1 INFO-VAX	Thu, 18 Oct 2001	Volume 2001 : Issue 579       Contents: Re: A free VMS implementation? Re: A free VMS implementation? Re: A free VMS implementation? Re: A free VMS implementation? Re: A free VMS implementation? Re: A free VMS implementation? alpha 433au's only $399 6 ANN: New release of VMSTAR with expanded ODS-5 supportP Re: BACKUP and /NOALIAS (was: Re: [OpenVMS] V7.2 VAX satellite doesn't find V7.3P Re: BACKUP and /NOALIAS (was: Re: [OpenVMS] V7.2 VAX satellite doesn't find V7.3P Re: can NFS client choose to mount over tcp or udp depending upon the NFS server CDD and CDD$DICTIONARY4 Re: Converting an ODS-2 to an ODS-5 file system disk Copy command...  Re: Copy command...  Re: Copy command...  Re: DECNET ping equivalent?  Re: DECNET ping equivalent? 6 Re: ES45 Announced as "UNIX server" - VMS absent again6 Re: ES45 Announced as "UNIX server" - VMS absent again6 Re: ES45 Announced as "UNIX server" - VMS absent again Forcing alignment errors?  Re: Forcing alignment errors? G Future VMS owners/plans, was:Re: More official info on Compaq/HP merger P Re: Future VMS owners/plans, was:Re: More official info on Compaq/HP merger mergP Re: Future VMS owners/plans, was:Re: More official info on Compaq/HP merger merg Re: Global symbol  Re: Global symbol & Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors& Re: Higher prices for Alpha processors) Linker64 producing un-INSTALLable images?  Re: make files on OpenVMS * Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger* Re: More official info on Compaq/HP merger Re: MOZILLA 0.9.5 & Re: Mozilla 0.9.5 and file protections- Re: multinet IP address and host.local change & Quotation for an AlphaServer 300 4/266, Re: Scott McNealy has no respect for Alpha's7 Re: sd comman (or who has the biggest cd.com or sd.com) 7 Re: sd comman (or who has the biggest cd.com or sd.com)  RE: TL892s and AUTO_CLEAN  Re: user authentification  Re: user authentification  VTEST on Alpha# Re: Wanted:SMS Center under OpenVMS # Re: Wanted:SMS Center under OpenVMS , Re: We've burned our boats say Compaq and HP* Re: Windows Fails To Storm the Data Centre Re: writing to shared files  Re: writing to shared files  Re: writing to shared files  Re: writing to shared files  Re: writing to shared files  Re: writing to shared files  Re: writing to shared files  Re: writing to shared files  Re: writing to shared files   F ----------------------------------------------------------------------   Date: 17 Oct 2001 23:27:33 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) ' Subject: Re: A free VMS implementation? , Message-ID: <9ql455$2p9h$1@info.cs.uofs.edu>  ' In article <3BCB56C0.E8CF165C@fsi.net>, 4  "David J. Dachtera" <djesys.nospam@fsi.net> writes: |>  C |> My impression is that you're quite a few cuts above "the average 
 |> UN*X-er".    N That's probably more of a compliment than I deserve, but thank you anyway. :-)  L |>            No doubt, serious kernel hackers would evenutally grasp it. MyH |> point was that to OpenSource VMS would not be a serious threat to it,J |> though the profitability of commercial issues might suffer considerably1 |> if not differentiated from the "free" version.    This I can agree with.   |>  J |> In deference to certain VMS customers, though, perhaps a "declassified"I |> version of OVMS would be more suitable to OpenSource, leaving the more G |> sensitive bits out, but still leaving a buildable kernel, libraries, J |> etc. Then, "VMS" could go back to being THE commercial VMS, and OpenVMS' |> could become the OpenSource version.   I No matter what they called them, there would still be only one "official" K VMS, just like there is only one "official" FreeBSD and only one "official" I NetBSD.  It is all a matter of control.  Linux, the distributions not the G kernel, don't have this and thus the confusion.  I would not expect VMS G to degenerate to that state as the people likely to work on VMS, even a K port to new architectures, strike me as being considerably more disciplined  than the average Linux hacker.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 17 Oct 2001 23:31:23 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) ' Subject: Re: A free VMS implementation? , Message-ID: <9ql4cb$2p9h$2@info.cs.uofs.edu>  - In article <9qgrnu$mej$1@tyfon.itea.ntnu.no>, <  Roar =?iso-8859-1?Q?Thron=E6s?= <roart@nvg.ntnu.no> writes: |>  H |> Mainstream Linux/Unix has not even got a decent networked file system |> (or so I think).   D And which decent networked file system does VMS have??  This is likeG people who constantly complain about the shortcomings of X11 when there ; is no real alternative for networked graphics applications.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 17 Oct 2001 23:43:59 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) ' Subject: Re: A free VMS implementation? , Message-ID: <9ql53v$2q2r$1@info.cs.uofs.edu>  / In article <00256AE7.004D8DAC.00@quegw01.btyp>, #  Steve.Spires@yellgroup.com writes: O |> Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza  |>   |>  O |> I think you have taken some of that same attitude in your assessment of this O |> book [UNIX for VMS Users] based on what you say - have you purposefully been # |> selective in what you have said?   F Well, I couldn't type the whole book into a news article so I did have to be a little selective.  :-)    Q |> your own HHL program or using DCL procedures. nroff and troff are NOT included  |> as 'file management' tools,    - Table 4.1 Summary of File management Commands     Page 69 -- nroff     Page 70 -- troff 0 Table 4.2 Commonly Used File management Commands    Page 71 -- nroff     Page 72 -- troff   F To be honest, these two tables appear to have all of the Unix commandsC listed in them.  Surely there is more to Unix than File Management?   O |>                             but are included as text processing tools. tr is S |> included in the 'Advanced File Management' chapter. What or where would you have  |> placed these commands in?  < All of them (nroff, troff, tr) are text processing commands.   |>  S |> I have found the book invaluable in my initial use of Unix, and even refer to it Q |> from time to time now. And it has also been a great help to the Unix bods here  |> in reverse.  F Which makes me think even more that a newer version written by someoneE who actually knows Unix might be equally valuable.  Especially as it  F becomes more and more obvious that even diehard VMS shops are going to% have to deal with Unix on some level.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 17 Oct 2001 23:49:02 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) ' Subject: Re: A free VMS implementation? , Message-ID: <9ql5de$2q2r$2@info.cs.uofs.edu>  / In article <3BCCF601.6CC5030D@cableinet.co.uk>, 6  Tim Llewellyn <tim.llewellyn@cableinet.co.uk> writes: |>  E |> ANyway, back to your original point, why do you think they started  |> implementing  |> new bits of VMS in C? |>    : Maybe because it's the best language for the job??     :-)   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 17 Oct 2001 21:30:01 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: Re: A free VMS implementation? 3 Message-ID: <zyHYKxbyYE01@eisner.encompasserve.org>   ` In article <9ql5de$2q2r$2@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:1 > In article <3BCCF601.6CC5030D@cableinet.co.uk>, 8 >  Tim Llewellyn <tim.llewellyn@cableinet.co.uk> writes: > |>  G > |> ANyway, back to your original point, why do you think they started  > |> implementing  > |> new bits of VMS in C? > |>   > < > Maybe because it's the best language for the job??     :-)  4 No, because programmers were more readily available.   ------------------------------    Date: 17 Oct 2001 21:31:00 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: Re: A free VMS implementation? 3 Message-ID: <qUo2oyjINgpS@eisner.encompasserve.org>   ` In article <9ql4cb$2p9h$2@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:/ > In article <9qgrnu$mej$1@tyfon.itea.ntnu.no>, > >  Roar =?iso-8859-1?Q?Thron=E6s?= <roart@nvg.ntnu.no> writes: > |>  J > |> Mainstream Linux/Unix has not even got a decent networked file system > |> (or so I think).  > 7 > And which decent networked file system does VMS have?   ; DFS, which is about as far as you can go without a cluster.    ------------------------------  % Date: Wed, 17 Oct 2001 15:27:40 -0400 - From: "www.islandco.com" <sales@islandco.com>   Subject: alpha 433au's only $399/ Message-ID: <tsrm956uub698a@news.supernews.com>   7 We're dumping these systems - about 20 of them for $399    1.44MB Floppy included  3 Go to: http://www.islandco.com/specials/433base.htm   , Quantity being sold off with 1 Year warranty   sales@islandco.com www.islandco.com' http://www.islandco.com/legal-email.htm    We sell Alpha's !    ------------------------------  # Date: Wed, 17 Oct 2001 22:03:18 GMT - From: goathunter@goatley.com (Hunter Goatley) ? Subject: ANN: New release of VMSTAR with expanded ODS-5 support 0 Message-ID: <3bcdfd9c.79311413@news.process.com>  * VMSTAR V3.4 is now available for download.  = Thanks to Patrick Young, VMSTAR now features full support for 9 ODS-5 disks (a release in August included some support by ; Larry Kilgallen).  If you're de-tarring onto an ODS-5 disk, ; VMSTAR will now retain the case on filenames, extra dots in  filenames, etc.  For example:   5 $ vmstar/extr/verb dka100:[hunter.fileserv]catdoc.tar 6                               [HUNTER.catdoc-0^.91^.4]:                               [HUNTER.catdoc-0^.91^.4.doc]F Sep 11 06:37:37 2000      779 [HUNTER.catdoc-0^.91^.4.doc]Makefile.in;C Apr 17 12:11:31 2000     8965 [HUNTER.catdoc-0^.91^.4.doc]catdoc.1;  [...]   
 $ dir [.cat*]   ' Directory LDA9:[HUNTER.catdoc-0^.91^.4]   A COPYING.;1                     36/36      27-SEP-1999 11:19:07.00 A CREDITS.;1                      3/3       30-DEC-1999 14:25:31.00 A doc.DIR;1                       1/1       17-OCT-2001 16:59:14.76 A INSTALL.;1                      5/5       27-SEP-1999 11:19:07.00 A INSTALL.dos;1                   6/6       27-SEP-1999 11:19:07.00 A Makefile.in;1                   1/1       27-SEP-1999 11:19:07.00 A NEWS.;1                         6/6       27-SEP-1999 11:19:07.00 A README.;1                       4/4       17-OCT-2001 16:59:19.05     : In addition, VMSTAR V3.4 includes changes from John Reagan< for /LIST ("-t") to better emulate UN*X tar programs.  /LIST? now gives a brief, filename-only listing, while adding /VERBOSE < displays even more information about the files than previous2 releases did (the file protections are now shown).  > I've included .OBJ files for OpenVMS VAX 5.4+ (VAX C), OpenVMS> VAX V6.0+ (DEC C), and OpenVMS Alpha V6.1+.  If you don't have= a C compiler, you can create the .EXE files by just executing 
 @LINK.COM.  = You can download VMSTAR V3.4 using any of the following URLs:    http://www.process.com/openvms/   6 ftp://ftp.process.com/vms-freeware/fileserv/vmstar.zip; http://vms.process.com/ftp/vms-freeware/fileserv/vmstar.zip 2 ftp://ftp.tmk.com/vms-freeware/fileserv/vmstar.zip7 http://www.tmk.com/ftp/vms-freeware/fileserv/vmstar.zip   2 And on the other mirrors within the next 24 hours.   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 9 goathunter@goatley.com     http://www.goatley.com/hunter/    ------------------------------  % Date: Wed, 17 Oct 2001 14:13:06 -0400 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> Y Subject: Re: BACKUP and /NOALIAS (was: Re: [OpenVMS] V7.2 VAX satellite doesn't find V7.3 $ Message-ID: <3bcdca65$1@news.si.com>  D >  The discussion was around using /ALIAS it to improve performance C >  of the BACKUP -- with /ALIAS, less goes out and less comes back  C >  in, but the resulting disk contents are valid regardless of the   >  use of /ALIAS.   ( This seems to contradict what HELP says:  @      Specifies that the previous behavior of multiple processing@      of alias and primary file entries be maintained. The /ALIASA      qualifier maintains the previous BACKUP behavior of treating F      alias file entries the same as primary file entries. Therefore, aE      primary file may be processed multiple times by BACKUP if one or C      more alias file entries reference the same primary file entry.   * I would expect /NOALIAS to move less data. --  A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.com = 3290 Patterson Ave. SE, MS      Addresses modified to prevent < Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Wed, 17 Oct 2001 14:14:25 -0400 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> Y Subject: Re: BACKUP and /NOALIAS (was: Re: [OpenVMS] V7.2 VAX satellite doesn't find V7.3 $ Message-ID: <3bcdcab4$1@news.si.com>  E >  The reason /ALIAS is not the default is because of expectations of E >  selective file restorations -- on a disk with alias entries, only  F >  the primary entry gets copied out, meaning only the primary can be ) >  selectively restored from the archive.   + According to HELP, /ALIAS _is_ the default:    $ help backup /alias   BACKUP     /ALIAS  &         /ALIAS save-set-spec (default)         /NOALIAS  3 I don't understand the "save-set-spec" valie there.  --  A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.com = 3290 Patterson Ave. SE, MS      Addresses modified to prevent < Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  # Date: Wed, 17 Oct 2001 22:00:01 GMT 4 From: "Matt Muggeridge" <Matt.Muggeridge@compaq.com>Y Subject: Re: can NFS client choose to mount over tcp or udp depending upon the NFS server @ Message-ID: <Bbnz7.178422$bY5.832702@news-server.bigpond.net.au>   Hi Michle,   K It's on the list, but no dates as yet.  If you need an official answer then J please contact our product manager ( send me mail and I'll provide contact	 details).o   Cheers,r Matt.i  > "Michle Magenc" <mmagenc@proxis-services.fr> wrote in message7 news:6c0a4ed0.0110150641.4895d9d0@posting.google.com...'
 > Hi Matt, >N$ > Thank you very much for answering.F > BTW, will this feature (NFS Client over TCP and/or UDP) be part of a > future version ? >3 > Best regards, Michle.   ------------------------------  % Date: Wed, 17 Oct 2001 20:01:30 -0400t+ From: "Mike Ranger" <mranger@quickclic.net>o Subject: CDD and CDD$DICTIONARYT2 Message-ID: <9ql609$fbi$1@news1.mountaincable.net>  	 Hi all...yH     Quick question.  I have a c++ compiler on one node of a cluster, andK cdd's on each of the three nodes.  I wish to compile a c++ file referencingrK the CDD on one of the other nodes, for my "#pragma dictionary cdd$top.blah"  stuff.  H     I tried referencing CDD$DICTIONARY to point to the other cdd.dic butK since I cannot reassign it system wide, the compile fails saying "hey, thatlK is supposed to be a system logical".  I'm afraid making it a system logicall; even for a short period of time will annoy a few people :-)w  ? Particulars that I care to remember:  VMS 6.something on a VAX.o  I I'm sure it can't be that hard, but darned if I could find it in good oldi help, wizard, faq or google.   Mike   ------------------------------    Date: 17 Oct 2001 14:42:44 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)r= Subject: Re: Converting an ODS-2 to an ODS-5 file system disks3 Message-ID: <BlvLeBuJYoQb@eisner.encompasserve.org>h  b In article <3bcdc4d4$1@news.si.com>, "Brian Tillman" <tillman_brian@notnoone.notnohow.com> writes:< > What is there about ODS-5 that makes it undoable on a VAX?   Priorities and demand.  C VMS Development is under the impression that existing VAX customersr prefer stability to innovation.l   ------------------------------  % Date: Wed, 17 Oct 2001 22:24:19 -0300o' From: "valdemir" <valdemir-@uol.com.br>p Subject: Copy command...< Message-ID: <000c01c15773$9cf238a0$152b90c8@unipobjetivo.br>  , This is a multi-part message in MIME format.  + ------=_NextPart_000_0009_01C1575A.77053E30e Content-Type: text/plain;o 	charset="iso-8859-1"e+ Content-Transfer-Encoding: quoted-printable   
 Hello all:  I  What's the right way to copy all files, directories and subdirectories =e from     a device to another device ?  ?   $ copy/log disk$100:[sales...]*.*;*  disk$200:[sales...]*.*;*o  G    This command will create directory's tree in the device disk$c200: =a ???o      Thanks in advance...o  ?    (Please, be pacient with my little English knowledgement...)p  + ------=_NextPart_000_0009_01C1575A.77053E30. Content-Type: text/html; 	charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printablea  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>7 <META http-equiv=3DContent-Type content=3D"text/html; =o charset=3Diso-8859-1">9 <META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>e <STYLE></STYLE>  </HEAD>e <BODY bgColor=3D#ffffff>8 <DIV><FONT face=3DArial size=3D2>Hello all:</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>I <DIV><FONT face=3DArial size=3D2>&nbsp;What's the right way to copy all =a	 files,=20 0 directories and subdirectories from</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>D <DIV><FONT face=3DArial size=3D2>&nbsp; a device to another device = ?</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>4 <DIV><FONT face=3DArial size=3D2>&nbsp; $ copy/log =! disk$100:[sales...]*.*;*&nbsp;=20 % disk$200:[sales...]*.*;*</FONT></DIV>f4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>H <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; This command will create = directory's=20. tree in the device disk$c200: ???</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>9 <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Thanks in =  advance...</FONT></DIV> 4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>H <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (Please, be pacient with = my little=204 English knowledgement...)</FONT></DIV></BODY></HTML>  - ------=_NextPart_000_0009_01C1575A.77053E30--c   ------------------------------  # Date: Thu, 18 Oct 2001 00:40:52 GMTf, From: "Paul Dennis" <comedyox@earthlink.not> Subject: Re: Copy command...D Message-ID: <oypz7.7300$SU2.762676@newsread1.prod.itd.earthlink.net>   Vlad writes:  H > What's the right way to copy all files, directories and subdirectories from >i > a device to another device ?? > $ copy/log disk$100:[sales...]*.*;*  disk$200:[sales...]*.*;*e   I'd use:  1 $ backup disk$100:[sales...]*.*;* disk$200:[*...]t   .pd.   ------------------------------  % Date: Wed, 17 Oct 2001 23:34:43 -0400 0 From: "Virginia Flores" <virginiaflores@msn.com> Subject: Re: Copy command...5 Message-ID: <OE1348AoRbU2LRXNbN00001de52@hotmail.com>l  , This is a multi-part message in MIME format.  + ------=_NextPart_000_0095_01C15764.4C694CC0  Content-Type: text/plain;k 	charset="iso-8859-1"t+ Content-Transfer-Encoding: quoted-printabled  H Either the COPY command or the BACKUP command will work equally well.  = Your English is fine.|   -V!   ----- Original Message -----=20    From: valdemir=20t   To: Info-VAX@Mvb.Saic.Com=20+   Sent: Wednesday, October 17, 2001 9:24 PMn   Subject: Copy command...       Hello all:   =20d<    What's the right way to copy all files, directories and = subdirectories fromG   =20m      a device to another device ?   =20nA     $ copy/log disk$100:[sales...]*.*;*  disk$200:[sales...]*.*;*$   =20iI      This command will create directory's tree in the device disk$c200: =? ???8   =20T      Thanks in advance...n   =20eA      (Please, be pacient with my little English knowledgement...)k  + ------=_NextPart_000_0095_01C15764.4C694CC0c Content-Type: text/html; 	charset="iso-8859-1"h+ Content-Transfer-Encoding: quoted-printableo  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>3 <META content=3D"text/html; charset=3Diso-8859-1" =  http-equiv=3DContent-Type>9 <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>  <STYLE></STYLE>g </HEAD>s <BODY bgColor=3D#ffffff>J <DIV><FONT face=3DGaramond>Either the COPY command or the BACKUP command = will work=206 equally well.&nbsp; Your English is fine.</FONT></DIV> <DIV>&nbsp;</DIV>i* <DIV><FONT face=3DGaramond>-V</FONT></DIV> <BLOCKQUOTE=20J style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =, 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">E   <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>a	   <DIV=201?   style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =a black"><B>From:</B>=20+   <A href=3D"mailto:valdemir-@uol.com.br" =U, title=3Dvaldemir-@uol.com.br>valdemir</A>=20   </DIV>2   <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20*   href=3D"mailto:Info-VAX@Mvb.Saic.Com"=20@   title=3DInfo-VAX@Mvb.Saic.Com>Info-VAX@Mvb.Saic.Com</A> </DIV>G   <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, October 17, =T 2001 9:24=20
   PM</DIV>G   <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Copy command...</DIV>P   <DIV><BR></DIV> :   <DIV><FONT face=3DArial size=3D2>Hello all:</FONT></DIV>6   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>G   <DIV><FONT face=3DArial size=3D2>&nbsp;What's the right way to copy =i
 all files,=20S2   directories and subdirectories from</FONT></DIV>6   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>F   <DIV><FONT face=3DArial size=3D2>&nbsp; a device to another device = ?</FONT></DIV>6   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>6   <DIV><FONT face=3DArial size=3D2>&nbsp; $ copy/log =! disk$100:[sales...]*.*;*&nbsp;=20 '   disk$200:[sales...]*.*;*</FONT></DIV>,6   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>J   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; This command will create = directory's=200   tree in the device disk$c200: ???</FONT></DIV>6   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>;   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Thanks in =r advance...</FONT></DIV> 6   <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>J   <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (Please, be pacient with = my little=20C   English knowledgement...)</FONT></DIV></BLOCKQUOTE></BODY></HTML>   - ------=_NextPart_000_0095_01C15764.4C694CC0--#   ------------------------------  # Date: Wed, 17 Oct 2001 19:01:59 GMT 3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>.$ Subject: Re: DECNET ping equivalent?/ Message-ID: <3BCDD518.53DD8709@cableinet.co.uk>q   Larry Kilgallen wrote: > g > In article <3BCDB3DD.B6EDD5FA@cableinet.co.uk>, Tim Llewellyn <tim.llewellyn@cableinet.co.uk> writes:  > >A > >,% > > Steve.Spires@yellgroup.com wrote:u > >>Q > >> Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plazat > >>Q > >> Well, strictly speaking it DOES denote whether the node is reachable or not.e > >>H > > but does it reach out and "touch" the requested node like ping does?F > > Maybe I am wrong and it does, can't test at the moment as I am VMS
 > > deprived.  > > D > > Anyway, you don't get packet loss figures like you do with ping. > G > DECnet does not support a user interface for sending isolated packetsaE > like UDP.  Therefore any packet loss will be recorded in your localY > error counters.s  F sure, but mcr ncp show known nodes does not provide that. This was the nit I was picking at.    regards: -- n Tim.Llewellyn@cableinet.co.uk  i  C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.r   ------------------------------  % Date: Wed, 17 Oct 2001 18:52:02 -0600b' From: Thomas Dzubin <dzubint@vcn.bc.ca>a$ Subject: Re: DECNET ping equivalent?$ Message-ID: <3BCE27B2.2D4@vcn.bc.ca>  8 Here's a fragment I wrote about five or six years ago... I pulled it out of dejanews:  (search for: dzubin decnet ping)  < In article <80ccth$lru$1@sylvester.vcn.bc.ca>, Thomas Dzubin <dzubint@vcn.bc.ca> wrote:G > If your site policies allow you to do a "SET HOST", then why not just,D > try and open the DECNET object #23 ?(I think this still works with > phase V)?? >iC > Something like: (In DCL...sorry everyone, I'm just winging it...)> >      $ N="MYNODE">+ >      $ OPEN FILE 'N'::"23="/ERROR=BADOPENe >      $ CLOSE FILEt >      $ OPENSTATUS=$STATUS  >      $ SUCCESS=1 >      $BADOPEN: >      $ OPENSTATUS=$STATUSw >      $ SUCCESS=0 >      $DONEOPEN:o >a         labadie wrote: >  > Hello- > M > I had already posted (2000/07/12) this decnet ping with my account palm6174s > % > May be it should go in the freeware3 >  > EnjoyD >  > Grard Labadie > 
 > $!'f$ver(0)  > $ SET NOON > $ SET CONTROL=Yu > $ ON CONTROL_Y THEN GOTO FIN, > $ NETNODE_REM = F$TRNLNM("NETNODE_REMOTE")  > $ IF NETNODE_REM .EQS. "" THEN. > NETNODE_REM  :=SYS$SYSTEM:NETNODE_REMOTE.DAT
 > $ DEBUT: > $ FLAG_OK = 1c
 > $ NAME = P1i' > $ IF NAME .eqs. "" THEN goto HELP_FINl) > $ IF F$LOCATE(".",P1) .NE. F$LENGTH(P1)  > $ THEN > $       FLAG_ADDR = 1M/ > $       AREA = F$INTEGER(F$ELEMENT(0,".",P1)) / > $       IF AREA .GT. 63 THEN GOTO ERREUR_ADDRe. > $       NUM = F$INTEGER(F$ELEMENT(1,".",P1))0 > $       IF NUM .GT. 1023 THEN GOTO ERREUR_ADDR > $       ADDR = AREA*1024+NUM > $       ADDH=ADDR . > $ NAME = " Address ''AREA'.''NUM' or ''addr'# > (dec)"+f$fao("!XW",addh)+" (hex)"  > $ ELSE > $       FLAG_ADDR = 0a% > $       IF F$CVUI(0,8,P1) .GT. %X39  > $       THEN) > $               ADDR = F$EXTRAC(0,6,P1), > $       ELSE& > $               ADDR = F$INTEGER(P1)+ > $               IF ( ADDR .EQ. 0 ) .OR. (  > ADDR .EQ. 1 )a > $               THEN2 > $                       ADDR = F$INTEGER(%X'P1')3 > $                       IF ( ADDR .EQ. 0 ) .OR. (. > ADDR .EQ. 1 )  > $                       THEN1 > $                               ADDR = F$EXTRACi
 > (0,6,P1) > $                       ELSE0 > $                               IF ( ADDR .GT. > 65535 ) .OR. ( ADDR .LT.1 ) & > $                               THEN. > $                                       GOTO
 > ERREUR_ADDR & > $                               ELSE0 > $                                       AREA = > ADDR/1024T0 > $                                       NUM  = > ADDR-(AREA*1024), > $                                       P1 > = "''AREA'.''NUM'"4 > $                                       GOTO DEBUT' > $                               ENDIF/ > $                       ENDIF  > $               ELSE* > $                       AREA = ADDR/10241 > $                       NUM  = ADDR-(AREA*1024)/1 > $                       P1   = "''AREA'.''NUM'"l$ > $                       GOTO DEBUT > $               ENDIFl > $       ENDIF 	 > $ ENDIFd > $ IF FLAG_ADDR > $ THEN/ > $       OPEN/READ/SHARE NETNODE 'NETNODE_REM'S2 > $       READ/KEY="''ADDH'"/ERROR=ERR_LEC NETNODE > RECORD+ > $       NODE_NAME = F$EXTRACT(2,6,RECORD)o1 > $ NAME = NODE_NAME + " Address ''p1' or ''addr'N! > (dec)"+f$fao("!XW",addr)+" (hex3 > $       ERR_LEC: > $       CLOSE NETNODE/ > $ ELSE/ > $       OPEN/READ/SHARE NETNODE 'NETNODE_REM'e3 > $       READ/KEY="''ADDR'"/INDEX=1/ERROR=ERR_LEC1v > NETNODE RECORD3 > $       ADDH = F$CVUI(0,16,F$EXTRACT(0,2,RECORD))r+ > $       NODE_NAME = F$EXTRACT(2,6,RECORD)w > $       AREA = ADDH/1024! > $       NUM  = ADDH-(AREA*1024) 3 > $ NAME = p1 + " Address ''AREA'.''NUM' or ''addr'c > (dec)"+f$fao("!XW",addh)+" (hc > $       ERR_LEC1:l > $       CLOSE NETNODEt	 > $ ENDIFt > $ DEFINE SYS$OUTPUT NL:- > $ DEFINE SYS$ERROR  NL: ) > $ A=F$FILE_ATT("''ADDR'::""1=""","ORG")m > $ STATUS = $STATUS > $ DEASSIGN SYS$OUTPUTj > $ DEASSIGN SYS$ERROR1 > $ IF STATUS .EQ. %X0000206C !%SYSTEM-F-REMRSRC, ! > insufficient systemresources at@1 > $ THEN WRITE SYS$OUTPUT "  ''NAME' insufficient/! > system resources atremote node" * > $ ELSE IF STATUS .EQ. %X00000294 !REJECT- > $      THEN  WRITE SYS$OUTPUT "  ''NAME' isg% > alive,but DECNET rejectconnection "t3 > $      ELSE IF STATUS .EQ. %X000020A4 ! NOSUSHOBJw2 > $           THEN  WRITE SYS$OUTPUT "  ''NAME' is > alive on DECNET  ". > $           ELSE IF STATUS .EQ. %X0000028C ! > NOSUSHNODE" > $              THEN  FLAG_OK = 0 > $                WRITE0 > SYS$OUTPUT "''NAME'''F$ELEMENT(1,",",F$MESSAGE > (status))"1 > $              ELSE IF STATUS .EQ. %X00002094 !e
 > UNREACHABLEi$ > $                 THEN FLAG_OK = 0 > $                WRITE0 > SYS$OUTPUT "''NAME'''F$ELEMENT(1,",",F$MESSAGE > (status))" > $                     ELSE > $                WRITE0 > SYS$OUTPUT "''NAME'''F$ELEMENT(1,",",F$MESSAGE > (status))" > $                ENDIF > $           ENDIFP > $       ENDIF 	 > $ ENDIFr+ > $ IF ( FLAG_OK .AND. (F$EXTRAC(0,1,F$EDIT4( > (P2,"UPCASE")) .EQS. "F")) THEN MC NCP > $FIN:T. > $ IF F$TRNLNM("SYS$OUTPUT") .EQS. "NL:" THEN > DEASSIGN SYS$OUTPUT-- > $ IF F$TRNLNM("SYS$ERROR") .EQS. "NL:" THEN0 > DEASSIGN SYS$ERROR > $ EXIT > $ERREUR_ADDR:n > $HELP_FIN:% > $ WRITE SYS$OUTPUT "Address Error."a* > $ WRITE SYS$OUTPUT "Please enter an node' > address : x.xxx or decimal form xxxxxs/ > $ WRITE SYS$OUTPUT " or enter the name of the  > node." > $exitt > # > Steve.Spires@yellgroup.com wrote:s > P > > Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza > >y > > $ MC NCP > > NCP> LOOP NODE nodenamee > >m > > should work for you. > >H
 > > Cheers > >t > > Steve Spires > >bJ > > "frank brown" <frank.brown@ci.seattle.wa.us> on 10/16/2001 03:49:17 PM > > $ > > To:        Info-VAX@Mvb.Saic.Com/ > > cc:         (bcc: Steve Spires/YellowPages)aR > > From:      "frank brown" <frank.brown@ci.seattle.wa.us>, 16 October 2001, 3:49 > >            p.m.  > >d > > DECNET ping equivalent?e > > G > > Is there an equivalent to the unix ping for DECNET phase IV to testPF > > connectivity to a remote node without using TCP/IP?  I'm using DIR9 > > NODE::DUAn:[DIR] but wonder if there's a cheaper way., > >c > > -Frank Brown > > http://www.inwa.net/~frog/   ------------------------------  % Date: Wed, 17 Oct 2001 22:15:04 +0200t& From: John McLean <mcleanj@dplanet.ch>? Subject: Re: ES45 Announced as "UNIX server" - VMS absent again>* Message-ID: <3BCDE6C8.C2F1FAF9@dplanet.ch>   Bill Todd wrote: > : > JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message( > news:3BCCEFC1.1EF3CF90@videotron.ca... > > "David J. Dachtera" wrote: > > >MN > http://www.infoworld.com/articles/hn/xml/01/10/16/011016hncompaq.xml?1016tup > m1 > > >d > > > No mention of VMS. > >M > > K > > Yeah, but there are lots of news in that article. The first sentense ist > funny though:U9 > > REFRESHING ITS COMMITMENT to the company's RISC-basediE > >                       AlphaServer product line, Compaq on Tuesday1 > introduced
 > > three newr0 > >                       AlphaServer offerings. > >N# > > (uppercase is part of article).. > >a > >l > > But the big clincher is: > > ##N > > Compaq will support its Alpha customers indefinitely and OS transitions toN > > Itanium should be seamless, but around 2003  the Alpha road map will morph > toN > > Itanium and new versions of Alpha chips will be designed by an Intel team. > > ## > >AK > > Got to give it to the producers of the Curly&Carly show, they sure know  > how to; > > stimulate the media with all sorts of funny statements.l > I > I suspect it was simply reporter confusion about the chips that will belM > starting to appear in 'AlphaServers' (if that brand is still used) at aboutnH > that time (which of course will be 100% Itanic in nature, save for the > 'legacy' real Alphas). > * > But I particularly enjoyed the statement > M > "I think the ES45 is further indication that we are absolutely committed torM > the Alpha road map, and there is no backing off that commitment," she said.  > K > Now that the Alpha road map has a big "Dead End!" sign and barricade wellwF > this side of the horizon, it's possible that *this* commitment mightM > actually be adhered to - but I can't find it in my heart to give Compaq anyd > credit for that. >  > - bill    H It's interesting that Compaq should say that the ES45 is a unix box whenB Tru64 will clash with HP Unix and 64 will probably die as a result5 (after some clustering things have been transferred).u  D Also on this thought, if Tru64 dies that would have left only VMS onF Alpha, so perhaps this is also why Alpha is disappearing; the costs ofD supporting a processor for one "niche" operating system could not be
 justified.  C BTW, I love the continuous claims that the transition from Alpha toWE Intel should be seamless.  Is this a reassuring comment to customers,eA one that is supported by facts, or is it wishful thinking that its3 "should" (but possibly won't) be the way things go.o     John McLean    ------------------------------  # Date: Thu, 18 Oct 2001 02:39:33 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net>? Subject: Re: ES45 Announced as "UNIX server" - VMS absent again.> Message-ID: <Fhrz7.130306$vq.28827150@typhoon.ne.mediaone.net>  3 "John McLean" <mcleanj@dplanet.ch> wrote in messageI$ news:3BCDE6C8.C2F1FAF9@dplanet.ch...   > E > BTW, I love the continuous claims that the transition from Alpha to G > Intel should be seamless.  Is this a reassuring comment to customers,NC > one that is supported by facts, or is it wishful thinking that it<5 > "should" (but possibly won't) be the way things go.V >O  K Methinks it all depends on what the meaning of the word "seamless" is. Note&H that Tandem did a CISC-to-RISC transition with minimal disruption to theH customer base. VAX to Alpha was more disruptive, but it was a reasonablyK successful transition nonetheless. (And would have been more successful had=F DEC managed the marketing, positioning, and phase-in more coherently.)   ------------------------------  % Date: Wed, 17 Oct 2001 23:40:35 -0400*- From: JF Mezei <jfmezei.spamnot@videotron.ca>D? Subject: Re: ES45 Announced as "UNIX server" - VMS absent again<, Message-ID: <3BCE4F30.65D2AFE3@videotron.ca>   "Terry C. Shannon" wrote:rM > Methinks it all depends on what the meaning of the word "seamless" is. Note J > that Tandem did a CISC-to-RISC transition with minimal disruption to theJ > customer base. VAX to Alpha was more disruptive, but it was a reasonablyM > successful transition nonetheless. (And would have been more successful hadiH > DEC managed the marketing, positioning, and phase-in more coherently.)    N VAX to ALPHA wasn't seen as such a dismal failure because it was overshadownedK by Digital dropping a large portion of the software portfolio that had madeaU VMS popular, so any porting failures were in fact blamed on DEC abandonning products.1  K Digital used the Alpha port as an excuse to drop its leadership position infM messaging for instance, by not porting Message Router and all the Digital and K 3rd party gateways that existed, not providing an upgrade path to its newer I Mailbus 400 product which never got off the ground, and forcing messaging-M customers to keep some vaxes in their network/cluster to handle the messaginglI portion that couldn't run on Alpha. At the very least, Digital could haveOX bowed out of the MTA business and made PMDF the official product for messaging backbone.  M This, of course, was the prelude which gave some paper ammunition to Bobby GQsE Palmer to dump email alltogether and force all Digital to start usingr/ Microsoft products for corporate email etc etc.     I Had the VMS engineers accomplished the same level of porting as the Apple2N engineers had done, Digital could not have used the VAX->ALPHA migration as anL excuse to drop so many products since VAX executables could have been run onI Alpha transparently by customers. Digital could have had all its productssO automatically ported to Alpha, leaving the marginal products in emulation mode.:  H There is much less software available on VMS now, so I guess the port toJ Itanium won't result in so many software apps not being ported. However, II suspect that much of the 3rd party freeware applications won't make it tonK IA64. If customers don't move to IA64, the apps they maintain won't move toe IA64.   K Compaq/HP has an uphill battle to convince VMS customers to want to move to!M IA64.  It isn't enough to provide the means to port (the engineer's job), youT> also have to make customers want to migrate (marketing's job).   ------------------------------    Date: 17 Oct 2001 14:13:32 -07001 From: charles_gilley@hotmail.com (Charles Gilley)f" Subject: Forcing alignment errors?= Message-ID: <a46e1a08.0110171313.4d9af349@posting.google.com>a  D Okay, I admit, it has been a few years since I had to deal with thisD issue.  However, I'm in an argument with someone and want to prove a; point about using the /nomember_align flag.  We have a huge:9 application with large #s of data structures of the form:y     struct _st   {l     char Date[6];s     char TestFlag[1];D     .      .=     .G   } TYPE_ST;     TYPE_ST AdataStructure;r  C   Now, in this data structure, we have liberal amounts of character B arrays that must result in alignment issues.  Well, I thought theyE would if we use /nomember_align.  However, the C compiler is happy onvC the alpha, and performance tests indicate that the contents of this<E structure are aligned.  This is driving me nuts... where am I missingc it?  Shouldn't this:  $    AdataStructure.TestFlag[0] = 'Y';  C be misaligned (not on a quad word boundary) and thus slow the alpha  down?<   chgc   ------------------------------  # Date: Wed, 17 Oct 2001 23:05:05 GMTe+ From: Ryan Moore <rmoore@rmoore.dyndns.org>D& Subject: Re: Forcing alignment errors?= Message-ID: <Pine.LNX.4.31.0110171558570.24669-100000@jaipur>f  H There isn't an alignment problem here.  Alignment means that the item is- at an address that is 'natural' for its size.e  & Quadword (8-bytes) on 8-byte boundary. Longword on 4-byte boundary. short on 2-byte boundary char on 1-byte boundary.  H TestFlag is a character array.  Depending on the Alpha chip you have, itD can't directly access a single character anyway.  So the compiler isD forced to do make code (probably in terms on logwords) to store yourJ value.  It doesn't matter what address the char is at.  It's 'slow' either way.  " Now, this would make a difference:  
 struct _st {I 	char Date[6];
 	int  foo; .i .3 .& }p  F It should make a different how quickly the computer accesses the 'foo'* element based on the /nomember_align flag.  % On 17 Oct 2001, Charles Gilley wrote:,  F > Okay, I admit, it has been a few years since I had to deal with thisF > issue.  However, I'm in an argument with someone and want to prove a= > point about using the /nomember_align flag.  We have a huge0; > application with large #s of data structures of the form:t >. >   struct _st >   {E >     char Date[6];e >     char TestFlag[1];7 >     .n >     .q >     .  >   } TYPE_ST; >  >   TYPE_ST AdataStructure;D >@E >   Now, in this data structure, we have liberal amounts of character D > arrays that must result in alignment issues.  Well, I thought theyG > would if we use /nomember_align.  However, the C compiler is happy on E > the alpha, and performance tests indicate that the contents of thiseG > structure are aligned.  This is driving me nuts... where am I missinge > it?  Shouldn't this: > & >    AdataStructure.TestFlag[0] = 'Y'; > E > be misaligned (not on a quad word boundary) and thus slow the alpha  > down?s >i > chgi >y   ------------------------------  # Date: Wed, 17 Oct 2001 19:14:36 GMTiB From: Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP>P Subject: Future VMS owners/plans, was:Re: More official info on Compaq/HP merger6 Message-ID: <wMkz7.33079$ev2.40206@www.newsranger.com>  J On 17 Oct 2001 16:08:16 GMT, in article <9qkadg$dro$1@joe.rice.edu>, Jerry
 Leslie wrote:i > ' >Alan Greig (a.greig@virgin.net) wrote:eF >: On Wed, 17 Oct 2001 14:01:27 +0100, Alan Greig <a.greig@virgin.net>	 >: wrote:1 >:A >: And it gets worse. Here is the Aberdeen groups recommendations:; >: concerning the Tru64 ports to Itanium and the VMS ports:> >:H >: "First, the port of Tru64 UNIX to Itanium should not be completed....G >: ...Second, the port of OpenVMS to Itanium should not be completed." 1 >:2 >: They do suggest that the NSK port be completed. >:I >: And this is the report that Carly has praised in press statements!!!!!s  H What I would like to know is how is this statement from Carly compatibleG with the recent announcement that Oracle products will be ported to VMSi	 on IA64 ?   F Perhaps the port of VMS to IA64 will be completed, but just not by HP.  L I am also trying to imagine how HP view VMS. To us in the VMS community it'sL as familiar and as viable as Windows is to other people, but I wouldn't mindI betting that in Carly's eyes it's viewed more along of the lines of "that29 obsolete thing been kept alive in some corner of Compaq".i  H >: I suggest Compaq staff press for a statement on Carly's praise of theH >: Aberdeen groups analysis when it contains statements like the above.  >:C >Note the reference to "migration path" in the following article..." >H5 >   http://news.cnet.com/news/0-1003-200-7460040.html E >   HP's Fiorina predicts smooth merger ride -  Tech News -  CNET.como >L [cut] H >   "I would not anticipate a huge distraction," she said. "You ought toI >   expect that very soon after the merger closes--a month--everyone willGJ >   know who their account team is and what their migration path will be."@ >                                                 ^^^^^^^^^ ^^^^ >AH >Given hints about VMS possibly running on IBM's PowerPC, IBM's apparentN >decision not to release AIX for Intel IA64, it wouldn't be much of a suprise 6 >for HP to kill off or sell OpenVMS, Tru64, and HP-UX. > I >IBM could be the buyer for VMS and/or Tru64 to have a platform for IA64. J >You think IBM might have had a represntative at Carly, Curly, and Craig's >"love in" 18 months ago ?   >N  H Actually, if VMS is to be sold, I wouldn't have as big a problem with itJ going to IBM, as I would with it going to other potential owners mentionedK in c.o.v (ie: Microsoft or CA), provided that IBM intended to market it and  not just run it down.   I I also wonder if VMS would have a more natural home at IBM instead of HP.    My reasons:   ' IBM _understand_ the enterprise market.   ? They don't have a problem marketing multiple operating systems.   M IBM is already associated with enterprise class systems, so any VMS marketingT' from them is going to be more credible.    Simon.  J PS: I would like to be positive and think that VMS does have a future evenJ if it may not be with HP. I don't think that Compaq/Oracle would have doneK (for example) the Oracle porting announcement if CPQ intended to retire VMS " instead of maintain it or sell it.   -- A; Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFP K In the task of removing Microsoft from the marketplace, I have discovered a E truly remarkable plan, but this signature is too small to contain it.    ------------------------------  % Date: Wed, 17 Oct 2001 20:44:13 +0100 % From: Alan Greig <a.greig@virgin.net>CY Subject: Re: Future VMS owners/plans, was:Re: More official info on Compaq/HP merger mergA* Message-ID: <3BCDDF8D.742EB113@virgin.net>   Simon Clubley wrote:   >RK > >: And this is the report that Carly has praised in press statements!!!!!  >TJ > What I would like to know is how is this statement from Carly compatibleI > with the recent announcement that Oracle products will be ported to VMSE > on IA64 ?R >(  J My guess is that Carly, if challenged, would say that she only referred inP general terms to the merger starting to get positive press and gave the AberdeenN Group report as an example and did not mean that she agreed with every word ofP it. She could hardly say anything else right now. The policy of DEC/Compaq seemsM to have been divide and conquer - that is don't alienate everyone at the same L time by telling them the whole truth. However it was always possible to readO between the lines with DEC and Compaq and I believe that is still true. ReadingmO between the lines (or in this case reading the actual lines) I am convinced theO# new HP will kill VMS *if they can*.N   >jH > Perhaps the port of VMS to IA64 will be completed, but just not by HP. > N > I am also trying to imagine how HP view VMS. To us in the VMS community it'sN > as familiar and as viable as Windows is to other people, but I wouldn't mindK > betting that in Carly's eyes it's viewed more along of the lines of "thatA; > obsolete thing been kept alive in some corner of Compaq".2 >   N Because people such as Carly have never used a real OS they probably genuinelyQ think we are all nuts and just haven't seen the light. I doubt for one second she - believes VMS to be in any way superior to NT.P  ' IBM _understand_ the enterprise market.s   >)A > They don't have a problem marketing multiple operating systems.  > O > IBM is already associated with enterprise class systems, so any VMS marketing") > from them is going to be more credible.S >O  P Indeed if HP/Compaq were to sell VMS I would hope it would be to IBM.  Ten years! ago I would have never said that.    >X > Simon. >_L > PS: I would like to be positive and think that VMS does have a future evenL > if it may not be with HP. I don't think that Compaq/Oracle would have doneM > (for example) the Oracle porting announcement if CPQ intended to retire VMSs$ > instead of maintain it or sell it. >   O Remember they only made that statement after they were continually pressured onNO why no statement had been forthcoming. Had that pressure not been put on then IsM doubt we would have seen such a statement. Also the Oracle statement does not>2 amount to a firm committment to port as I read it.  Q Compaq can't afford to kill off VMS now. They've got to keep up the appearance of"O keeping it alive and leave any decision to terminate the port to HP. That's why Q the more we pressure them now the more chance they can be boxed into a corner and P be forced to complete a full port and not just find a fudge to keep the military
 etc happy.  O If I were a 'sensitive' user with clout of OpenVMS right now I'd call Carly and P Curly in and do some straight talking. I would not talk to Marcello or Gorham as1 they will ultimately do what they are told by HP.o --
 Alan Greig   ------------------------------  % Date: Wed, 17 Oct 2001 18:11:33 -0400g- From: JF Mezei <jfmezei.spamnot@videotron.ca>>Y Subject: Re: Future VMS owners/plans, was:Re: More official info on Compaq/HP merger mergs, Message-ID: <3BCE0210.DDC7D5E7@videotron.ca>   Simon Clubley wrote:H > Perhaps the port of VMS to IA64 will be completed, but just not by HP.  M HP will not sell VMS as a viable operating system to a competitor. As long asrG VMS is able to generate profits even without marketing, then it will behM allowed to live. But as with before, no marketing and VMS won't get mentioned  in corporate presentations.   I What they may do is to doneate VMS and its engineers to Microsoft to help N shore up NT in the enterprise, justy like they donated the Alpha engineers andN IP to Intel. But if they do that, it will be don with some assurances that VMSM won't be marketed by the buyer (eg: buy only the IP and engineers, not the OSr and custoemrs).p  N Either way, VMS will continue to be supported for existing customers by HP forN a good number of years, with HP probably trying to convince those customers to5 migrate to NT once NT gauins sufficient capabilities.t   ------------------------------   Date: 17 Oct 2001 19:16:15 CDT= From: wayne@tachysoft.xxx.062469.killspam.00be (Wayne Sewell)b Subject: Re: Global symbol. Message-ID: <ccBJOMvKluA1@tachxxsoftxxconsult>  a In article <tsrfvq2d92m7ef@corp.supernews.com>, Michael Zarlenga <zarlenga@conan.ids.net> writes:h@ > Brian Schenkenberger, VAXman- <system@SendSpamHere.ORG> wrote:O > :>: You can also do an IF .NOT. $STATUS THEN WRITE SYS$OUTPUT "SOMETHING WENTh > :>: WRONG" >  > :>Wouldn't you want " > :>	if (.not. ($STATUS .and. 1))  > F > : Only if you like adding unnecessary processing to your procedures. >  > Unnecessary? > ) > Isn't any even $STATUS value a failure?t  J Yes, which is why the ".not. $status" works fine just the way the originalO poster said (which is also how help and the manual say to check $status, by the  way).e  M Only the low order bit is used to determine whether a value is true or false.aL Therefore your use of .and. to strip off everything but the low order bit is4 pointless because that's all it's looking at anyway.    L The .not. operator reverses all the bits in the value, including the one bit+ that is used for determining true or false.g       -- lO ===============================================================================mM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxs: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)LO ===============================================================================rH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------    Date: 17 Oct 2001 18:50:02 -0700- From: afeldman@gfigroup.com (Alan E. Feldman)e Subject: Re: Global symbol= Message-ID: <af1e4ce6.0110171750.6bfae6d5@posting.google.com>s  m "Syltrem" <syltrem@videotron.spammenot.ca> wrote in message news:<brjz7.69772$TW.367131@tor-nn1.netcom.ca>...pG > Boolean IF constructs like these work like an implicit .AND. 1 .EQ. 1b > N > IF X THEN is the same as IF X .AND. 1 .EQ. 1 THEN is the same as IF X .AND.1 > THEN [snip]  E The rules for the logical values of DCL symbols are documented in thed User's Manual:  
 [begin quote]VB Some operations interpret numbers and character strings as logical data with values as follows:   True e? A number has a logical value of true if it is odd (that is, thegF low-order bit is 1). A character string has a logical value of true if8 the first character is an uppercase or lowercase T or Y.   False A A number has a logical value of false if it is even (that is, theSD low-order bit is 0). A character string has a logical value of false? if the first character is not an uppercase or lowercase T or Y.n [end quote]   F Additionally, if a character string contains only numerals, then it isD treated as a number, which is why the value of $STATUS can by itselfC be tested for being True or False. IOW, $STATUS is True for successn" and False for all types of errors.  @ If you need to use $STATUS, I recommend using something like the
 following:  3 $ SET NOON  ! Used to disable the DCL error handlera0 $ <the DCL command you wish to test for success>A $ STATUS = $STATUS  ! Capture the value of $STATUS before it getss changed. $ SET ON
 $ IF (STATUS) ! $ THEN  ! Command was successful.1 $     <success code> $ ELSE  ! Command failed.r $     <failure code> $ ENDIF   D Rules for logical operations involving DCL symbols are also given inC the User's Manual (see the Chapter on using Symbols in DCL commandsh and DCL command procedures).  K > "Michael Zarlenga" <zarlenga@conan.ids.net> a crit dans le message news: & > tsrfvq2d92m7ef@corp.supernews.com...B > > Brian Schenkenberger, VAXman- <system@SendSpamHere.ORG> wrote:L > > :>: You can also do an IF .NOT. $STATUS THEN WRITE SYS$OUTPUT "SOMETHING >  WENTp > > :>: WRONG" >  b > > :>Wouldn't you wants# > > :> if (.not. ($STATUS .and. 1))p > >  nH > > : Only if you like adding unnecessary processing to your procedures. > >t > > Unnecessary?   Yes. See above.r  + > > Isn't any even $STATUS value a failure?r  8 Yes, but IF .NOT.$STATUS is still sufficient. See above.   [snip]   Disclaimer: JMHO Alan E. Feldman  afeldman&gfigroup.com    ------------------------------  # Date: Wed, 17 Oct 2001 18:15:42 GMT * From: "Bill Todd" <billtodd@metrocast.net>/ Subject: Re: Higher prices for Alpha processorsa> Message-ID: <iVjz7.9921$_h.563082@bin4.nnrp.aus1.giganews.com>  0 Alan Greig <a.greig@virgin.net> wrote in message2 news:nbkqstgur2mei6ibshmcjotl76f5auiq7t@4ax.com...   ...m   > Bill,e >pB > I think it is about time to repost this. Fancy doing so? I don'tD > appear to have the final document immediately available although IH > know I have it at home. Anyone else with a copy (or who can find it in1 > a newsgroup search) feel free to post it again.   K Well, the following is the latest draft I can find, and should be identicalo+ to or at least very close to the final one:        May 14, 2000     Michael Capellas Chief Executive Officere Compaq Computer Corporation    cc:  Richard Marcelloa     Dear Mr. Capellas:    E We are an international group of computer industry professionals withfI diverse backgrounds who have recently banded together to discuss concernshJ about Compaq's relative neglect of its OpenVMS operating system.  Our hopeJ is that a coherent presentation at the highest level may be more effectiveJ in communicating the adverse effects of such neglect than the constant but9 muted customer rumbling that has occurred over the years.   K We appreciate your time and attention and will try to be concise.  In turn,tI we hope you will be tolerant of the level of occasionally-blunt detail we L deem necessary to break through long-standing barriers to changes in the wayJ OpenVMS has been handled.  It appears that some such changes may be takingG place even as we speak:  please do not mistake our attempt to present aeK complete picture for any lack of appreciation for the efforts already underl way.  J Our own discussions have ranged more widely and deeply than can reasonablyJ be presented here.  Should you find the following material useful and haveH interest in further contact, we would be happy to talk with you or other appropriate parties.     Sincerely yours,  ( <names excised to protect the still-shy>  > plus several contributors who have elected to remain anonymous       Part I:  Why OpenVMS?  Why Now?t     OpenVMS's Role Within Compaq  D There may be a natural tendency to concentrate on the intense directG competition that the rest of Compaq's products face with their external I look-alikes and an understandable reluctance to risk disrupting OpenVMS'saK significant and at least relatively uncontested revenue stream.  If so, the I view inherited from Digital that OpenVMS is a 'legacy' system nearing its L twilight years likely reinforces any inclination to leave well enough alone.> However, such treatment ignores the role OpenVMS could play inD differentiating Compaq from vendors such as Dell, Sun, and HP, whoseJ offerings consist primarily of commodity Windows and Unix products, and inK placing Compaq on equal footing with IBM, which currently does a far betters2 job of leveraging the full breadth of its systems.  E OS/360-370-390 is a respected 36-year-old architecture that remains aaK leader, despite running on limiting 32-bit hardware, and IBM has taken full K advantage of it over the years as it explored additional markets with newer K products.  OpenVMS was once a similarly respected system but is now largely I ignored, despite running on arguably the fastest and most scalable 64-bitrG commercial hardware in the world, because Digital decided long ago that I 'non-proprietary' systems were its future and did its best to convert itsh$ existing customer base to their use.  F Since it remains impossible to forecast when, if ever, Unix (let aloneF Windows) will be able to adequately replace OpenVMS (or OS/390), IBM'sH strategy of integrating its proprietary crown jewel seems to have provenH superior to Digital's strategy of replacement.  Unfortunately, corporateF decisions of such a fundamental nature carry with them a great deal ofF inertia, not least because admitting failure can compromise high-levelI careers, and that inherited inertia apparently continues to influence the0. attitude of Compaq toward OpenVMS to this day.     But OpenVMS is so Proprietary$  D So are OS/390 and OS/400 - perhaps more so, if one includes hardwareK multi-sourcing considerations.  And while customers and third-party vendorsvE do gravitate toward the familiarity and increased vendor-independencegL offered by Unix or Windows solutions when such solutions satisfy their needsF cost-effectively, when this is not the case they still readily turn toE full-service vendors for 'proprietary' solutions as long as they haveeI confidence that the vendor, and the solution, will continue to meet their  requirements over time.   F Despite over a decade of marketing neglect, OpenVMS has maintained itsJ technological leadership and remains superbly qualified for this role.  ItJ is significantly superior to any commonly-used Unix (let alone Windows) inH the areas of reliability, availability, scalability, disaster-tolerance,J security, near-real-time activities (e.g., process control), I/O-intensiveG workloads, record-oriented processing, and mixed-language applications.nC Other notable strengths include ease of administration, support for > application development, and performance/operating efficiency.  J Given the degree to which expectations have been lowered over the years byL Windows and Unix and their associated hype, we feel a need to emphasize thatG these distinctions are real.  OpenVMS can credibly claim to be the mosttH scalable system on the planet:  it is suitable for the smallest start-upL operation, yet can never be outgrown.  It has levels of security found in noK other commercial operating system, clustering technology that remains yearssK ahead of any competition, and a degree of fault-tolerance and resistance touJ error that allows OpenVMS to be used in mission-critical systems that mustI stay up for years at a time (the longest we know of is 17 years without al5 reboot in the service of the Irish National Railway).o    $ OpenVMS as The Compaq Differentiator  J Sole ownership of OpenVMS gives Compaq the ability to react quickly to newF customer needs and attract business by offering features that Unix andH Windows environments cannot match (see above).  Customers dependent upon> unique OpenVMS features become tied to Compaq to a degree thatG 'non-proprietary' customers are not - a healthy relationship as long as L Compaq views it as symbiotic rather than exploitative.  Combine this lock-inH with the common desire, especially among large customers, to deal with aJ single vendor, and other vendors who lack such soup-to-nuts range in theirJ product sets become second-class contenders in a significant percentage of sales situations.r  K IBM has long used its OS/360-370-390 architecture to anchor the high end ineJ such situations and the niche solutions supported by its OS/400 systems toE anchor its presence in other environments.  If Compaq can demonstratetG effectively that it now views OpenVMS as a core asset rather than as antL aberration in its product line-up, OpenVMS can once again become the kind ofL keystone that clinches corporate-wide standardization on a single vendor and5 stabilizes, rather than frustrates, customer loyalty.F  I Ideally, all of Compaq's systems should be able to win sales on their own @ merits.  However, the intense competition for advantage in IntelJ Architecture hardware platforms (including IBM's OnForever robust hardwareH and X Architecture heterogeneous clustering initiatives), the continuingL apathy toward Tru64 in the Unix market, and the partnerships Dell has formedL to sell servers and server-appliances and to counter its weakness in serviceI and support are only a few of the factors conspiring to make it difficultIG for Compaq to hold the Windows and Unix ground it already occupies, lethF alone gain any.  Linux may change the nature of the Unix playing fieldC somewhat, but here again competitive pressures are strong, with IBMaG committing to support Linux environments on all its systems - includingiK OS/390 and OS/400 - as well as positioning S/390 systems as general-purposeh2 servers (an important AlphaServer market segment).  H A highly-visible renewed commitment to OpenVMS is one of the few ways inL which Compaq can differentiate itself to gain entry into and/or advantage inK corporate sales situations for all its products.  It is also an opportunityhL to break the long-standing stranglehold that industry doubts about OpenVMS'sC future have held on one of Compaq's highest-margin revenue streams.   @ The sections below outline some of the current obstacles to suchH revitalization and suggested remedies for them.  Since we recognize thatG Compaq has a great deal of experience in how to market products that itmJ wants to market, most of this discussion is presented in abbreviated form,2 which we would be happy to expand upon if desired.       Part II:  Problems/Remediesi     Advertisinge  K Unless Compaq puts its money where its mouth is, no one is going to believedC that a renewed commitment to OpenVMS is any more real than previousvE temporary blips on the otherwise blank radar screen.  How much money? I Compare the net profit generated by PC and Industry-Standard Server sales H and service to that generated by OpenVMS sales and service.  Now compareI their respective ad budgets, in all media (not including AlphaServer ads:nL they almost never mention OpenVMS save as an afterthought to a Tru64 pitch).  J While that provides a first approximation of the degree of change requiredK for credibility, OpenVMS may not need nearly as much general advertising asnL long as it has industry advertising comparable to Windows'.  For a start, itA needs something like two-page "OpenVMS Advantage" ads in the sameiJ publications (and with the same frequency) as the "Windows 2000 Advantage"H ads so that not only the OpenVMS name but detailed information about itsK capabilities will reach the people who approve corporate purchases, as welluL as those who recommend them.  (We understand that the Windows 2000 AdvantageI ads are shared with Microsoft, but many of Compaq's other Wintel platformd
 ads are not.)c  I OpenVMS advertising needs to emphasize the OpenVMS strengths (see earliereK list) that other systems, including Compaq's, lack, just as advertising for J other Compaq systems emphasizes their own perceived strengths (such as theE recent UK ad headlined "Nothing integrates better with NT than TRU-64oK UNIX" - ahem).  This is difficult to do tactfully when an ad is shared withOL other Compaq systems, though ancillary, less specific shared advertising canK be effective too as long as the systems are featured equally.  OpenVMS alsorL needs to be advertised to the rest of Compaq's current customers in the same? manner other Compaq systems are advertised to the OpenVMS base.e  I Additional specialized OpenVMS advertising is warranted in markets deemedoK especially receptive to OpenVMS - certainly the current 'target market' setoB plus any environment (e.g., Web services of all kinds) requiring aK highly-available, highly-scalable, and/or highly-secure platform.  However,oK it is important not to perpetuate the impression that those markets are theeL only areas in which OpenVMS is actively competing:  a system perceived to beK holed up in a few remaining strongholds is not one corporations will choose H to commit to for the next decade or more.  Less concentrated but visibleK specialized advertising in any market segment where OpenVMS can effectivelytF compete will provide important reassurance of Compaq's dedication to a* strategy of broad-based, long-term growth.  J All the above won't begin to use up the amount of money suggested above asK necessary for credibility, but it will at least be a good start.  It likelyhJ has more directly-measurable benefits than generic 'brand awareness' printG and television advertising (though the competition does not shrink from I funding this).  And it should provide initial evidence suggesting whethera) further increases would prove profitable.e     Web InformationA  L Once people are made aware of OpenVMS, it is imperative that they be able toG find out virtually anything they may want to about it easily, includingmE information about purchasing and pricing, available applications, and I up-to-date benchmark results (a critical factor in some sales).  While wenJ recognize that Compaq has been working hard to improve OpenVMS informationH accessibility via the corporate Web site, we have yet to see anything toF suggest that the desired result will appear in the foreseeable future.  H There are too many examples of Web-site problems even just to list here,G which leads us to suspect that the underlying issue may be structural -eF perhaps a result of over-centralization of content-control rather thanA leaving it in the hands of the people best equipped to present iteC effectively (under suitable overall corporate look, feel, and tastehI guidelines), un-muddled by frequent inter-mixing of references to Windows J and Tru64.  Whatever the cause, prompt action is important, and once again< we would be happy to offer detailed suggestions if asked to.    ( Corporate Publications and Presentations  L While the decidedly inadequate OpenVMS Web presence may merely be the resultG of corporate ineptitude, the consistent disregard for OpenVMS in CompaqnK publications and presentations that glowingly showcase Windows, Tandem NSK,=G and Tru64 presents the disturbing appearance of an active conspiracy of  silence.  When  E Compaq's Annual Report fails even to mention OpenVMS in its corporate-F narrative despite an 'unstoppable' theme that OpenVMS fits better than anything else save NSK,e  K the January Investor Relations presentation by Enrico Pesatori is similarly. silent,m  I the Inform corporate newsletter presents a 'success story' without noting.# that the platform used was OpenVMS,p  K the Compaq Non-Stop eBusiness Strategy white paper treats OpenVMS more like @ SCO Unix and NetWare than like Compaq's other main-line systems,  A the set of AlphaServer Web links is overwhelmingly Tru64-related,C  K it conveys a definite message to both existing and potential customers thatiF OpenVMS is not a priority for Compaq.  No competitor could instill theH degree of 'Fear, Uncertainty, and Doubt' about OpenVMS that Compaq's ownL actions (and Digital's before it) have:  pervasive, long-term change will be necessary to erase it.     Sales   J Similar FUD regarding OpenVMS has been generated by the persistent effortsJ of the sales force to encourage happy OpenVMS customers to migrate to someI other Compaq platform.  We hope that recent rumors of change in this areaeI are true:  not only does it tend to lose Compaq entire corporate accountssI (if they migrate, it is often to a competitor), but it's really annoying.$  K We also have anecdotal evidence that when OpenVMS is being considered for aoL new installation, along with some other Compaq system, failure to pursue theL OpenVMS option often results in loss of the entire sale to some other vendorL (e.g., OpenVMS was competitive due to its unique qualities whereas Tru64 was not).S     Press Relations   G Compaq does a commendable job of releasing information about its PC and H Industry-Standard Server offerings and a more modest but adequate job ofE releasing information about AlphaServer hardware and Tru64 Unix.  ButsI (again) there is only silence where OpenVMS is concerned, and as a resultrE media coverage routinely categorizes OpenVMS as 'aging', 'legacy', orMC 'defunct' (all have appeared recently).  A bit of targeted personals= schmoozing might also help:  the return could be substantial.e     Application Availability  J The fact that customers often choose an application and only then choose aG hardware platform means that system sales can often be dependent on thesE range of available applications - an area in which OpenVMS has becomeaK seriously deficient.  Visible renewed commitment by Compaq to OpenVMS saleseL across the full market spectrum will start to encourage Independent SoftwareL Vendors and Value-Added Resellers to make applications available on OpenVMS.I Even minor additional effort specifically aimed at courting and educating E ISVs and VARs could achieve disproportionate results.  For especiallycH strategic applications, consider providing hardware, consulting, or even financial aid.  K Examples of enterprise applications not available in their current versionssF on OpenVMS include SAP, Oracle Applications, Baan, Peoplesoft, Sybase,C Informix, DB2, MS SQLserver, Netscape Server Suite, Lotus Notes, MSIL Exchange, MS IIS, Squid, MS Office, Corel Office, Lotus Smartsuite, and StarH Office.  The much shorter list of such applications that are available -F Oracle, Oracle RDB, PMDF, and Apache - does not compare favorably with competing platforms.     New Product Features  I Published road maps for OpenVMS development do not present a picture of a K system committed to continued leadership of the kind it enjoys today.  This K makes knowledgeable customers hesitant to commit their own operations to it G for the long term.  Targeted new development can also be a real bargainaI compared with other promotional mechanisms, and we offer two examples fore consideration:  K The currently-defunct OpenVMS POSIX environment originally gave rise to thetL 'Open' in OpenVMS.  We have heard that efforts are under way to resurrect itE in a more usable form, with better performance and one hopes improvedvK integration with the native environment (i.e., much more than just a 'checknG the box' facility).  Extension to allow it to run many/most Alpha LinuxlG binaries on OpenVMS would not only help make a large library (1200+) ofsK sorely-needed applications instantly available but would match IBM's 'Linuxc everywhere' strategy (see L http://www10.nytimes.com/library/tech/00/03/biztech/articles/20soft.html andF http://www.redherring.com/insider/2000/0503/tech-ibmlinux050300.html -G interesting reading in multiple respects).  An efficient and integratednK Linux persona coupled with the existing strengths of OpenVMS would create aa# platform unequaled in the industry.o  F A second initiative which would mesh nicely with such Linux support isB development of a heterogeneous SAN file system to allow concurrentK data-sharing across OpenVMS, Windows 2000, and Unix/Linux.  Though IBM, HP,SK Veritas, EMC, Adic, Avid, and likely others have products in this space, iteJ remains an area where no one yet appears willing to make the commitment toH do the job right.  This represents a leadership opportunity that Compaq,K with its expertise across OpenVMS, Tru64, and NT environments, is unusually K well-positioned to avail itself of.  It also offers improved integration ofeG heterogeneous systems within single Wildfire boxes, dovetails well withaL Compaq's strengths in lower-level storage architecture, and protects againstI industry standardization on some competitive implementation that does note include OpenVMS and Tru64.     OpenVMS in Academiaf  H We applaud rumors of a recent decision to offer free OpenVMS licenses toK academia.  In combination with existing free academic cluster licensing, iteH should help stimulate use of OpenVMS in areas long ago lost to free Sun, *BSD, and Linux configurations.p  G While we cannot prove it, we suspect that the decline of OpenVMS in the L marketplace is at least in some small part attributable to its disappearance? from academia (where it once reigned supreme) and its resulting I unfamiliarity to the current generation of purchasers, users, and supportrC personnel.  If so, additional efforts in this area (e.g., strategictL applications and video and/or on-line tutorials that could be used as course adjuncts) could prove fruitful.i     Entry-Level System Pricing  G Aggressive pursuit of entry-level sales (like attention to academia andaJ serious on-going development) tends to reassure customers about a vendor'sI long-term commitment to a system, since there is little immediate, directoC payoff for the effort expended.  One of our members stated it thus:n  J "Without seeds, you don't get seedlings.  Without seedlings, you don't getK new trees.  A huge, elegant, mature tree surrounded by asphalt and concreteaL and maintained lawn and pretty little flowerbeds in a city square is a dyingL tree.  In contrast, a patch of fertile land covered in nondescript scrub can( be a forest of such trees in the making.  K "I think people may appreciate this at an instinctive level.  No OpenVMS iniH colleges, no small OpenVMS sites, no affordable low-end OpenVMS, means aG dying operating system, and the only question is how long the remaininge trees will stand for."  F We will not presume to suggest what Compaq's trade-off between low-end@ profit and market penetration should be, but offer the following observations for consideration:   F The low-end market is especially sensitive to the relationship betweenF hardware and system software price.  This suggests making at least theG system software price platform-specific rather than shared across, say,oG DS10s, DS20s, and ES40s (or a new sub-DS10 platform should one appear). L Pre-packaged 'cluster in a box' configurations and volume discounts starting@ at quantity 2 for multi-box sales might also stimulate interest.  K The price of an entry-level OpenVMS system will inevitably be compared withnI Windows 2000 Server or Windows 2000 Advanced Server (the latter includingrJ primitive clustering support).  Given the superior capabilities of OpenVMSH and the fact that entry-level DS10 hardware costs about twice as much asL good-quality Intel hardware, one can justify pricing a DS10 OpenVMS softwareD configuration at about twice the level of a similar Windows software configuration.  G Price it much higher than that level, and even OpenVMS enthusiasts willoK start to question its value; price it noticeably lower, and the market willoJ perceive it as aggressive.  In this context, note that Windows 2000 ServerH and Advanced Server include features such as TCP/IP and other networkingG support, disk defragmentation, and volume shadowing that are extra-costnE options in OpenVMS and should thus be added before comparing pricing.aH Furthermore, Windows system prices are typically discounted when bundled with a hardware sale.t      
 Conclusion  I Because OpenVMS has suffered years of neglect compared with other DigitalaI and competing systems, temporary compensatory efforts may be necessary todG let the world know in no uncertain terms that OpenVMS is not only still K alive but hunting for bear.  We otherwise suggest that all Compaq platformspI will have the best chance of realizing their potential if they attempt toiJ exploit their mutual synergy (a strategy that IBM embraces whole-heartedlyL within its own product set) rather than partition themselves into boxes thatG at least some customers will not find to their liking.  In the process,eF Compaq will return to a business model that served Digital well at theJ height of its success - and be seen as more responsive to its customers as well./   ------------------------------  % Date: Wed, 17 Oct 2001 12:06:10 -0700e+ From: Mark Crispin <mrc@CAC.Washington.EDU>n/ Subject: Re: Higher prices for Alpha processorsnV Message-ID: <Pine.NXT.4.41.0110171126270.13392-100000@Tomobiki-Cho.CAC.Washington.EDU>  & On Wed, 17 Oct 2001, Alan Greig wrote:E > wsmr-simtel20.army.mil was one of the last holdouts but even ".mil"  > couldn't save it from DEC,   DEC had nothing to do with it.  J Speaking as someone who was there, SIMTEL20 was killed by a combination of factors:1  1) perceived costs of ownership and maintenance.rL  2) perceived irrelevance, inappropriateness, and illegality of the archive.K  3) perceived superiority of AT&T 3B2 systems as "modern" Internet engines. D  4) politics.  The less said about this, the better; the individualsK     involved are now retired.  Let's just say that in government, includingaJ     military, one of the well-used ways to get at someone you loathe is to/     attack his subordinates and their projects.   D Note my usage of the word "perceived".  We are not talking about theD perceptions of anyone involved with SIMTEL20.  Consider how item (4) interacts with perception.  H SIMTEL20 suffered a mortal wound over a year before the plug was finallyI pulled.  It was not a happy time.  The SIMTEL20 archivist, and especiallyyI the fellow who was the heart and soul of the SIMTEL20 TOPS-20 system frompA its inception, bore the brunt.  I have evil memories nonetheless.   H I ensured that all the email queued on SIMTEL20 was passed on before theI plug was pulled.  SIMTEL20's last act before the electrons ceased flowingSJ was to foist the last queued but undeliverable message (due to destination; host down) onto one of the "modern" 3B2s which replaced it.u  J It is amazing that the archive didn't die, since that was one of the goalsH of shutting down SIMTEL20.  At least in that respect, the bastards lost.  I There is a lot more to this story than I am telling here, but you'll haveh to hear it from someone else.   
 -- Mark --   http://staff.washington.edu/mrceF Science does not emerge from voting, party politics, or public debate.   ------------------------------  % Date: Wed, 17 Oct 2001 21:00:26 +0100o% From: Alan Greig <a.greig@virgin.net> / Subject: Re: Higher prices for Alpha processorsn* Message-ID: <3BCDE359.FE81D17B@virgin.net>   Mark Crispin wrote:S  ( > On Wed, 17 Oct 2001, Alan Greig wrote:G > > wsmr-simtel20.army.mil was one of the last holdouts but even ".mil"i > > couldn't save it from DEC, >v  > DEC had nothing to do with it. >p  N Mark, I was referring to military use of TOPS-20 not being suffficient to saveN *TOPS-20* from DEC. Not save SIMTEL20 itself. Earlier in this thread, before IK added the crossposting, someone had stated that Compaq could never kill VMSnK because it was used by the military. I just picked SIMTEL20 as a well knowneP example of a site with a ".mil" domain which survived into the relatively recent
 Internet age.    >tL > It is amazing that the archive didn't die, since that was one of the goalsJ > of shutting down SIMTEL20.  At least in that respect, the bastards lost. >   O Presumably the old DUMPER tapes survive. Just to mark a bit of Arpanet/InternetrP history it would be nice to bring up the SIMTEL20 archives on an emulated PDP-10N and make it available online. Someone would have to rebuild a KS-10 version ofP TOPS-20 with Internet support though as the currently booting TOPS-20 V4.1 KS-10G distribution doesn't have Arpanet support built in. Do you still have a L buildable KS-10 distribution by any chance? Was there ever an official KS-10L distribution with Arpanet support or was that limited to KL-10 distributions only?s   >sK > There is a lot more to this story than I am telling here, but you'll have  > to hear it from someone else.e >l > -- Mark -- >r! > http://staff.washington.edu/mrctH > Science does not emerge from voting, party politics, or public debate.   --
 Alan Greig   ------------------------------  # Date: Wed, 17 Oct 2001 20:40:27 GMTe* From: "Bill Todd" <billtodd@metrocast.net>/ Subject: Re: Higher prices for Alpha processors ? Message-ID: <%0mz7.523698$Lw3.31937355@news2.aus1.giganews.com>i  > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote in message+ news:wahz7.592$RL6.5300@news.cpqcorp.net...r >u+ > david20@alpha2.mdx.ac.uk wrote in messagee" <9qjot9$mho$1@aquila.mdx.ac.uk>...   ...o  K > >For Microsoft to support Hammer with its 64bit version of its windows OSn > >should be relatively simple. L > >The HAL makes running descendents of the NT operating system on different > >platforms relatively easy.e > >m >  >r7 > Heck, Alpha ran NT.  But that didn't make it succeed.t  G One has to wonder whether the situation might have changed had a usablemF version of Star Office been available even as recently as 2 years ago.     If Microsoft givesK > it's full support to it, then it will live, otherwise the 64-extension ofe > Hammer will be useless.t  K My point above is that a usable (6.0, though still in beta) version of StarcJ Office apparently now *does* exist.  This means that if Microsoft supportsK Hammer *at all* (e.g., OS-only support, as was the case with Alpha), it can L be a far more usable general-purpose platform than Alpha was - especially asL it can run all *existing* IA32 applications at native speeds (including, one- should note, 32-bit Microsoft Office itself).g  /   If MS throws itself into Itanium, it forces aa churnh > of the 32-bit software.c > K > >The presence of AMDs 32bit chips will mean that it is extremely unlikelyp > IntelVH > >could just stop producing IA32 chips. Intel ceding the desktop to AMD wouldh4 > >be even more stupid that Compaq's recent actions. > >f >s >bI > Why?  All MS has to do is start producing 64-bit Itanium products, with  thehJ > new features, play some licensing games to make the 32-bit stuff (now inH > maintenance mode) more expensive, and you get a 3-5 year transition toC > Itanium with the added bonus that you get to sell more SW and HW.   F Only if Microsoft has no competition (such as Star Office) that offersJ compatibility with those new features.  *And* only if Microsoft is willingL to gamble that people will accept such coercion to change hardware platformsD in preference to changing OS platforms (remembering that changing OSJ platforms to something compatible with existing 32-bit Microsoft offerings) will become easier and easier over time).o  K Significant percentages of users are already starting to consider alternateaF platforms because of Microsoft's new licensing schemes and attempts toJ extend its tentacles around the Internet.  Use of such alternate platformsE is becoming increasingly feasible, and Microsoft is clearly concernedpL (witness its recent public condemnations of open-source software).  This mayI well not be a time when they feel secure enough to abandon their existingyA user base in an attempt to force it onto completely new hardware.w   >eL > MS could easily say "we will put all our software on Itanium" and tell AMDL > that they can pay them if they want support for specific layered products.0 > Look at how little MS did for (free on) Alpha.  J It could be well worth it to AMD to fund such support, since it could wellK be their stepping-stone to replacing Intel as the dominant Windows hardwarel? platform.  Hell, it might even have been worth doing for Alpha.t   - bill   ------------------------------  % Date: Wed, 17 Oct 2001 17:23:16 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>a/ Subject: Re: Higher prices for Alpha processorsr, Message-ID: <3BCDF6C2.E6DEB3AE@videotron.ca>   Fred Kleinsorge wrote:@ > >There is no need for 64 bit on the desktop for maybe 5 years. > K > The job for Microsoft and Intel is to drive that need.  Most people don'trL > "need" 1.5GHz systems, my 266MHz PII does a fine job on almost everything.. > But it is being forced to be obsolete by MS.  K Actually, perhaps not the office desktop, but the home desktop needs the 64aJ bits, wide data paths and all the speed it can get to play the video games) that have real time 3d rendering engines.f  J Had Digital wanted high volumes for Alpha, it would have truck a deal withE Nintendo or Sega. And if neither Nintendo nor Sega wanted Alpha, thenqL Microsoft would have used it for its X-BOX to have technological superiority to its competitors.i  K And as far as office machines, I think that videoconferencing (aka: CUseeme I and MS's proprietary equivalent) may eventually start to consume a lot ofeE resources when you start transmitting better quality and large video.c   ------------------------------  % Date: Wed, 17 Oct 2001 17:53:25 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>e/ Subject: Re: Higher prices for Alpha processorsm, Message-ID: <3BCDFDD1.E223A811@videotron.ca>   david20@alpha1.mdx.ac.uk wrote:aQ > (or bloatware) are not worth having. If for instance Microsoft were to make theaN > 64 bit version of word incompatible with the version available on the 32 bitO > systems then most corporations would stick with the 32bit version since to doiM > otherwise would cost them a fortune in the midst of a recession as they are / > forced to replace all their hardware at once.n  L Look at what happened between Windows 3.1 and Windows 95/NT. People switchedK because of social pressures, marketing, but also because they wanted to getc- out of that indecent DOS/Windows combination.o  L Windows 98/2000/ME/XP/whatever were just incremental changes. No pressure to) do a corporate-wide upgrade for desktops.   K However, imagine the scenario where Windows-** on IA64 servers provides allnM sorts of nifty LAN management features which won't be available on the 32 bit I version. That will provide some incentives for corporations to move theirSG servers to 64 bits, and eventually their desktops when prices make IA64e commodity (if it ever happens).a    M The big question in my mind is the sort of incestual relationship that exists M between Microsoft and Intel. If Intel has a deal with Microsoft, then you candN be assured that Microsoft will take whatever decisions needed to make IA64 the& de-facto standard and kill off Hammer.   ------------------------------    Date: 17 Oct 2001 17:16:38 -0500 From: rivie@cougar.no.domain/ Subject: Re: Higher prices for Alpha processorss3 Message-ID: <slrn9ss1a4.10c.rivie@cougar.no.domain>   < In article <3BCDFDD1.E223A811@videotron.ca>, JF Mezei wrote: > N > Look at what happened between Windows 3.1 and Windows 95/NT. People switchedM > because of social pressures, marketing, but also because they wanted to get / > out of that indecent DOS/Windows combination.s  H The DOS/Windows combination in Windows 95 is every bit as indecent as it& is in Windows 3.1, it's just prettier. --
 Roger Ivie ivie@cc.usu.edu     > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----A http://www.newsfeeds.com - The #1 Newsgroup Service in the World!b> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----   ------------------------------  % Date: Wed, 17 Oct 2001 22:44:20 -0000p From: sword7@speakeasy.org/ Subject: Re: Higher prices for Alpha processorsn/ Message-ID: <tss2e4ncg4rif3@corp.supernews.com>d  7 In alt.sys.pdp10 Alan Greig <a.greig@virgin.net> wrote:gQ > Presumably the old DUMPER tapes survive. Just to mark a bit of Arpanet/InternetiR > history it would be nice to bring up the SIMTEL20 archives on an emulated PDP-10P > and make it available online. Someone would have to rebuild a KS-10 version ofR > TOPS-20 with Internet support though as the currently booting TOPS-20 V4.1 KS-10I > distribution doesn't have Arpanet support built in. Do you still have awN > buildable KS-10 distribution by any chance? Was there ever an official KS-10N > distribution with Arpanet support or was that limited to KL-10 distributions > only?,   Alan:a  F Yes, I am aware of that because I downloaded some files from SIMTEL20 G system some time ago.  After SIMTEL20 was shut down, all archives were eK moved to somewhere.  I was BITNET user some time ago and e-mailed requests sH to SIMTEL20 to send me files.  When archive-server was shut down, I had I sent messages to one of BITNET nodes to send me files.  I finally got my aK Internet account (gallux.gallaudet.edu) in rest of my college life.  I was I7 able download some files from SIMTEL20 via FTP program.n  K My development version of TS10 emulator has complete KL10 emulation.  KL10 ,K TOPS-10 system successfully was loaded and run on my TS10 emulator.  DTE20 aJ communications are not completely yet because I have to develop PDP-11/40 . emulator to support KL10 emulator cocurrently.  K About VAX emulator module, I now am implementing disk/tape drives for MSCP eF controller.  A dot is much closer.  Opps! I mean a dollar because VMS > always use a dollar on VMS prompt as a dot on TOPS-10 promopt.  F I found MSCP information in TOPS-10 v7.03 sources.  Check MSCSER.MAC, D MSCPAR.MAC, SCASER.MAC, and RAXKON.MAC for more information.  Kevin F provided me a copy of his code and I learned that some are missing in G NetBSD files.  TOPS-10 v7.03 sources has more complete information and  J documentation about MSCP communications for HSC50 controller and RA60 and F RA81 disk drives.  After I studied NetBSD files about MSCP, I clearly F recongized TOPS-10 files has more complete information.  For example, I unit flags are not defined in Online End message but MSCPAR.MAC mentions  ! unit flags in Online End message.l   -- Tim Stark   -- r, Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------    Date: 17 Oct 2001 16:17:23 -0700, From: David Masterson <dmaster@synopsys.com>/ Subject: Re: Higher prices for Alpha processorse( Message-ID: <uwv1tluv0.fsf@synopsys.com>   >>>>> JF Mezei writes:  F > Actually, perhaps not the office desktop, but the home desktop needsC > the 64 bits, wide data paths and all the speed it can get to playt; > the video games that have real time 3d rendering engines.a  B > Had Digital wanted high volumes for Alpha, it would have truck aE > deal with Nintendo or Sega. And if neither Nintendo nor Sega wantedo@ > Alpha, then Microsoft would have used it for its X-BOX to have/ > technological superiority to its competitors.a  - Aren't Nintendo and Sega already at 128 bits?o   -- w: David Masterson                dmaster AT synopsys DOT com- Sr. R&D Engineer               Synopsys, Inc.o, Software Engineering           Sunnyvale, CA   ------------------------------    Date: 17 Oct 2001 16:24:52 -0700, From: David Masterson <dmaster@synopsys.com>/ Subject: Re: Higher prices for Alpha processorst( Message-ID: <usnchluij.fsf@synopsys.com>   >>>>> david20  writes:  C > If for instance Microsoft were to make the 64 bit version of wordiD > incompatible with the version available on the 32 bit systems thenB > most corporations would stick with the 32bit version since to doD > otherwise would cost them a fortune in the midst of a recession as8 > they are forced to replace all their hardware at once.  @ Incompatible how?  There were a lot of incompatibilities between@ Word97, Word98, and Word2000.  Many companies had to keep Word97A around until they could get all their desktops converted to W2000hF because the claimed "backward-compatibility" wasn't.  The advantage ofD being a big monopoly is that Microsoft could ignore all the "little"E company's complaints long enough that they would be forced to upgradeu2 (and everyone is a "little" company to Microsoft).   -- u: David Masterson                dmaster AT synopsys DOT com- Sr. R&D Engineer               Synopsys, Inc.e, Software Engineering           Sunnyvale, CA   ------------------------------   Date: 17 Oct 2001 23:53:18 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)e/ Subject: Re: Higher prices for Alpha processorsl, Message-ID: <9ql5le$2q2r$4@info.cs.uofs.edu>  + In article <9qjot9$mho$1@aquila.mdx.ac.uk>,v!  david20@alpha2.mdx.ac.uk writes:t |>P |> Intel and Microsoft ganging up to force a move to 64bit itanium would lead to |> the biggest DOJ case ever.,  N Microsoft has already tested those waters and found they have nothing to fear.   bill   -- rJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   s   ------------------------------   Date: 17 Oct 2001 23:56:40 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)n/ Subject: Re: Higher prices for Alpha processorsh, Message-ID: <9ql5ro$2q2r$5@info.cs.uofs.edu>  1 In article <wahz7.592$RL6.5300@news.cpqcorp.net>, 8  "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: |> nO |> david20@alpha2.mdx.ac.uk wrote in message <9qjot9$mho$1@aquila.mdx.ac.uk>...s |> >N |> >Intel and Microsoft ganging up to force a move to 64bit itanium would lead |> to  |> >the biggest DOJ case ever. |> > |>   |> o/ |> Not as long as the Republicans are in power.  |> c  B Short memory??  The Microsoft case was started and ended under theB Democrats.  By the time the Republicans got there the decision to B let them run roughshod over the industry had already been made andC with it all the precedent Microsoft will ever need remain powerful.a   bill   -- SJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   o   ------------------------------  # Date: Thu, 18 Oct 2001 02:00:56 GMTc2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>/ Subject: Re: Higher prices for Alpha processors)? Message-ID: <sJqz7.192398$Rb.6520384@sjcpnn01.usenetserver.com>n  , In alt.sys.pdp10 sword7@speakeasy.org wrote:M > My development version of TS10 emulator has complete KL10 emulation.  KL10 rM > TOPS-10 system successfully was loaded and run on my TS10 emulator.  DTE20 lL > communications are not completely yet because I have to develop PDP-11/40 0 > emulator to support KL10 emulator cocurrently.  G Ah, now this is the news I've been waiting for.  Have you tried running G TOPS-20 V7.0 on it?  Personally I'm not to worried, at this time, about C running TOPS-10 under KL10 emulation since we can do that on a KS105J emulator.  However, TOPS-20 is a different matter, and the V7.0 tapes look to be the most complete.  I What devices are you currently supporting on the KL10 emulation, and whats" devices do you plan on supporting?   			Zanei   ------------------------------  # Date: Thu, 18 Oct 2001 03:04:51 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>/ Subject: Re: Higher prices for Alpha processorse> Message-ID: <nFrz7.130329$vq.28847825@typhoon.ne.mediaone.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagek9 news:%0mz7.523698$Lw3.31937355@news2.aus1.giganews.com...l >o@ > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote in message- > news:wahz7.592$RL6.5300@news.cpqcorp.net..., > >e- > > david20@alpha2.mdx.ac.uk wrote in messageS$ > <9qjot9$mho$1@aquila.mdx.ac.uk>... >a > ...l >.J > > >For Microsoft to support Hammer with its 64bit version of its windows OS! > > >should be relatively simple.tD > > >The HAL makes running descendents of the NT operating system on	 differenti > > >platforms relatively easy.  > > >  > >o > > 9 > > Heck, Alpha ran NT.  But that didn't make it succeed.n >OI > One has to wonder whether the situation might have changed had a usableuH > version of Star Office been available even as recently as 2 years ago. >   K Yep. Which goes back to the original Alliance for Enterprise Computing dealdH announced on 3 August 1995. Had DEC not accepted Microsoft's first offerI (Intel-Alpha server-side apps parity, no client-side parity) things mightMI look very different today. No client apps for Alpha NT = not a snowball'sr. chance in hell for Alpha as a volume platform.   ------------------------------  # Date: Thu, 18 Oct 2001 03:06:16 GMT14 From: "Terry C. Shannon" <terryshannon@mediaone.net>/ Subject: Re: Higher prices for Alpha processorss> Message-ID: <IGrz7.130331$vq.28849037@typhoon.ne.mediaone.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messager9 news:NF1z7.513798$Lw3.31489676@news2.aus1.giganews.com...r >u@ > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote in message- > news:pd1z7.533$RL6.4757@news.cpqcorp.net... J > > Seems to me that both you and Bill are wasted - *you* should be CEO's. > HowiK > > is it that your raw pearls of wisdom have gone unnoticed?  At least youf< > > should be the head of Strategy for a Fortune 50 company. >hK > Actually, at least some of those pearls were noticed but discarded, since L > they were presented to Capellas (and then redirected to Marcello) about 17
 > months ago.e  L Indeed they were. In addition to Michael Capellas, Bill Heil was a recipient of the aforementioned pearls.t   ------------------------------  # Date: Thu, 18 Oct 2001 03:12:50 GMT 2 From: Arthur Krewat <krewat@bartek.dontspamme.net>/ Subject: Re: Higher prices for Alpha processors 5 Message-ID: <3BCE4844.15CEFB55@bartek.dontspamme.net>o   "Zane H. Healy" wrote: > . > In alt.sys.pdp10 sword7@speakeasy.org wrote:N > > My development version of TS10 emulator has complete KL10 emulation.  KL10N > > TOPS-10 system successfully was loaded and run on my TS10 emulator.  DTE20M > > communications are not completely yet because I have to develop PDP-11/40-2 > > emulator to support KL10 emulator cocurrently. > I > Ah, now this is the news I've been waiting for.  Have you tried runninguI > TOPS-20 V7.0 on it?  Personally I'm not to worried, at this time, abouttE > running TOPS-10 under KL10 emulation since we can do that on a KS10 L > emulator.  However, TOPS-20 is a different matter, and the V7.0 tapes look > to be the most complete.  F Me too, but I'm interested in running TOPS-10 6.03A and the only stuffH around is for KL. I'd REALLY be interested in 5.06A but that was runningG on a KA10 and I'm not sure the KL was supported in that version. I also  don't have anything that old :)b   aaki   ------------------------------  % Date: Wed, 17 Oct 2001 16:51:27 -0700p$ From: Shane Smith <ssmith@icius.com>2 Subject: Linker64 producing un-INSTALLable images?0 Message-ID: <01C1572C.00A00870@sulfer.icius.com>  E Hi folks, it's the return of the Shane. I'm not regularly surfing theb( group again yet, but I'm back in action.  D I have run into something rather odd. We have a fairly large programA that gets linked, and is normally installed with /read, /head andmF /share. This works for us on 6.2 and 7.2.. One of our customers, who'sG on 7.2 and has installed the ADB073 kit including the LINKER64 package,oH links it with exactly the same link options. For him it puts some psectsE in P2 space, causing the INSTALL utility to throw it out with the (asnG far as I can see) undocumented error NOINST64BIT. Unfortunately because B of his environment he has to link it himself, and when he bypasses= LINK64 and uses LINK the NOINST64BIT goes away but he gets ann? inexplicable subscript out of range out of the resulting image.   H There are only a few instructions in the OPT file relating to the psectsG in question, of the form PSECT={psect_name},SOLITARY. (These predate my E arrival here, but apparently they're there for alignment purposes.) InH figure this has to have something to do with it. However, I haven't beenH able to track down any documentation on LINK64 to see how it treats them, or if there's a way to change the behaviour.  C Does anyone know anything that might help me find the solution? Cane= anyone point me to the right documentation, or send it to me?o   Shane     ##### #-O-O-#o #  L  #r  #===#   ###    ------------------------------  % Date: Wed, 17 Oct 2001 19:30:04 +0200M2 From: martin@radiogaga.harz.de (Martin Vorlaender)" Subject: Re: make files on OpenVMS; Message-ID: <3bcdc01c.524144494f47414741@radiogaga.harz.de>e  + Schild Niklaus (schin@hta-bi.bfh.ch) wrote:nJ > I'm looking for some informations about how to write makefiles (make.com   I don't know that one.   > and descript.mms) .e  ! That's descrip.mms in most cases.a  = > I have an example which I don't understand. My search about L > any documentation about makefiles on VMS was not successfull. Does someone) > know where I can find infos about this?s  K You'd need the DECset (which MMS, the Module Management System, is part of)sD set of documents. I have no idea whether these are available online.2 Is MMS installed on your system? Try "$ HELP MMS".  ? Alternatively, get MMK (a free MMS clone) from www.madgoat.com.   H If you know Unix makefiles, perhaps the "Converting a Unix Makefile to a' DESCRIP.MMS" article is useful for you:sE http://www.pdv-systeme.de/users/martinv/VMS_Programming_FAQ.html#4.1.x  G Apart from all these links, makefiles aren't too difficult. You specifyoE a target, prerequisites that are needed to build it, and action linesv( that do actually build it. The syntax is     target1 : prereq1, repreq2      action1      action2     target2 : ...w  < If, say, you want to build an executable from a C file, it's   file.obj : file.ce%     CC /OBJECT=$(MMS$TARGET) file.objo   file.exe : file.objw+     LINK /EXECUTABLE=$(MMS$TARGET) file.objt  I The "$(MMS$TARGET)" thingie is called a macro. There are a few predefined ? ones, and you can set up you own. Please find more in the docs.8   cu,E   Martin -- rG                            | Martin Vorlaender  |  VMS & WNT programmero4  UNIX is user friendly.    | work: mv@pdv-systeme.deG  It's just selective about |   http://www.pdv-systeme.de/users/martinv/t;  who its friends are.      | home: martin@radiogaga.harz.dei   ------------------------------    Date: 17 Oct 2001 13:22:07 -0700( From: bob@instantwhip.com (Bob Ceculski)3 Subject: Re: More official info on Compaq/HP mergera= Message-ID: <d7791aa1.0110171222.21d0c9cf@posting.google.com>t  e Alan Greig <a.greig@virgin.net> wrote in message news:<2k4rstcvgd3e5ie0sh5k843605dcgf5v1u@4ax.com>...aE > On Wed, 17 Oct 2001 14:01:27 +0100, Alan Greig <a.greig@virgin.net>t > wrote: > @ > And it gets worse. Here is the Aberdeen groups recommendations: > concerning the Tru64 ports to Itanium and the VMS ports: > G > "First, the port of Tru64 UNIX to Itanium should not be completed.....F > ...Second, the port of OpenVMS to Itanium should not be completed."  > 1 > They do suggest that the NSK port be completed.e > H > And this is the report that Carly has praised in press statements!!!!!G > I suggest Compaq staff press for a statement on Carly's praise of thetG > Aberdeen groups analysis when it contains statements like the above. s >  > More of this nonsense at > http://quicken.elogic.com/sec_grab.asp?ticker=CPQ&faddr=edgar%2Fdata%2F714154%2F0000912057%2D01%2D535049%2Etxt&fkey=0000912057%2D01%2D535049&ftype=425  J AND THAT IS THE PROBLEM ... THESE PEOPLE, CEOS AND GROUPS ARE INFILTRATINGN MICROSOFTS COMPETITION AND DESTROYING THEIR SUPERIOR TECHNOLOGY OR AT THE VERYI LEAST HOLDING BACK UPGRADES (I.E. DAVE PALMER W/VMS).  UNIX OR LINUX WILL:N SURVIVE IN SOME FORM BUT WE NEED VMS TO BE BOUGHT BY SOMEONE WHO WANTS NO PARTI OF THE MICROSOFT CROWD ... ISN'T THIS ILLEGAL (MONOPOLY) AND WHERE IS THEm SEC?   ------------------------------  % Date: Wed, 17 Oct 2001 21:47:13 +0100t% From: Alan Greig <a.greig@virgin.net>M3 Subject: Re: More official info on Compaq/HP mergerv* Message-ID: <3BCDEE51.E2E4DDE0@virgin.net>  ] Bob Ceculski wrote:AND THAT IS THE PROBLEM ... THESE PEOPLE, CEOS AND GROUPS ARE INFILTRATING1  P > MICROSOFTS COMPETITION AND DESTROYING THEIR SUPERIOR TECHNOLOGY OR AT THE VERYK > LEAST HOLDING BACK UPGRADES (I.E. DAVE PALMER W/VMS).  UNIX OR LINUX WILL0P > SURVIVE IN SOME FORM BUT WE NEED VMS TO BE BOUGHT BY SOMEONE WHO WANTS NO PARTK > OF THE MICROSOFT CROWD ... ISN'T THIS ILLEGAL (MONOPOLY) AND WHERE IS THE  > SEC?   And that is the amazing thing. The article I have quoted is from an SEC filing by Compaq itself! Here's the quote from the article head:      i                                                 Filed by Compaq Computer Corporation Pursuant to Rule 425en                                                                               Under the Securities Act of 1933l                                                                     And Deemed Filed Pursuant to Rule 14a-12l                                                                    Under the Securities Exchange Act of 1934j                                                               Subject Company: Compaq Computer Corporationn                                                                                    Commission File No.: 1-9026  f                         This filing relates to a planned merger (the "Merger") between Hewlett-Packardd                      Company ("HP") and Compaq Computer Corporation ("Compaq") pursuant to the termse                        of an Agreement and Plan of Reorganization, dated as of September 4, 2001 (theee                      "Merger Agreement"), by and among HP, Heloise Merger Corporation and Compaq. Theab                          Merger Agreement is on file with the Securities Exchange Commission as anb                          exhibit to the Current Report on Form 8-K, as amended, filed by Compaq ona                             September 4, 2001, and is incorporated by reference into this filing.t  c                          Following are analyst reports by Aberdeen Group, Inc. which were posted onkS                                   the Compaq internal intranet on October 10, 2001:      So Compaq are telling *us* the customers that they will complete the post but are filing financial disclosure reports that suggest they won't. Just as Compaq told *us* that Alpha was safe but suggested otherwise in statements to financial analysts. I suspect Curly is playing his "get out of jail" card.   --
 Alan Greig   ------------------------------  % Date: Wed, 17 Oct 2001 17:04:36 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>o3 Subject: Re: More official info on Compaq/HP mergerh, Message-ID: <3BCDF263.1CED84EA@videotron.ca>   Ben Myers wrote:: > Does Microsoft get a seat on the merged HP-Compaq board?  J Microsoft doesn't need a seat on companies it holds by the balls. It knows9 that they will behave and do exactly as Microsoft wishes.n   ------------------------------  % Date: Wed, 17 Oct 2001 17:05:22 -0400e% From: "John Vottero" <John@mvpsi.com>o3 Subject: Re: More official info on Compaq/HP mergero/ Message-ID: <tsrskje97g8f6b@news.supernews.com>A  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:2k4rstcvgd3e5ie0sh5k843605dcgf5v1u@4ax.com...E > On Wed, 17 Oct 2001 14:01:27 +0100, Alan Greig <a.greig@virgin.net>- > wrote: >a@ > And it gets worse. Here is the Aberdeen groups recommendations: > concerning the Tru64 ports to Itanium and the VMS ports: > G > "First, the port of Tru64 UNIX to Itanium should not be completed....6E > ...Second, the port of OpenVMS to Itanium should not be completed."e > 1 > They do suggest that the NSK port be completed.i >tH > And this is the report that Carly has praised in press statements!!!!!G > I suggest Compaq staff press for a statement on Carly's praise of the F > Aberdeen groups analysis when it contains statements like the above. >n  H Clearly, the Aberdeen group is dazed and confused.  Take a look at these gems:e  D "OpenVMS has basically been in maintenance mode for the past severalI years -- with a few new features added to help retain the large installed  base,c0 some of which is still running on VAX hardware."  I "Digital had planned to migrate OpenVMS users to Windows NT on Alpha, buta thatK strategy was dropped when the Windows-on-Alpha product line was scrapped. "   L "Second, the port of OpenVMS to Itanium should not be completed. The OpenVMSH installed base has traditionally been a very loyal group for Digital and later2B Compaq, but it will be a hard sell to get that base to port mature applicationsG to HP-UX or Windows NT/2000 on Itanium. Thus, HP/Compaq should focus onu using>L its existing customer relationships and service capabilities to make the newL company the preferred platform vendor for OpenVMS customers who want to jump to a more contemporary platform."  H (Aren't these statements diametrically opposed?  First they say that VMSH should be dumped because it will be a hard sell to get people to port toI HP-UX or NT.  Then they say that they should focus on being the preferred K platform vendor for OpenVMS customer who do want to port.  It's too hard tonI port isn't it?  You just said so.  If the only reason that I'm porting is-L because OpenVMS is being dropped, why would I buy from the person forcing me	 to port?)n    E Anyway, it's just the ramblings of a couple of nonpractitoners at ther* Aberdeen group, the official HP answer is:  ) Q5: WILL YOU CONTINUE TO SUPPORT OPENVMS?o  L A: Yes. We have a loyal installed base of OpenVMS users and we will continue toK support their needs under the roadmap we have already communicated prior to  thenL announcement of the proposed transaction. This includes continued support on theeJ upcoming EV7 and EV79 Alpha systems, as well as a continuation of the port and L release on Itanium(TM)-based systems. We will, as previously stated prior to thetI announcement of the proposed transaction, migrate our OpenVMS applicationoE portfolio, ensuring the ongoing operating environment for our OpenVMSi	 customersl
 and partners.i   ------------------------------  % Date: Wed, 17 Oct 2001 22:15:33 +0100m% From: Alan Greig <a.greig@virgin.net>c3 Subject: Re: More official info on Compaq/HP mergern* Message-ID: <3BCDF4F4.BFC19B32@virgin.net>  G > Anyway, it's just the ramblings of a couple of nonpractitoners at the-, > Aberdeen group, the official HP answer is: >   P Nope I'm afraid it isn't nor is it confused (in a syntactical sense) if you readL the whole thing. They say it will be difficult to get users to port to HP-UXL which is exactly *why* they say the VMS port should be terminated as fast asM possible so that HP can then concentrate on that problem now rather than havesL several years of Sun and IBM grabbing away much of the user base. And pleaseP note that the Aberdeen Group report I am quoting has been filed by Compaq itself! and referred to by Carly herself.   O Obviously I think it's a suicide note but does anyone seriously think Curly ando Carly have a clue?     >o+ > Q5: WILL YOU CONTINUE TO SUPPORT OPENVMS?1 >nN > A: Yes. We have a loyal installed base of OpenVMS users and we will continue > to >e  M I've been given the same promises about TOPS-20, Alpha/NT and Alpha itself bye' DEC/Compaq. Turned out to be worthless.l --
 Alan Greig   ------------------------------    Date: 17 Oct 2001 17:25:54 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 3 Subject: Re: More official info on Compaq/HP merger.3 Message-ID: <CzAIBu0w7QL0@eisner.encompasserve.org>e  W In article <tsrskje97g8f6b@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:e  J > Clearly, the Aberdeen group is dazed and confused.  Take a look at these > gems:. > F > "OpenVMS has basically been in maintenance mode for the past severalK > years -- with a few new features added to help retain the large installed. > base,i2 > some of which is still running on VAX hardware." > K > "Digital had planned to migrate OpenVMS users to Windows NT on Alpha, butw > thatM > strategy was dropped when the Windows-on-Alpha product line was scrapped. "o > N > "Second, the port of OpenVMS to Itanium should not be completed. The OpenVMSJ > installed base has traditionally been a very loyal group for Digital and > later D > Compaq, but it will be a hard sell to get that base to port mature > applicationsI > to HP-UX or Windows NT/2000 on Itanium. Thus, HP/Compaq should focus on  > usinghN > its existing customer relationships and service capabilities to make the newN > company the preferred platform vendor for OpenVMS customers who want to jump > to  > a more contemporary platform." > J > (Aren't these statements diametrically opposed?  First they say that VMSJ > should be dumped because it will be a hard sell to get people to port toK > HP-UX or NT.  Then they say that they should focus on being the preferredaM > platform vendor for OpenVMS customer who do want to port.  It's too hard toDK > port isn't it?  You just said so.  If the only reason that I'm porting is@N > because OpenVMS is being dropped, why would I buy from the person forcing me > to port?)   @ Think of the Aberdeen group as getting paid by the word, with no accountability.3   ------------------------------  # Date: Wed, 17 Oct 2001 23:00:01 GMTe* From: Chuckie Cheese <Chuckie@Cheese.nuts>3 Subject: Re: More official info on Compaq/HP mergert+ Message-ID: <3BCE0F2B.8EA3F920@Cheese.nuts>o  E "Aberdeen group as getting paid by the word, with no accountability."o  / CIA getting paid to look for Osama bin Laden...y   Larry Kilgallen wrote:  Y > In article <tsrskje97g8f6b@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:  >ML > > Clearly, the Aberdeen group is dazed and confused.  Take a look at these	 > > gems:- > >-H > > "OpenVMS has basically been in maintenance mode for the past severalM > > years -- with a few new features added to help retain the large installed 	 > > base,D4 > > some of which is still running on VAX hardware." > >aM > > "Digital had planned to migrate OpenVMS users to Windows NT on Alpha, bute > > thatO > > strategy was dropped when the Windows-on-Alpha product line was scrapped. "u > >aP > > "Second, the port of OpenVMS to Itanium should not be completed. The OpenVMSL > > installed base has traditionally been a very loyal group for Digital and	 > > laternF > > Compaq, but it will be a hard sell to get that base to port mature > > applicationsK > > to HP-UX or Windows NT/2000 on Itanium. Thus, HP/Compaq should focus onn	 > > using P > > its existing customer relationships and service capabilities to make the newP > > company the preferred platform vendor for OpenVMS customers who want to jump > > to" > > a more contemporary platform." > > L > > (Aren't these statements diametrically opposed?  First they say that VMSL > > should be dumped because it will be a hard sell to get people to port toM > > HP-UX or NT.  Then they say that they should focus on being the preferred-O > > platform vendor for OpenVMS customer who do want to port.  It's too hard to.M > > port isn't it?  You just said so.  If the only reason that I'm porting is.P > > because OpenVMS is being dropped, why would I buy from the person forcing me
 > > to port?)h > B > Think of the Aberdeen group as getting paid by the word, with no > accountability.v   ------------------------------  # Date: Thu, 18 Oct 2001 01:01:22 GMTh* From: cjt & trefoil <cheljuba@prodigy.net>3 Subject: Re: More official info on Compaq/HP merger2+ Message-ID: <3BCE29E4.C07D44F3@prodigy.net>h   Larry Kilgallen wrote: >  <snip>B > Think of the Aberdeen group as getting paid by the word, with no > accountability.A  L And yet Compaq/HP seem to think they're credible enough to file their report
 with the SEC.o   ------------------------------    Date: 17 Oct 2001 21:14:38 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)S3 Subject: Re: More official info on Compaq/HP mergeri3 Message-ID: <CSM7Dj4WGm70@eisner.encompasserve.org>   X In article <3BCE29E4.C07D44F3@prodigy.net>, cjt & trefoil <cheljuba@prodigy.net> writes: > Larry Kilgallen wrote: >> T > <snip>C >> Think of the Aberdeen group as getting paid by the word, with noo >> accountability. > N > And yet Compaq/HP seem to think they're credible enough to file their report > with the SEC.o  " They think the SEC won't complain.   ------------------------------    Date: 17 Oct 2001 21:22:18 -0500+ From: young_r@encompasserve.org (Rob Young) 3 Subject: Re: More official info on Compaq/HP mergert3 Message-ID: <XhxtOzdm6IZ5@eisner.encompasserve.org>=  W In article <tsrskje97g8f6b@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:m4 > "Alan Greig" <a.greig@virgin.net> wrote in message4 > news:2k4rstcvgd3e5ie0sh5k843605dcgf5v1u@4ax.com...F >> On Wed, 17 Oct 2001 14:01:27 +0100, Alan Greig <a.greig@virgin.net>	 >> wrote:n >>A >> And it gets worse. Here is the Aberdeen groups recommendationse; >> concerning the Tru64 ports to Itanium and the VMS ports:h >>H >> "First, the port of Tru64 UNIX to Itanium should not be completed....F >> ...Second, the port of OpenVMS to Itanium should not be completed." >>2 >> They do suggest that the NSK port be completed. >>I >> And this is the report that Carly has praised in press statements!!!!!mH >> I suggest Compaq staff press for a statement on Carly's praise of theG >> Aberdeen groups analysis when it contains statements like the above.t >> > J > Clearly, the Aberdeen group is dazed and confused.  Take a look at these > gems:p >    	Very nice piece of digging.  F > "OpenVMS has basically been in maintenance mode for the past severalK > years -- with a few new features added to help retain the large installede > base,n2 > some of which is still running on VAX hardware." >   @ 	This of course flies in the face of recent VMS growth (i.e over= 	the last 2-3 years).  But why should facts get in the way ofo 	writing a nice piece?  K > "Digital had planned to migrate OpenVMS users to Windows NT on Alpha, but  > thatM > strategy was dropped when the Windows-on-Alpha product line was scrapped. "  >   A 	This must be tangentially referring to Affinity and Affinity wassH 	dead long before WindowsAlpha was knifed.  Early on, few were migratingB 	from VMS to NT.  That was an insane strategy given the immaturityD 	of NT.  Windows 2000 is much stronger but NT was/is impossibly weakG 	as a replacement and the suckers (WM) that bought into that eventuallyaE 	paid the price.  Unfortunately , there was a good deal of collateraleB 	damage.  Digital bought into a dream.  NT was the be-all-end-all, 	but it wasn't.7  N > "Second, the port of OpenVMS to Itanium should not be completed. The OpenVMSJ > installed base has traditionally been a very loyal group for Digital and > latertD > Compaq, but it will be a hard sell to get that base to port mature > applicationsI > to HP-UX or Windows NT/2000 on Itanium. Thus, HP/Compaq should focus on  > usinggN > its existing customer relationships and service capabilities to make the newN > company the preferred platform vendor for OpenVMS customers who want to jump > to  > a more contemporary platform." > 3 > (Aren't these statements diametrically opposed?  e   	Yes.O   First they say that VMStJ > should be dumped because it will be a hard sell to get people to port toK > HP-UX or NT.  Then they say that they should focus on being the preferred M > platform vendor for OpenVMS customer who do want to port.  It's too hard toeK > port isn't it?  You just said so.  If the only reason that I'm porting isoN > because OpenVMS is being dropped, why would I buy from the person forcing me > to port?)7 >   C 	A key observation and one not missed by senior management.  As you4@ 	point out below, there are public statements contradicting what= 	was written above.  Just goes to show that anyone can write EC 	a well polished position paper and few will be wiser to contradictE> 	unless they are very well acquainted with many of the issues.   > G > Anyway, it's just the ramblings of a couple of nonpractitoners at the., > Aberdeen group, the official HP answer is: > + > Q5: WILL YOU CONTINUE TO SUPPORT OPENVMS?e > N > A: Yes. We have a loyal installed base of OpenVMS users and we will continue > toM > support their needs under the roadmap we have already communicated prior toe > theoN > announcement of the proposed transaction. This includes continued support on > theTL > upcoming EV7 and EV79 Alpha systems, as well as a continuation of the port > andEN > release on Itanium(TM)-based systems. We will, as previously stated prior to > theVK > announcement of the proposed transaction, migrate our OpenVMS application G > portfolio, ensuring the ongoing operating environment for our OpenVMS  > customersn > and partners.z >  > ? 	Nice.  It's a beautiful thing when someone digs up and totallyl 	contradicts talking heads.a   				Rob:   ------------------------------  % Date: Wed, 17 Oct 2001 22:29:29 -0400p% From: "John Vottero" <John@mvpsi.com> 3 Subject: Re: More official info on Compaq/HP merger / Message-ID: <tssfkar6g8nn19@news.supernews.com>o  2 "Alan Greig" <a.greig@virgin.net> wrote in message$ news:3BCDF4F4.BFC19B32@virgin.net... >r >nI > > Anyway, it's just the ramblings of a couple of nonpractitoners at the . > > Aberdeen group, the official HP answer is: > >  > I > Nope I'm afraid it isn't nor is it confused (in a syntactical sense) ifm you readH > the whole thing. They say it will be difficult to get users to port to HP-UX K > which is exactly *why* they say the VMS port should be terminated as fastf asJ > possible so that HP can then concentrate on that problem now rather than haveG > several years of Sun and IBM grabbing away much of the user base. Andn pleaseK > note that the Aberdeen Group report I am quoting has been filed by Compaqt itself# > and referred to by Carly herself.   L They are clearly confused if they think they should dump OpenVMS so they can5 focus on telling OpenVMS customers how good HP-UX is.s   >iG > Obviously I think it's a suicide note but does anyone seriously think 	 Curly and  > Carly have a clue? >m >K > >a- > > Q5: WILL YOU CONTINUE TO SUPPORT OPENVMS?  > > G > > A: Yes. We have a loyal installed base of OpenVMS users and we will  continue > > to > >  >FL > I've been given the same promises about TOPS-20, Alpha/NT and Alpha itself by) > DEC/Compaq. Turned out to be worthless.r   ------------------------------  # Date: Thu, 18 Oct 2001 02:56:06 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: More official info on Compaq/HP merger.> Message-ID: <axrz7.130323$vq.28840366@typhoon.ne.mediaone.net>  7 "cjt & trefoil" <cheljuba@prodigy.net> wrote in message % news:3BCE29E4.C07D44F3@prodigy.net...  > Larry Kilgallen wrote: > >- > <snip>D > > Think of the Aberdeen group as getting paid by the word, with no > > accountability.o >aG > And yet Compaq/HP seem to think they're credible enough to file theirC report > with the SEC.c  K Compaq and HP seem to have filed darn near every bit of writing that's beenr! done on the proposed acquisition.   J As for the credibility of the various market research/analyst firms, thereH was a recent "Analyzing The Analysts" write-up in one of the trade press organs.0   ------------------------------  # Date: Thu, 18 Oct 2001 03:55:05 GMTM* From: "Bill Todd" <billtodd@metrocast.net>3 Subject: Re: More official info on Compaq/HP merger ? Message-ID: <tosz7.525538$Lw3.32101328@news2.aus1.giganews.com>e  = Terry C. Shannon <terryshannon@mediaone.net> wrote in message18 news:axrz7.130323$vq.28840366@typhoon.ne.mediaone.net...   ...   H > Compaq and HP seem to have filed darn near every bit of writing that's been# > done on the proposed acquisition.F  2 Including the 75% - 80% that's extremely negative?   - bill   ------------------------------  # Date: Thu, 18 Oct 2001 04:00:09 GMT.* From: cjt & trefoil <cheljuba@prodigy.net>3 Subject: Re: More official info on Compaq/HP mergerl+ Message-ID: <3BCE53C4.8E486B30@prodigy.net>u  N I think somebody here said Carly had spoken favorably of this Aberdeen report.L If that's so, it could perhaps be considered an endorsement of the report's  conclusions.   "Terry C. Shannon" wrote:a > 9 > "cjt & trefoil" <cheljuba@prodigy.net> wrote in messagen' > news:3BCE29E4.C07D44F3@prodigy.net...w > > Larry Kilgallen wrote: > > >p
 > > <snip>F > > > Think of the Aberdeen group as getting paid by the word, with no > > > accountability.n > > I > > And yet Compaq/HP seem to think they're credible enough to file theirp > report > > with the SEC.p > M > Compaq and HP seem to have filed darn near every bit of writing that's beenb# > done on the proposed acquisition.a > L > As for the credibility of the various market research/analyst firms, thereJ > was a recent "Analyzing The Analysts" write-up in one of the trade press	 > organs.w   ------------------------------  # Date: Thu, 18 Oct 2001 04:01:38 GMTi4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: More official info on Compaq/HP mergero> Message-ID: <Cusz7.130367$vq.28899992@typhoon.ne.mediaone.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messaged9 news:tosz7.525538$Lw3.32101328@news2.aus1.giganews.com...l > ? > Terry C. Shannon <terryshannon@mediaone.net> wrote in message : > news:axrz7.130323$vq.28840366@typhoon.ne.mediaone.net... >  > ...n > J > > Compaq and HP seem to have filed darn near every bit of writing that's > been% > > done on the proposed acquisition.- >e4 > Including the 75% - 80% that's extremely negative? >p  A It would seem so, based on a quick once-over of the SEC material.a   ------------------------------  % Date: Thu, 18 Oct 2001 00:25:06 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca>o3 Subject: Re: More official info on Compaq/HP merger , Message-ID: <3BCE599C.23C68224@videotron.ca>  * Here is a most interesting one from EDGAR:@ http://www.edgar-online.com/brand/eol/glimpse/glimpse.pl?sym=CPQ   ##B Consolidation of high performance servers on single microprocessorK architecture could adversely affect revenue. In June 2001, Compaq and InteldN Corp. ("Intel") announced a strategic alliance that, over a multi-year period,N will lead to Compaq consolidating its high performance enterprise servers on aF single microprocessor architecture. Plans to consolidate Compaq's highL performance enterprise servers on a single microprocessor architecture couldG lead to the loss of high-end business. Compaq believes that the currentCK development plans for the Compaq Alpha(TM) microprocessor offer significantsL advantages for its customers and that the cost effectiveness of the Intel(R)D Itanium(TM) microprocessor will be an attractive value. However, theL transition to the Intel architecture could lead to the loss of potential newM business for Compaq's high-end enterprise products and the associated servicehL business, and, more significantly, the loss of current customers to high-end0 enterprise hardware competitors in this sector.  ##    N So Compaq knows full well that that killing Alpha was a very bad business moveD for Compaq. But since at that time Compaq was already working on itsL end-of-life (absorbsion into HP), that decision need not be a sound businessE decision for Compaq, it needs to be a sound business decision for HP.5  N With Alpha dead, it effectively protects HP's own products and decisions. (eg:N HP's investment into IA64). Had HP inherited the superior Alpha, it would haveL been caught in a bind since the logical thing to do was to move to Alpha and. merge HP-US into Tru64 instead of the reverse.   ------------------------------  # Date: Wed, 17 Oct 2001 19:17:56 GMT@3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>i Subject: Re: MOZILLA 0.9.5/ Message-ID: <3BCDD8D6.E371C8DC@cableinet.co.uk>e   Brian Tillman wrote: >   > >The new version is available:N > >http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.5/mozilla-openvms-al > pha-m095.sfx_axpexeo >  > But it doesn't run on a VAX.  F Don't worry Brian, help is at hand from the IT recruitment profession.  E from http://www.it.jobserve.com/jobserve/JobDetail.asp?jobid=14974098i  G Site engineers required with the following experience. Sun Vax hardwarea fix repair and>                                                        ^^^^^^^D diognostic experience on corporate cusomer sites + some knowledge of	 Compaq or,H Dells would be a bonus. Both Senior and Customer Engineers are needed to
 fill these varied interesting roles.e                          a5 yup, the Sun VAX has arrived :-).                    e    t --   Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.    ------------------------------   Date: 17 Oct 2001 18:45:21 CDT= From: wayne@tachysoft.xxx.062469.killspam.00be (Wayne Sewell)u/ Subject: Re: Mozilla 0.9.5 and file protections . Message-ID: <$z1dVvjNdCQD@tachxxsoftxxconsult>  e In article <3BCDA524.D8DFF448@cableinet.co.uk>, Tim Llewellyn <tim.llewellyn@cableinet.co.uk> writes:P > Colin Blake wrote: >> h >> Larry Kilgallen wrote:n >>  E >> > Are the protections explicitly specified in the PCSI .PDF file ?  >>   >> No. >>  D >> > If not, could it be defaulting to the RMS default on the system >> > in question ? >>  \ >> No. Well, it shouldn't be. Mozilla does NOT specify any protection on its "file" commandsZ >> in its PCSI description file. The default protection is meant to be "protection public") >> which is (S:RWED, O:RWED, G:RE, W:RE).  >>  	 >> Colin.i > J > default file protections are ultimately controlled by a SYSGEN parameter > RMS_FILEPROT. C > This might psosibly explain why you are seing differences betweeny
 > systems.  G Not to mention that there could be a set prot/default in the installingy account's login.     --  O ===============================================================================mM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxl: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)tO ===============================================================================sH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------  # Date: Wed, 17 Oct 2001 22:02:40 GMT ' From: Steve Thompson <smt@twcny.rr.com> 6 Subject: Re: multinet IP address and host.local changeG Message-ID: <Pine.LNX.4.33.0110171801530.2948-100000@vger.vgersoft.com>t  % On Wed, 17 Oct 2001, mrauscher wrote:l  E > We've recently changed the IP (multinet) address of our VMS clusteroM > machines. Because the cluster is behind a firewall and the addresses of thenL > cluster members on the external DNS server are not the same as the addressG > on the cluster interfaces, we want each cluster member to resolve thehK > qualified names of the other members from its own host.local table rather N > than using the DNS. After changing the interface IP addresses and making the= > appropriate changes to the host.local, we do the following:  >  > $multinet host_table compile > $@multinet:install_databases > $@multinet:start_servern > $@multinet:start_smtpw >dK > Everything looks fine, but when we ping or otherwise try to access one of N > the other members via its name in the host.local, the machine appears to notE > be using its host.local (which is specified as the first source fortH > resolution) but going directly to the DNS, and therefore returning the, > external, and therefore the wrong address. >1I > Any tips on what we're doing wrong, or how we can force the machines tocG > reference their own host.local tables before going to the DNS server?D  I If DNS is configured in MultiNet, a gethostbyname() [etc] call looks onlydI to DNS and ignores the local host tables, unless DNS is not available. AneG application has to call _gethostbyname() explicitly to look directly ati2 the host tables. So, if I'm not wrong, you're SOL.   Stevet   ------------------------------    Date: 17 Oct 2001 21:38:48 +0200  From: Cthulhu <noone@nowhere.it>/ Subject: Quotation for an AlphaServer 300 4/266n) Message-ID: <9qkmo8$1c4$1@kadath.deep.it>9  F How much do you think I can offer for an AlphaServer 300, model 4/266, 64 MB RAM, 2 x 1GB HDD?>H No monitor, maybe keyboard and mouse (maybe - does it have PS/2 ports?).  F Is it able to run OpenVMS + DECwindow in some working way with only 646 MB RAM, or is it at least exapndable with common DIMM?   	evalutatingly,S 	   Cthulhul   --    H        Ph'nglui mglw'nafh Cthulhu http://www.rlyeh.it/ wgah'nagl fhtgan!$ 		     <cthulhu (at) rlyeh (dot) it>   ------------------------------  # Date: Thu, 18 Oct 2001 02:18:42 GMTd4 From: "Terry C. Shannon" <terryshannon@mediaone.net>5 Subject: Re: Scott McNealy has no respect for Alpha'si> Message-ID: <6_qz7.130282$vq.28809903@typhoon.ne.mediaone.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message.= news:TJZy7.772802$NK1.69883572@bin3.nnrp.aus1.giganews.com...r >.5 > Bob Ceculski <bob@instantwhip.com> wrote in message 9 > news:d7791aa1.0110160601.3767a5c4@posting.google.com...o9 > > "Bill Todd" <billtodd@metrocast.net> wrote in message > > news:<JeLy7.15958$%B.2037405@bin1.nnrp.aus1.giganews.com>...9 > > > Bob Ceculski <bob@instantwhip.com> wrote in message"; > > > news:d7791aa1.0110150531.781567@posting.google.com...  > > >t	 > > > ...r > > >hK > > > > why don't you wake up ... after looking at the itanium spec resultss > anyoneK > > > > could see itanic was a dud ... intel had to buy alpha to be able tos > have aL > > > > "working" 64 bit platform ... alpha will live on with the intel logo > > > > on it! > > >eD > > > There's really no effective way to reply to someone so clearly	 convincedn > ofJ > > > his misconceptions.  But the vast preponderance of opinion of people > almostE > > > certainly far better informed than you are is that Intel has no  > intention"C > > > whatsoever of doing anything with the Alpha implementation orv
 > instruction-I > > > set, but just wanted its engineers and some design features (and to # > > > eliminate it as competition).p > > >s > > > - bill > >nC > > wrong!  they needed the compilers and some other key pieces ...a >oL > No, they needed the compiler *expertise* to build Itanic back-ends (though1 > the existing front-ends will likely be useful).p >wB > > the new itanic has to be all things to all people so some modsC > > will need to made to vms (port), but i guarantee the new itanicc9 > > will be very close to the never to be made ev8 alpha! E > > otherwise, intel will never sit in a high end shop ... why do you.E > > think comps like cerner and the dod are going along with this ...aF > > because now intel can provide alpha technology cheaper than compaqD > > which means cheaper boxes ... this is what i have been told fromB > > someone high up in the vms group ... unless you think they are
 > > lying! >dL > They are lying, and you are gullible.  And while it is possible that IntelI > may want to incorporate EV8-inspired features like OOO and SMT into theaJ > Itanic architecture (which is not at all the same thing as rebadging andL > shipping EV8 itself), they couldn't ship such a product before 2006 at theI > earliest - though they might be able to incorporate peripheral features  like/ > EV7's on-chip glue for MP and memory by 2005.e >   B Consistent with what I've heard. Glueless SMP and memory bandwidthI enhancements should appear in post-Madison IPF chips. Chances are slim tot< none that INTC will jettison IPF for the Alpha architecture.   ------------------------------   Date: 17 Oct 2001 23:51:50 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)h@ Subject: Re: sd comman (or who has the biggest cd.com or sd.com), Message-ID: <9ql5im$2q2r$3@info.cs.uofs.edu>  D Does anyone else here find it ironic that while denigrating the UnixE way of doing things so many people here have immitation Unix commands  for VMS.  E I on the other hand, being an old Unix hand, was given a set of thesesD when I first got onto VMS and abandoned them as a bad idea.  It just0 makes it harder to get used to working with VMS.   bill   -- jJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   o   ------------------------------    Date: 17 Oct 2001 21:33:09 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)s@ Subject: Re: sd comman (or who has the biggest cd.com or sd.com)3 Message-ID: <pHVERUXweUgV@eisner.encompasserve.org>a  ` In article <9ql5im$2q2r$3@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:F > Does anyone else here find it ironic that while denigrating the UnixG > way of doing things so many people here have immitation Unix commandsn
 > for VMS. > G > I on the other hand, being an old Unix hand, was given a set of thesegF > when I first got onto VMS and abandoned them as a bad idea.  It just2 > makes it harder to get used to working with VMS.  J There is no reason to make people unhappy by withholding trivial crutches.   ------------------------------  % Date: Wed, 17 Oct 2001 14:29:58 -0400e> From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>" Subject: RE: TL892s and AUTO_CLEANM Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D01602479@MBCALBEXC03.BENDER.COM>i   > -----Original Message-----! > From: Koska, John C. (LNG-MBC)  * > Sent: Tuesday, October 16, 2001 11:07 AM > To: Info-VAX@mvb.saic.coms$ > Subject: RE: TL892s and AUTO_CLEAN >  >  > > -----Original Message-----D > > From: Webb, William W Raleigh, NC [mailto:wwebb1@email.usps.gov], > > Sent: Tuesday, October 16, 2001 10:25 AM > > To: Info-VAX@mvb.saic.como" > > Subject: TL892s and AUTO_CLEAN > > 7 > > I've got three TL892s and an expansion minilibrary.  > > VMS Alpha 7.2-1  > > ABS 3.1A(193)e > > MDMS 3.1A(350) q > > MRU 1.4  > > 7 > > It has come to our attention that AUTO_CLEAN is not  > > supported on TL892s. > > 7 > > What are other ABS/MDMS users with multiple drives n) > > doing with respect to drive cleaning?s > > , > > Does anyone out there have a workaround? > >  > > TIA." > > ==============================. > > William W. Webb, EDS, c/o USPS DSSC/OSS/MS2 > > 4924 Green Road Raleigh, NC 27616 919 874 3043 > H > I have a TL896, and had a similiar problem of no AUTO_CLEAN supported. > @ > I wrote a some DCL that is by no means polished, but seems to  > get the job ; > done.  I run the below DCL every other week based on the - > volume of tape( > that my TL896 sees.  The DCL is below: >  > $! > $ set noon
 > $ set noverd > $!
 > $ show timeR > $!@ > $! This procedure is for a TL896 and two cleaning tapes.  The  > cleaning h? > $! tape media type CLEANING has to be created in MDMS with $ o > MDMS CREATE > > $! MEDIA_TYPE CLEANING, before cleaning tape volume entries  > can be added with 6 > $! $ MDMS CREATE VOLUME CLN### /MEDIA_TYPE=CLEANING  > /STATE=ALLOCATED.  iF > $! Periodically, additional cleaning tape volumes can be added with 6 > $! $ MDMS CREATE VOLUME CLN### /MEDIA_TYPE=CLEANING  > /STATE=ALLOCATED, as eacheH > $! cleaning tape volume reaches a mount/usage count of 20.  Or if the @ > $! INJECT_NEW_CLEANING_TAPE.COM procedure is used, the volume  > entries will > $! be added by it. > $! > $! > $ MDMS_INQ_MOUNT_COUNT == 0  > $ CLEANSLOT == 175 > $ ALTCLEANSLOT == 174a > $!> > $! Check to see if tape cleaning cartridge has been used 20  > times or so, and if > > $!  so eject it, email that a new cleaning tape needs to be  > injected, andw& > $!  use the alternate cleaning tape. > $!' > $ mdms show volume /output=volist.tmp1 > $ open/read volist volist.tmpy	 > $loop1:d% > $ read/end_of_file=endit volist rec 2 > $ slot = f$extract(f$locate("SLOT",rec),999,rec) > $ if slot .eqs. "SLOT 175" > $   then i) > $     cleanvolabel = f$extract(0,6,rec)e > $   else ? > $     goto loop1	 > $ endif- > $ close volist > $!> > $ mdms show volume 'cleanvolabel /symbols /output=volist.tmp > $ delete/nolog volist.tmp;*i$ > $ show symbol mdms_inq_mount_count% > $ if mdms_inq_mount_count .ge. "20"  > $   then e( > $   robot eject slot 'cleanslot port 11 > $   mdms inventory jukebox /slots=('cleanslot) r > $   write sys$output ""s? > $   write sys$output "The cleaning tape in slot ''cleanslot' a > is spent... ejecting!"@ > $   write sys$output "Using alternate cleaning tape from slot  > ''altcleanslot'."a= > $   write sys$output "Will move alternate cleaning tape to e > slot ''cleanslot' first."y@ > $   write sys$output "Please as soon as possible put the next  > cleaning tape"  = > $   write sys$output "barcode label on a new cleaning tape S > and place in the" = > $   write sys$output "injection port of the Vista ATL, and e > run the inject new"s1 > $   write sys$output "cleaning tape procedure."h6 > $   define/nolog sys$output new_cleaning_tape.needed > $   show process > $   deassign sys$output ? > $   mail new_cleaning_tape.needed back1 /Subject="Please run  0 > Inject New Cleaning Tape procedure on ALAXP4" ? > $   mail new_cleaning_tape.needed back2 /Subject="Please run i0 > Inject New Cleaning Tape procedure on ALAXP4" ? > $   mail new_cleaning_tape.needed back3 /Subject="Please run t0 > Inject New Cleaning Tape procedure on ALAXP4" 3 > $   robot move slot 'altcleanslot slot 'cleanslot 	 > $ endifa > $!$ > $ mdms unload drive TL896_D0 /wait& > $ robot load drive 0 slot 'cleanslot4 > $ mdms_inq_mount_count == mdms_inq_mount_count + 1 > $ wait 00:05:00e( > $ robot unload drive 0 slot 'cleanslot> > $ mdms set volume 'cleanvolabel /mount='mdms_inq_mount_count0 > $ mdms inventory jukebox ATL1 /slot='cleanslot > $!$ > $ mdms unload drive TL896_D1 /wait& > $ robot load drive 1 slot 'cleanslot4 > $ mdms_inq_mount_count == mdms_inq_mount_count + 1 > $ wait 00:05:00z( > $ robot unload drive 1 slot 'cleanslot> > $ mdms set volume 'cleanvolabel /mount='mdms_inq_mount_count0 > $ mdms inventory jukebox ATL1 /slot='cleanslot > $!  $ > $ mdms unload drive TL896_D2 /wait& > $ robot load drive 2 slot 'cleanslot4 > $ mdms_inq_mount_count == mdms_inq_mount_count + 1 > $ wait 00:05:00e( > $ robot unload drive 2 slot 'cleanslot? > $  mdms set volume 'cleanvolabel /mount='mdms_inq_mount_counte1 > $  mdms inventory jukebox ATL1 /slot='cleansloto > $!$ > $ mdms unload drive TL896_D3 /wait& > $ robot load drive 3 slot 'cleanslot4 > $ mdms_inq_mount_count == mdms_inq_mount_count + 1 > $ wait 00:05:00e( > $ robot unload drive 3 slot 'cleanslot> > $ mdms set volume 'cleanvolabel /mount='mdms_inq_mount_count0 > $ mdms inventory jukebox ATL1 /slot='cleanslot > $!$ > $ mdms unload drive TL896_D4 /wait& > $ robot load drive 4 slot 'cleanslot4 > $ mdms_inq_mount_count == mdms_inq_mount_count + 1 > $ wait 00:05:00(( > $ robot unload drive 4 slot 'cleanslot> > $ mdms set volume 'cleanvolabel /mount='mdms_inq_mount_count0 > $ mdms inventory jukebox ATL1 /slot='cleanslot > $!$ > $ mdms unload drive TL896_D5 /wait& > $ robot load drive 5 slot 'cleanslot4 > $ mdms_inq_mount_count == mdms_inq_mount_count + 1 > $ wait 00:05:00w( > $ robot unload drive 5 slot 'cleanslot> > $ mdms set volume 'cleanvolabel /mount='mdms_inq_mount_count0 > $ mdms inventory jukebox ATL1 /slot='cleanslot > $!
 > $ exit 1 > $!" > $!--------Error Routines--------	 > $endit:h > $ close volist9 > $ write sys$output "There was an error in finding slot  4 > ''cleanslot' with a cleaning tape. Please re-run." > $!
 > $ exit 1 > $!  ' :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadwayi Albany, NY  12204c USA  518-487-3255 John.C.Koska@lexisnexis.com   ) I post personal opinion only, and all thei* disclaimers one could imagine apply.  That( includes, I speak for myself only and my) views in no way represent my employer(s).l+ One should also take note of the Electronic9) Communications Privacy Act of 1986, whicht+ imposes civil and criminal liability on anyn( person who intentionally intercepts "any( wire, oral or electronic communication."   ------------------------------  % Date: Wed, 17 Oct 2001 19:16:08 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender)" Subject: Re: user authentification; Message-ID: <3bcdbcd8.524144494f47414741@radiogaga.harz.de>9  3 Hoff Hoffman (hoffman@xdelta.zko.dec.nospam) wrote:e6 > martin@radiogaga.harz.de (Martin Vorlaender) writes:6 > :Hoff Hoffman (hoffman@xdelta.zko.dec.nospam) wrote:9 > :> Mike Rechtman <michael.rechtman@digital.com> writes:f0 > :> :Depending on the language you plan to use:I > :> :1  call SYS$HASH_PASSWORD with the users parameters and the enterede > :> :passwordB > :> :2  get the quadword password field from the SYSUAF ($GETUAI)* > :> :3  compare the two quadword results. > :>, > :>   The crackers will love this approach. > :rH > :The only problem they'll have is that you need privileges for step 2. >-I >   Actually not, depending on exactly what you are up to.  You *really* 9B >   need to be careful here, lest you expose more than you expect.  F Without privileges, one account can be hacked (I agree that is one tooI many) *if* the setup is "one UIC .eq. one user". With GRPPRV, one group'stH accounts. You need SYSPRV or BYPASS to access all SYSUAF accounts. Did I miss anything?   cu,e   Martin -- lD                         | Martin Vorlaender  |  VMS & WNT programmer1  VMS is today what      | work: mv@pdv-systeme.deyE  Microsoft wants        |    http://www.pdv-systeme.de/users/martinv/o8  Windows NT 8.0 to be!  | home: martin@radiogaga.harz.de   ------------------------------    Date: 17 Oct 2001 14:44:09 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)G" Subject: Re: user authentification3 Message-ID: <fDumpFYD9pN3@eisner.encompasserve.org>b  p In article <3bcdbcd8.524144494f47414741@radiogaga.harz.de>, martin@radiogaga.harz.de (Martin Vorlaender) writes:5 > Hoff Hoffman (hoffman@xdelta.zko.dec.nospam) wrote:e7 >> martin@radiogaga.harz.de (Martin Vorlaender) writes:=7 >> :Hoff Hoffman (hoffman@xdelta.zko.dec.nospam) wrote:=: >> :> Mike Rechtman <michael.rechtman@digital.com> writes:1 >> :> :Depending on the language you plan to use:tJ >> :> :1  call SYS$HASH_PASSWORD with the users parameters and the entered >> :> :passwordiC >> :> :2  get the quadword password field from the SYSUAF ($GETUAI)=+ >> :> :3  compare the two quadword results.a >> :>D- >> :>   The crackers will love this approach.u >> :I >> :The only problem they'll have is that you need privileges for step 2.- >>J >>   Actually not, depending on exactly what you are up to.  You *really* C >>   need to be careful here, lest you expose more than you expect.n > H > Without privileges, one account can be hacked (I agree that is one tooK > many) *if* the setup is "one UIC .eq. one user". With GRPPRV, one group'smJ > accounts. You need SYSPRV or BYPASS to access all SYSUAF accounts. Did I > miss anything?   Yes.   ------------------------------  # Date: Thu, 18 Oct 2001 00:10:32 GMTs, From: "Paul Dennis" <comedyox@earthlink.not> Subject: VTEST on AlphaeC Message-ID: <Y5pz7.9518$cy.765895@newsread2.prod.itd.earthlink.net>    Hey all,  K We're using a DTM type product called VTEST on our VAXes.  We're porting toeK Alpha but we can't get hold of the original proprietor of the s/w to see ifg it's available.e  J Has anyone here (a) used it (b) know if a version exists for Alpha and (c)" know how/where it can be acquired?   TIA, .pd.   ------------------------------  % Date: Wed, 17 Oct 2001 17:00:55 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>n, Subject: Re: Wanted:SMS Center under OpenVMS+ Message-ID: <3BCDF186.3B3933D@videotron.ca>    Alan Greig wrote: G > It entirely depends on the cellular network provider. At least two ofrF > the UK cell service providers were able to provide me with a dial-up@ > number using the TAP pager protocol which interfaced with SMS.  E TAP is very basic, one way communications, usually restricted to text F messages.  There is also the SMPP protocol which is a full blown 2-wayJ functionality allowing not only text but also binary messages such as ringI tones, pbone-book entries (business cards), calendar/agenda etc etc. More 4 importantly, it allows a handset to send YOU an SMS.  L So if you want to provide a flight status service for instance, you need a 2H way protocol to allow a customer to send you an SMS with a request for aL flight status and you then send an SMS back to that person with the response< to his inquiry. TAP does not provide for that functionality.  N Another way to achieve this is to plug a handset to your vax and have your vaxM talk the proprietary protocol for that particular handset to send/receive SMSbM messages. This approach is the cheapest since yo don't really require specialuF relationaship with the network provider (needed for SMPP), but has theK disadvantage of having less reliability (if the handset shuts off, you needc> someone to physically press the ON button again for instance).   ------------------------------  # Date: Wed, 17 Oct 2001 21:56:07 GMTg3 From: Burnie Morgan <burniem.NOSPAM@ozemail.com.au>e, Subject: Re: Wanted:SMS Center under OpenVMS8 Message-ID: <65vrsto270jgki7rdh3qiu1it8sdes1ml4@4ax.com>  3 Then certainly SEMA is a lead player in this field.i  < Please note that non UK support offices have a 'lack of fullA information' about their own product and you should tie down youre! support contract wirth penalties.B  < Also, before signing, I suggest that you review the hardwareC configuration proposed (SEMA only sell a combined software/hardware7B package). Their current HP SMSC is not configured in a robust way.  F If you propose to use SEMAs own IMD then note the lack of full billingE information passed on IP (DECnet services are fine). This is an issue D if you wish to allow Internet access to the IMD in a DMZ and run the SMSC in your internal network.B SEMA staff suggested to us that we tunnel DECnet thru a firewall !   Burnie M    C On Wed, 17 Oct 2001 15:22:20 +0100, Alan Greig <a.greig@virgin.net>n wrote:  8 >On Wed, 17 Oct 2001 16:06:11 +0400, "Ruslan R. Laishev"" ><Laishev@SMTP.DeltaTel.RU> wrote: >n >>U >>	We are mobile phone company, and we need to interoperate with MSC with a TCAP/SS7.n >> >>	Anyway thanks for the info. >iE >That makes a huge difference!! I assumed you just wanted to send SMSo	 >from VMSp >  >>Alan Greig wrote:  >>> ; >>> On Wed, 17 Oct 2001 14:57:39 +0400, "Ruslan R. Laishev" % >>> <Laishev@SMTP.DeltaTel.RU> wrote:r >>> 
 >>> >Hi Alan, ` >>> >       the SMS-ing you described is sort of paging, and it's not allow to writting SMS from >>> >cell-phone, is not ?a >>> I >>> It entirely depends on the cellular network provider. At least two ofnH >>> the UK cell service providers were able to provide me with a dial-upJ >>> number using the TAP pager protocol which interfaced with SMS. There'sI >>> very little difference after all in sending a text message to a pagersH >>> and a text message to a phone. At least one other provider could notA >>> provide such an interface but did point me at an alternative.n >>>  >>> >Alan Greig wrote: >>> >>> >>> >> On Wed, 17 Oct 2001 10:21:27 +0400, "Ruslan R. Laishev"( >>> >> <Laishev@SMTP.DeltaTel.RU> wrote: >>> >> >>> >> >Hi All!oa >>> >> >       I looking for Short Message Service soluting for the OpenVMS, any pointers will bel >>> >> >greatly appreciated. >>> >>L >>> >> I've used the Ckermit TAP scripts to send SMS messages before. If theH >>> >> cellphone company you use provides a TAP ( Telocator AlphanumericJ >>> >> Protocol) dial-up interface then the kermit APAGE script will work.J >>> >> Alternatively some providers have email to SMS or web/SMS gateways. >>> >>; >>> >> Here's the header info from the Kermit sample scriptl >>> >> >>> >> ; >>> >> ; File APAGE.KSC  >>> >> ; Version 4.0 >>> >> ;D >>> >> if < \v(version) 700000 end 1 C-Kermit 7.0 or later required. >>> >>G >>> >> ; TAP/IXO alphanumeric paging script for Kermit 95 and C-Kermit.)K >>> >> ; Authors: F. da Cruz and C. Gianone, Columbia University, Septemberi >>> >> 1996. >>> >> ;9 >>> >> ; For use with C-Kermit 7.0 / K95 1.1.17 or later.aG >>> >> ; For a detailed explanation, consult "Using C-Kermit", 2nd Ed.,l >>> >> pp.454-456. >>> >> ; >>> >> >>> >> >       TIA.t >>> >>	 >>> >> --  >>> >> Alan  >>>  >>> -- >>> Alan   ------------------------------  # Date: Thu, 18 Oct 2001 02:47:19 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>5 Subject: Re: We've burned our boats say Compaq and HP > Message-ID: <Xorz7.130316$vq.28833323@typhoon.ne.mediaone.net>  F "Brian Tillman" <tillman_brian@notnoone.notnohow.com> wrote in message news:3bc6fe06$1@news.si.com...L > >Ah, so you are aware of the SCULPTOR project? Then you probably know that aoB > >well-dressed gentleman of Italian heritage spiked that program. >gL > I hate it when you're cryptic, Terry.  What does this mean???  Shannon mayJ > know, but some of the rest of us don't and when you couch things in yourF > insider code like this, the rest of us just sit scratching our heads$ > thinking "What the hell it that?".  L It was an initiative to render Windows NT "industrial strength." It involvedH the porting of the NonStop SQL/MX database to NT, the porting of the VMSG cluster file system and DLM to NT, and the porting of several other VMS K products to NT. Much of the work was actually done, but the plug was pulled C in mid-1999. Had the project gone forward Alpha would have been the0 reference platform for Win64.M  & Shoulda, woulda, coulda, but didn't...   ------------------------------    Date: 18 Oct 2001 02:56:46 +0800, From: Paul Repacholi <prep@prep.synonet.com>3 Subject: Re: Windows Fails To Storm the Data Centre-- Message-ID: <87wv1u9jtd.fsf@prep.synonet.com>   , Arne Vajhj <arne.vajhoej@gtech.com> writes:   > Jerry Leslie wrote:  ... D > > The pro-Microsoft PHBs are fond of saying "Well, NT is where VMS< > > 3.x was".  A fairer comparision is to compute the age ofC > > WNT/W2K/WXP, and then look to see where VMS was after that manyn? > > years. VMS 3.x is still ahead of today's NT in reliability.n  E > I think there are a basic flaw in the logic "OK - maybe MS softwareqE > are not ssecure and reliable today, but it will be next year, so weiF > should switch to it now": MS software are not getting better - it is > getting worse over time !!!!  D M$ reliability is constant, it is always the least that 'the market'E will put up with. Excess quality is removed in release versions so as & to ensure the flow of service revinue.  E So it does not matter a damm if NT *can* be useful, the only questionTF is will billyboy *let* it... Untill that changes, then you are hangingC by a thread and are totally at M$'s mercy. BTW, remember to get all  the promises in writing...   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Wed, 17 Oct 2001 15:00:55 -0400e0 From: "Syltrem" <syltrem@videotron.spammenot.ca>$ Subject: Re: writing to shared files5 Message-ID: <Wvkz7.69782$TW.367080@tor-nn1.netcom.ca>g  6 You must do a $FLUSH to have the data written to disk.   --   SyltremYI http://pages.infinit.net/syltrem (OpenVMS related web site - en franais)e> To reply to myself directly, remove .spammenot from my address  K "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans le message.0 news: 3BCDC4F1.95EF58F3@EDV-Berater-Online.de...G > With DCL there is a command SET OUTPUT_RATE. I use this with detachedpD > processes to look continuously at output from the program running. >eE > I tried to get the same effect with log files directly written by a F > program developped in FORTRAN. However, I was not successful. I used@ > OPEN (USEROPEN=function) and tried several options in the FAB. >dA > Does anyone know which bits have to be set in which FAB fields?" >c	 > Thanks.  >  > Lothar Geyer   ------------------------------  % Date: Wed, 17 Oct 2001 21:14:05 +0200l7 From: Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> $ Subject: Re: writing to shared files5 Message-ID: <3BCDD87D.71363839@EDV-Berater-Online.de>m   Syltrem schrieb: > 8 > You must do a $FLUSH to have the data written to disk.  ( And how to do that in a FORTRAN program?   Lothar Geyer >  > -- > 	 > SyltremxK > http://pages.infinit.net/syltrem (OpenVMS related web site - en franais)h@ > To reply to myself directly, remove .spammenot from my address > M > "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans le message.2 > news: 3BCDC4F1.95EF58F3@EDV-Berater-Online.de...I > > With DCL there is a command SET OUTPUT_RATE. I use this with detachedeF > > processes to look continuously at output from the program running. > >tG > > I tried to get the same effect with log files directly written by atH > > program developped in FORTRAN. However, I was not successful. I usedB > > OPEN (USEROPEN=function) and tried several options in the FAB. > >gC > > Does anyone know which bits have to be set in which FAB fields?i > >s > > Thanks.  > >l > > Lothar Geyer   ------------------------------  % Date: Wed, 17 Oct 2001 15:45:49 -0400o0 From: "Syltrem" <syltrem@videotron.spammenot.ca>$ Subject: Re: writing to shared files5 Message-ID: <0alz7.69786$TW.367049@tor-nn1.netcom.ca>c  J call sys$flush with the RAB address as a oarameter (you get get it in your useropen routine).  F Don't have an example at hand. Lookup the documentation, all is there.   --   SyltremrI http://pages.infinit.net/syltrem (OpenVMS related web site - en franais)u> To reply to myself directly, remove .spammenot from my address  K "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans le messaged0 news: 3BCDD87D.71363839@EDV-Berater-Online.de... > Syltrem schrieb: > > : > > You must do a $FLUSH to have the data written to disk. >o* > And how to do that in a FORTRAN program? >i > Lothar Geyer > >  > > -- > >0 > > Syltrem C > > http://pages.infinit.net/syltrem (OpenVMS related web site - enu	 franais)qB > > To reply to myself directly, remove .spammenot from my address > > G > > "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans let messages4 > > news: 3BCDC4F1.95EF58F3@EDV-Berater-Online.de...K > > > With DCL there is a command SET OUTPUT_RATE. I use this with detachedlH > > > processes to look continuously at output from the program running. > > >'I > > > I tried to get the same effect with log files directly written by aeJ > > > program developped in FORTRAN. However, I was not successful. I usedD > > > OPEN (USEROPEN=function) and tried several options in the FAB. > > >mE > > > Does anyone know which bits have to be set in which FAB fields?x > > >s
 > > > Thanks.  > > >  > > > Lothar Geyer   ------------------------------  % Date: Wed, 17 Oct 2001 22:07:21 +0200c7 From: Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> $ Subject: Re: writing to shared files5 Message-ID: <3BCDE4F9.915C6975@EDV-Berater-Online.de>t  H So I will have to call sys$flush after every write - and there is no way* to tell RMS once to save all data on disk?   Lothar Geyer   Syltrem schrieb: > L > call sys$flush with the RAB address as a oarameter (you get get it in your > useropen routine). > H > Don't have an example at hand. Lookup the documentation, all is there. >  > -- > 	 > SyltremeK > http://pages.infinit.net/syltrem (OpenVMS related web site - en franais)h@ > To reply to myself directly, remove .spammenot from my address > M > "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans le message12 > news: 3BCDD87D.71363839@EDV-Berater-Online.de... > > Syltrem schrieb: > > >e< > > > You must do a $FLUSH to have the data written to disk. > >2, > > And how to do that in a FORTRAN program? > >  > > Lothar Geyer > > >i > > > -- > > > 
 > > > SyltrempE > > > http://pages.infinit.net/syltrem (OpenVMS related web site - ene > franais)pD > > > To reply to myself directly, remove .spammenot from my address > > >aI > > > "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans len	 > messagei6 > > > news: 3BCDC4F1.95EF58F3@EDV-Berater-Online.de...M > > > > With DCL there is a command SET OUTPUT_RATE. I use this with detached0J > > > > processes to look continuously at output from the program running. > > > >iK > > > > I tried to get the same effect with log files directly written by aHL > > > > program developped in FORTRAN. However, I was not successful. I usedF > > > > OPEN (USEROPEN=function) and tried several options in the FAB. > > > > G > > > > Does anyone know which bits have to be set in which FAB fields?n > > > >l > > > > Thanks.t > > > >  > > > > Lothar Geyer   ------------------------------  % Date: Wed, 17 Oct 2001 16:32:54 -0400 0 From: "Syltrem" <syltrem@videotron.spammenot.ca>$ Subject: Re: writing to shared files5 Message-ID: <9Slz7.69788$TW.367240@tor-nn1.netcom.ca>s   >there is no way, > to tell RMS once to save all data on disk?  J Not sure about this one for sequential files. I use sys$flush, maybe there% is a better method I am not aware of.    --   SyltremlI http://pages.infinit.net/syltrem (OpenVMS related web site - en franais) > To reply to myself directly, remove .spammenot from my address  K "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans le messageP0 news: 3BCDE4F9.915C6975@EDV-Berater-Online.de...J > So I will have to call sys$flush after every write - and there is no way, > to tell RMS once to save all data on disk? >  > Lothar Geyer >e > Syltrem schrieb: > > I > > call sys$flush with the RAB address as a oarameter (you get get it in! your > > useropen routine). > > J > > Don't have an example at hand. Lookup the documentation, all is there. > >l > > -- > >e > > SyltremaC > > http://pages.infinit.net/syltrem (OpenVMS related web site - en@	 franais)mB > > To reply to myself directly, remove .spammenot from my address > >dG > > "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans le( messaged4 > > news: 3BCDD87D.71363839@EDV-Berater-Online.de... > > > Syltrem schrieb: > > > > > > > > > You must do a $FLUSH to have the data written to disk. > > >c. > > > And how to do that in a FORTRAN program? > > >p > > > Lothar Geyer > > > >a
 > > > > -- > > > >  > > > > SyltremSG > > > > http://pages.infinit.net/syltrem (OpenVMS related web site - en2
 > > franais)oF > > > > To reply to myself directly, remove .spammenot from my address > > > >rK > > > > "Lothar Geyer" <Lothar.Geyer@EDV-Berater-Online.de> a crit dans leh > > messagem8 > > > > news: 3BCDC4F1.95EF58F3@EDV-Berater-Online.de...F > > > > > With DCL there is a command SET OUTPUT_RATE. I use this with detachedL > > > > > processes to look continuously at output from the program running.	 > > > > >sK > > > > > I tried to get the same effect with log files directly written byi aoI > > > > > program developped in FORTRAN. However, I was not successful. IR usedH > > > > > OPEN (USEROPEN=function) and tried several options in the FAB.	 > > > > >-I > > > > > Does anyone know which bits have to be set in which FAB fields?s	 > > > > >@ > > > > > Thanks.j	 > > > > >o > > > > > Lothar Geyer   ------------------------------    Date: 17 Oct 2001 15:40:16 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)o$ Subject: Re: writing to shared files3 Message-ID: <qI46e7weKGev@eisner.encompasserve.org>   o In article <3BCDE4F9.915C6975@EDV-Berater-Online.de>, Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> writes:wJ > So I will have to call sys$flush after every write - and there is no way, > to tell RMS once to save all data on disk?  ? Presumably you are concerned about the effort the computer must:= make to make two calls, rather than the effort the programmero must make to code two calls.  < Making an extra call to RMS involves an insignificant amount4 of effort compared to actually writing data to disk.   ------------------------------  % Date: Thu, 18 Oct 2001 00:33:35 +0200e7 From: Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de>i$ Subject: Re: writing to shared files5 Message-ID: <3BCE073F.10D45E12@EDV-Berater-Online.de>b   Larry Kilgallen schrieb: > q > In article <3BCDE4F9.915C6975@EDV-Berater-Online.de>, Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> writes: L > > So I will have to call sys$flush after every write - and there is no way. > > to tell RMS once to save all data on disk? > A > Presumably you are concerned about the effort the computer must ? > make to make two calls, rather than the effort the programmerb > must make to code two calls.  B I am not concerned about the the two calls the AXP and VMS have to handle.aH However, if there are a lot of WRITE statements in the program I have toE code a lot of calls to SYS$FLUSH and the probability to forget one isM high.s  > > Making an extra call to RMS involves an insignificant amount6 > of effort compared to actually writing data to disk.  G I know. But this machine is not very busy. One computer sends a messageaG every 6 or 7 minutes with an order number. Then order data is read fromiG an Oracle database and distributed to almost 20 other machines (each in0  a different format). That's all.   Lothar Geyer   ------------------------------    Date: 17 Oct 2001 21:18:14 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)a$ Subject: Re: writing to shared files3 Message-ID: <XRQG93H5GFTA@eisner.encompasserve.org>u  o In article <3BCE073F.10D45E12@EDV-Berater-Online.de>, Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> writes:t > Larry Kilgallen schrieb: >> er >> In article <3BCDE4F9.915C6975@EDV-Berater-Online.de>, Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> writes:M >> > So I will have to call sys$flush after every write - and there is no wayf/ >> > to tell RMS once to save all data on disk?a >>  B >> Presumably you are concerned about the effort the computer must@ >> make to make two calls, rather than the effort the programmer >> must make to code two calls.r > D > I am not concerned about the the two calls the AXP and VMS have to	 > handle.!J > However, if there are a lot of WRITE statements in the program I have toG > code a lot of calls to SYS$FLUSH and the probability to forget one iss > high.a  B If there is no way to force this through RMS setting (and I am notB convinced on that), the proper software engineering approach would? be to remove _all_ WRITE statements and replace them with callssF to a new subroutine that does a WRITE followed by a call to SYS$FLUSH.   ------------------------------    Date: 17 Oct 2001 22:42:49 -0700" From: cstranslations@msn.com (Joe)$ Subject: Re: writing to shared files= Message-ID: <d56d1c2d.0110172142.3267f30e@posting.google.com>   t Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> wrote in message news:<3BCE073F.10D45E12@EDV-Berater-Online.de>... > Larry Kilgallen schrieb: > > s > > In article <3BCDE4F9.915C6975@EDV-Berater-Online.de>, Lothar Geyer <Lothar.Geyer@EDV-Berater-Online.de> writes:.N > > > So I will have to call sys$flush after every write - and there is no way0 > > > to tell RMS once to save all data on disk? > > C > > Presumably you are concerned about the effort the computer musteA > > make to make two calls, rather than the effort the programmerO  > > must make to code two calls. > D > I am not concerned about the the two calls the AXP and VMS have to	 > handle.lJ > However, if there are a lot of WRITE statements in the program I have toG > code a lot of calls to SYS$FLUSH and the probability to forget one isI > high.t  A Depending on the needs of the application I suppose one could notlD worry about calling sys$flush after each write. Rather one could set@ up a timer to expire at regular intervals (sys$setimr). The sole> purpose of this timer request would be to then call sys$flush.   Joet   ------------------------------   End of INFO-VAX 2001.579 ************************