1 INFO-VAX	Fri, 09 Nov 2001	Volume 2001 : Issue 623       Contents:! Alpha to Itanium Technical Update  Re: Backup and open files  Callable backup API and ECO  Re: Callable backup API and ECO  Re: Compaq guarantees? Re: Compaq guarantees? Re: Compaq guarantees? Re: Compaq guarantees?% Re: Compaq's future (or lack thereof) $ Re: Compaq: VMS is alive and kicking% Re:  Compaq: VMS is alive and kicking  Re: DECUS in many names  Re: DECUS in many names ! Re: DHCP client software for VMS?  Re: eco notices D Re: Editing DCL command lines longer than the current terminal widthD Re: Editing DCL command lines longer than the current terminal widthD Re: Editing DCL command lines longer than the current terminal widthD Re: Editing DCL command lines longer than the current terminal widthD Re: Editing DCL command lines longer than the current terminal width Re: Emacs-2[01] on VMS RE: Emacs-2[01] on VMS Re: EMC + software raid % Re: How to upgrade VMS/Vax 6.0 to 6.1  Re: ignore - just a test post @ Re: Is TCP/IP really needed to install WEBES and Compaq Analyze? Re: Lost system password* Re: Name Change of Alpha Server 4000 5/300 Re: ok I am back in my office  Re: ok I am back in my office  Re: ok I am back in my office  Re: ok I am back in my office E Reliable Transaction Router (RTR) for Linux Intel and Alpha beta kits A Rob's British Champion, was: Re: Compaq: VMS is alive and kicking E Re: Rob's British Champion, was: Re: Compaq: VMS is alive and kicking E Re: Rob's British Champion, was: Re: Compaq: VMS is alive and kicking # Re: Transparent RMS access to TCPIP # Re: Transparent RMS access to TCPIP  VMS Landing Versions for VAX  Re: VMS Landing Versions for VAX  Re: VMS Landing Versions for VAX+ VMS upgrade and SCSI disk firmware question  Re: welcome.txt ( Re: What comes after TCPIP$FTP_SHUTDOWN?
 where is 7.3?  Re: Which Disks are Which?P [Fwd: FW: INFORMATION ANARCHY = As good as it gets? Software CAN be bui	ltsecure [Help]Serial QIO Code  Re: [Help]Serial QIO Code  Re: [Help]Serial QIO Code  Re: [Help]Serial QIO Code  Re: [Help]Serial QIO Code   F ----------------------------------------------------------------------  $ Date: Thu, 8 Nov 2001 16:45:36 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>* Subject: Alpha to Itanium Technical Update3 Message-ID: <Y0DG7.1417$RL6.46293@news.cpqcorp.net>    Dear Newsgroup,   L I just got this, you may be interested in participating in this.  Please let( Dale know you saw this on the newsgroup.   Sue       K Gaitan D'Antoni will be presenting a valuable to our ISV's and customers on  the following dates:       Date Time Target Audience   0 Monday, November 19th 11-1 p.m. Developers/ISV's  2 Friday, November 30th 11-12:30 p.m Customers/Sales  H Each webcast will cover an update on the port of OpenVMS to the ItaniumTH Processor Family that was announced in June, 2001. During this technicalK session, you will learn about the current OpenVMS ItaniumT Processor Family I schedule, plans for porting layered products, plans for compilers, binary A translators, and other preliminary information about porting your . applications to Itanium-based OpenVMS systems.  J The CSA list and customer list from the Littleton Call Center will be usedJ to invite people to these webcasts. If there is any doubt that one of yourJ contacts may not be on our mailing lists, forward their email addresses toK me now and I will send them an invitation. These presentations will also be  available for playback.    Dale Theresa Howard   " OpenVMS Business Solutions Manager   OpenVMS Systems Software Group   603-884-7300 ZKO3-4/4V02   dale.howard@compaq.com   ------------------------------   Date: 8 Nov 2001 18:36:57 -0800 . From: spamsink2001@yahoo.com (Alan E. Feldman)" Subject: Re: Backup and open files< Message-ID: <b096a4ee.0111081836.fb0fa57@posting.google.com>  k "DigiDemon" <digidemon@hotmail.com> wrote in message news:<20011107.081725.1350573793.22723@hotmail.com>...  > Good Morning all!  > ? > I have a lil question....here at work we use CONNEX ODBC data H > connectivity for data pulls.  We have been sheduling our backup aroundJ > these data pulls, but now it seems I'm running out of hours.  During theC > backup verification pass I know that any altered files will error F > out....but will open files do the same thing?  I'm not thinking they. > will...but I'd like to be sure.  Thanks all! >  > James   D Open files will not be backed up at all unless you use the qualifierD /IGNORE=INTERLOCK. If you use that qualifier, you will get a warning message for each open file.   C Any file that doesn't match during the verification pass will get a C verification error for each block that doesn't match, regardless of ! whether the file was open or not.    Disclaimer: JMHO Alan E. Feldman  afeldman&gfigroup.com    ------------------------------   Date: 8 Nov 2001 11:30:41 -0800 1 From: anders_wallin@altavista.com (Anders Wallin) $ Subject: Callable backup API and ECO< Message-ID: <6cc41c7.0111081130.50c54c67@posting.google.com>   Hi!   F I need to build an application using callable backup that shall run inG a cluster with VMS/Alpha nodes. Versions are 7.1-1H1, 7.2 and 7.2-1. We 1 will probably be running 7.3 within a year or so.   C How do I compile and link my application (written in C) so that the C same executable will run on all nodes. Today the program works only ' for the VMS version it was built under.   D 1) Can the ECO kit mentioned in the FAQ be installed on VMS versions    7.1-1H1, 7.2 and 7.2-1 ?    2) Is the API ok for VMS 7.3?    3) The name of the ECO-kit?   1 4) Any other information relevant to the problem?      Thanks for any help   
 Anders Wallin   F >--------------------- Found in FAQ ----------------------------------H >    Build your applications with the most current BACKUP API available.G >    Changes made to the V7.1-2 and V7.2 API were incompatible with the A >    V7.1 and V7.2-1 and later APIs, and this incompatibility was G >    repaired via a BACKUP ECO kit.  Do NOT build your application with F >    the versions of the BACKUP API that shipped with V7.1-2 and V7.2,F >    as these are incompatible with the BACKUP API constants that were >    used on other versions.I >------------------------------------------------------------------------    ------------------------------  $ Date: Thu, 8 Nov 2001 15:50:42 -0500% From: "John Vottero" <John@mvpsi.com> ( Subject: Re: Callable backup API and ECO/ Message-ID: <tuls13degmt17f@news.supernews.com>   I You should compile and link on the oldest version of VMS that you want to K support but you must make sure that the backup ECO is installed.   You have H to have the backup ECO on both the build machine and the target machine.  > "Anders Wallin" <anders_wallin@altavista.com> wrote in message6 news:6cc41c7.0111081130.50c54c67@posting.google.com... > Hi!  > H > I need to build an application using callable backup that shall run inI > a cluster with VMS/Alpha nodes. Versions are 7.1-1H1, 7.2 and 7.2-1. We 3 > will probably be running 7.3 within a year or so.  > E > How do I compile and link my application (written in C) so that the E > same executable will run on all nodes. Today the program works only ) > for the VMS version it was built under.  > F > 1) Can the ECO kit mentioned in the FAQ be installed on VMS versions >    7.1-1H1, 7.2 and 7.2-1 ?  >  > 2) Is the API ok for VMS 7.3?  >  > 3) The name of the ECO-kit?  > 3 > 4) Any other information relevant to the problem?  >  >  > Thanks for any help  >  > Anders Wallin  > H > >--------------------- Found in FAQ ----------------------------------J > >    Build your applications with the most current BACKUP API available.I > >    Changes made to the V7.1-2 and V7.2 API were incompatible with the C > >    V7.1 and V7.2-1 and later APIs, and this incompatibility was I > >    repaired via a BACKUP ECO kit.  Do NOT build your application with H > >    the versions of the BACKUP API that shipped with V7.1-2 and V7.2,H > >    as these are incompatible with the BACKUP API constants that were > >    used on other versions.K > >------------------------------------------------------------------------    ------------------------------  # Date: Thu, 08 Nov 2001 19:35:25 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Compaq guarantees? B Message-ID: <18BG7.102010$tb2.8255206@bin2.nnrp.aus1.giganews.com>  < Bill Gunshannon <bill@triangle.cs.uofs.edu> wrote in message& news:9seb8m$1q1k$1@info.cs.uofs.edu...
 really be.   ...   I > Too bad Ken Olsen isn't interested any more.  He probably has the money J > to buy a strong voting block (maybe even a majority share the way things1 > are going) of stock based on the current price.   L A nice thought, but my impression at some point was that KO was worth 'only'L a few hundred million, which even at the current price would purchase only a few percent of Compaq stock.   - bill   ------------------------------  # Date: Thu, 08 Nov 2001 19:46:11 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Compaq guarantees? A Message-ID: <7iBG7.62541$7x1.5399089@bin4.nnrp.aus1.giganews.com>   4 Barry Treahy, Jr. <Treahy@mmaz.com> wrote in message" news:3BEA8F59.F7E9867A@mmaz.com... >  > Peter da Silva wrote:  > 5 > > Maybe Compaq may need VMS more than they thought:  > > J > > http://cbs.marketwatch.com/news/story.asp?column=TechWatch&siteid=mktw > > K > > I hope Compaq can start up the EV8 development again. They may need to.  > J > Compaq already put the gun to their head and pulled the trigger on Alpha unless they  > can renege on the Intel deal.   L Not entirely clear.  If the deal doesn't not specify limitations on Compaq'sG option to resurrect Alpha, then they only put the gun (solidly) to both J feet, and with inspired prosthetic surgery *could* walk again if they wereL so inclined:  while most of the EV8 engineers have gone to Intel, the designJ may have been far enough along to be completed by the EV7 engineers CompaqI has left (plus any of those encouraged to leave who became convinced that B this time EV8 was for real and found Itanic less to their liking).  A That still may leave compilers in question, but if EV8 is largely K compiler-invisible (as long as no one starts trying to use SMT fine-grained B on single logical threads) that might not be an immediate problem.  J Resurrecting EV8 and succeeding with it would also be a suitable manner inL which to emphasize the utter incompetence (and/or personal greed in defianceC of their fiduciary obligations) of the unprincipled, lying bastards I currently at the helm, and about the closest legal alternative to tarring : and feathering them and riding them out of town on a rail.   - bill   ------------------------------  % Date: Thu, 08 Nov 2001 21:51:50 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: Compaq guarantees? ' Message-ID: <3BEB52D6.9683EB08@fsi.net>    Bob Ceculski wrote:  > b > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3BE8B95C.282EB342@fsi.net>... > > Bob Ceculski wrote:  > > > f > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3BE5F76C.8716C057@fsi.net>... > > > > Bill Gunshannon wrote:	 > > > > > E > > > > > In article <dpeF7.4735$MI.1685953@typhoon.ne.mediaone.net>, A > > > > >  "Terry C. Shannon" <terryshannon@mediaone.net> writes:  > > > > > |>C > > > > > |> And Gates, Grove, and McNealy would inherit the earth.  > > > > > |>	 > > > > > P > > > > You make my mouth water with such talk. Some others and myself (locally)M > > > > are hedging our bets on the chance that Solaris will see a resurgence K > > > > and Linux will come into its own in the server space. I'm sorry VMS O > > > > can't be there as well, but there's that whole "affordability" obstacle ! > > > > remaining to be overcome.  > > > >  > > > R > > > what affordability issue?  i am tired of people saying how expensive vms is!S > > > if you shop around you can find very good prices on boxes, licenses, anything ? > > > you need ... we just last year bought an alphaserver 1200  > > L > > Clearly, you do not work with enterprise-class equipment in environmentsH > > where lives are at stake. Management would never go for such a deal,K > > especially after the outage we just had - 9 days over the course of two I > > weeks, due to 64-bit PCI riser cards in GS160 (they've been recalled, I > > AFAIK, at least at Cerner sites - dunno about Compaq itself, but they L > > duplicated in their lab the problem we had which did rather an efficient+ > > job of scrambling our Oracle database).  > > I > > My partner was explaining to me today that 1+GHz "fireboxes" are over A > > $100,000 each - not sure what the GS160 istelf was worth new.  > > = > > ...and that doesn't BEGIN to discuss VMS license pricing.  > > J > > Better check a price list before making another post like that, son... > I > i can get you used certified gs80 & gs160 boxes for 25-50k depending on L > configurations, and as82 and 8400 boxes can still be bought new w/warrantyL > for cheap! ... es40's aren't bad either!  i may not be using the big stuff> > (i use alphaserver 800's and 1200's), but i know how to buy!  H If that's true, then you're in the wrong line of work. Oh, and learn howD to use the <SHIFT> key effectively. You'll find it works wonders forA your career to be able to communicate effectively and make a good  impression.   J > if you want me to find you a deal, new or used, let me know what you are > looking for!  E Take Compaq's entire hardware price list, apply a 60% to 90% discount H across the board. Take Compaq's entire software price list, apply an 80%" to 95% discount across the board.   G *THAT* will make our VMS-based quotes comptetive with the alternatives.    That's what we're looking for.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Thu, 08 Nov 2001 23:42:43 -0500 ( From: David Froble <davef@tsoft-inc.com> Subject: Re: Compaq guarantees? , Message-ID: <3BEB5EC3.3050908@tsoft-inc.com>   Bill Todd wrote:  > > Bill Gunshannon <bill@triangle.cs.uofs.edu> wrote in message( > news:9seb8m$1q1k$1@info.cs.uofs.edu... > really be. >  > ...  >  > I >>Too bad Ken Olsen isn't interested any more.  He probably has the money J >>to buy a strong voting block (maybe even a majority share the way things1 >>are going) of stock based on the current price.  >> > N > A nice thought, but my impression at some point was that KO was worth 'only'N > a few hundred million, which even at the current price would purchase only a > few percent of Compaq stock. >  > - bill    D And why should he waste his money?  If I had a portion of that 'few B hundred million' I'd much rather buy a tropical island, install a H runway, and have the option of laying in the sun, or in the shade under  the wing of my jet.  :-)     Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Thu, 08 Nov 2001 19:31:55 GMT * From: "Bill Todd" <billtodd@metrocast.net>. Subject: Re: Compaq's future (or lack thereof)A Message-ID: <L4BG7.62538$7x1.5390397@bin4.nnrp.aus1.giganews.com>   8 Warren Spencer <wspencer@ap.nospam.org> wrote in message1 news:915384F47warrenspencer1977@207.126.101.97... 1 > bill@cs.scranton.edu (Bill Gunshannon) wrote in " > <9sc4q0$n9n$1@info.cs.uofs.edu>:   ...   K > >But if Compaq were to get out of the un-profitable PeeCee biz and decide J > >to build on it's profitable VMS/Alpha biz what would they need HP for?? > >  > >bill  > >  > F > A cushion.  I suspect that "getting out" of any venture like that is hugelyI > expensive.  You've got fixed assets and employees to de-commission, and I > that costs big bucks.  Far better if you can sell it (see "Alphacide").  If? > you can't sell it, merge it with someone else's to dilute the  > decommissioning costs.  A Technically, the quotation read "if Compaq were to get out of the J *unprofitable* [emphasis mine] PeeCee biz", not "if Compaq were to get outI of the PeeCee biz" period.  IBM arguably got out of the 'unprofitable' PC J biz without getting out altogether, and if Compaq did the same (by settingE its pricing to make a modest profit while producing as efficiently asgI possible to serve those customers who wished to have one-stop shopping or I who otherwise like the brand rather than by setting pricing to attempt to ? gain market share) there'd be a lot less need for that cushion.i   - bill   ------------------------------  # Date: Mon, 05 Nov 2001 23:58:30 GMT  From: dittman@dittman.net - Subject: Re: Compaq: VMS is alive and kickingu? Message-ID: <GIFF7.7385$Z97.695958@e420r-atl2.usenetserver.com>h  . JF Mezei <jfmezei.spamnot@videotron.ca> wrote: : Peter Kastner wrote:9 :> From Aberdeen Group's perspective, here are the facts:t   : Thank you for chiming in.   H :> 3.  We gave HP and Compaq permission to post our research at internal# :> intranet web sites at no charge.   P : What I find interesting is that Compaq would proudly post a document not meantI : to be public which paints a poor picture of the future of Compaq's most0K : profitable product. If some consulting firm says that customers shouldn'tkI : trust Compaq because it is about to kill a product, Compaq shouldn't bei  : trumpeting around that report.  N What I find interesting is a company that is supposed to know what is going on= recommends that Compaq/HP kill their most profitable product.   N :> As to the root question, I recommend that concerned VMS users look up their$ :> counterparts who own HP 3000's.    K : Are HP 3000 users based on a dead chip and with a migration to IA64 too ?   H Late last year I had to work with some HP3000/MPE systems.  HP was stillI actively updating the OS.  The newer HP3000 systems (from what I was toldF% by an HP employee) use a PA-RISC CPU.  --   Eric Dittman dittman@dittman.netN= Check out the DEC Enthusiasts Club at http://www.dittman.net/]   ------------------------------  # Date: Tue, 06 Nov 2001 00:00:27 GMT  From: dittman@dittman.net . Subject: Re:  Compaq: VMS is alive and kicking? Message-ID: <vKFF7.7386$Z97.696582@e420r-atl2.usenetserver.com>,  + Peter Kastner <kastner@aberdeen.com> wrote:i  M : As to the root question, I recommend that concerned VMS users look up theirgK : counterparts who own HP 3000's.  From our vantage point, HP is not givinggM : any more support to its own venerable HP 3000 base than it is to the Compaq 
 : VMS base...   K Why would HP be giving any support to Compaq OpenVMS?  Right now the mergeroK is still in progress and until the merger is complete Compaq is the companye that supports OpenVMS. --   Eric Dittman dittman@dittman.nety= Check out the DEC Enthusiasts Club at http://www.dittman.net/l   ------------------------------  % Date: Thu, 08 Nov 2001 21:53:43 -0500t! From: Beyonder <beyonder@vrx.net>r  Subject: Re: DECUS in many names8 Message-ID: <e7hmut0ji4ejogh0dmulb938vogisk2us8@4ax.com>  D It already exists, in a sense, all you have to do is start USING it.  9 Wander on over to .VMS (there's .VAX and .ALPHA as well).t	 new TLDs.u  F ah but most of you can't get there (unless you don't realize it). heh.  D So what say you all? it's off the beaten track, it's there, and it's5 waiting for all the DECUS people and hobbyists alike.o   One rule: no politics.   B.F On Mon, 05 Nov 2001 13:21:05 +0000, Nic Clews <sendspamhere@127.0.0.1> wrote:   >JF Mezei wrote: >> tM >> I still maintain that there should be a single , global, VMS user's group.  >iC >Fully agreed. Same worldwide name too. VMSUG ? VMSUS ? (I like the3	 >latter).V > H >DECUS was DECUS, and I started in the UK chapter and joined quite a few' >SIGs. I believe that worked very well.y >oH >The 'new' way doesn't seem as coherant (perhaps some chairpersons wouldE >like to comment?) so I accept that my former suggestion may be a nonnF >starter. If on the network then, maybe a password protected FTP site,: >with details on release of a proper and valid membership. >oE >However I have to say I am pleased with the forward 10 months eventslE >calendar in the UK (we're called CUO and I didn't vote for it) but IoC >note that "the usergoup formerly known as DECUS (TUFKAD)" has beeno/ >hijacked by the iPaqs and a mickey soft bunch.       @ -----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----A http://www.newsfeeds.com - The #1 Newsgroup Service in the World!n@  Check out our new Unlimited Server. No Download or Time Limits!@ -----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----   ------------------------------  % Date: Thu, 08 Nov 2001 23:24:29 -0500v( From: David Froble <davef@tsoft-inc.com>  Subject: Re: DECUS in many names, Message-ID: <3BEB5A7D.2020401@tsoft-inc.com>   Alan Greig wrote:a  H > On Mon, 05 Nov 2001 13:21:05 +0000, Nic Clews <sendspamhere@127.0.0.1> > wrote: >  > F >>However I have to say I am pleased with the forward 10 months eventsF >>calendar in the UK (we're called CUO and I didn't vote for it) but I >> > G > Yep, I should be there for Dave Fenwick's talk next week then the webiE > enabling VMS session next month - assuming corporate don't suddenlye > impose any more flight bans. >  > D >>note that "the usergoup formerly known as DECUS (TUFKAD)" has been0 >>hijacked by the iPaqs and a mickey soft bunch. >> >  > -- > Alan >   C Well, it's also trying very hard to follow the DODO bird.  Just in:w  = Looking ahead, the Board of Directors has made some strategics< membership decisions for the coming year.  As an independentE association, the viability of Encompass lies directly in the hands ofrB our members.  Thus, we're asking you to support our new membershipG categories and their associated costs (all listed in US dollars), which-G will be effective for all new and renewing members beginning January 1, D 2002 with full implementation by December 31, 2002. Corporate memberC categories were created to increase the participation of recognizedo corporate entities.    *Individual Members- $90% *International Individual Member-$135 4 *Corporate Member (Five individuals included) - $400B *International Corporate Member (Five individuals included) - $600F *Associate- No cost (Associates will receive this newsletter and otherF e-mail communication, but miss out on valuable member benefits and are( not eligible for member-only activities)    G Real strategic!  Watch the membership drop with this one.  So much for lI the free hobbyist license.  While you're kilking Alpha and VMS, might as o# well take out the users group also.s  D I'd consider dues for a VMS organization.  (Guess I'm still an easy F mark.)  But $90 out of my pocket to rub sholders with windoz and ipaq  users?  HA!c   Dave   -- r4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Thu, 08 Nov 2001 21:51:23 -0500l! From: Beyonder <beyonder@vrx.net>e* Subject: Re: DHCP client software for VMS?8 Message-ID: <53hmutkn2il3jac2e62rnj9b79v9sjbl0s@4ax.com>  A On Mon, 5 Nov 2001 18:39:41 +0000 (UTC), david20@alpha2.mdx.ac.ukM wrote:L >Your idea for DECUS to handle this with deposits/rental fees sounds awful - >a bureucratic nightmare.7 >1 >David Webb. >VMS and Unix team leader  >CCSSV >Middlesex Universityn  A Well then I suggest we ALL wander on over to .VMS and forget thisp	 nonsense.    Yes, there is a TLD called .VMS   C How many of you out there want to be part of it, and get this stuff-A moving? no fees, no nonsense, just the way DECUS was meant to be.c   B.      @ -----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----A http://www.newsfeeds.com - The #1 Newsgroup Service in the World!a@  Check out our new Unlimited Server. No Download or Time Limits!@ -----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----   ------------------------------  # Date: Fri, 09 Nov 2001 00:19:57 GMTp6 From: "Andy Bustamante" <a_c_bustamante@earthlink.net> Subject: Re: eco noticesE Message-ID: <NiFG7.25623$S4.2316114@newsread1.prod.itd.earthlink.net>-  K I replied to ECO-Queries@compaq.com last night noting the HTML messages andrJ had a reply this morning. It seems this a a retranmission of notices whichK may not have been properly sent.  The HTML was a mistake, text messages aren2 being remailed.  I also noted the lack of subject.  L Many of these I have seen, but I did see one I should pull down and scheduleK install.  And thanks for the quick response.  Glad to know Compaq feels the + ECO mailing list is worth keeping in synch.      -- Andy Bustamanteo Remove the ASCII 95s to replyi   ------------------------------  # Date: Fri, 09 Nov 2001 00:23:03 GMTo' From: Steve Thompson <smt@twcny.rr.com>eM Subject: Re: Editing DCL command lines longer than the current terminal width H Message-ID: <Pine.LNX.4.33.0111081924020.21485-100000@vger.vgersoft.com>  ( On Mon, 5 Nov 2001, Simon Clubley wrote:  J > Are there any plans to fix the inability to fully edit DCL command lines* > longer than the current terminal width ? > J > Having just spent a good chunk of the weekend editing long command linesI > (as part of some application testing), it is my opinion [currently, NothJ > So Humble :-)] that the inability to fully edit DCL command lines longer6 > than the current terminal width is now unacceptable. >e > What do other people think ? > [...]   5 Right. Pet peeve. This was unacceptable from day one.e   steveg   ------------------------------  % Date: Fri, 09 Nov 2001 13:09:33 +1030y/ From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>oM Subject: Re: Editing DCL command lines longer than the current terminal width . Message-ID: <3BEB41E5.F769230@wasd.vsm.com.au>   Simon Clubley wrote: > J > Are there any plans to fix the inability to fully edit DCL command lines* > longer than the current terminal width ? > J > Having just spent a good chunk of the weekend editing long command linesI > (as part of some application testing), it is my opinion [currently, NotdJ > So Humble :-)] that the inability to fully edit DCL command lines longer6 > than the current terminal width is now unacceptable. >  > What do other people think ?  A Strongly agree.  It's embarressing in front of my U*x colleagues.    -- .# Non sinere illegitamus carborundum.i   ------------------------------   Date: 8 Nov 2001 18:49:59 -0800r1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)fM Subject: Re: Editing DCL command lines longer than the current terminal widtht= Message-ID: <cf15391e.0111081849.6139d740@posting.google.com>    Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> wrote in message news:<nuwF7.13058$xS6.16083@www.newsranger.com>... J > Are there any plans to fix the inability to fully edit DCL command lines* > longer than the current terminal width ?  D Hear, hear!  This has been one of those little nagging annoyances toB me for a long, long time, and I would greatly welcome a fix.  I'veC often used the workaround of switching to 132-column mode, but thaty9 only helps if the command is under 132 columns in length.f  D I'd even be happy to settle for a partial fix (for example, it mightA work with DECterms but not all brands of video terminals) -- that" would be OK.C -------------------------------------------------------------------AC Keith Parris | parris at encompasserve dot org | VMS consulting on: C Clusters, Disaster Tolerance, Internals, Performance, Storage & I/Or   ------------------------------  % Date: Fri, 09 Nov 2001 13:48:02 +1030a/ From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>lM Subject: Re: Editing DCL command lines longer than the current terminal widtha/ Message-ID: <3BEB4AEA.EB08FDA1@wasd.vsm.com.au>s   Mark Daniel wrote: >  > Simon Clubley wrote: > > L > > Are there any plans to fix the inability to fully edit DCL command lines, > > longer than the current terminal width ? > >eL > > Having just spent a good chunk of the weekend editing long command linesK > > (as part of some application testing), it is my opinion [currently, NoteL > > So Humble :-)] that the inability to fully edit DCL command lines longer8 > > than the current terminal width is now unacceptable. > >t  > > What do other people think ? > C > Strongly agree.  It's embarressing in front of my U*x colleagues.e  F As well as an inconvenient in practice (he adds as an afterthought :^)   >  > --% > Non sinere illegitamus carborundum.    --  # Non sinere illegitamus carborundum.    ------------------------------  % Date: Thu, 08 Nov 2001 22:39:55 -0600a1 From: "David J. Dachtera" <djesys.nospam@fsi.net> M Subject: Re: Editing DCL command lines longer than the current terminal width.' Message-ID: <3BEB5E1B.49778517@fsi.net>c   Mark Daniel wrote: >  > Mark Daniel wrote: > >e > > Simon Clubley wrote: > > >tN > > > Are there any plans to fix the inability to fully edit DCL command lines. > > > longer than the current terminal width ? > > > N > > > Having just spent a good chunk of the weekend editing long command linesM > > > (as part of some application testing), it is my opinion [currently, NotwN > > > So Humble :-)] that the inability to fully edit DCL command lines longer: > > > than the current terminal width is now unacceptable. > > >w" > > > What do other people think ? > >mE > > Strongly agree.  It's embarressing in front of my U*x colleagues.t > H > As well as an inconvenient in practice (he adds as an afterthought :^)  D Well, o.k. Understand what you're asking for here. In VMS terms, ...  G When a <DEL> is received and the cursor is already at column 1, somehow9+ you must accomplish *ALL* of the following:   D 1. Move the cursor to the end of the previous display line. Issue an; ASCII space (cursor should wrap to the next display line). y  1 2. Read and store the character under the cursor.l  A 3. If the terminal supports display editing, you must request the-D terminal to delete the character under the cursor and "collapse" theG line (shift everything over one byte toward the cursor position so thatgE the character that was in column two(2) is now under the cursor whichnA should remain at column one(1)). If the terminal does not support$F display editing, you must issue an "erase to end of line" sequence and; repaint that line on the screen minus the first character. e  F (What if there's more than two display lines? Starting to get the idea( that this is not as simple as it seems?)  E 4. Move the cursor to the end of the previous display line. Issue the G character that was stored at step 2. The cursor should wrap to the nextcG display line. Move the cursor to the end of the previous display line.    H ...and while doing the above, edit the command line buffer to accurately reflect this manipulation.    Starting to get the picture now?  G What if it's a *REALLY* long line and wraps to a total of three display  lines? What then?   E My advice would be to get the VMS source listings, find the code that2C needs a fix, write and test the fix, and donate the code to OpenVMS - engineering to see if they will implement it.o  @ Long shot at best, but worth a try if you think you're up to the
 challenge.  D Yes, I understand that VMS is not open source. Why let that stand in( your way? Do you want this fixed or not?   -- m David J. Dachterac dba DJE Systemsg http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/g   ------------------------------  # Date: Fri, 09 Nov 2001 00:11:35 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") Subject: Re: Emacs-2[01] on VMSq8 Message-ID: <00A04BF8.80DB18FB@SSRL04.SLAC.STANFORD.EDU>  w In article <01KAGT79CKOU90UTW5@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:uH >> It's not C that's the problem per se.  Can you say autoconfig?  BuiltG >> on C preprocessor dependancies that are little more than really uglysH >> unix hackery.  Everytime I rekindle my effort on this project, littleE >> time is lost before my blood boils.  Targets are built in the samesG >> locations as the sources and, if a build fails, it can never be pro-oG >> perly restarted (and this is 19.28).  Also, It might have been nice rH >> if the Stallman crowd had merged the VMS mods of 19.28 into the laterF >> versions but, since VMS is not a unix, it might have tainted their  >> precious unixy shit code. >oI >No surprise here.  Stallman's ideas that ANY software which is not free  F >is INHERENTLY EVIL makes it unattractive for him or his followers to  >support VMS in any form.b >eK This is logical but seems to be untrue.  Most GNU tools run on free Unixes,oI proprietary Unixes, and Windows, at least, and a number also run on MacOS0M and VMS.  While some individual maintainers are uninterested in incorporatingiM VMS modifications into there stuff - and this may well be the case for EMACS,rL which I haven't looked into - other individual and group maintainers are allL in favor of the widest possible audience for their tools.  PERL, for exampleK (which I include here because it can be used under either its own Artistic rM License or the GPL) has an active VMS developer contingent, and their patchesnJ are put into the main source promptly and efficiently.  I talked to RasmusL Lerdorf a few weeks ago about VMS support for PHP and he was very interested and supportive.i  E (Of course, we could make the logical distinction between "Stallman'stJ followers" and "member of the Free Software movement", with the diagnosticM being that if you're a dogmatic jerk who won't support any non-free OS you'ren9 one of Stallman's followers; in that case, you're right.)u     -- Alan   O ===============================================================================r0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056dM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================C   ------------------------------  $ Date: Thu, 8 Nov 2001 16:23:39 -0800# From: "Tom Linden" <tom@kednos.com>] Subject: RE: Emacs-2[01] on VMS-9 Message-ID: <CIEJLCMNHNNDLLOOGNJIAEMBDIAA.tom@kednos.com>t  E I use emacs 20.7.1 under W2K and I would have thought that that wouldF, have been a more difficult port than to VMS.   > -----Original Message------ > From: "Alan Winston - SSRL Admin Cmptg Mgr",) > [mailto:winston@SSRL.SLAC.STANFORD.EDU]u+ > Sent: Thursday, November 08, 2001 4:12 PMF > To: Info-VAX@Mvb.Saic.Comn! > Subject: Re: Emacs-2[01] on VMSt >w >e= > In article <01KAGT79CKOU90UTW5@sysdev.deutsche-boerse.com>, = > Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:nJ > >> It's not C that's the problem per se.  Can you say autoconfig?  BuiltI > >> on C preprocessor dependancies that are little more than really uglyaJ > >> unix hackery.  Everytime I rekindle my effort on this project, littleG > >> time is lost before my blood boils.  Targets are built in the samerI > >> locations as the sources and, if a build fails, it can never be pro--H > >> perly restarted (and this is 19.28).  Also, It might have been niceJ > >> if the Stallman crowd had merged the VMS mods of 19.28 into the laterG > >> versions but, since VMS is not a unix, it might have tainted theirg > >> precious unixy shit code. > >)J > >No surprise here.  Stallman's ideas that ANY software which is not freeG > >is INHERENTLY EVIL makes it unattractive for him or his followers too > >support VMS in any form.N > >0@ > This is logical but seems to be untrue.  Most GNU tools run on > free Unixes,K > proprietary Unixes, and Windows, at least, and a number also run on MacOSgA > and VMS.  While some individual maintainers are uninterested in  > incorporatingt? > VMS modifications into there stuff - and this may well be the  > case for EMACS, : > which I haven't looked into - other individual and group > maintainers are allnB > in favor of the widest possible audience for their tools.  PERL,
 > for exampleuC > (which I include here because it can be used under either its owns
 > ArtisticA > License or the GPL) has an active VMS developer contingent, ands > their patchesrL > are put into the main source promptly and efficiently.  I talked to RasmusC > Lerdorf a few weeks ago about VMS support for PHP and he was very" > interested > and supportive.C >(G > (Of course, we could make the logical distinction between "Stallman's L > followers" and "member of the Free Software movement", with the diagnostic< > being that if you're a dogmatic jerk who won't support any > non-free OS you're; > one of Stallman's followers; in that case, you're right.)N >g >p	 > -- Alane >tD > ================================================================== > ============= 2 >  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUA >  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:- > 650/926-3056C >  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CAn
 >  94309-0210.D > ================================================================== > =============  >n   ------------------------------   Date: 8 Nov 2001 18:36:23 -0800b1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)w  Subject: Re: EMC + software raid< Message-ID: <cf15391e.0111081836.5c204ad@posting.google.com>  ` "Kenneth" <yeungkenneth@yahoo.com> wrote in message news:<9se1b3$15i2@imsp212.netvigator.com>...M > I am using VMS 7.2-1 with EMC disks. Does anyone has try to form a software  > raid 0 with EMC disks?  F Yes, I know of at least one VMS cluster site that used host-based RAID@ software with EMC controllers; they found it was the only way toD provide acceptable performance for EMCs that were connected via SCSIB behind HSJ controllers so they could be accessed cluster-wide in a CI-based cluster.y  = You'd first need to purchase a license for (or get a software B loan-of-products PAK to try out) the software product "Compaq RAID% Software for OpenVMS".  The SPD is ata/ http://www.compaq.com/info/SP4649/SP4649PF.PDF.   F The DCL verb for this product is RAID.  A typical sequence of commands* to form a RAID-0 array of 3 disks follows:  6 $ RAID INITIALIZE/RAID_LEVEL=0/CHUNKSIZE=nnn arrayname DKA100:,DKA200:,DKA300:m  3 This writes metadata onto each of the member disks.C  6 $ RAID BIND arrayname DKA100:,DKA200:,DKA300: DPAnnnn:  C This creates a virtual disk with a device name of DPAnnnn:, throughlA which you  access the RAID-0 array -- it just looks like a singleo large disk under VMS.n   $ INITIALIZE DPAnnnn: labelg $ MOUNT/SYSTEM DPAnnnn: labelw  F Once the array is created, at subsequent VMS boots you only need to do the RAID BIND and the MOUNT.C ------------------------------------------------------------------- C Keith Parris | parris at encompasserve dot org | VMS consulting on:oC Clusters, Disaster Tolerance, Internals, Performance, Storage & I/O-   ------------------------------  % Date: Thu, 08 Nov 2001 23:30:22 -0500p( From: David Froble <davef@tsoft-inc.com>. Subject: Re: How to upgrade VMS/Vax 6.0 to 6.1, Message-ID: <3BEB5BDE.7020101@tsoft-inc.com>   Hoff Hoffman wrote:-  V > In article <3BEA5EE0.9836D68A@wxs.nl>, Maarten van Tilburg <mtilburg@wxs.nl> writes: > :The CO wrote: > :> :D > :> "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message2 > :> news:Fp_F7.1326$RL6.33964@news.cpqcorp.net...L > :> > In article <O8_F7.21087$hZ.1943070@newsread2.prod.itd.earthlink.net>,= > :> "Andy Bustamante" <a_c_bustamante@earthlink.net> writes:c > :> <snip> M > :> >   On a system running OpenVMS VAX V6.0, I'd follow the sequence in the B > :> >   OpenVMS FAQ to upgrade to V7.3 -- I'd upgrade to current. > :> e > :> Can I lawfully do that? > :M > :Yes, provided that  > :$ license list vax-vms /fulld > :tK > :does not state a version number (other than 0.0) or a release date limitc >  > J >   Again, I'm not a lawyer, but I know that LMF and license PAKs can and I >   will let you do things that you may not be authorized to do -- it is oK >   NOT an enforcement tool.  Generally, either a right-to-upgrade license wI >   or a software support agreement is a requirement for access to newer  D >   OpenVMS versions.  Check your software agreement(s) for details.    G I've seen license PAKs for sale on EBAY.  That piece of paper is NOT a S; license, and anyone who bought one does NOT have a license.E     Dave     -- o4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Thu, 08 Nov 2001 18:59:59 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)& Subject: Re: ignore - just a test post3 Message-ID: <PCAG7.1414$RL6.44526@news.cpqcorp.net>n  d In article <xQzG7.151949$YL3.45296152@news3.rdc1.on.home.com>, "John Smith" <a@nonymous.com> writes: :test post....ignore  C   Please use one of test newsgroups, oh anonymous newsgroup poster.i  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 8 Nov 2001 21:40:15 GMT + From: Dale Dellutri <ddellutr@enteract.com>pI Subject: Re: Is TCP/IP really needed to install WEBES and Compaq Analyze?C+ Message-ID: <9seu3v$aoq$1@bob.news.rcn.net>r  O On Thu, 8 Nov 2001 11:24:01 -0500, Peter Weaver <peter.weaver@stelco.ca> wrote:i: > "Dale Dellutri" <ddellutr@enteract.com> wrote in message' > news:9se6ts$i82$1@bob.news.rcn.net...a? >> Is TCP/IP really needed to install WEBES and Compaq Analyze?i >>D >> I've got some ES40's, and the techs always ask if I've got CompaqE >> Analyze installed when they dial in to look at a hardware problem.aF >> I've balked at installing CA (and WEBES) because of all the patches >>...uL > You'll be sorry... tell them that if they want to run that garbage to lookK > at the error log then they can install it at their site and you will mailaD > them a copy of the ERRLOG.SYS through DSN or some other means. ...  A This is what we've done previously, but it slows down the problem  resolution.n  N > That said, when we were unfortunate enough to have that garbage installed onM > one of our ES40's (we only put it on the test machine, I would not allow it." > to go on the production machine)  ; Can you give me some details on why you think it's garbage?5   -- r& Dale Dellutri -- ddellutr@enteract.com   ------------------------------  % Date: Thu, 08 Nov 2001 22:44:02 -0500t' From: Howard S Shubs <howard@shubs.net>1! Subject: Re: Lost system passwordm< Message-ID: <howard-514FB8.22440108112001@enews.newsguy.com>  3 In article <sqzG7.1412$RL6.38162@news.cpqcorp.net>,w4  hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote:  D >   Being somewhat of a delinquent :-), I have been known to invoke  >   the following: > - >     SET FILE/ENTER=SYSUAFALT.DAT SYSUAF.DATi   Ugh.  Kinda evil, Hoff.l -- l Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Thu, 08 Nov 2001 22:14:01 -0600c1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o3 Subject: Re: Name Change of Alpha Server 4000 5/300t' Message-ID: <3BEB5809.DFA42EF2@fsi.net>s  	 JH wrote:o > B > I temporarily wan to change my servers name from i.e. "ALPHA" toF > "BETA"; reason is to afterwards restore a complete image backup of aD > system disk from another server with all it's licenses etc. and we1 > don't want to relicense everything from scratchr> > Does anybody know, which steps to take in order to do this ?   Huh?  ? Well, there's the DECnet node name and address, the SCSNODE andr: SCSSYSTEMID parameters, the local hosts file, the DNS, ...   What did I forget?   -- t David J. Dachterab dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------  # Date: Thu, 08 Nov 2001 20:42:36 GMTk7 From: "Lyle W. West" <lyle.west@childrenshc.org.nospam>i& Subject: Re: ok I am back in my office6 Message-ID: <3BEA99CC.12EAF731@childrenshc.org.nospam>   Rob Young wrote: > ^ > In article <3BE9C251.EC3E36B2@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > > Sue Skonetski wrote:J > >> Take advantage of up to 15% trade-in value for your older AlphaServer
 > >> systems.  > >iP > > Shouldn't there be some VAX to alpha upgrades yet, or did Digital give up on > > those a decade ago ? >  > JF,c > B >         Does the sun ever shine north of the border?  The reasonI >         I ask is that it appears to me - regardless of time of season -cK >         you suffer from a *chronic* case of seasonal affective disorder*.s > G >         Perhaps a large dose of photons would make you a more chipper  >         person. . .  > % >                                 Rob  > 0 > *http://www.mentalhealth.com/book/p40-sad.html8 > "SAD is defined by the pattern of depressive episodes"    Rob, < 	You may be interested to know that this is the same jfmezei: 	who several years ago wrote to alt.disasters.aviation the< 	JFK Jr crash could not have been the result of a Dead Man's8 	Spin because he could not duplicate it on his M$ Flight7 	Simulator. (although, he did not suggest an All-In-Onew 	solution!)d   --    0 My opinions seldom reflect those of my employer.   Lyle W. West   ------------------------------  $ Date: Thu, 8 Nov 2001 14:37:13 -0500; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>u& Subject: Re: ok I am back in my office$ Message-ID: <3beadee2$1@news.si.com>  J >Shouldn't there be some VAX to alpha upgrades yet, or did Digital give up on >those a decade ago ?t  I Sheesh, JF!  Why not try looking at that page once?  Right there it says:w  F Upgrade a VAX system to an AlphaServer system and double your trade-in allowance: details   --A Brian Tillman                   Internet: tillman_brian at si.comtA Smiths Aerospace                          tillman at swdev.si.comh= 3290 Patterson Ave. SE, MS      Addresses modified to preventg< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Thu, 08 Nov 2001 18:38:00 -0500i- From: JF Mezei <jfmezei.spamnot@videotron.ca>e& Subject: Re: ok I am back in my office, Message-ID: <3BEB1755.E0B0A818@videotron.ca>   "Lyle W. West" wrote:tE >         You may be interested to know that this is the same jfmezeitC >         who several years ago wrote to alt.disasters.aviation theeE >         JFK Jr crash could not have been the result of a Dead Man's A >         Spin because he could not duplicate it on his M$ Flighte@ >         Simulator. (although, he did not suggest an All-In-One >         solution!)    J I would be very much interested in you providing a URL to such a post thatF puts all of the headers for such a post. Since I do not have MS flightM simulator, I doubt I would have ever said that. The only sim I have is Flighti on VMS.n   ------------------------------  % Date: Thu, 08 Nov 2001 22:00:08 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>'& Subject: Re: ok I am back in my office' Message-ID: <3BEB54C8.B5188352@fsi.net>t   Hi, Sue!   Good to hear from you!   Sue Skonetski wrote: >  >  just got this,  >  > suet > . > AlphaServer Upgrade/Trade-In Promotion site: > ' > http://www.compaq.com/hps/promotions/m > M > The attached site contains AlphaServer MOA promotions, trade-in information G > and both leasing programs. It also offers an on-line survey form thatr/ > pre-qualifies people for telesales follow-up.  > $ >  A bounty of Alpha upgrade offers! >  >  Don't lose out. > K > The time has never been better to take advantage of Compaq's unparalleled-K > upgrade and trade-in offers. Overcome your year-end budget constraints byuB > getting the solution you need now and paying nothing until 2002. > H > Conserve your valuable resources while you defer payment for 4 months. >  > Benefit from a 0% lease. > G > Take advantage of up to 15% trade-in value for your older AlphaServerh
 > systems. >  > and more.l > & > Act quickly though! Time is limited.  ? Preaching to the choir again. To expedite corporate acquisitiontC procedures (some can go one to three years or more from planning toiH acquisition), you'll need to target the chief executives decision makers4 and bean counters, not the braves on the front line.  A > For more detail, log onto http://www.compaq.com/hps/promotions/e   -- a David J. Dachterar dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Thu, 8 Nov 2001 16:53:06 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>N Subject: Reliable Transaction Router (RTR) for Linux Intel and Alpha beta kits3 Message-ID: <_7DG7.1418$RL6.46199@news.cpqcorp.net>'   Dear Newsgroup,e  H I tried this from Internet exploder and was able to access but am having some problems from Netscape.   suee   Dear Valued Customer,h  G I am please to announce the availability of Reliable Transaction RouterG (RTR) for Linux Intel ando  K Alpha beta kits. If you are interested in trying RTR for Linux, please fillf out the short form and  - download the binaries at www.compaq.com/rtr .    Thank you for your interest.  
 Sincerely,   Rick McLaughline   Rick.McLaughlin@compaq.com   Business Development   Compaq Computer Corporationo   ------------------------------  # Date: Thu, 08 Nov 2001 20:10:01 GMTaG From: Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP>'J Subject: Rob's British Champion, was: Re: Compaq: VMS is alive and kicking6 Message-ID: <tEBG7.17968$xS6.28911@www.newsranger.com>  ( On 7 Nov 2001 14:13:42 -0600, in article9 <T2FM9+edvTNK@eisner.encompasserve.org>, Rob Young wrote:L >o: >	Ah.... excellent tactic not unlike our British Champion. >   G Rob, I would like to point out that at the last count, there were about=D 60 million of us, and that we are not all clones of Andrew Harrison.  H Have you considered using "Sun Champion" instead of "British Champion" ?   Simon.  7 PS: Andrew seems to have been silent for a long time...E   -- N@ Simon Clubley, simon_clubley@remove_me.altavista.co.uk-Earth.UFPK In the task of removing Microsoft from the marketplace, I have discovered ahE truly remarkable plan, but this signature is too small to contain it.L   ------------------------------   Date: 8 Nov 2001 15:06:39 -0600t- From: Kilgallen@SpamCop.net (Larry Kilgallen)nN Subject: Re: Rob's British Champion, was: Re: Compaq: VMS is alive and kicking3 Message-ID: <YAJW25kAfO9j@eisner.encompasserve.org>h   In article <tEBG7.17968$xS6.28911@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:* > On 7 Nov 2001 14:13:42 -0600, in article; > <T2FM9+edvTNK@eisner.encompasserve.org>, Rob Young wrote:t >>; >>	Ah.... excellent tactic not unlike our British Champion.s >> > I > Rob, I would like to point out that at the last count, there were aboutrF > 60 million of us, and that we are not all clones of Andrew Harrison. > J > Have you considered using "Sun Champion" instead of "British Champion" ?  M I think there are many who work at Sun who are not clones of Andrew Harrison.o   ------------------------------  % Date: Thu, 08 Nov 2001 18:22:31 -0500)- From: JF Mezei <jfmezei.spamnot@videotron.ca>NN Subject: Re: Rob's British Champion, was: Re: Compaq: VMS is alive and kicking, Message-ID: <3BEB13B6.FE77FD2C@videotron.ca>   Simon Clubley wrote:9 > PS: Andrew seems to have been silent for a long time...r  M Compaq is no longer a threat to Sun sales. With Compaq shooting itself in the M foot in a very visible way, Sun no longer needs to bother ponting to Compaq'sn silly decisions.   ------------------------------  # Date: Thu, 08 Nov 2001 20:17:52 GMTE4 From: "Matt Muggeridge" <Matt.Muggeridge@compaq.com>, Subject: Re: Transparent RMS access to TCPIPA Message-ID: <QLBG7.314573$bY5.1260638@news-server.bigpond.net.au>x  E Will you be sending this request along to OpenVMS product management?w  = > Another feature that would be nice would be support for FTP  > eg:e
 > FTP"clintoni? cigar"::ftp.whitehouse.gov/oval_office/documents/missing_w.keyslL > would automatically open an FTP session that would either get (if open forE > read) the file, or write records to a file there if open for write.c  K Not sure if this is what you're looking for, but the CLI for FTP is similarr toDECnet.  Eg.  (     $ copy/ftp ftp.whitehous.gov"clinton1 cigar"::"/oval_offic/documents/missing_w.keys" []a  L > Heck, why not also support HTTP requests and feed the response data to the* > application as if it were a local file ?  @ Great idea!  Better send that to OpenVMS product management too.   Matt.   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3BEA5B7A.B40F66C4@videotron.ca... > Just a suggestion: >-H > Currently, one can use transparent DECnet for a program to access dataJ > residing on another decnet node, with that data being a file or a stream ofF > data supplied by some server program. To the application this is all transparent. >2J > so, a program can open a file such as BIKE"clinton cigar"::"0=TWIST" and thenK > read records as they are being fed by the TWIST.COM residing in Clinton's 
 directory. >gC > It would be *really neat* if RMS were modified to support sumilart
 operations > with TCPIP connections.  >  > for instance:eL > TCPIP::server.whitehouse.gov:23  would establish a tcpip connection to the< > named host and port number and one could read/write to it. > F > The nice advantage of using RMS is that RMS would have the smarts to assembleL > records on your behalf (eg: take raw packets and assemble until a new line > character is received).a >IL > Right now, everyone needs to re-invent the wheel, writing his own routines toL > buffer incoming packets and feed newline terminated records to the calling< > application. And that sounds like the perfect job for RMS. >/= > Another feature that would be nice would be support for FTPi > eg:u
 > FTP"clintons? cigar"::ftp.whitehouse.gov/oval_office/documents/missing_w.keys/L > would automatically open an FTP session that would either get (if open forE > read) the file, or write records to a file there if open for write.0 >KL > Heck, why not also support HTTP requests and feed the response data to the* > application as if it were a local file ?   ------------------------------  % Date: Thu, 08 Nov 2001 18:36:09 -0500A- From: JF Mezei <jfmezei.spamnot@videotron.ca>a, Subject: Re: Transparent RMS access to TCPIP, Message-ID: <3BEB16E6.E2D9EF63@videotron.ca>   Matt Muggeridge wrote: > G > Will you be sending this request along to OpenVMS product management?p  F From what i was told, they only raise issues that have arrived throughL official channels. And I don't have access to official channels, and I doubtJ that a 1980s paper SPR would make it way to the right people. I have a few left in some binders.R  J If the idea has merit, then perhaps a valued customer can bring this up to9 Compaq since they would have access to official channels.D  L And if Compaq staff do not have the ability to see some good suggestions andD raise them themselves in their committees, then it is Compaq's loss.   ------------------------------  # Date: Thu, 08 Nov 2001 21:12:07 GMTl) From: rob.buxton@wcc.govt.nz (Rob Buxton)d% Subject: VMS Landing Versions for VAX"1 Message-ID: <3beaf37a.246421605@news.wcc.govt.nz>p   Hi All,   C I see that OpenVMS 7.2-2 is considered to be the "Landing Zone" for 0 those planning on sticking to 7.2 for a while.   Okay fine for Alpha.B Will 7.2 on VAX be supported under the traditional support in line+ with 7.2-2 on Alpha, i.e. to December 2002?oD I can't find the VMS Support committments for OpenVMS on VAX on  the) Compaq Web Site, only the Alpha Variants.o   TIAL   Rob.   ------------------------------  # Date: Thu, 08 Nov 2001 22:00:46 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)) Subject: Re: VMS Landing Versions for VAXn3 Message-ID: <igDG7.1419$RL6.46281@news.cpqcorp.net>e  ] In article <3beaf37a.246421605@news.wcc.govt.nz>, rob.buxton@wcc.govt.nz (Rob Buxton) writes:   D :I see that OpenVMS 7.2-2 is considered to be the "Landing Zone" for1 :those planning on sticking to 7.2 for a while.  a ..C :Will 7.2 on VAX be supported under the traditional support in linel, :with 7.2-2 on Alpha, i.e. to December 2002?E :I can't find the VMS Support committments for OpenVMS on VAX on  thef* :Compaq Web Site, only the Alpha Variants.  A   The URL you seek is included in the OpenVMS FAQ.  Specifically:   ?     http://www.compaq.com/services/software/ss_pvs_se_amap.html   F   This is the Compaq Americas and Asia Pacific Software Services site.  G   For other Compaq Software Services support information, please visit:@  ,     http://www.compaq.com/services/software/  F   I'll add the term "Landing Zone" to the Prior Version Support (PVS) E   text description to be included in next edition of the FAQ, to try cG   to make this text easier to find.  I'll also add the Compaq Software e<   Services URL (cited above) to the same section of the FAQ.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 08 Nov 2001 23:34:36 GMT ) From: rob.buxton@wcc.govt.nz (Rob Buxton)r) Subject: Re: VMS Landing Versions for VAXi1 Message-ID: <3beb15a8.255171096@news.wcc.govt.nz>9   Hoff,$  # Thanks.  Gives me the info I need. aF Should have thought to look at the start date of Prior version support< rather than trying to find the end date of standard support!  E On Thu, 08 Nov 2001 22:00:46 GMT, hoffman@xdelta.zko.dec.nospam (Hoffk Hoffman) wrote:C  ^ >In article <3beaf37a.246421605@news.wcc.govt.nz>, rob.buxton@wcc.govt.nz (Rob Buxton) writes: > E >:I see that OpenVMS 7.2-2 is considered to be the "Landing Zone" fort2 >:those planning on sticking to 7.2 for a while.   >..OD >:Will 7.2 on VAX be supported under the traditional support in line- >:with 7.2-2 on Alpha, i.e. to December 2002?oF >:I can't find the VMS Support committments for OpenVMS on VAX on  the+ >:Compaq Web Site, only the Alpha Variants.n >pB >  The URL you seek is included in the OpenVMS FAQ.  Specifically: >t@ >    http://www.compaq.com/services/software/ss_pvs_se_amap.html >rG >  This is the Compaq Americas and Asia Pacific Software Services site.- >-H >  For other Compaq Software Services support information, please visit: >o- >    http://www.compaq.com/services/software/w >mG >  I'll add the term "Landing Zone" to the Prior Version Support (PVS) cF >  text description to be included in next edition of the FAQ, to try H >  to make this text easier to find.  I'll also add the Compaq Software = >  Services URL (cited above) to the same section of the FAQ.E >  RO > ---------------------------- #include <rtfaq.h> -----------------------------nO >      For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    -O > --------------------------- pure personal opinion ---------------------------eM >   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com0 >    ------------------------------  % Date: Thu, 08 Nov 2001 17:51:54 -0800 8 From: Joe <schneider.NoSpam@zippy.labmed.washington.edu>4 Subject: VMS upgrade and SCSI disk firmware questionJ Message-ID: <schneider.NoSpam-E2D3A3.17515408112001@news.u.washington.edu>  Keywords: OpenVMS, SCSI firmware  H OK, cleaning up an inherited DEC 3000 running VMS 7.2-1, I noticed that I there were several RZ26L disks on the system.  The release notes for VMS CG 7.1, 7.2 and 7.3 all seem to indicate that there is a minimum firmware  E version recommended for these drives (0568 or 442D).  Which is newer?/  I I've got some with 440C, 442D, and some RZ28M's with 0568, 0616 and 4001.y  5 Do higher version numbers imply more recent releases?e  I The release notes explain how to get from 440C to 442D on the RZ26L, but .I I don't see mention of updating the RZ28M's ... is this possible, is the .& firmware (image?) available somewhere?  B Are there limitations on other digital/compaq SCSI disks' minimum 0 firmware versions for different versions of VMS?  8 Any help or additional information would be appreciated. -- u< joe schneider,   university of washington,  seattle, wa, usa4 (To reply, please remove ".NoSpam" from my addresss)   ------------------------------   Date: 8 Nov 2001 15:01 PST+ From: rankin@eql14.caltech.edu (Pat Rankin)r Subject: Re: welcome.txt0 Message-ID: <8NOV200115010146@eql14.caltech.edu>  ? In article <QewG7.42800$zK1.10987738@typhoon.tampabay.rr.com>,\s+  "john nixon" <jnixon@cfl.rr.com> writes...hK > I need to put a long message in welcome.txt and I need it to pause in the H > middle (darn security people) to give the user time to read it. (press$ > return to continue sort of thing). >eL > Since this is just a text file and not a command procedure (even though it- > get invoked with an @),   how do I do this?v >l > Openvms VAX 7.1  > Openvms Alpha 7.2-1t  >      To do this properly, you would need to define sys$welcomeA to point at a mailbox device (MBAx:) instead of an ordinary file,r> and have a detached job running a program which waits for some? process to read from that mailbox.  The program would then sendW> whatever you wanted and do any extra interaction.  But getting< this sort of thing to work correctly when multiple users are= capable of logging in at the same time is nontrivial.  (You'dg< probably need to read and write directly to the terminal and? then send end-of-file to the mailbox rather than trying to sendd= the welcome text through the mailbox, and you'd need to avoid > blocking other processes that attempt to read the same mailbox< while waiting for a user to acknowlege the first part of the; text.  Trying to think about how to make this work robustlyo; is starting to give me a headache....  Skipping the welcomev> mechanism and directly using DCL in sylogin.com is going to be= much easier, although it has several potential problems too.)i  2                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  # Date: Thu, 08 Nov 2001 20:08:58 GMT:4 From: "Matt Muggeridge" <Matt.Muggeridge@compaq.com>1 Subject: Re: What comes after TCPIP$FTP_SHUTDOWN?sA Message-ID: <uDBG7.314527$bY5.1260145@news-server.bigpond.net.au>    Hi Gabriel,a  E Oswald has answered your question for V5.0A, (as you requested), justeF thought I'd chime in with an FYI... for a future date if you have V5.1
 installed....v  C In V5.1, each component has its own startup and shutdown procedure. D TCPIP$CONFIG menu has been enhanced to support startup/shutdown on a per-component basis too.  D The syntax being:  @sys$startup:tcpip$<component>_<startup|shutdown>  + So in V5.1, the procedure for FTP would be:   %     $ @sys$startup:tcpip$ftp_shutdowna     $! do some worko$     $ @sys$startup:tcpip$ftp_startup  L Or if you were working with the "ftp_client", then you would use that as the2 component string in the startup/shutdown commands.  A Alternately, the TCPIP$CONFIG menu options make it very easy too.m   Matt.   2 "Gabriel Sterk" <gabi@aipm.co.il> wrote in message, news:001901c16863$63b8f000$2c46bf10@manai... > Hello all, >o; > Is there a way to start up the FTP process after shuttingo3 > it down with SYS$STARTUP:TCPIP$FTP_SHUTDOWN.COM ?s: > Seems to me, that the only way is to run the whole bunch > of TCPIP$STARTUP.COM . > Thanks for any hint, >m > Gabriel Sterk  >oC > P.s. Disable & enable of the service is not what I'm looking for.-   ------------------------------  % Date: Thu, 08 Nov 2001 21:55:37 -0500 ! From: Beyonder <beyonder@vrx.net>  Subject: where is 7.3?8 Message-ID: <gchmutk958o3k83bi1jkvk5i9ve8grlmdo@4ax.com>  D I haven't seen any word of it, montagar certainly isn't dealing with it yet.i   B.    @ -----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----A http://www.newsfeeds.com - The #1 Newsgroup Service in the World!e@  Check out our new Unlimited Server. No Download or Time Limits!@ -----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----   ------------------------------  % Date: Thu, 08 Nov 2001 22:09:16 -0600t1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e# Subject: Re: Which Disks are Which?'' Message-ID: <3BEB56EC.3BE527FD@fsi.net>c   Blast wrote: >  > "Dijk, Jeroen van" <Jeroen.vanDijk@Getronics.com> wrote in message news:<2795B75EF003D311801A00A0C906B511011C6981@cucexec.gbc.getronics.nl>...H > > If you use a HSx controller you can give the disk any name you want. > >P3 > > Here you have an example with a HSD controller.- > >- > > S> show dev dua65 /fullN > >0S > > Disk $1$DUA65: (HSD000), device type MSCP served SCSI disk, is online, mounted,lQ > >     file-oriented device, shareable, served to cluster via MSCP Server, error1 > >     logging is enabled.t > > S > >     Error count                    0    Operations completed            2565166 S > >     Owner process                 ""    Owner UIC                      [SYSTEM] S > >     Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,WnS > >     Reference count              126    Default buffer size                 512uS > >     Total blocks             8378028    Sectors per track                   113oS > >     Total cylinders             3708    Tracks per cylinder                  20uS > >     Host name               "HSD000"    Host type, avail              HSD5, yes S > >     Alternate host name         "FE"    Alt. type, avail     VAX 4000-705A, yesa( > >     Allocation class               1 > >iS > >     Volume label         "CUCVMSV71"    Relative volume number                02S > >     Cluster size                   9    Transaction count                   269iS > >     Free blocks              3685698    Maximum files allowed            418901oS > >     Extend quantity                5    Mount count                           2eS > >     Mount status              System    Cache name         "_$1$DUA65:XQPCACHE" S > >     Extent cache size             64    Maximum blocks in extent cache   368569 S > >     File ID cache size            64    Blocks currently in extent cache 271557mS > >     Quota cache size               0    Maximum buffers in FCP cache       2164mS > >     Volume owner UIC           [1,1]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCDt > >aR > >   Volume Status:  subject to mount verification, protected subsystems enabled,A > >       file high-water marking, write-through caching enabled.R# > >   Volume is also mounted on FE.q > >  > >iF > > Here you have an example of show dev d /full with a HSZ controller > >t > > RN> show dev dkc101 /full. > >aT > > Disk $1$DKC101: (RN), device type DEC HSZ50-AX, is online, file-oriented device,B > >     shareable, available to cluster, error logging is enabled. > >aS > >     Error count                    0    Operations completed             330567 S > >     Owner process                 ""    Owner UIC                      [SYSTEM]rS > >     Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W S > >     Reference count                0    Default buffer size                 512 S > >     Total blocks            41890140    Sectors per track                   113-S > >     Total cylinders            18536    Tracks per cylinder                  20.( > >     Allocation class               1 > >iU > > Without a HSx controller you have following result and now its easy to see in VMSvj > > all the info you need. Normally a raid controller changes the values of the SCSI port, target and LUN. > >l > >  > > TH> show dev dkb /full > >qS > > Disk $1$DKB0: (TH), device type DEC RZ1CB-CA, is online, mounted, file-orientedoJ > >     device, shareable, available to cluster, error logging is enabled. > >hS > >     Error count                    0    Operations completed             467660uS > >     Owner process                 ""    Owner UIC                      [SYSTEM]sS > >     Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W S > >     Reference count              223    Default buffer size                 512eS > >     Total blocks             8380080    Sectors per track                   113 S > >     Total cylinders             3708    Tracks per cylinder                  20h( > >     Allocation class               1 > >nS > >     Volume label         "CUCVMSV72"    Relative volume number                0iS > >     Cluster size                   9    Transaction count                   367fS > >     Free blocks              5017779    Maximum files allowed            419004eS > >     Extend quantity                5    Mount count                           1 S > >     Mount status              System    Cache name          "_$1$DKB0:XQPCACHE".S > >     Extent cache size             64    Maximum blocks in extent cache   501777tS > >     File ID cache size            64    Blocks currently in extent cache  12699sS > >     Quota cache size               0    Maximum buffers in FCP cache       2680fS > >     Volume owner UIC        [SYSTEM]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD. > > P > >   Volume Status:  ODS-2, subject to mount verification, protected subsystemsJ > >       enabled, file high-water marking, write-through caching enabled. > >eM > > Disk $1$DKB100: (TH), device type RZ29B, is online, file-oriented device,tB > >     shareable, available to cluster, error logging is enabled. > >sS > >     Error count                    0    Operations completed                 25pS > >     Owner process                 ""    Owner UIC                      [SYSTEM]tS > >     Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,WcS > >     Reference count                0    Default buffer size                 512yS > >     Total blocks             8380080    Sectors per track                   113kS > >     Total cylinders             3708    Tracks per cylinder                  20s( > >     Allocation class               1 > >e > > o > > Normally if you have DKC123 it tells you that is a disk (D) based on SCSI (K) that is the third adapter (C)mh > > this on SCSI port 1 (1), target 2 (2) and lun 3 (3). But with a raidcontroller it's free changeable. > > U > > I hope I have explained it clearly enough and show with examples the differences.p > >H > >e > >s  > > > -----Original Message-----B > > > From: vmendham@altavista.com [mailto:vmendham@altavista.com]) > > > Sent: dinsdag 6 november 2001 16:370 > > > To: Info-VAX@Mvb.Saic.Com.) > > > Subject: Re: Which Disks are Which?a > > >S > > > 0 > > > mark.barry@ps.net (Blast) wrote in message > > >  > > > Mark,g > > >:? > > > I guess you have used sho dev DUA##/full or DKA##/full or  > > > $1$DUA###/full etc. L > > > This should show u the kind of disk and then you could try to match onH > > > the controller. If it is dka0: that should be scsi device 0? or if  > > > DKA100: could be SCSI 1??. > > >e( > > > Nodename> sho dev sys4b$dka0:/full > > >tK > > > Disk SYS4B$DKA0:, device type RZ57, is online, mounted, file-orientedq
 > > > device,l. > > >     shareable, error logging is enabled. > > >t > > >nK > > > Device                  Device           Error    Volume         Freen > > > Trans Mnt,L > > >  Name                   Status           Count     Label        Blocks > > > Count Cnt L > > > $1$DKA0:        (SYSA)  Online               0  (remote shadow member)D > > > $1$DKA200:      (SYSA)  Mounted              0  (remote mount) > > >         1tL > > > $1$DKA300:      (SYSA)  Online               0  (remote shadow member)L > > > $2$DKA0:        (SYSB)  Online               0  (remote shadow member)L > > > $2$DKA200:      (SYSB)  Mounted              0  VAXVMS62             0 > > >   250   1'L > > > $2$DKA300:      (SYSB)  Online               0  (remote shadow member)4 > > > $2$DKA700:      (SYSB)  Online wrtlck        0 > > >-% > > > SYSTEMB-> sho DEV $1$dKA0:/FULL0 > > >0= > > > Disk $1$DKA0: (SYSA), device type DEC RZ26N, is online,u > > >RK > > > Also check the sys$startup:startup_vms.com files to see if there is aoC > > > mount command, which could tell you which disks are doing thet" > > > shodowing or mirroring etc.. > > >s< > > > $MOUNT/SYSTEM DSA1: /SHADOW=($1$DKA300,$2$DKA300) USER9 > > > $MOUNT/SYSTEM DSA2: /SHADOW=($1$DKA0,$2$DKA0) USER2  > > >.H > > > Does the HSC show any info on the mounted devices? Show disk, show > > > tape etc...e > > >2 >  > All, > B > Thanks for all your input. I've managed to get the information IB > wanted using SWCC 2.1, most useful. However, I do have a problemD > configuring SWCC to see the bottom 1/2 of one cabinet. I have beenG > able to configure it to see all the disks on dkc (this serves all the F > disks in l/hand cab). Also able to configure it to see all the disksF > in top 1/2 of right hand cabinet, from dkb. However, if I try to runE > the config on either node in the cluster to add in all the disks onsD > the dke bus (all disks in bottom of r/hand cabinet) SWCC says that4 > "this device is not a member of this cluster"...?? >  > Any clues anyone?mB > Thanks for reading, and thanks in advance for any more pointers.  E In my experience, SWCC is not recommended. System instability is very-' likely and data loss is not unheard of.   = Again, in my experience - your mileage may vary considerably.-   -- - David J. Dachterae dba DJE Systems- http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/m   ------------------------------  % Date: Thu, 08 Nov 2001 21:55:56 -0500 0 From: Glenn and Mary Everhart <everhart@gce.com>Y Subject: [Fwd: FW: INFORMATION ANARCHY = As good as it gets? Software CAN be bui	ltsecure ' Message-ID: <3BEB45BC.EB6FC11C@gce.com>e   Folks -dG I recently sent this to another group, but it did not get thru far as ItA could see. However  I thought perhaps in this forum someone mightN& have minor interest in the thoughts...  C I have thought that the care taken in VMS Engineering is a strength@ not well appreciated outside.   F This took place in context of discussions about whether security holes should be discussed openly.o    
 -------------gC The repeated claims that it is impossible to build secure software,t< so we need to just accept whatever is handed out, bother me.  C It is possible to both build software cleanly, and to clean up code B written for an earlier time where network issues and security were less important.U  K However what it takes is a focus, by the entire group doing the engineering.H of the programs, on ensuring that the software runs correctly, both from0 a security point of view and from a results one.  L This has been done at a place I worked once. System changes got handled withE a process that did and does a pretty good job of flushing out issues.h  K When a system change is contemplated, somebody does an investigation of its F implications. This produces a report and leads to a meeting of as many affectedI groups as can be discerned. (Anybody can come if he thinks his work mightoK be affected.) During this meeting the investigator must explain the problem F and proposed solutions. These are examined in detail for functional orL security issues, as well as for elegance, maintainability, and extendability of the design.   K There may be additional meetings so that this stage is not exited until then1 investigation looks to have reached a conclusion.-  O Then there is a design and functional specification activity, which can includedL building demo level code and often results in procedures and data structures beinguL laid out. This is followed by another meeting, generally with more attendees thanJ the investigation report, during which the design and functional detail is	 examined..P Here again security issues get brought out. (You want to change the way you skipO files on a tape? What security implications are there? Might mess up some thirdm party M applications? How do you fix that? OK, privileged site option, how's that fitg! with other tape control options?)Z  O Then there is the actual coding and the tests and code reviews after. The folkse doing O this are experienced in looking for border conditions, edge effects and oddballo cases > and will treat data corruption or insecurity as show stoppers.  I The result of this process is that designs that come out generally have at certain K elegance, and that security mistakes are few. The process means that almost 
 everythingM has many minds looking it over (the exceptions tending to be hardware controlw
 code whereJ one person has really mastered a piece of hardware and others know it only glancingly.)  L You can buy the operating system produced there: it's called VMS. Some users recentlyN put a VMS box up at DEFCON and won "cool and unhackable" awards there with it; thisN was a generic alpha based workstation with some apps on it and to which anyone couldrK get an account. That it survived attacks is I believe not coincidental. The  culturei# that produces it keeps it that way.e  G Things were not always thus. VMS used to be full of holes and had to bei massively tweakedhJ to gain even a semblance of secure operation. (It wasn't until V6 that the
 defaults were)P changed so it installs secure out of the box.) It also got broken into massively duringC the 80s and this led to rewrites of many subsystems after redesign.   O Unix had similar issues, since up to the mid 80s or so it was not hardened, andg was usedP by on the whole a mature community who wanted to get work done with it (or play) and O did not view random destruction as amusing but as idiotic. Since that time manyo	 functionsyN have been redone and numerous misfeatures have been fixed. This is still going on, but H the point is that bad code can be redesigned correctly and the number of security holes can be minimized.n  P Microsoft might ask the question: if the number of security bugs discovered were one every coupleO months, would it be so very hard to get updates that fixed them out?  (So mighte others.)J At such a rate, mind, the fixes devised could be tested so they would work	 reliably.   M As it is, I find the complaints about full disclosure from a vendor which hasLK produced the security flaws in the first place to have too much conflict ofl interest to.P be taken as disinterested wisdom. Let them come with clean hands to the court of public' opinion. They appear to be scrubbing...   ; Meanwhile I find documents like RFPolicy pretty persuasive.R  W     -----Original Message-----8 From: Raymond Pritchett [mailto:darksided@DARKSIDED.COM]* Sent: Saturday, November 03, 2001 12:07 AM$ To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM2 Subject: INFORMATION ANARCHY = As good as it gets?    H Full-Disclosure is the best CURRENT method for securing systems, howeverF in utopia Full-Disclosure would not be necessary for securing systems.   I know this is not utopia.  D The security community has for a long time assisted peons in IT likeF myself providing an information backbone to securely manage enterpriseG systems, and in essence making things better has been the ultimate goaldD of those who are involved in Full-Disclosure. Scott Culp gave me the@ impression he completely dismissed the contribution the securityH community currently makes through Full-Disclosure, which is where my red flags were raised.  D I do not disagree with a lot of the points made by Scott Culp in hisC article; however I do disagree with his premise that companies like E Microsoft can provide a better solution if we just trust them to, and > that the lack of Full-Disclosure is a better alternative to noG disclosure at all. He offered a pretty blatant opinion, and many others.A have followed his lead by offering opinions of their own, however&C neither Scott Culp nor any of the other opinions raised offered any-, viable alternatives that address the issues.  E If Microsoft's objective is to work with industry leaders to build an H "industry wide consensus on this issue," then that is where the "Call toH Arms" must take place for the security community if security is to truly remain the ultimate goal.e  C This campaign from Microsoft is purely a publicity campaign at this#E point, and from Scott Culp's article it seems pretty clear to me that.C the Full-Disclosure community should get ready, the publicity anglefE appears to be that You are public enemy #1. If Microsoft or any other,H large company puts out the cash to create a public opinion frenzy on theH subject, making Full-Disclosure the bane of data security in the current9 terrorist threat environment, the consequences are scary.o  C It would be nice if all parties could discuss a real alternative toAG Full-Disclosure, of coarse that means the industry would have to changerD the way they think about security, and the Full-Disclosure communityC would have redefine their purpose. The government ideas were tossedl> around as a 3rd party broker, but as a Senior Consultant for aE government agency let me just ask which government do you trust to do,= it? This list alone is represented from citizens of dozens ofeD governments, and all equally have agenda's just like any corporation@ would. Which 3rd party is above influence from the entire global	 industry?w  D Industry leaders can create think tanks to determine the best way toF secure systems without Full-Disclosure, but one of the first questionsB any think tank should ask is "With all the Agenda's of the various0 parties, is Full-Disclosure as good as it gets?"  G The fact is, I make a fortune thanks to companies like Microsoft, their8B security vulnerabilities, and the fact Full-Disclosure may lead toC possible exploitation hacks in the future. Even though every single D server system I have been responsible for has never fallen prey to a= vulnerability in the past (thanks to vigilance and researched G information provided by methods such as Full-Disclosure), with an issue 8 like this even my peon IT guy agenda should be measured.     Raymond Pritchett  Network/Systems Consultant  H "Never argue with an idiot. They drag you down to their level, then beat you with experience."   :                                  -Dilbert's Rules of Order     -----Original Message-----$ From: Windows NTBugtraq Mailing List; [mailto:NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM] On Behalf Of Russl' Sent: Friday, November 02, 2001 4:42 PMi$ To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM+ Subject: Call to arms - INFORMATION ANARCHY   E The following message was received from the poster. I'm sending it on6 that person's behalf.  A > Please read the attached text file and help support this cause.a > 7 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-t >s5 > "I don't intend to offend, I offend with my intent"w >e > hellNbak@nmrc.orgl > http://www.nmrc.org/~hellnbakd  2 A Step Towards Information Anarchy: A Call To Arms by hellNbak <hellNbak@nmrc.org>o  G Recently, Scott Culp of Microsoft's Security Response Team released the  following paper:  H http://www.microsoft.com/technet/treeview/default.asp?url=/technet/colum ns/s ecurity/noarch.asp.b  C Since the suspiciously timed release of this paper, rumors are thatlG Microsoft has been contacting the management of various research groupse toH discuss with them their disclosure policies and how to fall into the newH Microsoft line of thinking.  Unfortunately, I have not been privy to any ofC these discussions with Microsoft, but one can only guess that theirlG intentions are not pure.  I am not going to write another rant on why I C think Microsoft is out to lunch and how I know for a fact that they  would2G like to force legitimate security research into the grave and return tot therF days of not spending money on security, but I am going to write a rant onE what I think the research community needs to do to help Microsoft andr allrH vendors see the light.  Make no mistake about it - Full Disclosure is inH clear and present danger of being stomped out by vendors like Microsoft.  A Back in the day, groups like ADM, Rhino9, L0pht, and w00w00 woulde8 responsibly release advisories with complete details and proof-of-conceptH code.  Security was improving, vendors continued to get the message thatE their software had better be secure, and that they would be forced to0 dealH with serious security issues.  Or did they?  Unfortunately, it seems theG only message that the software vendors learned was that security issues  are E expensive, and while money should be spent convincing the public that  thedG vendors care about security issues, the full disclosure community needs  to? be crushed so that things can go back to business as usual.  To"	 Microsoft E and vendors like them, security is not a technical or a developmental  issue;C it is merely a marketing issue that can be - and is - leveraged for  press  time.1  H Unfortunately, today, Rhino9 is no longer and ADM has been quite quiet -A keeping things to themselves no doubt.  L0pht is now a consulting F organization and w00w00 has also been very, very quiet.  To add to theC problems, we have groups and people like Georgi Guninski, who whilexC releasing some very interesting research and proof-of-concept code,c refuseG to do it in a responsible manner, giving the vendors all the ammunition  they- need to attack the full disclosure community.u  G So how do we fix what seems to be broken beyond repair?  How do we take  the B power away from the software vendors and return it to the researchA community?  My answer is: INFORMATION ANARCHY.  Microsoft likenedgD researchers - not criminal hackers or script kiddies - to terrorists holdingeA software companies at ransom and being irresponsible by releasingeB proof-of-concept code.  Microsoft claims that we are in a state ofF "Information Anarchy" and that the research community must be stopped. Do we D really want to return to the olden days when vendors knew they could ignoreF security issues?  I say no; it has to stop and the only way to stop it is tocF demonstrate to Microsoft and the world what _true_ Information Anarchy is. @ I propose that everyone who is involved in security research and supportsH full disclosure steps up research efforts and releases those issues thatH they have been sitting on.  Let's flood the security department of everyF vendor with new issues.  Let's show the world what they would miss and whatF information could just as easily have stayed in the underground rather than" be posted to Bugtraq or Vulnwatch.  F Before you go out and start releasing all your zero-days, I do caution thisH with the recommendation that we all put in the effort to coordinate withF vendors before releasing the advisories.  I do not mean you should sit onH something for 90 days until the vendor decides to fix it, but I do thinkE that the vendor should be notified and given a set amount of time (30  daysH to fix and 5 to respond, perhaps) to respond properly.  While we need to be; direct with our actions, we do need to exercise caution and  responsibility.l  E Show your support for this movement; help us take the power back fromt thecC vendors.  I am offering my free time to help anyone with a security  issue to@ report it to the vendor and craft an advisory.  I am also asking everyoneA in the research community who supports full disclosure to release,
 advisories9 in support of what I am calling Information Anarchy 2K01.g  B We have had the lame, media-created defacement wars between script	 kiddies -EG now it is time to wage a true war that will demonstrate our skills, and  moreB importantly, demonstrate to the vendors, the corporations, and the world,+ what they are forcing into the underground.m  G I am not asking anyone to do anything illegal, I do not want to see anyrD supportive defacements or hacks but I do want to see some supportiveC advisories and research efforts.  Microsoft just spent the last few  years H fighting for their "freedom to innovate" and now they are trying to take ours.   B For information, help, or comments please email hellnbak@nmrc.org.  H ======================================================================== ====* Delivery co-sponsored by Trend Micro, Inc.H ======================================================================== ====< BEST-OF-BREED ANTIVIRUS SOLUTION FOR MICROSOFT EXCHANGE 2000A Earn 5% rebate on licenses purchased for Trend Micro ScanMail foroC Microsoft Exchange 2000 between October 1 and November 16. ScanMailnB ensures 100% scanning of inbound and outbound traffic and providesC remote software management. For program details or to download your$ 30-day FREE evaluation copy:H http://www.antivirus.com/banners/tracking.asp?si=53&bi=245&ul=http://www ae ntivirus.com/smex2000_rebate    F **********************************************************************J This transmission may contain information that is privileged, confidentialO and/or exempt from disclosure under applicable law. If you are not the intended N recipient, you are hereby notified that any disclosure, copying, distribution,N or use of the information contained herein (including any reliance thereon) isG STRICTLY PROHIBITED. If you received this transmission in error, pleaserP immediately contact the sender and destroy the material in its entirety, whether, in electronic or hard copy format. Thank youF **********************************************************************   ------------------------------   Date: 8 Nov 2001 14:30:22 -0800W5 From: Hiroyuki_Tanaka4@excite.co.jp (Hiroyuki Tanaka)e Subject: [Help]Serial QIO Code= Message-ID: <68cfa44d.0111081430.5231772c@posting.google.com>r  
 Dear Readers,a  F I am trying to learn how to do serial I/O using QIO's.  For my test I A have an Alpha station 200 and connected a modem to TTA0:.  In the- serialB line I have a HP protocol analyser so I can see what is going on.   > When I use $set host /dte TTA0: and type At<Cr> and the modems response OKA4 is displayed. On the protocol analyser the trace is:   $set host /dte tta0:* DTE Signal <Cr> A T <Cr>                  + DCE Signal  <Cr> A T <Cr><Cr><Lf>OK<Cr><Lf>e  A I have been trying to acheive the same with some QIO code I have  C written.  However when I run the code I do not get the OK response.g@ I actually get the AT which I sent, plus my code sends AT twice.  0 DTE Signal A T <Cr>                     A T <Cr>1 DCE Signal  A T <Cr><Cr><Lf>OK<Cr><Lf>   A T <Cr>d  C I have attached the code I am using.  How call I change my code to  F work like to result to set host /dte.  I am at a loss as to the reasonE as I am trying to learn how to use QIO.  I have attached the terminal   characteristics that I am using.   Thanks for your help.          PROGRAM MODEMd       IMPLICIT NONEi       INCLUDE '($IODEF)'       INCLUDE '($SSDEF)'       INCLUDE '($DVIDEF)'n       INCLUDE '($DEVDEF)',       INCLUDE '($TTDEF)'       INCLUDE '($TT2DEF)'r       INCLUDE '($SYSSRVNAM)'         INTEGER*4 STATUS       INTEGER*4 SERIAL_RECV        INTEGER*4 SERIAL_SEND          CHARACTER *80 OUTPUT       CHARACTER *255 INPUT       CHARACTER *80 TERMINAL         INTEGER*2 CHANNEL        INTEGER*2 NBYTES       INTEGER*2 ILEN         STRUCTURE /CHARBUF/o          BYTE        CLASS          BYTE        TYPEt          INTEGER*2   BUFLENd          INTEGER*4   CHAR1          INTEGER*4   CHAR2       ENDSTRUCTURE         RECORD /CHARBUF/ ORIGCHARi       RECORD /CHARBUF/ NEWCHAR         TERMINAL = 'TTA0:'-       STATUS = SYS$ASSIGN(TERMINAL,CHANNEL,,)   )       STATUS = SYS$QIOW( , %val(CHANNEL),t0 %val(io$_sensemode),,,,ORIGCHAR, %val(12),,,,, )       NEWCHAR = ORIGCHAR;       NEWCHAR.CHAR1 = IBSET( NEWCHAR.CHAR1, tt$v_nobrdcst ) ;       NEWCHAR.CHAR2 = IBSET( NEWCHAR.CHAR2, tt2$v_pasthru )a  ?       STATUS = SYS$QIOW( , %val(CHANNEL), %val(io$_setmode),,,,o NEWCHAR, %val(12),,,,, )         OUTPUT = 'AT'//CHAR(13)n)       CALL STR$TRIM(OUTPUT, OUTPUT, ILEN)e  4       NBYTES = SERIAL_SEND(CHANNEL, OUTPUT, ILEN, 0)  =       NBYTES = SERIAL_RECV(CHANNEL, INPUT, SIZEOF(INPUT), 0) x  !       write (6,*) input(1:nbytes)g
       STOP	       ENDnP !+==============================================================================B       INTEGER*4 FUNCTION SERIAL_RECV(CHANNEL, BUFF, LENBUFF, FLAG)       IMPLICIT NONEi       INCLUDE '($IODEF)'       INCLUDE '($SSDEF)'       INCLUDE '($SYSSRVNAM)'         INTEGER*2 CHANNELt       CHARACTER*(*) BUFF       INTEGER*4 LENBUFFa       INTEGER*4 FLAG       CHARACTER*255 IN_BUFFg       INTEGER*4 STATUS       STRUCTURE /IOSBLK/          INTEGER*2 STATUSa          INTEGER*2 SIZEe          INTEGER*4 RETADRt       END STRUCTUREt       RECORD /IOSBLK/ IOSB         STATUS = SYS$QIOW(, &      -                  %VAL(CHANNEL),+      -                  %VAL(IO$_READVBLK),i      -                  IOSB,t      -                  ,e      -                  ,l&      -                  %REF(IN_BUFF),+      -                  %VAL(LEN(IN_BUFF)),h      -                  ,       -                  ,e      -                  ,) !        IF (.NOT. STATUS) THEN%         CALL LIB$SIGNAL(%VAL(STATUS))s         SERIAL_RECV = 0e         RETURN       END IF !t!       IF (.NOT. IOSB.STATUS) THENn%         CALL LIB$SIGNAL(%VAL(STATUS))          SERIAL_RECV = 0          RETURN       END IF !  e!       BUFF = IN_BUFF(1:IOSB.SIZE)        SERIAL_RECV = IOSB.SIZEl       RETURN	       END P !+==============================================================================B       INTEGER*4 FUNCTION SERIAL_SEND(CHANNEL, BUFF, LENBUFF, FLAG)       IMPLICIT NONEb       INCLUDE '($IODEF)'       INCLUDE '($SSDEF)'       INCLUDE '($SYSSRVNAM)'       INTEGER*2 CHANNELh       CHARACTER*(*) BUFF       INTEGER*4 LENBUFF        INTEGER*4 FLAG       INTEGER*4 STATUS       STRUCTURE /IOSBLK/          INTEGER*2 STATUSt          INTEGER*2 SIZE           INTEGER*4 RETADR        END STRUCTUREo       RECORD /IOSBLK/ IOSB         STATUS = SYS$QIOW(,a&      -                  %VAL(CHANNEL),,      -                  %VAL(IO$_WRITEVBLK),      -                  IOSB,c      -                  ,       -                  ,m#      -                  %REF(BUFF),s&      -                  %VAL(LENBUFF),      -                  ,p      -                  ,v      -                  ,) !x       IF (.NOT. STATUS) THEN%         CALL LIB$SIGNAL(%VAL(STATUS))e         SERIAL_SEND = 0t         RETURN       END IF !i!       IF (.NOT. IOSB.STATUS) THENu%         CALL LIB$SIGNAL(%VAL(STATUS))          SERIAL_SEND = 0w         RETURN       END IF !  c       SERIAL_SEND = IOSB.SIZEe       RETURN	       ENDi   $show term tta0 @ Terminal: _TTA0:      Device_Type: Unknown       Owner: No Owner  B    Input:    9600     LFfill:  0      Width:  80      Parity: None0    Output:   9600     CRfill:  0      Page:   24   Terminal Characteristics::E    Interactive        Echo               Type_ahead         No EscapeoB    No Hostsync        TTsync             Lowercase          No Tab>    Wrap               Scope              No Remote          No EightbitC    Broadcast          No Readsync        No Form            FulldupaE    No Modem           No Local_echo      Autobaud           No HangupcE    No Brdcstmbx       No DMA             No Altypeahd       Set_speedg>    No Commsync        Line Editing       Overstrike editing No FallbackF    No Dialup          No Secure server   No Disconnect      No PasthruF    No Syspassword     No SIXEL Graphics  No Soft Characters No Printer Port>    Numeric Keypad     No ANSI_CRT        No Regis           No
 Block_mode>    No Advanced_video  No Edit_mode       No DEC_CRT         No DEC_CRT2>    No DEC_CRT3        No DEC_CRT4        No DEC_CRT5        No
 Ansi_Color    VMS Style Input   ------------------------------  $ Date: Fri, 9 Nov 2001 00:21:37 +0100. From: "Jesper Naur" <jesper.naur@post.tele.dk>" Subject: Re: [Help]Serial QIO Code; Message-ID: <3beb137e$0$358$edfadb0f@dspool01.news.tele.dk>i  @ Hiroyuki Tanaka <Hiroyuki_Tanaka4@excite.co.jp> wrote in message7 news:68cfa44d.0111081430.5231772c@posting.google.com...t  I Your problem is most likely that you need to set your terminal to NOECHO..  The effect of not doing this is:   1) Your program sends an 'A' 2) The modem echoes the 'A'e@ 3) Since the terminal is not set to NOECHO, it will echo the 'A'! 4) Same thing happens for the 'T'yI 5) The only reason, that this doesn't go on forever is probably, that theM+ modem hasn't really got a typeahead buffer.i  % You can set the terminal NOECHO usingi   $ set term/noecho/perm tta0:  K You can also do it from your code using the $QIO function IO$_SETMODE. This L is very likely, what 'set host/dte' does - try a 'show term tta0' while 'set host/dte' is in effect.t       Best regards     Jesper Naurj   ------------------------------  % Date: Thu, 08 Nov 2001 18:54:49 -0500r- From: JF Mezei <jfmezei.spamnot@videotron.ca>a" Subject: Re: [Help]Serial QIO Code, Message-ID: <3BEB1B45.50D19027@videotron.ca>   Hiroyuki Tanaka wrote:B > I have been trying to acheive the same with some QIO code I haveE > written.  However when I run the code I do not get the OK response. B > I actually get the AT which I sent, plus my code sends AT twice.  M Looks like an echo problem. When you set the terminal characteristics in youroF code, try adding IO$M_NOECHO (or whatever variations are used for your! language) in the characteristics.a  L Another thing to do is to add/or IO$M_NOECHO to the IO$M_READVBLK when doingJ the read to make sure that stuff the modem sends to you doesn't get echoed back to the modem as well.   ------------------------------  $ Date: Fri, 9 Nov 2001 13:15:41 +1100/ From: "Phil Howell" <phowell@snowyhydro.com.au>"" Subject: Re: [Help]Serial QIO Code0 Message-ID: <t0HG7.260$c87.14716@ozemail.com.au>  B "Hiroyuki Tanaka" <Hiroyuki_Tanaka4@excite.co.jp> wrote in message7 news:68cfa44d.0111081430.5231772c@posting.google.com...o > Dear Readers,  >sG > I am trying to learn how to do serial I/O using QIO's.  For my test IsC > have an Alpha station 200 and connected a modem to TTA0:.  In theb > serialC > line I have a HP protocol analyser so I can see what is going on.  >h@ > When I use $set host /dte TTA0: and type At<Cr> and the modems
 > response OKa6 > is displayed. On the protocol analyser the trace is: >m > $set host /dte tta0: > DTE Signal <Cr> A T <Cr>- > DCE Signal  <Cr> A T <Cr><Cr><Lf>OK<Cr><Lf>e >rB > I have been trying to acheive the same with some QIO code I haveE > written.  However when I run the code I do not get the OK response.tB > I actually get the AT which I sent, plus my code sends AT twice. >r2 > DTE Signal A T <Cr>                     A T <Cr>3 > DCE Signal  A T <Cr><Cr><Lf>OK<Cr><Lf>   A T <Cr>O >ND > I have attached the code I am using.  How call I change my code toH > work like to result to set host /dte.  I am at a loss as to the reasonG > as I am trying to learn how to use QIO.  I have attached the terminal=" > characteristics that I am using. >n <snip>I the code used in set host /dte is in SYS$COMMON:[SYSHLP.EXAMPLES]DTE_AT.C.! this may be a good place to startf? (I think in the past there were versions in macro and fortran -oA maybe I should keep a backup of sys$examples before upgrading vmsa) who knows what other gems have been lost)c Phil   ------------------------------   Date: 8 Nov 2001 22:33:08 -0800o, From: mcbill20@hotmail.com (Bill McLaughlin)" Subject: Re: [Help]Serial QIO Code= Message-ID: <e9cbc4f2.0111082233.10c9cfcf@posting.google.com>r  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3BEB1B45.50D19027@videotron.ca>...i > Hiroyuki Tanaka wrote:D > > I have been trying to acheive the same with some QIO code I haveG > > written.  However when I run the code I do not get the OK response.tD > > I actually get the AT which I sent, plus my code sends AT twice. > O > Looks like an echo problem. When you set the terminal characteristics in youreH > code, try adding IO$M_NOECHO (or whatever variations are used for your# > language) in the characteristics.t > N > Another thing to do is to add/or IO$M_NOECHO to the IO$M_READVBLK when doingL > the read to make sure that stuff the modem sends to you doesn't get echoed > back to the modem as well.  F I have considerable experience using QIO's to talk to modems and otherE devices and I definitely agree with the previous posters. I would not A only turn off echo on the serial port (set term/noecho or qio setnA mode) but also with the modem. As you probably already know, ATE0t turns off echo.d  F I have code that uses a modem to dial a pager and another program thatF calls the NIST time service to set the system time. Please let me know if you need any examples.i   Bill McLaughlinx   ------------------------------   End of INFO-VAX 2001.623 ************************