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

RE: [BPQ32] Re: New CMS Site

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.