1 INFO-VAX	Wed, 12 Dec 2001	Volume 2001 : Issue 689       Contents:P Re: Ada on VMS/IA64, was: Re: New York City meeting - Porting OpenVMS to Itanium# Re: Apache & protecting OSU scripts # Re: Apache & protecting OSU scripts # Re: Apache & protecting OSU scripts > Re: Availability Manager V2.0-1/DECamds V7.3B is now available Backup of a corrupted disk CI bandwidth limit Re: CI limit  Re: Compaq now a takeover target Re: Compaq to can OpenVMS ?  Re: Compaq without the merger  Re: Compaq without the merger  Re: Crash Notification' Creating a Terminal Server (LTA Device) + RE: Creating a Terminal Server (LTA Device) + Re: Creating a Terminal Server (LTA Device) 0 Re: Encompass Board Election Countdown Continues RE: ftp problem  Re: ftp problem  Re: ftp problem  GS80 VS GS160 Memory access : Re: How to tell if foreign command (SET COMMAND) is known?" Re: HP Foundations - let them know" Re: HP Foundations - let them know" Re: HP Foundations - let them know" Re: HP Foundations - let them know" Re: HP Foundations - let them know" Re: HP Foundations - let them know" Re: HP Foundations - let them know" Re: HP Foundations - let them know Re: Info-VAX@Mvb.Saic.Com  Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L3 Re: It you say it often enough does it become fact? 3 Re: It you say it often enough does it become fact? 3 Re: It you say it often enough does it become fact? 3 Re: It you say it often enough does it become fact? 3 Re: It you say it often enough does it become fact? : Re: Looking for .CLD files for some standard VMS  commands Re: Need help with MLU9 Re: Packard Foundation Tells Merger Urgers to "Paq it In" 9 Re: Packard Foundation Tells Merger Urgers to "Paq it In"  Poll Re: Poll Re: Poll Reflections 8 version of LAT?? SYS$EXAMPLES in 7.3  Re: SYS$EXAMPLES in 7.3  Re: The demise of compaq Re: The demise of compaq RE: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: Unix for HELP ... Examples?  Re: Unix for HELP ... Examples?  Re: Unix for HELP ... Examples?  Re: Unix for HELP ... Examples?  Unknown VAXstation 4000-90 ???" Re: Unknown VAXstation 4000-90 ???" Re: Unknown VAXstation 4000-90 ??? VMS 72 on MV 3100  Re: VMS 72 on MV 3100  Re: VMS 72 on MV 3100 ? Re: Writing a device driver: virtual/physical address questions ? Re: Writing a device driver: virtual/physical address questions ? Re: Writing a device driver: virtual/physical address questions   F ----------------------------------------------------------------------    Date: 11 Dec 2001 14:57:27 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) Y Subject: Re: Ada on VMS/IA64, was: Re: New York City meeting - Porting OpenVMS to Itanium 3 Message-ID: <aN4tVcH7zsJS@eisner.encompasserve.org>    In article <BGoR7.57390$xS6.92627@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:) > On 11 Dec 2001 01:18:28 GMT, in article ? > <20011210201828.18482.00002980@mb-cg.aol.com>, Doug W. wrote:  >>M >>5.) I learned both Compaq and Intel compilers were on the roadmap and there : >>would be an Ada compiler provided (whatever that means). > L > There is an issue with just which Ada compilers will be available on IA64. > H > Apologies if you already know the following, but "whatever that means" > indicates that you may not:  > I > There are two Ada standards, the original Ada 83, and the later Ada 95.  > I > CPQ's Ada (Compaq Ada, aka, DEC Ada) compiler is basically Ada 83. When J > Ada 95 came out, DEC signed an agreement with Ada Core Technologies, whoI > produce a GPLed Ada 95 compiler called GNAT, to port GNAT to VMS, which  > they did.  > 6 > However, DEC also kept DEC Ada running on the Alpha. > M > The problem is that there is a big question mark about if CPQ will now port L > Compaq Ada to IA64, or require Ada users to switch to GNAT. Various peopleN > are getting different answers from different people, with the initial answerM > that it was not to be ported, but later statements saying that yes it will.  > K > The problem is that because of the nature of Ada projects, switching to a K > different compiler would generally be considered to be a big issue, so if I > CPQ Ada is not ported to IA64, then that decision is likely to _really_  > upset a lot of people.  B Those who don't "do" Ada can consider it similar to the difference@ between VAXC and DEC C.  The CC command on VAX will support bothC compilers at the same time, allowing users of an individual machine B to use one compiler or the other (and the system manager to choose
 the default).   A DEC C also provided a /STANDARD=VAXC qualifier.  So why would one @ need an old VAX C compiler if the new DEC C compiler can use the< /STANDARD=VAXC qualifier ?  The answer is that even with the> qualifier, DEC C was not originally exactly the same as VAX C. Maybe it is by now.   B With Ada the differences are much less in the language definition,C since Ada83 is almost a proper subset of Ada95.  The differences in > Ada have to do with the compilation model.  The Ada83 standardE required a compilation subsystem, which VAX/DEC/Compaq Ada faithfully C supplied.  Ada95 has no such requirement, and most Ada95 vendors do A their checking in a different manner that requires a full scan of A source files for each compilation, sort of the way C does include C files and Bliss does require files, as contrasted with the way that C Bliss does library files and Pascal does environment files (talking D about the DEC compilers for these languages, although the C behavior is required by the C standard).   B So Ada83 source files can be compiled under an Ada95 compiler, butE everything that one would do with MMS in other languages is different C between Ada83 and the GNAT Ada95 compiler.  That makes it rough for C anyone trying to build applications on two different compilers (and  GNAT does not support VAX).   < One other issue is that DEC Ada introduced a patented "smartA recompilation" technique that considerably speeds up development. 0 That is not currently in any other Ada compiler.   ------------------------------    Date: 11 Dec 2001 11:29:34 -0800( From: bob@instantwhip.com (Bob Ceculski), Subject: Re: Apache & protecting OSU scripts= Message-ID: <d7791aa1.0112111129.74945b05@posting.google.com>   h "Tom Wade" <t.wade@vms.eurokom.ie.removespam> wrote in message news:<2YpR7.2712$_3.10734@news.iol.ie>...7 > "Bob Ceculski" <bob@instantwhip.com> wrote in message 9 > news:d7791aa1.0112100852.6898f319@posting.google.com...  > I > > try setting up ACL's for each individual file you want to protect ...  > M > I think I may have caused some confusion here.  By 'protect' I refer to the K > web browser popping up a username/password dialog box, and authenticating H > this against the SYSUAF. The CGI script can then use the authenticated > username.  > G > Apache seems to activate this for all the files in a given directory, L > whereas OSU could specify a single script file.  Since scripts written forM > OSU must reside in a single directory, how can I turn authentication on for  > some of these, but not all.  > N > If, on the other hand, there is a way using ACLs to achieve this (as opposedE > to granting access to the script for the Apache account), could you G > elaborate please, as I can't find any reference to this in the Apache  > documentation ?  >   H that's a question for David Jones or the Apache support group ... we useH Purveyor and at the click of a mouse can do that to any file we want ...   ------------------------------  # Date: Tue, 11 Dec 2001 23:55:49 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr"), Subject: Re: Apache & protecting OSU scripts8 Message-ID: <00A065E4.C48928E9@SSRL04.SLAC.STANFORD.EDU>  8 In article <2YpR7.2712$_3.10734@news.iol.ie>, "Tom Wade"* <t.wade@vms.eurokom.ie.removespam> writes:   > 6 >"Bob Ceculski" <bob@instantwhip.com> wrote in message8 >news:d7791aa1.0112100852.6898f319@posting.google.com... > H >> try setting up ACL's for each individual file you want to protect ... > L >I think I may have caused some confusion here.  By 'protect' I refer to theJ >web browser popping up a username/password dialog box, and authenticatingG >this against the SYSUAF. The CGI script can then use the authenticated 
 >username. > F >Apache seems to activate this for all the files in a given directory,K >whereas OSU could specify a single script file.  Since scripts written for L >OSU must reside in a single directory, how can I turn authentication on for >some of these, but not all. >   O Tom, one option is to to use the <LocationMatch> container, not the <Directory> G container.  (This matches your URL, or parts thereof with wildcarding.)    For example:  0 <LocationMatch /cgi-bin/rdbweb/update_phonelist>     SSLRequireSSL      AuthType Basic*     AuthName "SSRL OpenVMS authentication"     AuthUserOpenVMS On     require valid-user </LocationMatch>     J (Which happens to be a working extract from my test apache config; rdbweb G is actually a script in cgi-bin and update_phonelist is a parameter to  , rdbweb, but it doesn't matter; you could do   " <LocationMatch /htbin/scriptname>      SSLRequireSSL      AuthType Basic*     AuthName "SSRL OpenVMS authentication"     AuthUserOpenVMS On     require valid-user </LocationMatch>    I and this should require the authentication before doing the magic to make  it run an htbin program.   -- Alan     O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================    ------------------------------  % Date: Tue, 11 Dec 2001 21:33:30 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender), Subject: Re: Apache & protecting OSU scripts; Message-ID: <3c166d9a.524144494f47414741@radiogaga.harz.de>   K I haven't yet have the time to get too accustomed with Apache configuration 9 (which is a guru task really ;-), but I'll try an answer.   2 Tom Wade (t.wade@vms.eurokom.ie.removespam) wrote: > By 'protect' I refer to the K > web browser popping up a username/password dialog box, and authenticating H > this against the SYSUAF. The CGI script can then use the authenticated > username.  > G > Apache seems to activate this for all the files in a given directory, L > whereas OSU could specify a single script file.  Since scripts written forM > OSU must reside in a single directory, how can I turn authentication on for  > some of these, but not all.   % In general, authentication looks like   7   AuthType Basic  ! or sysuaf (or whatever it's called)    AuthName realm-name !   AuthUserFile /path/to/user-file #   AuthGroupFile /path/to/group-file 1   Require Valid-User  ! or Require User some-user 3                       ! or Require Group some-group   E These authentication directives can be set in the context of a "scope F container", i.e. a <VirtualHost>, <Directory>, <Location>, <Files>, orH <FilesMatch> section (my selection). I guess one of the last two is what
 you're after.   D See http://httpd.apache.org/docs/howto/auth.html. This page talks ofA "directory or any other scope container", whereas the directives' 9 descriptions say the context is <Directory> or .htaccess. / I must admit I don't know which one is correct.    cu,    Martin --  D                         | Martin Vorlaender  |  VMS & WNT programmer1  VMS is today what      | work: mv@pdv-systeme.de E  Microsoft wants        |    http://www.pdv-systeme.de/users/martinv/ 8  Windows NT 8.0 to be!  | home: martin@radiogaga.harz.de   ------------------------------    Date: 11 Dec 2001 20:11:11 +0100* From: eplan@kapsch.net (Peter LANGSTOEGER)G Subject: Re: Availability Manager V2.0-1/DECamds V7.3B is now available * Message-ID: <3c165a4f$1@news.kapsch.co.at>  j In article <%2PM7.1994$RL6.61657@news.cpqcorp.net>, "Barry Kierstein" <Barry.Kierstein@Compaq.Com> writes:M >    The Availability Manager team is happy to announce a new version of both J >Availability Manager and DECamds.  They are available on the Web from theF >OpenVMS home page (www.openvms.compaq.com/openvms/products/availman).   Thanks a lot  B >    Availability Manager V2.0-1 has fixed the following problems: > K >         Large (>32K) ENQLM and ENQCNT values are now displayed correctly. < >         Bugs in Event Notification on VMS have been fixed. > 3 >    DECamds V7.3B has fixed the following problem:  > F >        DECamds help now works correctly.  Formatting problems in the> >          help file caused the help to not display correctly.  M But is still doesn't preserve the screen positions of its windows with "Exit" G "System Overview" climbs up to left upper corner and "Event Log" climbs N down a couple of millimeters, just like the years before. Window Sizes are ok," only window positions get changed.  ! >    RMDRIVER (affects both kits)  > > >         Rare bug fixed that would cause a crash on a node if9 >            1)  The node was under a heavy I/O load, and ; >            2)  AM or DECamds GUI was run on the same node H >                 EBA0: is now not chosen as a communication device.  On
 >Galaxies,E >                 this device is now a communications channel between # >                 Galaxy instances.   K And it fixes my problem with missing V7.3 VAXes in AMDS GUI (ACCVIO seen in 	 Logfile).   H >    Before installing either kit, read the release notes.  They containK >information about running AM V2.0 and RMDRIVER from the new kits, and some ; >PCSI patches that are needed for the OpenVMS installation.    --  < 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: Tue, 11 Dec 2001 14:44:06 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> # Subject: Backup of a corrupted disk , Message-ID: <3C166201.684F63ED@videotron.ca>  M While doing a backup of my system disk, the system started to generate oodles M of mount verification messages, and the backup log indicated some fatal drive D errors (SYSTEM-F-DRVERR). But it only generated those files in a fewD directories (probably bad areas on the drive). After BACKUP has doneZ generating all the errors, it then seems to continue happily with other files/directories.    L Obvioiusly, I have to consider this backup to be incomplete. So plan B is toV restore a previous backup onto a new drive. However, I do have the following question:  L If I restore from the untrustable save set all files whose modification dateM is after the file that was restored from the previous backup, what happens if J one such file was in fact a file which could not be fully backed-up due toP drive errors ? Will it restore a corrupted file or will it just skip that file ?   ------------------------------  % Date: Wed, 12 Dec 2001 08:07:09 +0800 $ From: "Kenneth" <chehon@net-yan.com> Subject: CI bandwidth limit , Message-ID: <9v66lu$30dk$1@news.net-yan.com>  K I read the specification that CI has the limit of 140Mbit/sec which I think K is about 18MByte/sec (in + out). When I collect the CI thruput by DECPS, it  gives me the following result:    L                                                                        Block@  Cir-                      Path  Data-  Mess-    Disk       Disk	 Transfers G  cuit    Node  Component   Name  grams   ages Operations KB Thruput  KB  Thruput L ------  ------ ---------   ----  -----  ----- ---------- ----------  ------- --- C CI-4           ** total **         0.0 1381.3      517.7     6298.7  11628.5 C CI-4    HSJ017                     0.0  330.4      156.4      957.5u 1061.7C CI-4    HSJ023                     0.0  128.8       62.5     1022.2C 1083.8C CI-4    HSJ026                     0.0  101.9       51.1      856.3  1022.9C CI-4    HSJ027                     0.0  215.8      101.5     1707.0  1951.5C CI-4    HSJ028                     0.0  222.2      100.2      676.8o 770.0 C CI-4    HSJ029                     0.0   99.7       46.1     1078.9g 1305.8C CI-4    J      UNKNOWN     PNE0    0.0  820.6      267.1     3120.8w 7504.1C CI-4    L      UNKNOWN     PNE0    0.0  843.3      250.6     3177.9e 8557.2  L The total thruput is more than 11MBbye. Is CI has seperate bandwitdth for IN and OUT or not?n   ------------------------------    Date: 11 Dec 2001 17:17:43 -08001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)c Subject: Re: CI limitf= Message-ID: <cf15391e.0112111717.2e2a7bbf@posting.google.com>l  \ "Kenneth" <yeungkenneth@yahoo.com> wrote in message news:<9tgb0h$3054$1@news.net-yan.com>...K > I have read the manual in the VMS clustering that the CI thruput limit isoJ > 140Mb ( apporx. 17MB), but when I capture the thruput (KB/sec) of the CI0 > from the DECPS, it always has reach 30MB, why?  E For the benefit of other folks following this discussion, Kenneth waspB kind enough to e-mail me a copy of the DECps data off-line, and itF appears the problem was a simple mistake: adding up "stacked" values. F With this mistake removed, the data showed about 10 MB/second maximum.? ---------------------------------------------------------------n? Keith Parris | parris at encompasserve dot org | Consulting on:t> Clusters, Disaster Tolerance, Performance, I/O, Storage & SANs   ------------------------------  + Date: Tue, 11 Dec 2001 20:14:20 +0000 (UTC)i/ From: Sander Vesik <sander@haldjas.folklore.ee>s) Subject: Re: Compaq now a takeover targetl3 Message-ID: <1008101657.785644@haldjas.folklore.ee>   ; In comp.arch JF Mezei <jfmezei.spamnot@videotron.ca> wrote:  > cjt wrote: >>  D >> Scott might want Compaq's customers, but I doubt he wants Compaq.  N > Has anyone calculated at what share price Compaq starte to become attractive4 > just for its customers and intellectual property ?  O > Like buying a 750 for peanuts, throw away the computer and use the cabinet toe > put in your stereo/tve > or put in a bar.  M > Look at the way American Airlines bought TWA. They only puchased the assetse/ > they were interested in and ditched the rest.n  N > A buyer might just get a controlling share, perhaps in conjunction with someP > other major shareholder and cannabalize Compaq, returning the proceeds back to/ > shareholders and getting rid of a competitor.i  , This is the CA cenario of CPQ buy-up, right?   -- r 	Sanderi   +++ Out of cheese error +++e   ------------------------------  % Date: Tue, 11 Dec 2001 14:00:04 -0500-5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>0$ Subject: Re: Compaq to can OpenVMS ?2 Message-ID: <oLsR7.436$BK1.13855@news.cpqcorp.net>  G There is Telco, and there is Telco.  VMS does a significant business is-J portions of Telco.  Not necessarily the same things that Tru64 wass making significant gains in.m    = JF Mezei wrote in message <3C1654B1.146756BF@videotron.ca>...> >"Terry C. Shannon" wrote:K >> VMS hasn't asserted a presence in the HPTC space in quite some time, andu thewL >> same seems to be true for the segment of the telco market which the DS20LJ >> addresses. The decommitment appears to be confined to the DS20L itself. > I >Humm, wasn't the Telco market one of the few strong remaining niches for  VMS ?p > Now that one is gone too ? >oJ >Has Compaq woken up to the fact that lack of sales in telcos is a natural sideG >effect of the telco industry being in a depression ? So what Compaq isP sayingH >is that once the telco industry wakes up again, VMS will no longer be a chosen product.e   ------------------------------  % Date: Tue, 11 Dec 2001 14:24:01 -0500m- From: JF Mezei <jfmezei.spamnot@videotron.ca> & Subject: Re: Compaq without the merger, Message-ID: <3C165D4D.2F95AF13@videotron.ca>   "Terry C. Shannon" wrote:qG > That said, Compaq IMHO needs to do a much better job articulating itse > enterprise strategy.  K As long as Compaq sends out McFowell and Winkler to brief analysts, how cant6 Compaq have any credibility in the enterprise market ?  H How come Marcello isn't being sent out to brief real analysts ? How comeH Marcello seem to only be allowed to talk to the existing customer base ?   ------------------------------  # Date: Tue, 11 Dec 2001 19:31:12 GMTp4 From: "Terry C. Shannon" <terryshannon@mediaone.net>& Subject: Re: Compaq without the merger. Message-ID: <4atR7.31798$wL4.118040@rwcrnsc51>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3C165D4D.2F95AF13@videotron.ca... > "Terry C. Shannon" wrote:vI > > That said, Compaq IMHO needs to do a much better job articulating its  > > enterprise strategy. > I > As long as Compaq sends out McFowell and Winkler to brief analysts, how  can 8 > Compaq have any credibility in the enterprise market ? >CJ > How come Marcello isn't being sent out to brief real analysts ? How comeJ > Marcello seem to only be allowed to talk to the existing customer base ?  J Well, I don't work for Compaq so I really can't explain how and why CompaqC allocates its human resources. Near as I can tell, Mr. Marcello wasoD unavailable during the London briefing because he was out talking to customers and prospects.  A Mr. Blackmore seemed to do a pretty good job talking about things5 enterprise-related, though. ;-}    ------------------------------  % Date: Wed, 12 Dec 2001 02:00:28 -0500l  From: John Santos <JOHN@egh.com> Subject: Re: Crash Notificatione6 Message-ID: <1011212013230.64413B-100000@Ives.egh.com>  " On 11 Dec 2001, Bob Koehler wrote:  [ > In article <3C1502CC.6CFF8EA3@vmmc.org>, Jack Trachtman <Jack.Trachtman@vmmc.org> writes:i9 > > At the end of SYSTARTUP_VMS.COM, I have myself paged.m > > H > > I'd like to differentiate between a normal boot and a crash restart. > > D > > What can I look at from within DCL to see if this is a normal or > > a crash restart?
 > > Thanks > G >    If you put an SDA copy command in the boot somewhere, it will copyrH >    the dump from the dump file only if it was a crash.  You could then' >    test for presence of the new copy.y  F That used to work, and I still have SDA (actually, analyze/crash) copyF commands in all my systartup_vms.com's, but since they added CLUE (VMS) V7.0?), it seems to have stopped working.u  H My understanding was SDA checked to see if it was in the startup processG (process name = "STARTUP"), and if so, it checked a flag that meant theeG dump was from a new (unanalyzed) crash.  If set, it copyied and clearedCI the flag.  If clear, COPY is a NOP.  This was to prevent copying the dump2@ file on normal boots, or if the dump file contained only an old, previously saved crash dump.  B When they added CLUE, it executed the 1st analyze/crash in processA "STARTUP" and hence cleared the flag, so my later attempt to copy/ did nothing.  E However, I was just looking at CLUE$STARTUP.COM today, and in fact it E runs ANALYZE/CRASH in a detached process, so it shouldn't be clearinge the "already analyzed" flag.  : Does COPY still work (V7.1 and later) for everyone but me?? (All my systems use a separate dump file, not PAGEFILE.SYS.  Oni@ a few cluster nodes, it is a cluster-common dump file aliased to, sys$specific:[sysexe]sysdump.dmp.  No DOSD.)  B It looks like adding a "COPY SYSDUMP.SAV" (or whatever) in the 1st $   analyze/crash 'dump_fileB should do the trick, but I doubt this is the prefered method since/ it is modifying a Compaq-supplied startup file.   ? A more complicated method would be to submit a batch job out of A systartup_vms.com that checks for a new (post-BOOT, pre-NOW) CLUE > file in sys$errorlog:, and then does the copy only if the CLUEC analysis file exists.  (Range-check the file, because if the systemaA ever got its time set to some random future date, e.g. due to Y2Kg@ testing or a mis-typed set time command, it would always produce/ dump copies, until the bogus date was reached.)i  ! Does anyone have a better method?e   -- s John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Tue, 11 Dec 2001 19:53:17 GMT> From: sfm1115@bjc.org (sfm)h0 Subject: Creating a Terminal Server (LTA Device)1 Message-ID: <3c1662a8.439914133@news.starnet.net>o  E I am not very good with LAT.  I need to create some LTA Devices on myb, Alpha Server 1000 5/400 running OpenVMS7.2-1 Can anyone give me a hand.  ! It is running Multinet 4.2 rev. A   E I can do a show port in LATCP and see the devices which are inactive, F but when I do a show queue like on our other servers, all I see is the# Print Queues I defined in Multinet.r     Thanks in advance for any help.    ------------------------------  % Date: Tue, 11 Dec 2001 16:15:19 -0500e* From: WILLIAM WEBB <WWEBB1@email.usps.gov>4 Subject: RE: Creating a Terminal Server (LTA Device)- Message-ID: <0033000044530958000002L082*@MHS>c  
 =0AWow.  LAT.i It's been YEARS.  - LAT is LAT is apples and IP is IP is oranges.   0 Exactly what are you trying to do?  Give us more detail.M  7 Are you setting up serial printers via terminal serversh6 that use LAT, or are you using the serial ports on the back of the box?  " Or are you setting up IP printers?  2 Multinet has nothing to do with it, to the best of5 my knowledge (but then I've never USED Multinet, justa UCX and Compaq TCPIP Services.  * What does MCR LATCP SHOW PORT LTAxxx /FULL# show you for the ports in question?    MCR LATCP CREATE PORT LTAxxx= MCR LATCP SET PORT LTAxxx /NODE=3Dservername /PORT=3Dportnameo     -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNET=( Sent: Tuesday, December 11, 2001 2:56 PMB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET0 Subject: Creating a Terminal Server (LTA Device)    E I am not very good with LAT.  I need to create some LTA Devices on my , Alpha Server 1000 5/400 running OpenVMS7.2-1 Can anyone give me a hand.  ! It is running Multinet 4.2 rev. A=  E I can do a show port in LATCP and see the devices which are inactive,3F but when I do a show queue like on our other servers, all I see is the# Print Queues I defined in Multinet.       Thanks in advance for any help.=   ------------------------------  # Date: Tue, 11 Dec 2001 22:28:37 GMTe2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)4 Subject: Re: Creating a Terminal Server (LTA Device)2 Message-ID: <pMvR7.447$BK1.14041@news.cpqcorp.net>  O In article <3c1662a8.439914133@news.starnet.net>, sfm1115@bjc.org (sfm) writes:e+ :...I need to create some LTA Devices on myI0 :Alpha Server 1000 5/400 running OpenVMS7.2-1...  H   Please acquire access to and read the available OpenVMS documentation.E   On-line copies of the manuals are available at the OpenVMS website.w  J   With OpenVMS Alpha V7.2-1, you would want to look in the LAT$STARTUP.COMJ   and particularly in LAT$SYSTARTUP.COM and LAT$SYSTARTUP.TEMPLATE.  TheseJ   files are in SYS$SYSROOT:[SYSMGR].  There are also details of LAT in theG   OpenVMS manuals, particularly in the system management documentation.p  " :It is running Multinet 4.2 rev. A  D   LAT, IP, Clustering and DECnet are completely different protocols.D   If you want to set up LAT printing to a terminal server, you will F   need to use the LAT protocol to communicate between the LAT softwareA   on the host system and the LAT software in the terminal server.e  F :I can do a show port in LATCP and see the devices which are inactive,G :but when I do a show queue like on our other servers, all I see is thet$ :Print Queues I defined in Multinet.  F   First create the LAT (LT) devices per the information in the OpenVMSE   documentation and in LAT$SYSTARTUP.TEMPLATE.  Once you have created C   these devices, you can use the standard commands for creating andhG   operating a print queue to a serial printer -- a central goal of LAT wE   was to provide a host interface that looks to the queue manager andnG   to other user and host components much the same as does a printer or  9   a terminal connected to a serial terminal line appears.     :Thanks in advance for any help.  D   If the LAT protocol is not relevent to the question and you reallyG   want to create an LPD/LPR queue or a telnet queue, then you will wanteF   to review the Multinet documentation -- the LAT protocol and the LT H   devices are not related to the question.  In the specific case of the E   Compaq TCP/IP Services product, there are details in the managementaD   documentation for the product, and there are tips and suggestions C   that are available by reviewing topic (1020) and other referenced:F   topics over in the Ask The Wizard area.  "Reverse telnet" -- a topicF   that sees regular discussions, and potentially of interest to you --F   is also discussed in the OpenVMS FAQ and in the Ask The Wizard area.      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: Tue, 11 Dec 2001 14:10:03 -0500 % From: Karl S. Erbland <karl@ksme.net> 9 Subject: Re: Encompass Board Election Countdown Continuesd5 Message-ID: <MPG.16802418581f2a5998970f@news.alt.net>o  I In article <PfNQ7.22247$ER5.279152@rwcrnsc52>, terryshannon@mediaone.net   says...   BM > This is an important election... regardless of who you'd like to see on the A > Board, PLEASE take the opportunity to vote in this cycle. Voter E > participation in recent BoD elections has been disappointingly low.   H O, please, you make me barf. Like you really care unless it is you that 
 gets elected.h   > (and yep, I'm running...     See, told you so.n   RESIST THE BORG!. It doesn't make any bit of difference, anyhow.   ------------------------------  % Date: Tue, 11 Dec 2001 14:05:14 -0500G# From: "Dan Allen" <dallen@nist.gov>- Subject: RE: ftp problem: Message-ID: <NEBBIALHDHJMJINPGMOAEEGNDOAA.dallen@nist.gov>   > -----Original Message-----. > From: Alan Greig [mailto:a.greig@virgin.net]* > Sent: Tuesday, December 11, 2001 9:29 AM > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: ftp problem >  > F > On Tue, 11 Dec 2001 12:59:22 +0000, Roy Omond <Roy@Omond.net> wrote: >  > >Kari Keronen wrote: > >1 > >> troll-ftpdd > >>: > >> http://www.trolltech.com/developer/download/ftpd.html > >>. > >> From products man pages UNUSUAL FEATURES: > >>M > >> "ASCII mode transfer is omitted, because it's useful so seldom and tripstM > >> careless users so often. If the client tries to download a file in ASCIIi? > >> mode, ftpd prints a warning at the start of the download."e > >>O > >> One of our unix admins said that it's quite popular in linux world becauserI > >> it's "simple and safe". In this case it proved to be quite unusable.n > >n > >"Unusual features" ???e > >fJ > >It's simply very badly broken, regardless of what your Unix admins say. > . > But doesn't SET F|ILE/ATT:RFM:STMLF filenameG > work if the file is downloaded in binary mode? Assuming the file is afH > Unix format ASCII file then a binary download will get it onto the VMSH > system exactly as is. So changing to STMLF to match the Unix file typeE > should work. If you download using the ftp client from Netscape youK@ > end up with files already in STMLF format - not fixed 512 byte > records. $ > F > Unix has no concept of non binary files. ASCII files are just binary? > files with LF chars separating lines. VMS, on the other hand,eB > understands Unix ASCII format so just change the format with the > command above to match.   H 	Only that the FTPD doesn't conform to one of the most used and simplestF 	TCP/IP protocols extant today. How useful do you figure an FTP:// urlC 	served by that ftpd would be in any browser? SAFE? Nay brain dead,u 	comotose, stinkin rotten... - > = > No need to ZIP the files first. Or have I missed something?  > + > >"Troll ftpd" ?  How appropriately named.6 > > ( > >Do your best to get rid of this junk. > >0
 > >*sigh* ...1 > >  > >Roy Omond > >Blue Bubble Ltd.  >  > -- > Alan >    ------------------------------  % Date: Tue, 11 Dec 2001 21:47:35 +01000 From: Dirk Munk <munk@home.nl> Subject: Re: ftp problem' Message-ID: <3C1670E6.79F7FC12@home.nl>    Kari Keronen wrote:4  0 > > But doesn't SET F|ILE/ATT:RFM:STMLF filenameI > > work if the file is downloaded in binary mode? Assuming the file is a6J > > Unix format ASCII file then a binary download will get it onto the VMSJ > > system exactly as is. So changing to STMLF to match the Unix file typeG > > should work. If you download using the ftp client from Netscape youCB > > end up with files already in STMLF format - not fixed 512 byte > > records. > > H > Using TCPIP 5.1 ECO 3 ftp client I ended up fixed 512 byte records (as# > expected) when using binary mode.e >g > From VMS help: >1B >      o  Specifying IMAGE results in a sequential file with fixedB >         records of 512 bytes. Select this type when transferring9 >         non-ASCII files such as executable image files.p >l > SET FILE/ATTR won't fix this., >t  L Sorry, but you are wrong in this case. When you choose binary mode, the fileH will be a exact copy of the the file on the Linux system, byte for byte,K including line terminators like <cr> and <lf>. These terminators are in the N file, that is the important issue. Normally these terminators would be used inP ASCII FTP to determine the end of a record, so the FTP utility on the other sideL can do with the record what ever it wants to. A image file doesn't have realK records, that is why you don't have record attributes like <cr> etc. The sof4 called record is merely a disk block, and that's it.  G Now if you examine the file by using dump, you can determine which linekM terminator was used, <cr>, <lf>, or <cr><lf>. Changing the file attributes tosP Stream-LF, Stream-CR or Stream-CRLF for instance will tell RMS to look for thoseP terminators in the file, and to disregard the block boundaries as is normal withO most files. Of course you have to change the maximum record length too, usuallyrO to the maximum of 32676 (just like with files produced with C-programs). I have O used this method quite often with files downloaded from the internet, and I cane assure you it works.           >t > > >r* > > >Do your best to get rid of this junk. > > >eN > I will try my best to convice the owner of the linux box to change their ftpH > server :)  Any good suggestions by the way ? chroot support essential. >n > -Kari-   ------------------------------  % Date: Wed, 12 Dec 2001 00:56:50 -0500r  From: John Santos <JOHN@egh.com> Subject: Re: ftp problem6 Message-ID: <1011212004618.64413A-100000@Ives.egh.com>  % On Tue, 11 Dec 2001, Dirk Munk wrote:    >  >  > Kari Keronen wrote:- > 2 > > > But doesn't SET F|ILE/ATT:RFM:STMLF filenameK > > > work if the file is downloaded in binary mode? Assuming the file is aeL > > > Unix format ASCII file then a binary download will get it onto the VMSL > > > system exactly as is. So changing to STMLF to match the Unix file typeI > > > should work. If you download using the ftp client from Netscape younD > > > end up with files already in STMLF format - not fixed 512 byte > > > records. > > >rJ > > Using TCPIP 5.1 ECO 3 ftp client I ended up fixed 512 byte records (as% > > expected) when using binary mode.f > >e > > From VMS help: > >kD > >      o  Specifying IMAGE results in a sequential file with fixedD > >         records of 512 bytes. Select this type when transferring; > >         non-ASCII files such as executable image files.  > >t! > > SET FILE/ATTR won't fix this.h > >t > N > Sorry, but you are wrong in this case. When you choose binary mode, the fileJ > will be a exact copy of the the file on the Linux system, byte for byte,M > including line terminators like <cr> and <lf>. These terminators are in the-P > file, that is the important issue. Normally these terminators would be used inR > ASCII FTP to determine the end of a record, so the FTP utility on the other sideN > can do with the record what ever it wants to. A image file doesn't have realM > records, that is why you don't have record attributes like <cr> etc. The sos6 > called record is merely a disk block, and that's it. > I > Now if you examine the file by using dump, you can determine which lineoO > terminator was used, <cr>, <lf>, or <cr><lf>. Changing the file attributes tosR > Stream-LF, Stream-CR or Stream-CRLF for instance will tell RMS to look for thoseR > terminators in the file, and to disregard the block boundaries as is normal withQ > most files. Of course you have to change the maximum record length too, usually3Q > to the maximum of 32676 (just like with files produced with C-programs). I havesQ > used this method quite often with files downloaded from the internet, and I cant > assure you it works.  K I just want to add:  Change the file with $ SET FILE/ATTR.  *Don't* convertlH it.  CONVERT will assume your original file really was fixed-length, 512F byte records and will convert it to a variable length record file withJ implied carriage control where all the records just happen to be 512 bytesH long (if the output of CONVERT is sequential variable), or it will stuffH in a <CR>, <LF>, or <CR><LF> every 512 characters (if the output file isJ Stream-CR, Stream-LF, or Stream-CRLF respectively.)  None of these formatsG is correct; your file already has the Unix <LF>'s in it, you don't wantn to add them.  H I'm not 100% sure, but IIRC the original post said you had converted theC output file to Stream-LF and it just inserted spurious line breaks, : which is exactly what I would expect in this circumstance.   --   John SantosC Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 12 Dec 2001 00:28:13 GMT' From: dashw459@aol.comeatspam (Doug W.)c$ Subject: GS80 VS GS160 Memory access9 Message-ID: <20011211192813.18462.00003155@mb-cg.aol.com>f  O The QBBs in a GS80 are not linked in the same manner as those in the GS160.  DotO the GS 80 and GS120 have identical cross QBB memory latencies and bandwidtheven & though there are hardware differences?   ------------------------------  # Date: Wed, 12 Dec 2001 03:17:29 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>sC Subject: Re: How to tell if foreign command (SET COMMAND) is known?u' Message-ID: <3C16CC89.61A45530@fsi.net>l   Howard S Shubs wrote:o > ) > In article <3C157EFB.220B0BCB@fsi.net>, 5 >  "David J. Dachtera" <djesys.nospam@fsi.net> wrote:w > L > > Building a private command table (disk file) does not require privilege.D > > Actually modifying your UAF record to use it is another question
 > > entirely.s > N > Since that's not necessary, it doesn't matter.  Once logged in, you can do a >  > $ SET COMMAND/TABLE=file > J > and switch over, as far as I can tell.  Modifying the UAF record is only# > necessary to use it -by default-.m  F ...or use one installed in shared memory. AFAIK, (corrections welcome,A as always, if stated with respect) *ANY*time you SET COMMAND, the H resulting table goes into local (process) memory, and eats up space that, could otherwise be used for code, data, etc.   -- s David J. Dachterae dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 11 Dec 2001 11:21:53 -0800. From: jcwoman1963@hotmail.com (Sharon Guthrie)+ Subject: Re: HP Foundations - let them know = Message-ID: <997d6325.0112111121.137ec94f@posting.google.com>1  P In article <3C150310.43B0405A@swissonline.delete.ch>, John McLean <mcleanj@swiss online.delete.ch> writes:iG > - if the sales that Fred refers to are new sites and not existing VMS H > who are updating or expanding, I'm intrigued as to how they discoveredJ > VMS and where they have found any information.  I can understand some ofH > Defense hearing about VMS via the COE stuff but other people ??   Gee,C > if this is what can be done without telling anyone about VMS justeI > imagine what a little bit of marketing ^h^h^h^h^h^h^h^h promotion might 
 > achieve.  O         Exactly what I've been wondering.  I wonder if Fred is also not seeing  N what the low-level portions of the computer industry think of VMS.  Low-level H meaning the computer programmers, system analysts, etc.  Fred made this  comment:  L > > I have every reason to believe that OpenVMS will emerge from this in theN > > best shape and position that it has been in for years.  We will have the  N > > same robust and trusted O/S, and we will have it on a platform that should6 > > provide competetive performance, with lower costs.  P         I agree with this.  However, it will be a robust and trusted OS that is J scorned by developers as being obsolete or legacy.  Companies who look at O buying VMS systems will have trouble getting people to work on them.  Why do I -O say this?  Simple.  For the past - ohh 5 or so years, with the past 2ish years eN being really bad, this is what I see from my peers when I tell them I work on  VMS.L         Best response:  Oh, I used that in college but I didn't know it was 
 still around.dM         Worst response: (a physical sneer)  Oh, that's so oooold!  Why don't aG you jump into the new millenium, retrain and get your skillset current?e  O         Sometimes the worst response is nothing more than a physical sneer, as iJ if they can't lower themselves to address *such* a silly person who keeps N working on obsolete crap.  I've had many people tell me to learn Java and C++ M to get my programming skills current.  When I tell them I certainly could do u< that because Java and C++ both run on VMS, they're shocked.   M         Fred, I agree with you that hopefully after all the dust settles and  N VMS is ported to Itanium, it will be just as terrific as it has always been.  L But Compaq/HP STILL needs to get their rears in gear to market/promote it.  P It's *almost* too late.  Right now, today, we have one hell of a negative image ! to counter.  It's very, very sad.m   Sharon   ------------------------------  + Date: Tue, 11 Dec 2001 20:36:16 +0100 (MET)n9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> + Subject: Re: HP Foundations - let them known; Message-ID: <01KBR6PPLX5Q9138XQ@sysdev.deutsche-boerse.com>e  E > Best response:  Oh, I used that in college but I didn't know it wasp > still around.  > J > Worst response: (a physical sneer)  Oh, that's so oooold!  Why don't youF > jump into the new millenium, retrain and get your skillset current?   # I've heard: "Is that still legal?!"1  H > Sometimes the worst response is nothing more than a physical sneer, asE > if they can't lower themselves to address *such* a silly person who H > keeps working on obsolete crap.  I've had many people tell me to learnH > Java and C++ to get my programming skills current.  When I tell them IG > certainly could do that because Java and C++ both run on VMS, they'reS > shocked. ,  I A few years ago, I was involved in a project doing numerically intensive TB work in C++ (no, I didn't write the code; I would have done it in H Fortran95, but for various historical reasons it was in C++).  Although E it was written in strictly standard C++, it ran without modification MG only on VMS and the Mac.  The VMS C++ compiler was by far the best and fE most user friendly and for the few questions we did have we received r? quick and friendly email advice from the fine folks at Digital.w  J > Fred, I agree with you that hopefully after all the dust settles and VMSJ > is ported to Itanium, it will be just as terrific as it has always been.H > But Compaq/HP STILL needs to get their rears in gear to market/promoteF > it. It's *almost* too late.  Right now, today, we have one hell of a3 > negative image to counter.  It's very, very sad. o  E I think Fred is right when it comes to keeping VMS about where it is sH now.  Despite the doom mongerers, the VMS market is about the same size C as it was 10 years ago.  There have been some losses in some areas  E (notably academia, which is important for "metamarket" reasons), but oI gains in others.  What puzzles me is the lack of effort to expand VMS to mC other markets.  I don't think the average Joe wants or needs a VMS nI machine to replace his PC (in fact, the average Joe doesn't need a PC in nH many cases---check out Cliff Stoll's most recent book).  However, there @ is a lot of space between the average Joe and current VMS users.   ------------------------------  % Date: Tue, 11 Dec 2001 21:20:44 +0000i4 From: Andrew Swallow <andrew.swallow@baesystems.com>+ Subject: Re: HP Foundations - let them knowt. Message-ID: <3C1678AC.C8C926FE@baesystems.com>   Sharon Guthrie wrote:a >  [snip] > N >         Fred, I agree with you that hopefully after all the dust settles andN > VMS is ported to Itanium, it will be just as terrific as it has always been.L > But Compaq/HP STILL needs to get their rears in gear to market/promote it.Q > It's *almost* too late.  Right now, today, we have one hell of a negative image-# > to counter.  It's very, very sad.n >   4 Say by calling VMS a grown up operating system, for  serious computing.  - As distinct from Windows which is a beginners-* system, whose main applications are games.. Remember that Microsoft tv advert which showed0 the 50 year secretary fooling her boss by moving
 the mouse?  4 Providing Itanium computers are significantly faster4 than the toys sold to the general public they can be- marketed as the grownup pc.  This permits VMSa6 computers to be shown doing big jobs like calculating 5 the payroll for the entire US Army or something risky  like landing aircraft.   Example slogansy  6 VMS the serious operating system for serious computers doing serious tasks.  4 When computer failure means disaster, you are ready  for VMS. -- n7 _______________________________________________________l+ Andrew Swallow (7605) 2225   Cowes site, UKh andrew.swallow@baesystems.com    ------------------------------  # Date: Tue, 11 Dec 2001 23:07:57 GMTf* From: "Bill Todd" <billtodd@metrocast.net>+ Subject: Re: HP Foundations - let them know0B Message-ID: <hlwR7.221910$uB.24218578@bin3.nnrp.aus1.giganews.com>  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KBR6PPLX5Q9138XQ@sysdev.deutsche-boerse.com...r   ...]  L > > Fred, I agree with you that hopefully after all the dust settles and VMSL > > is ported to Itanium, it will be just as terrific as it has always been.J > > But Compaq/HP STILL needs to get their rears in gear to market/promoteH > > it. It's *almost* too late.  Right now, today, we have one hell of a4 > > negative image to counter.  It's very, very sad. >>F > I think Fred is right when it comes to keeping VMS about where it isI > now.  Despite the doom mongerers, the VMS market is about the same size  > as it was 10 years ago.n  H Is it?  I would have been inclined to agree with that statement any timeL prior to June 25th, but do you have any reason to believe that the situation( hasn't changed significantly since then?  G The Q3 financials suggest that Alpha revenue, which had been relativelyaI unaffected by the 'slowdown' (or whatever you call it) through Q2, took a L major dive in Q3.  Do you have some information to the contrary, or at least5 to indicate that VMS sales weren't part of that dive?   C Assuming that the Alpha cancellation didn't affect anything much iscI certainly what Compaq would like people to believe but is contradicted bydJ all evidence (both financial and anecdotal) that I'm aware of.  Please letL us know of any evidence you have to the contrary, or at least reconcile your8 statement above with the evidence others have presented.   Thanks,a   - bill   ------------------------------  % Date: Tue, 11 Dec 2001 18:54:19 -0500e- From: JF Mezei <jfmezei.spamnot@videotron.ca> + Subject: Re: HP Foundations - let them knowe, Message-ID: <3C169C96.55404CC2@videotron.ca>   Bill Todd wrote:I > The Q3 financials suggest that Alpha revenue, which had been relativelybK > unaffected by the 'slowdown' (or whatever you call it) through Q2, took a  > major dive in Q3.   M Not sure about that. All I remember is a statement that NSK sales held up but K the rest of enterprise computing didn't fare so well. So yes, it would lead M one to conclude that the Digital part went down, but it could be that it went-L down just a bit while the wintel crap servers went down big time, or perhapsM the reverve with the Digital business having tanked big time due to the alphaiS murder and the wintel servers just on its reasonable decline that matches industry.   N Lets not forget that Capellas is an accountant. So his creative energies don'tM go towards creating new systems or architectures, it goes to creative ways of 4 presenting numbers to say what you want them to say.  N As a result, it isn't whether VMS s doing well or not that is the message. TheL message is that Compaq management go through great lengths not to reveal how
 VMS is doing.   V And there is a clear message when a company takes such steps to hide/ignore a product.   ------------------------------  # Date: Wed, 12 Dec 2001 03:12:27 GMTu1 From: "David J. Dachtera" <djesys.nospam@fsi.net>t+ Subject: Re: HP Foundations - let them know ' Message-ID: <3C16CB56.4F4ABA4A@fsi.net>a   Fred Kleinsorge wrote: > C > David J. Dachtera wrote in message <3C157D24.36451DCD@fsi.net>... 
 > > [snip]K > >Bill and the others like him probably have a perceived (by them) lack ofmH > >anything to lose since they've likely written off VMS. So, they don't> > >have to worry about leaving a sour taste in anyone's mouth. > >sF > >I'm not far behind them - I'm just too stupid to know when to quit! > >oK > >> That isn't to say that there are not people here who are concerned, or  > evenK > >> unhappy about recent events.  However, I continue to get private mail,u > fromL > >> those who do not want to be added to Bill's "anyone who disagree's with > me= > >> is an idiot" list - supporting OpenVMS, and it's future.k > >mB > >If you're privy to information that has escaped the media, thisI > >newsgroup, etc., bravo for you. We've seen little - if anything - thato+ > >purports even the remotest hope for VMS.  > >g > G > What?  That a few readers in this forum write me directly, instead of M > wanting to engage in a fruitless battle against Bill and the wrecking crew?i> > Should I then place their private mail (even redacted) here?  % How does that fit in? All I said was:   B > >If you're privy to information that has escaped the media, thisI > >newsgroup, etc., bravo for you. We've seen little - if anything - that + > >purports even the remotest hope for VMS.t  G > What exactly does "even the remotest hope for VMS" mean?  We're stilleN > selling VMS.  We're still selling Alphas.  We eventually will be selling VMS
 > on Itanium.r  A I would not be surprised to find that some scumbag on Titanic was-C selling life-jackets at black market prices right up until the last,D moments before it sank. That you're still selling it proves nothing,G without stating (and proving!) whether the numbers and volume sales aredD trending upward or downward. Then, the numbers speak for themselves.  > >  Have you heard from some difinitive, non-speculative source > that VMS is going away?o  G I can hear and I can read. I trust my senses and my instincts. Hard-wong- lessons learned in the School of Hard Knocks.p  H If I hold a hammer above the floor and release it, I do not need to have3 heard it fall to know that it has, in fact, fallen.   E I hear and read much about VMS defections. I do not need to hear that ? they continue in order to know that they do, in fact, continue.   C > >Recent events have done nothing and offerred less to abate that:t > >y. > >o Major hurdles to the merger being erected > N > What does this have to do with the price of tea in China?  I think VMS would* > be stronger if the merger goes through.   G ...but only if the resulting company were to see it as an indispensableiC asset. Experience to date casts serious doubt on such a likelihood.l  # > But at the same time, I don't seee: > where VMS has a EOL strategy if the merger fails either.  / Alpha had no EOL strategy, either. Meaningless.r  eJ > >o Alphacide, no viable IA64 = no where for VMS to go (market perceptionJ > >= market reality = our reality = no jobs, no sales, 86 on VMS, over and	 > >OUT!).y > > > Smoking the same stuff as Bill?  Why is Itanium not viable?   0 See recent postings regarding Intel "sightings".  
 > PerformancetN > predictions from a flounder?  Who's market perception are you talking about?  A The one found in the responses to the aforementioned "sightings".S  L > I've presented the OpenVMS roadmap to a number of customers - they did not2 > have any perception that Itanium was not viable.  G No doubt, you showed them nothing about the aforementioned "sightings".m   >  We are still continuing too > sell VMS.o  : ...and I'm continuing to nurse my sprained ankle. So what?  J > >Again, if you're privy to anything that gives hope of a future for VMS,H > >now is the time to speak up. Your employer and your job are at stake! > >  > G > It is?  I haven't been presented any evidence that VMS doesn't have a 
 > future.   , I'd check out that river in Egypt (de Nile).  B > We have turned a declining business around, and continue to make > forward progress.   H You have? Evidence please? (Hint: Compaq's stock price is still in tank,/ though it is near the pre-announcement levels.)L  : > We have a plan to get to a new architecture base for the
 > future.   F Is this more Intel vapor-ware or is it a currently shippable, saleable product?  D > We will also continue to support existing machines for a very longM > time with new versions of VMS, and new features.  Our project plans include-I > not just new HW support, and Itanium porting, but extensive performancelG > enhancement work, file system work, UNIX compatabilty work, and more.a  G Good for you. I just hope the defections to platforms that don't have a2A known (sort of) EOL don't pour too much cold water on that party.u  	 > >[snip]SE > >> In the middle of a industry wide slump in system sales, he woulda > attributeh9 > >> all of our problems to the decision regarding Alpha.  > >e> > >Well, not *ALL*, but by far a great, overwhelming majority. > >e > L > Not quite sure I agree with this for OpenVMS.  We still have strong demandM > for OpenVMS Alpha.  Along with committments from large customers, ISV's ande > partners for Itanium support.j  F I'm sure you're aware that the word "commitment" is about as valueless/ as used toilet paper where Compaq is concerned.s  oD > >Oh sure, you'll likely see sales now just like VAXcide(?) - folksJ > >stocking up now on what they can get while they can get it. After that,G > >it'll be like racing at full throttle off the white Cliffs of Dover.  > >e >  > Crystal ball gazing eh?    Speaking from experience.c  1 > Why are you soooo sure that Itanium will not bee	 > viable?a  E Who ever said it won't be? The point is it currently is *NOT* viable.I7 Whether or not it ever will be is entirely up to Intel.   E You might want to rent "The Hunt for Red October" and fast-forward toIH the scene where Capt. Bart Mancuso offers Jones's side arm to Jack Ryan.E Ryan says, "He's defecting.". Bart says, "Are you willing to bet yourn life on that?"  C >  I remember a lot of people saying how the x86 was just a toy andcN > would never be competetive.  Intel can throw a lot of money and pretty smart > people at a problem.  , Then, they'd better shit or get off the pot.  - > >> On the other hand, I1J > >> continue to see the internal large "wins" messages for new VMS sales, > thatH > >> would seem to counter that (and no, we do not make such wins public	 > without1$ > >> the customer wishing it to be). > >nK > >How 'bout seeing if you can at least get permission to say publicly, "ontI > >xx-xxx-xxxx, we sold a total of $nn,nnn,nnn worth of (Alpha, StgWorks, A > >etc.) to y customer(s)"? ("n" and "y" are integers, of course)M > >  > N > You are talking to the wrong guppy.  I do not, and never want, permission to > release such information.u  ? Then who should be "the one"? (Welcome to the real world, Neo!)l   M > >> I have every reason to believe that OpenVMS will emerge from this in the^; > >> best shape and position that it has been in for years.e > >nJ > >Do you also have inside info. from Intel as to when they'll FINALLY(!!)I > >have a viable, saleable IA64/IPF CPU for building into OpenVMS-capableo > >systems?t > >a > - > I believe that even at todays performance, e  E Performance is not the issue - accuracy and error-free processing aree
 the issue.  # > and Itanium running OpenVMS would.D > be a viable solution for many customers - depending on the price.   D DAMN! There's the AFFORDABILITY thing again! Bun of a Sucking Fitch!  	 > Not all.M > systems have to have the bleeding edge performance.  Heck, SUN would be outtL > of business if that was the case.  I believe that within a few years, IA64F > will start getting performance numbers that are competetive with theN > high-end RISC boxes.  I also believe that Intel can drive the price on these > way down.e  D Again, to the hell fires with performance, if we can't get accuracy.  k > >> We will have thetH > >> same robust and trusted O/S, and we will have it on a platform that > shouldL > >> provide competetive performance, with lower costs.  We will continue toN > >> support VAX and Alpha.  My direct contact with several customers has beenH > >> very positive.  The indirect evidence I have from others who are in > direct6 > >> contact with customers and ISVs is also positive. > > K > >As much detail as you can disclose in regard to the foregoing would be a  > >*VERY* *LARGE* help!a > >  > I > Come on now.  Would you like it if I disclosed confidential information  > regarding *your* plans?   G C'mon, damnit, use your head! We're looking for sales volume, plans foruH additional volume, shit like that! No one gives flying fuck WHAT they'reA doing or who is doing it. We want to know what the meaning is forsE OpenVMS! Try thinking like an investor, or get someone to help you ifoD you can't. Regardless of what the customer is doing with the systemsB they buy, what does that sale mean to the stock-holder? What's the prospect for future sales?  F See? You can come up with *ALL* *KINDS* of positive info. without even# the hint of breaching a confidence!   / > I will say that last month I had to visit tworN > largish customers, each who have large investments in OpenVMS, in Alpha, andK > who still have a few VAXes around.  Both of them were interested in A) is K > there a plan, B) what is the timing of releases/availability, C) what waskN > the story about cluster interoperability and compatability of interconnects.= > Neither was concerned in the least about "Itanium" itself.    H All I have to care about is how long we can keep our Alphas going beforeD we have to face the A64 -> IA64 migration. Until Intel has a viable,8 shippable IPF product, I don't give two shits about IPF!   > One recently: > signed a new contract for new systems for it's customer.  F See???!!! You just released positive information!!! You *CAN* do it!!!C You just didn't *KNOW* you could! Three cheers and a tiger for you!   F Now: repetition is the mother of skill. So, what other tidbits can you	 give us? o  > You just discovered a new muscle. Exercise it and build it up!  	 > >[snip]nE > >Right now, Compaq is in a dangerously vulnerable position, with no I > >margin for error. One wrong word can destroy any hope there may be forc@ > >the future of Compaq, VMS, etc. The spin-meisters remain MIA. > >  > # > Not quite sure I understand this.    O.k. Let's review:  : o Alpha is dead. No replacement is visible on the horizon.  C o Current VMS customers see this, and wonder where they can go fromrH OpenVMS-Alpha in the short to mid term. Now, remember, the confused mindA always says, "No". Will they stay with VMS? Can they trust Compaq. "commitments"?   WWYD? (What Would You Do?)  
 Ask yourself:wC o Would *YOU* put *YOUR* stockholder's "eggs" in Compaq's "basket",u knowing what we know today?0  G o Is it reasonable to expect other business leaders to think as you do?,  # o How does this portend for Compaq?a  K > >I'm still in denial about the death of VMS, also. I'd love to share your I > >optimisitc assessment. However, with no evidence available directly toS> > >me, optimism is becoming more and more difficult every day. > >aH > >*ANY* positive *EVIDENCE* will go further than sparring verbally with > >*ANY*one here.o > >c > K > Look.  If Compaq really wanted, as the consiracy theorist who lead you to-G > believe, OpenVMS to "go away" they had a perfect opportunity when thesL > Itanium strategy was announced.  It would have been "easy" for them to sayJ > "We will continue to execute the Alpha roadmap for OpenVMS, but will notL > port OpenVMS to Itanium.  We will support OpenVMS on VAX and Alpha as longI > as you need them".  In fact, that was what *I* expected would happen iflN > Alpha was ever retired.  Much to *my* suprise, what we got was a committment. > from the company to port OpenVMS to Itanium.  @ If you still put any stock in Compaq's "commitments", you should- seriously consider having yourself committed.n   L > Here we are months later and what I see is that we have hired engineers to > help with the port,   B What happens to them afterward? (Can you say "job security"? No, I didn't think you would.)  9 > meaning that the company did increase our headcount and M > $$ budget.  I see engineers comming off existing projects and starting fulluL > time on the design and implementation.  I'm seeing real designs, replacingJ > investigations.  I see the compilers start to show up.  We now have bothN > Compaq Itanium servers, as well and HP Itanium workstations on the floor.  IK > am now running a regular "booting" meeting (since I'm project leading them > initial boot). > M > As a member of the technical lead staff, I see the plans for new projects -_M > for instance a new file system - actually starting to move forward.  Or thebK > performance work on disk and network IO, as well as lock performance, and: > NUMA performance.l > M > I see weekly customer win reports, where millions of dollars of business iss1 > being closed.  Old customers and NEW customers.g  8 Let the world see that - and watch the numbers multiply!  c* > I see us lining up the ISVs for Itanium. > - > So where in this should I fit "pessimism"? d  E Ask that question again the next time an IPF deadline at Intel slips. G Ask that question again when the postings appear here about VMS systems D being replaced due to uncertainty about the future of IPF, and otherG factors. Ask that question again the next time there are "sightings" of  anomalies in IPF.i  H *THAT* is what the world sees. "Customer 'wins'" are what you "insiders"B see. You're looking at the VMS world through Compaq's rose-colored	 glasses.    @ Do you remember a play, I think it was on Broadway (or maybe offF Broadway) called, "The Fantastiks"? Remember the mask? Starting to get the picture?   >  Because Bill is unhappy?nJ > Because there won't be an EV8?  Because a few people do not believe that) > Intel will be able to make Itanium fly?e  F IPF is a question of when, not if. We know this. We also know that IPFE is - and remains - vaporware. It currently is not a viable, shippableoD product where OpenVMS-level quality is required, expected, demanded.  1 Regardless of Bill's issue, *THAT* is *MY* issue.c  ' > Someone recently shared this with me:e > J >     Talking to Bill is like trying to teach a pig to sing.  You just get  > frustrated, and annoy the pig. > D > I can't teach Bill to sing.  The only thing that will get close toI > convincing those who probably were in a precarious position with VMS totJ > begin with that *VMS* will continue to be viable, is to execute to plan.L > Face it, no words here will really do it.  Nor would a wholesale change ofJ > management convince anyone that the new management is different than the > current management.   G Better the devil you know than the devil you don't, eh? Granted, it's ahE crap shoot at best. However, if there's the chance of getting someoneoI who has a better grasp of what its all about, then I'd say, "Go for it!" .  H Sure things could get worse. They could also get better, but not withoutF some kind of change. Keeping things the same and expecting the results5 to change is one of the many definitions of insanity.t  7 > And the way we convince both customers and management H > that VMS is viable is to tell them what we'll do, and execute to plan.  0 There's that whole COMMITMENT thing again! SHIT!  G To quote a local pastor, "a reputation is not built on what you PLAN toe do".   >  Maket > money, and grow the business.s  H ...which is not done by shooting yourself in the foot until it ends justE below your shoulder. I think the Q are down to just a couple of hairsh( left at this point, or is that a toupee?   --   David J. Dachterah dba DJE Systems. http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 11 Dec 2001 23:47:07 -0600+ From: young_r@encompasserve.org (Rob Young)-+ Subject: Re: HP Foundations - let them know 3 Message-ID: <oVUEFZT1vr7I@eisner.encompasserve.org>u  [ In article <3C16CB56.4F4ABA4A@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:e  ? >> Smoking the same stuff as Bill?  Why is Itanium not viable? 3 > 2 > See recent postings regarding Intel "sightings". >  >> PerformanceO >> predictions from a flounder?  Who's market perception are you talking about?t > C > The one found in the responses to the aforementioned "sightings".n >   = 	Merced is Dead.  Has been Dead.  Never had a chance.  But asp 	Paul Demone points out:   			Merced != IA64   ? 	The architecture lives on and they will actually sell McKinleyn 	in reasonable volumes.   ; http://news.cnet.com/news/0-1003-200-8145128.html?tag=tp_pr   N With McKinley, sales are expected to begin picking up. By the third quarter ofJ next year, McCarron predicts that Intel could be selling a "couple hundred thousand (chips) a quarter." t  L But the expense involved in making McKinley--along with other factors--could. keep sales of the upcoming chip moderate too.   N Kevin Krewell, an analyst at MicroDesign Resources, predicted that the companyG will sell around 100,000 Itanium chips per quarter by the end of 2002. s  / 	The Madison shrink will further boost numbers.c  M >> I've presented the OpenVMS roadmap to a number of customers - they did nots3 >> have any perception that Itanium was not viable.p > I > No doubt, you showed them nothing about the aforementioned "sightings".n >   @ 	Don't be too alarmed by "sightings" on a Dead chip... it means 	 	nothing.   C >> We have turned a declining business around, and continue to makee >> forward progress. s > J > You have? Evidence please? (Hint: Compaq's stock price is still in tank,1 > though it is near the pre-announcement levels.)  >   ? 	He didn't say Compaq.  He said "a declining business", judginge? 	from the context that wouldn't be too difficult to take a wildu$ 	guess that he was referring to VMS.  ; >> We have a plan to get to a new architecture base for the, >> future. s > H > Is this more Intel vapor-ware or is it a currently shippable, saleable
 > product? >   A 	Future plans imply products that may not exist, hope that helps.a     >> tM >> Not quite sure I agree with this for OpenVMS.  We still have strong demand N >> for OpenVMS Alpha.  Along with committments from large customers, ISV's and  >> partners for Itanium support. > H > I'm sure you're aware that the word "commitment" is about as valueless1 > as used toilet paper where Compaq is concerned.  >  n  9 	Overlooking his statement that "[they] still have strongtB 	demand for OpenVMS Alpha".  Why not FUD that up?  Is he bluffing?8 	Just rose colored glasses?  No, let's focus on the wordB 	"committment" as their "committments" from customers are suspect?7 	These aren't backed by contracts?  How would you know?     2 >> Why are you soooo sure that Itanium will not be
 >> viable? > G > Who ever said it won't be? The point is it currently is *NOT* viable.a9 > Whether or not it ever will be is entirely up to Intel.o >   " 	It will be.  Give it enough time.  D >>  I remember a lot of people saying how the x86 was just a toy andO >> would never be competetive.  Intel can throw a lot of money and pretty smart  >> people at a problem.h > . > Then, they'd better shit or get off the pot. >     ? 	They have only started to spend the money.  If they can garnerrF 	95% of server CPU sales, they would probably be successful.  I figure? 	they probably have a pretty high percentage now with X86, IA64i 	is icing on the cake.   >> >> On the other hand, IK >> >> continue to see the internal large "wins" messages for new VMS sales,v >> that I >> >> would seem to counter that (and no, we do not make such wins public 
 >> without% >> >> the customer wishing it to be).a >> >L >> >How 'bout seeing if you can at least get permission to say publicly, "onJ >> >xx-xxx-xxxx, we sold a total of $nn,nnn,nnn worth of (Alpha, StgWorks,B >> >etc.) to y customer(s)"? ("n" and "y" are integers, of course) >> > >> eO >> You are talking to the wrong guppy.  I do not, and never want, permission toh >> release such information. > A > Then who should be "the one"? (Welcome to the real world, Neo!)  >  r  @ 	You can't expect that.  Some of their large wins are governmentC 	and military... don't expect anyone to be bragging those up.  JustL 	the way it works.  N >> >> I have every reason to believe that OpenVMS will emerge from this in the< >> >> best shape and position that it has been in for years. >> >K >> >Do you also have inside info. from Intel as to when they'll FINALLY(!!) J >> >have a viable, saleable IA64/IPF CPU for building into OpenVMS-capable >> >systems? >> > >> m. >> I believe that even at todays performance,  > G > Performance is not the issue - accuracy and error-free processing areu > the issue. >   ? 	Yep.  Give them one more go round and they will have it right.'< 	You can bet the verification runs on McKinley will be more ( 	thorough.  They have Merced as a guide.   > E > o Current VMS customers see this, and wonder where they can go fromiJ > OpenVMS-Alpha in the short to mid term. Now, remember, the confused mindC > always says, "No". Will they stay with VMS? Can they trust CompaqV > "commitments"? >   ; 	Come on... it is hard enough to peal those well performingl< 	Vaxes from some folks fingers.  We are mostly crunching I/O@ 	out here... several spins on EV7 will carry most business needsC 	except for explosive growth.  Maybe you envision clusters grindinguC 	to a halt and no Alphas to be found anywhere?  When is that?  2008k4 	or 2009?  Why haven't you begun your IPF migration?   > WWYD? (What Would You Do?)  ( 	Plan appropriately.  What would you do?   >  > Ask yourself: E > o Would *YOU* put *YOUR* stockholder's "eggs" in Compaq's "basket",  > knowing what we know today?t >   < 	Sure... if they are still around in 2008.  I don't care who
 	owns VMS.  I > o Is it reasonable to expect other business leaders to think as you do?i   	Yes.  Solutions is solutions.   > % > o How does this portend for Compaq?r >   
 	Not sure.  L >> >I'm still in denial about the death of VMS, also. I'd love to share yourJ >> >optimisitc assessment. However, with no evidence available directly to? >> >me, optimism is becoming more and more difficult every day.m >> >I >> >*ANY* positive *EVIDENCE* will go further than sparring verbally with. >> >*ANY*one here. >> > >>  L >> Look.  If Compaq really wanted, as the consiracy theorist who lead you toH >> believe, OpenVMS to "go away" they had a perfect opportunity when theM >> Itanium strategy was announced.  It would have been "easy" for them to saysK >> "We will continue to execute the Alpha roadmap for OpenVMS, but will noteM >> port OpenVMS to Itanium.  We will support OpenVMS on VAX and Alpha as longwJ >> as you need them".  In fact, that was what *I* expected would happen ifO >> Alpha was ever retired.  Much to *my* suprise, what we got was a committmentd/ >> from the company to port OpenVMS to Itanium.a > B > If you still put any stock in Compaq's "commitments", you should/ > seriously consider having yourself committed.O >  S  B 	No.  He probably knows a few more things than we do.  Like signedE 	longterm contracts to very large customers that are binding.  Thingse" 	the owner(s) of VMS will inherit.  M >> Here we are months later and what I see is that we have hired engineers toe >> help with the port, > D > What happens to them afterward? (Can you say "job security"? No, I > didn't think you would.) >   B 	Talk to Keith Parris... or look at his resume online.  He was oneB 	of many more that worked on VAX->Alpha as that port required many? 	more workers.  Perhaps others that actually did the work would @ 	care to comment... but several in this forum and elsewhere have? 	pointed out that this port should be fairly "easy".  Of courseb? 	guys traipsing through the console (like Fred) have one of them; 	harder tasks (not to take anything away from anyone else).o  : >> meaning that the company did increase our headcount andN >> $$ budget.  I see engineers comming off existing projects and starting fullM >> time on the design and implementation.  I'm seeing real designs, replacing K >> investigations.  I see the compilers start to show up.  We now have bothiO >> Compaq Itanium servers, as well and HP Itanium workstations on the floor.  IaL >> am now running a regular "booting" meeting (since I'm project leading the >> initial boot).  >> rN >> As a member of the technical lead staff, I see the plans for new projects -N >> for instance a new file system - actually starting to move forward.  Or theL >> performance work on disk and network IO, as well as lock performance, and >> NUMA performance. >>  N >> I see weekly customer win reports, where millions of dollars of business is2 >> being closed.  Old customers and NEW customers. > : > Let the world see that - and watch the numbers multiply! >   + >> I see us lining up the ISVs for Itanium.  >> M. >> So where in this should I fit "pessimism"?  > G > Ask that question again the next time an IPF deadline at Intel slips.eI > Ask that question again when the postings appear here about VMS systemseF > being replaced due to uncertainty about the future of IPF, and otherI > factors. Ask that question again the next time there are "sightings" of  > anomalies in IPF.n >   D 	Who cares about the deadline?  They have several THOUSAND engineers 	working on IPF.  ; 	They have design teams on IPF stacked 5-8 deep.  Future ofrF 	IPF?  Come on... you can generate better FUD than that.  "Sightings"? 	Come on... weak... very weak.    J > *THAT* is what the world sees. "Customer 'wins'" are what you "insiders"D > see. You're looking at the VMS world through Compaq's rose-colored > glasses. a > < 	No.  He is talking dollars and cents.  That puts a shine on
 	most things.I   >>  Because Bill is unhappy?K >> Because there won't be an EV8?  Because a few people do not believe thate* >> Intel will be able to make Itanium fly? > H > IPF is a question of when, not if. We know this. We also know that IPFG > is - and remains - vaporware. It currently is not a viable, shippabletF > product where OpenVMS-level quality is required, expected, demanded. > 3 > Regardless of Bill's issue, *THAT* is *MY* issue.  >   B 	Well the on-chip availability features (not quite fault tolerant)= 	will make it a reliable chip.  Those sightings will go away.   8 >> And the way we convince both customers and managementI >> that VMS is viable is to tell them what we'll do, and execute to plan.  > 2 > There's that whole COMMITMENT thing again! SHIT! >   : 	Yeah... probably on the smart customer end backed up withD 	signed contracts that their legal department spent months crafting.   >>  Make  >> money, and grow the business. > J > ...which is not done by shooting yourself in the foot until it ends justG > below your shoulder. I think the Q are down to just a couple of hairso* > left at this point, or is that a toupee? >   A 	But if currently they are making money and growing the business,i! 	then you have to give them that.s   				Robo   ------------------------------  % Date: Wed, 12 Dec 2001 07:24:50 +0100i1 From: John McLean <mcleanj@swissonline.delete.ch>s+ Subject: Re: HP Foundations - let them know,5 Message-ID: <3C16F832.7DE85525@swissonline.delete.ch>s   Bill Todd wrote: >  .... > I > The Q3 financials suggest that Alpha revenue, which had been relativelyrK > unaffected by the 'slowdown' (or whatever you call it) through Q2, took aaN > major dive in Q3.  Do you have some information to the contrary, or at least7 > to indicate that VMS sales weren't part of that dive?a > E > Assuming that the Alpha cancellation didn't affect anything much iscK > certainly what Compaq would like people to believe but is contradicted bySL > all evidence (both financial and anecdotal) that I'm aware of.  Please letN > us know of any evidence you have to the contrary, or at least reconcile your: > statement above with the evidence others have presented.  H This is a tough question to answer because of Compaq's product groupings for their accounting segments.  C What we do know is that Revenue and Income were sliding through the F first 2 quarters and dropped even further in the 3rd.  The figures (inC millions) were Q1:R=$2908, I=$132,  Q2:R=$2711, I=$74,  Q3:R=$2376,o I=-$104.  H From the revenue figures the market does seem to have been contracting. G As to why this should be I can only speculate that the dot-com collapsepD hit the Unix server business particularly hard but the collapse alsoE triggered a slump in the IT market as a whole.  With Year 2000 issueseH then the dot-com boom the whole IT industry was doing wonderful businessD and companies were trying to sell as much gear as they could even if0 they did have a suspicion that it couldn't last.  F (It is interesting from the above figures that a drop in revenue in Q2G of about $200 million meant a drop in income of $58 million, then a 3rdlA quarter revenue fall of $335 million meant a revenue fall of $178dG million.  The ratios of the respective falls are nowhere near equal and E clearly there's a certain revenue figure which needs to be met to paye the fixed costs.)s  D When the general economy was dropping I am sure there were plenty ofH companies who were failing (and releasing gear onto the 2nd hand market)E and others who have deferred purchases and are trying to make do witho what they have.t  C I've already mentioned that the dot-com collapse was probably a bigpF factor in the unix server sales slump but each of the products in thisE area has its own charateristics and these probably had some effect ont  the impact on each product line.  H It's interesting that the expandability of VMS may have been a factor inG its financial returns during this period.  Sites could make "component"mF purchases to expand their current systems and thus reduce the need for big outlays.  G I don't know the big Proliant servers at all well but clustering is notnH a strong point and I believe their expandability is not as good as VMS. F The other thing to bear in mind is that they are relatively new on theG market and it would appear that a customer would have to decide if theywH wanted to purchase the entire system or not.  Maybe purchases were made," or maybe these have been deferred.  E I think that all we can do in this area is speculate and while CompaqsH will have figures for each product line I wonder if they have any betterD idea of the real motivations of customers.  If they don't understandF these motivations then they won't know how to best position themselves for future sales.T   Just my thoughts...      John McLeano   ------------------------------  # Date: Wed, 12 Dec 2001 04:39:41 GMT 5 From: "Ken and Kelley Coleman" <knkcoleman@attbi.com> " Subject: Re: Info-VAX@Mvb.Saic.Com. Message-ID: <hcBR7.36079$ER5.422102@rwcrnsc52>  I I apologize, Mr. Sture. I really meant no harm at all by it. Bad American ' humor on my part. Have a wonderful day.r   Kelley  5 "Paul Sture" <paul.sture@bluewin.ch> wrote in message ' news:VA.000004e6.e7075636@bluewin.ch...hF > In article <5jgR7.28855$wL4.88207@rwcrnsc51>, Ken and Kelley Coleman > wrote:B > > Well, we voted and it turned out that you ARE the weakest Link > >t
 > > Good bye!t > >o5 > > (just kidding, of course...I haven't a clue why.)p > >gC > Which gets my vote for the sh*ttiest message I've seen here for a  > while. Totally uncalled for. > ___e > Paul Sture
 > SwitzerlandS >    ------------------------------  % Date: Tue, 11 Dec 2001 14:24:40 -0500w) From: "Mike Foley" <mikiefoley@yahoo.com>o' Subject: Re: Inquirer: OpenVMS on DS20Lu/ Message-ID: <u1cn61jitdj129@corp.supernews.com>e  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messages' news:MsoR7.35513$Yy.383191@rwcrnsc53... J > Pure conjecture, but I have a vague recollection that the DS20L is based onK > a third-party (Samsung) motherboard, not a CPQ-designed board. This mightp4 > have something to do with the lack of VMS support.  H I believe it's based on the API CS20 design, though it may have recievedG "updating" when it moved to Compaq. If so, it's based on the UP2000 APIbK motherboard. ie: Tsunami-based. However, it probably has a southbridge thatvG VMS knows nothing about and ethernet controllers that VMS knows nothing I about. The CS20 has/had two built-in ethernet controllers, Intel I think.   K It doesn't surprise me that the DS20L isn't supported on VMS. You don't seenH VMS running on a UP1000 either. Qualifying a platform for VMS isn't likeC releasing a new update to Linux after all. There's a tried and true 
 proceedureK for supporting new hardware. The VMS group has to be in on the design cycleaJ of the system in order to time support for it. The VMS group was NOT in onG the design cycle of API's CS20. It was developed to run Linux and MAYBE F Tru64 on a good day. After all, Tru64 and VMS are Compaq products, not  sold or supported by API.  L As Fred K. said, if your customers decided they had to have x00's of DS20L'sK running VMS, I'm sure the product managers in ZK would stand up and notice.(     --   mike Former VMS Group system manageri* Former technical marketing engineer at API   ------------------------------  % Date: Tue, 11 Dec 2001 14:28:18 -0500 2 From: "Sue Skonetski" <susan.skonetski@compaq.com>' Subject: Re: Inquirer: OpenVMS on DS20Lm2 Message-ID: <Z5tR7.440$BK1.13946@news.cpqcorp.net>   This is an unannounced product.e   sue     : "Chris Bardell" <tessier-ashpool@usa.net> wrote in message7 news:9f261edc.0112110305.242e3732@posting.google.com...o > Anyone got any views on this?h >d) > http://www.theinquirer.net/11120107.htmh >g7 > Don't believe the DS20L is even a current system (seed$ > http://207.18.199.3/alphaserver/ ) >a% > Info, gossip, conjecture, please...a   ------------------------------  % Date: Tue, 11 Dec 2001 14:35:38 -0500s- From: JF Mezei <jfmezei.spamnot@videotron.ca>,' Subject: Re: Inquirer: OpenVMS on DS20Lt* Message-ID: <3C166006.6FF044@videotron.ca>  + I have no idea if the DS20L is noew or old.h  I But having the designation "DS20" would make it a Compaq branded product,r	 correct ?   N If it is different enough from other Alphas that it requires too much work forI certification on VMS,  wouldn't it also require expensive certication forb Tru64 support ?   N If it is a new product, who is the bozo who designed that box so that it wouldH be just different enough that no Compaq OS would run on it because theirK certification would be too expensive ? When you put that in the end-of-lifeV6 context of Alpha, this makes it look even more stupid.   ------------------------------  % Date: Tue, 11 Dec 2001 15:43:54 -0500o- From: JF Mezei <jfmezei.spamnot@videotron.ca> ' Subject: Re: Inquirer: OpenVMS on DS20Lt+ Message-ID: <3C167001.F1284F0@videotron.ca>    Fred Kleinsorge wrote:H > will qualify it.  A low-profile, rackmount pretty much developed for a> > single UNIX customer isn't something I will lose sleep over.  H Then why doesn't Compaq simply say that this was a custom designed/builtG system for a specific customer instead of giving it a product name thatt) implies it is a standard Alpha computer ?T   ------------------------------  # Date: Tue, 11 Dec 2001 21:07:05 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>' Subject: Re: Inquirer: OpenVMS on DS20L + Message-ID: <ZzuR7.8902$7y.79115@rwcrnsc54>.  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message% news:3C167001.F1284F0@videotron.ca...e > Fred Kleinsorge wrote:J > > will qualify it.  A low-profile, rackmount pretty much developed for a@ > > single UNIX customer isn't something I will lose sleep over. >eJ > Then why doesn't Compaq simply say that this was a custom designed/builtI > system for a specific customer instead of giving it a product name thate+ > implies it is a standard Alpha computer ?v  H Who knows, they might do that. At least one Compaq person has weighed inJ with the observation that the product is an Unannounced Product. Hence the5 firm has a little wiggle room if they want to use it!y   ------------------------------  + Date: Wed, 12 Dec 2001 00:03:59 +0000 (UTC)S From: david20@alpha1.mdx.ac.uk' Subject: Re: Inquirer: OpenVMS on DS20Ls+ Message-ID: <9v66tf$4h8$1@aquila.mdx.ac.uk>n  j In article <bmsR7.431$BK1.13769@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:I >Puleese.  There have been any number of systems that were not officially E >supported by OpenVMS.  Really.  And at least one that VMS refused to 	 >support.e  M Yes all the white box stuff. The problem is that we all thought we'd won thislM argument and Compaq had just promised that VMS would run on all the new Alphah3 boxes. Looks like another easily broken commitment.a  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Tue, 11 Dec 2001 19:22:55 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca>a' Subject: Re: Inquirer: OpenVMS on DS20Lt+ Message-ID: <3C16A348.D2AA3E7@videotron.ca>n   david20@alpha1.mdx.ac.uk wrote:GO > Yes all the white box stuff. The problem is that we all thought we'd won thiscO > argument and Compaq had just promised that VMS would run on all the new Alpha 5 > boxes. Looks like another easily broken commitment.e  N What I don't quite understand is that if this was really a custom made box forI a single customer, how come Compaq would go through the trouble of makingC; public the fact that it would not support VMS on that box ?    ------------------------------  % Date: Tue, 11 Dec 2001 14:06:43 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca> < Subject: Re: It you say it often enough does it become fact?+ Message-ID: <3C165940.19990EC@videotron.ca>t   Jeff Killeen wrote:tN > highlights the numbers from storage and services because they are doing veryL > well in an attempt to justify the underlying strengths of Compaq.  If OVMSD > was this great source of profit as claimed in c.o.v. then it makesN > absolutely no business sense for Compaq not to also highlight those numbers.' > It leads to one of two conclusions....  J Remember back in the good bad days of Digital when, quarter after quarter,M things were getting worse as they increased their migrate-FROM-VMS strategy ? J At one point, they were bleeding so bad that they realised that it was tooM soon to kill VMS because it was their sole source of profit. Their "affinity".E program was quietly toned down to help save what was left of Digital.e    I > 1) The black helicopter theory - Compaq management is so pro some other K > technology or so against OVMS they have ceased being rational businessman N > and instead have allowed a emotional dislike of OVMS to take over and act inB > manner contrary to their personal interests and the interests of > shareholders.r   you should read the above as:v  M Compaq management believes that there is no growth potential for VMS and that N it should just milk it for its profits until the systems it believes will growK into the enterprise market materialise. They see VMS as a stop-gap measurte  until NT can do the job.  D There is no need for black-helicopter theory when the management areL brainwashed into thinking that NT willr ule the world and that it is logical, to position Compaq to be ready when it does.  K Did you accuse IBM of being "black helicopter" back when it would brainwashaN its customers into thinking that only MVS could handle serious work, and wouldN tell senior VPs of a bank that a volume shadowing across two buildings was notJ possible and that the plans of a loony VMS manager for a disaster recoveryN were not serious ? (ahh, they got egg on their face when the plan worked right from the start).  L If IBM was quite good at brainwashing customers back then, why would you notL believe that Microsoft would be equally as good as brainwashing vendors into- thinking that microsoft will rule the world ?e   ------------------------------  % Date: Tue, 11 Dec 2001 23:13:48 +0100i1 From: John McLean <mcleanj@swissonline.delete.ch>p< Subject: Re: It you say it often enough does it become fact?5 Message-ID: <3C16851C.E7590D8F@swissonline.delete.ch>a   Jan Vorbrueggen wrote: > / > > >From: Peter Kastner (kastner@aberdeen.com)nN > > >And it would be unseemly to remind legacy customers that the profits they  > > >bring fuel new-product R&D. > D > I didn't notice this on the first read. I must say I disagree withE > this. Obviously, _something_ must fuel R&D, and the only source can K > be profit from "legacy" (i.e., existant) customers - who else is bringing G > in money? It's a matter of scale, obviously, but for instance I wouldpG > suppose that almost every customer of Intel is happy on them spendingiG > part of the profit on better fabs and new x86 microarchitectures. New / > processor architectures, I'm not so sure 8-).  > 
 >         Jann  C I think along the lines of you get what you pay for.  If you want aMG solid, reliable, SECURE, expandable, flexible, easily-managed operatingsE system then youve got to expect to pay for it.  It's sort of like thetH top-line Mercedes or Rolls-Royce equivalents. (Please, no comments about
 crashes !)  G Quality is something we all want and while there are no guarantees thattC a high-price means high quality it's damn difficult to include reala quality at a low price.      John McLean   A PS.  Does anyone remember when Compaq PCs were the about the mostcB expensive on the market and Compaq claimed it was because of their quality ???s   ------------------------------  % Date: Tue, 11 Dec 2001 17:47:57 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>e< Subject: Re: It you say it often enough does it become fact?, Message-ID: <3C168D0C.AF0F63F6@videotron.ca>   John McLean wrote:E > I think along the lines of you get what you pay for.  If you want aeI > solid, reliable, SECURE, expandable, flexible, easily-managed operatingo1 > system then youve got to expect to pay for it. d  N Perhaps Compaq is not interested in low volume high quality systems and preferH to spew out large volumes of low quality wintel crap that people have to9 replace every couple of years because it becomes so slow.   M And Compaq is definitely interested in selling you 50 wintel servers comparedqM to a single larger Alpha because selling 50 servers helps it in its competions( on who get to sell the most pcs/servers.  I By having the PC business as a sideline (to help serve customers who needmH desktops), Compaq wouldn't so obsessed with its wintel volumes and couldM concentrate on expanding the markets for its real systems. Humm, soubds a lot M like IBM. I just wish Capellas would put his decisions where his mouth is. IfbJ he wants to emulate IBM, he should de-emphasize the pc business instead of# just pretending to try to copy IBM.h  K This means sending Marcello out to analysts and telling Winkler to shut hiss goddam mouth up.   ------------------------------  % Date: Tue, 11 Dec 2001 17:24:59 -0500c& From: "Jeff Killeen" <Jeff@IDM-IO.com>< Subject: Re: It you say it often enough does it become fact?/ Message-ID: <u1d534c2cmc092@corp.supernews.com>o  5 "Bill Todd" <billtodd@metrocast.net> wrote in message : news:wnqR7.65281$C8.3848313@bin4.nnrp.aus1.giganews.com...D > By George, Jeff, you've done it yet again!  You've acted as if the	 *numbers*tI > given by Compaq in July (not June - just checked), 2000, simply did note. > exist and questioned how profitable VMS was. >s8 > I'll simply repeat my post from yesterday in response: >mL > So were you questioning Compaq's OVMS numbers stated in June [correction -K > July], 2000 ($800 million annual profit on $4 billion annual revenue), or I > just saying those numbers weren't particularly good compared with othertL > Compaq endeavors (and if so please list them, along with their revenue and
 > profit)? >lL > Please try to answer this time:  it's at least the fourth [now fifth] timeI > I've posed the question and you've instead waffled and complained abouth > being misunderstood.  I Bill to avoid after my posting Todd spin if you answer these three issueseJ below directly I will be more than happy to directly respond to your point above...  I 1) What period of time does the $800 million apply to (start date and endh date)s  L 2) That you acknowledge that my original posting below never questioned OVMS as being unprofitableg  L 3) That you acknowledge the issue raised in the posting below is questioningI the claim of that ISSG servers are less profitable as an established fact      ----- Original Message -----& From: "Jeff Killeen" <Jeff@IDM-IO.com> Newsgroups: comp.os.vmsf' Sent: Friday, December 07, 2001 6:05 PMc8 Subject: It you say it often enough does it become fact?    L Something I have noticed in this newsgroup is people stating their _opinion_K about how profitable OVMS is to the point where it has become an article of0K faith.  What is interesting is that data points exist to the contrary (veryuK profitable) and to my knowledge Compaq does not provide the data to back up ? any claim.  The statement that caught my attention today was...s  H "Can't remember about the larger (although I'm sure the $9B of VMS, UnixF and Tandem put together get at least near to 50%) - more profitable is an established fact. "  D Alpha and NSK servers are more profitable than ISSG servers as fact?G Especially as it relates to 8-ways?  Where is the data to back this up?i  H I do NOT claim that either case is true but my malarky detector goes offH each time I see this stated as fact.  Unfortunately I see a lot of POV'sJ based on the assumption that Alpha servers are this great source of profitI that Compaq is throwing away.  While I am not claiming that Alpha serversnJ are grossly unprofitable like the Access Group stuff I do wonder about theH profitability of the Intel, Alpha, and Hymilaya server groups.  Based onJ public information I suspect all 3 groups are making money over the last 8G quarters but it is nothing major.  A key data point to consider is thatcH Compaq management is under huge pressure to show results.  They point toD profitability of the storage and services.  They do NOT point to theD profitability of any of the server groups.  If Alpha servers were asF profitable as some in this feel they are why isn't an embattled CompaqH management touting that when they are touting the profitability of other= groups?  I suspect most folks will have one of two answers...   J Possible answer #1) Each morning when Capellas, Blackmore, and Winkler flyL their black helicopters into their secret underground HQ in Houston they areH told by Bill Gates and Andy Grove they can't say anything positive aboutD OVMS or Alpha.  They all stand in front of two large screens and areI instructed to keep this information secret at all costs.  It must be keptoE secrete even if it means depressing the company stock and costing theu0 executives personally on their performance plan.  L Possible answer #2) Alpha servers aren't anywhere near as profitable as some* people keep repeating in this newsgroup...   ------------------------------  # Date: Wed, 12 Dec 2001 04:16:03 GMT5* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: It you say it often enough does it become fact?B Message-ID: <7SAR7.228255$8q.21698354@bin2.nnrp.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message0) news:u1d534c2cmc092@corp.supernews.com...87 > "Bill Todd" <billtodd@metrocast.net> wrote in message:< > news:wnqR7.65281$C8.3848313@bin4.nnrp.aus1.giganews.com...F > > By George, Jeff, you've done it yet again!  You've acted as if the > *numbers*hK > > given by Compaq in July (not June - just checked), 2000, simply did not 0 > > exist and questioned how profitable VMS was. > >e: > > I'll simply repeat my post from yesterday in response: > >u@ > > So were you questioning Compaq's OVMS numbers stated in June
 [correction -cJ > > July], 2000 ($800 million annual profit on $4 billion annual revenue), orK > > just saying those numbers weren't particularly good compared with othersJ > > Compaq endeavors (and if so please list them, along with their revenue andl > > profit)? > >0I > > Please try to answer this time:  it's at least the fourth [now fifth]o timeK > > I've posed the question and you've instead waffled and complained about  > > being misunderstood. >sK > Bill to avoid after my posting Todd spin if you answer these three issuesiL > below directly I will be more than happy to directly respond to your point
 > above...  J Jeff, you are once again confused:  if you'd rather duck the question thanI answer it, it hardly reinforces *your* position, so I couldn't care less.t  K I will, however, answer the first question you posed (which is a reasonableoL request for clarification):  while the context of the numbers was not statedD explicitly, it was definitely current as of the July, 2000, date theI statement was made and I have reason to suspect it was for 1999 (the lastiG previous full year and one uncomplicated by the transition to Wildfire,eA which temporarily first depressed demand in anticipation and thenvG encountered supply problems).  I also believe that the numbers included F associated storage and service revenue (as I mentioned previously whenI presenting them) which is why I've been consistently careful to term thisMH "VMS-system-related revenue" - but unless you can line up a bunch of VMSK customers who will swear that they would have happily purchased a differenteK system from Compaq instead then including such revenue and profit under the % VMS umbrella is entirely appropriate.o   - bill   ------------------------------  # Date: Wed, 12 Dec 2001 03:22:01 GMT01 From: "David J. Dachtera" <djesys.nospam@fsi.net>cC Subject: Re: Looking for .CLD files for some standard VMS  commandsr' Message-ID: <3C16CD98.8F24DA78@fsi.net>2   Larry Kilgallen wrote: > ] > In article <3C1580C2.1E787E77@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  > H > > I'm hoping he's taking up the idea to write freeware versions of theI > > command programs for the revived FreeVMS project. Thus, he would need-E > > the .CLDs so the correct calls to the CLI$ routines can be coded.f > G > Then it would not be freeware, since it would rely on DEC's coding ofgC > the .CLD files.  Anything unencumbered would have to be done froms% > scratch based on the documentation.a  H Yeah, I guess you're right on that score. One could just build one's ownE COPY.CLD and use a local (process private?) command table to test the C program. Just reDEFINE SYS$SYSTEM /PROCESS or /JOB and/or make it a G search list, including the system-wide translation as the second index.i   -- a David J. Dachterau dba DJE Systemsr http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  # Date: Tue, 11 Dec 2001 19:41:58 GMTe" From: Alfred Falk <falk@arc.ab.ca> Subject: Re: Need help with MLUe9 Message-ID: <Xns9174812EE31A8falkarcabca@205.233.108.180>e  . Dave Greenwood <greenwoodde@ornl.gov> wrote in+ news:10DEC01.21580530@feda01.fed.ornl.gov: a  < > In a previous article, Alfred Falk <falk@arc.ab.ca> wrote:F >> Dave Greenwood <greenwoodde@ornl.gov> wrote in news:7DEC01.21380446 >> @feda01.fed.ornl.gov: e >>  ? >> > In a previous article, Alfred Falk <falk@arc.ab.ca> wrote:dG >> >> I'm trying to set up MLU (Media Loader Utility) from the Freewaree >> tH > I don't know when the TZ875 showed up, but the last development on MLUG > was done in 1994.  I tried to use MLU in 1995 to talk to my TLZ7L andeI > eventually gave up.  I bought MRU (Media Robot Utilities) instead which-H > works fine for me.  I see that TZ875 is not listed among the supported+ > devices for MLU but it is listed for MRU.F  I You're right.  I assumed MLU wouldn't really be that fussy about what it fK worked with.  I have just learned that MRU can be downloaded from Compaq's mL website, and I just tested it. Need to look at legality, though.  They have A a disclaimer that begins "MRU is not freeware...".  However, the iJ documentation says that it comes with the tape library.  But I bought the  library as used equipment.H (I have NO budget for non-essential software this year, even though MRU  license is not expensive.)   -- o@ ----------------------------------------------------------------A   A L B E R T A         Alfred Falk               falk@arc.ab.ca e@ R E S E A R C H         Information Systems Dept   (780)450-5185+   C O U N C I L         250 Karl Clark Road-1                         Edmonton, Alberta, Canada< http://www.arc.ab.ca/   T6N 1E4n  http://www.arc.ab.ca/staff/falk/   ------------------------------    Date: 11 Dec 2001 13:20:02 -06009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)eB Subject: Re: Packard Foundation Tells Merger Urgers to "Paq it In"3 Message-ID: <FpCZfmkusJvR@eisner.encompasserve.org>h  h In article <3C1529AE.67C0AB4@swissonline.delete.ch>, John McLean <mcleanj@swissonline.delete.ch> writes:F > The documents say that they must get "a majority" then go on to talkI > about non-votes and such, and how these should be counted/discounted in 4 > terms of reaching the 50% of all *possible* votes. > I > If you really need the info in more detail, please let me know and I'lls& > cut and paste from the SEC document.  H A pointer to a web page would be fine. I don't know if the Compaq and HPL procedures are the same or not. I've het to get anything in the mail for theL meager number of Compaq shares that are still left from my DEC ESPP and ESOP plans.  C         We need to ensure that actions by our government uphold theeF         principles of a democratic society, accountable government andG         international law, and that all decisions are taken in a manner )         consistent with the Constitution.-4                                                     1 	26-October, 2001: A day that will live in infamyc4 	Support Freedom: http://www.indefenseoffreedom.org/   ------------------------------  % Date: Tue, 11 Dec 2001 23:26:44 +0100i1 From: John McLean <mcleanj@swissonline.delete.ch>uB Subject: Re: Packard Foundation Tells Merger Urgers to "Paq it In"5 Message-ID: <3C168824.1DFFBDCD@swissonline.delete.ch>c   Bob Kaplow wrote:d > j > In article <3C1529AE.67C0AB4@swissonline.delete.ch>, John McLean <mcleanj@swissonline.delete.ch> writes:H > > The documents say that they must get "a majority" then go on to talkK > > about non-votes and such, and how these should be counted/discounted inr6 > > terms of reaching the 50% of all *possible* votes. > >wK > > If you really need the info in more detail, please let me know and I'llu( > > cut and paste from the SEC document. > J > A pointer to a web page would be fine. I don't know if the Compaq and HPN > procedures are the same or not. I've het to get anything in the mail for theN > meager number of Compaq shares that are still left from my DEC ESPP and ESOP > plans.   Okay, the URL isG http://www.sec.gov/Archives/edgar/data/47217/000095010901505083/ds4.txt G and the document is about 750K, which in this case is 117 pages plus at  least 40 pages of Appendix.   F The above details come from page 31 of this document.  From about page- 34 there are details for Compaq stockholders.t    	 John McL.i   ------------------------------  # Date: Tue, 11 Dec 2001 21:50:02 GMTS, From: peterw@u.genie.co.uk (Peter Watkinson)
 Subject: Polls7 Message-ID: <3c167c95.14961515@news.cable.ntlworld.com>a  F I wondered if I might do a straw poll asking posters if they have a PC what type it is.  2 For me I still use a dual PPro 200mhz running NT4.  F The reason I ask is I'm still confused as to why Q killed the Alpha. IF now have a cable modem installed at home and I find the speed of my PCA more than adequate for all my pc uses. In the past with a dial upwD connection I was always looking for more speed to cope with the slow network connection.tF  If this is the case with other users I wonder what makes Compaq thinkD that home users or business will rush out to buy Itaniums when their old kit is up to the job. F  With EV7 to be imminently released and hopefully knock Power4 off theE top of the performance pile the Alpha will have plenty of performance-F to keep Itanium or even Mckinley at bay and thus still keep it's share of the Market in the HPC arena.hC  If Compaq wanted a growth area for Alpha maybe they shouldn't havesF cancelled AlphaNT. Alternatively instead of investing $ in the port ofD VMS/Tru64 to IA64 maybe they should have invested in an Office (Star
 Office) port.e?  Seems to me the only reason I can think of that -Compaq boughtfB Digital in the first place was part of a 3 pronged conspiracy with% Wintel to narrow down the opposition.i       Peter Watkinson  peterw@u.genie.co.uk   ------------------------------  # Date: Tue, 11 Dec 2001 21:53:48 GMTe, From: peterw@u.genie.co.uk (Peter Watkinson) Subject: Re: Pollb7 Message-ID: <3c167feb.15815265@news.cable.ntlworld.com>t  = On Tue, 11 Dec 2001 21:50:02 GMT, peterw@u.genie.co.uk (Peter  Watkinson) wrote:    >i >aG >I wondered if I might do a straw poll asking posters if they have a PC  >what type it is.  >n3 >For me I still use a dual PPro 200mhz running NT4.u >nG >The reason I ask is I'm still confused as to why Q killed the Alpha. ItG >now have a cable modem installed at home and I find the speed of my PChB >more than adequate for all my pc uses. In the past with a dial upE >connection I was always looking for more speed to cope with the slowe >network connection.G > If this is the case with other users I wonder what makes Compaq think E >that home users or business will rush out to buy Itaniums when their  >old kit is up to the job.G > With EV7 to be imminently released and hopefully knock Power4 off thefF >top of the performance pile the Alpha will have plenty of performanceG >to keep Itanium or even Mckinley at bay and thus still keep it's share   >of the Market in the HPC arena.D > If Compaq wanted a growth area for Alpha maybe they shouldn't haveG >cancelled AlphaNT. Alternatively instead of investing $ in the port ofaE >VMS/Tru64 to IA64 maybe they should have invested in an Office (Star, >Office) port.@ > Seems to me the only reason I can think of that -Compaq boughtC >Digital in the first place was part of a 3 pronged conspiracy withn& >Wintel to narrow down the opposition. >q >i >w >Peter Watkinson >peterw@u.genie.co.ukv >     > I forgot to add that where I live there are plenty of small PCE assembly shops most of whom wouldn't know an Alphaserver if landed on E their heads from a very great height. Maybe the same mentality existsw1 in Houston just on a grander scale...............h     Peter Watkinsond peterw@u.genie.co.uk   ------------------------------    Date: 11 Dec 2001 17:10:13 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)g Subject: Re: Polls3 Message-ID: <EgSHTHBnFHMN@eisner.encompasserve.org>w  f In article <3c167feb.15815265@news.cable.ntlworld.com>, peterw@u.genie.co.uk (Peter Watkinson) writes:? > On Tue, 11 Dec 2001 21:50:02 GMT, peterw@u.genie.co.uk (PeterM > Watkinson) wrote:i >  >> >>H >>I wondered if I might do a straw poll asking posters if they have a PC >>what type it is.  A How about we mail you the answers, and you summarize at the end ?"   ------------------------------  $ Date: Wed, 12 Dec 2001 0:20:54 +0000% From: Ian Robinson <ian@canicula.com>p' Subject: Reflections 8 version of LAT??@C Message-ID: <01HW.B83C5366000FCDB61850AA80@news.cable.ntlworld.com>r   Hi,g  K I'm trying to track down a copy of the LAT component that shipped with WRQ f Reflections version 8.  L We are buying Reflections 9 for a project. About 6 of the PC's that will be N using Reflections 9 will need to use LAT to access a VMS box. I've been on to J WRQ both in the UK and the US who say that you can use the version of LAT L that was included with Reflections 8 with version 9 as long as the user has 6 admin rights to the PC it is on. I can live with that.  K The probelm is neither the UK office or the US office is able to supply me aN with a copy of the LAT installer to use with Reflections 9. It's not included K on the CD anymore as far as I can assertain. They don't have any version 8 e
 CD's left!  B So does anyone know where I can get a copy? Can anyone send me it?  K I don't want Reflections itself as I am going to buy that. I'm not looking oK for any pirate software. Just a copy of the LAT component which WRQ say is . okay to use if you have it.    Help!8   Cheers,a   Ian    -- d Ian Robinson, Belfast, UKT <http://www.canicula.com>    ------------------------------   Date: 12 Dec 2001 00:31:59 GMT' From: dashw459@aol.comeatspam (Doug W.)s Subject: SYS$EXAMPLES in 7.39 Message-ID: <20011211193159.18462.00003156@mb-cg.aol.com>e  M Strolling by a unit running VMS 7.3 I happened to do a DIR of sys$examples to<L see if anything new had been added.  I was surprised to find that programs IM recalled from earlier versions of VMS were not present.  Was this a corrupted & unit or have programs been eliminated?   ------------------------------  # Date: Wed, 12 Dec 2001 02:00:02 GMTr2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)  Subject: Re: SYS$EXAMPLES in 7.32 Message-ID: <CSyR7.452$BK1.13861@news.cpqcorp.net>  c In article <20011211193159.18462.00003156@mb-cg.aol.com>, dashw459@aol.comeatspam (Doug W.) writes:dN :Strolling by a unit running VMS 7.3 I happened to do a DIR of sys$examples toM :see if anything new had been added.  I was surprised to find that programs I N :recalled from earlier versions of VMS were not present.  Was this a corrupted' :unit or have programs been eliminated?t     $ set mode/psychic  ! :-)   K   Yes, we moved some operations and capabilities that were previously only oG   available as example programs into documented and supported commands.o     $ set mode/nopsychic  H   Um, which particular programs, features or capabilities would identify+   these missing programs more specifically?     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: Tue, 11 Dec 2001 14:31:41 -0500b5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>o! Subject: Re: The demise of compaqe2 Message-ID: <%ctR7.441$BK1.13975@news.cpqcorp.net>   aaron spink wrote in message= <1chQ7.38634$WC1.3793796@newsread2.prod.itd.earthlink.net>...r >oA >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messagel, >news:x27Q7.294$BK1.4303@news.cpqcorp.net...J >> I was going to say something along the line that all the ex-DECies that> >> wanted to work in Seattle, have long since moved out there. >>J >Who said anything about Seattle?  There is a fairly sizable contingent ofI >ex-DECies working for MS in the bay area.  MS has apparently picked up atL >decent number of people from WRL and SRC lately and I wouldn't be supprised >to see them pick up more. >n >tK >> Hmmm.   A VMS executive environment for NT might be a hoot.  Let me knows >ifa> >> they open a development office for it in a warm climate ;-) >>L >Got any friends that worked/work for the DEC R&D groups in the bay area, it? >is generally pretty warm and never get as cold as new england.d >e    J I have a tough problem.  The wife is from Nashua, and hasn't yet warmed up3 to the idea of leaving the area :-(    Otherwise...n  I After all, year long golf is more important than what job you have ;-)  Ic, just have to convince my (much) better half.   ------------------------------  % Date: Tue, 11 Dec 2001 14:37:33 -050045 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> ! Subject: Re: The demise of compaq 2 Message-ID: <vitR7.442$BK1.13814@news.cpqcorp.net>  < Jerry Leslie wrote in message <9uso03$ci4$1@joe.rice.edu>...   >nG >   Joel: Don't get me started! If you're a software company, there aretA >   lots of great business reasons to love bloatware. For one, if G >   programmers don't have to worry about how large their code is, theyuJ >   can ship it sooner. And that means you get more features, and featuresJ >   make users' lives better (if they use them) and don't usually hurt (ifA >   they don't). As a user, if your software vendor stops, before J >   shipping, and spends two months squeezing the code down to make it 50%I >   smaller, the net benefit to you is going to be imperceptible, but youlF >   went for two months without new features that you needed, and THAT
 >   hurt." >i: >Thanks for the warning against reading this after eating. >rA >Bloated code means more code that can break later on, as well as ! >increasing the costs of testing.u >r    K Yes, but he has a very, very valid point.  The best written software in the L world will lose the battle, if by the time it ships the competition owns theJ market with something inferior.  By the time the "better" thing ships, theK inferior product might have already had 2-3 releases.   It is always easieruG to fix the bugs, and enhance the features for something that is alreadys selling and making money.o   ------------------------------  % Date: Tue, 11 Dec 2001 11:48:09 -0800e# From: "Tom Linden" <tom@kednos.com>n! Subject: RE: The demise of compaqu9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEJEDLAA.tom@kednos.com>   3 So, Fred, what is more important, Golf or Marriage?p   > -----Original Message-----< > From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com]+ > Sent: Tuesday, December 11, 2001 11:32 AMa > To: Info-VAX@Mvb.Saic.Comt# > Subject: Re: The demise of compaqh >  >p > aaron spink wrote in message? > <1chQ7.38634$WC1.3793796@newsread2.prod.itd.earthlink.net>...e > > C > >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message-. > >news:x27Q7.294$BK1.4303@news.cpqcorp.net...L > >> I was going to say something along the line that all the ex-DECies that@ > >> wanted to work in Seattle, have long since moved out there. > >>L > >Who said anything about Seattle?  There is a fairly sizable contingent ofK > >ex-DECies working for MS in the bay area.  MS has apparently picked up a A > >decent number of people from WRL and SRC lately and I wouldn'te > be supprised > >to see them pick up more. > >e > >h@ > >> Hmmm.   A VMS executive environment for NT might be a hoot.
 > Let me knowe > >iff@ > >> they open a development office for it in a warm climate ;-) > >>A > >Got any friends that worked/work for the DEC R&D groups in theo > bay area, itA > >is generally pretty warm and never get as cold as new england.h > >o >  > L > I have a tough problem.  The wife is from Nashua, and hasn't yet warmed up5 > to the idea of leaving the area :-(    Otherwise...  >OK > After all, year long golf is more important than what job you have ;-)  Ia. > just have to convince my (much) better half. >r >  >  >    ------------------------------   Date: 11 Dec 2001 19:53:07 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)! Subject: Re: The demise of compaq 0 Message-ID: <9v5o73$clv$1@pegasus.csx.cam.ac.uk>  2 In article <vitR7.442$BK1.13814@news.cpqcorp.net>,4 Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote: >8 >0L >Yes, but he has a very, very valid point.  The best written software in theM >world will lose the battle, if by the time it ships the competition owns therK >market with something inferior.  By the time the "better" thing ships, the L >inferior product might have already had 2-3 releases.   It is always easierH >to fix the bugs, and enhance the features for something that is already >selling and making money.  D Your first sentences are true, but your last is most definitely not!  @ That is true for the trivial bugs only.  If they are bugs in the@ interface, design or (worst) basic model, then it is MUCH harder> to fix them after shipment because doing so will stop all your( existing customers dead in their tracks.  C And it is this conflict that is the reason that MOST of the serious @ bugs in modern software are long-lived and pervasive - there are5 many that I have been suffering from for 20 years :-(t  B It can only get worse - and worse - and worse - until such time as? we have a major meltdown, with all the chaos that implies.  Gode help our children!     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679-   ------------------------------  % Date: Tue, 11 Dec 2001 15:15:16 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> ! Subject: Re: The demise of compaqt2 Message-ID: <SRtR7.443$BK1.13984@news.cpqcorp.net>  K Well.  So far Marriage is winning out ;-) or I'd be sending this from sunnya Florida.     Tom Linden wrote in message ...l4 >So, Fred, what is more important, Golf or Marriage? >  >> -----Original Message-----e= >> From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com]d, >> Sent: Tuesday, December 11, 2001 11:32 AM >> To: Info-VAX@Mvb.Saic.Com$ >> Subject: Re: The demise of compaq >> >> >> aaron spink wrote in message,@ >> <1chQ7.38634$WC1.3793796@newsread2.prod.itd.earthlink.net>... >> >D >> >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message/ >> >news:x27Q7.294$BK1.4303@news.cpqcorp.net...uH >> >> I was going to say something along the line that all the ex-DECies thatA >> >> wanted to work in Seattle, have long since moved out there.u >> >>aJ >> >Who said anything about Seattle?  There is a fairly sizable contingent ofL >> >ex-DECies working for MS in the bay area.  MS has apparently picked up aB >> >decent number of people from WRL and SRC lately and I wouldn't >> be supprisedC >> >to see them pick up more.  >> > >> >A >> >> Hmmm.   A VMS executive environment for NT might be a hoot.l >> Let me know >> >ifA >> >> they open a development office for it in a warm climate ;-)  >> >>iB >> >Got any friends that worked/work for the DEC R&D groups in the >> bay area, it B >> >is generally pretty warm and never get as cold as new england. >> > >> >>J >> I have a tough problem.  The wife is from Nashua, and hasn't yet warmed up6 >> to the idea of leaving the area :-(    Otherwise... >>L >> After all, year long golf is more important than what job you have ;-)  I/ >> just have to convince my (much) better half.g >> >> >> >> >F   ------------------------------  % Date: Tue, 11 Dec 2001 15:23:18 -050095 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>@! Subject: Re: The demise of compaq 2 Message-ID: <nZtR7.445$BK1.13966@news.cpqcorp.net>  F Nick Maclaren wrote in message <9v5o73$clv$1@pegasus.csx.cam.ac.uk>...3 >In article <vitR7.442$BK1.13814@news.cpqcorp.net>,f5 >Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:e >> >>I >>Yes, but he has a very, very valid point.  The best written software ind thenJ >>world will lose the battle, if by the time it ships the competition owns thePL >>market with something inferior.  By the time the "better" thing ships, theF >>inferior product might have already had 2-3 releases.   It is always easierI >>to fix the bugs, and enhance the features for something that is already2 >>selling and making money.  >nE >Your first sentences are true, but your last is most definitely not!  >sA >That is true for the trivial bugs only.  If they are bugs in thetA >interface, design or (worst) basic model, then it is MUCH harderc? >to fix them after shipment because doing so will stop all youra) >existing customers dead in their tracks.e >wD >And it is this conflict that is the reason that MOST of the seriousA >bugs in modern software are long-lived and pervasive - there ares6 >many that I have been suffering from for 20 years :-( >.C >It can only get worse - and worse - and worse - until such time asI@ >we have a major meltdown, with all the chaos that implies.  God >help our children!a >d    : The alternative is to be fixing them and NOT making money.  K I, and almost anyone in this business make routine decisions everyday about H the level of quality code must have before it ships.  In general, out ofJ about 5 or 6 levels of bug priorities I use, only one - showstopper - willD prevent the code from shipping, or slipping the date.  Enough "high"J priority bugs might also cause this.  But I have never shipped code that IK could reasonable conclude had no bugs, unless it was small enough to fit onk a couple screens.   L I have from time to time been put in a position to recommend doing work thatK will make code better to maintain, and reduce the number of problem reportslL over time we would get... but cannot justify it because there simply isn't aK sufficient customer visable benefit - the question being how many customerseJ will not buy if we don't do it, and how many new ones will buy if we do do it.t  H Someone like a Microsoft has precious little incentive to clean up theirI code.  Add features, sell new versions, fix the X% highest bugs reported.- Repeat until rich.   ------------------------------  # Date: Tue, 11 Dec 2001 20:35:45 GMTk4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: The demise of compaqn. Message-ID: <B6uR7.33923$ER5.385850@rwcrnsc52>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:nZtR7.445$BK1.13966@news.cpqcorp.net...   >wJ > Someone like a Microsoft has precious little incentive to clean up theirK > code.  Add features, sell new versions, fix the X% highest bugs reported.  > Repeat until rich. >n  K Just take Occam's Razor to the above statement, and you've got the Story ofp Micro$oft in 25 words or less.   Well done, Fred!   ------------------------------  % Date: Tue, 11 Dec 2001 15:29:41 -0500.5 From: David Beatty <David.Beatty@qwertysasasdfgh.com>m! Subject: Re: The demise of compaqs2 Message-ID: <dmwWPJA4vG3=nQ+l1mXz97LjtLp8@4ax.com>  4     Hmmm ... maybe once technology gets back in it's0 feet again you can move to North Carolina, where7 year-round golf is most certainly a reality -- I playedf Sunday!n   David R. Beattym  5 On Tue, 11 Dec 2001 14:31:41 -0500, "Fred Kleinsorge" $ <kleinsorge@star.zko.dec.com> wrote:   >aaron spink wrote in messageA> ><1chQ7.38634$WC1.3793796@newsread2.prod.itd.earthlink.net>... >>B >>"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- >>news:x27Q7.294$BK1.4303@news.cpqcorp.net...cK >>> I was going to say something along the line that all the ex-DECies thatD? >>> wanted to work in Seattle, have long since moved out there.n >>>nK >>Who said anything about Seattle?  There is a fairly sizable contingent ofeJ >>ex-DECies working for MS in the bay area.  MS has apparently picked up aM >>decent number of people from WRL and SRC lately and I wouldn't be supprised  >>to see them pick up more.  >> >>L >>> Hmmm.   A VMS executive environment for NT might be a hoot.  Let me know >>if? >>> they open a development office for it in a warm climate ;-)- >>>-M >>Got any friends that worked/work for the DEC R&D groups in the bay area, itK@ >>is generally pretty warm and never get as cold as new england. >> >s >eK >I have a tough problem.  The wife is from Nashua, and hasn't yet warmed upn4 >to the idea of leaving the area :-(    Otherwise... > J >After all, year long golf is more important than what job you have ;-)  I- >just have to convince my (much) better half.g >s >s >    ------------------------------   Date: 11 Dec 2001 21:41:44 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)! Subject: Re: The demise of compaqe0 Message-ID: <9v5uio$gns$1@pegasus.csx.cam.ac.uk>  2 In article <nZtR7.445$BK1.13966@news.cpqcorp.net>,4 Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote: >>B >>That is true for the trivial bugs only.  If they are bugs in theB >>interface, design or (worst) basic model, then it is MUCH harder@ >>to fix them after shipment because doing so will stop all your* >>existing customers dead in their tracks. >>E >>And it is this conflict that is the reason that MOST of the seriouseB >>bugs in modern software are long-lived and pervasive - there are7 >>many that I have been suffering from for 20 years :-(  >>D >>It can only get worse - and worse - and worse - until such time asA >>we have a major meltdown, with all the chaos that implies.  Godh >>help our children! >l; >The alternative is to be fixing them and NOT making money.n >rL >I, and almost anyone in this business make routine decisions everyday aboutI >the level of quality code must have before it ships.  In general, out of K >about 5 or 6 levels of bug priorities I use, only one - showstopper - will E >prevent the code from shipping, or slipping the date.  Enough "high"kK >priority bugs might also cause this.  But I have never shipped code that InL >could reasonable conclude had no bugs, unless it was small enough to fit on >a couple screens. >3M >I have from time to time been put in a position to recommend doing work that3L >will make code better to maintain, and reduce the number of problem reportsM >over time we would get... but cannot justify it because there simply isn't anL >sufficient customer visable benefit - the question being how many customersK >will not buy if we don't do it, and how many new ones will buy if we do doe >it. > I >Someone like a Microsoft has precious little incentive to clean up their1J >code.  Add features, sell new versions, fix the X% highest bugs reported. >Repeat until rich.7    I am not denying any of that :-(  C But I am also warning that the world is heading for a disaster, andoA I don't mean the minor glitches that we have seen so far.  We can C only hope that we receive a healthy shock in time to recover.  Yes,iC I really am talking about a potential collapse of civilisation, and 5 most of the other experts in this area agree with me.s  B As with the ecology and resources, short-term gain always wins out? against long-term survival, and we are relying on unsustainable ? practices.  We are seeing an increasing number of projects failp< simply because changing circumstances bring deep bugs to the= surface, and it is simply infeasible to locate the problem inrB time to save the project.  Often because there is nobody left with the appropriate skills.-  A One day this will happen to something critical, and cause a major @ economic collapse - which, history teaches us, very often causes a major war :-(-  - There is a saying about a horseshoe nail ....-     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679@   ------------------------------  # Date: Wed, 12 Dec 2001 01:02:10 GMT7/ From: "Timothy A. Seufert" <tas@mindspring.com>r! Subject: Re: The demise of compaq99 Message-ID: <tas-0EEAED.17020811122001@netnews.attbi.com>n  & In article <3C1296B8.3750CB78@gmx.de>,*  Bernd Paysan <bernd.paysan@gmx.de> wrote:  I > I think the Mozilla example is a very typical one. This project startedxJ > by open sourcing Netscape. Actually, they couldn't open source Netscape,F > because major parts were third party libraries. So they open sourcedG > something that couldn't be compiled to something useful. While peopleiD > looked through the monstrous code (created by those people crowdedJ > together in the Netscape office), they decided to rewrite it rather thanJ > to fix it. Eventually, they rewrote everything. But in the meantime, theG > people at Netscape fought against the rewrites. Really, it would havetB > been better if these people had moved the original (proprietary)J > Netscape forward. But then, noone of the outsider developers (who reallyF > did most of the rewrites) would have been inclined to put their code > into Mozilla.t  I I Am Not A Mozilla Developer, but AFAIK the scenario you present is VERY h& different from what actually happened.  G In reality, the project had a great deal of difficulty even attracting eG outside developers.  As you mentioned, they had to cut out third party tC libraries to open their own code, so they did not release a usable tG project.  Additionally, the existing code was very convoluted.  It was 0H difficult for outsiders to come up to speed on the code, and there were F few ways for them to contribute anything meaningful until the missing B pieces were replaced.  As a result not many people stuck with the ) project unless it was their job to do so.h  G So, the majority of the work on Mozilla was and is done by people with uG netscape.com email addresses.  That includes the ground-up rewrites of yF many core components.  Netscape people didn't fight change, they were  the movers behind it.     B The results of the rewrites are a mixed bag.  As I understand it, G rewriting the HTML layout engine was a big win.  The new layout engine uG is more standards compliant and significantly faster than the old, and  + (AFAIK) did not take that long to complete.r  I What didn't go so well was the complete redesign of how Mozilla/Netscape sF handles its GUI.  Old-style Netscape simply had platform-specific GUI I code.  Mozilla (and Navigator) have a complete GUI engine built in, with  G almost no platform specific code and more or less identical appearance rE (save window borders) on all platforms.  That has turned out to be a vI mistake.  The implementation is poor (bloated and slow), and it fails to hI integrate well with each platform because its widgets and editing fields o< and so forth behave differently than the host's equivalents.   --     Tim    ------------------------------  % Date: Tue, 11 Dec 2001 23:51:07 -0500e# From: Paul DeMone <pdemone@igs.net>A! Subject: Re: The demise of compaqt' Message-ID: <3C16E23B.4F302B76@igs.net>    "Terry C. Shannon" wrote:  > B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message  L > > Someone like a Microsoft has precious little incentive to clean up theirM > > code.  Add features, sell new versions, fix the X% highest bugs reported.W > > Repeat until rich. > >. > M > Just take Occam's Razor to the above statement, and you've got the Story ofi  > Micro$oft in 25 words or less. >  > Well done, Fred!  < I think the best overview of M$ was expressed in an EE Times" editorial (IIRC) 3 or 4 years ago.  A Basically the author's point was that M$ is in the disappointmentiC business. Each new M$ software package promises much but in the endi@ fell short because of awkward or misdirected features, and bugs.A It is always in M$ interest to disappoint because satisfied userseB don't upgrade. The trick is for each new release to contain enoughC incentive to upgrade to version N+1 but not be good enough to leaveo no reason to upgrade to N+2.     --D Paul W. DeMone       The 801 experiment SPARCed an ARMs race of EPICE Kanata, Ontario      proportions to put more PRECISION and POWER intoaG demone@mosaid.com    architectures with MIPSed results but ALPHA's well $ pdemone@igs.net      that ends well.    > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----A http://www.newsfeeds.com - The #1 Newsgroup Service in the World!o> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----   ------------------------------    Date: 12 Dec 2001 07:58:33 +0100* From: Ketil Z Malde <ketil@apal.ii.uib.no>! Subject: Re: The demise of compaqu+ Message-ID: <eg3d2g2acm.fsf@apal.ii.uib.no>   * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  4 > In article <nZtR7.445$BK1.13966@news.cpqcorp.net>,6 > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:  = >> The alternative is to be fixing them and NOT making money.   A So you could say that shipping the bugs, and planning to fix theme& later, is an easy *business* decision.  @ > But I am also warning that the world is heading for a disaster  C Given the cost of maintaining a normal PC with a bit of software oniD it, I'd say the disaster is already happening.  If business actuallyC measured the cost vs the productivity gains, I suspect they'd starta& looking for alternatives pretty quick.   -kzm -- iH If I haven't seen further, it is by standing in the footprints of giants   ------------------------------    Date: 11 Dec 2001 14:03:16 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)d( Subject: Re: Unix for HELP ... Examples?3 Message-ID: <OIU8nPYL+NtP@eisner.encompasserve.org>u  ` In article <9v52nh$1ma0$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:5 > In article <Y2fqeAJb0Job@eisner.encompasserve.org>, 2 >  Kilgallen@SpamCop.net (Larry Kilgallen) writes: > |>E > |> > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in messaged, > |> > news:9v2puh$hnu$1@info.cs.uofs.edu... > |> > [...]C > |> >> What is the VMS equivalent of the apropos (man -k) command.mC > |> >> Oh wait, we have already determined that there is no way to-, > |> >> do a context based search of HELP.   > |> eG > |> But then again someone should also pitch in with an explanation ofcK > |> "the apropos (man -k) command" that does not involve unix terminology.w > |> r, > |> Come on, you people should know better. > F > Sorry, I thought that reading these two sentences would have made itH > pretty clear what the command did.  Especially being as this topic has+ > been going on for a little while already.l  , And I had been wondering what apropos meant.7 I gather now it is a "search" across the help database.-  C > My whole point was merely that Unix and VMS have different onlinen@ > documentation paradigms (just like the whole philosophy of theA > underlying OS is also different).  It doesn't make one right ort? > the other wrong.  Just like everybody doesn't like to drive asE > Cadillac or a Kia, people's tastes in OS and user interface differ.t> > That doesn't make one better than the other, only different.  @ That's fine, but the best answers in the VMS newsgroup will come from using VMS terminology.a   ------------------------------    Date: 11 Dec 2001 14:35:37 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)f( Subject: Re: Unix for HELP ... Examples?3 Message-ID: <RQ0DBZUPVk2w@eisner.encompasserve.org>   ` In article <9v559q$1ndt$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:3 > In article <3c15481a.694363411@news.wcc.govt.nz>,a. >  rob.buxton@wcc.govt.nz (Rob Buxton) writes:K > |> On 10 Dec 2001 15:05:26 -0600, koehler@encompasserve.org (Bob Koehler)r > |> wrote:a > |> nH > |> And, once you've figured that man displays your subject you're thenI > |> flummoxed by how the hell to get out of man. Oh yes, you hit "q" howv# > |> remiss of me not to know that.  > I > And you exit from HELP how??  Oh wait, just keep hitting <CR> until you>N > get back to the "$" prompt.  Is "q", as in "quit" really that un-intuitive??  1 If Q is the normal method for Unix, that is fine.13 On VMS Ctrl/Z is the normal method, and I use that.o  B > |> And as the poor poster asked, well no, many pages do not haveH > |> examples. I guess they vary depending on the flavour of unix you're
 > |> running.c  % >   Additional information available:1 >  >   Image      Process >  > RUN Subtopic? 	 > Topic? k > $  > C > Hmmm.....  No Examples.  Maybe Examples aren't provided when theysC > serve no particular purpose (in the mind of the document writer.)   0 There are examples under both Image and Process.@ Examples under the common section would not be much help because@ so many aspects of the examples for Image or Process are illegal for the other mode.f  B > How about this one.  How does one go about adding an item to VMS9 > HELP for a locally written utility??  What's Involved??   9 $ LIBRARY/HELP SYS$COMMON:[SYSHELP]HELPLIB.HLB MYHELP.HLPu  I or were you referring to the fact that there is a text format to follow ?   @ Of course there are alternate techniques involving separate helpC libraries and logical names, but if you use the simple method aboveiB VMS will preserve your non-conflicting entries on upgrade, because& it has to do so for Fortran, Rdb, etc.   ------------------------------  # Date: Wed, 12 Dec 2001 00:05:18 GMTn) From: rob.buxton@wcc.govt.nz (Rob Buxton)a( Subject: Re: Unix for HELP ... Examples?1 Message-ID: <3c169b8f.781264999@news.wcc.govt.nz>t  < On 11 Dec 2001 14:30:18 GMT, bill@triangle.cs.uofs.edu (Bill Gunshannon) wrote:  2 >In article <3c15481a.694363411@news.wcc.govt.nz>,- > rob.buxton@wcc.govt.nz (Rob Buxton) writes:oJ >|> On 10 Dec 2001 15:05:26 -0600, koehler@encompasserve.org (Bob Koehler)
 >|> wrote: >|> G >|> And, once you've figured that man displays your subject you're thenlH >|> flummoxed by how the hell to get out of man. Oh yes, you hit "q" how" >|> remiss of me not to know that. > H >And you exit from HELP how??  Oh wait, just keep hitting <CR> until youM >get back to the "$" prompt.  Is "q", as in "quit" really that un-intuitive??   E Or ^Z (which just relegates your job to the background on Unix) or ^Cb or ^Y. And yes, just <CR>c- And, well no, q wasn't immediately intuitive.wA And on the Linux Boxes we have here there are no examples for ANYf	 commands.o     >a >|> A >|> And as the poor poster asked, well no, many pages do not havedG >|> examples. I guess they vary depending on the flavour of unix you'rei >|> running. >|>  >i >$ help runc >i >RUN >aG >     Executes an image within the context of your process (see Image).g >eD >     Creates a subprocess or a detached process to run an image andA >     deletes the process when the image completes execution (seea >     Process).> >    >: >: >e$ >  Additional information available: >9 >  Image      Process> >  >RUN Subtopic?   >Topic?  >$ r >oB >Hmmm.....  No Examples.  Maybe Examples aren't provided when theyB >serve no particular purpose (in the mind of the document writer.) >    Errr......     NODE  help rune   RUN   F      Executes an image within the context of your process (see Image).  C      Creates a subprocess or a detached process to run an image andS@      deletes the process when the image completes execution (see      Process).  #   Additional information available:1     Image      Process   RUN Subtopic? imagey   RUNs     Imagem  D        Executes an image within the context of your process. You can8        abbreviate the RUN command to a single letter, R.    stuff trimmed............         Format            RUN  filespec    %     Additional information available:I       Parameter  Qualifier
     /DEBUG     Examples   And that last line, Examples.i  rA >How about this one.  How does one go about adding an item to VMS 8 >HELP for a locally written utility??  What's Involved?? >i  D Still within help, I tried help (help on help seemed reasoanble) and> then looked at the /USERLIBRARY comamnd. So, from that you can? configure the HLP$LIBRARY_n logical to point to additional Helps modules.  F But, once you're a bit more familiar with Library, then you could lookC through the Help and look at how you can add modules to an existingo library.  E It always seems to take the Unix admins longer to do things that seemeA so easy on VMS. It takes me bleedin' ages to do anything on Unix.p   Rob.   >billt >  >-- K >Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesoE >bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.w >University of Scranton   | B >Scranton, Pennsylvania   |         #include <std.disclaimer.h>      ------------------------------  % Date: Wed, 12 Dec 2001 06:57:51 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender)( Subject: Re: Unix for HELP ... Examples?; Message-ID: <3c16f1df.524144494f47414741@radiogaga.harz.de>   2 Bill Gunshannon (bill@triangle.cs.uofs.edu) wrote:1 > koehler@encompasserve.org (Bob Koehler) writes:a. > |> "C.W.Holeman II" <cwhii@mail.com> writes:- > |> > What is Unix for Examples in VMS HELP?1& > |> > MAN seems to lack this feature. > |> e6 > |> The UNIX equivalent to examples is "hire a guru". >aC > Many of the man pages contain examples.  But you have to actuallyK > read them. >o= > What is the VMS equivalent of the apropos (man -k) command.l= > Oh wait, we have already determined that there is no way too$ > do a context based search of HELP.  
 Is there not?   2 > I guess the answer to that is "hire a VMS guru".  5 And I guess that VMS guru then writes an APROPOS.COM. $ And though I'm not a guru, I did it:   [-- APROPOS.COM --]> $! APROPOS.COM $! $! Search a help entries filee $t $ ON WARNING   THEN GOTO helle $ ON CONTROL_Y THEN GOTO hell- $ $ $ IF P1 .NES. "" THEN GOTO got_topicC $ WRITE SYS$OUTPUT "Usage: ",F$ENVIRONMENT("PROCEDURE"), " <topic>"a $ EXIT $got_topic:l $ topic = P1 $p0 $ apropos_file = "SYS$DISK:[]HELP_ABSTRACTS.TXT"@ $ tmpfile = "SYS$SCRATCH:APROPOS_" + F$GETJPI("","PID") + ".TMP" $iI $ SEARCH /MATCH=OR /OUTPUT='tmpfile' 'apropos_file' "-entry- ","''topic'"   $ topic = F$EDIT(topic,"UPCASE") $ skip_mode = 05 $ OPEN /READ RESULT 'tmpfile'I# $ OPEN /READ APROPOS 'apropos_file' & $ READ /END_OF_FILE=hell APROPOS line2 $resultloop:0 $   READ /END_OF_FILE=end_resultloop RESULT line $   WRITE SYS$ERROR line+ $   IF F$EXTRACT(0,8,line) .EQS. "-entry- "e $   THEN $     entry = line - "-entry- "  $     skip_mode = 0e $   ELSE' $     IF skip_mode THEN GOTO resultloopoB $     IF F$LOCATE(topic,F$EDIT(line,"UPCASE")) .LT. F$LENGTH(line)
 $     THEN $       ! Find & show entryp $      readloop1: ) $       IF line2 .NES. "-entry- ''entry'"t $       THEN7 $         READ /END_OF_FILE=end_readloop1 APROPOS line2o $         GOTO readloop1 $       ELSE$ $         line2 = line2 - "-entry- "  $         WRITE SYS$OUTPUT line2 $        readloop2:i7 $         READ /END_OF_FILE=end_readloop2 APROPOS line2 J $         IF F$EXTRACT(0,8,line2) .EQS. "-entry- " THEN GOTO end_readloop2  $         WRITE SYS$OUTPUT line2 $         GOTO readloop2 $        end_readloop2:t
 $       ENDIFe $      end_readloop1:n $       skip_mode = 1n $     ENDIFh	 $   ENDIFs $   GOTO resultloop  $end_resultloop: $ CLOSE RESULT $ DELETE 'tmpfile';* $ EXIT $i $hell: $ sts = $STATUSu9 $ IF F$TRNLNM("APROPOS","LNM$PROCESS") THEN CLOSE APROPOSt7 $ IF F$TRNLNM("RESULT","LNM$PROCESS") THEN CLOSE RESULTc $ DELETE 'tmpfile';* $ EXIT 'sts' [-- APROPOS.COM --]i  D And just as under Unix, where you have to build a 'whatis' file from2 the man pages (which is then searched by apropos):   [-- MAKE_WHATIS.COM --]  $! MAKE_WHATIS.COM $!4 $! Extract top-level entries from all help libraries $a $ ON WARNING   THEN GOTO helle $ ON CONTROL_Y THEN GOTO helle $i0 $ apropos_file = "SYS$DISK:[]HELP_ABSTRACTS.TXT"; $ tmpfile = "SYS$SCRATCH:EX_" + F$GETJPI("","PID") + ".TMP"o $ $ $ OPEN /WRITE APROPOS 'apropos_file' $s" $ libfile = "SYS$HELP:HELPLIB.HLB" $ GOSUB read_library $  $ libfile = "HLP$LIBRARY"-- $ IF F$TRNLNM(libfile) .EQS. "" THEN GOTO fina $i $ n = 0t	 $libloop:,
 $   n = n + 1i  $   libfile = "HLP$LIBRARY_''n'"! $   IF F$TRNLNM(libfile) .NES. "". $   THEN $     GOSUB read_library $     GOTO libloop	 $   ENDIF- $- $fin:- $ CLOSE APROPOSe $ EXIT $0 $read_library:* $ LIBRARY /LIST='tmpfile' /NAMES 'libfile' $ OPEN /READ LIST 'tmpfile's $ ! skip headers
 $skiploop:, $   READ /END_OF_FILE=end_skiploop LIST line' $   IF line .NES. "" THEN GOTO skiploopB $end_skiploop: $readloop1:./ $   READ /END_OF_FILE=end_readloop1 LIST modulev? $   LIBRARY /EXTRACT=("''module'") /OUTPUT='tmpfile'2 'libfile'p $   in_top_section = 0" $   OPEN /READ CONTENTS 'tmpfile'2
 $  readloop2:e3 $     READ /END_OF_FILE=end_readloop2 CONTENTS lineh* $     IF line .EQS. "" THEN GOTO readloop2  $     sect = F$EXTRACT(0,1,line) $     IF sect .EQS. "1"c
 $     THEN $       in_top_section = 1< $       line = "-entry- " + (F$EDIT(line,"COMPRESS") - "1 ")
 $     ELSEF $       IF sect .GES. "2" .AND. sect .LES. "9" THEN in_top_section = 0 $     ENDIFs/ $     IF in_top_section THEN WRITE APROPOS lined $     GOTO readloop2 $  end_readloop2:  $    CLOSE CONTENTSr $    DELETE 'tmpfile'2;r $    GOTO readloop1  $end_readloop1:e $ CLOSE LIST $ DELETE 'tmpfile';  $ RETURN $  $hell: $ sts = $STATUSt; $ IF F$TRNLNM("CONTENTS","LNM$PROCESS") THEN CLOSE CONTENTSl3 $ IF F$TRNLNM("LIST","LNM$PROCESS") THEN CLOSE LISTi9 $ IF F$TRNLNM("APROPOS","LNM$PROCESS") THEN CLOSE APROPOSj! $ DELETE 'tmpfile';*,'tmpfile'2;*e $ EXIT 'sts' [-- MAKE_WHATIS.COM --]A  @ Disclaimer: This is just a proof-of-concept, so there are issues. with error checking, quotes in the topic, etc.   cu,r   Martin -- nD                     | Martin Vorlaender    |    VMS & WNT programmer-   Smiert Spamionem  | work: mv@pdv-systeme.detD                     |       http://www.pdv-systeme.de/users/martinv/4                     | home: martin@radiogaga.harz.de   ------------------------------  # Date: Tue, 11 Dec 2001 20:56:08 GMT " From: "Hans Vlems" <hvlems@iae.nl>' Subject: Unknown VAXstation 4000-90 ???s0 Message-ID: <IpuR7.719$8p1.3014@typhoon.bart.nl>  I Today I was given a VAXstation model 4000-90A. That's what it says on thee box.? I connected the serial console and powered it up. It responded:r   ?? CRPT - Reenter bit clrn ?? CRPT - Reenter bit clrl  G This message was repeated about thirty times and suddenly a more normalp message appeared:n   ?? CRPT - Reenter bit clr    U   KA49-A V1.3-0BC-V4.4   83 MHZp 08-00-2B-94-CD-C3' 80MB     OK  K So far so good, so I installed VAX/VMS V7.3. During the first reboot (after  unpacking VMS073.B) I spotted ai strange message:    @ This system has an unsupported CPU configuration.  Your softwareD licenses may not function properly until your hardware is corrected.8 %%%%%%%%%%%  OPCOM  11-DEC-2001 21:08:14.95  %%%%%%%%%%%/ Logfile has been initialized by operator _OPA0:o- Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1r  K Installing PAK's did not work since no number of units would satisfy LMF asr the next commands showed:t         $ sho lic/charge* VMS/LMF Charge Information for node VS4090> This is a Unknown VAXstation 4000-90A, hardware model type 477I Type: A, * Not Permitted *      (VAX/VMS Capacity or OpenVMS Unlimited or3 Base)B4 Type: B, * Not Permitted *      (VAX/VMS F&A Server)9 Type: C, * Not Permitted *      (VAX/VMS Concurrent User)e5 Type: D, * Not Permitted *      (VAX/VMS Workstation)cD Type: E, * Not Permitted *      (VAX/VMS System Integrated Products)6 Type: F, * Not Permitted *      (VAX Layered Products)* Type: G, * Not Permitted *      (Reserved)8 Type: H, * Not Permitted *      (Alpha Layered Products)2 Type: I, * Not Permitted *      (Layered Products) $ sho cpu/full  % VS4090, a Unknown VAXstation 4000-90AmH Multiprocessing is DISABLED. Uniprocessing synchronization image loaded.   PRIMARY CPU = 00   CPU 00 is in RUN state/ Current Process: SYSTEM          PID = 00000212  Capabilities of this CPU:e         PRIMARY QUORUM RUN- Processes which can only execute on this CPU:          *** None *** $i    & Question: what kind of system is this?+ And, more importantly: can I run VMS on it?v  
 Hans Vlems   ------------------------------  % Date: Tue, 11 Dec 2001 22:48:58 +0000.% From: "a.carlini" <arcarlini@iee.org>e+ Subject: Re: Unknown VAXstation 4000-90 ???a' Message-ID: <3C168D5A.EC9ECD52@iee.org>E   Hans Vlems wrote:a > ?? CRPT - Reenter bit clre > ?? CRPT - Reenter bit clrt >     The console ROM (or possibly the% NVRAM) is corrupt. Anecdotal evidences$ suggests that NetBSD will do this to# the console ROM (it lives in Flash,  so it is certainly possible).o   > KA49-A V1.3-0BC-V4.4   83 MHZ  > 08-00-2B-94-CD-C3  > 80MB    You do indeed have a VS4000-90A. The VS4000-90 announces itself as running at 71MHz.  B > This system has an unsupported CPU configuration.  Your softwareF > licenses may not function properly until your hardware is corrected.  - OpenVMS has some code to detect what it callss0 "jimmied ROMS". I guess this started back in the, days of the KA650, which came in a multiuser1 variant (KA650-A) and a single user (workstation)c variant (KA650-B). g  # Your corrupted console has probablya upset OpenVMS's detection code.o  ( > Question: what kind of system is this?- > And, more importantly: can I run VMS on it?   + My guess is that you have a VS4000-90A witho a corrupted flash.   Antonio    --     ---------------n- Antonio Carlini             arcarlini@iee.orgv   ------------------------------  # Date: Tue, 11 Dec 2001 23:06:00 GMT.2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)+ Subject: Re: Unknown VAXstation 4000-90 ???-2 Message-ID: <sjwR7.450$BK1.13997@news.cpqcorp.net>  U In article <IpuR7.719$8p1.3014@typhoon.bart.nl>, "Hans Vlems" <hvlems@iae.nl> writes:E1 :Today I was given a VAXstation model 4000-90A...s@ :I connected the serial console and powered it up. It responded: :g :?? CRPT - Reenter bit clr :?? CRPT - Reenter bit clr  I   This looks like corrupt or otherwise failing hardware -- if the system gM   configuration is valid (eg: right type of memory, etc), and if (re)seating eI   the components and cables and options doesn't clear this error, then...     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, 12 Dec 2001 00:13:41 -0500 . From: Phillip <nntpmouse@prism.datastacks.com> Subject: VMS 72 on MV 3100/ Message-ID: <u1dpm8q4dlpmd6@corp.supernews.com>b   Hi all!sD I'm tring to get VMS 72 on a MicroVAX 3100 from the hobby CD, but am getting stuck.  G I get the output below, but dont ever get past it (no noticable IO from- disks, cd, etc. ).  K I've tried having the CD on DKB0 and DKA0, and harddisks on DKA200,300,400. F My BestGuess(tm) so far has been to see if there is a way to boot the H actual VMS enviroment and using the MOUNT/NOMOUNT_VERIFICATION command, J then coping over the image. I found that on a web page somewhere, but the K example was on a diffrent model and the command does not work on the 3100. i2 (the command, fwiw, was ``B/R5:10000000 DKA400:'')   Any help would be appreciated! -Phillip  @  DKA200   RZ2     A/2/0/00  RODISK    681 MB   RM        CD-ROM @  DKA300   RZ3     A/3/0/00  DISK      104 MB   FX        RZ23   @  ...HostID....    A/6       INITR                               !                                  c!  ...HostID....    B/6       INITR,!                                  n >>> boot dka200      -DKA200<= %SYSBOOT-I-SYSBOOT Mapping the SYSDUMP.DMP on the System Diskn= %SYSBOOT-W-SYSBOOT Can not map SYSDUMP.DMP on the System Diskh> %SYSBOOT-W-SYSBOOT Can not map PAGEFILE.SYS on the System DiskJ    OpenVMS (TM) VAX Version X72T Major version id = 1 Minor version id = 0  1 PLEASE ENTER DATE AND TIME (DD-MMM-YYYY  HH:MM)  oC PLEASE ENTER DATE AND TIME (DD-MMM-YYYY  HH:MM)  11-DEC-2001  14:48x   Configuring devices . . .j  P Available device  DKA200:                          device type SONY CD-ROM CDU-8D Available device  DKA300:                          device type RZ23 M %BACKUP-I-IDENT, Stand-alone BACKUP T7.2; the date is 11-DEC-2001 14:49:06.47a+ $ BACKUP/IMAGE DKA200:VMS072.B/SAVE DKA300:dO %SYSTEM-I-MOUNTVER, SABKUP$DKA200: is offline.  Mount verification in progress.'   ------------------------------  % Date: Wed, 12 Dec 2001 00:43:44 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: VMS 72 on MV 3100, Message-ID: <3C16EE8A.3A43B375@videotron.ca>   Phillip wrote:A >  DKA200   RZ2     A/2/0/00  RODISK    681 MB   RM        CD-ROMx? >  DKA300   RZ3     A/3/0/00  DISK      104 MB   FX        RZ23e  - > $ BACKUP/IMAGE DKA200:VMS072.B/SAVE DKA300:eQ > %SYSTEM-I-MOUNTVER, SABKUP$DKA200: is offline.  Mount verification in progress.     1 Have you tried a low level format of the trive ? o  L at the >>> prompt rior to booting, it is TEST 75  on the 3100. Enter whetherM the device is on the internal or external scis bus, then the device's scsi IDfS and then a confirmation and voila. That shoudl give you a sanity check on the driveu   ------------------------------  % Date: Wed, 12 Dec 2001 01:35:07 -0500 . From: Phillip <nntpmouse@prism.datastacks.com> Subject: Re: VMS 72 on MV 3100/ Message-ID: <u1duevr90llk57@corp.supernews.com>   0 After tring that, there have been no change.  :(    3 On Wed, 12 Dec 2001 00:43:44 -0500, JF Mezei wrote:u  2 > Have you tried a low level format of the trive ? > F > at the >>> prompt rior to booting, it is TEST 75  on the 3100. EnterF > whether the device is on the internal or external scis bus, then theJ > device's scsi ID and then a confirmation and voila. That shoudl give you > a sanity check on the drive:   ------------------------------  % Date: Tue, 11 Dec 2001 13:57:37 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> H Subject: Re: Writing a device driver: virtual/physical address questions2 Message-ID: <3JsR7.435$BK1.13816@news.cpqcorp.net>  J Well, I wouldn't say that it is a good practice for a device to know aboutE page table formats.  Makes it platform, and perhaps even OS specific.v  I The next really fast thing, especially for network adapters will be PCI-XbK and message based interrupts.  A message based interrupt method removes the J need for the device to stop, and wait for the interrupt to be reset by theJ driver (which also generally requires a PCI read, which does bad things toK bus performance - since the read waits for pending writes to be completed).u    $ Jan Vorbrueggen wrote in message ...J >Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes: > K >> I was curious about the DEC devices because I seem to remember that somee@ >> VAX stuff (maybe CI) could read the VAX page tables directly. >eH >Yes, all CI adapters on VAX do that, I suspect that's true of Alphas as well, I >though I know the ones that are in the same chassis (VAX/DEC 7000/10000). areE= >loaded with different microcode depending on processor type.a >cF >Really fast network adapters should do that as well. How about memory channel?/ >I think those just map windows into PCI space.  >  > Jan    ------------------------------  # Date: Tue, 11 Dec 2001 20:01:23 GMTr+ From: Jeff Campbell <jcampbell@ins-msi.com>pH Subject: Re: Writing a device driver: virtual/physical address questions* Message-ID: <3C165D91.94BC555@ins-msi.com>   Jan Vorbrueggen wrote: > K > Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:  > L > > I was curious about the DEC devices because I seem to remember that someA > > VAX stuff (maybe CI) could read the VAX page tables directly.  > O > Yes, all CI adapters on VAX do that, I suspect that's true of Alphas as well, N > though I know the ones that are in the same chassis (VAX/DEC 7000/10000) are> > loaded with different microcode depending on processor type. > P > Really fast network adapters should do that as well. How about memory channel?0 > I think those just map windows into PCI space. > 
 >         Jan   L The Qbus RQDX3 disk(ette) controller can read the uVAXII Qbus mapping array. Does that count?  8-)o   Jeff n8wxs@arrl.net   ------------------------------  % Date: Tue, 11 Dec 2001 19:29:34 +0000n% From: "a.carlini" <arcarlini@iee.org> H Subject: Re: Writing a device driver: virtual/physical address questions' Message-ID: <3C165E9E.5843D934@iee.org>    Simon Clubley wrote:I > Yes, that's what I thought. It's been true for every device spec that I I > have seen. (Although I am new to writing drivers _on VMS_, I am not newtL > to hardware programming in general...) I was curious about the DEC devicesF > because I seem to remember that some VAX stuff (maybe CI) could read > the VAX page tables directly.1  ' Yes, CI on VAX could do that (I think).r  . Cretainly the DMB32 could run in several modes0 where it had carnal knowledge of the OpenVMS VAX- page table structure. Fortunately it could be * persuaded to run in other modes, otherwise. the late-in-life changes to the VAX page table0 structure would have proved somewhat burdensome!   Antonioi     -- m   --------------- - Antonio Carlini             arcarlini@iee.org    ------------------------------   End of INFO-VAX 2001.689 ************************