1 INFO-VAX	Sat, 11 Aug 2001	Volume 2001 : Issue 443       Contents:( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate Re: Alphabooks  Re: BACKUP (was Re: Red Code...)  Re: BACKUP (was Re: Red Code...)6 Re: Backup disk on one system to tape drive on another. Re: Can queue manager handle 100.000 entries ?. Re: Can queue manager handle 100.000 entries ?. Re: Can queue manager handle 100.000 entries ? Re: Flip-Chip" FYI 	 Re: HSD10 8 Re: HWRPB (Alpha) blundering in the dark - info required= Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel 1 Re: Installing V7.3 on Personal Workstation 500au 6 Re: IPF Console Bootstrap (was: No chance for OpenVMS) Re: Linker-Warnings in VMS 7.3 Re: Linker-Warnings in VMS 7.3 Re: Linker-Warnings in VMS 7.3 Re: Linker-Warnings in VMS 7.3 Re: Linker-Warnings in VMS 7.31 Re: Looking for a Pine.exe for TCPIP 5.x services * Re: Microsoft and Code red (Cisco as well)* Re: Microsoft and Code red (Cisco as well) Re: Missing TK50 in uVAX?  Re: Missing TK50 in uVAX?  RE: Missing TK50 in uVAX?  Re: Move to Sun  Re: Move to Sun ' Re: MS610-EA ES40 Memory - Very Cheap !  Re: NTP  Re: OpenVMS  + Itanium Re: OpenVMS  + Itanium2 Re: OpenVMS apps and Compaq committment story here2 RE: OpenVMS apps and Compaq committment story here2 Re: OpenVMS apps and Compaq committment story here Re: Press Release  Re: Press Release  Re: Press Release  Query string problem with CSWS. # Re: Query string problem with CSWS. ! Re: Red Code: where are we going? ! RE: Red Code: where are we going? ! Re: Red Code: where are we going?  Re: Server up? Re: Server up? RE: Server up?0 Re: Slow time and bad memory - are they related?& Re: The VMS Opensource Porting Project Re: Third postcard from Sun  Re: Third postcard from Sun P VMS: Nothing Stops It (was "I just have to post this - and apoligse later Alpha/ Re: We've launched TAPESYS v6.0   F ----------------------------------------------------------------------  % Date: Fri, 10 Aug 2001 17:48:41 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com>1 Subject: Re: Alpha:  an invitation to communicate * Message-ID: <3B741069.D39BABF1@uk.sun.com>   jlsue wrote: > 5 > On Fri, 03 Aug 2001 17:17:51 +0100, andrew harrison # > <andrew.nospam@uk.sun.com> wrote:  >  > >  > >jlsue wrote:  > >>D > >> I see.  So if you document a particular behavior, and then someJ > >> competitor complains that it does exactly what it's documented to do,+ > >> then you should fix it.  Yeah.  Right.  > >> > > ? > >Sorry that isn't what you did, try again. You documented the ; > >fact of the 3x difference and then went on to claim that 8 > >this was near UMA and that it would not be a problem. > B > Exactly.  But it is correct.  Yes or no.  If it is, then there'sA > nothing to fix.  But that's not to say that you may not want to ; > improve, if possible, and that's for the next generation. E > The fact still remains that it was disclosed in the white paper you  > keep complaining about.  >   A No it isn't correct. 3x isn't near UMA and yes it is a problem as - your TPC-C, Oracle Apps and SAP results show.   H > You haven't proven that it's that much of a problem in the real world. >   ? Sorry you have proved it is a problem. Both SAP and Oracle Apps ? were run without being able to use OPS on WildFire and in both  D cases WildFire turned in significantly slower results than expected.  B Both are real world applications. They are in fact the only other @ OLTP benchmark results that you have published for the WildFire.  @ If you hadn't published these results then your conjecture wouldF be more plausible, the fact that you have makes this an unsupportable  possition for you to take.   Get used to it.      Regards  Andrew Harrison  Enterprise IT Architect    ------------------------------    Date: 10 Aug 2001 18:52:01 -07003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com> 1 Subject: Re: Alpha:  an invitation to communicate 0 Message-ID: <qh7kwb5poe.fsf@ruckus.brouhaha.com>   yyyc186@mindspring.com writes:I > If the brain surgeon can't sterilize the scalpal they are about to use, E > then they are completely incompetent.  If the brain surgeon doesn't L > realize they actually have to have the staples for the staple gun in order2 > to seal the incision, then they are incompetent.  J Actually, neither sterilizing the scalpel nor making sure that the staples2 are present are the responsibility of the surgeon.  6 But then, analogies are often like flawed comparisons.   ------------------------------  % Date: Fri, 10 Aug 2001 03:34:00 -0600 + From: Ben Franchuk <bfranchuk@jetnet.ab.ca> 1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B73AA88.61090440@jetnet.ab.ca>   Eric Smith wrote:  >   > yyyc186@mindspring.com writes:K > > If the brain surgeon can't sterilize the scalpal they are about to use, G > > then they are completely incompetent.  If the brain surgeon doesn't N > > realize they actually have to have the staples for the staple gun in order4 > > to seal the incision, then they are incompetent. > L > Actually, neither sterilizing the scalpel nor making sure that the staples4 > are present are the responsibility of the surgeon. > 8 > But then, analogies are often like flawed comparisons.  D But then you can't expect most brain surgeons to have much practice.J How often does a "live" brain show up for medical school training practiceI and the people stupid enough to volunteer don't have great quality brains  in the first place. :-)  Ben  --  > Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.< "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics.   ------------------------------  # Date: Fri, 10 Aug 2001 14:29:39 GMT - From: goathunter@goatley.com (Hunter Goatley)  Subject: Re: Alphabooks 0 Message-ID: <3b73efbd.96060818@news.process.com>  K On Thu, 09 Aug 2001 21:52:44 -0700, Tom Crabtree <tccrab@sunset.net> wrote:   K >Alphabooks are not an urban myth, although most of us have never seen one. I >They were rare to begin with (and expensive) and are even more rare now. J >Tadpole Technology sold them originally, maybe they know or keep track of0 >people selling them.  Their link is as follows: >http://www.tadpole.com  > ? A year ago, they were still selling refurbished Alphabooks.....    Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 9 goathunter@goatley.com     http://www.goatley.com/hunter/    ------------------------------    Date: 10 Aug 2001 16:56:52 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) ) Subject: Re: BACKUP (was Re: Red Code...) 3 Message-ID: <AvdTGPPWCBR$@eisner.encompasserve.org>   e In article <g2Yc7.28$bB1.4624@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: A > "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> wrote in message - > news:hdRc7.349$4_4.48825@news.uswest.net...  > E >   I have not seen the earlier portions of this thread, as I was not D >   particularly interested in Code Red discussions.  I now see that! >   the discussions have changed.  >  > : ... L > : Amazing statement, since I have lost data with the VMS backup due to theN > : complexity of it's command line, yet I have never lost data with the builtK > : in NT4 or W2K backup software - and yes, I've had to restore from both.  > :... >  >   So?  > < >   The following BACKUP command causes all data to be lost: > ; >     $ BACKUP criticaldisk:[*...]*.* NLA0:SAVESET.BCK/SAVE    You left off the /DELETE :-)   ------------------------------  # Date: Fri, 10 Aug 2001 21:07:24 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)) Subject: Re: BACKUP (was Re: Red Code...) 0 Message-ID: <g2Yc7.28$bB1.4624@news.cpqcorp.net>  ? "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> wrote in message + news:hdRc7.349$4_4.48825@news.uswest.net...   C   I have not seen the earlier portions of this thread, as I was not B   particularly interested in Code Red discussions.  I now see that   the discussions have changed.    : ... J : Amazing statement, since I have lost data with the VMS backup due to theL : complexity of it's command line, yet I have never lost data with the builtI : in NT4 or W2K backup software - and yes, I've had to restore from both.  :...     So?   :   The following BACKUP command causes all data to be lost:  9     $ BACKUP criticaldisk:[*...]*.* NLA0:SAVESET.BCK/SAVE   A   The other interface to the BACKUP utility is the BACKUP$MANAGER B   tool, an interface that is designed to be easier to operate, but%   accordingly somewhat less flexible.   C   I've regularly seen restoration problems with BACKUP due to media E   errors or device errors, and I've seen cases where I've not caused  :   the necessary data to be written to the archive saveset.  E   There are failure modes for most (all?) archiving tools, regardless    of the platform.  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: Sat, 11 Aug 2001 00:31:21 +0200 (CEST): From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>? Subject: Re: Backup disk on one system to tape drive on another J Message-ID: <Pine.LNX.4.21.0108110002570.32195-100000@irys.stanpol.com.pl>  ( On Thu, 9 Aug 2001, Brian Tillman wrote:   >+>Possibilities:  >+> G >+>1. Install and configure DECnet on the second node.  If you have the 8 >+>licenses, this is likely the fastest and easiest way. >+ >+Sorry, but that won't help.   7  Excuse me, but the sentence may be little wrong ;) and ( you themself say that that *may* help :)  0 >+    You can't reference remote tape drives via! >+DECnet with the BACKUP command.   B  Hm... You can reference, that "only" may not work as expected -;)& (excuse the little malice, please :)!)  - >+  The only time BACKUP allows a remote file M >+specification is when you're referring to an on-disk saveset.  They already M >+said they don't have enough disk space for an on-disk saveset that can then ! >+be COPYed to the remote device.  >+L >+There might be another DECnet-based solution, however.  Years ago, someoneM >+posted a task-to-task example of writing a saveset to a remote system, with = >+the DECnet task on that system actually doing the tape I/O.   ?  Really, and I also do that before have found that the problem   is old as VMS :)    The major point was: : - something like CONVERT may be good on the "server" side,6  without this the RMS format is "variable" (and wrong)8 - the task must MOUNT/FOREING the tape, and the point isH  the first reason of problems (remote FAL cannot mount a tape/FOREIGN !)> - correction for RMS network buffers count is required, except;  cases when you has interest with small save-set block size =  (the default of RMS default NBC is too small to save typical   save-set block !)  2  Fixed-value TASK example is described in FAQ... !    Regards - Gotfryd   --  E ===================================================================== F $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME . $!                        GS@stanpol.zabrze.plE =====================================================================    ------------------------------  # Date: Fri, 10 Aug 2001 18:34:10 GMT 3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk> 7 Subject: Re: Can queue manager handle 100.000 entries ? / Message-ID: <3B74276B.9725034E@cableinet.co.uk>    Jan-Erik Sderholm wrote:  > 4 > Well, shutting down for the day (or rather night).	 > Status: 8 > - 87.488 queue entries (highest entry number 8007488).D > - QMAN process "Peak WS" = 198.656 and "Peak virt size" = 422.336.A > - sys$system:sys$queue_manager.qman$journal now 257.142 blocks. ( > - Two more reboots due to "INSVIRMEM".  ' Hi, so you are trying some tests! Good.   D Anyway, once the INSVIRMEM and whatever else is configured once you  should be ready for production.   	 > Notes : : > - Still adding aprox 6 entries/second as from the start. >   No slowdown.  : not exactly fast, though is it. WHat is the system doing?  CPU, IO, paging?   H > - Takes "forever" to START/QUE/MAN, say 5-10 minutes on my 150Mhz box.  ' Whats that, 3000-300 box? How much RAM?   = > - Can the "journal" be sized when doing START/QUE/MAN/NEW ?    Apparently not, see M http://www.openvms.compaq.com:8000/73final/6017/6017pro_054.html#start_q_mgr     Optimization tips are atJ http://www.openvms.compaq.com:8000/73final/6017/6017pro_055.html#qman_perf4 As expected it seems to be CPU and disk I/O limited.   > 2 > I hope to reach the 100.000'th entry tomorrow...   regards       --   Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.    ------------------------------  # Date: Fri, 10 Aug 2001 18:56:30 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)7 Subject: Re: Can queue manager handle 100.000 entries ? 0 Message-ID: <y7Wc7.24$bB1.4493@news.cpqcorp.net>   In article <y4y9os70of.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:5 :hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:  : L :>   Each queue manager can handle a maximum of one hundred thousand entries : ' :Didn't you mean to say 99999 entries?    I   Yes.  Given that there is no zero entry number possible in the current     design...   N :Is this more related to displaying entry numbers than any inherent limitationM :in the code? Even with three blocks per entry, a normal 36 GB disk should be * :able to contain about 20 million entries.  *   This number was derived from the design.  F :>   Up to five queue managers can be sharing the same queue database. : O :Is this limitation dictated by locking scalability considerations, or just the ( :limit of your testing and thus support?     Does it matter?   B   If there is a serious requirement for more entries or more queueC   managers, please contact the Customer Support Center and request  
   assistance.   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: Fri, 10 Aug 2001 14:39:24 +0200 < From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>7 Subject: Re: Can queue manager handle 100.000 entries ? ( Message-ID: <3B73D5FC.F3E61377@home.com>    OK. My final post on this issue.  1 My DCL script happily passed the "9009999" limit. 3 It begun counting "10000000", "10000001" and so on. 2 (In the message from the $PRINT command, that is.)  < Doing "SHO QUE/OUT=somefile" and "SEA/STAT somefile Pending"< shows "100017 records matched", so SHO QUE can actualy "see" 100017 uniqe entries.   ? SHO /QUE/SUM says ""Job summary : 34481 pending (100017 blocks) / The number of block is OK, but the count isn't.    The SHO QUE output ends with :      Entry  Jobname ...     -----  ------- ...  9009998  9009999  *******  *******N  ! Just an formatting issue maybe !?    Doing : 9 $ enr = f$getqui("display_entry","entry_numner",10000002)e $ sh sym enr gives : = ENR = 10000002   Hex=<some hex value>  Octal=<some oct value>l  	 Seems OK.   D So the only "limit" to 100.000 (or 99.999) entries that I can "see",H is in the output formatting of SHO QUE, and in the wrong number returned from SHO QUE/SUM.?   Well, that's all :-)   Jan-Erik Sderholm.?   ------------------------------  % Date: Fri, 10 Aug 2001 17:20:40 -0400  From: Ray <lists@aik.tec.sc.us>i Subject: Re: Flip-Chip"u- Message-ID: <3B745028.75C8CC06@aik.tec.sc.us>s   Hi Dan,h  A I did a little work on the new Flip-Chip technology about 8 yearseF ago (strangely at a former DEC site).  We were working with IBM-Japan D and it was my understanding that they developed it.  Another strangeD thing was that the only software that could be used to design boardsE for flip chips back then, ran on Sun Sparc Stations.  So there I was  ? a former DEC employee using Sun equipment with IBM technology. h  @ It was initially used in PCMCIA cards due to limited space, but ? the advantage of no extra leads between the chip and the board a  made higher clock speeds easier.  A Anyway, Intel is not alone in using the Flip-Chip term.  Actuallyu% they are several years behind others.e   Ray/   ------------------------------  % Date: Fri, 10 Aug 2001 09:19:31 -0400 2 From: "Sue Skonetski" <susan.skonetski@compaq.com> Subject: FYI0 Message-ID: <5bRc7.16$bB1.4242@news.cpqcorp.net>   Dear Newsgroup,a  F I just wanted to let you know, that I am unable to respond to all yourL email.  I have damaged my hand, and one handed typing is way to slow and the? cast hits wrong keys, so please do not think I am ignoring you.e   sueP   ------------------------------    Date: 10 Aug 2001 20:56:18 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)0 Subject: Re: HSD10, Message-ID: <J5KntJ82fwvU@malvm5.mala.bc.ca>  ( In article <3B74A6C6.4AB9EE1C@fsi.net>, 6    "David J. Dachtera" <djesys.nospam@fsi.net> writes:   > MikeWJ wrote:p >>  . >> I know that the HSD10 has a DSSI connector. >> tM >> BUT...is there an HSD10 model that has a SCSI connector, so that it may bea0 >> attached to a MicroVAX 3100 as a SCSI device? >  > SCSI would be HSZsomething...e > 5   There's the RaidArray 310 ( with an HSZ20 inside ).o  :   The problem is that its SCSI output is Wide/Differential; and the MicroVAX 3100 needs Narrow/Single Ended. The actual < HSZ20 is Single-Ended SCSI - there's a board in the box that> converts it to differential. It might be possible to cobble up; a cable to bypass the SE/Diff converter, I'm not sure aboutd  the Wide-to-Narrow issue though.  9   Of course you could get a PWSxxx for under $1000, sticke< a differential SCSI card in it, connect it to the Raid Array3 310 and then cluster that to the MicroVAX 3100. Addr< $6000 or so if you have to buy the VMS/Cluster licenses. ;-)   ------------------------------  % Date: Fri, 10 Aug 2001 23:47:50 +0100s+ From: "antonio.carlini" <arcarlini@iee.org>uA Subject: Re: HWRPB (Alpha) blundering in the dark - info required & Message-ID: <3B746496.9A5F16B@iee.org>   Patrick Young wrote:B > download area). Not much use regarding the SRM console though. I3 > remember kind of expecting SRM source code when Ia( > bought it :-( - only SRM flash images.  ( SRM sources were not generally available* even within Digital. The EBSDK should have, the SR*O*M sources for at least some boards.  F > All references to this manual confused me in the first instance as IG > did not (and still have not) found an electronic copy. my belief is I.E > am looking at (parts of) the handbook (advertised as) the reference   ( The handbook is available electronically, (at least, I've just found a copy I stashed ' away some time ago). I *thought* that Ii* had a copy of the AARM in PDF but I cannot& locate it and it might just be wishful thinking on my part :-)s   Antonioa   -- r   --------------- - Antonio Carlini             arcarlini@iee.orgt   ------------------------------  % Date: Fri, 10 Aug 2001 14:34:07 -0400o2 From: rdeininger@mindspring.com (Robert Deininger)F Subject: Re: I just have to post this - and apoligse later Alpha/IntelL Message-ID: <rdeininger-1008011434080001@user-2ivea65.dialup.mindspring.com>  5 In article <3B7420E3.FBF1AEB1@videotron.ca>, JF Mezeib% <jfmezei.spamnot@videotron.ca> wrote:d   > Robert Deininger wrote:hL > > These have been answered also.  The current servers will not support EV7N > > via board swap; a system swap will be required. (This was known before the > > big announcement.) > P > But when Wildfire was announced, they made a lot of noise about the ability ofN > wildfires to add new boards that were not necessarily the same generation as8 > the existing ones, preserving your investment etc etc.  J And those CPU upgrades have since been announced, at least the first batchD of them.  They are not EV7 upgrades, and they are not IPF.  They areI faster EV6x upgrades.  Maybe that doesn't fit your personal definition ofg "next generation".   M > Are you saying that this no longer holds true and those that currently havehO > wildfires on EV6x will have to ditch their wildfire if they want to upgrade ?e  D That has been well-known for quite some time.  The current GS-seriesF systems are not deemed to be a good match for EV7.  The current memoryJ architecture isn't good enough for EV7, and I believe the current crossbarJ switch doesn't scale up to many CPUs as well as was originally hoped. Next& generation systems are in development.   -- 1 Robert Deininger rdeininger@mindspring.com    ------------------------------   Date: 10 Aug 2001 21:07:17 GMT5 From: koehler@bessta.gsfc.nasa.aspm.gov (Bob Koehler)tF Subject: Re: I just have to post this - and apoligse later Alpha/Intel/ Message-ID: <9l1ie5$otr$1@skates.gsfc.nasa.gov>e  \ In article <3B72CB10.4248EA6D@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: >Sue Skonetski wrote:l  N >>     This was not a Compaq (Houston) directive but a technical decision made$ >> by Alpha engineers that you know. >fK >Sue, this statement kills credibility. It becomes very clear that you have L >been assimilated by the borg and must now tow the party line. Read your ownL >web site and you will see that Alpha had lots of technical superiority over >Intel's IA64. >   C Word out now that the technical folks designing the followon to thetG newest series of Alpha servers initiated the move.  Alpha has technicalaF superiority now (Compaq has it now?) but it appears it is not going to8 maintain performance superiority (Digital had it when?).  H Sounds to me like Sue is credible, but maybe she should have said "AlphaG server engineers" instead of "Alpha engineers" which may have been read  as "Alpha chip engineers".  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = GSFC Code 582 Flight Software   | Federal Sector, Civil GrouplI                                 | please remove any ".aspm" when replyinga   ------------------------------    Date: 10 Aug 2001 14:16:02 -0700+ From: mend0070@tc.umn.edu (Phil Mendelsohn)rF Subject: Re: I just have to post this - and apoligse later Alpha/Intel= Message-ID: <9fffd0d8.0108101316.62d9d250@posting.google.com>-  D The real issue here, is that Compaq appears to be in the business of, making rather than that of making computers.   ------------------------------  % Date: Fri, 10 Aug 2001 17:22:15 -0400@' From: "Bill Todd" <billtodd@foo.mv.com><F Subject: Re: I just have to post this - and apoligse later Alpha/Intel( Message-ID: <9l1jai$o40$1@pyrite.mv.net>  B "Bob Koehler" <koehler@bessta.gsfc.nasa.aspm.gov> wrote in message) news:9l1ie5$otr$1@skates.gsfc.nasa.gov...s   ...   E > Word out now that the technical folks designing the followon to theeI > newest series of Alpha servers initiated the move.  Alpha has technicaldH > superiority now (Compaq has it now?) but it appears it is not going to: > maintain performance superiority (Digital had it when?). >IJ > Sounds to me like Sue is credible, but maybe she should have said "AlphaI > server engineers" instead of "Alpha engineers" which may have been reado > as "Alpha chip engineers".  I Or perhaps Compaq has finally found a group of engineers willing to mouthB! the words the brass feed to them.E  J It will be very interesting to hear exactly what aspects of the Alpha chipL aren't as amenable to use in servers as is IA64, since on the face of it theL situation is exactly the opposite.  But I'm sure we're all willing to listenF and draw our own conclusions, so exactly where can the details of this 'word' you speak of be found?    - bill   >tH > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences Corporationn? > GSFC Code 582 Flight Software   | Federal Sector, Civil GrouptK >                                 | please remove any ".aspm" when replyingI >v   ------------------------------  % Date: Fri, 10 Aug 2001 18:19:22 -0400,- From: JF Mezei <jfmezei.spamnot@videotron.ca> F Subject: Re: I just have to post this - and apoligse later Alpha/Intel+ Message-ID: <3B745DE8.BF0FF38@videotron.ca>K   Robert Deininger wrote:fL > And those CPU upgrades have since been announced, at least the first batch > of them. b  F > That has been well-known for quite some time.  The current GS-series4 > systems are not deemed to be a good match for EV7.  K I am very disapointed in this. Capellas had made a point to say a couple of L times that if you boght a wildfore now (back during the launch) you would beI able to add CPU blocks of newer generations of CPUs preserving your multi. million dollar investment.  K But now, it seems that this was only applicable to the same generation withl just a newer faster chip.   K I assume that from a legal point of view, Compaq delivered what it claimed.-L However, considering the death of Alpha and the image that the few remainingK customers that Compaq cares about are all large shops likely to be wildfire L based, will they really bother to go EV7 if it means that they have to ditch their wildfire ?  D Perhaps Compaq would be better off continuing to improve EV6 line byF increasing clock speed which would allow the wildfires to be upgraded.   ------------------------------   Date: 10 Aug 2001 19:13 CDT ' From: carl@gerg.tamu.edu (Carl Perkins) F Subject: Re: I just have to post this - and apoligse later Alpha/Intel- Message-ID: <10AUG200119131801@gerg.tamu.edu>e  1 JF Mezei <jfmezei.spamnot@videotron.ca> writes...oE }Perhaps Compaq would be better off continuing to improve EV6 line by G }increasing clock speed which would allow the wildfires to be upgraded.H  D They are. As far as I can tell, they still plan to do another shrinkC (which would be the EV69). Of course, that assumes that their newly ! revised "roadmaps" are correct...e   --- Carl   ------------------------------  % Date: Fri, 10 Aug 2001 21:31:28 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> F Subject: Re: I just have to post this - and apoligse later Alpha/Intel, Message-ID: <3B748AF0.AB30ABD5@videotron.ca>   Carl Perkins wrote:sF > They are. As far as I can tell, they still plan to do another shrinkE > (which would be the EV69). Of course, that assumes that their newly # > revised "roadmaps" are correct...o    ( But isn't EV7 sort of a waste of money ?  G The effort put in for lockstep is wasted since Tandem won't run on EV7.tM And the current customers of wildfires won't really be investing in EV7 since * it isn't compatible with their mainframes.  M So who is left to buy EV7s at a time when competing companies will already bek> on what, according to Compaq, will be the chip of the future ?   ------------------------------  % Date: Fri, 10 Aug 2001 21:58:58 -0400m' From: "Bill Todd" <billtodd@foo.mv.com> F Subject: Re: I just have to post this - and apoligse later Alpha/Intel( Message-ID: <9l23h6$72h$1@pyrite.mv.net>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messageEF news:rdeininger-1008012127580001@user-2ivech6.dialup.mindspring.com...   ...   I > EV68 is arguably a newer generation.  But it's a silly question anyway.=" > Unless the so-called commitments  L As I pointed out before, if you don't like the term, take it up with Compaq: they chose it.  "  promised particular architecturalH > features, or specific performance levels, then Compaq could meet these0 > "commitments" by relabeling the EV68 as a EV7. > E > When Wildfire was launched, how many specifics of EV7 had been made I > public?  I suspect anything they published would have had "preliminary"" > written all over it. >kH > EV8 was in the "preliminary" state right up until it was cancelled.  IL > don't understand how people can talk about "commitments" in the context of. > such incompletely-specified future products.  L Then, again, take it up with Compaq:  the Heil/Lipcon 'commitment' letter (II don't know the date it was published, but someone recently said 18 months.G ago, which if so noticeably pre-dated the Wildfire launch you mentioneddH above) specified simultaneous multi-threading by name (and with specificD references to a related MicroProcessor Forum presentation) as an EV8 feature.     I still see people whiningL > that Compaq broke a "commitment" to build EV9 and EV10.  Those were almost > pure vaporware.1  H But nonetheless called out as 'commitments' in the Heil/Lipcon letter ofJ reassurance that Alpha technology was indeed a safe bet for the long haul.  L It really takes a special kind of asshole to call people 'whiners' when they' hold a company to its written promises.    - bill   ------------------------------  % Date: Fri, 10 Aug 2001 13:48:50 +0100e( From: Nic Clews <sendspamhere@127.0.0.1>F Subject: Re: I just have to post this - and apoligse later Alpha/Intel) Message-ID: <3B73D832.BDFA33DE@127.0.0.1>c   Here's my take.a  B Marketing and PR have never been the strong points of VMS from the Digital days till even now.p  C Compaq could have handled this much better. Still too many "companyuH confidentialities". We're all intelligent people here, publish them with/ a disclaimer, it would help build up the trust.o  , May I be so bold as to say Alpha has failed?  H It is NOT as Digital intended a chip running multiple operating systems.F When NT was lost, that was it. History. (Two of your own don't count).  H Performance. Speed is not everything to _VMS_ customers, never has been.G If it was to you, you'd be replacing your slower Alphas with GS320s andt ES45s.  G With regard to intel reliability, take your heads out the sand and take > a look at the Proliant systems. Have a laugh at the claims and> capabilities of the software,  but you'll deserve the title ofH 'philistine' if you don't agree that the hardware capabilities today are
 very good.  G In summary, it's the marketing thats the issue. You need to address the G non-VMS base, not us, we're the converted. many in unix land think thataH Digital have been talking about the death of VMS for years. This is whatA you have to counter, and it's a bigger challenge that the 'port'.-  D Sending "Mark Twain" quotes is cute, but it needs to go to the right$ people, otherwise it's wasted money.  D How can I explain this better. Don't bother sending mailshots to theH Porche drivers telling them that a Porche is a great car, send it to theH Mercedes and Lexus drivers. Sending it to the guys getting driven in the% back of the Porche would be good too.e   --  ( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comn   ------------------------------  % Date: Fri, 10 Aug 2001 13:55:26 +0100t* From: "Richard Brodie" <R.Brodie@rl.ac.uk>F Subject: Re: I just have to post this - and apoligse later Alpha/Intel, Message-ID: <9l0lk1$1t7u@newton.cc.rl.ac.uk>  d "Rudolf Wingert" <win@fom.fgan.de> wrote in message news:200108100603.IAA20920@sinet1.fom.fgan.de...  J > P.S. Alpha to IA 64 (64bit to 64bit) will be never an upgrade. It is theG >      same level, other design. Alpha to Playstation (64bit to 128bit)b >      would be an upgrade.H  ; It's hard to tell from here but that was a joke, wasn't it?-   ------------------------------  % Date: Fri, 10 Aug 2001 14:13:23 +0100s% From: Alan Greig <a.greig@virgin.net>qF Subject: Re: I just have to post this - and apoligse later Alpha/Intel* Message-ID: <3B73DDF3.2397EB30@virgin.net>   Nic Clews wrote:   > HK  . > May I be so bold as to say Alpha has failed? >iJ > It is NOT as Digital intended a chip running multiple operating systems.H > When NT was lost, that was it. History. (Two of your own don't count). >d  I And indeed many people said at the time that one possible explanation for G dropping Alpha/NT *after* completing the port was to prepare the way togH phase out Alpha at EV7. In fact at the time I said "I do not have a warmI fuzzy feeling about EV8 and beyond". If you read generic Compaq publicityrD statements you will not get the impression they are committed to anyI non-Wintel technology with the reluctant exception of Linux. Trusting theaE publicity aimed directly at Alpha users has not, in the past, allowednF customers to accurately predict the future. Reading the generic Compaq( publicity and VP speeches has however...  H Oh and as to the count of operating systems I make it three of their ownI plus one other. VMS, Tru64, NSK (supposedly committed) and Linux (perhapseJ even a FreeBSD port?). And NT wasn't 'lost'. If I intentionally tossed  myI cellphone into the trash can could I legitimately claim it 'lost' from my-! insurance company? I think not...:  * > Regards, Nic Clews CSC Computer Sciences > nclews at csc dot comc   --
 Alan Greig   ------------------------------   Date: 10 Aug 2001 22:20 CDTu' From: carl@gerg.tamu.edu (Carl Perkins)lF Subject: Re: I just have to post this - and apoligse later Alpha/Intel- Message-ID: <10AUG200122201264@gerg.tamu.edu>   1 JF Mezei <jfmezei.spamnot@videotron.ca> writes...u }Carl Perkins wrote:G }> They are. As far as I can tell, they still plan to do another shrinksF }> (which would be the EV69). Of course, that assumes that their newly$ }> revised "roadmaps" are correct... }  } ) }But isn't EV7 sort of a waste of money ?" } H }The effort put in for lockstep is wasted since Tandem won't run on EV7.N }And the current customers of wildfires won't really be investing in EV7 since+ }it isn't compatible with their mainframes.e } N }So who is left to buy EV7s at a time when competing companies will already be? }on what, according to Compaq, will be the chip of the future ?b  H Anybody who wants more processing power than the EV6 boxes can give them@ and doesn't want to switch OSes (or, for watever reason, can't)?  K When someone buys a large system, how many "in-box" upgrades do they expectlG to get? Clearly nobody expects to use the same box forever. "Fork-lift"uK upgrades are inevitable. Any given person/company's answer to this questionrC will influence whether or not they think buying an EV7 is worth it.h  K After EV7 (although there will never be a plain EV7, the first one actually I available will be the EV78) comes out, in it's shiny new systems, they do-I say that there will be a shrink (EV79) which means that you'll be able toaG upgrade at least once. Each will probably have at least one faster, butnI same process, version released later as seems to be the standard practice:G (relase at speed X, bump up later to speed X+Y) which would allow for aeH second upgrade, or more if they have more speed-bump releases. So that'sI at least two upgrades, probably three or more - you might get an originaliK EV78 at speed A, upgrade to an EV78 at speed B, upgrade to EV79 at speed C, I and then again to an EV79 at speed D for a total of three in-box upgradesiG after the original purchase (and, if you are lucky, there could be morem7 than one speed increase for each, especially the EV79).e  E Buying an EV7 system when they first come out doesn't seem to be muchtH of a problem - you might not get as many in-cabinet uprades as you mightI prefer, but you should get at least two, probably 3, and maybe more. (HowlG many board swap upgrades are there for a DS10? None. But they still getiH bought. How many have there been for a DS20? One? The ES40? One? I'm notJ really sure for either of those. I don't know how many there have been forL the GS series systems, old 8x00 style or new. Is it more than three? I thinkD the old-style ones have had 4 or 5 across two generations of Alpha.)  H Buying one later might be a problem - at least until the make the systemJ that is board compatable with the IPF boards. After that, it is a questionJ of "does it make sense to get an Alpha now and 'upgrade' to the IPF boards? later, since that also involves changing out all the software?"w   --- Carl   ------------------------------  % Date: Sat, 11 Aug 2001 01:04:12 -0400a( From: Hamlyn Mootoo <univms@bigfoot.com>F Subject: Re: I just have to post this - and apoligse later Alpha/Intel+ Message-ID: <3B74BCCC.36612E2C@bigfoot.com>m   Sue Skonetski wrote:   We have asJ > number of engineers in VMS (around 400) and are hiring some more for the > porting project.  G Care to release names of these 400. (I'm guessing most of them wouldn'toD mind)?  Also, this "HIRING".  When Compaq sold those machines in theD article to the military, was it in exchange for some sort of stealthF technology related to hiring?  Or is this another cross application ofE Compaq's stealth VMS marketing technology?  Hiring? For the VMS port?sE Where????????  I see the recruiters advertising for Linux and True-64y porting help, but not VMS.     HM   ------------------------------  % Date: Sat, 11 Aug 2001 00:21:28 -0400P- From: JF Mezei <jfmezei.spamnot@videotron.ca>aF Subject: Re: I just have to post this - and apoligse later Alpha/Intel, Message-ID: <3B74B2B9.222ED4B5@videotron.ca>   Robert Deininger wrote:0J > The wildfire replacement systems will work with EV7, and will be able to4 > accept IPF replacement CPUs, from what I've read.   N Has such a commitment been made public ? Would Compaq actually commit on paper
 for this ?  M Unless both Alpha and IA64 can co-exist on the same Wildfire equivalent "box"lN allowing for a progressive migration of CPUs from one to the other,  what goodN does it do to buy one of those IA64 comptible wildfires loaded with EV7s sinceK you'll need to buy yet another one loaded with IA64s to allow you to switch  off the ALPHA one ?y  J You're better off upgrading your existing EV6 based wildfore and once IA64J becomes available, you can then buy one of those new wildfores loaded with> IA64s and then proceed with the migration from one to another.       > EV7 really means EV7x,= > since there will be several generations if there is demand.e  I Are you sure ? I was under the impression that Compaq was to send all EV7?L engineers to Compaq as soon as EV7 is done. Who would be there to make those new generation EV7x ?t  I Also, unless there are massive changes in Compaq management, it is to the.H advantage of the existing Compaq heads to allow IA64 to surpass Alpha asN quickly as possible. Remember that their excuse for killing Alpha is that IA64 would become faster than Alpha.t   ------------------------------  % Date: Fri, 10 Aug 2001 22:32:42 +0100m9 From: "Colin Butcher" <colinDOTbutcherATxdeltaDOTcoDOTuk> : Subject: Re: Installing V7.3 on Personal Workstation 500au@ Message-ID: <997478968.4330.0.nnrp-12.9e98f8e9@news.demon.co.uk>  K RE: Installing V7.3 on Personal Workstation 500auDepending on the model youmH might find several device types for the CDrom. The "officially runs VMS"E variant had a SCSI CDrom because back then (V7.1-1H1 days) VMS didn't-/ support IDE devices. VMS V7.3 does support IDE.@  I My PWS 500AU was originally an NT variant, so has IDE CDrom. However it'st running VMS V7.3 just fine.a  J So, simply install the latest firmware update (V5.9 or V6.0) from CD, thenI boot the VMS CD from DQA0 (IDE) or DKA400 (or whatever SCSI device it is)aD and off you go installing VMS V7.3 to your target system disc deviceL (DKcnnn:). The advice elsewhere on multiple SCSI adapters is sensible - haveI more than one if you can. I use one for slow stuff (CDs, CD-R, tape etc.)t, and another couple for faster stuff (discs).  L >>>SHO DEV and >>>SHO CONF are useful console commands, as is >>>SET OS_TYPE VMS.  L The console commands are documented in the manuals. You can find most of theF manuals on the web as the "out of production models" part of the Alpha* workstation section of the Compaq web siteC (http://www.compaq.com/alphaserver/workstations/retired/index.html)n   -- Hope this helps. Colina# (colinDOTbutcherATxdeltaDOTcoDOTuk)m   ------------------------------  % Date: Fri, 10 Aug 2001 09:03:31 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>g? Subject: Re: IPF Console Bootstrap (was: No chance for OpenVMS)e0 Message-ID: <eZQc7.13$bB1.4113@news.cpqcorp.net>  K What Bob wanted, and what Bob got were not always the same.  He also wanted-* a single common console - read: AlphaBIOS.     mulp wrote in message ...n > A >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message , >news:EdY97.512$Yx2.9528@news.cpqcorp.net...H >> Nope.  The console ROM has full support for network booting.  It uses >"PXE"J >> (preboot execution environment) which uses things like DHCP, and MTFTP. IcL >> am by no means an expert, but our expert tells me that this will not be a >> problem.F >> >eK >I believe that Bob Supnik directed that MOP support be removed from futureeG >Alpha consoles about five years ago.  The console supported bootp (thee basisn@ >for dhcp) and tftp (the basis for mtftp) from day one of Alpha. >dJ >There's been nothing other than SMOP and the logistics of ensuring that aK >compatible TCP stack is started early enough to make satellite booting viakL >bootp/tftp as convenient as MOP booting.  If switching to bootp/tftp is notL >a problem today, why wasn't the switch made when the two versions of DECnetL >were creating all the problems with MOP booting.  The reason is that it wasL >easier to implement support for three ways of MOP booting than to switch to5 >bootp/tftp: DECnet Classic, DECnet PLUS, and LANACP.n >hG >The neat thing about the LANACP MOP boot capability is that it becomes 5 >active shortly after all the devices are configured.a > L >Or is this an indication that a TCP/IP stack is going to be integrated into >VMS?p >w >d   ------------------------------  % Date: Fri, 10 Aug 2001 13:06:01 -0400i* From: John Reagan <john.reagan@compaq.com>' Subject: Re: Linker-Warnings in VMS 7.3e) Message-ID: <3B741479.4070009@compaq.com>a   M.Eismann&W.Richard wrote: > < > Yes, I'm very sure that I take the right versions from theG > obj-libs....! All source-files and link-commands (in dcl-scripts) areo% > untouched since we use OpenVMS 7.1!m > : > But that's not the problem! Why is the linker generating/ > NOMSG-warnings?! That's the question, or not?e > 	 > Cheers!d > Martin  " I think there are 2 problems here.  F One, the linker cannot find the correct message file.  As I mentioned I before, the "fix" to the linker was to reformat the IDC warning messages -F to prevent wrapping.  In the past, the linker used one single message F with lots of $FAO codes.  When those fields were large, the resulting G message exceeded the 255 char limit of the message.  The change was to 0C invent new message codes and to print multiple messages that would aI contain all the information (the name of the "entity" being checked, the OE names of the 2 modules involved, and the 2 timestamps involved).  It eF seems that the linker is using these new messages but cannot find the I message file.  (I've verified those hex numbers are the right numbers by uF looking at the V7.3 listing files).  Perhaps these weren't propagated G into the correct system message file?  I'll do some checking at my end w for that situation.e  E Two, the linker might be wanting to complain about a mis-matched IDC  D when there isn't a mis-match.  That is what I'm trying to determine.I If the IDCs that you listed before are the only IDCs seen by the linker, sG then it should not complain as there is nothing it should be checking. $D During field test for V7.3 this was a problem.  It should have been > fixed for the real V7.3 release.  Can you post the results of:  : $ anal/image/select=(link,ident,build) sys$system:link.exe  . so I can verify exactly which linker you have?   John Reagans Compaq Pascal Project Leader   ------------------------------  % Date: Fri, 10 Aug 2001 09:30:37 -0400y* From: John Reagan <john.reagan@compaq.com>' Subject: Re: Linker-Warnings in VMS 7.3 ) Message-ID: <3B73E1FD.2010405@compaq.com>m   M.Eismann&W.Richard wrote:[ > John Reagan <john.reagan@compaq.com> wrote in message news:<3B72CDCB.50201@compaq.com>...u >  ...s   >  > I hope this helps....w >  > Greetingse > martin eismann > cretschmar-logistik gmbh > duesseldorf, germany >     G I'll skim over the IDC records (and look at the linker source code) in k6 the next couple of days to see if I can spot anything.  F As for the current patch to the linker: the problem is solves is with E the SOLITARY option on PSECTs in linker options files.  It shouldn't h make a difference here.s   John Reagan    ------------------------------  % Date: Fri, 10 Aug 2001 09:33:41 -0400b* From: John Reagan <john.reagan@compaq.com>' Subject: Re: Linker-Warnings in VMS 7.3 ) Message-ID: <3B73E2B5.8090605@compaq.com>)   Jan Vorbrueggen wrote:. > John Reagan <john.reagan@compaq.com> writes: >  > D >>Before V7.3, when the linker was trying to produce ENTIDENT check 8 >>messages, the message would wrap and become truncated. >> > M > I hadn't heard about this before. What do you use it for - to make sure thehA > right versions of modules are taken from the object libraries? h >  > 	Jan >   I In essence, yes.  There are timestamps buried in this IDC records placed -H in the object files.  The linker collects and compares IDC records with @ the same "key" (ie environment name) and gives a message if the  timestamp does not match.e  F The PEN_CHECKING_STYLE attribute in Pascal provides some control over I these records and lets you use the ident string instead of the timestamp  
 for checking.o   John Reagan    ------------------------------  % Date: Fri, 10 Aug 2001 09:40:22 -0400r* From: John Reagan <john.reagan@compaq.com>' Subject: Re: Linker-Warnings in VMS 7.3p) Message-ID: <3B73E446.8070205@compaq.com>A   M.Eismann&W.Richard wrote: > C > Yes, we use Pascal-Compiler as You can see in following output! IaF > remember, that we've got PAS$ENVIRONMENT_TIME during some links; you2 > can find these entries also in following output: > H > Analyze Object File                          10-AUG-2001 09:00:55.01   > Page 1$ > LZO_SOURCE_DEVICE:[MAIN]MAIN.OBJ;1 > ANALYZ A07-04e >  > I hope this helps....  >  > Greetingsa > martin eismann > cretschmar-logistik gmbh > duesseldorf, germany >   B That is the ANAL/OBJ from one of your .OBJ files.  The set of IDC F records shows which environments that it used.  I need to see the IDC G records from EVERY .OBJ file or module that is seen by the linker.  It s: is comparing them and perhaps generating the "mismatched" B PAS$ENVIRONMENT_TIME message.  With just the single .OBJ file you D listed, the linker would never generate an IDC mismatch since there  aren't "two" of any of them.  5 You just said that you "remember" that you've gotten  H PAS$ENVIRONMENT_TIME messages in the past.  However, your original post 5 said that V7.2-1 link was message free.  Which is it?r  D If you want to do ANAL/OBJ on ALL the .OBJ files (and .OLB modules) G used, extract the IDC records like you did for MAIN.OBJ, and mail them oG to me (it might be too big to post here).  I'll do the check "by hand" oJ to see if the linker was correct in trying to print the IDC check message.   John Reagana Compaq Pascal Project Leader   ------------------------------    Date: 10 Aug 2001 16:12:43 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>@' Subject: Re: Linker-Warnings in VMS 7.31H Message-ID: <y466bwovfo.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ; lzoedv@cretschmar-logistik.de (M.Eismann&W.Richard) writes:h  : > But that's not the problem! Why is the linker generating/ > NOMSG-warnings?! That's the question, or not?    Three possibilities:  G - The linker message file wasn't updated with the message text for this2   warning message.J - The text is there, but in a ...MSG.EXE the linker/image activator cannot;   find (for instance, because it was omitted from the kit).iM - The message number in the linker code got the wrong value by some accident.i  I You could try dumping the message file the linker uses (look with ANA/IMAyK and/or SHOW DEV/FILE while the linker is running) and UNMESSAGE it, lookingtL for a text that matches. Reading such things is very educating and enjoyable once in a while anyway...a   	Jan   ------------------------------  % Date: Fri, 10 Aug 2001 20:45:27 +0200c= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> : Subject: Re: Looking for a Pine.exe for TCPIP 5.x services) Message-ID: <3B742BC7.6CBEBD7A@gtech.com>    Jan-Erik Sderholm wrote:t > Just got :? > "550 No access to [PUB.VMS.NBL]. Requested action not taken."i& > when trying to access the URL below.  " Let me guess: you are using MSIE ?  . MSIE does not work well with VMS FTP servers !   Netscape usually works.e  ! And command-line FTP always work.c   Arne   ------------------------------   Date: 10 Aug 2001 18:47:25 GMT1 From: George Cornelius <corneliu@gfc127.mayo.edu>p3 Subject: Re: Microsoft and Code red (Cisco as well) + Message-ID: <9l1a7t$hmu$1@tribune.mayo.edu>t   sms@antinode.org wrote:l6 > From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>  N >> I applied the patch according to the MS Security email I received and stillI >> had problems; not with my MS Servers, but with my Cisco 675 DSL modem. N >> There is a similar bug in the Cisco DSL modems.  I have yet to see anythingO >> from Cisco on fixing their bug.  USWest/Qwest finally found and provided thee >> fix.F  E I seem to have avoided the attacks.  The web management interface has>C a rudimentary filter so that you can specify a single host that hassC access for management purposes (password still required), and I hadwC specified a 10.0.0.x address on my internal network.  I do the same . thing with the modem's telnet management port.  D I see that my modem has been denying several access attempts an hour? to port 80, though, and that has not been the case in the past.   E >    Cisco does not deal with peons like us on CPE (Customer Premises G > Equipment).  They deal with higher level entities, like Qwest.  QwestoJ > supplies instructions for a work-around for the problem, not a fix.  TheI > fix is in a later version (2.4.x) of the CBOS, which I got (months ago) A > from my ISP, because until very recently, Qwest was too lame tom2 > distribute anything newer than 2.2.x themselves.  I Yep.  And CBOS 2.2.x has a bug in its filtering capabilities which causesaN wildcard 'deny' filters to override any overlapping 'allow' filters regardlessG of which filter is earlier in the list, but I suppose the typical QwesttC residential customer doesn't bother with that kind of thing anyway.a  6 >> [...]The solution is to change the HTTP port on theE >> modem to a random number above 1024.  Like I said, Qwest found and'( >> provided this information, not Cisco.  I >   "Solution", right.  Why a port above 1024?  No good reason.  Anythingd" > other than 80 evades the attack.   -- :5 George Cornelius                   cornelius@mayo.edu >                                    cornelius@encompasserve.org   ------------------------------  % Date: Fri, 10 Aug 2001 15:06:27 -0600 4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>3 Subject: Re: Microsoft and Code red (Cisco as well) 3 Message-ID: <p1Yc7.2152$4_4.196918@news.uswest.net>h  I You avoided the attacks because you used the single host option:  set webrH remote <ip>.  Qwest had me use this and the "set web port [port > 1024]"H command.  As far as the CBOS version, I downloaded v2.4.1 from Qwest, soL whatever their problem with the newer versions was has been cleared.  As farL as CBOS 2.4.2 is concerned, Windows 2000 magazine is reporting that "set webJ disable" still doesn't protect the Cisco 600 series modems from the buffer overrun issue. --
 Mike Ober.  > "George Cornelius" <corneliu@gfc127.mayo.edu> wrote in message% news:9l1a7t$hmu$1@tribune.mayo.edu...n > sms@antinode.org wrote:,8 > > From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> >lJ > >> I applied the patch according to the MS Security email I received and stillmK > >> had problems; not with my MS Servers, but with my Cisco 675 DSL modem.bG > >> There is a similar bug in the Cisco DSL modems.  I have yet to seen anythingD > >> from Cisco on fixing their bug.  USWest/Qwest finally found and provided the	 > >> fix.t >sG > I seem to have avoided the attacks.  The web management interface has E > a rudimentary filter so that you can specify a single host that hasjE > access for management purposes (password still required), and I hadsE > specified a 10.0.0.x address on my internal network.  I do the sameh0 > thing with the modem's telnet management port. > F > I see that my modem has been denying several access attempts an hourA > to port 80, though, and that has not been the case in the past.  >sG > >    Cisco does not deal with peons like us on CPE (Customer PremisesrI > > Equipment).  They deal with higher level entities, like Qwest.  QwestgL > > supplies instructions for a work-around for the problem, not a fix.  TheK > > fix is in a later version (2.4.x) of the CBOS, which I got (months ago)eC > > from my ISP, because until very recently, Qwest was too lame to 4 > > distribute anything newer than 2.2.x themselves. >0K > Yep.  And CBOS 2.2.x has a bug in its filtering capabilities which causesIE > wildcard 'deny' filters to override any overlapping 'allow' filters3
 regardlessI > of which filter is earlier in the list, but I suppose the typical QwestsE > residential customer doesn't bother with that kind of thing anyway.t >U8 > >> [...]The solution is to change the HTTP port on theG > >> modem to a random number above 1024.  Like I said, Qwest found andt* > >> provided this information, not Cisco. >iK > >   "Solution", right.  Why a port above 1024?  No good reason.  Anythingo$ > > other than 80 evades the attack. >  > --7 > George Cornelius                   cornelius@mayo.eduo@ >                                    cornelius@encompasserve.org   ------------------------------  % Date: Fri, 10 Aug 2001 13:57:39 -0500 / From: Chris Scheers <chris@applied-synergy.com>l" Subject: Re: Missing TK50 in uVAX?3 Message-ID: <3B742EA3.6E198A6B@applied-synergy.com>h   "Antti Jrvinen" wrote:t >  > Dear Sirs, > 6 > quite a beast, if I may, says upon typing "test 50": >  > KA410-A V2.2 > ID 08-00-2B-08-4B-06 >  >    CLK      0000.0001C >    NVR      0000.0001? >  ? DZ       0000.4001s= >       00004001 00000001 00000001 00000001 00000000 00000000a >    MEM      0006.0001e >       00600000 >    MM       0000.0001g >    FP       0000.0001a >    IT       0000.0001p >    HDC      7110.0001 " >       0004C437 0004C437 00000000 >  ? TPC      0000.4001cO >       FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF03- >    SYS      0000.0001a > ?? NI       0000.7004  V1.20 > G > My interest here is tape controller, here marked with "? TPC". I have:G > a TK50Z in separate box, connected and powered up and if I understand3D > corretly the controller doesn't see the tape or the controller mayI > be dead or something? What does the "TPC 0000.4001" mean? The following D > line presents the devices found, last one is the controller itselfL > (I did try changing the SCSI ID to 7, originally it was 0) but what should- > I do to make the controller find the drive?a > F > TK50Z has two connectors, which one should be used? Should I connect& > a terminator to the other connector? > 8 > Disks are of RD54 kind, I think, what is the capacity? > D > There is only 6 megabytes of memory installed, what kind of memory/ > fits? This thingie doesn't use SIMM -modules?i  ' According to the T 50 output, you have:i   	MicroVAX 2000 	6MB RAM. 	(2) RD54 (190MB unformatted, 159MB formatted)  C The ? DZ error is warning.  You are using a serial console, so thatf serial port can not be tested.  F The ? TPC error is a warning that nothing was seen on the bus.  The MV is at ID 7.  Don't use that ID.t  C The ?? NI error is because your ethernet is not terminated.  Either F terminate it or connect it to a network.  If you have a MV2K with bothG AUI and Thinwire connectors, make sure that the switch is set to selectt the correct interface.  D Since you mention a SCSI ID switch, I assume that the tape drive youB have is a TK50Z-GA.  The -FA model did not have a switch.  Set theC switch to ID 1.  Connect a cable from the MV2K to the TK50Z (eitherBD connector) and put a terminator on the other connector on the TK50Z.  F The vast majority of MV2Ks are either 4MB or 6MB.  There is 2MB on theH motherboard.  Most expansion cards are 2MB or 4MB.  There is a 12MB card< available.  It is a MS400-CA.  This gives you a 14MB system.  H Alternately, Clearpoint made a memory card that took you up to 16MB (theF maximum addressable by the CPU chip).  IIRC, this card required customH ROMs, so make sure that you get the ROMs if you find one of these cards.  
 Good luck!  G -----------------------------------------------------------------------l$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com e   Fax: 817-237-3074u   ------------------------------  # Date: Fri, 10 Aug 2001 18:47:35 GMTa2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)" Subject: Re: Missing TK50 in uVAX?0 Message-ID: <b%Vc7.23$bB1.4490@news.cpqcorp.net>  \ In article <m3pua4yi5l.fsf@muikku.baana.suomi.net>, costello@iki.fi (Antti Jrvinen) writes:     Followups set to comp.os.vms.o   ..
 :KA410-A V2.2a  1   MicroVAX 2000 or VAXstation 2000 series system.w   .. : ? DZ       0000.4001     serial controller.   .. : ? TPC      0000.4001N :      FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF03  C   That's the tape controller, and the diagnostics didn't like it...h   :   SYS      0000.0001 :?? NI       0000.7004  V1.2  
   Network.  G :My interest here is tape controller, here marked with "? TPC". I have i :a TK50Z in separate box...   9   You must have the TK50Z-F*, and not the TK50Z-G* drive.-  8   The TK50Z-F* (usually -FA) must be at bus address one.  ,   You do not have a SCSI bus on this system.  7 :Disks are of RD54 kind, I think, what is the capacity?3  C   159 MB.  Pointers to hardware information are in the OpenVMS FAQ.I  D :There is only 6 megabytes of memory installed, what kind of memory . :fits? This thingie doesn't use SIMM -modules?  J   The SIMM concept didn't become particularly common until somewhat later.G   The VAXstation 2000 and MicroVAX 2000 permit up to 14 MB of physical  J   memory (2 MB plus a 12 MB module), using modules specific to the system.E   MS400-BA 4 MB expansion or MS400-CA 12 MB expansion, with one slot.   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: Fri, 10 Aug 2001 15:28:02 -0500e* From: WILLIAM WEBB <WWEBB1@email.usps.gov>" Subject: RE: Missing TK50 in uVAX?- Message-ID: <0033000031944098000002L082*@MHS>t  H =0A> My interest here is tape controller, here marked with "? TPC". I h= avevH > a TK50Z in separate box, connected and powered up and if I understand=  D > corretly the controller doesn't see the tape or the controller mayH > be dead or something? What does the "TPC 0000.4001" mean? The followi= ngD > line presents the devices found, last one is the controller itselfH > (I did try changing the SCSI ID to 7, originally it was 0) but what s= houldC   From the codes shown,a  H FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF03=  E SCSI 0   SCSI 1   SCSI 2   SCSI 3   SCSI 4   SCSI 5   SCSI 6   SCSI 7 H Empty    Empty    Empty    Empty    Empty    Empty    Empty    Controll= er  = it looks like the controller ID is 7.  That's often the case.sA If your tape drive ID is 7, the system won't see it won't see it.   - > I do to make the controller find the drive?- >-5 > TK50Z has two connectors, which one should be used?3   One of the two.n   Should I connect& > a terminator to the other connector?  A Yes.  If you don't have this terminated, the system won't see it.n Hope this helps.   WWWebb     > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ' > Sent: Friday, August 10, 2001 3:06 PM F > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET$ > Subject: RE: Missing TK50 in uVAX? >e >C > "Antti J=E4rvinen" wrote:k > >u > > Dear Sirs, > >e8 > > quite a beast, if I may, says upon typing "test 50": > >c > > KA410-A V2.2 > > ID 08-00-2B-08-4B-06 > >  > >    CLK      0000.0001o > >    NVR      0000.0001n > >  ? DZ       0000.4001a? > >       00004001 00000001 00000001 00000001 00000000 00000000- > >    MEM      0006.0001  > >       00600000 > >    MM       0000.0001e > >    FP       0000.0001R > >    IT       0000.0001. > >    HDC      7110.00010$ > >       0004C437 0004C437 00000000 > >  ? TPC      0000.4001.? > >       FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05r > FFFFFF05 FFFFFF03e > >    SYS      0000.0001s > > ?? NI       0000.7004  V1.2m > >n< > > My interest here is tape controller, here marked with "? > TPC". I have> > > a TK50Z in separate box, connected and powered up and if I > understandF > > corretly the controller doesn't see the tape or the controller may= > > be dead or something? What does the "TPC 0000.4001" mean?c > The followingrF > > line presents the devices found, last one is the controller itself> > > (I did try changing the SCSI ID to 7, originally it was 0) > but what shoulda/ > > I do to make the controller find the drive?n > >sH > > TK50Z has two connectors, which one should be used? Should I connec= tR( > > a terminator to the other connector? > >e: > > Disks are of RD54 kind, I think, what is the capacity? > >nF > > There is only 6 megabytes of memory installed, what kind of memory1 > > fits? This thingie doesn't use SIMM -modules?r >:) > According to the T 50 output, you have:c >s >      MicroVAX 2000 >      6MB RAM4 >      (2) RD54 (190MB unformatted, 159MB formatted) >yE > The ? DZ error is warning.  You are using a serial console, so thatb  > serial port can not be tested. >-H > The ? TPC error is a warning that nothing was seen on the bus.  The M= VL! > is at ID 7.  Don't use that ID.. > E > The ?? NI error is because your ethernet is not terminated.  EithersH > terminate it or connect it to a network.  If you have a MV2K with bot= he? > AUI and Thinwire connectors, make sure that the switch is sete > to select  > the correct interface. > F > Since you mention a SCSI ID switch, I assume that the tape drive youD > have is a TK50Z-GA.  The -FA model did not have a switch.  Set theE > switch to ID 1.  Connect a cable from the MV2K to the TK50Z (eitherrF > connector) and put a terminator on the other connector on the TK50Z. >sH > The vast majority of MV2Ks are either 4MB or 6MB.  There is 2MB on th= en> > motherboard.  Most expansion cards are 2MB or 4MB.  There is
 > a 12MB carde> > available.  It is a MS400-CA.  This gives you a 14MB system. >s= > Alternately, Clearpoint made a memory card that took you upd > to 16MB (theH > maximum addressable by the CPU chip).  IIRC, this card required custo= m"= > ROMs, so make sure that you get the ROMs if you find one of  > these cards. >g > Good luck! >a@ > -------------------------------------------------------------- > ---------g& > Chris Scheers, Applied Synergy, Inc. > D > Voice: 817-237-3360            Internet: chris@applied-synergy.com >   Fax: 817-237-3074  >=   ------------------------------  % Date: Fri, 10 Aug 2001 21:00:36 +0200e= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>u Subject: Re: Move to Sun) Message-ID: <3B742F53.1565BD0D@gtech.com>n   David Mathog wrote:nL > Thanks to Digital and Compaq's outstanding  management I've been porting aL > lot of Fortran and C code from OpenVMS->Solaris over the last month - withL > very few difficulties.  The hardest part was usually writing the makefile.K > But then most of the code I deal with has been data in, crunch, data out,oK > and so the interfaces aren't very complicated.   Here's an example of theeK > sorts of minor changes I've seen. The Solaris C compiler didn't like codes
 > that did >  > char foo[100]n >  >    function(&foo)e >  > instead of >  >    function (&foo[0])j > 3 > when the prototype for that parameter was char *,-  < I think most compilers will give a warning on that construct+ (at least DEC C 6.x and GNU C 2.95-x does).o  ? The real problem I see with that construct is that, if one use:e   char *foo2 = foo;3  = then there are suddenly a semantic difference between the twot calls (with foo2).  I > Wait, two more things.  On VMS a Fortran FORMAT statement could use "i" L > for either an integer*2 or integer*4,but that format only works for i*4 on > Solaris, with the i*2 blowinga" > up the program when it executes.   Sounds logical.c  D I guess it died when it tried to access a 4 byte integer on a 2 byte alignedm but not 4 byte aligned address.2  D But even if it had handled the case, then the result would have been. nonsense anyway due to SPARC being big endian.   Arne   ------------------------------  % Date: Fri, 10 Aug 2001 15:08:34 +0100I0 From: andrew harrison <andrew.nospam@uk.sun.com> Subject: Re: Move to Sun) Message-ID: <3B73EAE2.4D0678A@uk.sun.com>t   Arne Vajh=F8j wrote: > =    > andrew harrison wrote:J > > > "Thus far, Sun is the only vendor that does not plan to include Int= elJ > > > chip support in its product line. Instead, Sun is going the proprie= taryB > > > route with its SPARC and 64-bit UltraSPARC microprocessors." > =i  : > > You post also totally ignores that fact that there are: > > other vendors who have no intention of including IA-64 > > in their product lines.s > >y> > > The IBM S390 division, the AS400 and the RS/6000 divisions> > > have no intention of including any IA-64 products in their > > product lines. > =r   > ???? > =h  @ > It is already some time since IBM renamed their hardware boxes< > to foobarSeries (specifically I think a RS/6000 are called > a pSeries. > =l    ; I know but most people are more familiar with the RS/6000 =r  8 than the pSeries which is what it has been re-branded to be.     D > But your statement does not make any sense ! Compaq Alpha divisionD > are not including IA-64. VMS (and Tru64) will support IA-64. It isB > the same for IBM. Their pSeries will not use IA-64. But AIX willH > support IA-64 (I think the beta version of AIX 5 for IA-64 are already
 > out there).d > =     > AIX is being ported to IA-64 (Sequent) because IBM wants one =  : common UNIX OS for their two UNIX platforms. This does not= mean that they are migrating to IA-64 nor does it mean that =]  = they will stop positioning the pSeries(RS/6000) as their highd performance UNIX platform.  = This is totally different to Compaq since Compaq are dropping. Alpha in favour of IA-64. =h    	 Regards =1   Andrew Harrisonn Enterprise IT Architectn   ------------------------------    Date: 10 Aug 2001 18:02:18 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) 0 Subject: Re: MS610-EA ES40 Memory - Very Cheap !, Message-ID: <kRSz0qzVW0iZ@malvm5.mala.bc.ca>  * In article <3B747D4E.51423A0E@wi.rr.com>, *     Scott Vieth <svieth@wi.rr.com> writes:  5 > I know where I can get them for significantly less.9 >  > You get one guess....  >   :    Well, if their web page is to be believed it's not from, Great Lakes Computer, their "specials" page + (http://www.glcomp.com/specials.htm) shows:s  . MS610-EA  ES40, 2GB MEMORY OPTION  $5,800.00    !    So that's my guess used up :-)t   > -Scott > $ > "D.B. Turner, islandco.com" wrote: >  >> Special comp.os.vms deal  >>7 >> MS610-EA 2GB for ES40 - 10 pieces left at $3500 eachn >>  >> We sell Alpha's & Alpha Parts >> http://www.islandco.com >> sales@islandco.com  >> Island Computers US Corp. >> 2700 Gregory Street >> Savannah GA 31404 >> Tel: 912 447 6622 >> Fax: 912 201 0096 >    ------------------------------  % Date: Fri, 10 Aug 2001 15:00:42 +0200I1 From: "Tomasz Dryjanski" <tdryjanski@hotmail.com>i Subject: Re: NTP. Message-ID: <9l0lts$2ei2$1@news2.ipartners.pl>  ( > Look TCPIP Management Documentation in >e+ > http://www.openvms.compaq.com:8000/#tcpip    Thanks.    >  > Works fine by the way    It really does. :)   T. D.e   ------------------------------  % Date: Fri, 10 Aug 2001 09:09:31 -0400d5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>u Subject: Re: OpenVMS  + Itaniums0 Message-ID: <S2Rc7.14$bB1.4076@news.cpqcorp.net>  F Snapshot, or fastboot, was IIRC something that was mostly aimed at theK desktop/workstation.  The main problem with it (aside from few people usingtD it) was that I don't believe it worked for clusters, only standalone systems.    A David J. Dachtera wrote in message <3B6B5671.A763E363@fsi.net>...e >Rudolf Wingert wrote: >>	 >> Hello,o >>H >> a veryf nice feature will be, that a cluster client copies the systemH >> to a local disk (e.g. as memory dump). The next time it must boot, itG >> boots from the local disk and, if neccessary, it updates the changedaI >> software from the server. This would allow a fast boot and low network, >> traffic.l >rF >I believe a similar feature, originally called "snapshot", I believe,B >was implemented in VMS and later desupported, possibly to lack of >interest. Dunno.i >c@ >I used to work with an o.s. that ran on Data General Nova/3 andF >MicroNova called EOS. I seem to recall that once you shut it down, onI >the Nova/3's at least - because they had the front panel toggle switchesaH >- you could simply press a button on the front panel and the o.s. wouldD >resume at the instruction after the HALT instruction that ended theF >shutdown sequence ... or maybe you had to advance th program counter,- >then resume. Don't remember exactly anymore.g > I >What you had was not entirely usable, but it seemed like "Hey, if we cane >do that, why not ..." > , >I dunno - just rambling tonight, I guess... >  >--  >David J. Dachtera >dba DJE Systems >http://www.djesys.com/- > ) >Unofficial Affordable OpenVMS Home Page:m  >http://www.djesys.com/vms/soho/   ------------------------------    Date: 10 Aug 2001 15:19:09 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>r Subject: Re: OpenVMS  + Itanium,H Message-ID: <y4g0b02gtu.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:?  H > Snapshot, or fastboot, was IIRC something that was mostly aimed at theM > desktop/workstation.  The main problem with it (aside from few people using F > it) was that I don't believe it worked for clusters, only standalone
 > systems.  M I think that is correct. Also, at current processor speeds, even with all the K things being loaded, booting only takes a few minutes. At the time fastboot0I was developed, a slower machine could easily take half an hour or more toeL become useable again. And those were often multi-user machines. So any crashJ led to 20-100 people twiddling their thumbs for half an hour or more...not good.    	Jan   ------------------------------  % Date: Fri, 10 Aug 2001 21:06:02 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>c; Subject: Re: OpenVMS apps and Compaq committment story hereg( Message-ID: <3B74309A.C97ADFD@gtech.com>   Larry Kilgallen wrote:k > In article <3B738E54.8DA48852@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:h > > paul@wren.cc.kux.edu wrote:rI > >> http://dailynews.yahoo.com/h/cmp/20010809/tc/iwk20010808s0007_1.htmly > >f > > Good story., > > < > > It would be better if linked from www.openvms.compaq.com* > > or still better from www.compaq.com !! > G > I think that is immaterial and think it is more important to have the)& > outreach effect in a separate venue. > E > All those who are upset about Alpha-IA64 can read about the articleP > here in comp.os.vms.  + How many decision-makers read comp.os.vms ?D   Arne   ------------------------------  % Date: Fri, 10 Aug 2001 15:41:17 -0500t* From: WILLIAM WEBB <WWEBB1@email.usps.gov>; Subject: RE: OpenVMS apps and Compaq committment story heren- Message-ID: <0033000031945571000002L012*@MHS>l  . =0AHow many decision-makers read comp.os.vms ?  5 Considering the tone of some of the posts as of late,i I hope not many.   WWWebb   > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ' > Sent: Friday, August 10, 2001 3:34 PMtF > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET= > Subject: RE: OpenVMS apps and Compaq committment story here  >t >p > Larry Kilgallen wrote:2 > > In article <3B738E54.8DA48852@gtech.com>, Arne! > =3D?iso-8859-1?Q?Vajh=3DF8j?=3D B > <arne.vajhoej@gtech.com> writes: > > paul@wren.cc.kux.edu wrote: > > >>F > http://dailynews.yahoo.com/h/cmp/20010809/tc/iwk20010808s0007_1.html > > >o > > > Good story.  > > > > > > > It would be better if linked from www.openvms.compaq.com, > > > or still better from www.compaq.com !! > >-= > > I think that is immaterial and think it is more important2
 > to have the ( > > outreach effect in a separate venue. > >:H > > All those who are upset about Alpha-IA64 can read about the article=   > > here in comp.os.vms. >d- > How many decision-makers read comp.os.vms ?: >s > Arne >=   ------------------------------    Date: 10 Aug 2001 16:54:40 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)A; Subject: Re: OpenVMS apps and Compaq committment story here 3 Message-ID: <fR0CJImuTRMJ@eisner.encompasserve.org>0  h In article <3B74309A.C97ADFD@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes: > Larry Kilgallen wrote:l >> In article <3B738E54.8DA48852@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:  >> > paul@wren.cc.kux.edu wrote:J >> >> http://dailynews.yahoo.com/h/cmp/20010809/tc/iwk20010808s0007_1.html >> > >> > Good story. >> >= >> > It would be better if linked from www.openvms.compaq.comv+ >> > or still better from www.compaq.com !!  >> hH >> I think that is immaterial and think it is more important to have the' >> outreach effect in a separate venue.o >> 4F >> All those who are upset about Alpha-IA64 can read about the article >> here in comp.os.vms.O > - > How many decision-makers read comp.os.vms ?y  2 I am not convinced that any decisionmakers either:   	a. read comp.os.vms    or: 	b. are upset about Alpha-IA64   ------------------------------  % Date: Sat, 11 Aug 2001 00:42:57 -0400X( From: Hamlyn Mootoo <univms@bigfoot.com> Subject: Re: Press Release+ Message-ID: <3B74B7D1.EFA6A794@bigfoot.com>    JF Mezei wrote:a >  > Sue Skonetski wrote:P > > Compaq Federal LLC. "And we're equally pleased that more and more governmentL > > agencies are turning to Compaq whether they need the mobility of an iPACO > > Pocket PC, Evo desktops or laptop units, Compaq Pro-Liant industry-standard-= > > services or a total services-led IT enterprise solution."i > M > Another example. Why does Compaq take every opportunity to feature its iPAQ,  C For one, iPAQ is being positioned by Microsoft as the Palm killer. >F Compaq couldn't make enough of them to sell.  My understanding is thatH they started coming out with the black and white iPAQ's, like the H3150,C et al, becuase they couldn't get enough color screens for the colordE models, not because they wanted to introduce a lower price point- butaH that's what they're spinning.  Microsoft has made some heavy bets in theA mobile computing space, and eventually, this may be Compaq's mostsG profitable commodity.  Old billy boy is even making embedded visual c++rE and embedded visual basic and related pocket PC and Handheld PC SDK'sFF available FREE for download on the web, just so developers get tons ofB apps into the pipeline for Windows CE.  Now when was the last timeH microsoft gave away two compilers for free? In my opinion, the pocket PCE could very well kill the palm devices due to the fact that PPC's havesG more visible real estate, and run MUCH faster processors than Palms and A Handspring Visors.  The Palm OS might quickly be losing ground too Windows CE for this reason.      HM   ------------------------------  % Date: Sat, 11 Aug 2001 00:48:06 -0400o( From: Hamlyn Mootoo <univms@bigfoot.com> Subject: Re: Press Release+ Message-ID: <3B74B906.93C74B5E@bigfoot.com>i  G Sound like extortion of the government to me: You give us a lot of youreG contracts, and we won't kill support on your critical military systems.;E Can Capellas be put to death for high treason?  I don't think any VMS?G customers would object on constitutional grounds - and I can think of auH few shareholders who might want a first row seat.  Maybe ticket sales toC this event might offset Compaq revenue shortfalls? Oh well, just anN idea.    HM     Sue Skonetski wrote: > 6 > From the Nashu (New Hampshire) Telegraph (newspaper) > N > http://www.nashuatelegraph.com/Main.asp?SectionID=27&SubSectionID=357&Articl > eID=37912F >  > Wednesday, August 08, 2001 > " > Compaq computer takes to the sky > $ > By EILEEN KENNEDY, Telegraph Staff >  > kennedye@telegraph-nh.com  > I > NASHUA - Technology developed at Compaq's Spit Brook Road facility, and N > elsewhere in New England, is now flying proudly in one of the U.S. Air Force  > 's newest surveillance planes. > F > On Monday, the U.S. Air Force took delivery of a Block 20 E-8C JointK > Surveillance Target Attack Radar System plane, which has 20 Alpha servers H > with Open VMS operating systems, from the primary contractor, Northrop > Grumman Corp.  > N > The servers and operating systems are part of a $30 million contract between > Compaq and Northrop Grumman. > L > This is in addition to $1 billion in unrelated government contracts CompaqM > has won with the Social Security Association, the National Security and theb > U.S. Postal Service. > H > Government work is becoming an increasingly important part of Compaq'sM > business these days. Compaq had about $1.5 billion in revenue from the U.S.rG > government last year, out of total revenue of $42 billion - about 3.5 D > percent of the company's business, according to company officials. > N > While the aircraft delivered Monday is the 11th in the production series, itN > is the first plane to use commercial off-the-shelf ES40CV Alpha servers with > Open VMS operating systems.  > H > The AlphaServer systems and other systems on J-STARS provide accurate,J > real-time data and analysis about vehicles on the ground and slow-movingL > aircraft for peacekeeping missions and decision-making on the battlefield,I > according to a Compaq spokesman. The power of the servers is a welcomed K > addition to the planes, said the spokesman, since they offer 10 times theiN > computer capacity and memory of the computers previously used on the planes. > H > "Traditionally, equipment used in the military surveillance and combatL > environments has been highly specialized and highly customized," said RichK > Marcello, vice president and general manager of Compaq's High PerformancesI > Systems division. "The fact that commercially available technology likenK > Compaq's Open VMS-based AlphaServer ES40CV systems can be integrated intoSG > those environments is a testament to the performance, reliability ande9 > functionality of Compaq's industry-leading technology."  > N > Compaq and Digital Equipment Corp. - before it was acquired by Compaq - haveF > been working with Northrup Grumman since 1990, on a variety of otherF > programs, according to Mary Ellen Fortier, director of marketing and6 > business development for Compaq's Open VMS business. > J > When the contract for the J-STAR planes was put out to bid, Compaq was aM > natural choice because Northrop Grumman "knew how the product would behave,uM > and it would work under the stressful conditions of being on a surveillanceh > plane," she said.M > M > One of the reasons Compaq's Alphas were chosen, she said, is because of theh) > amount of security the servers provide.a > H > "Security is very important to many customers, but particularly so forN > customers like this. No intrusion can get onto the systems, from our country/ > or from (outside the country)," Fortier said.e > L > It shows the quality and power of Compaq's servers when the U.S. Air ForceK > is willing to use the "off-the-shelf" products for surveillance in battleIJ > conditions, Fortier said, and in the end, the taxpayers benefit from the > cost savings.  > F > "We applaud the initiative to use Compaq's commercial, off-the-shelfK > AlphaServer systems in the J-STARS aircraft," said Ron Ross, president of N > Compaq Federal LLC. "And we're equally pleased that more and more governmentJ > agencies are turning to Compaq whether they need the mobility of an iPACM > Pocket PC, Evo desktops or laptop units, Compaq Pro-Liant industry-standard ; > services or a total services-led IT enterprise solution."r > I > During 2001, Compaq was chosen by more than a dozen federal agencies totK > provide equipment, services or both, according to a Compaq spokesman. ThepJ > value of federal contracts awarded to Compaq over the past three months,M > including some large multi-year agreements, will total more than $1 billione( > if all contract options are exercised. > J > Last week, the National Security Agency awarded a 10-year contract worthI > more than $2 billion to a group of more than a dozen partner companies,8B > including Compaq. The companies will modernize the technologicalJ > infrastructure of the agency, which will include using Compaq equipment. > L > Earlier this year, the U.S. Postal Service signed an agreement with CompaqJ > to make Presario Internet PCs and a variety of Internet services optionsL > available at discounts to more than 800,000 post office employees. As partI > of the contract, Compaq created a custom portal for postal employees tog) > securely access the service's intranet.e > F > In April, Compaq was awarded a $30 million contract to update 32,000L > computers in the Social Security Administration in 1,000 service locations$ > across the country in five months. > L > Compaq has 2,200 employees in Nashua, with several buildings on Spit BrookH > Road, where much of the software for Alpha computers is developed. TheK > company also has a software manufacturing and packaging company on Cottone > Road.m   ------------------------------  % Date: Sat, 11 Aug 2001 01:40:03 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>t Subject: Re: Press Release, Message-ID: <3B74C531.99B688F6@videotron.ca>   Hamlyn Mootoo wrote:D > For one, iPAQ is being positioned by Microsoft as the Palm killer.. > Compaq couldn't make enough of them to sell.    J But an announcement about a VMS win is not a place to start flaunting yourJ proliants and iPaqs unless you're also willing to flaunt your VMS when you make Proliant press releases.   I > more visible real estate, and run MUCH faster processors than Palms andhC > Handspring Visors.  The Palm OS might quickly be losing ground toa > Windows CE for this reason.o  J Be careful. MS bloated software requires faster processors to acheive sameM response time. My old trusty PSION 3 runs at 7mhz and is faster in many cases-K than newer handhelds that have much fatsre processors and bloated software.e  K Also, faster processors require more power. The Palm may be technologically!M very simple, but it does its job very well and has great battery autonomy. In@K the end, you don't need a colour screen to take down phone numbers etc etc.cM (although a colour screen does provide for some additional functionality thatl is beyond a pocket organiser).   ------------------------------    Date: 10 Aug 2001 11:57:40 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)-( Subject: Query string problem with CSWS., Message-ID: <2xxcvW63maS+@malvm5.mala.bc.ca>  5  I've run into a problem with the OSUScript module ofi1 CSWS. It appears that the query string is getting-3 the first character chopped off of it. Eg If I haves	 a url of:r  +   http://myserver/htbin/procedure?param=abcc  6  I get a value of "aram=abc" in WWW_QUERY_STRING after running CGI_SYMBOLS.  .   This brings up a support question - is CSWS:      a.) not supported?-  8    b.) supported under a VMS software support agreement?  8    c.) supported under a separately purchased agreement?   ------------------------------  % Date: Sat, 11 Aug 2001 06:20:49 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender), Subject: Re: Query string problem with CSWS.; Message-ID: <3b74b2a1.524144494f47414741@radiogaga.harz.de>-  2 Malcolm Dunnett (nothome@spammers.are.scum) wrote:7 >  I've run into a problem with the OSUScript module ofm3 > CSWS. It appears that the query string is gettingR5 > the first character chopped off of it. Eg If I haveo > a url of:o >h- >   http://myserver/htbin/procedure?param=abct >o8 >  I get a value of "aram=abc" in WWW_QUERY_STRING after > running CGI_SYMBOLS. >e0 >   This brings up a support question - is CSWS: >    a.) not supported? : >    b.) supported under a VMS software support agreement?: >    c.) supported under a separately purchased agreement?   AFAIK, it's b.)e   cu,t   Martin -- tJ One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.deaJ One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  % Date: Fri, 10 Aug 2001 16:43:45 -0400e+ From: "John Saunders" <jws@ma.ultranet.com>.* Subject: Re: Red Code: where are we going?+ Message-ID: <9l1h36$mhf$1@bob.news.rcn.net>a  ? "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> wrote in messageN+ news:hdRc7.349$4_4.48825@news.uswest.net... J > Amazing statement, since I have lost data with the VMS backup due to theL > complexity of it's command line, yet I have never lost data with the builtI > in NT4 or W2K backup software - and yes, I've had to restore from both.    Mike,   H All due respect, but it sounds like you lost data with VMS Backup by notJ testing your backup procedures - by restoring from them. Is that the case? --
 John Saunders  jws@ma.ultranet.comu   ------------------------------  % Date: Fri, 10 Aug 2001 17:07:11 -0400c+ From: "Main, Kerry" <Kerry.Main@compaq.com> * Subject: RE: Red Code: where are we going?R Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D55FC7@kaoexc01.americas.cpqcorp.net>  = >>> How do you identify it? ?XX is CR-I and ?NN is CR-II ? <<:  K Just as a heads up and as an additional incentive to ensure the recommendedr: procedures to safeguard your NT/W2K servers are followed -  ' Get ready for the sequel - code red IIIo  = http://news.cnet.com/news/0-1003-201-6741564-0.html?tag=mn_hdk  K http://news.cnet.com/news/0-1003-200-6835996.html (Code Red III much worse)t   Regards,  
 Kerry Main Senior Consultant  Compaq Canada Corp.. Professional Servicesr Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----3 From: Didier Morandi [mailto:Didier.Morandi@gmx.ch]e Sent: August 9, 2001 3:13 PM To: Info-VAX@Mvb.Saic.Como* Subject: Re: Red Code: where are we going?     "Doc.Cypher" wrote:a  K > I now have over 400 IP addresses in the list of those that have attempted ( > to attack my server (Code Red Type II)  6 How do you identify it? ?XX is CR-I and ?NN is CR-II ?   D.   ------------------------------    Date: 10 Aug 2001 16:07:55 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>t* Subject: Re: Red Code: where are we going?H Message-ID: <y48zgsovno.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  N I think the problem with NT backup is that you cannot restore a working systemN from tape, i.e., there is no such thing as standalone backup (and we know thatN in 99.99% of all cases, a backup of a live system will yield a bootable system damn near to the original).!   	Jan   ------------------------------    Date: 10 Aug 2001 13:15:41 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)h Subject: Re: Server up?A3 Message-ID: <mgMYm8kgiTyY@eisner.encompasserve.org>.  _ In article <CIEJLCMNHNNDLLOOGNJIGELCDBAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:  > Anybody know?1  
 What server ?r  < You don't access comp.os.vms through DECUServe, as I recall.   ------------------------------  # Date: Fri, 10 Aug 2001 19:01:39 GMT02 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Server up? 0 Message-ID: <ncWc7.25$bB1.4459@news.cpqcorp.net>  _ In article <CIEJLCMNHNNDLLOOGNJIGELCDBAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:R :Anybody know?  8   Yes, the tub is filled with brightly colored wrenches.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 10 Aug 2001 14:37:36 -0500n+ From: Christopher Smith <csmith@amdocs.com>. Subject: RE: Server up? L Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DB13@cmiexch1.cmi.itds.com>   > -----Original Message-----% > From: hoffman@xdelta.zko.dec.nospam.  < > In article <CIEJLCMNHNNDLLOOGNJIGELCDBAA.tom@kednos.com>, ' > "Tom Linden" <tom@kednos.com> writes:d > :Anybody know?  : >   Yes, the tub is filled with brightly colored wrenches.   Blue!     ! Christopher Smith, Perl Developerl Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");m ':  s   ------------------------------   Date: 10 Aug 2001 21:08:41 GMT5 From: koehler@bessta.gsfc.nasa.aspm.gov (Bob Koehler) 9 Subject: Re: Slow time and bad memory - are they related?m/ Message-ID: <9l1igp$otr$2@skates.gsfc.nasa.gov>i  W In article <C2256AA4.00620114.00@jklh21.valmet.com>, norm.raphael@jamesbury.com writes:j >8> >Is it possible that the bad memory caused the time situation? >I  F Depends on the failure mode and model of VAX.  If it was causing noise& on the system bus anything's possible.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = GSFC Code 582 Flight Software   | Federal Sector, Civil Group I                                 | please remove any ".aspm" when replyingn   ------------------------------  % Date: Fri, 10 Aug 2001 09:43:43 -0400v* From: John Reagan <john.reagan@compaq.com>/ Subject: Re: The VMS Opensource Porting Project ) Message-ID: <3B73E50F.4010807@compaq.com>a   Patrick Spinler wrote:I > Sorry for following up to myself, but one other possible source of goods; > advice might be found here http://gnv.sourceforge.net (or-- > http://www.sourceforge.net/projects/gnv).    > F > For instance, I see that they have a package: "The CRTL SupplementalD > library provides functions typically found on Unix system, but areJ > missing, incomplete, or incorrect on VMS. It is intended to make porting: > to VMS easier" at http://gnv.sourceforge.net/crtlsup.htm >  > Again, good luck ! > -- Pat >   D To add to that...  In my "spare time", I've been working on the GNV F files at gnv.sourceforge.net.  I'll be checking some corrected files, G along with 'by-hand' configured header files back into the CVS library   sometime in the next month.n  H As for the CRTL supplemental library, I need to check with the CRTL guy L (he's on vacation in Ireland right now) on getting a fresh version in place.   John Reaganb9 Compaq Pascal Project Leader (and recent GNV/bash hacker)    ------------------------------  % Date: Fri, 10 Aug 2001 13:13:21 +0100w% From: Alan Greig <a.greig@virgin.net> $ Subject: Re: Third postcard from Sun* Message-ID: <3B73CFE1.673BDF17@virgin.net>   Larry Kilgallen wrote:   > In article <y4snf06zzf.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:; > > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:  > >eO > >> To my knowledge, no engineers in VMS were layed off post-EFI announcement, = > >> although some non-engineering positions were eliminated.r > >n< > > So you now have to do some of the support work yourself? > B > If only Bob Palmer had not cancelled the AI Usenet Autoresponder
 > project :-)c  A Actually it was picked up by Sun and renamed "Andrew Harrison" :)    --
 Alan Greig   ------------------------------  % Date: Fri, 10 Aug 2001 09:16:01 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>M$ Subject: Re: Third postcard from Sun0 Message-ID: <Y8Rc7.15$bB1.4212@news.cpqcorp.net>  $ Jan Vorbrueggen wrote in message ...8 >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: >a? >> To my knowledge, no engineers in VMS were layed off post-EFI 
 announcement, ; >> although some non-engineering positions were eliminated.  >l9 >So you now have to do some of the support work yourself?  >      No.e   ------------------------------  % Date: Fri, 10 Aug 2001 15:51:49 -0400t, From: "John W. Hom" <j.hom.1@alumni.nyu.edu>Y Subject: VMS: Nothing Stops It (was "I just have to post this - and apoligse later Alpha/a- Message-ID: <3B743B55.7000800@alumni.nyu.edu>h   David Mathog wrote (in part):t  > > The other issue that perhaps should be mentioned explicitly,  @ > and which accounts for a lot of the heat in these discussions,  < > is that when Compaq forces people with 20 years of OpenVMS  = > experience off the OS they very much devalue those 20 years   = > of hard earned knowledge.   We take this personally because.  ? > it is personal, very personal.  You're good at what you do.  U    = I still have two pristine, unused bumper stickers issued fromeA Digital when we were all celebrating the 20th anniversary of VMS.i= Along with all the graphic elements were the huge words "VMS"t and "Nothing Stops It."    Sigh.e   John -- r John W. Hom  j.hom.1@alumni.nyu.edu   ------------------------------  % Date: Sat, 11 Aug 2001 00:07:00 -0400o( From: Hamlyn Mootoo <univms@bigfoot.com>( Subject: Re: We've launched TAPESYS v6.0+ Message-ID: <3B74AF64.15E5AE42@bigfoot.com>n  H And all of this functionality comes with a hefty price tag.  Better thanD $1800 (or was it $3000, I can't remember) for connecting two measilyA DS-10's together last time I checked (to say nothing about larger ! configs.)  Thanks, but no thanks.    HM   Technical Support wrote: > L > I don't mean to spam one of my favorite news groups.  I just thought thereN > might be some TAPESYS users out there who would be interested in V6.0.  I amL > particularly proud of the new communications transports that are supportedM > such as icc and tcpip.  The database has been revamped and made more objecttM > oriented.  Lots of other nice stuff as well, including a simplified install J > and automated backup load balancing across drives.  The next phase is to > implement a web gui. >  > Dave > J > Software Partners, Inc. is pleased to announce the launch of the TAPESYSL > V6.0 field test. This program makes the first release candidate of TAPESYSK > V6.0, as well as that of JB V4.0, available to the public for free 60-daydN > trial. TAPESYS, the OpenVMS Tape Management System, is the premier automatedK > tape backup solution for today's enterprise OpenVMS environments. JB, thelL > OpenVMS Jukebox Manager, provides OpenVMS with robust robotic tape library > control and media management.k > K > Please visit the Software Partners web site to register and download your $ > free 60-day trial of TAPESYS V6.0. > % >     http://www.SoftwarePartners.comi > L > For more information about TAPESYS, please visit Software Partners product > information page.t > : >     http://www.SoftwarePartners.com/products/tapesys_vms > ' > New features in TAPESYS V6.0 include:g > ) >     VMSINSTAL software installation kit  > 4 >     Automated conversion and configuration utility > A >     Improved linking procedures for VAX and ALPHA architecturesu > * >     More efficient reformatted databases > J >     Communication between internal TAPESYS processes over TCP/IP and ICC* > (InterCluster Communication), as well as >     DECnet > E >     Integration of our JB database into the master TAPESYS databaseh > 4 >     Improved control of Media Management reporting > H >     A new database field to improve management of offsite tape storage > K >     A restructuring of the startup procedures for more efficient linking,o- > easier software maintenance and management.o > M >     Many new parameters in SETUP.PAR and SETUP_SHIPPED_VERSION.PAR to allow.$ > better control of features, report  >     printing and communication > M >     Integration of VMS Backup and RMU backup utilities into one easy to use  > utility template > 3 >     Improved compatibility with Multi-version RMUc > 9 >     Compatibility with the latest changes to VMS Backupa > N >     System backup history files have been reformatted for compatibility with > ODS5 filenames > K >     A daily checking procedure to ensure that ALL of your disks are being  > backed up  >   >     Improved backup scheduling > C >     A revamped menu-driven system backup (SBK) template generatord > ) >     Improved diagnostic output controlsC > M >     New option for a centralized license key directory allowing one licenser- > key for multiple Software Partners products  > " > New features in JB V4.0 include: > K >     Ability to use the TAPESYS database, its own native database, or bothm > databasest > G >     Automated initialization of volumes in a specified range of slotst > L >     Automated addition of volumes to the JB native database or the TAPESYS- > database with labels derived from barcodes.n > F >     Ability to update a volume's jukebox association on JB CONFIGURE. > commands, automating migration of tapes from >     jukebox to jukebox > , >     JB is now completely written in DEC C. >  >     Improved error handlingo > 9 >     Improved load and eject door and port compatibility  >  >     New key system > : >     New SET JUKEBOX command to modify the jukebox record > > >     Improved timing logic for dismounting volumes from drive > + >     Vastly improved barcode reading logicr > > >     Vastly improved JB CONFIGURE logic for jukebox inventory > < >     Improved performance through improved database locking > 2 >     Ability to define allocation order of drives > L >     Expanded compatibility with SCSI-2/SCSI-3 and MRU-controlled jukeboxes   ------------------------------   End of INFO-VAX 2001.443 ************************