1 INFO-VAX	Thu, 28 Jun 2001	Volume 2001 : Issue 355       Contents:- 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+ < Re: =?iso-8859-1?Q?StorageWorks=AE?= MSL 5026SL Tape Library+ Re: Advance Server error after installation I Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence)  Re: BACKUP listing []  RE: BACKUP listing []  Re: Changing platforms.  Re: Changing platforms.  Re: Changing platforms.  Re: Changing platforms.  Re: Changing platforms.  Re: Changing platforms.  Re: Changing platforms.  Re: Changing platforms. $ Re: Compaq proves their incompetence$ Re: Compaq proves their incompetenceJ Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design  team...)I Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) P Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) team..( Re: Compaq's Alpha design team for sale? DCPS 1.8 with LEXMARK T616& Re: Disk Cluster Size for Oracle Disks& Re: Disk Cluster Size for Oracle Disks& Re: Disk Cluster Size for Oracle Disks FastCash Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FUD  Re: Full port of VMS to Itanium A Re: Full port of VMS to Itanium (was: What does Alphas dead mean)   RE: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium. GEM (was: Compaq proves)  Golden Opportunity for Microsoft$ RE: Golden Opportunity for Microsoft$ RE: Golden Opportunity for Microsoft$ Re: Golden Opportunity for Microsoft$ Re: Golden Opportunity for Microsoft$ Re: Golden Opportunity for Microsoft$ RE: Golden Opportunity for Microsoft$ Re: Golden Opportunity for Microsoft Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World % Re: Itanium, non-issue, stop the mail  little help please Re: NYSE Re: NYSE% One more dreadful thought to consider 6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry ShannonP Re: Question to Charlie Matco - reply to Terry Shannon (and some general commentP Re: Question to Charlie Matco - reply to Terry Shannon (and some general commentP Re: Question to Charlie Matco - reply to Terry Shannon (and somegeneral comments
 RE: Rdb troll  Read other user's mail Re: Read other user's mail RE: Read other user's mail Re: Read other user's mailP Re: Reward for the first of the next 50 posts: which company	shouldbuy VMS VMSVM! Re: ROSS GemBase on OpenVMS Alpha ! Re: ROSS GemBase on OpenVMS Alpha  Salt in the Wounds@ SRM Auto_action: what's the difference between BOOT and RESTART?5 Re: Standalone Teco (was Re: VMS on IA64 (technical)) 5 Re: Standalone Teco (was Re: VMS on IA64 (technical)) 5 Re: Standalone Teco (was Re: VMS on IA64 (technical)) 5 RE: Standalone Teco (was Re: VMS on IA64 (technical)) 5 RE: Standalone Teco (was Re: VMS on IA64 (technical)) ) Re: StorageWorks MSL 5026SL Tape Library 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 6 Trapping telnet disconnects (no dead Alpha references)* Re: Upgrade to 7.3 migrating CA Ingres 6.4 vax 4000/90 < RE: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< RE: Wailing and moaning... (was: Question to Charlie Matco.)< RE: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< RE: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.) Re: Wailing and moaning....  Wailing and moaning.... ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ! Which group for VMS hardware ads? % Re: Which group for VMS hardware ads? ' Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either P Re: [OT] IBM Slow and sclerotic?  ( Was Re: Compaq's Alpha design team for sale?  F ----------------------------------------------------------------------  % Date: Wed, 27 Jun 2001 15:51:18 -0400 % From: "Chuck Viau" <viau@process.com> 6 Subject: 3 Reasons why VMS is alive and probably well++ Message-ID: <9hddk4$5f0$1@news.process.com>   - 3 Reasons why VMS is alive and probably well+   H 1. VMS is firmly entrenched in our Military , Financial , Scientific and Medical industries. E That is an undisputable fact, and is not likely to change in the near  future. There are billionsK of lines of hard earned, expensive debugged code running on these Vax's and  Alpha's and most of E these users will not fix what is not broken.  That alone will drive a  successful port to the IA64.  K 2. In my experience, even on it's worst day, a machine(s)  running VMS will  be an order ofH magnitude more reliable than on ANY NT or W2k server in it's class.  You just have to work : for a .com relying on IIs for a few years to realize this.  J 3. With the industry support that the IA64 will inherit, then so VMS reaps the support it did not get from the Alpha.    Good things indeed.    ------------------------------  % Date: Wed, 27 Jun 2001 23:35:03 -0400 2 From: rdeininger@mindspring.com (Robert Deininger): Subject: Re: 3 Reasons why VMS is alive and probably well+L Message-ID: <rdeininger-2706012335040001@user-2ivecak.dialup.mindspring.com>  8 In article <9hddk4$5f0$1@news.process.com>, "Chuck Viau" <viau@process.com> wrote:   / > 3 Reasons why VMS is alive and probably well+  > J > 1. VMS is firmly entrenched in our Military , Financial , Scientific and > Medical industries.   : I would like to agree with you, but scientists are largelyH herd-followers.  VMS is no longer faddish in scientific circles, and theI most sheep-like among us actively sabotage VMS when they see it.  The fad I has moved from VMS through various Unix flavors, and is presently sitting  in the linux neighborhood.  H One of the strengths of VMS, reliability, is not valued in most researchF environments.  The motto seems to be, "if it's worth doing, it's worth8 doing over, and over, and over..." until it seems right.  J Years ago, VMS found it's way into many labs because a huge array of weirdJ equipement could be attached to a Vax.  In that role VMS has been replacedJ by peecees running Labview and other nasty toys.  Or, if performance is atE all an issue, by unixy modular computers living in VME busses or some  such.   F In December, I heard Rich Marcello (then VP in charge of VMS) say thatI they aren't making any effort to push VMS in science and research.  Tru64 A was worth the effort, but VMS has much greener pastures to graze.   J Military folks have been dabbling in the fads as well, but they do have toF worry about reliability.  VMS probably remains strong, particularly in< older systems.   Life cycles are long in military equipment.  I According to Compaq, Financial and Medical are industries where VMS is at  its strongest.   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Wed, 27 Jun 2001 14:39:52 -0400 ( From: Hamlyn Mootoo <univms@bigfoot.com>E Subject: Re: =?iso-8859-1?Q?StorageWorks=AE?= MSL 5026SL Tape Library + Message-ID: <3B3A2878.CF46B533@bigfoot.com>   0 This suggestion is more in the "other" category:G Buy some big disks (if you don't have them already) and do disk to disk D backups so you can get your batch jobs rolling as soon as possible. A That way you can shove the data to tape at your leisure.  I'm not H familar with MUMPS databases so I don't know if the following suggestionE is applicable, but I would suggest getting as many tape drives as you G can so you can stream your I/O in parallel as much as possible, cutting C down the time to actually get the data off disk (whether primary or  backup disks) onto tape.   HM   "Jay E. Morris" wrote: > K > Ok, looks like we might be going to 2 shifts which means that I've got to M > reduce my nightly backup time.  I've already played all the software tricks K > (block size, quotas, etc) so I've got to go to a faster drive.  Currently L > using a TZ88 that we swap tapes in everyday.  The backup of the productionK > databases take about 3+ hours for about 50GB.  Yes, we run verify.  These N > are Mumps databases so we have to take the production software down. BecauseN > of the increased workload we're expecting I think the databases will grow toI > about 80-100GB.  The TZ88 ain't gonna cut it.  There's bunches of batch N > processing that has to occur after backup and before 1st shift.  Rest of theI > backup can take all day far as I'm concerned, as long as the production  > system is back up in time. > 
 > I'm runing: . > AlphaServer 2100 (no, I didn't forget the A). > AlphaServer 1000 (no, I didn't forget the A) > RA3000 > OpenVMS 7.2-1 (7.3 rsn) L > The Alphas have the QLogic ISP1020 SCSI which are connected to the RA3000." > I have KZPBA-CX cards available. > M > So I'm thinking about using the StorageWorks MSL 5026SL Tape Library with 1 K > drive (mainly because of the throughput but size counts).  So I'm looking  > for: > & > Good/bad experience with this thing.N > Is it going to work with this setup (I'm a little confused because the specsF > for the SDLT drive itself shows the KZPBA but the library only shows5 > 3X-KZPEA-DB and this won't work in the 1000/2100*.)  > Other backup suggestions.  > N > *but if the drive itself works with the KZPBA then I may still be stuck with: > changing tapes.  Or use it as an excuse for a new Alpha. >  > Jay E. Morris . > System Software Specialist (Sys/Net Manager) > General Dynamics, WTS # > Lead, Medical Information Systems : > Epidemiological Surveillance Division (AFIERA/SDE (MIS)) > Brooks AFB, TX   ------------------------------    Date: 28 Jun 2001 03:08:52 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)4 Subject: Re: Advance Server error after installation* Message-ID: <3b3a83a4$1@news.kapsch.co.at>  Z In article <tjh4r362v8rq61@corp.supernews.com>, "Thomas Steuver" <steuver@nku.edu> writes:H >I installed Advance Server V7.3 on OpenVMS.  The installation performedM >without errors.  When I run the pwrk$config.com procedure however, I get the  >following error then aborts:  > > >Checking to see if OpenVMS Registry Services are available...= >The OpenVMS Registry server is already started on this node. 2 >%REG-E-DBNOTYETLOADED, database is not yet loaded4 >%REGUTL-W-NOTINREG, known but not found in registry: >%PWRK-E-NOTMIGRATED, entire lanman.ini file not processed > J >I can't find this error anywhere in documentation.  Does anyone know what% >the problem is and how I can fix it?   G Did you run the configuration procedure of the registry server before ? B ASOVMS V7 requires the registry server (instead of the LANMAN.INI)A and starts it if not running. But it seems, the startup procecure 2 does not define the database location permanently.  G So, define the SYS$REGISTRY yourself (eg. in SYLOGICALS.COM), start the E registry server yourself and check with the REG$CP if the registry is J working at all, before you continue to the ASOVMS problems (means, running PWRK$CONFIG again).    HIH    --  < Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  # Date: Wed, 27 Jun 2001 20:21:28 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)R Subject: Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence)1 Message-ID: <cfr_6.213$rc5.5812@news.cpqcorp.net>   ` In article <9gvjjtcj43jm4k6elk96j5eja9cqetc6t2@4ax.com>, Alan Greig <a.greig@virgin.net> writes: ..D :Hoff, I really hope that your cheery disposition indicates that youC :might be further ahead then we all think. Can you confirm that the E :iVMS port will not have to wait for some mythical server released in C :2004 if all goes well. Are you targeting even a limited release at . :current or near current IA64 Compaq hardware?     I do not know.    E   I do not know of any specific IPF microprocessors that are (or are  A   not) targets for the port, and the same holds for specific IPF  C   system targets.  AFAIK, none of that has been decided, and little !   of it has even been considered.   D   OpenVMS Engineering is presently examining the existing Intel IPF    documentation.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 27 Jun 2001 16:50:14 -0400   From: John Santos <JOHN@egh.com> Subject: Re: BACKUP listing []6 Message-ID: <1010627164310.38769A-100000@Ives.egh.com>  ) On Wed, 27 Jun 2001, Terry Aardema wrote:    > Ingemar Olson wrote: > > D > > I had occasion to actually *look* at one of our backup listings.L > > At the end there were a large number of files which were listed as being" > > in directory "[]" (ie: blank).C > > When I check the disk I find they *are* in an actual directory.    [...]    > E > If you BACKUP/IMAGE groupA: ..., you get an image backup of all the J > files under groupA:[000000...], followed by *ALL* the remaining files onJ > $x$userdisk:; but these files will appear in the backup listing to be inB > the [] (i.e. no) directory. In other words, an IMAGE backup of aD > subdirectory on a volume backups the *ENTIRE* volume (just as HELPI > BACKUP/IMAGE clearly states). It would be nice if BACKUP would at least H > spit out a warning ("%BACKUP-I-IMGLOG, groupA is a logical; the entire6 > contents of $x$userdisk will be backed up"), but ... >  > HTH  >  > Terry Aardema   H To quote Spock: "Facinating."  I never thought of that as a possibility.  > Check this out first, rather than risk messing around with the file structure on the disk.   4 Any other strange ways to get files in [] directory?   Mr. Olson -   @ Could you please post the complete backup command so the rest of us can dissect it?   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Wed, 27 Jun 2001 14:18:26 -0700 . From: "Olson, Ingemar" <IOlson@dairyworld.com> Subject: RE: BACKUP listing []M Message-ID: <763C579A82F7D3118EE400D0B74723D1041A31A4@exchsrv.dairyworld.com>   J This message is in MIME format. Since your mail reader does not understand< this format, some or all of this message may not be legible.  ' ------_=_NextPart_001_01C0FF4E.B4564AE0  Content-Type: text/plain;  	charset="iso-8859-1"   * >On Wed, 27 Jun 2001, Terry Aardema wrote: >  >> Ingemar Olson wrote:  >> >  E >> > I had occasion to actually *look* at one of our backup listings. G >> > At the end there were a large number of files which were listed as  being # >> > in directory "[]" (ie: blank). D >> > When I check the disk I find they *are* in an actual directory. >  >[...] >  >>  F >> If you BACKUP/IMAGE groupA: ..., you get an image backup of all theK >> files under groupA:[000000...], followed by *ALL* the remaining files on K >> $x$userdisk:; but these files will appear in the backup listing to be inkC >> the [] (i.e. no) directory. In other words, an IMAGE backup of alE >> subdirectory on a volume backups the *ENTIRE* volume (just as HELPoJ >> BACKUP/IMAGE clearly states). It would be nice if BACKUP would at leastI >> spit out a warning ("%BACKUP-I-IMGLOG, groupA is a logical; the entirep7 >> contents of $x$userdisk will be backed up"), but ...r >>   >> HTH >> p >> Terry Aardema >iI >To quote Spock: "Facinating."  I never thought of that as a possibility.i >n? >Check this out first, rather than risk messing around with thel >file structure on the disk. >T5 >Any other strange ways to get files in [] directory?a >. >Mr. Olson - >aA >Could you please post the complete backup command so the rest of  >us can dissect it?s >--  >John Santos >Evans Griffiths & Hart, Inc.  >781-861-0670 ext 539r  < Sure. Although I don't think there are any weirdnesses here.  ) $  BACKUP                               -e)         /IMAGE                          -M)         /NOALIAS                        - )         /BLOCK=65534                    - )         /RECORD                         - )         /IGNORE=(INTERLOCK,LABEL)       -a)         /NOASSIST                       - )         /NOREWIND                       -p)         /MEDIA_FORMAT=COMPACTION        -S1         /LIST=BKUPLOGS:'DEVICE'-FUL-LOG.'TDATE' - 4         /JOURNAL=BKUPJNLS:'DEVICE'-FUL-BJL.'TDATE' -         'DEVICE': -r#         'DLTG3''TWDAY''count'.BCK -f         /LABEL='WDAY6'  4 DEVICE is a symbol that contains the name of a DISK.< DLTG3  is a symbol that contains the name of the tape drive.$ the other symbols are just literals.  H I have subsequently discovered that the incremental backups for the same diskL do NOT exhibit this symptom. So that kinda rules out any setup issues that I can J think of. (This is for the "other" disk I originally referred to. We don't do i" incrementals of the system disk.)   L Although I did discover that on the system disk all the open files are shownG in SYSCOMMON, not VMS$COMMON, so we've got a (probably different) issuei
 there too.B I'd prefer to deal with just one thing at a time, so let me try to understand the rJ backlink a bit better (on my own time) before I have another look at that.  L Anyway, about the "other" disk, I posted a question with the wizard since it looks J more like a bug or overflow problem with BACKUP. By that I mean that it is not consistentK between incremental and image backups, *and/or* that the number of files inc the misreportediK directory's parent directory is quite large (20,000+), with these files allu
 being in a3 subdirectory which is last in the parent directory.    Eg:  disk:[ABC.DATA]=      entries for 20,000+ files plus some other subdirectorieso      ZZZ_ARCHIVE.DIR      hJ and it's all the files in and below ZZZ_ARCHIVE that are being misreported on the BACKUP  LISTing.  ' ------_=_NextPart_001_01C0FF4E.B4564AE0m Content-Type: text/html; 	charset="iso-8859-1"u+ Content-Transfer-Encoding: quoted-printable   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">4 <HTML> <HEAD>9 <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =  charset=3Diso-8859-1">@ <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
 5.5.2653.12"> $ <TITLE>RE: BACKUP listing []</TITLE> </HEAD>h <BODY>  F <P><FONT SIZE=3D2>&gt;On Wed, 27 Jun 2001, Terry Aardema wrote:</FONT> <BR><FONT SIZE=3D2>&gt;</FONT>7 <BR><FONT SIZE=3D2>&gt;&gt; Ingemar Olson wrote:</FONT> ( <BR><FONT SIZE=3D2>&gt;&gt; &gt; </FONT>G <BR><FONT SIZE=3D2>&gt;&gt; &gt; I had occasion to actually *look* at =g" one of our backup listings.</FONT>G <BR><FONT SIZE=3D2>&gt;&gt; &gt; At the end there were a large number = * of files which were listed as being</FONT>C <BR><FONT SIZE=3D2>&gt;&gt; &gt; in directory &quot;[]&quot; (ie: =E blank).</FONT>D <BR><FONT SIZE=3D2>&gt;&gt; &gt; When I check the disk I find they =$ *are* in an actual directory.</FONT> <BR><FONT SIZE=3D2>&gt;</FONT># <BR><FONT SIZE=3D2>&gt;[...]</FONT>n <BR><FONT SIZE=3D2>&gt;</FONT># <BR><FONT SIZE=3D2>&gt;&gt; </FONT>oI <BR><FONT SIZE=3D2>&gt;&gt; If you BACKUP/IMAGE groupA: ..., you get an =a image backup of all the</FONT>I <BR><FONT SIZE=3D2>&gt;&gt; files under groupA:[000000...], followed by = # *ALL* the remaining files on</FONT>oG <BR><FONT SIZE=3D2>&gt;&gt; $x$userdisk:; but these files will appear =d% in the backup listing to be in</FONT> I <BR><FONT SIZE=3D2>&gt;&gt; the [] (i.e. no) directory. In other words, =w an IMAGE backup of a</FONT> B <BR><FONT SIZE=3D2>&gt;&gt; subdirectory on a volume backups the =$ *ENTIRE* volume (just as HELP</FONT>G <BR><FONT SIZE=3D2>&gt;&gt; BACKUP/IMAGE clearly states). It would be =e$ nice if BACKUP would at least</FONT>I <BR><FONT SIZE=3D2>&gt;&gt; spit out a warning (&quot;%BACKUP-I-IMGLOG, =n& groupA is a logical; the entire</FONT>D <BR><FONT SIZE=3D2>&gt;&gt; contents of $x$userdisk will be backed = up&quot;), but ...</FONT>-# <BR><FONT SIZE=3D2>&gt;&gt; </FONT>-& <BR><FONT SIZE=3D2>&gt;&gt; HTH</FONT># <BR><FONT SIZE=3D2>&gt;&gt; </FONT>o0 <BR><FONT SIZE=3D2>&gt;&gt; Terry Aardema</FONT> <BR><FONT SIZE=3D2>&gt;</FONT>H <BR><FONT SIZE=3D2>&gt;To quote Spock: &quot;Facinating.&quot;&nbsp; I =. never thought of that as a possibility.</FONT> <BR><FONT SIZE=3D2>&gt;</FONT>G <BR><FONT SIZE=3D2>&gt;Check this out first, rather than risk messing =  around with the</FONT>9 <BR><FONT SIZE=3D2>&gt;file structure on the disk.</FONT>i <BR><FONT SIZE=3D2>&gt;</FONT>B <BR><FONT SIZE=3D2>&gt;Any other strange ways to get files in [] = directory?</FONT>a <BR><FONT SIZE=3D2>&gt;</FONT>) <BR><FONT SIZE=3D2>&gt;Mr. Olson -</FONT>e <BR><FONT SIZE=3D2>&gt;</FONT>B <BR><FONT SIZE=3D2>&gt;Could you please post the complete backup = command so the rest of</FONT>c0 <BR><FONT SIZE=3D2>&gt;us can dissect it?</FONT>! <BR><FONT SIZE=3D2>&gt;-- </FONT>t) <BR><FONT SIZE=3D2>&gt;John Santos</FONT>h> <BR><FONT SIZE=3D2>&gt;Evans Griffiths &amp; Hart, Inc.</FONT>2 <BR><FONT SIZE=3D2>&gt;781-861-0670 ext 539</FONT> </P>  > <P><FONT SIZE=3D2>Sure. Although I don't think there are any = weirdnesses here.</FONT> </P>   <P><FONT SIZE=3D2>$&nbsp; =3I BACKUP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=1I &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=n3 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -</FONT>o? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =.I /IMAGE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=eI &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=r &nbsp;&nbsp; -</FONT>V? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =pI /NOALIAS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs= I p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=n p; -</FONT>o? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =mI /BLOCK=3D65534&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=tA p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -</FONT> ? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =aI /RECORD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=eI ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=m ;&nbsp; -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = A /IGNORE=3D(INTERLOCK,LABEL)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =V -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =aI /NOASSIST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=aG sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =o -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =lI /NOREWIND&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=dG sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =  -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =-F /MEDIA_FORMAT=3DCOMPACTION&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =s2 /LIST=3DBKUPLOGS:'DEVICE'-FUL-LOG.'TDATE' -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ="5 /JOURNAL=3DBKUPJNLS:'DEVICE'-FUL-BJL.'TDATE' -</FONT>aI <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'DEVICE': =g -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =s" 'DLTG3''TWDAY''count'.BCK -</FONT>? <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =l /LABEL=3D'WDAY6'</FONT>t </P>  B <P><FONT SIZE=3D2>DEVICE is a symbol that contains the name of a = DISK.</FONT>F <BR><FONT SIZE=3D2>DLTG3&nbsp; is a symbol that contains the name of = the tape drive.</FONT>> <BR><FONT SIZE=3D2>the other symbols are just literals.</FONT> </P>  G <P><FONT SIZE=3D2>I have subsequently discovered that the incremental =i  backups for the same disk</FONT>I <BR><FONT SIZE=3D2>do NOT exhibit this symptom. So that kinda rules out =g# any setup issues that I can </FONT>sH <BR><FONT SIZE=3D2>think of. (This is for the &quot;other&quot; disk I =+ originally referred to. We don't do </FONT>B< <BR><FONT SIZE=3D2>incrementals of the system disk.) </FONT> </P>  G <P><FONT SIZE=3D2>Although I did discover that on the system disk all =r the open files are shown</FONT> A <BR><FONT SIZE=3D2>in SYSCOMMON, not VMS$COMMON, so we've got a =e, (probably different) issue there too.</FONT>I <BR><FONT SIZE=3D2>I'd prefer to deal with just one thing at a time, so =l$ let me try to understand the </FONT>I <BR><FONT SIZE=3D2>backlink a bit better (on my own time) before I have =S another look at that.</FONT> </P>  H <P><FONT SIZE=3D2>Anyway, about the &quot;other&quot; disk, I posted a =/ question with the wizard since it looks </FONT>0H <BR><FONT SIZE=3D2>more like a bug or overflow problem with BACKUP. By =, that I mean that it is not consistent</FONT>I <BR><FONT SIZE=3D2>between incremental and image backups, *and/or* that =r- the number of files in the misreported</FONT>o@ <BR><FONT SIZE=3D2>directory's parent directory is quite large =1 (20,000+), with these files all being in a</FONT>t= <BR><FONT SIZE=3D2>subdirectory which is last in the parent =i directory.</FONT>  </P>  2 <P><FONT SIZE=3D2>Eg:&nbsp; disk:[ABC.DATA]</FONT>G <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; entries for 20,000+ files =B% plus some other subdirectories</FONT>nB <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; ZZZ_ARCHIVE.DIR</FONT>3 <BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; </FONT>)I <BR><FONT SIZE=3D2>and it's all the files in and below ZZZ_ARCHIVE that =o+ are being misreported on the BACKUP </FONT>S" <BR><FONT SIZE=3D2>LISTing.</FONT> </P>   </BODY>- </HTML> ) ------_=_NextPart_001_01C0FF4E.B4564AE0--s   ------------------------------   Date: 27 Jun 01 11:58:16 MDT" From: ivie@cc.usu.edu (Roger Ivie)  Subject: Re: Changing platforms.% Message-ID: <w+ftYLeJq$1S@cc.usu.edu>   \ In article <3B3A10F2.B7F8E359@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:N > Ironically, with its low stock price, how much is Compaq worth these days ? O > Perhaps Ken Olsen could have bought back "Digital" from Compaq, complete withnO > VMS and Alpha and compilers and then hired a visionary to kick start VMS intot > a very competitive OS.  9 You do realize the Ken Olsen isn't a fan of Alpha, right?T -- ,N -------------------------+----------------------------------------------------3 Roger Ivie               | Ben Stein for president!n ivie@cc.usu.edu          | http://cc.usu.edu/~ivie/ | -----BEGIN GEEK CODE BLOCK-----  Version: 3.18 GP dpu s:+++ a C++ UB- P--- L- E--- W- N++ o-- K-- w--- > O M+ V+++ PS+++ PE++ Y+ PGP+ t++ 5++ X-- R tv++ b+++ DI+++ D-  G-- e++ h--- r+++ y+++ g ------END GEEK CODE BLOCK------c   ------------------------------  % Date: Wed, 27 Jun 2001 15:20:15 -0400S2 From: rdeininger@mindspring.com (Robert Deininger)  Subject: Re: Changing platforms.L Message-ID: <rdeininger-2706011520160001@user-2ivebp7.dialup.mindspring.com>  I In article <w+ftYLeJq$1S@cc.usu.edu>, ivie@cc.usu.edu (Roger Ivie) wrote:     ; > You do realize the Ken Olsen isn't a fan of Alpha, right?e  ? It's always possible that the Itanic has changed his mind.  ;-)S   -- W Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Wed, 27 Jun 2001 18:30:41 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>,  Subject: Re: Changing platforms.; Message-ID: <u8t_6.21391$l45.2269716@news20.bellglobal.com>   J Porting from VAX to Alpha was relatively easy for me. I worked on one portK in January 2000 (what Y2K problem?) and was working on a second one started5I in June 2001. This second project involves 200 executables (approximatelyIK 400K lines) all written in VAX-BASIC, DEC-C, and MACRO-32. About 10% of theeI programs needed several small tweaks that were related to bad programmingaG techniques. The new compilers were very helpful in this regard and even  pointed out a few bugs.l  L If you want to see the notes from my first port (which is almost the same as* my second), check out my porting diary at:6 http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html  G BTW, I would agree that it might be a different story for people eitherKJ "depending on apps which were never ported from VAX to Alpha" or "programs with lost source code"  
 Neil Rieck Kitchener/Waterloo/Cambridge,e Ontario, Canada.! http://www3.sympatico.ca/n.rieck/-   ------------------------------  % Date: Wed, 27 Jun 2001 18:34:46 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>o  Subject: Re: Changing platforms.; Message-ID: <eKt_6.22278$l45.2301969@news20.bellglobal.com>    ----- Original Message -----/ From: "JF Mezei" <jfmezei.spamnot@videotron.ca>- Newsgroups: comp.os.vms-" Sent: Tuesday, June 26, 2001 11:08  Subject: Re: Changing platforms.     [snip]  L > Furthermore, Alpha provided functions that made the port from VAX to AlphaJ > easy. But what if IA64 doesn't provide the various protection modes that VMS G > requires ? The engineers will have to spend much time at the very low  memoryD > management level to figure out a way to emulate the old behaviour. >d  / I agree. VMS style memory protection is a must.s   [snip]K > Also consider that most Compaq servers come with a default blue screen ofuD > death console. Will the VMS engineers provide a graphical OPA0: on servers, orF > will they find a way to provide character cell OPA0: on a non-serial console  > port ?  H All Alpha machines already have a VGA graphics card which is used as theF default console. And yes, it is blue during boot. You can connect a VT terminal= to the first serial port then issue the console mode command:u SET CONSOLE SERIALF to make it VAX like because the VGA console won't let you do EDT style editing 8 (which is my preferred way to enter license information)  
 Neil Rieck Kitchener/Waterloo/Cambridge,n Ontario, Canada.! http://www3.sympatico.ca/n.rieck/c   ------------------------------    Date: 27 Jun 2001 20:38:16 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)n  Subject: Re: Changing platforms.3 Message-ID: <9giU+LmNgHUz@eisner.encompasserve.org>t  g In article <eKt_6.22278$l45.2301969@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:   1 > From: "JF Mezei" <jfmezei.spamnot@videotron.ca>0  L >> Also consider that most Compaq servers come with a default blue screen ofE >> death console. Will the VMS engineers provide a graphical OPA0: onA
 > servers, > orG >> will they find a way to provide character cell OPA0: on a non-serialo	 > consoled	 >> port ?a > J > All Alpha machines already have a VGA graphics card which is used as the3 > default console. And yes, it is blue during boot."  ; I hate to bring up a technical nit in a politics newsgroup, B but mine are black on boot (with white letters).  Alphastation 250 and DEC 3000-400.b   ------------------------------  % Date: Wed, 27 Jun 2001 23:11:17 -0400w' From: "Bill Todd" <billtodd@foo.mv.com>   Subject: Re: Changing platforms.( Message-ID: <9he72b$crh$1@pyrite.mv.net>  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:Py9Kxb4PFzen@eisner.encompasserve.org...> > In articleH <35666012DF4CD411BE940090279FA240010BEFD7@ppnt41.physics.ox.ac.uk>, John5 Macallister <J.Macallister1@physics.ox.ac.uk> writes:t >eH > On a couple days reflection, it appears to me that Compaq is presently7 > in the process of not repeating mistakes made by DEC.   J Selling off valuable assets because you're too incompetent to develop them$ seems very reminiscent of DEC to me.   >UH > DEC saw itself as a computer manufacturer, yet it was the VMS softwareC > which sold VAXes.  Any hardware engineer could tell you there wasi? > nothing all that special about VAXes (at least most of them).s  J But there was something special at the hardware's external interface:  theJ instruction set.  For a period of time (pretty much until RISC establishedC itself, which was *well* after the VAX ISA was designed), that mademG assembly-language development and compiler construction reasonably easya) (compared with other CISC architectures).8  G I suspect that this was one of the things that helped VAX establish itshL early dominance (though of course 32-bitness was the real biggie).  The factJ that the world of instruction sets changed shortly thereafter wasn't DEC's; fault (though failing to adapt quickly to that change was).      Other H > vendors had somewhat faster systems but couldn't sell them in the faceJ > of VMS.  In those days if you has some software to do, you bought a VAX. >=I > DEC looked at porting VMS to 80386, but as a computer manufacturer they ! > wanted to sell VAXes, not 386s.L  I IIRC, the difference between VAX chip prices and 386 chip prices wasn't a J significant portion of the cost of a VAX system back then, nor had the 386I any initial performance advantage over a uVAX II (perhaps the reverse, inyL fact).  So a VMS port to the 386 back then had little obvious attraction for anyone.   K DEC's major blind spot was to the fact that the 386 heralded the onset of atE PC-level 32-bit architecture that could threaten VAX on more than thenA desktop (which it had no interest in occupying, save for high-end  workstations).  )   DEC's biggest concern seemd to be IBM'spI > repeated attempts to build VAX killers.  IBM was THE competition, DEC'sd > focus was on IBM.r  E Which was unfortunate, and may have led to so much misguided focus ono7 'strategy' rather than simply meeting customers' needs.)   >r3 > DEC underestimated the impact of RISC technology.o  I Absolutely.  And IA32 technology as well (as noted above).  And even IA16 K technology:  VMS should have taken steps to become the server-of-choice fortH PCs back in the mid-'80s, but instead it took many more years before DECF considered PCs as more than something to be grudgingly supplied to andB supported for customers who were too dumb or cheap to purchase DEC
 workstations.d     More than somewhatF > faster, it was an impact great enough that people were willing to goC > through the pain of VMS to UNIX migration to get on RISC systems.   J Not to mention being significantly less expensive as an entire system, due0 to the aggressive efforts of companies like SUN.   >;I > Too late, DEC responded with a great RISC chip.  Customers who had left!H > VMS found no reason to come back.  For a lot of applications which had) > been done on VMS, UNIX was good enough.t  I IIRC, Alpha appeared not at all long before Palmer started systematicallygI dismantling the company.  Was there *any* time between the moment VMS was/K fully ported to Alpha and DEC stopped trying to sell it?  VMS has certainlyoI been in limbo for at least a half-dozen years now, and may well have beeneJ there in part even long before Alpha first shipped (due to the internecineI conflicts with the Unix contingent).  In any event, suggesting that AlpharI didn't appear in plenty of time to save DEC (if that's what you're doing)  seems ill-considered.    >lF > Now Compaq, originally doing nothing but assembling hardware with noH > software of their own sees that they are making a great profit selling > great software.h  K What evidence can you present that Compaq has the slightest appreciation ofE VMS?  2   They see that their own chip line isn't going toG > maintain it's competitive edge, and will in the forseeable future getN% > behind the price/performance curve.   G Unless they fund it, which kind of investment appears to be contrary to3 their basic principles.r      They put thier money where the > profit is, software,  F WHAT???  The only significant money Compaq has ever seemed to considerJ devoting to VMS development is the currently-'committed' port - and that'sH not development, just (as was so aptly stated elsewhere) artificial lifeE support to compensate from just having carved out its hardware heart.e  2  and they do it in time to prevent a repeat of the > great migration off VMS.  G Last we heard here, there was a slight resurgence going on, not another>I 'great migration off'.  With even a *little* encouragement (marketing anduL new development commtments) it could have turned into a *real* 'renaissance'H (not just the PR one Marcello & Co. have been touting).  Instead, we get this.t   >OI > Painfull?  Yes, some customers are going to disagree with the decision,/J > Compaq has necessarily caused some uncertainty.  Dollars will have to be# > spent to keep the software going.T  K Anyone with the sense God gave the cat will sit back and wait for many realsJ millions to be spent:  not just on the port, and not just on the port plusL some minor ancillary stuff, but on enough new development and marketing that< *new* customers are attracted *in spite of* Monday's events.   >EH > Necessary?  Yes, the current path was obviously going to put them at a > competitive disadvantage.a  F In the words of the Grand Moff Tarkin, "I think you are too trusting."C Those are the words Compaq spoke, but not what a lot of independentp& evaluations (not just mine) suggested.   >tH > DEC like?  No, Compaq's doing exactly the kind of things DEC needed to > do and failed.  K No, to all appearances Compaq is doing exactly the kind of things DEC *did*t) do - and failing at them just as DEC did.B  L The thing about a market-based environment is that unless you are a monopolyE in order to thrive you have to be willing to step up to the plate and>K *compete*, rather than just lounge around in the boardroom trying to figurenJ out how to minimize costs and risks.  Bean-counters don't understand these= things, and their corporations pay the consequences for this.n   - bill   >OH > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences Corporations? > NASA GSFC Flight Software       | Federal Sector, Civil Group;G >                                 | please remove ".aspm" when replyingb   ------------------------------  % Date: Thu, 28 Jun 2001 13:06:40 +1000;- From: "Paul Nankervis" <paulnank@au1.ibm.com>n  Subject: Re: Changing platforms./ Message-ID: <9he70f$2d3a$1@poknews.pok.ibm.com>   F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:uQgbmwPWt2gh@eisner.encompasserve.org...s >nB > At least in the case of Ada there is a very good case that it isA > "mature" because it is the older Ada83 standard.  Regardless of F > how many customers of using it there is no reasonable set of furtherC > improvements that can be made to it short of going to Ada95.  But&F > that would be a whole different compiler.  Many Ada customers cannotL > stand a whole new compiler, they need the same compiler for compatibility.  H I did wonder if changing platform might actually be an opportunity to do thingsL a bit differently. For example it might be possible to adopt the object file formatF (.OBJ) of another system such as Tru64 or Linux.  Obviously this meansG big changes to the linker and to any other code which knows object filel format.NK But once it is done it means finding compilers for the system becomes a lot&K easier - for example the C compiler needs to know far less about the system> it is generating code for.  H I suggest this because one issue bugging me is that Tru64 has had betterH compiler technology with more optimizations than VMS.  There seems to be: a lesser interest in keeping the VMS compilers up to date.  G This might make it really simple to provide some new compilers for VMS.bI Obviously there will be a few problems, such as names of run-time libraryFC routines, or specific VMS feature such as PSECTS etc. But for those 	 compilersBJ which require these features it might be possible to provide extensions to theu object language.   Just a thought   Paul Nankervis   ------------------------------  # Date: Thu, 28 Jun 2001 04:17:42 GMTS4 From: "Terry C. Shannon" <terryshannon@mediaone.net>  Subject: Re: Changing platforms.; Message-ID: <Gdy_6.1172$UT1.383025@typhoon.ne.mediaone.net>a  / "Roger Ivie" <ivie@cc.usu.edu> wrote in messageo news:w+ftYLeJq$1S@cc.usu.edu...>7 > In article <3B3A10F2.B7F8E359@videotron.ca>, JF Mezei & <jfmezei.spamnot@videotron.ca> writes:H > > Ironically, with its low stock price, how much is Compaq worth these days ?L > > Perhaps Ken Olsen could have bought back "Digital" from Compaq, complete withL > > VMS and Alpha and compilers and then hired a visionary to kick start VMS into > > a very competitive OS. >f; > You do realize the Ken Olsen isn't a fan of Alpha, right?h  K Having seen the world progress from vacuum tubes to 16 bits to 32 bits, Ken L no doubt realized that a VAX successor would be necessary at some point. (HeI explicitly said as much at one of the DEC analyst events, 1989 IIRC). But I the whole Alpha effort was a marketing and strategic goat-rope right from H the get-go. By introducing an entire family of 64-bit systems (sans suchH stuff as OSes, compilers, and apps) on November 10, 1992, DEC imposed an& immediate sales freeze on VAX systems.  L Had the firm initially intro'd Alpha as a development platform, more revenueK could have been derived from the VAX line (the VAX architecture underwent atJ 13-fold performance improvement over the course of 39 months, another CMOS@ process shrink or two could have boosted performance even more).  * But we all have 20-20 hindsight, don't we?   ------------------------------  % Date: Wed, 27 Jun 2001 16:50:29 -0400 - From: John Reagan <reagan@hiyall.zko.dec.com>n- Subject: Re: Compaq proves their incompetence=2 Message-ID: <3B3A0ED5.169B8378@hiyall.zko.dec.com>   Bob Koehler wrote: > D > I wonder how closely the language the GEM back end reads resembles > either of these? >   F The GEM CIL (Compact Intermediate Language) does have some resemblanceB to an assembler's input.  There are ADD, SUB, LABEL, BRANCH, CALL,@ FETCH, STORE, etc. tuples.  The current GEM CIL manual lists 2761 different tuples that a front-end could generate.   > -- / John ReaganL Compaq Pascal Project Leader   ------------------------------  % Date: Wed, 27 Jun 2001 18:00:35 -0400:' From: "Bill Todd" <billtodd@foo.mv.com>)- Subject: Re: Compaq proves their incompetence ( Message-ID: <9hdkrm$r0h$1@pyrite.mv.net>  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:bvojjts6qu306oo7s2pplq97hvtnj4e9kn@4ax.com...   ...k  H > I think they screwed up big time buying DEC without a well thought outG > strategy. I have some sympathy for Capellas because he did not create  > the mess in the first place.  E I've got to ask (really, not just rhetorically):  was there really notJ strategy at the time of the purchase, or was there a strategy but one that) turned out not to be to the BoD's liking?-  G My impression before Pfeiffer got booted was that he was in fact fairly.K bullish on DEC technology - especially Alpha - and there really wasn't time ; for him to have done that much with it before the axe fell.K   - bill   ------------------------------  % Date: Wed, 27 Jun 2001 18:18:09 -0600-- From: "Dan Notov" <dannoHATES_SPAM@large.com> S Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design  team...)i/ Message-ID: <tjktriaugvbka3@corp.supernews.com>:  A I would hope the incentives will include transfer of pension/401Ke; eligibility, vacation accrual/retention, 10yr watches, etc.c  9 I'm also curious about how stock options will be handled.o  < "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message$ news:9hd8q7$1uq$1@lisa.gemair.com.... > In article <3B3A159F.3F2FC310@videotron.ca>,1 > JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:- > >Larry Kilgallen wrote: F > >> No, not freelance.  They are being "offered employment" at Intel. > >:H > >What are the mechanics of this. Aren't their paycheques automatically start toL > >come from Intel, or will their Compaq jobs be terminated at the same time as a! > >job offer from Intel arrives ?a > >kJ > >Would intel transfer employee by employee, or do a single mass transfer of the? > >payroll file and later on adjust each employee accordingly ?, > >ML > >If an employee decides not to work for Intel, will he have to resign from > >Compaq or from Intel ?e >iH > I've had this happen to me at a company once.  You are terminated fromK > the old employer and the new employer offers you a job.  You fill out alliL > the new employee paper work at the new place to get your pay started, etc. >pH > I wouldn't be surprised if there were some incentives being offered by6 > Intel, especially to ensure they get the key people. >s > -Jordan Hendersont > jordan@greenapple.com" >g   ------------------------------  % Date: Wed, 27 Jun 2001 18:03:30 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>nR Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...); Message-ID: <%Ks_6.20970$l45.2251906@news20.bellglobal.com>a  F After reading Mike Capellas' Monday morning tome, I decided to do someL poking around to discover what event (or events) may have pushed Compaq into. dropping Alpha as their flagship architecture.  > The following link is from the May 28 issue of InformationWeek. http://www.informationweek.com/839/itanium.htm; and contains the following interesting quote about Itanium:d  D Still, Intel officials are confident they can succeed by turning theL company's vast, economy-of-scale-driven manufacturing base to the productionK of high-performance, low-cost 64-bit chips. "Look at the cost-effectivenesssI we've been able to bring to the desktop and to the 32-bit server market,"pG CEO Craig Barrett says. "We're going to do the same thing in the 64-bit J space." Intel is selling the chips for as little as $1,177 each in batchesK of 1,000--hundreds of dollars less than its most-expensive Pentium III Xeonl chip.   K I'm not saying that this piece in InformationWeek started the ball rolling,.E but it contains facts that would scare the be-jesus out of most InteleJ competitors. BTW, my employer's company has many Xeon based Compaq servers- so the above fact may really hit home Compaq.o  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/l   ------------------------------    Date: 27 Jun 2001 14:31:35 -0400/ From: jordan@lisa.gemair.com (Jordan Henderson)-Y Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) team..K* Message-ID: <9hd8q7$1uq$1@lisa.gemair.com>  , In article <3B3A159F.3F2FC310@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:s >Larry Kilgallen wrote: D >> No, not freelance.  They are being "offered employment" at Intel. >mO >What are the mechanics of this. Aren't their paycheques automatically start tolO >come from Intel, or will their Compaq jobs be terminated at the same time as aA >job offer from Intel arrives ?  >yO >Would intel transfer employee by employee, or do a single mass transfer of the = >payroll file and later on adjust each employee accordingly ?h > J >If an employee decides not to work for Intel, will he have to resign from >Compaq or from Intel ?l  F I've had this happen to me at a company once.  You are terminated fromI the old employer and the new employer offers you a job.  You fill out all-J the new employee paper work at the new place to get your pay started, etc.  F I wouldn't be surprised if there were some incentives being offered by4 Intel, especially to ensure they get the key people.   -Jordan Henderson  jordan@greenapple.comr   ------------------------------  % Date: Thu, 28 Jun 2001 00:00:21 +0200E) From: Christof Brass <brass@infopuls.com>s1 Subject: Re: Compaq's Alpha design team for sale? , Message-ID: <3B3A5775.6D66EEC3@infopuls.com>   Larry Kilgallen wrote: > Z > In article <3B390CAD.2DBDBCBE@infopuls.com>, Christof Brass <brass@infopuls.com> writes:   [SNIP]  B > Why does there need to be a successor if IA64 does not improve ?   :-)   ? I just finished reading one HW analysis article about EPIC IA63a? and EV8 SMT. Facit: the problems of EPIC has still to be solvedr@ while the performance expectations based on obvious analysis for the EV8 are very high.  " It's unbelievable what Compaq did.   ------------------------------    Date: 27 Jun 2001 11:56:30 -0700& From: craig@hsc.mb.ca (Craig Gunhouse)# Subject: DCPS 1.8 with LEXMARK T616d= Message-ID: <8629bcd1.0106271056.3e9a4de1@posting.google.com>r  ? I get the following messages whenever I print long reports (200u pages):   7 %DCPS-F-CONTERMINATED, Connection abnormally terminateds   and   F %DCPS-I-RELEASE, $SET QUEUE/RELEASE/ENTRY=2516 ANSI_851 to release for printing    : I do NOT get this problem with shorter reports (10 Pages).    C I think that it is a timing problem, maybe with the network buffers  and/or timeout settings.   Craig Gunhouse   ------------------------------  # Date: Wed, 27 Jun 2001 19:33:47 GMT 1 From: "Mark D. Jilson" <jilly@clarityconnect.com>E/ Subject: Re: Disk Cluster Size for Oracle Diskse2 Message-ID: <3B3A3614.7A47EBFD@clarityconnect.com>  E This is either bogus or misunderstood advice.  Disk cluster size onlywH plays a part in file allocation and plays no part in IO transfer sizes. < Set the cluster size according to the disk size and the fileC creation/extension behavior of the applications that use that disk.h   Dave Harrold wrote:c > 	 > Hi All,e > G > We are running Oracle 7.3.3.6 on VMS 7.2-1H1 and our vendor said thatoG > the disks that have the Oracle data files on it should have a clusterhE > size that is a multiple of 16.  (Because Oracle does 8K transfers.)  > H > O.K., that seems reasonable to me, but my question is would having theC > cluster size be 16 not matter what be better?  Some of our largeraH > drives will have a cluster size of 112 by the multiple of 16 rule.  Is@ > that really as efficient? (I.e. does Oracle do 56K transfers?) > G > And as a related question, the answer to the above questions seems to H > be "It Depends on your I/O size".  So, what tools can I use to measure > the size of the I/Os?s >  > Thanks for the help. >  > Dave Harrold > X > ======================================================================================X > Dave Harrold                                          E-Mail: David_Harrold@Aurora.orgN > Sr. Software Systems Engineer                         Phone : (414) 647-6204N > Aurora Health Care                                    FAX   : (414) 647-4999K > 3031 W. Montana Street                                Milwaukee, WI 53234a > Z > "A common mistake people make when trying to design something completely foolproof is to1 > underestimate the ingenuity of complete fools."h   -- sD Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------  % Date: Wed, 27 Jun 2001 16:02:31 -0400a+ From: John Eisenschmidt <jeisensc@aaas.org>i/ Subject: Re: Disk Cluster Size for Oracle Disks # Message-ID: <sb3a03b1.063@aaas.org>a  J The Oracle cluster size, as I understand it, is the size of the chunk of =G data Oracle can pull from a datafile at once. If your tablespaces are = L layed out properly, and your database is maintained properly then it isn't =J a problem. Under something like NT, your DB_BLOCK_SIZE is only 2k, where =J some Alphas can even do 16k, which increases your overall data throughput.  K At one point, I was going to do with cluster sizes of 1, but I settled on =cD the default. Performance is - shall we say, instantanious. I'm not = complaining.  I >>> "Mark D. Jilson" <jilly@clarityconnect.com> 06/27/2001 3:33:47 PM >>>nE This is either bogus or misunderstood advice.  Disk cluster size onlyrJ plays a part in file allocation and plays no part in IO transfer sizes.=20< Set the cluster size according to the disk size and the fileC creation/extension behavior of the applications that use that disk.o   Dave Harrold wrote:  >=20	 > Hi All,g >=20G > We are running Oracle 7.3.3.6 on VMS 7.2-1H1 and our vendor said thatmG > the disks that have the Oracle data files on it should have a clustercE > size that is a multiple of 16.  (Because Oracle does 8K transfers.)  >=20H > O.K., that seems reasonable to me, but my question is would having theC > cluster size be 16 not matter what be better?  Some of our largereH > drives will have a cluster size of 112 by the multiple of 16 rule.  Is@ > that really as efficient? (I.e. does Oracle do 56K transfers?) >=20G > And as a related question, the answer to the above questions seems togH > be "It Depends on your I/O size".  So, what tools can I use to measure > the size of the I/Os?p >=20 > Thanks for the help. >=20 > Dave Harrold >=20K > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=$ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DL > Dave Harrold                                          E-Mail: David_Harro= ld@Aurora.org=20G > Sr. Software Systems Engineer                         Phone : (414) =i 647-6204G > Aurora Health Care                                    FAX   : (414) =g 647-4999G > 3031 W. Montana Street                                Milwaukee, WI =n 53234j >=20L > "A common mistake people make when trying to design something completely = foolproof is to 1 > underestimate the ingenuity of complete fools."s   --=20aD Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------  % Date: Wed, 27 Jun 2001 18:43:48 -0400m' From: "Bill Todd" <billtodd@foo.mv.com>o/ Subject: Re: Disk Cluster Size for Oracle Diskse( Message-ID: <9hdncm$t67$1@pyrite.mv.net>  < "Mark D. Jilson" <jilly@clarityconnect.com> wrote in message, news:3B3A3614.7A47EBFD@clarityconnect.com...G > This is either bogus or misunderstood advice.  Disk cluster size only I > plays a part in file allocation and plays no part in IO transfer sizes.   I Well, unless the file is fragmented.  For a table accessed randomly, *if*-B Oracle takes the trouble to align pages on consistent, predictableH boundaries, then choosing an appropriate cluster size could allow one toJ maintain (random access) performance without periodic file defragmentation9 (assuming a fair amount of size volatility in the table).m   - bill  > > Set the cluster size according to the disk size and the fileE > creation/extension behavior of the applications that use that disk.a >s > Dave Harrold wrote:  > >o > > Hi All,e > > I > > We are running Oracle 7.3.3.6 on VMS 7.2-1H1 and our vendor said thatmI > > the disks that have the Oracle data files on it should have a cluster G > > size that is a multiple of 16.  (Because Oracle does 8K transfers.)n > >hJ > > O.K., that seems reasonable to me, but my question is would having theE > > cluster size be 16 not matter what be better?  Some of our largerpJ > > drives will have a cluster size of 112 by the multiple of 16 rule.  IsB > > that really as efficient? (I.e. does Oracle do 56K transfers?) > >lI > > And as a related question, the answer to the above questions seems to J > > be "It Depends on your I/O size".  So, what tools can I use to measure > > the size of the I/Os?e > >o > > Thanks for the help. > >> > > Dave Harrold > >  > > L ============================================================================
 ==========A > > Dave Harrold                                          E-Mail:r David_Harrold@Aurora.orgG > > Sr. Software Systems Engineer                         Phone : (414)o 647-6204G > > Aurora Health Care                                    FAX   : (414)f 647-4999G > > 3031 W. Montana Street                                Milwaukee, WIh 53234o > >rL > > "A common mistake people make when trying to design something completely foolproof is ton3 > > underestimate the ingenuity of complete fools."- >- > --F > Jilly - Working from Home in the Chemung River Valley - Lockwood, NY/ > - jilly@clarityconnect.com - Brett Bodine fanC- > - Mark.Jilson@Compaq.com - since 1975 or so.- > - http://www.jilly.baka.com               -"   ------------------------------  # Date: Wed, 27 Jun 2001 12:53:16 PDT  From: employment@beer.com5 Subject: FastCash ) Message-ID: <3b3a73e5@MAIL.mhogaming.com>e  < FastCash.....is making its own statement. "It really works!"  ; Are you searching for a way to make money on the internet ?aC Have you banged your head against the wall waiting for the payoff ?l% This is then the program for you.....s0 Yes, you can advertise this all over the world !j Yes, you can start this and never stop. there is no time limit and the earnings are totally in your hands.) You can do this part time or full time...a: IT WILL STUFF YOUR MAILBOX WITH $5.00 BILLS ($40,000 U.S.)< $$SUCCESSFUL INTERNET MAILING PROGRAM WITH A SAFETY CATCH !!V An accountability list to ensure that ALL PARTICIPANTS get paid !! You CANNOT LOSE !!!G Invest just $10.00 (you no doubt have tried your hand at the lottery...na there is no guarantee of getting your money back...right? with this you will get your money back rg it's fool-proof ) see a return of $40,000+ for your $10.00 investment !! All the while $5.00 bills are lc arriving in your mail box every day.... For free details e-mail me at employment@beer.com  and put mc in subject box "Phase 1" and I will mail you the information to get you started... its that simple.e  @ Some other great sites: http://www.angelfire.com/super/money4u/ Q 	                     http://www.geocities.com/tyke4u2000/Internet_Business.html  ; 	                     http://www.geocities.com/tyke4u2000/ r   ------------------------------   Date: 27 Jun 2001 18:02:29 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)e Subject: Re: FreeVMS, Message-ID: <9hd73l$2g9q$3@info.cs.uofs.edu>  = In article <55f85d77.0106262321.3418c9f1@posting.google.com>,m,  P.Young@unsw.EDU.AU (Patrick Young) writes: |> Oh please...  |> CH |> I have OpenVMS 7.2-1 source sitting right next to me in my bedroom as5 |> I type this on my PC164/500 running OpenVMS 7.2-1.- |> oA |> The source code for OpenVMS is not expensive (and a worthwhile- |> investment).e |>   |> There are few secrets.   2 Compaqs lawyers would probably not agree with you.  G |>                         As far as I am concerned OpenVMS is OPEN - I  |> haverH |> source. I can use the source code for my licensed hardware at work to
 |> performG |> my work job function. In recent years Compaq has bent over backwards 
 |> to make6 |> OpenVMS available to everyone this is a good thing. |>  D |> If OpenVMS goes under - we all know how it works - we can rebuild
 |> (hopefullys< |> not on Intel though - not that we would have any choice).  D If OpenVMS goes under it won't change the copyright, patent or tradeG secret status of one line of code.  The fact that you are sitting theretD reading a copy of that code right now probably disqualifies you as a  developer of a free alternative.   bill   -- vJ 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: Wed, 27 Jun 2001 15:46:52 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: FreeVMSL Message-ID: <rdeininger-2706011546520001@user-2ivebp7.dialup.mindspring.com>  P In article <sb38ed9b.052@aaas.org>, John Eisenschmidt <jeisensc@aaas.org> wrote:     > <hoff>J > Based on a quick check of one of the larger of the source libraries of =K > OpenVMS Alpha operating system code around, Macro32 leads C and Bliss32 =y
 > modules.=20e >  >     *.MAR: 3811n >     *.C:   3708  >     *.B32: 2589" >     *.ADA:  103  >     *.B64:  132n >     *.COM: 2006 	 > </hoff>e > L > Would you prefer an OS written in RPG or PL/1? I myself am hoping either =L > vacuum tubes make a stylish comeback, or someone finally writes an OS in = > COBOL.  J Ada 95 would be best, but it's not currently stylish.  PL/1 would be fine,E but it's REALLY not stylish these days.  C is probably no better thann) Bliss, except for that style thing again.l  C The reality is, most of those modules are NOT going to be redone iniE another language anytime soon. There are more important things to do.m  J The front-ends of the compilers are all written.  A single, versatile backF end will have to be written for IA64, and every front-end plugged intoD it.  Then, compile till the smoke starts coming out of the GS-320s. : Whatever the language, the smoke will be the same color...   -- r Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Wed, 27 Jun 2001 16:04:42 -0400 + From: John Eisenschmidt <jeisensc@aaas.org>u Subject: Re: FreeVMS# Message-ID: <sb3a042f.073@aaas.org>A  H The Lady Lovelace would prefer it were all done in Delphi (or at least =! Pascal). Go on, ask her yourself.a  J >>> Robert Deininger <rdeininger@mindspring.com> 06/27/2001 3:46:52 PM >>>K In article <sb38ed9b.052@aaas.org>, John Eisenschmidt <jeisensc@aaas.org> =p wrote:   > <hoff>G > Based on a quick check of one of the larger of the source libraries =i of=20iC > OpenVMS Alpha operating system code around, Macro32 leads C and =o
 Bliss32=20 > modules.0l >=20 >     *.MAR: 3811n >     *.C:   3708c >     *.B32: 2589  >     *.ADA:  103n >     *.B64:  132  >     *.COM: 2006t	 > </hoff>c >=20E > Would you prefer an OS written in RPG or PL/1? I myself am hoping =n	 either=20 J > vacuum tubes make a stylish comeback, or someone finally writes an OS in > COBOL.  J Ada 95 would be best, but it's not currently stylish.  PL/1 would be fine,E but it's REALLY not stylish these days.  C is probably no better thane) Bliss, except for that style thing again.P  C The reality is, most of those modules are NOT going to be redone inoE another language anytime soon. There are more important things to do.e  J The front-ends of the compilers are all written.  A single, versatile backF end will have to be written for IA64, and every front-end plugged intoF it.  Then, compile till the smoke starts coming out of the GS-320s.=20: Whatever the language, the smoke will be the same color...   --=20  Robert Deininger rdeininger@mindspring.comd   ------------------------------  % Date: Wed, 27 Jun 2001 22:37:16 +0200 ) From: Christof Brass <brass@infopuls.com>. Subject: Re: FreeVMS, Message-ID: <3B3A43FC.B6FB5CA1@infopuls.com>   Patrick Young wrote: >  > Oh please... > G > I have OpenVMS 7.2-1 source sitting right next to me in my bedroom ast4 > I type this on my PC164/500 running OpenVMS 7.2-1. > @ > The source code for OpenVMS is not expensive (and a worthwhile > investment). > E > There are few secrets. As far as I am concerned OpenVMS is OPEN - I  > haveG > source. I can use the source code for my licensed hardware at work tob	 > perform F > my work job function. In recent years Compaq has bent over backwards	 > to makee5 > OpenVMS available to everyone this is a good thing.r > C > If OpenVMS goes under - we all know how it works - we can rebuilde > (hopefully; > not on Intel though - not that we would have any choice).   ? This is music in my ears but I don't have the chance to get the < source because it's not available for someone without credit card.    ------------------------------  % Date: Wed, 27 Jun 2001 22:48:47 +0200 ) From: Christof Brass <brass@infopuls.com>e Subject: Re: FreeVMS+ Message-ID: <3B3A46AF.ECAAAAC@infopuls.com>-   John Eisenschmidt wrote: >  > while !(end_of_drivel) > { //begin loop > I see someone watched last week's episode of South Park one too many times. Even when I'm adding "colorful" language I usually mix it up. You'll need a visit from the Knights of Standards and Practice.c   ??   > As for the "OS written in C" is shit comment, Hoff said yesterday that while Macro is the most common language, over 3700 modules are written in C.d >  > <hoff> > Based on a quick check of one of the larger of the source libraries of OpenVMS Alpha operating system code around, Macro32 leads C and Bliss32 modules.s >  >     *.MAR: 3811y >     *.C:   3708l >     *.B32: 2589  >     *.ADA:  103- >     *.B64:  132  >     *.COM: 2006 	 > </hoff>7 >  > Would you prefer an OS written in RPG or PL/1? I myself am hoping either vacuum tubes make a stylish comeback, or someone finally writes an OS in COBOL.  @ Agreed completely. Almost all available C sources I had a chance7 to look into were really awful. The very low quality of ? Mozilla's code is well known. Look into glimpse, into the Linuxo@ kernel sources. With a lot of effort and tools you might be able= to produce high quality C source. But this doesn't make sensem9 economically. I understand that VMS engineering cannot be < compared with the average UNIX C programmer. And I like that$ there are some Ada modules in there.   > As for my 2 cents - I think it's too early to tell what Mac OS-X and Mach are going to do. I think as a kernel Mach blows, (see, I could have called it shit, but I chose a unique epithet) but anything has to be better than the Mac OS Finder. Rhapsody was interesting - that whole "display postscript" concept - really revolutionary even if it never saw the light of day. Plus they have three layers of API to deal with - Carbon, Cocoa, and Classic. Macs are like the Dune Buggy of the IT world, I'd never driveM  it on a highway or day-to-day, but it's a fun toy to drive around the beach.u > } //end loop  4 I'm about to buy a Titan powerbook. I don't see much@ alternatives avoiding Untel and Micro$hit. I developed on Mac in= the late 80ies and early 90ies and liked it a lot. I had much ? less problems with it than on M$DOS, OS/2 and UNIX. I could user it very efficiently.   ------------------------------  % Date: Wed, 27 Jun 2001 16:55:34 -0400K* From: "Joshua Harding" <jharding@sscc.org> Subject: Re: FreeVMS/ Message-ID: <tjkhpmaqrdsif0@corp.supernews.com>r  L FreeVMS could and _never_ would take off because VMS was engineered from theI beginning, instead of evolving, such as Linux or Windows. The Open Source=K community seems eminently capable of developing 1,000 Mp3 players, web mail H interfaces and screensavers, but are clearly not capable (or wanting) to0 write an operating system comparable to OpenVMS.  < "BERTRAND Jol" <bertrand@perceval.cnam.fr> wrote in message0 news:slrn9iutga.ii9.bertrand@perceval.cnam.fr... > Good morning,e > 8 > I have seen an old project named FreeVMS. Its goal was< > to clone VMS with a Gnu Public Licence. This project seems; > to be dead. So I research anyone that has time to restartc > this project.  >-
 > Regards, >k > JKBm >mD > PS: I have some troubles with my news server, so you probably find > another post. Sorry...   ------------------------------  % Date: Wed, 27 Jun 2001 22:52:15 +0200m) From: Christof Brass <brass@infopuls.com>- Subject: Re: FreeVMS, Message-ID: <3B3A477F.5F20A8AC@infopuls.com>   John Eisenschmidt wrote:   [SNIP]   > Would you prefer an OS written in RPG or PL/1? I myself am hoping either vacuum tubes make a stylish comeback, or someone finally writes an OS in COBOL.  ; COBOL is dead although there is an oo version which is very > appreciated by the COBOL programmers I know personally. RPG is; as far I know not calculation complete. PL/1 is a srewed upr4 design version of Pascal. Why not DEC Pascal or Ada?   [SNIP]   ------------------------------  % Date: Wed, 27 Jun 2001 17:12:37 -0400 + From: John Eisenschmidt <jeisensc@aaas.org>o Subject: Re: FreeVMS# Message-ID: <sb3a1416.010@aaas.org>i  I Microfocus has done some amazing things with COBOL compilers, but I was =mD being flip there. COBOL does what it does very very well, but it's =E specialized (just like Fortran). If they could have written Unix in =yL Fortran they would have, but Richie and Kerrigan felt there was a need for = a general purpose language.=20  I I think people are entitled to their opinions, and I think VMS was done =eL right for its time - it was written in many different languagues. But AT&T =L took a big step when they wrote Unix - except for pieces written in ASM it =A was done entirely in C. Most of the Unix clones are the same way.l  G Now, Unix and VMS are roughly the same age. Given the current install =uJ base, who has weathered the test of time? I think both Unix and VMS have =K done remarkably well, and I think they lost some comrads on along the way =eI (RSX-11, OS/2 as we mentioned earlier this week). Most of the IBM stuff =s has weathered the storm.  L My point being, if it's survived 20 years, and it's written in C, it can't =I be all bad. I, on the other hand, have survived just over 20 years, and =/ I'm pure evil. <G>   =BFfoo?l  A >>> Christof Brass <brass@infopuls.com> 06/27/2001 4:52:15 PM >>>D John Eisenschmidt wrote:   [SNIP]  L > Would you prefer an OS written in RPG or PL/1? I myself am hoping either =J vacuum tubes make a stylish comeback, or someone finally writes an OS in = COBOL.  ; COBOL is dead although there is an oo version which is very > appreciated by the COBOL programmers I know personally. RPG is; as far I know not calculation complete. PL/1 is a srewed upn4 design version of Pascal. Why not DEC Pascal or Ada?   [SNIP]   ------------------------------  % Date: Wed, 27 Jun 2001 23:24:07 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: FreeVMSL Message-ID: <rdeininger-2706012324080001@user-2ivecak.dialup.mindspring.com>  ; In article <3B3A477F.5F20A8AC@infopuls.com>, Christof Brassi <brass@infopuls.com> wrote:e  = > COBOL is dead although there is an oo version which is very	: > appreciated by the COBOL programmers I know personally.   I I don't think Cobol is even close to dead.  But I'm not a Cobol intimate,-F it might have died while I wasn't looking.  I wonder why I see so many Cobol job postings.o   -- c Robert Deininger rdeininger@mindspring.come   ------------------------------  # Date: Thu, 28 Jun 2001 03:12:45 GMTc4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: FUD; Message-ID: <Ngx_6.1089$UT1.337135@typhoon.ne.mediaone.net>s  9 "Alphaman" <alphaman64@nixspam-home.com> wrote in messageo5 news:KTj_6.11307$P5.3924053@news1.rdc1.tn.home.com...s: > Terry C Shannon <shannon@world.std.com> wrote in message? > news:Pine.SGI.4.21.0106260906170.5295-100000@world.std.com...aE > > Well stated. This newsgroup benefits Sun, et al, far more than itn > > benefits Compaq and VMS. >wI > Look, Terry -- you've had this news for what, a week?  More?  We got itiE > Monday.  You had it spoon fed to you in the comfort of a teak linedhE > conference room in plush leather chairs with all kinds of smiling Qi standing  > around, warmly comforting you.  J Ah. You must have had the Incredible X-10 Wireless Camera in the room. ;-}, Sorry, no teak, and it was less than a week.  $ We got it via c.o.v, compaq.com, theL > Inquirer, alphanews.net, or the Register.  We had to go find stuff out for > ourselves. >nH > Put yourself in our position and understand that customers, EspeciallyL > OpenVMS customers, DON'T LIKE SURPRISES.  That's why we run OpenVMS, after > all. >v- > Compaq bungled this one worse than AlphaNT.p  I That is a matter of opinion. In the AlphaNT Incident, Compaq on August 18aL told the Bellevue AlphaNT32 developers to seek work elsewhere. This became a* matter of public knowledge 24 hours later.  G It took Compaq more than SIX WEEKS to come up with a customer pitch and D trade-in program. This time around, they at least had collateral and concalls on Day One.   ------------------------------  % Date: Wed, 27 Jun 2001 23:42:54 -0400r  From: John Santos <JOHN@egh.com>( Subject: Re: Full port of VMS to Itanium6 Message-ID: <1010627231414.51014C-100000@Ives.egh.com>  5 On Wed, 27 Jun 2001, Gotfryd Smolik, VMS lists wrote:   & > On Wed, 27 Jun 2001, Alphaman wrote: > 6 > >+Robert Deininger <rdeininger@mindspring.com> [...]F > >+> DECnet V has been the subject of as much FUD as anything in thisM > >+> newsgroup.  It isn't that bad.  The management interface is annoying ateH > >+> first, and the learning curve is non-trivial.  But I don't see any, > >+> fundamental problems with the product. > >+J > >+My opinion is that if you have a product that smacks of English in itsG > >+verbosity, why take a giant step backwards to an NCL-like language - >  >  The response was here: % > "that is the OSI naming standard" !r > ( > >+that is anything but comprehensible? > >+ > >+ Show known line countersc > [...]a  > >+ show routing child entity * >  >  Definitely agree ! 7 >  Getting differrence in naming convention withing the 4 > same network layer, regarding of the used protocol6 > (SHOW CSMA vs. SHOW FDDI) is hm... misunderstanding. > IMHO, of course. > : >  May be possible having both convention available (like 9 > in UCX) - but DECOMPAQ :) was not start the way; shame.l5 > BTW: the problems with the "VMS/DCL syntax" in somee3 >  first TCPIP releases (some command doesn't work)08 >  really irritates me, for the same reason: why someone9 >  must read tons of syntax, including the un*x one... :]A > - > >+[...]  This is _not_ intuitively obvious.j >  >  Really !o >  > [...]r0 > >+Why deliberately make a product non-obvious? > * > ..the advocacy may ask higher price ? ;) >  > [...]gN > >+I find NCL to be the closest thing to a UNIX command line under VMS.  If I$ > >+wanted UNIX, I'd get a lobotomy. >  >  :)r >  >  >  Regards - Gotfryd  B The old DEC SPR forms used to have a box "Could this SPR have been+ prevented by better or more documentation?"t  @ I think what is lacking is a tutorial guide to ncl that explainsA the concepts and organizes them coherently.  For example, all the A commands relating to ethernet interfaces should be together, nearlA all the commands relating to other kinds of interfaces, and other ' sections about MOP commands, dtss, etc.7  > The existing documentation seems to be in two classes:  How to: use NET$CONFIGURE.COM (simple and advanced), and a command? reference to NCL that is almost as confusing as the help and isi@ organized the same way (i.e. all the "add" commands, followed by= all the "advertise" commands followed by all the others, withg@ all the "set" and "show" commands jumbled together in alphabeticA rather than logical order.)  This is fine as a command reference,xF when you know what command you need, but want to check its sub-optionsB or precise syntax.  It is impossible to use if you don't know what a "csma-cd station" is.   @ Maybe the documentation is better than this now; I tried to readD it when we first got DECnet-Plus (then called DECnet-VAX Extensions,A or something similar), and the 1st 3 chapters of what appeared tokB be the introductory manual got bogged down in intricate details ofD DECdns namespaces, so I gave up.  I think the first 3 chapters could@ and should have been condensed to 4 sentences:  "Every host in a? DECnet-Plus network has a host name.  Names can be simple local B names, similar to DECnet Phase IV node names, stored on each host,D or can be stored in an elaborate, heirarchical, distributed databaseA using DECdns.  Names can also be TCP/IP host names.  See chaptersv> XX-YY for details."  Then they could have got on with the good; stuff.  (I think maybe from the DEC perspective, due to then> enormous size of DEC's internal network, DECdns *was* the goodA stuff, but to the vast majority of customers, it was irrelevant.)    -- - John Santos- Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Wed, 27 Jun 2001 15:41:11 -0400V2 From: rdeininger@mindspring.com (Robert Deininger)J Subject: Re: Full port of VMS to Itanium (was: What does Alphas dead mean)L Message-ID: <rdeininger-2706011541110001@user-2ivebp7.dialup.mindspring.com>  ; In article <3B391188.6857D040@infopuls.com>, Christof Brassh <brass@infopuls.com> wrote:d  @ > While it is a really great thing to have the head count of theB > VMS engineering group doubled we have to take into consideration> > that it needs about one to two years of training to get this< > people productive. During that time they are a load on the1 > people who already know to work on the product.m  J There are many folks who know enough VMS to be productive much faster thanF that.  Few would reach the level of the wizards any time soon, but notH everyone working on a software project needs to be a high-level wizard. G Elves can implement what wizards design.  Senior elves can test againsteH the specs the wizards decree.  Err, to borrow a phrase, too many wizards
 spoil the OS.r  = > I expect VMS current to be put in maintenace mode until theaA > migration is done. Bug fixing is essential for the current usere> > base which are almost exclusively quality oriented/dependent@ > business customers. This is quite different from the customers > of Micro$hit.o  E We've already heard (from Fred, IIRC) that some current VMS work will-E continue.  I think he mentioned that acronym thing that you hate, forj example.  F I expect they will learn a few new tricks during the porting, and someH will be backported to the older platforms.  VMS engineering has a strongI incentive to share as many source modules as they can on all platforms --r it's less work to maintain.M  @ > The hottest question I want to get answered: will VMS/Alpha be> > continued after the migration in the quality and development > speed than VMS/IA63?  I They are still doing VMS for VAX.  Some features are backported, some areaG not. I expect it will be similar for Alpha.  Cross-architure clustering H will probably last a long time.  Anything that doesn't involve intricate, hardware details probably has a good chance.  A > The good side of the move is that after two years - if all goes : > according to plan - the headcount of skillful VMS system> > developers is doubled and this would allow to equip VMS with> > additional services, keep the quality and maybe even attract/ > independent SW development companies by that.t   -- e Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Wed, 27 Jun 2001 19:10:14 +0100t8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>) Subject: RE: Full port of VMS to Itanium. N Message-ID: <35666012DF4CD411BE940090279FA240010BEFDF@ppnt41.physics.ox.ac.uk>  7 > I dont know the reasons you are allways condening M$.   F I don't believe I've ever condemned Microsoft on this list but I'm notL claiming that as a virtue rather a statement of fact. Microsoft, and severalF others, did indeed help to change the way we did computing. However, IJ believe it was Digital who led the way in interactive computing with theirK user-friendly operating systems. It's just a pity that they didn't market a L Windows operating system for the home market. The news about iVMS may change	 all that.m   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)    ------------------------------  % Date: Wed, 27 Jun 2001 16:50:39 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>r) Subject: Re: Full port of VMS to Itanium. , Message-ID: <3B3A471E.4FDC64FE@videotron.ca>   John Macallister wrote: * >The news about iVMS may change  all that.  N Could someone please post some link to an official Compaq statement about that; iVMS thing and what it will actually do that VMS won't do ?   M If you can't produce such a link and Compaq never actually proposed thsi iVMSd7 concept, perhaps you should stop spreading false hopes.,   ------------------------------  % Date: Wed, 27 Jun 2001 17:08:59 -0400u' From: "Bill Todd" <billtodd@foo.mv.com>.) Subject: Re: Full port of VMS to Itanium. ( Message-ID: <9hdhqu$opf$1@pyrite.mv.net>  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:ocnjjt0594250b8imdg2b459ehgm0q747a@4ax.com...G > On Tue, 26 Jun 2001 17:18:51 -0400, "Bill Todd" <billtodd@foo.mv.com>t > wrote: >  >n
 > >> iVMS. > >> > >> Let's go trekking ... > >tE > >Is Compaq paying you, or are you simply an idiot with a big mouth?o > >m > Is Sun paying you?  L You if anyone know that my expressions here are 100% consistent with beliefsE I've held for a long time - including a significant period when I waseE working hard with the rest of our group to try to open Compaq's eyes.   L No, SUN isn't paying me:  I'm just overcome with wholly-justifiable disgust,J as should be anyone with anything like an objective outlook on the matter.G I used to suspect that a lot of the people clinging to their hopes thatoL support by its owner for VMS would eventually come around might be more thanK a bit soft in the head, and their reaction to this latest betrayal seems toq confirm that suspicion.e   - bill   > 	 > >- billl > >, > >>	 > >> John  > >>G > >> Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukgF > >> Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKF > >> Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax) > >d > >k >h > -- > Alan   ------------------------------  % Date: Wed, 27 Jun 2001 17:27:14 -0400t' From: "Bill Todd" <billtodd@foo.mv.com>o) Subject: Re: Full port of VMS to Itanium.I( Message-ID: <9hdit5$pee$1@pyrite.mv.net>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagerF news:rdeininger-2706011131140001@user-2ive7go.dialup.mindspring.com...L > In article <9hatao$lke$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> > wrote: >P >o > > > It can be done.c > >nI > > Not any more.  Not that it was ever reasonable to expect it - but oneiC > > *might* have expected Compaq to be able to recognize the uniqueb	 strengths I > > assets like Alpha and VMS offered to higher-end applications and havetI > > cultivated expansion in those areas, especially given the ROI one cand expectJ > > there.  And there's no reason whatsoever to expect them to be any less blind F > > to VMS's strengths than they were to Alpha's (hell, Alpha at least *could*eG > > have penetrated lower-end markets without any significant effort on. Compaq'sG > > part, running Linux:  *that's* how interested Compaq is in fieldinge# > > non-Windows competition there).b >uF > Fred pointed out that the doubts about Alpha originated in the AlphaH > development group, not from on high.  They lost confidence.  They were1 > scared by Intel's shadow.  I don't know what...a  F It seems very probable that what they were most scared by was Compaq's( at-best indifferent development support.     But once that happened,v > how could Compaq continue?  G Perhaps by demonstrating a modicum of commitment?  Whoops, we know what F *that* means from Compaq:  no surprise that the development group lost confidence.c   >n? > In contrast, I don't detect any loss of confidence at OpenVMSa6 > engineering.  Your comparison doesn't quite hold up.  G And just how long before Alpha was cancelled did you detect the loss ofl  confidence by Alpha engineering?   >-I > Your doubts about future Compaq management, however, remain valid.  Not  > proven, but very valid.u  K Thanks.  I understand that intelligent people can disagree about the future C (and even aspect of the past that haven't fully been disclosed in anJ believable manner).  OTOH, since Compaq's actions over time so exactly fitI the beliefs I've held for years about their intentions, and since many ofeK the opposing viewpoints seem to be tenable only by completely ignoring thisoK history, it's hard to be quite as even-handed in discussing this as I mightd be in other situations.a   - bill   >E > -- > Robert Deininger > rdeininger@mindspring.com-   ------------------------------  % Date: Wed, 27 Jun 2001 17:44:46 -0400i' From: "Bill Todd" <billtodd@foo.mv.com>e) Subject: Re: Full port of VMS to Itanium.f( Message-ID: <9hdju1$q80$1@pyrite.mv.net>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messageeF news:rdeininger-2706011141530001@user-2ive7go.dialup.mindspring.com...L > In article <9hattq$mp7$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> > wrote:   ...    > > And whatever Intel buildsgK > > after McKinley is likely already pretty well set in concrete (using alls the B > > stuff they likely needed to steal from the HP implementation). >uJ > Here I disagree.  McKinley+1 will likely change due to this acquisition.  I If indeed changes are required to make VMS run at all, and porting VMS islI still a 'commitment' at the time, then *minor* changes could make it intouJ McKinley+1 (though certainly only in the form of limited hooks rather thanB anything remotely recognizable as a significant change in the IA64 architecture).  J That's about 3 years out (when you change things, schedules slip; for thatJ matter, Intel's have been slipping even without such perturbations), whichI makes any suggestion that VMS will be running on anything save absolutelytH vanilla IA64 in anything like an 18-month time-frame ridiculous (I don'tH think that was your suggestion, but it flavored my response - and as forI something that *really* starts to incorporate Alpha technology instead ofm- minor hooks, that's *far* beyond McKinley+1).o  G > Intel realized they were approaching some scary technical roadblocks.u? > They are just better at hiding their troubles than Compaq is.L  L Possibly.  But it's at least equally possible that Intel was simply facing aK single competitor that could  a) make its performance look bad (whereas the K rest of its competition makes the disparities at least less obvious, and as0I for SPARC...),  b) give Microsoft an easy out for Win64 (and Win64 is theVI only *really* captive market IA64 has, at least until PA-RISC goes away),.H and  c) already was the favorite 64-bit platform for Linux (whose futureI remains an unknown, but its current momentum at least makes it an issue).   J If IA64 should really hit a brick wall, having Alpha on the shelf might beB worth something to Intel.  But since process technology guaranteesL performance improvements even if the architecture doesn't change at all, theK need to take Alpha off the shelf or even to incorporate significant aspects K of its technology (which in the opinion of people who know a lot about suchmL hardware is not felt to be easy) is not at all apparent - now that Intel has@ available the option to *keep* Alpha on that shelf and avoid its competition.   - bill   >w > -- > Robert Deininger > rdeininger@mindspring.com1   ------------------------------  % Date: Thu, 28 Jun 2001 00:59:07 +0200e) From: Christof Brass <brass@infopuls.com>0) Subject: Re: Full port of VMS to Itanium.i, Message-ID: <3B3A653B.8FA5C938@infopuls.com>   Vance Haemmerle wrote: > & > Brian Schenkenberger, VAXman- wrote: > >w` > > In article <9h8eca$5vt$1@lisa.gemair.com>, jordan@lisa.gemair.com (Jordan Henderson) writes: > M > > >Compaq being unable to manage a port to the processor that it looks likeiP > > >everyone will be supporting in the future (see recent HP announcement, heckM > > >even Sun has hedged their bets by having a working Solaris port _today_)aH > > >will not bode well for their ability to sell into those high-marginG > > >Enterprise accounts that they are obviously trying to nurture withu > > >their entire new strategy.d > >n > > Compaq has a strategy? > K >   Lets port Tru64 to IA-64.  No wait, lets not port Tru64 to IA-64.  Hey, A >   lets port Tru64 to IA-64 again!  Compaq strategy at its best!   ? Lets buy Digital and Tandem to get their advanced technique and > service business. Lets merge Himalaya processor technique with? Alpha and migrate NSK to Alpha and expand the PC business whileo> srewing up services. No wait, lets sell Digital's and Tandem's8 technical assets, we don't migrate NSK to Alpha although> lockstep is already there and we want to get back to services.  > BTW what happens with NSK? Will lockstep find another way into
 some IA63?   >  > --D > Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USM > Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/    ------------------------------  % Date: Thu, 28 Jun 2001 01:20:54 +0200g) From: Christof Brass <brass@infopuls.com>s) Subject: Re: Full port of VMS to Itanium.g, Message-ID: <3B3A6A56.2F91070D@infopuls.com>   Wayne Sewell wrote:a > j > In article <acKZ6.98$rc5.4164@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:L > > I believe that the VAX port probably was the most tramatic for everyone.P > > Going from Alpha to IPF (Itanium Processor Family) will be less tramatic.  IM > > believe that if you have gotten to Alpha, odds are it will be a recompilen > > and go.r > > N > > Were you buying Alpha?  Or were you buying VMS?  I think that in the grandN > > scheme of things, you were buying OpenVMS for the things that it brings toP > > the table... if we could build a VAX that was as fast as Alpha - you'd still > > be on VAX. > J > This is true.  I never cared about alpha except as a vehicle to run vms.Q > That's why I considered the announcements of big wins with tru64 alpha, such asEO > that computing consortium in Australia, as pretty much irrelevant.   (Well, IyQ > was pleased that Sun and Andy-boy were embarrased by the Australia thing, but Ii= > didn't really *care* about it, since vms was not involved.)f > P > If vms can run as efficiently and *reliably* on Itanium or the Bugaloo 3000 orO > the Thunderbolt Greaseslapper as it does on vax and alpha, it's fine with me.i >  > Wayne. >  > --Q > ===============================================================================tO > Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : > http://www.tachysoft.xxx/www/tachyon.html and wayne.htmlM > change .xxx to .com in addresses above, assuming you are not a spambot  :-)uQ > ===============================================================================hM > Hotel guy (after bed demolition):  That bed goes back to Henry the eighth!!tQ >    Curly: That's nothin'!  We had a bed go back to Sears and Roebuck the fifth!o  6 But there are some problems with IA63 (IntelAlpha63?):< - Heat - we will (probably) never see a VMS laptop with that CPU.8 - Speed - SMT isn't compatible with EPIC. EV8 would have probably blown IA63 away.e  > By this move of Compaq you lose a lot: EV8 Alpha will never be: released and you will have to migrate which will costs you= money, time and nerves, trust me. Compare this situation with  continued enhancement of Alpha.    ------------------------------  % Date: Wed, 27 Jun 2001 21:12:14 -0500s% From: Keith Brown <kbrown780@isd.net>h) Subject: Re: Full port of VMS to Itanium.s/ Message-ID: <tjl4b13r8nr23c@corp.supernews.com>t   JF Mezei wrote:k > K > Could someone please post some link to an official Compaq statement about B > that iVMS thing and what it will actually do that VMS won't do ? >     8 http://www.compaq.com/newsroom/pr/2001/pr2001062501.html   It will run on IA-64  ;-)t -- t Keith Brownu kbrown780@isd.neti   ------------------------------  % Date: Wed, 27 Jun 2001 23:00:57 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)) Subject: Re: Full port of VMS to Itanium. L Message-ID: <rdeininger-2706012300580001@user-2ivecak.dialup.mindspring.com>  ; In article <3B3A653B.8FA5C938@infopuls.com>, Christof Brass  <brass@infopuls.com> wrote:i    u@ > BTW what happens with NSK? Will lockstep find another way into > some IA63?  J A Tandem NSK person has already told this newsgroup that IA64 has an extraD signal to support lockstep now.  This was in the works before Compaq bought Tandem.  J He also hinted that off-the-shelf CPUs tend to require extensive debuggingH before they support NSK's needs.  So the details may take quite a bit of@ work, but the architecture is already in the right neighborhood.  < He also said IA64 has something vaguely like to PALmode now.  G In light of this, I think it's possible limited-functionality, in-housep; examples of VMS could be built on the current itanium chip.-   -- . Robert Deininger rdeininger@mindspring.com8   ------------------------------  % Date: Thu, 28 Jun 2001 00:03:06 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>a) Subject: Re: Full port of VMS to Itanium.b, Message-ID: <3B3AAC72.2E1EE619@videotron.ca>   Keith Brown wrote:M > > Could someone please post some link to an official Compaq statement aboutaD > > that iVMS thing and what it will actually do that VMS won't do ? > >r > : > http://www.compaq.com/newsroom/pr/2001/pr2001062501.html  # That page has no mention of "iVMS".l   ------------------------------  % Date: Thu, 28 Jun 2001 14:14:51 +1000e- From: "Paul Nankervis" <paulnank@au1.ibm.com> ) Subject: Re: Full port of VMS to Itanium.s/ Message-ID: <9heb08$7pqm$1@poknews.pok.ibm.com>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B3A1304.16D18E86@videotron.ca... >aJ > Intel will be able to claim that its chips run the worlds most important stockeL > exchanges (and all the other critical applications which Tandem supports). Nowo! > is not the time to abandon VMS.t >cL > Compaq will quietly pull out of VMS over a long period of time and attract as% > little attention to it as possible.h  E I am usually just a lurker to this newsgroup - mainly to keep up witht whateverF the latest VMS happenings are. I never imagined traffic levels like we	 currently  have.m  K But I am really amazed at the the negativity in many of the postings at thet moment!nJ Compaq just looked into their crystal ball and discovered that they had to makeD changes in order to keep the VMS platform competitive. They made the decisionE to invest significant sums of money which will ultimately improve thef performance I of VMS and lower the cost of hardware to run it on. This would seem to bepL the most positive committment to VMS I have seen in a long time - and yet weK see many postings in which people think Compaq is actually abandoning VMS!!   L I really don't get it! Probably the worst thing Compaq could have done would beB to leave VMS as it was so that it would eventually die with Alpha.  L I suspect that if half the effort of writing notes critizing Compaq for this decisionL was spent on telling other people, especially managers, about how Compaq areK **investing** in VMS, then VMS would regain some portion of its popularity.a  H Give it a go! Think **positive** and PROMOTE  VMS!  After all the peopleL in this group influence far more people than Compaq marketing ever will (!).I Your opinions do count and will probably collectivelly decide the fate oft VMS.   Paul Nankervis   ------------------------------  % Date: Thu, 28 Jun 2001 00:46:13 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>u) Subject: Re: Full port of VMS to Itanium.d, Message-ID: <3B3AB68A.3222E975@videotron.ca>   Paul Nankervis wrote:oJ > Give it a go! Think **positive** and PROMOTE  VMS!  After all the peopleN > in this group influence far more people than Compaq marketing ever will (!).  M That is the exact problem. Why should the customers constantly fight aghainstnH the vendor in order to prevent that vendor's product from being canned ?  L If a vendor has a product it does not wish to market, then the vendor shouldM be left alone. It is pointless to fight that vendor and try to go against the  vendor's strategic directions.  J You see this an an investment in VMS. Technically yes. But politically no.E Compaq is spending a bit fo dollars in order to allow the sale of the J architecture that will give it a whole wad of money. The whole impetus forL this move is not to push VMS but rather to get rid of Alpha. The Port of VMS/ is a necessary evil to allow the sale of Alpha.w  J If Compaq had though that VMS on IA64 would have been great, how come theyJ didn't announce the port a long time ago, as it had announced for True64 ?  K Porting VMS isn't enough. It needs to be marketed especially in a period of2N uncertainty. If VMS continues to be neglected by Compaq from the point of viewJ of Marketing, then the port to IA64 will be meaningless and without effectK because nobody will notice and Compaq won't start to push VMS as a solutiong against NT.7   ------------------------------    Date: 27 Jun 2001 17:02:35 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)L! Subject: GEM (was: Compaq proves)o3 Message-ID: <ToWUiFamj3T6@eisner.encompasserve.org>g  b In article <3B3A0ED5.169B8378@hiyall.zko.dec.com>, John Reagan <reagan@hiyall.zko.dec.com> writes: > Bob Koehler wrote: >> oE >> I wonder how closely the language the GEM back end reads resemblesd >> either of these?  >>   > H > The GEM CIL (Compact Intermediate Language) does have some resemblance                ^^^^^^^D > to an assembler's input.  There are ADD, SUB, LABEL, BRANCH, CALL,B > FETCH, STORE, etc. tuples.  The current GEM CIL manual lists 2763 > different tuples that a front-end could generate.u  7 At least the renaming committee didn't get that far :-)    ------------------------------  % Date: Wed, 27 Jun 2001 13:26:33 -0700t* From: "Jack Peacock" <peacock@simconv.com>) Subject: Golden Opportunity for Microsoft 4 Message-ID: <amr_6.4512$Ib.479694@news1.primary.net>  E The Compaq-induced FUD over VMS et al. for the next three years could1C prove to be more profitable to Microsoft than Compaq or Intel.  Now7G those who have the religion will bite the conversion bullet and move to-H iVMS, but for those of us in small companies the real alternative is NT, not Solaris or Linux.:  H Anyone still trying to sell VMS based apps today knows there is a lot ofD immediate customer resistance once it's discovered the programs alsoE require an Alpha server.  In our experience the only resistance to NTnG has been from entrenched Netware sys admins who don't want to sacrifice H their Novell expertise (gee, sounds familiar, almost like VMS).  We haveF already made the strategic decision to develop all new products on NT,F and that effort is under way now.  The death of Alpha has virtually noD effect on our business.  What will make a difference is the eventualG demise of Netware, since it will open up sites for us to do conversionseF to NT.  (All our VMS customers already have NT servers, no opportunity there.)l  H It's obvious MS knows the main issue with their OS is stability, witnessG the effort in Win 2K.  With development budgets that make the VMS group E look like a garage outfit they can accomplish quite a bit in the next B three years. If NT 2004 is as dependable as VMS V5.x then VMS willD shrink to the customer base size of IBM mainframes, a few large richE customers to sustain it but essentially irrelevant to the mainstream.e3 Isn't that the marketing strategy for VMS even now?   H We still have VMS customers, in fact they are one of our biggest revenue> sources, but we can read spreadsheets.  Steady decline, no new@ customers, no reason to put more effort into it.  My money is onD Microsoft, so I'm in a quite literal sense betting my paycheck on MS2 delivering the VMS replacement for The Rest Of Us.  F Years ago we were on that ISV list for VMS application providers.  ForF all I know we are still listed, but we don't advertise VMS apps or try? to sell them to new customers.  I suspect that's the case for alH substantial portion of the ISVs.  The 5000 apps are vaporware (deadware?E obsoleteware? landfillware?).  In practical terms I'd be surprised if G the number of apps ported to iVMS are more than 1000 at most.  I'm suretD the people who need them will pay the price, but we won't be in thatG group of providers.  And not because the Alpha is gone.  Even if Compaqt? had continued on to EV8, we would still switch to NT.  Strictlyn: economics, just like Capellas' decision to kill the Alpha.  H For all the complaints about BSODs, our NT network has proven to be justA as reliable as the VMS cluster.  Users love SQL Server, but don't F mention Rdb if you value your life.  DCPS and device libraries provideG minimal print functionality, but if we get a color inkjet it just plugsrH in to NT and the color reports come out a few minutes later.  VMS offersH the reliability, but nothing more.  Sad to say that's not enough to makeE it in the 21st century.  VMS is destined to be the Studebaker for the1H computer world.  Lovingly preserved once it's gone but beloved only by a handful during it's lifetime.l  E One good point, Alphas should be meeting the ten year qualifying rule F for alt.folklore.computers so I'll soon be able to reminisce about theH good ole AXP VMS days instead of the good ole TOPS-20 days.  I envy HoffF and the VMS group, porting will be a systems programmer heaven for theF next few years.  The short time I spent modifying TOPS-20 code for theF company I worked for (does anyone remember TRAFFIC-20?) was one of theF most enjoyable jobs I had.  Grinding out VB code pays the bills but it( lacks the mystique of assembly language.    Jack Peacock    ------------------------------  % Date: Wed, 27 Jun 2001 19:23:57 -0400(+ From: "Main, Kerry" <Kerry.Main@compaq.com>h- Subject: RE: Golden Opportunity for MicrosofthR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7EC1@kaoexc01.americas.cpqcorp.net>   Jack,e  G >>> If NT 2004 is as dependable as VMS V5.x then VMS will shrink to theu( customer base size of IBM mainframes <<<   Something to consider -s  G The above statement assumes that Customer availability, scalability andoH security requirements in 2004 will be the same as today. Given that mostK Customers have less than 5-10% of their business on the Internet today, butjK are expected to have about 60+% of their business in 2004, do you not thinktH that matching tomorrows requirements with todays technologies is a risky	 approach?      Regards,  
 Kerry Main Senior Consultant  Compaq Canada Inc. Professional Servicese Voice: 613-592-4660u Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----/ From: Jack Peacock [mailto:peacock@simconv.com]s Sent: June 27, 2001 4:27 PM  To: Info-VAX@Mvb.Saic.Como) Subject: Golden Opportunity for Microsofte    E The Compaq-induced FUD over VMS et al. for the next three years could C prove to be more profitable to Microsoft than Compaq or Intel.  Now G those who have the religion will bite the conversion bullet and move toeH iVMS, but for those of us in small companies the real alternative is NT, not Solaris or Linux.p  H Anyone still trying to sell VMS based apps today knows there is a lot ofD immediate customer resistance once it's discovered the programs alsoE require an Alpha server.  In our experience the only resistance to NT G has been from entrenched Netware sys admins who don't want to sacrificetH their Novell expertise (gee, sounds familiar, almost like VMS).  We haveF already made the strategic decision to develop all new products on NT,F and that effort is under way now.  The death of Alpha has virtually noD effect on our business.  What will make a difference is the eventualG demise of Netware, since it will open up sites for us to do conversionswF to NT.  (All our VMS customers already have NT servers, no opportunity there.)e  H It's obvious MS knows the main issue with their OS is stability, witnessG the effort in Win 2K.  With development budgets that make the VMS group(E look like a garage outfit they can accomplish quite a bit in the nextyB three years. If NT 2004 is as dependable as VMS V5.x then VMS willD shrink to the customer base size of IBM mainframes, a few large richE customers to sustain it but essentially irrelevant to the mainstream.e3 Isn't that the marketing strategy for VMS even now?   H We still have VMS customers, in fact they are one of our biggest revenue> sources, but we can read spreadsheets.  Steady decline, no new@ customers, no reason to put more effort into it.  My money is onD Microsoft, so I'm in a quite literal sense betting my paycheck on MS2 delivering the VMS replacement for The Rest Of Us.  F Years ago we were on that ISV list for VMS application providers.  ForF all I know we are still listed, but we don't advertise VMS apps or try? to sell them to new customers.  I suspect that's the case for ahH substantial portion of the ISVs.  The 5000 apps are vaporware (deadware?E obsoleteware? landfillware?).  In practical terms I'd be surprised ifSG the number of apps ported to iVMS are more than 1000 at most.  I'm surevD the people who need them will pay the price, but we won't be in thatG group of providers.  And not because the Alpha is gone.  Even if Compaql? had continued on to EV8, we would still switch to NT.  Strictlyl: economics, just like Capellas' decision to kill the Alpha.  H For all the complaints about BSODs, our NT network has proven to be justA as reliable as the VMS cluster.  Users love SQL Server, but don'ttF mention Rdb if you value your life.  DCPS and device libraries provideG minimal print functionality, but if we get a color inkjet it just plugs H in to NT and the color reports come out a few minutes later.  VMS offersH the reliability, but nothing more.  Sad to say that's not enough to makeE it in the 21st century.  VMS is destined to be the Studebaker for thehH computer world.  Lovingly preserved once it's gone but beloved only by a handful during it's lifetime.   E One good point, Alphas should be meeting the ten year qualifying rulesF for alt.folklore.computers so I'll soon be able to reminisce about theH good ole AXP VMS days instead of the good ole TOPS-20 days.  I envy HoffF and the VMS group, porting will be a systems programmer heaven for theF next few years.  The short time I spent modifying TOPS-20 code for theF company I worked for (does anyone remember TRAFFIC-20?) was one of theF most enjoyable jobs I had.  Grinding out VB code pays the bills but it( lacks the mystique of assembly language.    Jack Peacock    ------------------------------  % Date: Wed, 27 Jun 2001 16:36:08 -0700=! From: Tom Linden <tom@kednos.com> - Subject: RE: Golden Opportunity for Microsofts9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEOOCNAA.tom@kednos.com>a  E They should be so lucky.  You underestimate the size of the mainframea market.  Maybe compaq=H could license Microsoft's DLL's, at least the ones without memory leaks.   > -----Original Message-----2 > From: Main, Kerry [mailto:Kerry.Main@compaq.com]( > Sent: Wednesday, June 27, 2001 4:24 PM > To: Info-VAX@Mvb.Saic.Come/ > Subject: RE: Golden Opportunity for Microsoft  >t >l > Jack,  >eI > >>> If NT 2004 is as dependable as VMS V5.x then VMS will shrink to theM* > customer base size of IBM mainframes <<< >r > Something to consider -  >tI > The above statement assumes that Customer availability, scalability anduJ > security requirements in 2004 will be the same as today. Given that mostB > Customers have less than 5-10% of their business on the Internet > today, butC > are expected to have about 60+% of their business in 2004, do yout > not thinkwJ > that matching tomorrows requirements with todays technologies is a risky > approach?o >s >r
 > Regards, >F > Kerry Main > Senior Consultant  > Compaq Canada Inc. > Professional Servicest > Voice: 613-592-4660M > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com >  >  > -----Original Message-----1 > From: Jack Peacock [mailto:peacock@simconv.com]4 > Sent: June 27, 2001 4:27 PMo > To: Info-VAX@Mvb.Saic.Com-+ > Subject: Golden Opportunity for Microsoft2 >0 > G > The Compaq-induced FUD over VMS et al. for the next three years couldFE > prove to be more profitable to Microsoft than Compaq or Intel.  NowuI > those who have the religion will bite the conversion bullet and move tosJ > iVMS, but for those of us in small companies the real alternative is NT, > not Solaris or Linux.p >nJ > Anyone still trying to sell VMS based apps today knows there is a lot ofF > immediate customer resistance once it's discovered the programs alsoG > require an Alpha server.  In our experience the only resistance to NTfI > has been from entrenched Netware sys admins who don't want to sacrificeSJ > their Novell expertise (gee, sounds familiar, almost like VMS).  We haveH > already made the strategic decision to develop all new products on NT,H > and that effort is under way now.  The death of Alpha has virtually noF > effect on our business.  What will make a difference is the eventualI > demise of Netware, since it will open up sites for us to do conversions8H > to NT.  (All our VMS customers already have NT servers, no opportunity	 > there.)F >zJ > It's obvious MS knows the main issue with their OS is stability, witnessI > the effort in Win 2K.  With development budgets that make the VMS group G > look like a garage outfit they can accomplish quite a bit in the nextaD > three years. If NT 2004 is as dependable as VMS V5.x then VMS willF > shrink to the customer base size of IBM mainframes, a few large richG > customers to sustain it but essentially irrelevant to the mainstream. 5 > Isn't that the marketing strategy for VMS even now?a >rJ > We still have VMS customers, in fact they are one of our biggest revenue@ > sources, but we can read spreadsheets.  Steady decline, no newB > customers, no reason to put more effort into it.  My money is onF > Microsoft, so I'm in a quite literal sense betting my paycheck on MS4 > delivering the VMS replacement for The Rest Of Us. >oH > Years ago we were on that ISV list for VMS application providers.  ForH > all I know we are still listed, but we don't advertise VMS apps or tryA > to sell them to new customers.  I suspect that's the case for aeJ > substantial portion of the ISVs.  The 5000 apps are vaporware (deadware?G > obsoleteware? landfillware?).  In practical terms I'd be surprised ifsI > the number of apps ported to iVMS are more than 1000 at most.  I'm sureyF > the people who need them will pay the price, but we won't be in thatI > group of providers.  And not because the Alpha is gone.  Even if CompaqeA > had continued on to EV8, we would still switch to NT.  Strictly < > economics, just like Capellas' decision to kill the Alpha. >fJ > For all the complaints about BSODs, our NT network has proven to be justC > as reliable as the VMS cluster.  Users love SQL Server, but don'ttH > mention Rdb if you value your life.  DCPS and device libraries provideI > minimal print functionality, but if we get a color inkjet it just plugspJ > in to NT and the color reports come out a few minutes later.  VMS offersJ > the reliability, but nothing more.  Sad to say that's not enough to makeG > it in the 21st century.  VMS is destined to be the Studebaker for thepJ > computer world.  Lovingly preserved once it's gone but beloved only by a > handful during it's lifetime.a >yG > One good point, Alphas should be meeting the ten year qualifying ruleeH > for alt.folklore.computers so I'll soon be able to reminisce about theJ > good ole AXP VMS days instead of the good ole TOPS-20 days.  I envy HoffH > and the VMS group, porting will be a systems programmer heaven for theH > next few years.  The short time I spent modifying TOPS-20 code for theH > company I worked for (does anyone remember TRAFFIC-20?) was one of theH > most enjoyable jobs I had.  Grinding out VB code pays the bills but it* > lacks the mystique of assembly language. >    Jack Peacock  >u   ------------------------------  % Date: Wed, 27 Jun 2001 17:35:04 -0700 * From: "Jack Peacock" <peacock@simconv.com>- Subject: Re: Golden Opportunity for Microsoft 4 Message-ID: <9%u_6.4525$Ib.480379@news1.primary.net>  . "Tom Linden" <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIMEOOCNAA.tom@kednos.com...iG > They should be so lucky.  You underestimate the size of the mainframec > marketE No, I know the mainframe market has lots and lots of dollars, but thecG number of customers is relatively small.   Everyone would like to get aoD piece of the action but the ante to play in the big stakes market isG very high too.  I work for a small company where our target customer is.F under 1000 employees.  They aren't going to be buying anything with 32E CPUs, 128GB of RAM and 100TB of SAN disk in it.  NT on a dual CPU x86yC server is ideal for that market, as VMS and the MicroVAX once were.rE Ten years ago VMS was ideal for us, low support costs once installed,iG remote maintenance via modem, and a customer lock in as they rarely hadrH anyone trained on VMS ("does that run under MS-DOS 5.0?").  We have beenH able to keep customers through 4-5 generations of VMS upgrades over moreB than 15 years (some going back all the way to RSX), because it all happened magically overnight.0  F NT now has most of the same ingredients.  Admin Terminal Services overF the internet gives us remote maintenance at tolerable speeds so we canB still do the magic overnight fixes.  People are more familiar withH Windows but very few have the skill to manage a system, so we still haveE little competition from the (usually non-existent) in-house IT staff.eH Best of all, PCs have lowered the customer's expectations of reliabilityH and service from the standards of twenty years ago.  The idea of a phoneG call followed by a magic fix appearing on their system still astonishestH customers conditioned to four hours on hold to a support line that can't answer the question anyway.   G We don't offer mainframe levels of support, teams of engineers ready to-E hop on a plane and live at the customer site for months, but darn few G companies can afford that.  I think VMS success at the lower end of the ? spectrum came in no small measure because of the stable, easilypE maintainable environment it offered.  But we now have NT to fill thatoE niche, so perhaps it is best VMS moves to be the high end proprietary E system at the edge of the mainframe market.  Compaq shareholders willuG see some return on their investment, and the rest of us will move on toa another OS.:  E EXEC 8, SCOPE, KRONOS, OS8, RSX, CP/M, TOPS, Unix, VMS, times change,  now NT gets it's chance.    Jack Peacock    ------------------------------  % Date: Wed, 27 Jun 2001 17:55:09 -0700h* From: "Jack Peacock" <peacock@simconv.com>- Subject: Re: Golden Opportunity for Microsoftr4 Message-ID: <_hv_6.4527$Ib.480425@news1.primary.net>  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageH news:BE56C50EA024184DAF48F0B9A47F5CF4AD7EC1@kaoexc01.americas.cpqcorp.ne t...E > The above statement assumes that Customer availability, scalabilityk andiE > security requirements in 2004 will be the same as today. Given thats mostB > Customers have less than 5-10% of their business on the Internet
 today, butG > are expected to have about 60+% of their business in 2004, do you not  thinktD > that matching tomorrows requirements with todays technologies is a riskyh > approach?  >kG Sure, by dependable I meant it's reliable enough to run the business on F it.  VMS 3 and 4 were okay but for those who remember that far back itF was not the Golden Age of VMS.  VMS 5 was the point where we could putC in a server and expect it to last indefinitely.  NT already ahs thet@ feature set to address the small business that needs an internetC connection.  Our biggest demand is an NT 4 SBS system with a DSL or C cable modem connection.  NT SBS 4 mostly worked (we quickly learnedtH about modem pools and fax server).  Win 2K may be the point where we seeG that positive comparison to VMS of a decade ago, the point where we canrF install it at the larger company and not have to live there to keep it running.  E For most of our customers NT 4 is already good enough.  The ones that G run 24 hours (casinos, factories) need something a little better, so we D still have VMS for those places.  But VMS is not the environment forE internet development (please don't quote the list of tools, I've seeniE them, no thanks, VMS doesn't even have a competitive browser).  We'vesC hit that wall several times already with customers.  NT will be our E solution for internet e-business, at least the kind we envision a fewC years from now.n  E One interesting aside...the more things change the more they stay theiG same.  Remember GE timeshare?  It seems not many do these days.  One ofBB our growth areas is selling timeshare...err, applications hosting.G Users connect over the internet and run our applications on our Alphas. E They think its all Windows, after all, that's what's on their PC, andbG the VT emulator is in a window.  Except there are no onsite servers, nosC backups, no hardware crashes, and no upfront equipment and softwarei? costs.  And emulators are remarkably reliable even on old Win9xnB machines.  Dirt cheap for us too, our cost is virtually nothing toC operate it.  I give all the credit to Microsoft for reinventing theuH wheel and calling it Applications Hosting.  VMS is still our only choice for 24/7 timeshare server.    Jack Peacocke   ------------------------------  % Date: Wed, 27 Jun 2001 20:53:16 -0500a% From: Keith Brown <kbrown780@isd.net> - Subject: Re: Golden Opportunity for Microsofte/ Message-ID: <tjl37jrmb38n99@corp.supernews.com>e   Jack Peacock wrote:i  0 > "Tom Linden" <tom@kednos.com> wrote in message5 > news:CIEJLCMNHNNDLLOOGNJIMEOOCNAA.tom@kednos.com...jH >> They should be so lucky.  You underestimate the size of the mainframe	 >> market G > No, I know the mainframe market has lots and lots of dollars, but the I > number of customers is relatively small.   Everyone would like to get apF > piece of the action but the ante to play in the big stakes market isI > very high too.  I work for a small company where our target customer iskH > under 1000 employees.  They aren't going to be buying anything with 32G > CPUs, 128GB of RAM and 100TB of SAN disk in it.  NT on a dual CPU x86sE > server is ideal for that market, as VMS and the MicroVAX once were. G > Ten years ago VMS was ideal for us, low support costs once installed, I > remote maintenance via modem, and a customer lock in as they rarely hadyJ > anyone trained on VMS ("does that run under MS-DOS 5.0?").  We have beenJ > able to keep customers through 4-5 generations of VMS upgrades over moreD > than 15 years (some going back all the way to RSX), because it all > happened magically overnight.r > H > NT now has most of the same ingredients.  Admin Terminal Services overH > the internet gives us remote maintenance at tolerable speeds so we canD > still do the magic overnight fixes.  People are more familiar withJ > Windows but very few have the skill to manage a system, so we still haveG > little competition from the (usually non-existent) in-house IT staff.oJ > Best of all, PCs have lowered the customer's expectations of reliabilityJ > and service from the standards of twenty years ago.  The idea of a phoneI > call followed by a magic fix appearing on their system still astonishestJ > customers conditioned to four hours on hold to a support line that can't > answer the question anyway.r > I > We don't offer mainframe levels of support, teams of engineers ready tosG > hop on a plane and live at the customer site for months, but darn fewtI > companies can afford that.  I think VMS success at the lower end of the)A > spectrum came in no small measure because of the stable, easilypG > maintainable environment it offered.  But we now have NT to fill that G > niche, so perhaps it is best VMS moves to be the high end proprietary G > system at the edge of the mainframe market.  Compaq shareholders willvI > see some return on their investment, and the rest of us will move on tou
 > another OS.  > G > EXEC 8, SCOPE, KRONOS, OS8, RSX, CP/M, TOPS, Unix, VMS, times change,h > now NT gets it's chance. >    Jack Peacockh >  >   L Many are beginning to feel that the shine has worn off of Microsoft.  At my H site we have more trouble than you can imagine trying to keep a 700+ NT B machines running (a couple thousand company wide). They throw new G contractors at it all the time at a very high cost. The AlphaVMS stuff eJ still just runs and runs at a fraction of the cost of NT/2000/XP/whatever G it is called this week..  The new Golden child is Linux.  IDC predicts aL Linux will own half the desktop and most of the small server market by 2010.   --   Keith Brownm kbrown780@isd.netf   ------------------------------  % Date: Wed, 27 Jun 2001 20:54:54 -0500e% From: Keith Brown <kbrown780@isd.net> - Subject: RE: Golden Opportunity for Microsofti/ Message-ID: <tjl3akj77huqc5@corp.supernews.com>i   Tom Linden wrote:v  G > They should be so lucky.  You underestimate the size of the mainframee > market.  Maybe compaq J > could license Microsoft's DLL's, at least the ones without memory leaks. >  >> -----Original Message----- 3 >> From: Main, Kerry [mailto:Kerry.Main@compaq.com]M) >> Sent: Wednesday, June 27, 2001 4:24 PMh >> To: Info-VAX@Mvb.Saic.Com0 >> Subject: RE: Golden Opportunity for Microsoft >> >> >> Jack, >>J >> >>> If NT 2004 is as dependable as VMS V5.x then VMS will shrink to the+ >> customer base size of IBM mainframes <<<  >> >> Something to consider - >>J >> The above statement assumes that Customer availability, scalability andK >> security requirements in 2004 will be the same as today. Given that mosteC >> Customers have less than 5-10% of their business on the Internet 
 >> today, butuD >> are expected to have about 60+% of their business in 2004, do you >> not thinkK >> that matching tomorrows requirements with todays technologies is a riskym >> approach? >> >> >> Regards,t >>
 >> Kerry Main1 >> Senior Consultant >> Compaq Canada Inc.a >> Professional Services >> Voice: 613-592-4660 >> Fax  :  819-772-7036d >> Email: Kerry.Main@Compaq.comi >> >> >> -----Original Message-----l2 >> From: Jack Peacock [mailto:peacock@simconv.com] >> Sent: June 27, 2001 4:27 PM >> To: Info-VAX@Mvb.Saic.Com, >> Subject: Golden Opportunity for Microsoft >> >>H >> The Compaq-induced FUD over VMS et al. for the next three years couldF >> prove to be more profitable to Microsoft than Compaq or Intel.  NowJ >> those who have the religion will bite the conversion bullet and move toK >> iVMS, but for those of us in small companies the real alternative is NT,l >> not Solaris or Linux. >>K >> Anyone still trying to sell VMS based apps today knows there is a lot ofaG >> immediate customer resistance once it's discovered the programs also H >> require an Alpha server.  In our experience the only resistance to NTJ >> has been from entrenched Netware sys admins who don't want to sacrificeK >> their Novell expertise (gee, sounds familiar, almost like VMS).  We havefI >> already made the strategic decision to develop all new products on NT,gI >> and that effort is under way now.  The death of Alpha has virtually noaG >> effect on our business.  What will make a difference is the eventuallJ >> demise of Netware, since it will open up sites for us to do conversionsI >> to NT.  (All our VMS customers already have NT servers, no opportunityo
 >> there.) >>K >> It's obvious MS knows the main issue with their OS is stability, witnessCJ >> the effort in Win 2K.  With development budgets that make the VMS groupH >> look like a garage outfit they can accomplish quite a bit in the nextE >> three years. If NT 2004 is as dependable as VMS V5.x then VMS willaG >> shrink to the customer base size of IBM mainframes, a few large richnH >> customers to sustain it but essentially irrelevant to the mainstream.6 >> Isn't that the marketing strategy for VMS even now? >>K >> We still have VMS customers, in fact they are one of our biggest revenueaA >> sources, but we can read spreadsheets.  Steady decline, no newOC >> customers, no reason to put more effort into it.  My money is onmG >> Microsoft, so I'm in a quite literal sense betting my paycheck on MSc5 >> delivering the VMS replacement for The Rest Of Us.p >>I >> Years ago we were on that ISV list for VMS application providers.  ForoI >> all I know we are still listed, but we don't advertise VMS apps or tryeB >> to sell them to new customers.  I suspect that's the case for aK >> substantial portion of the ISVs.  The 5000 apps are vaporware (deadware? H >> obsoleteware? landfillware?).  In practical terms I'd be surprised ifJ >> the number of apps ported to iVMS are more than 1000 at most.  I'm sureG >> the people who need them will pay the price, but we won't be in thatsJ >> group of providers.  And not because the Alpha is gone.  Even if CompaqB >> had continued on to EV8, we would still switch to NT.  Strictly= >> economics, just like Capellas' decision to kill the Alpha.d >>K >> For all the complaints about BSODs, our NT network has proven to be just D >> as reliable as the VMS cluster.  Users love SQL Server, but don'tI >> mention Rdb if you value your life.  DCPS and device libraries providefJ >> minimal print functionality, but if we get a color inkjet it just plugsK >> in to NT and the color reports come out a few minutes later.  VMS offerseK >> the reliability, but nothing more.  Sad to say that's not enough to makenH >> it in the 21st century.  VMS is destined to be the Studebaker for theK >> computer world.  Lovingly preserved once it's gone but beloved only by ae  >> handful during it's lifetime. >>H >> One good point, Alphas should be meeting the ten year qualifying ruleI >> for alt.folklore.computers so I'll soon be able to reminisce about thetK >> good ole AXP VMS days instead of the good ole TOPS-20 days.  I envy HoffiI >> and the VMS group, porting will be a systems programmer heaven for theaI >> next few years.  The short time I spent modifying TOPS-20 code for the I >> company I worked for (does anyone remember TRAFFIC-20?) was one of theiI >> most enjoyable jobs I had.  Grinding out VB code pays the bills but it + >> lacks the mystique of assembly language.V >>    Jack Peacock >> >  >      Tom Linden wrote:l  G > They should be so lucky.  You underestimate the size of the mainframet > market.  Maybe compaqtJ > could license Microsoft's DLL's, at least the ones without memory leaks. >   + How many could there be?  Maybe Two!    ;-)    -- a Keith Browne kbrown780@isd.neth   ------------------------------  % Date: Wed, 27 Jun 2001 23:40:59 -0400h2 From: rdeininger@mindspring.com (Robert Deininger)- Subject: Re: Golden Opportunity for MicrosoftbL Message-ID: <rdeininger-2706012340590001@user-2ivecak.dialup.mindspring.com>  C In article <amr_6.4512$Ib.479694@news1.primary.net>, "Jack Peacock"s <peacock@simconv.com> wrote:    lJ > We still have VMS customers, in fact they are one of our biggest revenue@ > sources, but we can read spreadsheets.  Steady decline, no new3 > customers, no reason to put more effort into it. b   <snip>  eH > Years ago we were on that ISV list for VMS application providers.  ForH > all I know we are still listed, but we don't advertise VMS apps or try" > to sell them to new customers.    G Gee, I wonder if that's why your VMS sales are in decline.  What do youSF sell?  Maybe I've been needing a copy all these years, and didn't know	 about it.n   --   Robert Deininger rdeininger@mindspring.comi   ------------------------------  % Date: Wed, 27 Jun 2001 11:06:33 -0700 & From: "Felger Carbon" <fmrfne@jps.net>  Subject: Re: IA64 Rocks My World6 Message-ID: <fxp_6.13228$n6.1205950@nntp3.onemain.com>  F Hugh Bonney <hfbonney@bolt.sonic.net> wrote in message news:fOk_6.2751 >sD > If profits, logic, ROI, and so on were most important, Intel wouldB > now drop the IA-64, write off the billion dollars, pay off a fewI > customers expenses, and develop the Alpha with enthusiasm. With Intel'srD > processing and money, they could economically sell the fastest cpu' > on the planet for many years to come.   J Uh, Hugh, the Alpha was Not Invented Here.  Human nature and hurt feelingsJ often trump technical factors...  as you could have learned over the years by reading this NG!  ;-(   ------------------------------  % Date: Wed, 27 Jun 2001 19:17:01 +0000t1 From: bengtl.net@telia.nospam.com (Bengt Larsson)@  Subject: Re: IA64 Rocks My World1 Message-ID: <3b41300c.77163325@enews.newsguy.com>m  8 In comp.arch, google@wot-club.org.uk (Chris Rijk) wrote:  _ >"del cecchi" <dcecchi@msn.com> wrote in message news:<BZa_6.158$wt2.7991@eagle.america.net>... 1 >> Check out Northstar/Pulsar/ISTAR/Sstar series.  >kF >AFAIK That chip has "vertical threading" (or coarse grained threadingC >or whatever you want to call it). If I remember correctly it holds B >two thread states on the core, and swaps between them on L1 cacheF >misses (and other events I guess) with a 3 cycle swap penalty to move6 >between threads. I think it has a 5 stage pipeline... > A >This isn't SMT, where multiple threads can be in all/most stages ? >of the pipeline at the same time. (though I'm sure people wills@ >be picky with my description). VT can be very useful but not as >good as SMT I think.o  = Another way of putting it: with SMT several instructions fromtD different threads can be executing at the same stage of execution inC different functional units at the same time (ie in the same cycle).h  = It took me a while to get the difference between SMT and morecC coarse-grain threading. There is a very nice figure illustrating ith at:d  ? http://www.realworldtech.com/page.cfm?ArticleID=RWT122600000000e   ------------------------------  # Date: Wed, 27 Jun 2001 21:38:53 GMT . From: "mulp" <michaelpettengill@earthlink.net>  Subject: Re: IA64 Rocks My WorldC Message-ID: <Nns_6.1965$th.223476@newsread1.prod.itd.earthlink.net>l  ? "Atlant Schmidt" <atlantnospam@mindspring.com> wrote in messaget( news:3B38A767.6ED07B86@mindspring.com...> >   (You can find out more in the previous edition of the "IBM= >   Journal of Research and Development" where they describeds? >   *TWO* of their latest PowerPC chips and their latest OS/390h
 >   chip.)  E This points out indirectly what should have been clue that this would I happen - one of the first things that Compaq killed was the DEC TechnicalnL Journal which is where all the unique IP was described.  Obviously IBM wantsK to talk about their unique IP and they have actually gone back to producingd
 it in volume.r   ------------------------------  # Date: Thu, 28 Jun 2001 02:46:48 GMTn) From: John Bayko <jbayko@sk.sympatico.ca>t  Subject: Re: IA64 Rocks My World/ Message-ID: <3B3A9A96.60308301@sk.sympatico.ca>    Peter Boyle wrote: [...]J@ > Intel didn't have to chop a flagship to start StrongArm sales.  @     The Intel i960, at one point the world's most popular 32-bitG embedded CPU, was tossed without regard when Intel switched to ARM. ARMbE may have been a better architecture, but the i960 was not at all bad,tC and had much life left in it - even superscalar versions, which ARMe
 doesn't have.e   ------------------------------  # Date: Thu, 28 Jun 2001 03:33:13 GMTl. From: "Stephen Fuld" <s.fuld@worldnet.att.net>  Subject: Re: IA64 Rocks My WorldF Message-ID: <Zzx_6.7984$J91.172919@bgtnsc06-news.ops.worldnet.att.net>  6 "John Bayko" <jbayko@sk.sympatico.ca> wrote in message) news:3B3A9A96.60308301@sk.sympatico.ca...h > Peter Boyle wrote: > [...]nB > > Intel didn't have to chop a flagship to start StrongArm sales. >pB >     The Intel i960, at one point the world's most popular 32-bitI > embedded CPU, was tossed without regard when Intel switched to ARM. ARMhG > may have been a better architecture, but the i960 was not at all bad, E > and had much life left in it - even superscalar versions, which ARMo > doesn't have.l      K Yes, but one might say, who needs slow but superscaler when you can have ansI embedded core running at 800 MHz?  When Intel made the decision, i960 wascG running at something like 100 MHz and StrongArm, without any of Intel's C process stuff was running at 200 MHz.  I have heard rumors that SA3iH (whatever it will be called) will be superscaler.  SA-2, aka Xscale, canL overlap loads with the following compute instructions, as ling as they don't< need the loaded value.  Plus StrongArm had much better powerH characteristics, which are important for many of the growth markets thatL Intel wants to get into.  I don't think you would ever see an i960 in a cellK phone or a PDA.  IMO, Intel made the right choice, even though it cost themb# something in customer loyalty, etc.a     --     -  Stephen Fulds   ------------------------------  # Date: Wed, 27 Jun 2001 21:33:25 GMTe. From: "mulp" <michaelpettengill@earthlink.net>. Subject: Re: Itanium, non-issue, stop the mailC Message-ID: <Fis_6.1616$ef.204567@newsread2.prod.itd.earthlink.net>s  D For VMS, it wouldn't be a big deal if the compilers did take care ofH everything, but they didn't when going from VAX to Alpha.  First of all,L there are 15-20 compilers that are needed to support "So what if you have toJ recompile your applications.  Big deal."  One of the compilers is MACRO-32F and another is MACRO-64; both are assembly language with one doing VAXH assembly and the other doing Alpha assembly.  The assembly code requiredK some manual tweaking to tell the compiler what was going on so the compilerIJ could correctly determine what the correct generated code was going to be.  K Another issue is going to be support of a large set of "builtins" which are.G available in nearly every higher level language.  These are things like K insert queue relative interlocked - to avoid significant overhead these arelD implemented in PAL code on Alpha which runs with interrupts disabledL allowing the multiple instructions to execute without concern for interruptsJ on the current processor and with access to the internal registers so thatL it can be determined up front whether a pagefault will occur.  Yes, they canD be coded in a user mode RTL, but the complexity will be high and the performance will suffer.  I To say that these kinds of features were stupid, that VMS and apps should J have been written only in C, or never used instructions that are unique toE VAX, is said only by someone who ignores history.  The decisions wereT correct even in hindsight.  C To say that VMS, or the descendents of the IBM 360 that has similarNC application channel commands directly driving the hardware, are nothH competitive because they aren't high volume and therefore should die, isD like saying that only different colored Accords make sense, or otherJ vehicles that are similar enough, but trains deserve to be killed off.  IfI the transportation industry had people like the dotcom'ers, you would seeoD caravans of accords hauling coal with the proforma statements of theK companies running them claiming that they will make a profit soon, once thehF volume of accords kicks in and they can get the accords without roofs, seats, and larger cargo area.n  J If you compiler writers were really that hot, it would be just a matter ofE another flavor of code morphing software and a faster transmeta chip.g  . "Tom Linden" <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIIENGCNAA.tom@kednos.com... K > Almost the only people effected are us poor compiler writers, the rest of  > you won't seetH > anything, thanks to us.  Who cares what the underlying processor is as long > as it works well,hJ > and I have to believe that it will.  Don't cry for the loss of alpha, itL > wasn't that great anyway, but then none of you knew that anyway, thanks to > the compilers. > @ > So what if you have to recompile your applications.  Big deal. >tI > This has consumed altogether too much bandwidth, i wish we had 2 lists,  onen
 > for serioust > stuff and one for BS >p >r   ------------------------------  # Date: Wed, 27 Jun 2001 21:04:16 GMTe+ From: "wright" <wright.patterson@libero.it>t Subject: little help pleaseh6 Message-ID: <kTr_6.2005$z11.158366@news.infostrada.it>   from the following lines:   L ---------------------------------------------------------------------------- ---a
 $ Set NoOn/ $ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))C  / accept: non-translatable vms error code: 0x2A14 , %system-f-exbytlm, exceeded byte count quota ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  8   EUROME       job terminated at 20-JUN-2001 16:53:37.13     Accounting information:rD   Buffered I/O count:             701209      Peak working set size: 12064 @   Direct I/O count:                76516      Peak virtual size: 212064>   Page faults:                       906      Mounted volumes: 0 C   Charged CPU time:        0 00:01:16.46      Elapsed time:       5t 20:32:48.34hK ---------------------------------------------------------------------------   C every 7 day the application crashes with the error displayed above.o  : what happens to accept() ?     [the common TCPIP function]  / maybe the application does not release memory ?r> and ... call after call, up to the need of accept, then dies ?  9 what does it mean " exbytlm, exceeded byte count quota" ?d  " Thank You very much for your help.  
 Marco Sala   ------------------------------  % Date: Wed, 27 Jun 2001 19:12:30 -0400s) From: "Neil Rieck" <n.rieck@sympatico.ca>o Subject: Re: NYSE ; Message-ID: <HLt_6.22307$l45.2303208@news20.bellglobal.com>o   ----- Original Message -----/ From: "JF Mezei" <jfmezei.spamnot@videotron.ca>- Newsgroups: comp.os.vmse$ Sent: Wednesday, June 27, 2001 09:45 Subject: Re: NYSE,     > Neil Rieck wrote:sL > > I know the Toronto Stock Exchange (TSE) is running on aging Tandem boxes andMH > > they were waiting for new hardware (reportedly Alpha based lock-stepI > > technology). Oops. I guess they'll be waiting for MIPS based machinesm now. >0L > I thought TSE was on aging IBM platform. I know that after Digital had won thefC > Montreal Stock Exchange, they tried to go for the TSE, but failedh
 (includingF > internal reasons where employees's infighting to get the sales quota resultedL > in no cooperation between the two Digital offices and also resulted in theJ > loss of another financial institution contract and the loss of a Digital/ > customer). As I recall, IBM had the machines.F > I I was sure they were old Tandem boxes feeding a main frame (could this bel theaG IBM platform you're referring to?). BTW, I found the rest of your storyn amusing.  
 Neil Rieck Kitchener/Waterloo/Cambridge,b Ontario, Canada.! http://www3.sympatico.ca/n.rieck/e   ------------------------------  % Date: Wed, 27 Jun 2001 22:22:44 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: NYSEt, Message-ID: <3B3A94F2.5B23EBDE@videotron.ca>   Neil Rieck wrote: I > IBM platform you're referring to?). BTW, I found the rest of your story 
 > amusing.  M Good on you. But I had worked hard t setup a VAX for office automation in the N montreal office of an outfit, so much so that their toronto head office wantedL to buy a vax too. But the infighting between the two digital offices becauseH of the problem to share quotas on the bid for the toronto stock exchangeL resulted in the toronto digital office not cooprating and wanting to controlH everything and they screwed up so bad that they lost a contract that wasG theirs for the taking and the outfit went to Data General that had beens1 invited to bid but told they stood little chance.l  I Turns out that the toronto sales person was very pregnant at the time andnM Digital refused to pro-rate her quota to the number of months she was to workaK that year, so it was very important for her to get all of the quota for themH sale of the vaxes to the toronto office AND the upgrades to our montrealL office, hence her unwillingness to work with the montreal sales rep and withL me. The same thing happened for her bid for the TSE since she didn't want toL share the potential quotas with the sales rep in montreal who had succceededI in selling to the montreal exchange (which dumped VMS a few years later).l  N I learned of the quota problems only well after the saga. Had I known about itM during the bid, I would have been able to find a way to make the bid work and N for Digital not only to keep its montreal customer but also gain a prestigious toronto one.   ------------------------------   Date: 28 Jun 2001 04:20:26 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog). Subject: One more dreadful thought to consider, Message-ID: <9hebaa$k3u@gap.cco.caltech.edu>  G A horrible trend popped into my mind this evening.  Here it is for yourl unenjoyment:  A 1.  Rather than compete with Oracle in databases, sell RDB to it. N 2.  Rather than compete with Quantum in storage, sell the disk business to it.A 3.  Rather than compete with Intel in CPUs, sell the Alpha to it.n   and the sickening conclusion:   ? 4.  Rather than compete with Microsoft in OS's, sell VMS to it..  I Unfortunately in the twisted, Machiavellian, and inevitably money losing,nH logic that passes for Digipaq management this last step is as natural asK night following day.  It makes even more sense than selling it to CA. Their J support for VMS has never been remotely as strong as it was for Alpha, andD look where Alpha is now. And it isn't like they haven't already soldI various technologies out of the OS to Microsoft already. Just as they hadnK previously licensed patents to Intel and sold them a FAB and the ARM group.mF How much of Compaq's service organization is Microsoft centered?  WhatI does the port of OpenVMS to IA64 do for Compaq?  Give them a product they>E can sell?  Heck no, they never made any significant effort to sell itkJ before, and there's no reason to think that they will do so in the future.I Especially when it's head to head with Microsoft who they dare not anger. K What it does give them is a division and a huge chunk of code they can more I easily vend to the competition.  Think back, have we really seen anything K else in the last 10 years besides reshape the company to make it easier to  H sell its parts?  "Look Bill, most of the code already has been tested onI IA64.  You can just patch it into Windows 2003 and save yourself a bundleIK in development time and costs.  And we're giving it to you for a song.  WhorH knows, some of the software engineers might even agree to work for you. A What?  Sure, they'll work as contractors through one of your shamsF companies!  You want us to structure the deal that way?"   Anyone wantH to wager that this conversation has not already taken place, or that the! deal has not already been signed?l  K Once again, OpenVMS engineering, it is time to review *all* your options.   G This is not the time to trust Compaq management and blindly accept the @I employee/employer status quo.  Ask your buddies in Alpha development.  If5F Compaq management won't contractually obligate itself to an acceptableJ future for yourselves and your product then you might as well get out now.E As I pointed out earlier, all your leverage evaporates as soon as the6K OpenVMS market does, and that's going to be evident real soon now, with the K humongous FUD that Q management (not this news group!) has poured over its oK customers.  It's a move that R. Palmer might have used - crunch the revenue J so that it's easier to sell the division.  Heck, if they sign the contractI and give you what you ask for that would be fantastic FUD buster.  And if F they don't, then you'll know right then and there what your future is.= And it would really do the customers a favor to know now too.   L If you all want to go work for Microsoft that's ok, Windows could certainly K use your expertise.  Just so long as you all know ahead of time that that'so what you're doing.   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech IJ **************************************************************************J *                       RIP VMS & ALPHA                                  *J **************************************************************************   ------------------------------  # Date: Thu, 28 Jun 2001 02:23:11 GMTr4 From: "Terry C. Shannon" <terryshannon@mediaone.net>? Subject: Re: Question to Charlie Matco - reply to Terry Shannont: Message-ID: <jyw_6.720$UT1.300744@typhoon.ne.mediaone.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:OCUM8ICC9Wrs@eisner.encompasserve.org.... >s >uD > Look at this folks... you can't say the word "pissed".  I use thatE > in the context of "very angry".  Sorry to offend the offensive wordm2 > scanner.  What a whacky world.  Kids these days. >: > Policy = Dirty Words >e+ > A duhty wuhd.  Uh..uh-uh.. uh... uh-uh-uhm >  > A duhty wuhd.o >e  K Ah. That explains the "quarantine" alert I too received. I thought it mightn2 have been about a diptheria outbreak or something!   ------------------------------  # Date: Thu, 28 Jun 2001 02:29:15 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>? Subject: Re: Question to Charlie Matco - reply to Terry Shannoni: Message-ID: <%Dw_6.754$UT1.305755@typhoon.ne.mediaone.net>  9 "Alphaman" <alphaman64@nixspam-home.com> wrote in message 5 news:THj_6.11300$P5.3917039@news1.rdc1.tn.home.com...t6 > Main, Kerry <Kerry.Main@compaq.com> wrote in message >iL news:BE56C50EA024184DAF48F0B9A47F5CF4A19466@kaoexc01.americas.cpqcorp.net...= > > Was I surprised at the announcement? Sure - everyone was.c >bL > Why is being surprised by an announcement goodness?  Why not do things theB > traditional way -- NDA's, migration, slow changes, condition the3 > marketplace, survey customers, sway the consumer?c >n  E Given the amount of stuff that managed to leak out (despite some verytC stringent NDAs) during the week leading up to the announcement, thehI "traditional" approach would have provided even more grist for the rumourhK mills. With a one-week lead time, CPQ managed to keep the press pretty much L in the dark. Aside from Mike Magee at www.theinquirer.net, nobody really hadD anything on this. Not even the WSJ, which generally gets a heads-up.  L For sure the menu in the Houston Executive cafeteria is crow and humble pie.A T'will be interesting to see how they reconcile IA-64 "Emigration.K Technology" with prior claims of Alpha superiority. Of course, CPQ might beaB privy to some Intel stuff that is inaccessible to we mere mortals.   ------------------------------  # Date: Thu, 28 Jun 2001 02:30:05 GMTi4 From: "Terry C. Shannon" <terryshannon@mediaone.net>? Subject: Re: Question to Charlie Matco - reply to Terry Shannon : Message-ID: <NEw_6.768$UT1.306197@typhoon.ne.mediaone.net>  / "Roger Ivie" <ivie@cc.usu.edu> wrote in message  news:vpl4i4cOKBCO@cc.usu.edu...u7 > In article <3B39792C.CC6CD6B6@videotron.ca>, JF Mezei-& <jfmezei.spamnot@videotron.ca> writes:L > > The bigger the chip, the more there are chances for a small defect whichL > > reduces the maximum Mhz rating for that chip. In other words, the bigger thelJ > > chip, the lower the yields, the higher the cost per chip, and the feweF > > quanities of chips that run fast enough you can produce. Alpha, by having aL > > reduced instruction set with no attempt at emulating legacy architecture can B > > be condensed more, and they can then concentrate on perforance improvements2 > > such as pipelining, branch prediction etc etc. >e5 > By that argument, they should be moving VMS to ARM.u   VMS on my iPAQ? Cool!m   ------------------------------  % Date: Wed, 27 Jun 2001 23:11:12 -0400d  From: John Santos <JOHN@egh.com>? Subject: Re: Question to Charlie Matco - reply to Terry Shannon.6 Message-ID: <1010627225008.51014B-100000@Ives.egh.com>  - On Wed, 27 Jun 2001, David J. Dachtera wrote:n   > "Bradford J. Hamilton" wrote:l > > 
 > > Hi Terry,g > > N > > I understand that the last 36 hours has been very trying for all involved. > > S > > I don't think that there is anyone (c.o.v. posters, COMPAQ, even Intel) *wants* W > > to destroy VMS.  I *do* think that a lot of the "negativity" seen in this NG arisese3 > > from the *way* in which the news was delivered.l >   > For myself, I'd tend to agree. > G > Not that doing it doesn't make sense - we've been beating them bloodyMI > about VMS on Intel since news of Emerald first appeared. That's not the  > point. > G > The point is that it makes sense for Itanic, Itanic-capable mobos andv > VMS to "grow-up" together: > > > o There are no commercially viable Itanic chips as of today.G > o For the prototype chips that exist, mobo designs are still in flux.dJ > o VMS on Itanic is today a challenge, as opposed to the impossibility it > was once thought to be.t > I > Just as Alpha, Alpha mobos and AXP/VMS grew from VAX/VMS V5.4-2, so nowo: > Itanic, Itanic mobos and OpenVMS-IA64 can grow together. > G > Taken together, this could be the most serious threat to M$ since theo > rise of Linux.  < David?  Is this you?  Do I see a ray of positive light about the future of VMS here?  :-)  8 (No, I don't know what postive light is, the opposite of; negative light, I suppose, which which be stream of photons1 with negative energy...)  J > ...but yes, perception being everything, the presentation is likely more4 > responsible for the reaction than the news itself. > --   > David J. Dachterao > dba DJE Systems5 > http://www.djesys.com/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/s  ? One point several people have made is that the current Itaniumsi; are even more expensive than DS10's.  I don't think it is a.< fair comparison right now.  I think the PC manufacturers who? have announced systems (I think you can order them, but I don'te> know how long you have to wait for delivery) know that at this= time, they can charge all the market will bear, because earlyc< adopters desperately need them.  For example, the people who> make Quicken (Intuit?) probably need to buy a few of them so aC version of Quicken for NT on IA64 will be ready by the time Itaniumi? systems ship in volume.  I'm sure they are willing to buy a fewo? systems at $8K a pop just for testing.  Same with all the othere big PC software manufacturers.  > In 6 months or so, I'm sure the price will drop a lot, and theA prices then will be a better comparison than today's prices.  ThetB long-term question is will it eventually (in 3 years) drop so that@ the price-performance is competitive with x86 PC's (at least for? native apps) or will it stay at a premium.  If it drops to thathA level, I think it will eventually replace the x86 as the standard < desktop PC, even for people with no rational need for 64 bit? address space.  (Especially if there is a killer app available,c" which for PC's seems to be games.)  @ If that happens and the VMS-IA64 port works, then maybe you will- at long last have your affordable VMS system.h  A I know that is a lot of "if's" but it is something to hope for...   H > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. > B > Feel free to exercise your rights of free speech and expression. > H > However, attacks against individual posters, or groups of posters, are > strongly discouraged.,   -- h John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Thu, 28 Jun 2001 03:50:37 GMTr4 From: "Terry C. Shannon" <terryshannon@mediaone.net>? Subject: Re: Question to Charlie Matco - reply to Terry Shannon ; Message-ID: <hQx_6.1148$UT1.363679@typhoon.ne.mediaone.net>H  8 "Richard D. Piccard" <piccard@ohio.edu> wrote in message" news:3B39F095.FF83B401@ohio.edu... >e > , > fabio_compaq@ep-bc.petrobras.com.br wrote: >sE > > I dont know who is this Charlie Matco which everybody talks here,o >  > [snip] > I > Years ago Terry Shannon wrote a column with that by-line, rather in then manner > of" > "Robert X. Cringely" on PCs (see  D IIRC the Charlie Matco column predated Robert X. Cringely's literaryF efforts. Outside of DECUS, from which the moniker originated, the nameK Charlie Matco first appeared in a review of the Spring 1995 DECUS symposiumnL in DEC Professional magazine. Matco's name next appeared in the October 1985J issue of Digital Review. This was rendered necessary because the author ofE the article in question (a review of DEC's Rainbow Office Workstation>K software) was still an employee of DEC Professional at the time the article- was submitted for publication.  K Matco subsequently became the author of the Rumor Roundup column in Digital I Review. The column lived on after its perpetrator departed Digital ReviewcG for greener pastures and a less tyrannical managment team. The originaleI author returned to resuscitate a failing column soon after Digital ReviewcI morphed into Digital News and Review. After that publication went throughcC another name change and ultimately went belly-up, Charlie went intouG hibernation only to enjoy a brief re-emergence during the brief life ofi BackOffice Magazine.  J But Chuckie hasn't left the building. Rantings and fulminations including:  ' http://www.acersoft.com/SKD/CM-1999.htm   ' http://www.acersoft.com/pdfs/cmatco.pdfh  , http://www.theinquirer.net/matcoinquirer.pdf  J and the even more recent CHARLIE MATCO AND THE DFWCUG BUNKER OF DOOM offerG proof of Matco's continued existence. As does the genuine first-edition L Charlie Matco coffee mug that became a part of the Computer History Museum'sI permanent DEC collection during the DECWORLD2001 event on  June 16, 2001.-   ------------------------------  % Date: Wed, 27 Jun 2001 19:30:46 -0400p' From: "Bill Todd" <billtodd@foo.mv.com>DY Subject: Re: Question to Charlie Matco - reply to Terry Shannon (and some general commentJ( Message-ID: <9hdq4q$242$1@pyrite.mv.net>  K "Magnus M" <mmad@tips.se> wrote in message news:3B39F4BD.5020906@tips.se...S > Bill Todd wrote:  K > > I've addressed the above not-yet-even-vaporware elsewhere, so I'll justmG > > remind people that *should* it ever materialize its special-purposes natureD > > (if it indeed is Alpha-specific in some way) will likely make it anythingC > > but cheap (not to mention that run-of-the-mill Itanics are moret	 expensiveh > > than Alphas already).o  I > Bill, as someone who very rarely posts to comp.os.vms (or should I calllJ > it comp.os.vms.advocacy?) but has been around since the Info-VAX days inG > the 80s I think you are off the mark here.. Have you ever been logged 3 > onto an "Itanic"? Tested some of your code on it?tC > While we all probably agree that Alpha is superior technology andFE > a much cleaner design in nearly all respects, the fact remains that E > even the current "late and slow" Itanium v1 is quite a performer insF > some specific areas (integer code not being one of them, clearly)...  L It has been observed elsewhere that first processor releases don't *have* toJ be inferior:  Alpha, for example, established a performance lead right out of the starting gate.   K And I'm not sure what relevance your comment has to the material you quotedwJ above.  I've never said that IA64 is a real pig, only that its performance7 is inferior to Alpha's in most areas (cryptographic andtD floating-point-intensive applications being exceptions) and that theF differing technologies of the two approaches seemed such as to make itI likely that Alpha could maintain or extend its performance lead over timetH (an opinion I've mostly stolen from people far more qualified to hold itC than I am:  highlights include any uses with significant amounts ofiG thread-level parallelism - e.g., virtually any kind of server - and thefG apparently typical cases where even single-threaded code paths are less L regular/predictable than in some floating-point applications).  Oh, and thatJ it seems to consume considerably more die space (thus affecting yields and4 price) and power than an Alpha of equal performance.  I IA64 does not appear to be so bad that, given Intel's marketing clout, itoJ can't be successful (unfortunate given the current turn of events, becauseL if it *were* really unsuccessful then Intel might actually do something withK Alpha).  But neither does it appear anywhere nearly good enough to shut outhI competition from an Alpha series developed at anything beyond subsistencel levels.h  L Aggressiveness, of course, is relative, but if the eetimes quote just postedH by Neil Reick is correct in its assertion that current Alpha developmentG costs Compaq $150 million annually, then the fact that VMS-based annualiH *profits* a couple of years ago were around $800 million - despite VMS'sH position at that time as a platform sold only grudgingly by its parent -J suggests fairly strongly that there was a significant opportunity to boostB VMS profits well into the $billions with *any* reasonable level ofG encouragement, which makes the continuing Alpha development expendituresK pretty easy to justify on the basis of VMS alone, let alone Tru64 and Linux K activity (about which I have no past profit figures nor as clear an idea ofi relative future potential).r   >  >p > 6 > Ex: Memory bandwidth on "Billybox" IA64 servers (tryF > testdrive.compaq.com's Linux64 Blazer box with some basic C code) is5 > higher than on a EV67 ES40 with ideal interleave...a8 > That's a gen-1 product, with immature GNU compilers...  C I'm no hardware engineer, so could you explain what impact compiler H technology has on memory bandwidth?  And what aspects of the IA64 memoryJ architecture aren't equally applicable to Alpha technology (since it's the= differences in core processor under discussion here more thanu) current-product board-level integration)?l  
  SpecFP isB > on par with EV68 for this inferior chip... (DS20E EV68 833: 784, > Itanium: 701)p > C > Given these facts, I find it a bit early to write it off as nevert> > being able to match Alpha perfomance, EV8 with its SMT gloryB > hasn't exactly taped out either (re: post-McKinley designs being > complete vapourware)?   J You've missed the context again, I'm afraid.  The 'not-even-yet-vaporware'A in question is some hypothetical super-chip that integrates AlphahL architecture features (not simply minor hooks) with IA64:  AFAICT, this chipK exists solely in Kerry's imagination, but he talks about it as it it were ae
 done deal.  L As for the details of why one might expect Alpha to maintain its performanceH leadership, I suggest you read the material at realworldtech.com and theJ 1999 Alpha paper referred to elsewhere (assuming that Compaq hasn't yankedJ that paper as politically incorrect).  Unless you're already familiar withG that material, in which case explaining its mistakes for the rest of use would be enlightening.   >u >oD > I honestly believe that Terry Shannons account of an analysis that< > says Alpha (given the difference in R/D spending between aB > bean-counter-dense Compaq and Intel, and fab latency) would haveA > lost its performance edge right after McKinley _might_ be true.o( > (ref: his SKC posting on Compaqs site)  L I've lost some confidence in the level of Terry's objectivity since he beganJ hob-nobbing in earnest with Compaq executives over the past year, and evenD without that Terry AFAIK is no hardware engineer.  But I'd welcome aD detailed explanation from him as well (or anyone else) about why theG analysis at realworldtech and the not-so-old Alpha papers is incorrect.'   >n >o? > With all the EV7 tapeout delays (noting that EV7 is "just" anmE > optimized EV6 core at heart with no radical technology steps taken)vD > perhaps the analysis is correct, and perhaps it wasn't done solelyH > by evil marketoid droids with an intrinsic wish to kill Alpha, perhaps; > (Gasp!) actual DECpaq chip designers were involved... :-)   H Then again, if it really was such a cookbook upgrade, one is inclined atK least to question why it has been so drawn-out if not because of deliberaten strangulation from above.t   >  >  >dA > Furthermore I'd bet that unless there is _delibarate_ poisoningk= > of the required BIOS/console interfaces to prevent VMS from ? > running on non-Compaq IA64 designs the boxes in question willc@ > be quite cheap, which in theory should even please some of the/ > "Affordable VMS systems NOW!!!!" crowd... :-)   J Except that it's not available NOW, or anything like NOW.  And if VMS diesI or is killed within the next couple of years, it won't be available THEN,- either.-  C And you still haven't explained how a significantly larger and moreCC power-hungry chip is going to be significantly cheaper than Alpha -lG especially given Intel's expressed desire to develop it to get into theh higher-margin product space.  I Since the balance of your post seems pretty much "Don't worry - be happy"e$ optimism, I'll stop responding here.   - bill   ------------------------------  # Date: Thu, 28 Jun 2001 04:07:26 GMTv4 From: "Terry C. Shannon" <terryshannon@mediaone.net>Y Subject: Re: Question to Charlie Matco - reply to Terry Shannon (and some general commentu; Message-ID: <24y_6.1162$UT1.376368@typhoon.ne.mediaone.net>   K "Magnus M" <mmad@tips.se> wrote in message news:3B39F4BD.5020906@tips.se...a >b > D > I honestly believe that Terry Shannons account of an analysis that< > says Alpha (given the difference in R/D spending between aB > bean-counter-dense Compaq and Intel, and fab latency) would haveA > lost its performance edge right after McKinley _might_ be true.5( > (ref: his SKC posting on Compaqs site)  K What it came down to (according to several senior hardware developer types)sB is that EV8 might well beat a then-incumbent Itanium, but not by aH sufficient margin to use as a "competitive differentiator." EV9 and EV10D were said to be in advanced development, but I suspect that any EV10E advanced development conducted to date was conducted on the back of a  restaurant placemat.  D In any event, EV8 was designed for a fabric-based post-Marvel systemK architecture that has yet to be completely defined. (Mister Fenwick's Third G Opus is still being written). With EV8 itself nowhere near being a donegK deal, and with FIRE and ICE being little more than smoke and mirrors from ahG system design standpoint, proceeding full speed ahead with Marvel and a G couple of generations of EV7 chips, then transitioning over to an IA-64 I based post-Marvel architecture seemed to be the most prudent thing to do.   J Whether or not this is the case won't be known for several years. EV7 PassG One silicon is booting Right About Now, prototype Marvel dual-processoroG modules have been sighted in the MR0 labs, but revenue shipments of EV7 B Marvel systems won't begin until late next year or early 2003 (theE telco-specific Raptor box might show up a bit sooner), and EV79 won't-F materialize until 2004. Which gives CPQ and INTC some breathing space.  J As for the viability of the architectural transition, a chat I had a whileH back with an Intel IA-64 developer who had some passing familiarity withH things Alpha (and PRISM and VAX Vector Architecture)-related leads me to believe it can work.   ------------------------------  % Date: Wed, 27 Jun 2001 15:31:05 -0400o2 From: rdeininger@mindspring.com (Robert Deininger)Y Subject: Re: Question to Charlie Matco - reply to Terry Shannon (and somegeneral commentspL Message-ID: <rdeininger-2706011531050001@user-2ivebp7.dialup.mindspring.com>  
 In articleA <OF8BB15099.76A624F6-ON03256A78.0056184B@ep-bc.petrobras.com.br>, * fabio_compaq@ep-bc.petrobras.com.br wrote:   > Like to have for example:p  t  E > c) A tool / compiler to develop OpenVMS Device Drivers more easily.   I What do you find so hard about VMS device drivers?  This is an inherentlypJ complex problem.  You have to interact with the innards of the OS, and the quirks of a hardware widget.  C Digital provided the tools (C compiler and extensive driver support0F routines and macros) the documentation (VMS manual set and the DigitalG Press book "Writing OpenVMS Alpha Device Drivers in C") and examples ofID working drivers.  They've also provided extensive debugging support.  F You have to understand your device.  I don't see any "tool" that could solve that for you.r  5 Then you have to follow the clearly documented rules.'   What's missing.i  I If there are fewer folks able to write drivers these days, I suspect it'sI= because there are fewer good programmers than in olden days. eJ Script-kiddies probably can't write decent device drivers on any platform.  E If you have ideas to make this complex task easier, I'm interested ine
 hearing them.b   --   Robert Deininger rdeininger@mindspring.comr   ------------------------------  # Date: Wed, 27 Jun 2001 19:32:04 GMTs2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: RE: Rdb troll1 Message-ID: <Uwq_6.208$rc5.5575@news.cpqcorp.net>    In article <DD11CB6FEB21D41184510004ACA3715304C906C8@mbsus228.mbc.com>, "Hipenbecker, Doug" <Hipenbecker.Doug@MBCO.COM> writes:oL :I think the Compaq "Bliss on Windows" stance raises a valid suspicion aboutI :Compaq's true intentions with OpenVMS.  I don't believe Compaq seriouslyn :intends to port OpenVMS...   H   Well, we've work with the ISVs starting up, extensive direct customer I   contacts now underway, and a large engineering effort starting up.  TheoH   new VP of OpenVMS has appointed the key members of his technical team D   -- the base OS techical architect and the application development B   technical architect -- in place.  Various OpenVMS engineers are D   presently researching IPF technical details in preparation for theG   port, with more research starting up daily.  Research related to the cJ   LPs and the expected and associated porting effort is now also underway.  K :Oracle could care less as most Oracle RDB customers will migrate to Oracle J :RDBMS.  However, the same cannot be said about keeping the hardware brand" :Compaq for the database platform.  F   Oracle Rdb is something used within OpenVMS Engineering -- it is theH   basis of the OpenVMS source code control system, among its other uses.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 27 Jun 2001 19:58:34 GMT& From: lee.webb@colossus.com (Lee Webb) Subject: Read other user's mailf2 Message-ID: <slrn9jkeng.1q3.lee.webb@colossus.com>  ' Disclaimer: I'm not too hot with VMS...t  A I have a situation whereby a non-interactive account's mailbox is C accumulating mail and needs deleting. However, the user in questione" cannot simply login and type MAIL.  K Thus, I was wondering if there is a way of safely accessing (and modifying)aD this user's mailbox using the SYSTEM account. I've looked into a VMSD equivalent of UNIX su, but that requires a third-party product and I. would prefer a VMS method as it is a live box.  0 So, is there any standard VMS way of doing this?   Thanks,n Lee.   ------------------------------   Date: 27 Jun 2001 21:58:34 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)# Subject: Re: Read other user's mailr, Message-ID: <9hdkua$bku@gap.cco.caltech.edu>  [ In article <slrn9jkeng.1q3.lee.webb@colossus.com>, lee.webb@colossus.com (Lee Webb) writes:t( >Disclaimer: I'm not too hot with VMS... >eB >I have a situation whereby a non-interactive account's mailbox isD >accumulating mail and needs deleting. However, the user in question# >cannot simply login and type MAIL.- >-L >Thus, I was wondering if there is a way of safely accessing (and modifying)E >this user's mailbox using the SYSTEM account. I've looked into a VMStE >equivalent of UNIX su, but that requires a third-party product and In/ >would prefer a VMS method as it is a live box.r >h1 >So, is there any standard VMS way of doing this?i   Absolutely!   
 $! as SYSTEM.e $ mail, mail> set file disk:[userinquestion]mail.mai   presto, you're in their mail.b   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech aJ **************************************************************************J *                       RIP VMS & ALPHA                                  *J **************************************************************************   ------------------------------  % Date: Thu, 28 Jun 2001 10:27:58 +0930c: From: "Barratt, Chris (FMC)" <Chris.Barratt@fmc.sa.gov.au># Subject: RE: Read other user's mailbN Message-ID: <07103702F27FD411ACA30000F808545257C71F@sagemshs001.fmc.sa.gov.au>  G IT might also be worth setting the "FORWARD" for that user, so that allm= future mail gets redirected to somewhere that it can be read.e   Cheers,  Chrish   > -----Original Message-----% > From: mathog@seqaxp.bio.caltech.edu ( > [mailto:mathog@seqaxp.bio.caltech.edu]# > Sent: Thursday, 28 June 2001 7:29  > To: Info-VAX@Mvb.Saic.Come% > Subject: Re: Read other user's maila >  > 5 > In article <slrn9jkeng.1q3.lee.webb@colossus.com>, g* > lee.webb@colossus.com (Lee Webb) writes:* > >Disclaimer: I'm not too hot with VMS... > >yD > >I have a situation whereby a non-interactive account's mailbox isF > >accumulating mail and needs deleting. However, the user in question% > >cannot simply login and type MAIL.a > >l? > >Thus, I was wondering if there is a way of safely accessing   > (and modifying)fG > >this user's mailbox using the SYSTEM account. I've looked into a VMS G > >equivalent of UNIX su, but that requires a third-party product and Ir1 > >would prefer a VMS method as it is a live box.  > >n3 > >So, is there any standard VMS way of doing this?e > 
 > Absolutely!u >  > $! as SYSTEM.  > $ mail. > mail> set file disk:[userinquestion]mail.mai >  > presto, you're in their mail.- > 
 > Regards, >  > David Mathog > mathog@caltech.eduA > Manager, sequence analysis facility, biology division, Caltech a@ > ************************************************************** > ************@ > *                       RIP VMS & ALPHA                        >            *@ > ************************************************************** > ************ >    ------------------------------  % Date: Wed, 27 Jun 2001 23:37:29 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)# Subject: Re: Read other user's mail)L Message-ID: <rdeininger-2706012337300001@user-2ivecak.dialup.mindspring.com>  P In article <slrn9jkeng.1q3.lee.webb@colossus.com>, leewebb@btinternet.com wrote:  ) > Disclaimer: I'm not too hot with VMS...u > C > I have a situation whereby a non-interactive account's mailbox isoE > accumulating mail and needs deleting. However, the user in questione$ > cannot simply login and type MAIL. > M > Thus, I was wondering if there is a way of safely accessing (and modifying)rF > this user's mailbox using the SYSTEM account. I've looked into a VMSF > equivalent of UNIX su, but that requires a third-party product and I0 > would prefer a VMS method as it is a live box. > 2 > So, is there any standard VMS way of doing this?  H In addition to the other replies, note that you can set a flag on a userI via AUTHORIZE that blocks delivery of mail.  I think the flag is DISMAIL,tE but HELP will give you a more reliable answer than does the top of mya head.y   -- e Robert Deininger rdeininger@mindspring.coma   ------------------------------  % Date: Thu, 28 Jun 2001 00:07:11 +0200p) From: Christof Brass <brass@infopuls.com>pY Subject: Re: Reward for the first of the next 50 posts: which company	shouldbuy VMS VMSVMe, Message-ID: <3B3A590F.43D631FF@infopuls.com>   Christopher Smith wrote: >  > > -----Original Message-----4 > > From: Christof Brass [mailto:brass@infopuls.com] > ? > > To be able to run VMS on affordable and easily available HWnD > > would be the only positive point I see in the Intel-Compaq deal.C > > But as some other posters pointed out Compaq will find a way topD > > screw this up. And Compaq has to find a way because it otherwiseB > > may threaten Micro$hit. At least they can increase the licenceC > > fees. There are multiple ways to kill VMS' market opportunitiesa= > > to protect Micro$hit. As long as VMS is part of Compaq or D > > another similar company there will be problems in increasing the > > VMS market share.t > L > I worried about that some, but I'm not sure it's warranted.  Yes, Compaq'sM > been more than incompetent in the past, but if they were consciously trying N > to protect microshaft, would they take a chance on even announcing a port to > the Unshippable Itanic?s  > They were pretty competent in protecting Micro$hit by limiting> VMS' opportunities. As other posters pointed out it seems that= the CEO of compaq is a proxy for Micro$hit and Untel. And theV@ people at Compaq will know how to prevent beeing able to run VMS/ on not Compaq boxes. I'm sure of that at least.s  p
 > Regards, >  > Chrisg > # > Christopher Smith, Perl Developerg > Amdocs - Champaign, IL >  > /usr/bin/perl -e 'A > print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");f > 'o   ------------------------------  # Date: Wed, 27 Jun 2001 18:50:56 GMTt& From: "Rich B." <richb500@hotmail.com>* Subject: Re: ROSS GemBase on OpenVMS Alpha< Message-ID: <kWp_6.117635$v5.8883643@news1.rdc1.ct.home.com>   Syltrem,K   Thanks for your help.  I suspected that it was possible, but I have never6H seen Gembase.  I worked for many years on a VAX, mostly in VAX-BASIC andD then a little in PowerHouse.  I have been programming on the WindowsK platform for the past 7 or so years, but my favorate OS is still VMS.  OvernJ my many years on VMS I came to believe that it is usually possible to callF anything from anywhere on that platform.  This is, of course the exactH opposite that I have come to believe about Windows and Visual Basic <G>.   Rich    ; "Syltrem" <syltrem@videotron.ca.spammenot> wrote in messagen/ news:Ofn_6.40102$TW.201962@tor-nn1.netcom.ca...rK > That was a long shot. Probably not a lot of people are using Gembase. BTWh it > also runs on other platforms.r > J > You can use the CALL statement to call a 3GL external program. They mustH > also declare the routine with EXTERNAL statement in their DML program.K > I have not done it yet so I can't say for sure but from what I coule read J > the 3GL program really should be a function returning a status code as a > longword.h > G > Then you have to build a shared image with your routine in there. ThehI > EXTERNAL statement (mentionned above) indicated the name of this sharedr" > image + the name of the routine. >oJ > That's fairly simple, especially if you are familiar with the concept of > shared images. >r > -- >a	 > Syltremc= > http://pages.infinit.net/syltrem (OpenVMS related web site)a >o >q@ > "Rich B." <richb500@hotmail.com> a crit dans le message news:3 > aDm_6.117336$v5.8869752@news1.rdc1.ct.home.com...eJ > > I have a client running an order application from ROSS Systems.  It isD > > written in GemBase.  We have a need for it to interface with IBM	 MQSeries.A > >(L > > 1) Is it possible for them to call external C functions from GemBase and- > > pass parameters to and from the routines?s > >oH > > 2) If so, what is the GemBase keyword for doing this (I need to know wherem! > > to send them in the docsets?)e > >nH > > 3) They have told me that they do not believe that it is possible to callL > > external routines, but they can invoke DCL commands (some CLI call) thatI > > spawn a subprocess to execute... This would be an OK workaround if we  haveH > > to use it, but with this CLI routine, can you pass parameters and/or	 > commands@ > > qualifiers to the call? They have indicated that you cannot. > >E > > Thank you in advance,e	 > > -Richa > >r > >h > >a > >  > >o >y >e   ------------------------------  % Date: Wed, 27 Jun 2001 16:50:14 -0400o+ From: John Eisenschmidt <jeisensc@aaas.org>i* Subject: Re: ROSS GemBase on OpenVMS Alpha# Message-ID: <sb3a0ed4.030@aaas.org>o  L Pulled a string. I'm told you should call Ross Gembase Support, but here's = the (edited) answer:  G Its in the Gembase guide. They can call any external program ... C or =tD Basic or Cobol or Macro or Bliss or anything ... the internal Ross =B MIS/TIbs/Licensing all use external calls to other programs ...=20  
 Good Luck, =BFfoo?   > >>> "Rich B." <richb500@hotmail.com> 06/27/2001 2:50:56 PM >>> Syltrem,G   Thanks for your help.  I suspected that it was possible, but I have =M nevermH seen Gembase.  I worked for many years on a VAX, mostly in VAX-BASIC andD then a little in PowerHouse.  I have been programming on the WindowsH platform for the past 7 or so years, but my favorate OS is still VMS.  = OverJ my many years on VMS I came to believe that it is usually possible to callF anything from anywhere on that platform.  This is, of course the exactH opposite that I have come to believe about Windows and Visual Basic <G>.   Rich    ; "Syltrem" <syltrem@videotron.ca.spammenot> wrote in messagei/ news:Ofn_6.40102$TW.201962@tor-nn1.netcom.ca...-I > That was a long shot. Probably not a lot of people are using Gembase. =r BTW  it > also runs on other platforms.  >jJ > You can use the CALL statement to call a 3GL external program. They mustH > also declare the routine with EXTERNAL statement in their DML program.H > I have not done it yet so I can't say for sure but from what I coule = readJ > the 3GL program really should be a function returning a status code as a > longword.a >iG > Then you have to build a shared image with your routine in there. The I > EXTERNAL statement (mentionned above) indicated the name of this sharedf" > image + the name of the routine. > J > That's fairly simple, especially if you are familiar with the concept of > shared images. >v > -- >p	 > Syltrema= > http://pages.infinit.net/syltrem (OpenVMS related web site)u >c >tB > "Rich B." <richb500@hotmail.com> a =E9crit dans le message news:3 > aDm_6.117336$v5.8869752@news1.rdc1.ct.home.com...aJ > > I have a client running an order application from ROSS Systems.  It isD > > written in GemBase.  We have a need for it to interface with IBM	 MQSeries.  > >MJ > > 1) Is it possible for them to call external C functions from GemBase = and'- > > pass parameters to and from the routines?8 > >lH > > 2) If so, what is the GemBase keyword for doing this (I need to know wheres! > > to send them in the docsets?)s > >tH > > 3) They have told me that they do not believe that it is possible to callI > > external routines, but they can invoke DCL commands (some CLI call) =t thatI > > spawn a subprocess to execute... This would be an OK workaround if wec haveH > > to use it, but with this CLI routine, can you pass parameters and/or	 > commandt@ > > qualifiers to the call? They have indicated that you cannot. > >, > > Thank you in advance,V	 > > -Richs > >s > >t > >n > >l > >  >t >a   ------------------------------  % Date: Wed, 27 Jun 2001 16:16:35 -0400,+ From: John Eisenschmidt <jeisensc@aaas.org>c Subject: Salt in the Woundsa# Message-ID: <sb3a06ee.021@aaas.org>o  6 There I go, looking at ZDNet again. Will I ever learn?  L http://www.zdnet.com/zdnn/stories/news/0,4586,2780645,00.html?chkpt=3Dzdhpn= ews01   F The Alpha processor proved a costly investment that was increasingly =J difficult to justify, a senior Compaq Computer Corp. executive said this = week.m  G According to Winkler, just to design and develop future generation of =aI Alpha was costing Compaq $300 million a year, he said. "That's no small =  change," he said.5  I In Capellas's memo to employees, he said the computer maker will aim to =4G slash operating expenses another $200 million per quarter. Compaq has =oK already slashed operating expenses this year and announced plans in April =l to lay off 9,000 workers.e   <foo>mK Hello? You paid 9 BILLION DOLLARS for DEC. That's B, as in BILLION. Three =nH years later, you're dumping it because the Alpha division cost you 300 =I Million a year to run? That's like 3 =BD percent. Maybe if you marketed =(L the product you spent all that money buying, you'd have seen a respectable = ROI.  4 Well, thank you Ziff-Davis, that made it all better. </foo>   =BFfoo?e   ------------------------------  % Date: Wed, 27 Jun 2001 21:12:06 -0700v3 From: David Spencer <spencer@spaamfree.recneps.com>eI Subject: SRM Auto_action: what's the difference between BOOT and RESTART?h> Message-ID: <270620012112068860%spencer@spaamfree.recneps.com>  B Trying to forget the Alpha/Itanium crisis and move on with life...  A Can somebody tell me what the difference is and why I should pick.? one over the other? I have a system that doesn't always like toaB auto-reboot after a power failure and I have to wonder if I've got it wrong somehow...e   Thanks,b   -- Dave Spenceri   ------------------------------  # Date: Wed, 27 Jun 2001 19:38:49 GMTa2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)> Subject: Re: Standalone Teco (was Re: VMS on IA64 (technical))1 Message-ID: <dDq_6.210$rc5.5767@news.cpqcorp.net>n  c In article <RX0w8ADYlmWU@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:D  I :Anyone care to guess if TECO will survive?  I understand TECO was VESTedaG :which turned up a lot of bugs in VEST.  That's not exactly the same asb! :having a portable source around.t  F   The initial IPF bootstrap of OpenVMS is expected to be based heavily   on Standalone Teco.   J   But seriously, I would expect to see Teco available on IPF, either from K   the existing nest of assembler code or based on a C version of Teco that eL   is apparently around.  This necessity has been fodder for a regular seriesH   of discussion -- most involving Andy, of course -- at the lunch table.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 27 Jun 2001 16:52:54 -0400c  From: John Santos <JOHN@egh.com>> Subject: Re: Standalone Teco (was Re: VMS on IA64 (technical))6 Message-ID: <1010627165144.38769B-100000@Ives.egh.com>  ( On Wed, 27 Jun 2001, Hoff Hoffman wrote:  e > In article <RX0w8ADYlmWU@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:  > K > :Anyone care to guess if TECO will survive?  I understand TECO was VESTed I > :which turned up a lot of bugs in VEST.  That's not exactly the same as # > :having a portable source around.a > H >   The initial IPF bootstrap of OpenVMS is expected to be based heavily >   on Standalone Teco.  > L >   But seriously, I would expect to see Teco available on IPF, either from M >   the existing nest of assembler code or based on a C version of Teco that iN >   is apparently around.  This necessity has been fodder for a regular seriesJ >   of discussion -- most involving Andy, of course -- at the lunch table.   iHooray!!!!  $$EX$$d   -- a John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 27 Jun 2001 17:01:33 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) > Subject: Re: Standalone Teco (was Re: VMS on IA64 (technical))3 Message-ID: <MCzQyHuRopkL@eisner.encompasserve.org>   Y In article <1010627165144.38769B-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:r* > On Wed, 27 Jun 2001, Hoff Hoffman wrote: > f >> In article <RX0w8ADYlmWU@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes: >> lL >> :Anyone care to guess if TECO will survive?  I understand TECO was VESTedJ >> :which turned up a lot of bugs in VEST.  That's not exactly the same as$ >> :having a portable source around. >> nI >>   The initial IPF bootstrap of OpenVMS is expected to be based heavilyc >>   on Standalone Teco. >> sM >>   But seriously, I would expect to see Teco available on IPF, either from UN >>   the existing nest of assembler code or based on a C version of Teco that O >>   is apparently around.  This necessity has been fodder for a regular series K >>   of discussion -- most involving Andy, of course -- at the lunch table.] >  > iHooray!!!!  $$EX$$i  @ Obviously they must be counting on extra-large IA64 purchases by LJK Software :-)   ------------------------------  % Date: Wed, 27 Jun 2001 16:05:10 -0500*+ From: Christopher Smith <csmith@amdocs.com> > Subject: RE: Standalone Teco (was Re: VMS on IA64 (technical))L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D2004@cmiexch1.cmi.itds.com>   > -----Original Message-----) > From: Kilgallen@eisner.decus.org.nospam   * > On Wed, 27 Jun 2001, Hoff Hoffman wrote:  H >   The initial IPF bootstrap of OpenVMS is expected to be based heavily >   on Standalone Teco.5    	 Ahh, yes.s  6 "To boot VMS from your primary hard drive, simply type ``%&^*$$^%$;'``$$   ) where $$^%$;'``$$ is the ID of your disk.e   ;)   Regards,   Chrisb  ! Christopher Smith, Perl Developer- Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");t 'h   ------------------------------  % Date: Wed, 27 Jun 2001 17:16:14 -0400a+ From: John Eisenschmidt <jeisensc@aaas.org>l> Subject: RE: Standalone Teco (was Re: VMS on IA64 (technical))# Message-ID: <sb3a14ec.025@aaas.org>m   <feature request>.9 my $boot_cmd =3D s/\$\$^%\$;'``\$\$/\$\$^%\$=BF'``\$\$/g;c </feature request>  3 I prefer upside down question marks to semi-colons.s   =BFfoo?i  C >>> Christopher Smith <csmith@amdocs.com> 06/27/2001 5:05:10 PM >>>i > -----Original Message-----, > From: Kilgallen@eisner.decus.org.nospam=20  * > On Wed, 27 Jun 2001, Hoff Hoffman wrote:  H >   The initial IPF bootstrap of OpenVMS is expected to be based heavily >   on Standalone Teco.e    	 Ahh, yes.d  6 "To boot VMS from your primary hard drive, simply type ``%&^*$$^%$;'``$$h  ) where $$^%$;'``$$ is the ID of your disk.    ;)   Regards,   Chrise  ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");n 's   ------------------------------  % Date: Wed, 27 Jun 2001 14:52:04 -0400*/ From: "McCarthy Kevin P." <McCarthyKP@BWSC.ORG> 2 Subject: Re: StorageWorks MSL 5026SL Tape Library: Message-ID: <4C519CCC638BD411A4270000F8CD1D821A5973@NTSV2>  B I agree... we backup our oracle databases from disks on a hsg80 toF locally attached disks on an ultra scsi bus and then backup to tape (aG tz89 on a differential ultra scsi bus (I know it only runs at fast wideiH speed!)) from there.  The system is a as4100 5/533 (ES40 68/833 rsn) andG we get times like 6 minutes for 6.5 GB and 17 minutes for 12 GB.  We dot not use verify.    Kevin McCarthy Boston Water & Sewer Commission    -----Original Message-----/ From: Hamlyn Mootoo [mailto:univms@bigfoot.com]i+ Posted At: Wednesday, June 27, 2001 2:40 PM  Posted To: vms3 Conversation: StorageWorks MSL 5026SL Tape Library 2 Subject: Re: StorageWorks MSL 5026SL Tape Library    0 This suggestion is more in the "other" category:G Buy some big disks (if you don't have them already) and do disk to disksD backups so you can get your batch jobs rolling as soon as possible. A That way you can shove the data to tape at your leisure.  I'm not H familar with MUMPS databases so I don't know if the following suggestionE is applicable, but I would suggest getting as many tape drives as youLG can so you can stream your I/O in parallel as much as possible, cuttingaC down the time to actually get the data off disk (whether primary or- backup disks) onto tape.   HM   "Jay E. Morris" wrote: > H > Ok, looks like we might be going to 2 shifts which means that I've got toF > reduce my nightly backup time.  I've already played all the software tricks@ > (block size, quotas, etc) so I've got to go to a faster drive.	 CurrentlyiA > using a TZ88 that we swap tapes in everyday.  The backup of theo
 productionD > databases take about 3+ hours for about 50GB.  Yes, we run verify. TheseeF > are Mumps databases so we have to take the production software down. BecauserF > of the increased workload we're expecting I think the databases will grow tonC > about 80-100GB.  The TZ88 ain't gonna cut it.  There's bunches ofe batchnG > processing that has to occur after backup and before 1st shift.  Rest  of the> > backup can take all day far as I'm concerned, as long as the
 production > system is back up in time. > 
 > I'm runing: . > AlphaServer 2100 (no, I didn't forget the A). > AlphaServer 1000 (no, I didn't forget the A) > RA3000 > OpenVMS 7.2-1 (7.3 rsn) D > The Alphas have the QLogic ISP1020 SCSI which are connected to the RA3000.t" > I have KZPBA-CX cards available. > F > So I'm thinking about using the StorageWorks MSL 5026SL Tape Library with 1C > drive (mainly because of the throughput but size counts).  So I'mr lookingp > for: > & > Good/bad experience with this thing.H > Is it going to work with this setup (I'm a little confused because the specseF > for the SDLT drive itself shows the KZPBA but the library only shows5 > 3X-KZPEA-DB and this won't work in the 1000/2100*.)P > Other backup suggestions.a > C > *but if the drive itself works with the KZPBA then I may still beh
 stuck with: > changing tapes.  Or use it as an excuse for a new Alpha. >  > Jay E. Morris0. > System Software Specialist (Sys/Net Manager) > General Dynamics, WTSS# > Lead, Medical Information SystemsD: > Epidemiological Surveillance Division (AFIERA/SDE (MIS)) > Brooks AFB, TX   ------------------------------  % Date: Wed, 27 Jun 2001 14:55:34 -0700e! From: Eric <etailor@jpl.nasa.gov>,: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B3A5656.CC4C0048@jpl.nasa.gov>  ; I used to be a vms kernel hacker. I still have 10 copies ofe< that book that says "Vax, Architecture for the '80s".  I was4 one of maybe 20 people who knew about special kernel? mode ast's. I sold a few million dollars worth of software thatb did these and other tricks.a  4 I pronounced DEC (and COMPAQ) alpha dead long ago!!!   Here is why:  8 Consider the vax without pdp-11 emulation when they went to the vax.w  7 Consider the mac without 68000 emulation when they wenta- to the power pc. (btw, fabulous job they did)   @ Consider the alphas without vax emulation when they.... wooopsss  > That was the killer. And did it ever piss me off. I could have' written an emulator myself in 3 months.y  7 Even Gordon Bell had been quoted as saying "Since everyhE vax program will run seemlessly on the alpha, they did it right". But B he was lied to. All those stupid migration tools that didn't work.  = Anyway, I only got here because my friend sent a message herenA about our move to linux. I now hack linux kernels, and I don't go. blind reading micro-fiche.   Regards to all you guys.  ) Eric (formally of  bear computer systems)r    @ BTW, did Ralph Stammerjohn ever move from rsx to vms? I remember% all those great decus magic sessions.r   ------------------------------  % Date: Wed, 27 Jun 2001 20:01:28 -04005' From: "Bill Todd" <billtodd@foo.mv.com>a: Subject: Re: The death of VMS has been greatly exaggerated( Message-ID: <9hdrua$353$1@pyrite.mv.net>  0 "John Vottero" <John@mvpsi.com> wrote in message) news:tjk1j99u64spe1@news.supernews.com...a@ > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message( > news:MFVbm5gV2I4b@malvm5.mala.bc.ca...3 > > In article <tji3n47ge8e60b@news.supernews.com>,h/ > >     "John Vottero" <John@mvpsi.com> writes:  > > >eE > > > 32 bit processors are a dead end for general purpose computing.  > >eE > >     Which problem in particular do you see 32bit processors being @ > > inadequate for? Will those problems need to be solved by the$ > > average desktop system customer? > >C >rI > It's not that all (or even many) problems need more than 32 bits.  It'sa thatL > most computers are used to do more than one thing.  A 32 bit chip can only > address 4GB of RAM.   K Tell that to Intel and its Xeons (32-bit machines supporting up to 64 GB of:K RAM).  It's like telling people a 16-bit PDP-11 could only address 64 KB of  RAM (IIRC 4 MB was the limit).   -bill3  4   Every day another pointy haired boss says "Tell meL > again why I can't put more than 4GB of RAM in the server.", "Can't we just$ > by machine with more DIMM slots?". >nJ > In a few years, we'll all be wondering how we ever got by with less than > 64GB of RAM. >I >I >L   ------------------------------  # Date: Thu, 28 Jun 2001 03:01:32 GMTB. From: "Alphaman" <alphaman64@nixspam-home.com>: Subject: Re: The death of VMS has been greatly exaggerated; Message-ID: <g6x_6.12912$P5.4505808@news1.rdc1.tn.home.com>n  8 Bob Koehler <koehler@encompasserve.org> wrote in message- news:koBxgZHscqX4@eisner.encompasserve.org...b7 > In article <3B390D63.35E0165B@videotron.ca>, JF Mezeir& <jfmezei.spamnot@videotron.ca> writes: > K > > 1-VMS is not a strategic product. It is there only because it generatest > > profitsi >fJ > I'm sure we all would run out own businesses our own way, but in my book- > "generates profits" IS a startegic product.   L Uhm, like Alpha generates profits, even when poorly marketed?  No matter howL bad things got at the Q, no matter how slim PeeCee margins slid, I can neverL recall a time when someone claimed that the Alpha was a loss leader, or thatJ profits in Alphas were poor.  I seem to recall just the opposite, in fact,H and that Alpha sales leveraged great things, even when Linux was the OS.   Aaron  --> Aaron Sakovich  http://members.home.net/sakovich/alphaman.html> Make April 15 just another day:        http://www.fairtax.org/K "Oh my God, they killed Alpha!!!  You bastards!" (Anonymous Alpha Engineer)i   ------------------------------  % Date: Wed, 27 Jun 2001 18:08:29 -0700e* From: "Jack Peacock" <peacock@simconv.com>? Subject: Trapping telnet disconnects (no dead Alpha references)i4 Message-ID: <uuv_6.4529$Ib.480407@news1.primary.net>  F I have a situation where users are connecting via telnet over a LAN toG an Alpha VMS 7.2 cluster.  My problem is they are used to PC operationsiF and simply close the emulator window when done, instead of logging outG of the VMS application (non-technical, they think they are running justoH another PC program).  This drops the telnet connection, so VMS kills the process.  D My question is, can I  trap this inside the login script and do some? clean up before the process actually terminates?  Now I know anfH exception handler inside an app can do this, but some apps are 3rd partyH and we can't modify the code.  I would like to be able to trap it in DCLF at the LOGIN script, to run a cleanup program before exiting.  I don't> see any way to do this, as it appears the telnet disconnect isG equivalent to a STOP/PROCESS.  We have tried procedural changes but notl? everyone remembers to log out, and operator turnover makes it aC recurring problem.    Jack Peacockn   ------------------------------   Date: 27 Jun 2001 22:59:38 GMT' From: prosullivan@aol.com (PROSULLIVAN)v3 Subject: Re: Upgrade to 7.3 migrating CA Ingres 6.4 : Message-ID: <20010627185938.03116.00001059@ng-xa1.aol.com>  M nearest  i've done is 7.2 on 6.4 - ca probably haven't tested it as 6.4 dropsnJ out of support soon - this means - evil grin - special CA support pricing.   ------------------------------  % Date: Thu, 28 Jun 2001 11:58:08 +08000 From: "mark" <mark@olc.com.au> Subject: vax 4000/905 Message-ID: <BTx_6.49$807.11519@nsw.nnrp.telstra.net>a  	 Hi there,f  J I am chasing a VAX 4000/90 with tape drive preferably, I thought that this was a good place to ask.  K If you think that you can help and you are in Australia please let me know.0   Thanks   ------------------------------  + Date: Wed, 27 Jun 2001 17:56:38 +0000 (UTC) ' From: david20@alpha2.mdx.ac.uk (D.Webb)lE Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)C+ Message-ID: <9hd6om$a8t$1@aquila.mdx.ac.uk>s   In article <BE56C50EA024184DAF48F0B9A47F5CF48DBF01@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@compaq.com> writes: >JF, >nL >>> No, Compaq is completing development of Alpha, irrespective of when IA64L >will be ready. So if IA64 is delayed by a few years, Compaq won't be adding' >a new version of alpha to keep up. <<<h >mI >How do you know this? I am certain no one on this list from Compaq couldD >answer that question. >eI >HP extended and bumped up PA because IA64 was late. Why could not Compaqu >extend EV7 in the same manner?i >p  ? Possibly because they no longer have the engineers / designers.h    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Wed, 27 Jun 2001 16:44:25 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca>oE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)o, Message-ID: <3B3A45A8.5F643E71@videotron.ca>   "Main, Kerry" wrote:J > HP extended and bumped up PA because IA64 was late. Why could not Compaq  > extend EV7 in the same manner?  L Didn't Compaq announce that as soon as EV7 work is done, the remaining AlphaM engineers will be switched to Intel ? Pretty hard to produce a new version ofMN your chip when you no longer have the staff or infrastructure to do that work.   ------------------------------  % Date: Wed, 27 Jun 2001 19:04:28 -0400 + From: "Main, Kerry" <Kerry.Main@compaq.com>sE Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)pR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7EC0@kaoexc01.americas.cpqcorp.net>  J >>> Didn't Compaq announce that as soon as EV7 work is done, the remaining Alpha J engineers will be switched to Intel ? Pretty hard to produce a new version ofH your chip when you no longer have the staff or infrastructure to do that work.<<<  % Define "as soon as EV7 work is done."i  L Are you plugged into some source that I do not know about which specifies an$ exact date as to when this is done ?  K Even if the IA64-2 was late, would it not make sense to offer an EV7+ speed-I bump in the exact same manner as what HP did with their PA architecture ?o   Regards   
 Kerry Main Senior Consultantr Compaq Canada Inc. Professional Services- Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] Sent: June 27, 2001 4:44 PM> To: Info-VAX@Mvb.Saic.ComeE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)-     "Main, Kerry" wrote:J > HP extended and bumped up PA because IA64 was late. Why could not Compaq  > extend EV7 in the same manner?  L Didn't Compaq announce that as soon as EV7 work is done, the remaining AlphaJ engineers will be switched to Intel ? Pretty hard to produce a new version ofH your chip when you no longer have the staff or infrastructure to do that work.h   ------------------------------  % Date: Wed, 27 Jun 2001 19:08:35 -0400S+ From: "Main, Kerry" <Kerry.Main@compaq.com>uE Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)nR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF48DBF0C@kaoexc01.americas.cpqcorp.net>  F >>> Possibly because they no longer have the engineers / designers.<<<  H The EV68+, EV7 teams have not gone to Intel. They are not slated to move" over until all their work is done.  I If IA64-2 were delayed, the EV7 work could be considered to be incompelte- and a speed bump planned.:   Regardsr    
 Kerry Main Senior Consultanta Compaq Canada Inc. Professional Servicesn Voice: 613-592-4660n Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----@ From: david20@alpha2.mdx.ac.uk [mailto:david20@alpha2.mdx.ac.uk] Sent: June 27, 2001 1:57 PM7 To: Info-VAX@Mvb.Saic.ComtE Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)e    
 In articleG <BE56C50EA024184DAF48F0B9A47F5CF48DBF01@kaoexc01.americas.cpqcorp.net>,v- "Main, Kerry" <Kerry.Main@compaq.com> writes:n >JF, >oL >>> No, Compaq is completing development of Alpha, irrespective of when IA64L >will be ready. So if IA64 is delayed by a few years, Compaq won't be adding' >a new version of alpha to keep up. <<<  >sI >How do you know this? I am certain no one on this list from Compaq couldr >answer that question. >tI >HP extended and bumped up PA because IA64 was late. Why could not Compaqy >extend EV7 in the same manner?  >d  ? Possibly because they no longer have the engineers / designers.,    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Wed, 27 Jun 2001 19:49:23 -0400:' From: "Bill Todd" <billtodd@foo.mv.com>aE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)m( Message-ID: <9hdr7n$2km$1@pyrite.mv.net>  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF48DBF0C@kaoexc01.americas.cpqcorp.net... >-H > >>> Possibly because they no longer have the engineers / designers.<<< > J > The EV68+, EV7 teams have not gone to Intel. They are not slated to move$ > over until all their work is done. > K > If IA64-2 were delayed, the EV7 work could be considered to be incompelte& > and a speed bump planned.;  B This bullshit is getting tiresome:  either point to some reference: describing details about this IA64-2, or shut up about it.   - bill   >r	 > Regards\ >\ >" > Kerry Main > Senior Consultant! > Compaq Canada Inc. > Professional Services  > Voice: 613-592-46601 > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  % Date: Wed, 27 Jun 2001 23:47:11 -0400g+ From: "Main, Kerry" <Kerry.Main@compaq.com>qE Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)eR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7EC2@kaoexc01.americas.cpqcorp.net>  F >>> This bullshit is getting tiresome:  either point to some reference= describing details about this IA64-2, or shut up about it.<<<n  L Thats what I like so much about you Bill.. such great etiquette when someone disagrees with you.   ( A real example of an adult conversation.   :-) :-)   I The reference to IA64-2 is simply to reflect the fact that OpenVMS, Tru64&K and NSK are not slated to be ported and run on todays intial release of the,A IA64 platform, but rather a followon version of the architecture.n  J As stated numerous times in the releases, todays IA64 technologies will beI integrated and upgraded with Alpha technologies to allow these OS's to be0 ported.0  1 Would you prefer something else like IA64.next ??O   Regards,  
 Kerry Main Senior Consultanta Compaq Canada Inc. Professional Services2 Voice: 613-592-4660T Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----, From: Bill Todd [mailto:billtodd@foo.mv.com] Sent: June 27, 2001 7:49 PMi To: Info-VAX@Mvb.Saic.ComIE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)       6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF48DBF0C@kaoexc01.americas.cpqcorp.net... >yH > >>> Possibly because they no longer have the engineers / designers.<<< >nJ > The EV68+, EV7 teams have not gone to Intel. They are not slated to move$ > over until all their work is done. >rK > If IA64-2 were delayed, the EV7 work could be considered to be incompeltee > and a speed bump planned.   B This bullshit is getting tiresome:  either point to some reference: describing details about this IA64-2, or shut up about it.   - bill   >s	 > Regards  >n >  > Kerry Main > Senior Consultantt > Compaq Canada Inc. > Professional Servicesi > Voice: 613-592-4660s > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  % Date: Thu, 28 Jun 2001 00:19:26 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>eE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)i+ Message-ID: <3B3AB045.A74BAB4@videotron.ca>J   "Main, Kerry" wrote:K > The reference to IA64-2 is simply to reflect the fact that OpenVMS, Tru64oM > and NSK are not slated to be ported and run on todays intial release of thesC > IA64 platform, but rather a followon version of the architecture.u  N When will we know exactly what features of IA64 are currently missing to allow VMS to run on IA64 ?    L > As stated numerous times in the releases, todays IA64 technologies will beK > integrated and upgraded with Alpha technologies to allow these OS's to bee	 > ported.a  C By your logic, EV7 would have been a MIPS/Alpha Hybrid because MipsBM technologies that allow Tandem to run will/would have been merged with Alpha.   N Just because you integrate some concepts and functions of another chip doesn't1 mean that you implement that chip into your chip.c  K Is Alpha a VAX-Alpha because they included in Alpha some functionality that . was present in VAX to allow VMS to run on it ?  I Similarly, I do not see wht IA64 will magically become an Alpha-IA64 justvM because IA64 might be modified to include some functions to allow VMS to bootC on it.  M Also consider that Intel already has access to much of the Alpha intellectualbN property. I doubt very much that the Alpha chip will have any impact on IA64. F The Alpha engineers may find themselves stuck trying to improve IA64'sM performance, but they will be at a disadvantage because they were trained ando[ spent much time working on a chip that had a totally different philosophy for optimisation.n   ------------------------------  % Date: Thu, 28 Jun 2001 01:07:48 -0400h' From: "Bill Todd" <billtodd@foo.mv.com>IE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)o( Message-ID: <9hedsr$hai$1@pyrite.mv.net>  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4AD7EC2@kaoexc01.americas.cpqcorp.net...H > >>> This bullshit is getting tiresome:  either point to some reference? > describing details about this IA64-2, or shut up about it.<<<t >oF > Thats what I like so much about you Bill.. such great etiquette when someones > disagrees with you.0  @ It's the bullshit I find offensive, not the disagreement per se.   >i* > A real example of an adult conversation.  K At least it's to the point, something which otherwise is often difficult to  reach when talking with you.   >l	 > :-) :-)o >oK > The reference to IA64-2 is simply to reflect the fact that OpenVMS, Tru64lI > and NSK are not slated to be ported and run on todays intial release ofl the C > IA64 platform, but rather a followon version of the architecture.i  L I'm glad you've clarified that IA64-2 simply refers to the first instance ofK the IA64 architecture on which VMS (and perhaps Tru64 and NSK as well) will.) run, rather than anything more ambitious.   I I suspect the industry already knows that IA64 archtecture member by someaC other name, however, so it might be better to use that one to avoid J confusion (see below).  Unless, of course, the member is so distant in theD future that no industry-known name yet exists for it - in which caseJ speaking of it with such specificity is a bit misleading (as is suggestingK any particular time-frame in which it might actually appear so that VMS cany run on it).p   >sL > As stated numerous times in the releases, todays IA64 technologies will beK > integrated and upgraded with Alpha technologies to allow these OS's to be 	 > ported.2 >u3 > Would you prefer something else like IA64.next ??o  L It has nothing to do with what I'd prefer:  the world *is* going to get IA64J next (in McKinley), and again after that, and most likely again after thatH (I don't track that architectural roadmap at that level of detail).  AndI unless VMS is willing to wait the 4 or 5 years *minimum* it would take tolL make any significant changes to that roadmap and the architecture in it (notI that I think that such changes are at all likely to occur, especially now G that Alpha has been removed from the array of IA64 competitors), VMS ispI going to run on IA64, period, not some "new combined Alpha/IA64 platform"e> (to use your words of Tuesday, June 26, 2001  11:43 P.M. EDT).  F You see, this is what I found confusing:  I thought your use of IA64-2G referred to this mythical super-chip, one that actually merges in Alpha G architectural elements of some significance.(not just minimal hooks fortI VMS).  In scanning through c.o.v. I find less explicit references to thisiI than I remembered:  my impression that this is the kind of beastie you've L often been referring to must have been strengthened by content in an earlierE private communication, which I'd be happy to quote from if you'd likeC
 specifics.  J As long as you're now happy to limit your use of 'IA64-2' to whatever IA64I architecture member first runs VMS, and refrain from intimating that this-I member will be anything *but* IA64-like in nature plus possibly a hook orAF three that VMS may require to run at all, I'll refrain from calling it	 bullshit.t  @ But if you should get a bit carried away and start talking aboutL 'Alpha/IA64' again or anything like that, without being able to point out anK Intel document specifying what Alpha architectural characteristics would betJ included in such a beast and some suggestion of when it might appear, I'll) repeat my breach of etiquette with gusto.b   - bill   >a
 > Regards, >t > Kerry Main > Senior Consultant  > Compaq Canada Inc. > Professional Services  > Voice: 613-592-4660S > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  % Date: Wed, 27 Jun 2001 17:12:44 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>n$ Subject: Re: Wailing and moaning....( Message-ID: <9hdi1u$p65$1@pyrite.mv.net>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:jXGQDvgIhDPW@eisner.encompasserve.org...i   ...e  H > When JF Mezei spoiled DECUServe with total negativity a few years ago,K > eventually he gave up and went away.  Good things come to those who wait..  J Good things indeed - now for Alpha, soon for VMS, and I wouldn't be at allD surprised if some just as good things happened to Compaq as a whole.   - bill   ------------------------------    Date: 27 Jun 2001 20:28:26 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)D  Subject: Wailing and moaning....3 Message-ID: <vMMIL0wpyxh3@eisner.encompasserve.org>t  \ In article <3B3A48F1.E10A5926@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Larry Kilgallen wrote:= >> Are you ignoring the HP EOL notice for PA-RISC processors,SF >> or are you claiming that the HP3000 is HP's primary processor line? >  > O > 1- Will HP's OS run on the first iteration of IA64 which has begun shipping ? 6 > 2- How close to being a product is HP's OS on IA64 ?O > 3- Have HP begun to show their IA64 version to customers for benchmarks etc ?d  F Those questions are irrelevant to the point to which I was responding, which you neatly omitted.k   ------------------------------  % Date: Thu, 28 Jun 2001 00:51:02 +0200a) From: Christof Brass <brass@infopuls.com>d2 Subject: Re: What does Alphas dead means for VMS ?, Message-ID: <3B3A6356.3DEE9974@infopuls.com>   Alan Greig wrote:l > 4 > On Tue, 26 Jun 2001 01:36:43 +0200, Christof Brass > <brass@infopuls.com> wrote:  >  > >cC > >This NSK/Himalaya zick-zack course is a slight proof that nobodyGC > >at Compaq thought about that "solution" earlier. That big change @ > >without much planing ahead doesn't seem to be a good starting	 > >point.a > A > Yes they had thought about it. At least a small team of WInklersH > loyalists had been talking to Intel loyalists in secret for quite someD > time. Or do you think they just came up with the idea last Friday? >  > -- > Alan  @ Why did they spent then that much effort for including lockstep.7 Did the left not know what the right hand planed to do?i   ------------------------------  % Date: Wed, 27 Jun 2001 22:13:07 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>t2 Subject: Re: What does Alphas dead means for VMS ?, Message-ID: <3B3A92B2.977355A9@videotron.ca>   Christof Brass wrote:eB > Why did they spent then that much effort for including lockstep.9 > Did the left not know what the right hand planed to do?i  N Perhaps the NSK-on-Alpha initiative was started by Pfeiffer. Perhaps the goalsG changed when Pfeiffer was ousted and the lower management convinced the"G accountant Capellas to return to a wintel focus only. Just speculation.    ------------------------------  % Date: Wed, 27 Jun 2001 23:45:42 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)2 Subject: Re: What does Alphas dead means for VMS ?L Message-ID: <rdeininger-2706012345420001@user-2ivecak.dialup.mindspring.com>  5 In article <3B3A92B2.977355A9@videotron.ca>, JF MezeiP% <jfmezei.spamnot@videotron.ca> wrote:C   > Christof Brass wrote:sD > > Why did they spent then that much effort for including lockstep.; > > Did the left not know what the right hand planed to do?S > ? > Perhaps the NSK-on-Alpha initiative was started by Pfeiffer. ,  F If not Pfeiffer, then someone at compaq.  NSK-on-IA64 was in the works@ before compaq bought alpha.  That effort will be dusted off now.   -- o Robert Deininger rdeininger@mindspring.com>   ------------------------------  + Date: Wed, 27 Jun 2001 21:52:24 +0000 (UTC)h From: jon@eoin.demon.co.uk* Subject: Which group for VMS hardware ads?0 Message-ID: <9hdkio$pkt$2@INDY.eoin.demon.co.uk>   Hello,  K I'm new here, and don't want to rock the boat, so I'd be grateful if anyoneMI could tell me if there is a suitable/preferred group to post VMS hardwarew for sale ads in.   Thanks in advance.   ------------------------------  # Date: Thu, 28 Jun 2001 03:05:03 GMT@4 From: "Terry C. Shannon" <terryshannon@mediaone.net>. Subject: Re: Which group for VMS hardware ads?; Message-ID: <z9x_6.1079$UT1.330221@typhoon.ne.mediaone.net>.  ' <jon@eoin.demon.co.uk> wrote in messages* news:9hdkio$pkt$2@INDY.eoin.demon.co.uk... > Hello, > F > I'm new here, and don't want to rock the boat, so I'd be grateful if anyoneK > could tell me if there is a suitable/preferred group to post VMS hardwaree > for sale ads in. >r  9 The eBay "Vintage Computer" section might be appropriate.t   ------------------------------   Date: 27 Jun 2001 17:53:04 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)0 Subject: Why Compaq won't succeed on IA64 either, Message-ID: <9hd6i0$1v7@gap.cco.caltech.edu>  E I've had a couple of days to calm down, but I'm still convinced that .J Compaq is nose down, the motors flamed out, and the ground coming up fast.  K They could not make market inroads with the Alpha, which for all but a few jH months of its life was the fastest CPU on the planet.  Among the reasonsH they did not do so were: noncompetitive prices, lack of advertising, andH insufficient software support, most notably, tepid support by Microsoft.H That's not a technical problem, it's a management level problem, and theH management is still there.  If they can't sell the greatest thing since # sliced bread, what can they sell???n  E In the PC space Dell is beating them senseless.  Dell is a much more gH efficient manufacturer and distributor than is Compaq.  There is little J evidence that this disparity will soon be reduced.  The Alpha had nothing J to do with this problem, and ditching Alpha only means that the enterpriseK half of the company will be less able to bail out the PC half for the next a 2 to 3 years.   I In the Unix enterprise space, Tru64 is a distant 4th behind Sun, IBM, andgJ HP. Count in small servers and it's probably 5th, also being behind Linux.G Tru64 used to make headway because it was on the fastest CPU, but thoseh days just went away. s  J Tandem always was a niche product, and through years of abuse, OpenVMS hasG been reduced to the same status.  They are, however, lucrative niches. :K A well managed company might be able to transit those customers to another OK hardware platform before the competition moved in on their markets.  Compaqd is not a well managed company.  B Compaq was doing well in high performance computing.  But that wasB primarily because the Alpha was faster than its competitors.  ThatJ advantage, and the sudden stake through Alpha's heart, guarantee that thatI market MUST shift very soon to some other processor.  That processor needlC not be IA64, and IBM, at least, has very good reason, and very good4D technology, and pretty good marketing, for making sure it is PowerPCI instead.  Don't count the Hammer out either - a lot of the guys who firsthK designed the Alpha now work for AMD. And Sun seems a long shot but it coulde- still pull a surprise rabbit out of the hat. m   So, it's 2004, and...s  H Compaq still can't produce and market machines as efficiently as Dell.  H Their fraction of the PC market is down to 1/2 of what it was in 2001.  ' Constant layoffs, bad morale, etc. etc.   H Compaq's service organization has contracted to less than 1/2 of what itF was when they bought it from Digital - several years of no Alpha basedH sales and falling PC market share having translated into huge numbers ofC lost accounts.  (IBM and Dell will be tearing off big former Compaq8- accounts like a shark eating a dead whale. ) >  I Tru64 never makes it to IA64 because there's no rationale for anybody to hK buy the 6th Unix onto IA64, after AIX, Solaris, HPUX, the BSDs, and Linux. rK If it does get ported, it dies.  Tru64 was worth having for Alpha, but it'suG benefits over AIX on any equivalent platform are nil.  And there's the bK possibility that a working IA64 platform might not ship until 2003 or even iG 2004, in which case all of these Unixes would effectively arrive at the\F same time, which puts the ISVs in the position of having to prioritize> their ports. Guess where Tru64 is going to fall on that list.   J Tandem's products will still be around, and will still be running on MIPs.K They'll still be making money too.  If they move to IA64 sooner or later it G won't really matter, because there's really nothing else that does whateG they do, so they are quite safe in their niche.  Moreover, Tandem salesrI should not be greatly affected as the platform never made it onto Alpha. rJ But the odds of VMS having survived the intervening years of reduced salesK (courtesy of the manner in which this transition was handled) are very low.aI Let's be optimistic and assume that VMS has been ported and Compaq hasn't K axed it. Will Compaq market it aggressively?  Will they price it to competenB against the current Windows?   Will they print so much as a singleK advertisement for it?   If history is any guide, the answer is no to all of I this.  IBM and Sun will absorb the remaining high end VMS market and it's 
 all over.   F And it ain't necessarily so that IA64 will be a winner, in which case K Compaq is the biggest loser of all. Just because everybody is betting on itnF doesn't mean it will turn out to be an adequate processor, or for thatJ matter, a volume processor.  Could be that people get along just fine withE 32 bit desktop machines _forever_, so no mass market for 64 bits evereI develops, and IA64 costs as much as, or even more than, Alpha.  If Intel gK perceives no competition in the 64 bit space, the IA64 is guaranteed to be yJ the most expensive chip ever to grace the planet.  Then there's the IA64'sJ integer performance, which at present is dreadful, and most of the world'sJ computing is integer work.  If IA64 turns out to be a turkey in real worldD applications Microsoft could spin on a dime and move Windows 2003 toG PowerPC or Hammer.  Dell would follow them like a shadow (they are thatdI nimble).  And that would put the remaining enterprise section of the goodgJ ship Compaq on the floor of the ocean faster than you can say "look at all7 the CMGI stock we received in exchange for AltaVista!" n  D Not a rosy scenario.  I am sooooo glad I don't own any Compaq stock.  E And I really dislike, from a strategic prespective, the way they have:K chosen to go up on the trapeze without a net.  The very least they could do ' would be to hedge their bets slightly. e  I But is there any possibility that Compaq could hedge their bet on the VMSnH port? It seems unlikely.  It's bad enough to change horses in midstream,I but Compaq management while at midstream spotted what looked like a horsehH on the far shore, shot the horse it was riding through the head, and setL off to swim across the river while still seated on the dead horse, with the K plan that it would try to capture the thing that might be a horse, and thennK ride that maybe creature away.   All that said, it might be prudent to take E this second VMS porting opportunity to isolate the platform dependenteJ pieces of the OS cleanly and to simultaneously port to PowerPC and Hammer.J They don't need a whole bunch of people working on these other ports, justI one or two guys for each of those other platforms, making sure that everycK nonhardware dependent module that builds for IA64 also builds for the othertI platforms.   Think of it is insurance - you don't really want your familyeI to collect on your life insurance, but you'd be a fool not to pay it.  SooI when 2003 hits, if Microsoft announces that they've just made PowerPC theoH primary platform for Windows and are stopping all further development onJ IA64, Compaq, and more importantly, VMS, stands a chance of surviving it.   	 Regards, c   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                       RIP VMS & ALPHA                                  *J **************************************************************************   ------------------------------  % Date: Wed, 27 Jun 2001 15:19:32 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)4 Subject: Re: Why Compaq won't succeed on IA64 eitherL Message-ID: <rdeininger-2706011519320001@user-2ivebp7.dialup.mindspring.com>  J In article <9hd6i0$1v7@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu wrote:    , > All that said, it might be prudent to takeG > this second VMS porting opportunity to isolate the platform dependent L > pieces of the OS cleanly and to simultaneously port to PowerPC and Hammer.L > They don't need a whole bunch of people working on these other ports, justK > one or two guys for each of those other platforms, making sure that everypM > nonhardware dependent module that builds for IA64 also builds for the othere > platforms.      J I suspect that VMS is getting more portable every time it is ported.  Some+ of what you want will happen automagically.m  G The "couple of guys" scheme has one major flaw, I think.  To build eacheD module on another platform, they'll need compilers targeted to thoseJ platforms.  And a couple of guys can't make those compilers in their spare time without getting caught.  > > Think of it is insurance - you don't really want your familyK > to collect on your life insurance, but you'd be a fool not to pay it.  SosK > when 2003 hits, if Microsoft announces that they've just made PowerPC themJ > primary platform for Windows and are stopping all further development onL > IA64, Compaq, and more importantly, VMS, stands a chance of surviving it.   H I assume you're making the same insurance suggestion to HP and the otherA unix folks who will certainly (according to you) beat Compaq intonI IA64-land?  Compaq's risk at this point isn't much different than several I other companies'.  Compaq might have fired more rounds into their feet to : get here, but they find themselves in a fairly large boat.   -- g Robert Deininger rdeininger@mindspring.comu   ------------------------------  % Date: Wed, 27 Jun 2001 13:33:38 -0600 4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>4 Subject: Re: Why Compaq won't succeed on IA64 either3 Message-ID: <xyq_6.2220$T_2.374135@news.uswest.net>t  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagenF news:rdeininger-2706011519320001@user-2ivebp7.dialup.mindspring.com...L > In article <9hd6i0$1v7@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu > wrote: >s >e@ > > Think of it is insurance - you don't really want your familyI > > to collect on your life insurance, but you'd be a fool not to pay it.i SoI > > when 2003 hits, if Microsoft announces that they've just made PowerPC, the L > > primary platform for Windows and are stopping all further development onI > > IA64, Compaq, and more importantly, VMS, stands a chance of survivinga it.e >sJ > I assume you're making the same insurance suggestion to HP and the otherC > unix folks who will certainly (according to you) beat Compaq intorK > IA64-land?  Compaq's risk at this point isn't much different than severalaK > other companies'.  Compaq might have fired more rounds into their feet toi< > get here, but they find themselves in a fairly large boat. >f  J The difference here is that IBM, HP, et.al won't have killed their primaryL processor/OS lines.  Compaq will be the only one without the life preserver.   > -- > Robert Deininger > rdeininger@mindspring.comt   --
 Mike Ober.   ------------------------------    Date: 27 Jun 2001 15:45:27 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)o4 Subject: Re: Why Compaq won't succeed on IA64 either3 Message-ID: <ZfklwZCFSvc1@eisner.encompasserve.org>   j In article <xyq_6.2220$T_2.374135@news.uswest.net>, "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> writes: > A > "Robert Deininger" <rdeininger@mindspring.com> wrote in messagetH > news:rdeininger-2706011519320001@user-2ivebp7.dialup.mindspring.com...M >> In article <9hd6i0$1v7@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu 	 >> wrote:3 >> >>A >> > Think of it is insurance - you don't really want your family-J >> > to collect on your life insurance, but you'd be a fool not to pay it. > SoJ >> > when 2003 hits, if Microsoft announces that they've just made PowerPC > the1M >> > primary platform for Windows and are stopping all further development on J >> > IA64, Compaq, and more importantly, VMS, stands a chance of surviving > it.J >>K >> I assume you're making the same insurance suggestion to HP and the other D >> unix folks who will certainly (according to you) beat Compaq intoL >> IA64-land?  Compaq's risk at this point isn't much different than severalL >> other companies'.  Compaq might have fired more rounds into their feet to= >> get here, but they find themselves in a fairly large boat.  >> > L > The difference here is that IBM, HP, et.al won't have killed their primaryN > processor/OS lines.  Compaq will be the only one without the life preserver.  : Are you ignoring the HP EOL notice for PA-RISC processors,C or are you claiming that the HP3000 is HP's primary processor line?E   ------------------------------  % Date: Wed, 27 Jun 2001 14:07:58 -0600i4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>4 Subject: Re: Why Compaq won't succeed on IA64 either1 Message-ID: <L2r_6.409$ib.255304@news.uswest.net>H  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:ZfklwZCFSvc1@eisner.encompasserve.org... G > In article <xyq_6.2220$T_2.374135@news.uswest.net>, "Michael D. Ober"t$ <mdo.@.wakeassoc.com.nospam> writes: > >aC > > "Robert Deininger" <rdeininger@mindspring.com> wrote in messageoJ > > news:rdeininger-2706011519320001@user-2ivebp7.dialup.mindspring.com...1 > >> In article <9hd6i0$1v7@gap.cco.caltech.edu>,e mathog@seqaxp.bio.caltech.edu1 > >> wrote:  > >> > >>C > >> > Think of it is insurance - you don't really want your familycL > >> > to collect on your life insurance, but you'd be a fool not to pay it. > > SoL > >> > when 2003 hits, if Microsoft announces that they've just made PowerPC > > thetL > >> > primary platform for Windows and are stopping all further development onL > >> > IA64, Compaq, and more importantly, VMS, stands a chance of surviving > > it.i > >>G > >> I assume you're making the same insurance suggestion to HP and thel otherhF > >> unix folks who will certainly (according to you) beat Compaq intoF > >> IA64-land?  Compaq's risk at this point isn't much different than several-K > >> other companies'.  Compaq might have fired more rounds into their feeti to? > >> get here, but they find themselves in a fairly large boat.s > >> > >3F > > The difference here is that IBM, HP, et.al won't have killed their primary E > > processor/OS lines.  Compaq will be the only one without the lifet
 preserver. >l< > Are you ignoring the HP EOL notice for PA-RISC processors,E > or are you claiming that the HP3000 is HP's primary processor line?t >l  0 HP may find itself in a similar situation, then. --
 Mike Ober.   ------------------------------  % Date: Wed, 27 Jun 2001 16:58:27 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>i4 Subject: Re: Why Compaq won't succeed on IA64 either, Message-ID: <3B3A48F1.E10A5926@videotron.ca>   Larry Kilgallen wrote:< > Are you ignoring the HP EOL notice for PA-RISC processors,E > or are you claiming that the HP3000 is HP's primary processor line?>    M 1- Will HP's OS run on the first iteration of IA64 which has begun shipping ?f4 2- How close to being a product is HP's OS on IA64 ?M 3- Have HP begun to show their IA64 version to customers for benchmarks etc ?t  e  F Once Compaq has gotten a commitment from Intel to incorporate speficicJ features iit IA64 with a timeframe promise and that prmise then gets closeL enough to completion that there is a high degree of confience in the releaseD schedule, only then would it be safe to announce the death of Alpha.  K But killing alpha has nothing to do with Alpha or IA64. It has to do with a L way to quickly raise money so that Compaq can get on with its core business:D services/solutions in which it wants to invest $500 million dollars.   ------------------------------    Date: 27 Jun 2001 17:03:52 -0400/ From: jordan@lisa.gemair.com (Jordan Henderson)-4 Subject: Re: Why Compaq won't succeed on IA64 either* Message-ID: <9hdhno$emr$1@lisa.gemair.com>  3 In article <xyq_6.2220$T_2.374135@news.uswest.net>,e3 Michael D. Ober <mdo.@.wakeassoc.com.nospam> wrote:n >.@ >"Robert Deininger" <rdeininger@mindspring.com> wrote in messageG >news:rdeininger-2706011519320001@user-2ivebp7.dialup.mindspring.com...oM >> In article <9hd6i0$1v7@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edub	 >> wrote:d >> >>A >> > Think of it is insurance - you don't really want your familyoJ >> > to collect on your life insurance, but you'd be a fool not to pay it. >So J >> > when 2003 hits, if Microsoft announces that they've just made PowerPC >theM >> > primary platform for Windows and are stopping all further development onaJ >> > IA64, Compaq, and more importantly, VMS, stands a chance of surviving >it. >>K >> I assume you're making the same insurance suggestion to HP and the other D >> unix folks who will certainly (according to you) beat Compaq intoL >> IA64-land?  Compaq's risk at this point isn't much different than severalL >> other companies'.  Compaq might have fired more rounds into their feet to= >> get here, but they find themselves in a fairly large boat.i >> >.K >The difference here is that IBM, HP, et.al won't have killed their primaryaM >processor/OS lines.  Compaq will be the only one without the life preserver.b >d   Well, maybe IBM, but HP?  4 I saw a better story about this, but note this line:  C   "Hewlett-Packard has already said it will phase out its high-end  0    chip architecture in favor of Itanium chips."   In this story:  3   http://news.cnet.com/news/0-1003-200-6367418.htmld   >> --l >> Robert Deiningerh >> rdeininger@mindspring.com >  >--b >Mike Ober.o >i >u >h   -Jordan Hendersont jordan@greenapple.comn   ------------------------------  % Date: Wed, 27 Jun 2001 17:13:15 -0400P* From: "Andy Stoffel" <acs@fcgnetworks.net>4 Subject: Re: Why Compaq won't succeed on IA64 either9 Message-ID: <d0s_6.102485$Uo3.2331125@news6.giganews.com>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B3A48F1.E10A5926@videotron.ca... > Larry Kilgallen wrote:> > > Are you ignoring the HP EOL notice for PA-RISC processors,G > > or are you claiming that the HP3000 is HP's primary processor line?o >t >cD > 1- Will HP's OS run on the first iteration of IA64 which has begun
 shipping ?6 > 2- How close to being a product is HP's OS on IA64 ?I > 3- Have HP begun to show their IA64 version to customers for benchmarksh etc ?a  H I'm assuming this is all rhetorical since a quick visit to HP's web site> will get you information on IA64 machines they are now selling (As of this month)   See below for an example:g  H http://www.hp.com/products1/unixservers/entrylevel/a/specifications.html  J Of course, this tells us nothing about how many have been delivered yet...     -Andy-   ------------------------------  # Date: Thu, 28 Jun 2001 01:16:25 GMTt, From: "Dale Hammer" <dalehammer@indy.rr.com>4 Subject: Re: Why Compaq won't succeed on IA64 either7 Message-ID: <Jzv_6.26186$eK.3171602@typhoon.neo.rr.com>.  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B3A48F1.E10A5926@videotron.ca... > Larry Kilgallen wrote:> > > Are you ignoring the HP EOL notice for PA-RISC processors,G > > or are you claiming that the HP3000 is HP's primary processor line?d  I HP is shipping the PA-8600 processor now and will be shipping the PA-8700o soon with plansMJ for the PA-8800 and 8900 to follow.  As we are co-designers of the Itanuim Processor FamilyI with Intel, binary compatibility has been designed into the architecture.    >  > D > 1- Will HP's OS run on the first iteration of IA64 which has begun
 shipping ?  L     Yes.  The OS is called HP-UX11i and is shipping now.  The IPF (IA-64) is binary compatiblev:         with the code that runs on the PA-RISC processors.  6 > 2- How close to being a product is HP's OS on IA64 ?  H     Now.   The products are called the RX4610 (1-4 cpu's) and the RX9610 (4-16 cpu's)  I > 3- Have HP begun to show their IA64 version to customers for benchmarkss etc ?T  .     Yes.  Please refer to the spec website at:  =     http://www.specbench.org/osg/cpu2000/results/cfp2000.html            for an example.e   Thanks for your questions.   Dale Hammeri Hewlett Packardm   ------------------------------  % Date: Wed, 27 Jun 2001 22:32:22 -0400y' From: "Bill Todd" <billtodd@foo.mv.com>,4 Subject: Re: Why Compaq won't succeed on IA64 either( Message-ID: <9he4pb$bnl$1@pyrite.mv.net>  ? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in messagel& news:9hd6i0$1v7@gap.cco.caltech.edu...F > I've had a couple of days to calm down, but I'm still convinced thatL > Compaq is nose down, the motors flamed out, and the ground coming up fast.   ...v  3 [And a great deal of other well-thought-out stuff.]n  L Thanks - my fingers were getting tired.  I wouldn't have had the patience toI cover things as thoroughly, nor likely the organization to do so as well.o   - bill   ------------------------------  % Date: Wed, 27 Jun 2001 23:56:01 +0200y) From: Christof Brass <brass@infopuls.com>sY Subject: Re: [OT] IBM Slow and sclerotic?  ( Was Re: Compaq's Alpha design team for sale?e, Message-ID: <3B3A5671.87EB3F68@infopuls.com>   Jordan Henderson wrote:o   [SNIP]  r > How about: > $ >     http://www.realwareawards.com/ > G >     http://www.zdnet.com/pcmag/stories/reviews/0,6755,2713481,00.htmln > > >     http://www.siia.net/events/awards/2001codies/winner.html > 4 >     http://biz.yahoo.com/iw/010502/0101026581.html > 6 >     http://www.linuxworldexpo.com/event-sub-03.shtml  < I don't trust these sources much less than close second hand= experience and detailed explanations (remember the MIT guy?).r  @ > Now, I have to admit that I have no first hand experience with> > Websphere, and I think you'd have to admit that yourself.  I= > just go by what's said in the press on such things, and theaA > above looks pretty impressive.  Hardly worthy of the "worthlessf > piece of shit".m  @ This is the nicest description which is close to be appropriate.= To put it in a different context: selling this is inline with = the type of fraud common with IBM SW products - it's simply a.@ way to get customers on the IBM life support system which is BTW very, very expensive ...  ; > I note that you failed to address _any_ of the other SW Io: > mentioned.  I guess I have to assume that you are taking@ > back the statement "IBM has no useful piece of SW developed by > its own."l  ? On the contrary - as I mentioned I don't want to delve in theseg@ areas also because the examples I picked were perfectly valid to? show that you were writing about things you don't know exactly.t  8 > I would guess that a highly performing, cross platform> > database like DB/2 would be useful to someone.  Or, a really? > good JIT Java compiler might be of some use to a Java user or = > developer.  Then, if you need voice recognition, you've goto8 > two realistic choices now, L&H (ha! would you bet your= > application on software from a bunch of managers in jail onH> > fraud?) or ViaVoice, from IBM.  ViaVoice sounds useful, too.? > A journaling file system might be useful to some Linux users.o  6 DB/2 has some major drawbacks compared to other DBs. I> participated in an evaluate 2 years ago and DB/2 came out flat> as a frog after a tank going over it. Oracle was the winner at the end.  @ Java is crap by design. Do you know the San Francisco Framework? Enough said.  ; > I know that where I work, we are finding a lot of use forr > MQ Series. > ; > Admit it, your statement that "IBM has no useful piece ofq9 > SW developed by its own." is just a ridiculous sweepingt( > statement that you now cannot justify.  = On the contrary I have to re-inforce that and to additionally,9 give the advice to everyone not to buy services from that* company.   [SNIP]  G > This is not an example of SW developed by IBM, true, but it is a good ? > example of a company that is not slow or sclerotic.  A lot of*F > companies buy technology and bury them (MS), or mismanage them (CA), > but IBM has done neither.d  < But this is exactly what sl&scl companies do becaues they're< unable to do it on their own in a timely fashion and with an idea where to go!i7 Think about Micro$hit when they missed the train to thep= Internet. How much money and blackmailing other companies did  they to destroy Netscape?p  D > In your post you accuse IBM of being slow and sclerotic.  Somehow,D > I think this image is at odds with a company that develops some of > the world's finest HW.  1 Again, please read my initial post on that topic.t  G > But, then, I have to admit, I don't understand your post.  See below.,   Different topics!r  A > The Web wasn't that new in the Summer of 1996???  Well, I guessoD > Tim Berners-Lee did have some pages up in 1991.  Seriously though,B > how many times has the Internet doubled in users since then?  OnF > the other hand, the Web was experiencing rapid growth in those days.  ? It was old news in the time of world I live. At that time I hadi? two years of Java applet developing finished and in trains werek7 mobile Internet displays offered. Do you call that new?u  @ > Again, IBM attempted a site that had unprecedented hits at theD > time and experienced some problems.  Sounds like a risk taker, not< > something you would expect from a slow, sclerotic company.  > It seems that you're not at all familiar what really happened.< The completely wrong dimensioned access connections were the5 least problem though the one which was quite visible.   B > Got anything more recent than 5 years ago of how bad the IBM web0 > sites are?  How about a really recent example? >  >   http://www.wimbledon.com/o > G > Seems like a pretty good site to me.  Well laid out, lots of features'H > easy to navigate, fast searches.  Do you have an example of a _better_1 > sports event site?  Why is your example better?g  ? Sorry, I'm not interested in sports other than doing it myself.-  C > Do you remember how deftly IBM got out of networking devices justDB > before the market completely dropped out?  Leaving Cisco and the> > optical companies gasping for air?  Hardly a move by a slow, > sclerotic company.  = Losing a business is a significant symptom for beeing sl&scl.r  ; BTW did you notice that you didn't respond to several of my. facts?  A > IBM is probably the most recognized brand in all of IT.  They'du> > be crazy to change it.  Oh, I know, how about something like% > "Accenture", that'd be more snappy.   : IBM has the smell of fraud, corruption and blackmail. To a@ certain degree it's honest to stay to that by keeping the rotten? name. But OTOH it's a symptom for not understanding what has to @ be done from an economical point of view. And sorry for relating@ a word like "honest" with IBM - this is one of the least fitting association.  C > I have dealt personally with IBM consultants, but I don't want toiB > share these experiences in a public forum.  Leave it to say thatC > I've dealt with much worse, even from other big consulting firms.'   Fair enough.   [SNIP]  G > I was just pointing out how difficult it is for IBM to move fast (and H > I think they do a pretty good job) when you are so large, and you giveH > me a counter example of someone who represents a much smaller company.B > If there's any irony, it's because you want to keep changing the
 > subject.  > No, I didn't. I tried to guide your attention to the fact that@ your qualification of Steve Job's work was beyound any notion of< reality. And BTW Apple has a size which allows for comparing them with IBM.  E > OK.  Now I see!  An organization cannot have a vision.  So when you_B > said that IBM is "visionless" you were just stating a tautology!  
 Narrowminded.i  :C > But wait, now you are saying that almost every other company (allgE > organizations) show more vision than IBM.  How can you show more ofo? > something that you can't have at all by your own definitions.x  = Don't waste your time with that type of arguing. Think about!a< You won't learn anything. It's like arguing about grammar or other language attributes.  B > I have to admit that I don't understand your post, as you accuseB > me of above.  But then, it appears you don't understand what you1 > are saying either, so I can perhaps be excused.e  > Not at all. And as you might have noticed despite your limited> understanding: there are different topics in this conversation> and if you don't understand one part - the one I was referring? to - it means that you didn't understand my post as a whole butC@ that doesn't mean that you could transfer your  problem from one) part to another where it might not exist.o  B > It's really hard to get a definition of "vision" out of you, but@ > I'm getting it bit-by-bit in what you say about it.  You avoidC > the dictionary definition below, you know, where you say it's notmD > "seeing into the future or prophesy".  The dictionary definition IE >  associate with the word vision is "foresight", which is synonomoustC > with being able to see into the future.  Please, tell me, what do- > _you_ mean by vision?u  = This makes me tired. I suppose you know that the meaning of ac> word depends on the context. If a crystal ball analyser speaks? about vision it clearly means something different than if Stevel) Jobs lives it. What is the vision of IBM?   ; > IBM bought Lotus in July of 1995.  By this time, OS/2 had < > been almost completely abandoned in the Enterprise.  Sure,= > they sold a lot of $89.95 boxes in 1994-95 to home and SOHOR? > users, but by late 1995, the companies that had adopted OS/2, A > by and large, were moving away from OS/2 toward NT in a big wayo7 > and the future looked very bleak for Enterprise OS/2.   7 Depends on the part of the world and the business area.   < > Lotus notes is an Enterprise tool, selling into Enterprise: > accounts.  No point in selling for a platform that's not, > used in Enterprise accounts, now is there?   As I said, it depends.  G > Well, Andrew Harrison, for one.  There are others, particularly thosei/ > who would defend some things about UNIX here.n  < Thanks, and yes, you are right on that. But I think that the? UNIX discussion is not yet in a state that you could claim thata< as an example for me "beeing not in touch with reality". The= most knowledgeable people in this NG added valuable argumentsI< against UNIX from what I conclude that my view of reality in this area is quite appropriate.s  E > Now, who questions my knowledge of facts except Andrew Harrison andrG > yourself.  Are you saying that Andrew was correct on those occassions % > and incorrect when criticizing you?w  < Now, I don't regard AH as valuable source of information and
 critiques.? I thought about other posters who questioned your point of viewt+ (vision?) of HW development and assessment.r  > > Hardly.  I didn't make sweeping generalizations using highly> > charged rhetoric that I couldn't back up.  I questioned your@ > judgement and gave a lot of specific examples to disprove your= > generalizations.  Specific examples that you have failed toa% > address, for the most part, at all.e  > Read your first sentences again. You are changeing the subject> here. I never critisised that you're doubting my facts but the9 style of your post. And I was completely specific on that @ (quoting, if you remember) that there is no technical reason why% you could have mismachted my comment.s  @ > Oh, now here's an example that's 20 years old!  I believe that? > IBM has almost completely reorganized about twice since then.a@ > I believe that _all_ of the SW products that I mentioned above7 > as being useful were developed since then.  They grewe8 > to be the dominant services organization in that time.  < But you didn't show with a certain credibility that these SW7 have been developed by IBM and are in fact that useful.o  A > About par for you.  A 5 year old example at how bad they are att@ > Web Site management (which is like 50 years in Internet-time),@ > and a 20 year old decision.  That decision, BTW, was driven by? > their frantic quest to field the original IBM PC before Apple-A > fielded a new generation.  Again, hardly an accusation of beingm? > slow and sclerotic that you make bad decisions in the heat of6/ > trying to get something to market right away.o   If that was the reason ...? Besides simple management mistakes it was the lack of a vision!m  > > I've had the tough job of proving a negative.  You said thatA > (paraphrase) "IBM has no useful SW they developed on their own.7> > They are slow, sclerotic and visionless".  I've had to prove > this was not true. > = > Fortunately, you used universal generalizations that can bea@ > disproved with specific examples.  I gave specific examples of? > useful software, and how they are not, particularly in the HWe@ > domain, a slow, sclerotic and visionless company.  In the caseC > of useful SW, you've only chosen to address Websphere at all, andrD > I've now countered that with my own reasons for thinking that it'sD > at least _useful_.  In the case of the HW, proving that IBM is not= > slow and sclerotic, you've not given any rebuttal _at all_.l  @ Read my statements again, understand them and you will know why.& You didn't prove what you're claiming.= I found more examples to support my position. Especially your ( reasoning about the crap IBM PC is weak.  @ > It seems the onus is on you to show how the SW examples I gave> > above are "useless".  Also, you need to justify how IBM is aB > slow and sclerotic company in the face of a lot of evidence thatC > they are actually quite innovative, particularly in the HW arena.s  3 Read my statements again and draw the consequences.a< The companies I know are better without services and SW from IBM.   > I could say the same to you.  3 A typical argument of a company which is sl&scl ...3   >  > >8 > > > -Jordan Hendersonr > > > jordan@greenapple.comi >  > -Jordan HendersonM > jordan@greenapple.com    ------------------------------   End of INFO-VAX 2001.355 ************************