Loading ...
Sorry, an error occurred while loading the content.

New CMS Site

Expand Messages
  • John Wiseman
    The Winlink team has deployed an additional CMS site (brentwood.winlink.org). If you are using the CMS option of TelnetServer to access the Winlink servers the
    Message 1 of 17 , Jul 8, 2011
    • 0 Attachment
      The Winlink team has deployed an additional CMS site
      (brentwood.winlink.org).

      If you are using the CMS option of TelnetServer to access the Winlink
      servers the new server should be picked up automatically. There is no need
      to reload BPQ32.

      73,
      John G88BPO
    • Jeff - WA4ZKO
      Looks like they ve also changed something that prevents the hosts file trick from blocking autoupdate on their software, at least on RMS Express. Guess I ll
      Message 2 of 17 , Jul 8, 2011
      • 0 Attachment
        Looks like they've also changed something that prevents the hosts file trick from blocking autoupdate on their software, at least on RMS Express. Guess I'll just have to firewall it off.

        Considering RMS Express v1.1.1.2 blew up the channel listings, I'd think it would be wise to rethink the forced autoupdate mechanism so folks could have a bit more control over when it happens. Why they have to be such a PIA on this topic baffles me. Why is it just too simple to just toss up a windows "hey there's an update available, do you want to download & install or wait till later" Good grief.

        Sorry for my venting ;-)


        73
        Jeff
        WA4ZKO

        --- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@...> wrote:
        >
        >
        > The Winlink team has deployed an additional CMS site
        > (brentwood.winlink.org).
        >
        > If you are using the CMS option of TelnetServer to access the Winlink
        > servers the new server should be picked up automatically. There is no need
        > to reload BPQ32.
        >
        > 73,
        > John G88BPO
        >
      • Matt Zilmer
        Well, if anyone cares, it s RMS Express 1.1.1.3 now.... One logical reason for forced updates is compatibility with the RMS software. A very few times, I ve
        Message 3 of 17 , Jul 8, 2011
        • 0 Attachment
          Well, if anyone cares, it's RMS Express 1.1.1.3 now....

          One logical reason for forced updates is compatibility with the RMS software.  A very few times, I've seen some major downrev'ed clients try to check in at my MARS RMS.  If the downrev is far enough back, there may be a few troubles (getting caught in a state-state loop sometimes).  Forced updates are simply the best way to ensure that most clients stay compatible with the RMS software.

          Long-term, forced updates make it more likely the whole system will interoperate with the fewest problems.

          Yeah, getting boxed in by having the AP yell at you for trying to shut down before the update is complete can be a PITA.  However, some users would *never* update if they were given the opportunity to choose.  This is very common with SDRs as well (the K3 for example) and can have strange results if a long overdue firmware upgrade is applied.  i know quite a few K3 ops that haven't done any upgrades at all.  Updates are best applied serially, for reasons of continuity and incremental bug reporting: "Which rev caused that bug, this one or the one before, or ...?"

          Meanwhile, our IT geniuses here at Magellan have very conveniently disabled SMTP outbounds as well as Telnet, so I can't get MARS traffic early in the day for distribution on the day's traffic net in the afternoon.  Sheesh!

          73,

          Matt Zilmer, W6NIA / NNN0UET / NNN0GAF THREE
          NMCM RMS Winmor: NNU9ET-5: Upland, CA.




          To: BPQ32@yahoogroups.com
          From: wa4zko@...
          Date: Fri, 8 Jul 2011 14:25:02 +0000
          Subject: [BPQ32] Re: New CMS Site

           
          Looks like they've also changed something that prevents the hosts file trick from blocking autoupdate on their software, at least on RMS Express. Guess I'll just have to firewall it off.

          Considering RMS Express v1.1.1.2 blew up the channel listings, I'd think it would be wise to rethink the forced autoupdate mechanism so folks could have a bit more control over when it happens. Why they have to be such a PIA on this topic baffles me. Why is it just too simple to just toss up a windows "hey there's an update available, do you want to download & install or wait till later" Good grief.

          Sorry for my venting ;-)

          73
          Jeff
          WA4ZKO

          --- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@...> wrote:
          >
          >
          > The Winlink team has deployed an additional CMS site
          > (brentwood.winlink.org).
          >
          > If you are using the CMS option of TelnetServer to access the Winlink
          > servers the new server should be picked up automatically. There is no need
          > to reload BPQ32.
          >
          > 73,
          > John G88BPO
          >


        • Jeff - WA4ZKO
          Well they (WDT) did a good job of cranking out a new fixed version of RMS Express although there s hints that the MARS side of things may still be broken. Of
          Message 4 of 17 , Jul 8, 2011
          • 0 Attachment
            Well they (WDT) did a good job of cranking out a new fixed version of RMS Express although there's hints that the MARS side of things may still be broken. Of course if you were someone that only had internet access long enough to get the broken version forced upon you, well it sucks to be you ;-)

            I agree that there has to be some means of getting folks to remain reasonably up to date. That said, forced/no-choice/no notification till after the fact software updates for every version that comes along is a very bad idea. Virtually any professional software project dev/manager will tell you that. Heck even Microsoft gives you several choices, auto, download & notify, notify only, or disabled entirely.

            I've seen what you mentioned regarding folks with really ancient client software installs. Often it's the /MM folks that probably are not around internet access enough to get the updates. This is true at least on the connects I've observed into my BPQ32 based gateway. As such, even the forced update scheme is failing to keep everyone on the same version.

            Would seem to me that the better approach would be to give the users some choice. Have a defined and known version/update and lifecycle policy. Then have the CMS servers check the client version of each incoming connect. If the user is using a somewhat old version then have the gateway response include a message along the lines of "version 1.x.x.x is no longer current, please update asap." If they are running a really old version then maybe provide a warning and only allow them to connect once or twice a day till they upgrade. This would prevent anyone without internet access from being completely cutoff if they can't upgrade immediately, but provide a hard to ignore incentive to upgrade as soon as they have internet access. The old carrot versus billy-club approach.

            I understand and respect that the WDT is a handful of volunteer devs making do with what they have and limited time. That said, John is pretty much a one man show with BPQ32 and (IMHO) turns out a solid product without the needing to forcing folks to update to the latest version every time one comes out. This is why many of us do not run RMS Packet/WINMOR anymore and choose to use BPQ32's built in CMS gateway that works like a jewel without the headaches of the RMS Packet software.

            It would seem to me that the WDT needs to stop using it's entire user base as it's "beta" testing team. A small "beta test" team of folks would of easily caught the RMS Express v1.1.1.2 bug.

            John uses a small group of folks to test his new BPQ32/BPQMailChat versions before creating a "public" release version. The perks of this approach speak for themselves.

            Yeah it's easy to set back and nitpick, but a great deal of the RMS headache just doesn't have to exist in the first place. That's why it's so aggravating to the users.


            73
            Jeff
            WA4ZKO

            --- In BPQ32@yahoogroups.com, Matt Zilmer <mzilmer@...> wrote:
            >
            >
            > Well, if anyone cares, it's RMS Express 1.1.1.3 now....
            >
            > One logical reason for forced updates is compatibility with the RMS software. A very few times, I've seen some major downrev'ed clients try to check in at my MARS RMS. If the downrev is far enough back, there may be a few troubles (getting caught in a state-state loop sometimes). Forced updates are simply the best way to ensure that most clients stay compatible with the RMS software.
            >
            > Long-term, forced updates make it more likely the whole system will interoperate with the fewest problems.
            > Yeah, getting boxed in by having the AP yell at you for trying to shut down before the update is complete can be a PITA. However, some users would *never* update if they were given the opportunity to choose. This is very common with SDRs as well (the K3 for example) and can have strange results if a long overdue firmware upgrade is applied. i know quite a few K3 ops that haven't done any upgrades at all. Updates are best applied serially, for reasons of continuity and incremental bug reporting: "Which rev caused that bug, this one or the one before, or ...?"
            >
            > Meanwhile, our IT geniuses here at Magellan have very conveniently disabled SMTP outbounds as well as Telnet, so I can't get MARS traffic early in the day for distribution on the day's traffic net in the afternoon. Sheesh!
            >
            > 73,
            > Matt Zilmer, W6NIA / NNN0UET / NNN0GAF THREE
            > NMCM RMS Winmor: NNU9ET-5: Upland, CA.
            >
            >
            >
            > To: BPQ32@yahoogroups.com
            > From: wa4zko@...
            > Date: Fri, 8 Jul 2011 14:25:02 +0000
            > Subject: [BPQ32] Re: New CMS Site
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            > Looks like they've also changed something that prevents the hosts file trick from blocking autoupdate on their software, at least on RMS Express. Guess I'll just have to firewall it off.
            >
            >
            >
            > Considering RMS Express v1.1.1.2 blew up the channel listings, I'd think it would be wise to rethink the forced autoupdate mechanism so folks could have a bit more control over when it happens. Why they have to be such a PIA on this topic baffles me. Why is it just too simple to just toss up a windows "hey there's an update available, do you want to download & install or wait till later" Good grief.
            >
            >
            >
            > Sorry for my venting ;-)
            >
            >
            >
            > 73
            >
            > Jeff
            >
            > WA4ZKO
            >
            >
            >
            > --- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@> wrote:
            >
            > >
            >
            > >
            >
            > > The Winlink team has deployed an additional CMS site
            >
            > > (brentwood.winlink.org).
            >
            > >
            >
            > > If you are using the CMS option of TelnetServer to access the Winlink
            >
            > > servers the new server should be picked up automatically. There is no need
            >
            > > to reload BPQ32.
            >
            > >
            >
            > > 73,
            >
            > > John G88BPO
            >
            > >
            >
          • Rick Muething
            Jeff, The forced update of WL2K based programs (auto update) is there primarily for two reasons: 1) It is the only thing we have found to date that keeps users
            Message 5 of 17 , Jul 8, 2011
            • 0 Attachment
              Jeff,
               
              The forced update of WL2K based programs (auto update) is there primarily for two reasons:
               
              1) It is the only thing we have found to date that keeps users up to date (most have the attitude if it ain’t broke don’t fix it!). Old versions continually cause compatibility problems and questions about “bugs”  long since fixed.
               
              and more important...
               
              2) The WL2K programming “staff” is a few (usually 3 or 4) dedicated part-time volunteers that also happen to be (in their current or past jobs) professional programmers.  Auto updating dramatically reduces the support required (“I am having a problem with my old version 1.0.0 running on WIN 98. ....should I now update to 3.0.0...etc.). Commercial organization have the luxury of a group (sometimes a very large group) that is dedicated to support including back rev support that a small all-volunteer team just can’t duplicate.  I don’t think it is really appropriate to compare the update mechanisms and support of a 4 person part-time volunteer development team with commercial companies like Microsoft which probably has a “screen saver” group with far more manpower  than WL2K has programmers.
               
              Unless and until ham radio embraces the reality that well written and well supported software is of real value that doesn’t come “free”  we will have to accept the fact that development and cradle to grave support will never likely rival what is available through commercial software.
               
              If you know of or can figure out a mechanism that would support, maintain and document old revisions without a significant load on our very limited manpower or wish to join the WL2K development team to aid in that effort we would very much appreciate your input.
               
              73,
               
              Rick Muething, KN6KB
            • Ken Jacobs
              Thanks John...I checked my Debugview Log and it picked up the new CMS just fine. Workin great! Ken KD6PGI
              Message 6 of 17 , Jul 8, 2011
              • 0 Attachment
                Thanks John...I checked my Debugview Log and it picked up the new CMS just fine. Workin great!

                Ken KD6PGI

                On Fri, Jul 8, 2011 at 3:01 AM, John Wiseman <john.wiseman@...> wrote:
                 


                The Winlink team has deployed an additional CMS site
                (brentwood.winlink.org).

                If you are using the CMS option of TelnetServer to access the Winlink
                servers the new server should be picked up automatically. There is no need
                to reload BPQ32.

                73,
                John G88BPO


              • Jeff - WA4ZKO
                Rick, A suggested better approach was detailed in my 4th paragraph of my previous posting. http://groups.yahoo.com/group/BPQ32/message/6331 Unfortunately the
                Message 7 of 17 , Jul 8, 2011
                • 0 Attachment
                  Rick,

                  A suggested "better" approach was detailed in my 4th paragraph of my previous posting.

                  http://groups.yahoo.com/group/BPQ32/message/6331

                  Unfortunately the current update approach is still failing to get everyone up on the same client version so why not try a notification and carrot based approach?

                  My acknowledgment of WDT's limited staff and resources was covered well in the 5th paragraph.

                  I don't expect Microsoft level of support from WDT ;-) The concerns revolve around update philosophy for which I know of no other ham software systems going about it the same way (forced updates). It's also an update approach that could easily be problematic in many scenarios.

                  If they come to you complaining about things due to an old version, simply tell them "update" or direct your inquiry to the mailing lists where they will likely get the same answer.

                  Maybe create a web form on the winlik.org site where all "bug reports" to the WDT must originate. Have the form ask for versions involved as part of the reporting process. Then if they they are running old versions, have the page inform them to try the current version as "we only support version "X" and newer."

                  When a new version of RMS software comes out, detail the fixes and new features on the related public mailing lists. This will help folks decide to update to get the new features/fixes. While including the release history text file with the new install is nice, the problem is no one sees that till that version has already been installed.

                  Again, I think the client version "screening" and limitation approach I mentioned in my previous posting would do far more to motivate folks to update than a forced approach. The current forced approach only irks many users off, creates new problems/concerns, and forces many to flat block the updates.

                  Plus, the current approach seems to be creating it's own share of "support" load issues too.


                  73
                  Jeff
                  WA4ZKO

                  --- In BPQ32@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                  >
                  > Jeff,
                  >
                  > The forced update of WL2K based programs (auto update) is there primarily for two reasons:
                  >
                  > 1) It is the only thing we have found to date that keeps users up to date (most have the attitude if it ain’t broke don’t fix it!). Old versions continually cause compatibility problems and questions about “bugs” long since fixed.
                  >
                  > and more important...
                  >
                  > 2) The WL2K programming “staff” is a few (usually 3 or 4) dedicated part-time volunteers that also happen to be (in their current or past jobs) professional programmers. Auto updating dramatically reduces the support required (“I am having a problem with my old version 1.0.0 running on WIN 98. ....should I now update to 3.0.0...etc.). Commercial organization have the luxury of a group (sometimes a very large group) that is dedicated to support including back rev support that a small all-volunteer team just can’t duplicate. I don’t think it is really appropriate to compare the update mechanisms and support of a 4 person part-time volunteer development team with commercial companies like Microsoft which probably has a “screen saver” group with far more manpower than WL2K has programmers.
                  >
                  > Unless and until ham radio embraces the reality that well written and well supported software is of real value that doesn’t come “free” we will have to accept the fact that development and cradle to grave support will never likely rival what is available through commercial software.
                  >
                  > If you know of or can figure out a mechanism that would support, maintain and document old revisions without a significant load on our very limited manpower or wish to join the WL2K development team to aid in that effort we would very much appreciate your input.
                  >
                  > 73,
                  >
                  > Rick Muething, KN6KB
                  >
                • Rick Muething
                  Jeff, Thanks for the response and pointing me to your suggestion. These are worth considering. However like most things in the real world there is always
                  Message 8 of 17 , Jul 8, 2011
                  • 0 Attachment
                    Jeff,
                     
                    Thanks for the response and pointing me to your suggestion.  These are worth considering.  However like most things in the real world there is always more to it.  For one thing such changes to the CMS as you suggest are not trivial.  There are 4 redundant CMS servers which must maintain message and user info and database synchronization  as well as full SMTP mail systems. This is all done with about 10 different major CMS applications (also written, supported and maintained by the same 3-4 member development team) as well as another small group of WL2K network wizards. Most users and sysops never see these “applications”  but they are a necessary part of the WL2K system and collectively they are larger and more complex than all the RMS server and client programs combined.
                     
                    In the past we have tried more automated bug reporting and rating systems with only limited success. Most users simply use it as a wish list (when will you write a driver for my obscure radio?...) or fail to supply useful information that narrows down where the problem might be.
                     
                    There is certainly always room for improvement including better exhaustive testing of updates to insure they don’t cause any un intended problems or incompatibilities.  This too takes good dedicated manpower including a  SKILLED team of dedicated beta testers.  Unfortunately requests for “BETA” testers are too often than not met with “Gee I’d like try try anything digital”  or replies like “It Crashes” without any other input or information.  Or Yes, I can help but only for a week. Beta testing  requires dedication, skill and commitment too.
                     
                    We will look carefully at your suggestions and continue to evaluate alternatives that still do not compromise remote users that have no internet access and ways to improve the effectiveness of our limited volunteer resources. We welcome those that wish to contribute their time skills and resources to continuing and improving the WL2K system....Now in its 12th year of continuous operation!
                     
                    73,
                     
                    Rick Muething, KN6KB
                     
                    Sent: Friday, July 08, 2011 2:00 PM
                    Subject: [BPQ32] Re: New CMS Site
                     
                     

                    Rick,

                    A suggested "better" approach was detailed in my 4th paragraph of my previous posting.

                    http://groups.yahoo.com/group/BPQ32/message/6331

                    Unfortunately the current update approach is still failing to get everyone up on the same client version so why not try a notification and carrot based approach?

                    My acknowledgment of WDT's limited staff and resources was covered well in the 5th paragraph.

                    I don't expect Microsoft level of support from WDT ;-) The concerns revolve around update philosophy for which I know of no other ham software systems going about it the same way (forced updates). It's also an update approach that could easily be problematic in many scenarios.

                    If they come to you complaining about things due to an old version, simply tell them "update" or direct your inquiry to the mailing lists where they will likely get the same answer.

                    Maybe create a web form on the winlik.org site where all "bug reports" to the WDT must originate. Have the form ask for versions involved as part of the reporting process. Then if they they are running old versions, have the page inform them to try the current version as "we only support version "X" and newer."

                    When a new version of RMS software comes out, detail the fixes and new features on the related public mailing lists. This will help folks decide to update to get the new features/fixes. While including the release history text file with the new install is nice, the problem is no one sees that till that version has already been installed.

                    Again, I think the client version "screening" and limitation approach I mentioned in my previous posting would do far more to motivate folks to update than a forced approach. The current forced approach only irks many users off, creates new problems/concerns, and forces many to flat block the updates.

                    Plus, the current approach seems to be creating it's own share of "support" load issues too.

                    73
                    Jeff
                    WA4ZKO

                    --- In mailto:BPQ32%40yahoogroups.com, "Rick Muething" <rmuething@...> wrote:

                    >
                    > Jeff,
                    >
                    > The forced update of WL2K based programs (auto update) is there
                    primarily for two reasons:
                    >
                    > 1) It is the only thing we have
                    found to date that keeps users up to date (most have the attitude if it ain’t broke don’t fix it!). Old versions continually cause compatibility problems and questions about “bugs” long since fixed.
                    >
                    > and more
                    important...
                    >
                    > 2) The WL2K programming “staff” is a few
                    (usually 3 or 4) dedicated part-time volunteers that also happen to be (in their current or past jobs) professional programmers. Auto updating dramatically reduces the support required (“I am having a problem with my old version 1.0.0 running on WIN 98. ....should I now update to 3.0.0...etc.). Commercial organization have the luxury of a group (sometimes a very large group) that is dedicated to support including back rev support that a small all-volunteer team just can’t duplicate. I don’t think it is really appropriate to compare the update mechanisms and support of a 4 person part-time volunteer development team with commercial companies like Microsoft which probably has a “screen saver” group with far more manpower than WL2K has programmers.
                    >
                    > Unless
                    and until ham radio embraces the reality that well written and well supported software is of real value that doesn’t come “free” we will have to accept the fact that development and cradle to grave support will never likely rival what is available through commercial software.
                    >
                    > If you know of
                    or can figure out a mechanism that would support, maintain and document old revisions without a significant load on our very limited manpower or wish to join the WL2K development team to aid in that effort we would very much appreciate your input.
                    >
                    > 73,
                    >
                    > Rick Muething,
                    KN6KB
                    >


                    No virus found in this message.
                    Checked by AVG - www.avg.com
                    Version: 10.0.1388 / Virus Database: 1516/3751 - Release Date: 07/08/11

                  • DEC
                    Isn t there a Winlink reflector for this?
                    Message 9 of 17 , Jul 8, 2011
                    • 0 Attachment
                      Isn't there a Winlink reflector for this?




                      On Jul 8, 2011, at 11:07 AM, Matt Zilmer <mzilmer@...> wrote:

                       

                      Well, if anyone cares, it's RMS Express 1.1.1.3 now....

                      One logical reason for forced updates is compatibility with the RMS software.  A very few times, I've seen some major downrev'ed clients try to check in at my MARS RMS.  If the downrev is far enough back, there may be a few troubles (getting caught in a state-state loop sometimes).  Forced updates are simply the best way to ensure that most clients stay compatible with the RMS software.

                      Long-term, forced updates make it more likely the whole system will interoperate with the fewest problems.

                      Yeah, getting boxed in by having the AP yell at you for trying to shut down before the update is complete can be a PITA.  However, some users would *never* update if they were given the opportunity to choose.  This is very common with SDRs as well (the K3 for example) and can have strange results if a long overdue firmware upgrade is applied.  i know quite a few K3 ops that haven't done any upgrades at all.  Updates are best applied serially, for reasons of continuity and incremental bug reporting: "Which rev caused that bug, this one or the one before, or ...?"

                      Meanwhile, our IT geniuses here at Magellan have very conveniently disabled SMTP outbounds as well as Telnet, so I can't get MARS traffic early in the day for distribution on the day's traffic net in the afternoon.  Sheesh!

                      73,

                      Matt Zilmer, W6NIA / NNN0UET / NNN0GAF THREE
                      NMCM RMS Winmor: NNU9ET-5: Upland, CA.




                      To: BPQ32@yahoogroups.com
                      From: wa4zko@...
                      Date: Fri, 8 Jul 2011 14:25:02 +0000
                      Subject: [BPQ32] Re: New CMS Site

                       
                      Looks like they've also changed something that prevents the hosts file trick from blocking autoupdate on their software, at least on RMS Express. Guess I'll just have to firewall it off.

                      Considering RMS Express v1.1.1.2 blew up the channel listings, I'd think it would be wise to rethink the forced autoupdate mechanism so folks could have a bit more control over when it happens. Why they have to be such a PIA on this topic baffles me. Why is it just too simple to just toss up a windows "hey there's an update available, do you want to download & install or wait till later" Good grief.

                      Sorry for my venting ;-)

                      73
                      Jeff
                      WA4ZKO

                      --- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@...> wrote:
                      >
                      >
                      > The Winlink team has deployed an additional CMS site
                      > (brentwood.winlink.org).
                      >
                      > If you are using the CMS option of TelnetServer to access the Winlink
                      > servers the new server should be picked up automatically. There is no need
                      > to reload BPQ32.
                      >
                      > 73,
                      > John G88BPO
                      >


                    • Jeff - WA4ZKO
                      With CMS gateway functionality built into the BPQ32 telnet server & a number of folks using RMS Express for a basic BPQBBS client....I d say it s plenty
                      Message 10 of 17 , Jul 8, 2011
                      • 0 Attachment
                        With CMS gateway functionality built into the BPQ32 telnet server & a number of folks using RMS Express for a basic BPQBBS client....I'd say it's plenty relevant for this list.


                        73
                        Jeff
                        WA4ZKO

                        --- In BPQ32@yahoogroups.com, DEC <n4zkf@...> wrote:
                        >
                        > Isn't there a Winlink reflector for this?
                        >
                        >
                        >
                        >
                        > On Jul 8, 2011, at 11:07 AM, Matt Zilmer <mzilmer@...> wrote:
                        >
                        > > Well, if anyone cares, it's RMS Express 1.1.1.3 now....
                        > >
                        > > One logical reason for forced updates is compatibility with the RMS software. A very few times, I've seen some major downrev'ed clients try to check in at my MARS RMS. If the downrev is far enough back, there may be a few troubles (getting caught in a state-state loop sometimes). Forced updates are simply the best way to ensure that most clients stay compatible with the RMS software.
                        > >
                        > > Long-term, forced updates make it more likely the whole system will interoperate with the fewest problems.
                        > >
                        > > Yeah, getting boxed in by having the AP yell at you for trying to shut down before the update is complete can be a PITA. However, some users would *never* update if they were given the opportunity to choose. This is very common with SDRs as well (the K3 for example) and can have strange results if a long overdue firmware upgrade is applied. i know quite a few K3 ops that haven't done any upgrades at all. Updates are best applied serially, for reasons of continuity and incremental bug reporting: "Which rev caused that bug, this one or the one before, or ...?"
                        > >
                        > > Meanwhile, our IT geniuses here at Magellan have very conveniently disabled SMTP outbounds as well as Telnet, so I can't get MARS traffic early in the day for distribution on the day's traffic net in the afternoon. Sheesh!
                        > >
                        > > 73,
                        > > Matt Zilmer, W6NIA / NNN0UET / NNN0GAF THREE
                        > > NMCM RMS Winmor: NNU9ET-5: Upland, CA.
                        > >
                        > >
                        > >
                        > > To: BPQ32@yahoogroups.com
                        > > From: wa4zko@...
                        > > Date: Fri, 8 Jul 2011 14:25:02 +0000
                        > > Subject: [BPQ32] Re: New CMS Site
                        > >
                        > >
                        > > Looks like they've also changed something that prevents the hosts file trick from blocking autoupdate on their software, at least on RMS Express. Guess I'll just have to firewall it off.
                        > >
                        > > Considering RMS Express v1.1.1.2 blew up the channel listings, I'd think it would be wise to rethink the forced autoupdate mechanism so folks could have a bit more control over when it happens. Why they have to be such a PIA on this topic baffles me. Why is it just too simple to just toss up a windows "hey there's an update available, do you want to download & install or wait till later" Good grief.
                        > >
                        > > Sorry for my venting ;-)
                        > >
                        > > 73
                        > > Jeff
                        > > WA4ZKO
                        > >
                        > > --- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@> wrote:
                        > > >
                        > > >
                        > > > The Winlink team has deployed an additional CMS site
                        > > > (brentwood.winlink.org).
                        > > >
                        > > > If you are using the CMS option of TelnetServer to access the Winlink
                        > > > servers the new server should be picked up automatically. There is no need
                        > > > to reload BPQ32.
                        > > >
                        > > > 73,
                        > > > John G88BPO
                        > > >
                        > >
                        > >
                        > >
                        >
                      • DEC
                        Guess it s time for me to unsubscribe then. Dave n4zkf
                        Message 11 of 17 , Jul 8, 2011
                        • 0 Attachment
                          Guess it's time for me to unsubscribe then.

                          Dave
                          n4zkf





                          On Jul 8, 2011, at 7:23 PM, "Jeff - WA4ZKO" <wa4zko@...> wrote:

                           

                          With CMS gateway functionality built into the BPQ32 telnet server & a number of folks using RMS Express for a basic BPQBBS client....I'd say it's plenty relevant for this list.

                          73
                          Jeff
                          WA4ZKO

                          --- In BPQ32@yahoogroups.com, DEC <n4zkf@...> wrote:
                          >
                          > Isn't there a Winlink reflector for this?
                          >
                          >
                          >
                          >
                          > On Jul 8, 2011, at 11:07 AM, Matt Zilmer <mzilmer@...> wrote:
                          >
                          > > Well, if anyone cares, it's RMS Express 1.1.1.3 now....
                          > >
                          > > One logical reason for forced updates is compatibility with the RMS software. A very few times, I've seen some major downrev'ed clients try to check in at my MARS RMS. If the downrev is far enough back, there may be a few troubles (getting caught in a state-state loop sometimes). Forced updates are simply the best way to ensure that most clients stay compatible with the RMS software.
                          > >
                          > > Long-term, forced updates make it more likely the whole system will interoperate with the fewest problems.
                          > >
                          > > Yeah, getting boxed in by having the AP yell at you for trying to shut down before the update is complete can be a PITA. However, some users would *never* update if they were given the opportunity to choose. This is very common with SDRs as well (the K3 for example) and can have strange results if a long overdue firmware upgrade is applied. i know quite a few K3 ops that haven't done any upgrades at all. Updates are best applied serially, for reasons of continuity and incremental bug reporting: "Which rev caused that bug, this one or the one before, or ...?"
                          > >
                          > > Meanwhile, our IT geniuses here at Magellan have very conveniently disabled SMTP outbounds as well as Telnet, so I can't get MARS traffic early in the day for distribution on the day's traffic net in the afternoon. Sheesh!
                          > >
                          > > 73,
                          > > Matt Zilmer, W6NIA / NNN0UET / NNN0GAF THREE
                          > > NMCM RMS Winmor: NNU9ET-5: Upland, CA.
                          > >
                          > >
                          > >
                          > > To: BPQ32@yahoogroups.com
                          > > From: wa4zko@...
                          > > Date: Fri, 8 Jul 2011 14:25:02 +0000
                          > > Subject: [BPQ32] Re: New CMS Site
                          > >
                          > >
                          > > Looks like they've also changed something that prevents the hosts file trick from blocking autoupdate on their software, at least on RMS Express. Guess I'll just have to firewall it off.
                          > >
                          > > Considering RMS Express v1.1.1.2 blew up the channel listings, I'd think it would be wise to rethink the forced autoupdate mechanism so folks could have a bit more control over when it happens. Why they have to be such a PIA on this topic baffles me. Why is it just too simple to just toss up a windows "hey there's an update available, do you want to download & install or wait till later" Good grief.
                          > >
                          > > Sorry for my venting ;-)
                          > >
                          > > 73
                          > > Jeff
                          > > WA4ZKO
                          > >
                          > > --- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@> wrote:
                          > > >
                          > > >
                          > > > The Winlink team has deployed an additional CMS site
                          > > > (brentwood.winlink.org).
                          > > >
                          > > > If you are using the CMS option of TelnetServer to access the Winlink
                          > > > servers the new server should be picked up automatically. There is no need
                          > > > to reload BPQ32.
                          > > >
                          > > > 73,
                          > > > John G88BPO
                          > > >
                          > >
                          > >
                          > >
                          >

                        • DEC
                          Yes! I did.
                          Message 12 of 17 , Jul 11, 2011
                          • 0 Attachment
                            Yes! I did.




                            On Jul 7, 2011, at 6:53 AM, "John Wiseman" <john.wiseman@...> wrote:

                             

                            Dave,
                             
                            Did you ever try the XP version?
                             
                            73,
                            John
                             


                            From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of DEC
                            Sent: 07 July 2011 11:47
                            To: BPQ32@yahoogroups.com
                            Subject: Re: [BPQ32] THOR RLC-100

                             

                            That do work though! Thanks John.

                            Dave
                            n4zkf




                            On Jul 7, 2011, at 5:57 AM, "John Wiseman" <john.wiseman@...> wrote:

                             

                            Keith,
                             
                            There are drivers for HDLC cards, including the RLC100, available for both Win98 and XP, but they are not part of the standard distrbution. They are used by very few stations, so should be considered experimental. If you'd lke to try either, let me know, and I'll dig out the code and documentation.
                             
                            I don't think either have been tested specifically with the RLC100, but any card that worked with DOS BPQ should be ok.
                             
                            73,
                            John
                             


                            From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of Keith
                            Sent: 07 July 2011 10:33
                            To: BPQ32@yahoogroups.com
                            Subject: [BPQ32] THOR RLC-100

                             

                            Has anybody managed to use BPQ32 with a THOR RLC-100 4 Port Packet Radio Data Controller? Using Xrouter at present but would love to be able to do away with the DOS element.

                            73 de Keith G1GXB

                          Your message has been successfully submitted and would be delivered to recipients shortly.