1 INFO-VAX	Mon, 01 Apr 2002	Volume 2002 : Issue 180       Contents:% Re: Analyse/system like tool for unix 2 Re: Announcing a boot contest for OpenVMS on Intel RE: Burning CD using LD  Re: Checksum goes cpu bound  Re: Commnets on Mozilla9.9 Re: Commnets on Mozilla9.93 Compaq set to unveil new Terabit Network Technology 7 Re: Compaq set to unveil new Terabit Network Technology C Re: DCL minute of the day: navigation, degrees and all these things  DECNET Pahse XVIII announced) Re: EMC / Symmetrix information requested  extract for Unix File IO query. Re: Good IBM Ad  Re: Good IBM Ad  Re: Good IBM Ad  Re: Good IBM Ad * Re: Help! VT100 emulators - some problems.* Re: Help! VT100 emulators - some problems.* Re: Help! VT100 emulators - some problems. Re: help!!! compilation issue ' HP Won't Renominate W. Hewlett to Board + Re: HP Won't Renominate W. Hewlett to Board + Re: HP Won't Renominate W. Hewlett to Board 4 Re: INCONMMGST, Inconsistent memory management state Re: Itanium troubles Re: Itanium troubles Migration Tool1 OT: Microsoft Uses FreeBSD To Host Anti-Unix Site  Re: Piping and recalling) Re: Predictions - just for the hell of it ' Seek information on FAXSR and VMS 7.3-1 8 Re: Sending Wake-up Message from NT to OpenVMS batch job4 Re: Spring Forward, Fall Back - unfortunately not :-4 Re: Spring Forward, Fall Back - unfortunately not :-4 Re: Spring Forward, Fall Back - unfortunately not :-E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 
 VAXORCIST 5.0   Re: VMS To Tru64 Migration Plans VMS To Tru64 Migration Plans  Re: VMS To Tru64 Migration Plans  Re: VMS To Tru64 Migration Plans  Re: VMS To Tru64 Migration Plans  Re: VMS To Tru64 Migration Plans Re: [OT] 11th of September  F ----------------------------------------------------------------------  % Date: Mon, 01 Apr 2002 14:25:14 +0530 % From: tejas bhise <btejas@in.ibm.com> . Subject: Re: Analyse/system like tool for unix* Message-ID: <3CA82072.F01A8DC0@in.ibm.com>   Anamika wrote: >  > HI, G >    Is there a analyse/system like tool for unix. I mean as good as it @ > is on VMS with comparable features. Any kind of unix would do. > 9 > I know about adb,kadb,sdb etc., they just don't cut it.  > 	 > Thanks,  > -A  ? Unix ( all sorts ) has its own tools which are used by the unix D community and have been sufficient for user space and kernel programD debugging. adb/kadb/crash/kdb will let do go through all kernel data structures that you want.    Regards, Tejas.   ------------------------------  # Date: Thu, 28 Mar 2002 19:26:56 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> ; Subject: Re: Announcing a boot contest for OpenVMS on Intel : Message-ID: <48Ko8.42319$44.16052544@typhoon.ne.ipsvc.net>   A BOOT POOL! Great idea!!!  J Herewith we have conclusive proof that not everyone in marketing is asleep at the switch!  = "Sue Skonetski" <susan.skonetski@compaq.com> wrote in message - news:oSIo8.1639$fL6.31660@news.cpqcorp.net...  > Dear Newsgroup,  > G > We now have a booting contest up on the web.  Give it your best shot. + > http://www.compaq.com/hps/ipf-enterprise/  >  > Warm Regards,  >  > Sue  >  >  >    ------------------------------  $ Date: Mon, 1 Apr 2002 05:21:54 -0800# From: "Tom Linden" <tom@kednos.com>   Subject: RE: Burning CD using LD9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOEHHEHAA.tom@kednos.com>   < I think the meaning was clear, but 96 is the smallest common= multiple, not the common denominator. :-)  Your site was very  useful, thanks.    > -----Original Message-----8 > From: David J. Dachtera [mailto:djesys.nospam@fsi.net]& > Sent: Sunday, March 31, 2002 8:01 PM > To: Info-VAX@Mvb.Saic.Com " > Subject: Re: Burning CD using LD >  > D > Deficiency duly noted. I will try to fix that in the next (final?) > iteration of my web pages. >  > Tom Linden wrote:  > > @ > > Thanks.  I didn't see that one anywhere.  But tht solved it. > >   > > > -----Original Message-----; > > > From: Alan E. Feldman [mailto:SPAMSINK2001@YAHOO.COM] * > > > Sent: Sunday, March 31, 2002 3:00 PM > > > To: Info-VAX@Mvb.Saic.Com & > > > Subject: Re: Burning CD using LD > > >  > > > 4 > > > "Tom Linden" <tom@kednos.com> wrote in message; > > > news:<CIEJLCMNHNNDLLOOGNJIAEGOEHAA.tom@kednos.com>... E > > > > I read the faq which directed me to David J. Dachtera site... 4 > > > > http://www.djesys.com/vms/cdrom.html#prepare > > > >  > > > > Example:0 > > > > $ LD CREATE CDROM.DSK/SIZE=184320 ! 90MB$ > > > > This went fine, but then ...+ > > > > FREJA>dir/size/date/owner CDROM.DSK D > > > > CDROM.DSK;1           184320  31-MAR-2002 09:42:33.08  [TOM] > > > > $ > > > > $ LD CONNECT CDROM.DSK LDA1:) > > > > FREJA> ld connect cdrom.dsk lda1: / > > > > %LD-F-DETECTEDERR, Detected fatal error 5 > > > > -SYSTEM-W-NOSUCHDEV, no such device available  > > > > D > > > > Also tried giving full file spec and leaving off lda1: , but > > > > same result  > > > > + > > > > Anybody know what I am doing wrong?  > > >  > > > L > > > Do you have LDA0:? Somewhere in the help, instructions, examples, ...,I > > > it shows you how do create it. Running a file called something like + > > > LD$STARTUP.COM (IIRC) will create it.  > > > + > > > Of course it could be something else.  > > >  > > >  > > > Disclaimer: JMHO > > > Alan E. Feldman ( > > > afeldman atski gfigroup dotski com > > >  > 3 > Sorry - I "top posted" this one! Look up there...  >  > -- > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/  >    ------------------------------  $ Date: Mon, 1 Apr 2002 13:42:42 -05000 From: "Mike Zarudzki" <mike.zarudzki@compaq.com>$ Subject: Re: Checksum goes cpu bound3 Message-ID: <FS1q8.1721$fL6.34382@news.cpqcorp.net>    Scott,  K  I just saw a post over in vmsnet.mail.pmdf which has a work around for the 	 CPU bound K checksum process. If your running PMDF you might want to look over there or  at the process5 PMDF archive at www.process.com/techsupport/pmdf.html    -Mike Z.9 "Bonita Fisher" <B.J.Fisher@Prodigy.net> wrote in message ; news:NZlp8.3223$lh5.150501421@newssvr17.news.prodigy.com... L > (I know that the checksum command is undocumented and unsupported, but the > question anyway) > I > We use checksum to check changes to a file during an anti-virus scan in J > incoming mail (details don't really matter).  Twice in the past week, weJ > arrived in the morning to find that the process doing a checksum had run for L > 6 hours (rather than more like 6 seconds) over night (thus backups did notG > finish ...).  This behavior is not completely unknown, but has anyone " > discovered any solution or help? >   > We are OpenVMS 7.2-1 on Alpha. >  > thanks >  > scott  >  > Scott.Fisher@Remmele.com >  >  >  >    ------------------------------  # Date: Mon, 01 Apr 2002 11:19:12 GMT ' From: Colin Blake <colin@theblakes.com> # Subject: Re: Commnets on Mozilla9.9 - Message-ID: <3CA84212.B7BBE40C@theblakes.com>    John Reagan wrote:  J > The only time when it takes a long time to load is if a previous MozillaH > died.  The next invocation seems to spend lots of time either deleting> > previous temporary files or rattling around in my [.mozilla]J > subdirectory looking for something.  If I exit/restart normally, then it! > comes up in just a few seconds.   L After a crash, the next time up it will delete all the cache files. Its in a readdir/delete loop.   ------------------------------   Date: 1 Apr 2002 04:43:21 -0800 ) From: P.Young@unsw.EDU.AU (Patrick Young) # Subject: Re: Commnets on Mozilla9.9 = Message-ID: <55f85d77.0204010443.21202261@posting.google.com>   [ John Reagan <john.reagan@compaq.com> wrote in message news:<3CA7CEF6.8090801@compaq.com>...  > J > I've been using it on my XP1000 (667Mhz, 2GB RAM) machine for months. I K > have huge account quotas to match.  With that, I find Mozilla (I'm using  # >   0.9.8) quite usable and stable.  >   H Much the same as I do - at work I spend a couple of hours each day usingH a mix of Mozilla and Netscape (for the large data downloads - Mozilla isK slow on this) both under OpenVMS. At home I use only Mozilla under OpenVMS.  Both perform very well.   E My general rule of thumb is that if it does not work under Mozilla or H Netscape (both OpenVMS) then it is not something I need to see (or wouldC be interested in). Simple as that (all new additions to Mozilla are C welcome as it extends what I can do on the WWW). If it is something E I'm *TOLD* to see or *TOLD* I have an interest to see, then I use VNC H viewer from my OpenVMS box to a Window(tm) 2000 box and use the NetscapeG 4.7x installed there. If there is a bug concerning one of my web sites, F I might use M$ IE to verify the bug - the "line" however is _drawn_ at that point.   C I am happy with Mozilla under OpenVMS in that it does 99% of what I 4 *NEED* to do in life, including my Internet banking.   ------------------------------  % Date: Mon, 01 Apr 2002 12:34:42 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> < Subject: Compaq set to unveil new Terabit Network Technology, Message-ID: <3CA89A1F.2CB38628@videotron.ca>  >               Some Perceived Problems with the Introduction of4                        Terabit Network Technologies.                  ,                                Julian Onions         /                              X-Tel Services Ltd +                                 Nottingham. *                                   ENGLAND.                  *                                   ABSTRACT         ?                   This short paper attempts to  highlight  some ?              potential  problems  associated with the introduc- ?              tion of high speed networking  -  specifically  at ?              the  Terabit  per second level. These problems are ?              still in the theoretical arena as practical  Tera- ?              bit networks are probably still several weeks away               from fabrication.                                    Introduction.          D         The primary problem when considering Terabit  networks  mustD         be the enormous speed that the packets on such networks willD         be traveling.  Naturally there are problems at the  protocolD         level  with  very  large  window  sizes necessary for usefulD         throughput, and enormous quantities of data in flight at anyD         one  point.  However,  these problems are encountered at theD         Gigabit level and are solvable in principle (by  appropriate9         window and packet size negotiation for instance).          D         The major problem that is perceived at such high  speeds  isD         that  data  is  now flowing at a significant fraction of theD         speed of light. This brings into play a number of relativis-D         tic  effects  that must be taken into account when designing!         such high speed networks.                    Physical Considerations.         D         There are firstly a number of physical  considerations  thatD         must  be  taken  into account. These are problems associated@         with any body traveling close to the speed of light (c).         D         1.   A large amount of energy is required to accelerate  theD              packets  to  the required velocity. However, the closerD              one  approaches  c  -  the  more  of  that  energy   isD              transformed   into   mass.  Thus  packets  will  becomeD              heavier. A related  problem  is  the  slowing  down  ofD              packets, when they enter conventional lower speed Mega-D              bit networks. The large amounts  of  energy  that  haveD              gone  into  accelerating  the  packets  and giving themD              extra mass will be lost. This will require  large  heatD              sinks.  Cable  fractures may also be explosive in theseD              cases (which is in keeping with the   abbreviation  TNTD              Terabit  Network  Technologies).  Alternatively, a spe-D              cial large coil of cable could be  used  to  allow  the,              packets to naturally slow down.  D         2.   Networks often need to be  laid  to  fit  the  physicalD              shapes  of buildings and other infrastructure. When anyD              body traveling close to  c  undergoes  acceleration  itD              tends  to  emit  breaking  radiation or bremsstrahlung.D              This is particularly noticeable  when  bodies  have  toD              undergo  angular  acceleration  when  turning  corners.D              Thus any bends in the cabling will have to  be  heavilyD              shielded  with lead plates to stop the intense burst ofD              high energy particles.  At high enough speeds, the cur-D              vature  of  the Earth may also prove a significant loss              of energy.          D         3.   Whilst traveling  at  high  speeds,  the  packets  willD              undergo  time-dilation effects. Thus whilst two ends ofD              a connection may agree  on  a  round-trip  time  for  aD              packet,  this may well be different to the packets per-D              ceived RTT. The packets estimate of  the  RTT  will  beD              shorter than the measured delay. Therefore if times are<              kept in the packet this will lead to confusion.         D         4.   When a body is traveling at high speeds,  it  tends  toD              shrink in the direction of the travel.  This means thatD              a packet taking 1400 bytes, might actually take up 1300D              bytes space on the network. This leads to more capacityD              being available than might first be perceived.  HoweverD              all  routers must be able to handle packets at speed toD              stop them  suddenly  growing.  This  leads  to  circuit?              switching being possibly a better base technology.          D         A perhaps more serious problem is the case of collisions  onD         a  network technology such as ethernet. The collision of twoD         very high speed packets could give rise to many  spectacularD         effects,  equivalent  to  those  seen  in  current  particleD         accelerators. In particular the creation of virtual  packetsD         may be a cause of errors. These packets would be short livedD         and would be undetectable directly except in the presence ofD         close detectors. However they may decay into real packets ofD         dubious composition  which  will  have  to  be  trapped  andD         ignored.  In  practice checksumming will probably catch many         of these cases.                    Protocol Considerations.         D         Due to the relativistic effects of traveling at high  speed,D         the  packets  will age at a slower rate than the rest of the5         world. This has impact on several parameters.          D         1.   Any time-to-live parameters may be  affected.   In  theD              non-relativistic  world has the packet has aged severalD              seconds, however the packet travelling  at  high  speedD              may  only  have  aged a few milliseconds. A packet withD              the destination of mars for instance, may in  the  realD              world  take several minutes to complete the round trip,D              but from the  packets  view  it  will  only  be  a  few              seconds.          D         2.   Security based on time stamps will have to be reviewed.D              Traveling  at  high speeds means that a window of a fewD              seconds is now much wider, because of  the  slowing  ofD              time  whilst  the packet containing the timestamp is in              flight.  D         One possible way of nullifying many of these effects  is  toD         make use of the session layer in the OSI model. With all itsD         inherent complexity, the session layer should add an  effec-2         tive braking force to many of the packets.         D         Another potential problem is red and blue shifting of  data.D         As  viewed  by  a  static network connector, the approachingD         data may well be blue-shifted by an appreciable amount. ThisD         might  be viewed as the equivalent of the logical-shift-leftD         operation. Data may very  well  appear  distorted  while  inD         transit.  Checksumming data in this environment is not goingD         to be easy. Similarly interface taps  attempting  to  verifyD         their  own  data may as it is transmitted may be confused by#         red-shifted data departing.          #         Application Considerations.n         D         There is much  potential  for  confusion  when  relativisticD         effects  are considered at the application level. It is com-D         mon  to  see  the  timestamps  on  messages   go   backwardsD         currently,  but  this  is  normally  due  to  unsynchronisedD         clocks. With time dilation effects it may  be  possible  forD         packets  to actually go backwards in time for small periods,$         further confusing the issue.         D         The Network Time Protocol (NTP) will have to be revisited toD         take into account the compression of time in packets. Possi-D         ble confusion may arise when it appears that a site  severalD         light  minutes  away  is  actually  only  taking  a few mil-4         liseconds to complete the network traversal.                  Other Considerations         D         The potential for compression of data whilst in flight couldD         lead  to  several possibilities. In particular the old tech-D         this technique. With sufficient power input it may be possi-D         ble to store many gigabytes in a short length of cable, pro-D         vided  of  course the floor is suitably strengthened to dealD         with the corresponding gain  in  mass.  Extensibility  usingD         this  technique  is easy and cheap. Just add a longer bit of         cable onto the reel.                  April 1, 1992-   ------------------------------  % Date: Mon, 01 Apr 2002 12:51:02 -0500 1 From: Michael Austin <maustin@firstdbasource.com>R@ Subject: Re: Compaq set to unveil new Terabit Network Technology2 Message-ID: <3CA89E06.BDA0CA76@firstdbasource.com>  = This is interersting.. especially the date at the bottom.. :)    JF Mezei wrote:c > @ >               Some Perceived Problems with the Introduction of6 >                        Terabit Network Technologies. >         April 1, 1992s   -- i Regards,  7 Michael Austin            Registered Linux User #261163f7 First DBA Source, Inc.    http://www.firstdbasource.comk Sr. Consultant   ------------------------------  % Date: Mon, 01 Apr 2002 08:33:53 +0100, From: Roy Omond <Roy@Omond.net>-L Subject: Re: DCL minute of the day: navigation, degrees and all these things) Message-ID: <3CA80D62.F95F73D8@Omond.net>c   Michael Austin wrote:e  1 > or you can just do this in PERL -- even on VMS:t >o, > $perl -e print(((3.14159265*2)/360)*1000); > 17.4532925  1 Not tested, but consider also ICALC from Hunter'sgD collection at: ftp://ftp.process.com/vms-freeware/fileserv/icalc.zip  = This should give you "infinite" precision and integrates (:-)t nicely with DCL.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Mon, 01 Apr 2002 12:44:41 -0500o- From: JF Mezei <jfmezei.spamnot@videotron.ca> % Subject: DECNET Pahse XVIII announced-, Message-ID: <3CA89C75.C4976C5A@videotron.ca>   <another blast from the past>@      Xerox Announces Hyper-Ethernet    n= Hyper-Ethernet enables the transmission of people.  ``People  A transmission over Hyper-Ethernet,'' according to Michael Liddle, uB V.P. of Office Systems, ``will greatly reduce elevator congestion C and eliminate the need for video conferencing.''  Order taking for  B Hyper-Ethernet will begin next month.  Installation will start in ! Los Angeles in the Third Quarter.     cB   In a related announcement, Wang Labs, headquartered in Hoboken, B New Jersey, announced Super-Hyper Wangnet, its twelfth generation B local area network.  According to Freddie Wang, President of Wang C Labs, ``Super-Hyper Wangnet will not only transmit people over the  A Wangnet, but will also transmit furniture and buildings over the  B interconnect and utility bands.  These additional capabilities of  Super-Hyper Wangnet are vitalC    n<   to the emerging office of the future.''  Order taking for E Super-Hyper Wangnet will begin next month.  Installation has already . occurred worldwide.e    wD   IBM Corporation, which has been rumored to be about to announce a = local area network since 1980, was not available for comment.      D   ------------------------------------------------------------------    .$   Digital Responds to Hyper-Ethernet    SD   TEWKSBURY, MA, April 1, 2010 -- Digital Equipment announced today @ its new DECNet Phase XVIII Architecture.  In response to recent A Xerox and Wang improvements to Ethernet that provide people- and aE facility-transportation across inter-node links, DEC's latest DECNet  E provides these capabilities as well as providing for the creation of b? virtual facilities and even countries.  These capabilities are mE provided by breakthroughs in communications technology that actually hE uses the Ether as a communications medium.  Through the use of a new i? dedicated NANO-PDP-11/E99 gateway processor system, ETHERGATE, I7 DECNet users can access anywhere in the Ethereal Plane.     hD   This development obsoletes teleconferencing, since meeting groups B can create their own common conference rooms and cafeterias, thus B resolving space, travel, and dining problems.  There may be a few A bugs left, as some of the dissenting DECNet Review Group members iA have not been seen since the last meeting held in such a virtual o conference facility.    -C   This breakthrough was brought about by a team of the Distributed u@ Systems Software and Hardware engineering teams in an effort to ; improve on their Tewksbury, Massachusetts, facility.  In a  D compromise decision, Distributed Systems will maintain an ETHERGATE E in TWOOO but it will connect directly to their new home somewhere in uE the Shire of their newly defined Middle Earth reality.  Despite some .: difficulties, the scenery, windows, tax breaks, pool, and ; racquetball courts made the relocation go quite smoothly.  2E Engineering Network topology will not change, as all forwarding will k? be done by the TWOOO Ethereal Plane Router residing in Utility a= packages such as Ethereal Person Transfer (EPT) and Ethereal  D Facility Transfer (EFT) provide appropriate capabilities for casual E users.  Sophisticated users can create ($CREATE), access ($OPEN) and  @ delete  ($NUKE) ethereal entities transparently from high level E languages using the Ethereal Management System (EMS) package and the sA Ethereal Access Protocol (EAP).  An ETHERTRIEVE utility for easy a* interactive use will be available shortly.    oE   DECNet Phase XVIII follows on the success of the Phase XVI ability  > to access everyone's Digital Professional Wristwatch computer C system. The lead to the current Phase XVII architecture, which has j? routing capabilities that allow direct communications with the t1 entire Earth population's Atari home video games.t    hD   Distributed Systems architects are hard at work on the next phase E of DECNet that will include multi-plane existence network management sB (using the NIECE protocol) and galaxy level routing using 64K-bit 
 addresses.     A   Digital will continue to support its Gateway products into the w8 Prime Material Plane. These products include an IBM ANA B (Acronym-based Network Architecture) Gateway, the TOLKIEN product 8 that allows control of all ring based networks, and our B Mega-broad-jump-band hardware which leaps past Wang's products in $ the hype-weary business marketplace.   ------------------------------   Date: 1 Apr 2002 08:22:30 -0600m+ From: young_r@encompasserve.org (Rob Young)82 Subject: Re: EMC / Symmetrix information requested3 Message-ID: <Cv0H8fAZIWCZ@eisner.encompasserve.org>e  q In article <cf15391e.0203311932.636a9edc@posting.google.com>, keithparris_NOSPAM@yahoo.com (Keith Parris) writes:uk > "Tom Simpson" <simpsont@attbi.com> wrote in message news:<mZjp8.1584$Ba.2127549@typhoon1.se.ipsvc.net>...eM >> Does anyone have experiences with EMC in general and the Symmetrix 3830-36 9 >> disk array (or similar) that they would like to share?  > D > This has been a common topic of discussion here in comp.os.vms.  IG > strongly suggest you do a Google search on "EMC" and read what's been  > written here before. >  > But to summarize:oH > o  EMC doesn't support the SCSI Read-Long/Write-Long that HBVS uses toG > simulate Forced-Error flags on SCSI disks.  It also won't support theeG > Write History Logging that the HSG80 soon will have, which will allow G > brief (seconds) mini-merges instead of full (hours-long) merges aftery > a node crashes.h% > o  EMC doesn't have mirrored cache.nB > o  EMC doesn't support dual-redundant controller configurations.@ > o  EMC requires that you buy in units of big, expensive boxes.  = 	I agree on most of this.  I'm not sure about how long merges  	take.  H > o  EMC will insist on doing all the storage configuration itself.  YouD > won't know how the storage is configured inside the box, so if youB > have performance problems, you won't have the information or the1 > control you need to fix it in a timely fashion.     ; 	If you take time to find out how the storage is configured 8 	inside the box by studying the bin files, you will know> 	how it is laid out.  But what they do is make sure it is laidC 	out so mirror pairs aren't on the same directors.  You are working.A 	with mirrors (hypers) or RAID10 (metas) in most cases.  They run @ 	a program (programs?) that essentially tells them how to lay it> 	out for the physical storage in the box.  I'm glad the HSV is= 	here so I don't have to figure out how to lay out storage ini? 	HSG80,HSJx0, etc.  See discussion in comp.arch.storage whethero@ 	it is advantageous to lay out RAID5 members diagonally in HSG80@ 	single bus kit (I say it is, feel free to join the discussion).    D > o  Consensus is that EMC storage costs about 1.5X the competition.   	Oh... what to say what to say.    > E > If you can direct the discussion toward technical issues and costs,e > you can win this battle. >c  A 	This has an assumption built in.... the assumption is that theree 	is a level playing field.   				Robe   ------------------------------  % Date: Mon, 01 Apr 2002 10:12:32 -0800t' From: David Mathog <mathog@caltech.edu>h Subject: extract for Unixt+ Message-ID: <3CA8A310.2FF846D3@caltech.edu>t  I For many years I was a happy user of Pat Rankin's EXTRACT utility on VMS. ? It was one of the things I missed most once our last VMS system @ was turned off. Sure, there was awk and perl but to be perfectlyA honest I'm not very fond of either; they're both much too complex ; as replacements for simple EXTRACT commands and I'm foreverrA trawling through the man pages or perldoc to figure out how to donC something. So, finally, I decided to write a version of EXTRACT for A Unix (and Windows, and VMS too, but of course, you've already gotuA EXTRACT there and don't need it as much.)   This "extract" is nott; a port of Pat's fine utility - it's a complete rewrite withd? similar column reordering functionality but a different command.? line, completely new code, and on the negative side, no ability = to handle anything other than text files. There's a companion > program "execinput" which can be used to execute many lines of< extract output in a pipe (without having to resort to a loop" structure in the calling script).   ; Here's a typical example that extracts some space delimitedcF columns, pads some of them out to 10 spaces and right justifies, emits; one other column, and changes the last value to lower case.   I # echo "A B C D 12" | extract -mt -cols '[fw10:jr:3,] from [1] to [cl:2]'a,          C          D         12 from A to b  ? Here's an example where it is used to clean up some file names.n   # ls -1 *htm Facility Guidelines.htme$ Macintosh configuration for 3100.htm Primer Design.htm 9 # ls -1 *htm | extract -cols 'mv "[:1,]" [mt:cl:dv_:1,]'  4 mv "Facility Guidelines.htm" facility_guidelines.htmN mv "Macintosh configuration for 3100.htm" macintosh_configuration_for_3100.htm( mv "Primer Design.htm" primer_design.htmC # ls -1 *htm | extract -cols 'mv "[1,]" [mt:cl:dv_:1,]' | execinput  # ls -1 *htm facility_guidelines.htm $ macintosh_configuration_for_3100.htm primer_design.htmt  B And finally, there's rarely a need to dig out the man page because   # extract -helph  " will list the command line options  ; If you would like to give "extract" and "execinput" a whirl ; the source code and .html documentation are available here:   ; ftp://saf.bio.caltech.edu/pub/software/linux_or_unix_tools/    Regards,   David Mathog mathog@caltech.edu   ------------------------------   Date: 1 Apr 2002 07:56:58 -0800  From: wingwong@witty.com (wing)  Subject: File IO query. = Message-ID: <873e96d6.0204010756.2fbfc587@posting.google.com>s   Hi,   E I have written a testing program to write 10000 records in a file. It F takes less than 4s. However, if I run 48 copies of the testing programF at the same time (by submit it to a job queue), it takes >47s to write 10000 records.   How to avoid this?  < I am using standard C to open a file with some VMS specified" attribute, the code is as follows.  > ::open(filename.c_str(), O_CREAT | O_APPEND | O_WRONLY, 00644, "shr=get", "rop = asy");  E I have not called fsync in the testing program as I intent to let ther system to fsync the file.    Thanks in advance,   Wing   ------------------------------  # Date: Thu, 28 Mar 2002 03:06:32 GMTa1 From: "Terry C. Shannon" <terryshannon@attbi.com>  Subject: Re: Good IBM Ad: Message-ID: <YMvo8.42071$44.15522793@typhoon.ne.ipsvc.net>  A "Tim Llewellyn" <tim.llewellyn@blueyonder.co.uk> wrote in messageh* news:3CA204D1.6705BC4D@blueyonder.co.uk... >t >  > "Terry C. Shannon" wrote:s >l > >eH > > If curly anf carly work for Wintel, why have they not dumped NSK? It makesaK > > money, probably even a little more money than VMS makes. (NSD did $1.3Bl last0 > > year, up year-over-year, very nice margins). > >  >mH > NSK is not a potential rival to M$ (and linux) at the mid and low end?  L Umm, no, unless Microsoft comes up with something more convincing than their insipid 5-nines advertisements.o  L Several years ago, there was an effort afoot to port the NSK-centric NonStopI SQL/mx database to NT. A companion project was designed to render NT moreaG "industrial-strength." The program was called SCULPTOR, Enrico Pesatorio nuked it in Spring 1999.  < Several months later, Compaq said hasta la vista to AlphaNT.   > F > Well, you asked Terry. Not saying I believe the conspiracy theories,  > but having an open mind helps. >eL > > And if curly works for Wintel, why is it that CTO Shane Robison elevatedJ > > Linux to Program Office status last year, right about the time a whole bunch # > > of Windoze loyalists got nuked?  >aH > Its an empire building, dog eat dog world out there in Compaq land :-)   That it most certainly is!   ------------------------------  # Date: Thu, 28 Mar 2002 03:09:41 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>. Subject: Re: Good IBM Ad: Message-ID: <VPvo8.42073$44.15524543@typhoon.ne.ipsvc.net>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3CA13AB7.CA7970B1@fsi.net...c > "Terry C. Shannon" wrote:e > >f@ > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message% > > news:3CA12FEB.C70B2BFC@fsi.net.... > > > "Stuart, Ed" wrote:t > > > >eL > > > > Looks like IBM hires marketing firms that deliver.  The back page of thefJ > > > > current issue of Computerworld has an ad for their eserver series. Thep > > adK > > > > says "Runs UNIX. Runs LINUX. And runs runs runs runs runs runs...."e Ac? > > > > concept like this would have worked well for OpenVMS onl
 AlphaServers.  > > > I > > > Nah - might have made them a pile of money, which is the last thingb= > > > anyone at the Q wants to see either OVMS or Alpha do...  > >tJ > > Umm, I would venture to guess that Mark Gorham, Sue Skonetski, and the UsualeH > > Compaq Lurkers in comp.os.vms would like to see VMS make big bags of > > money... >mJ > Well, Sue and the ng denizens (sounds like a musical group, eh?) I couldH > see. From Mark G.('s level) on up, I see no evidence to support such a > claim.  K How well do you know Mark? I see no reason why he wouldn't want VMS to makeyL big bags of money, he's the VP in charge of the product. Also one of the key' supporters of the VMS Hobbyist program.y  J So I would submit that one should be looking a bit higher on the org chart than the Mark Gorham level.h   ------------------------------  # Date: Thu, 28 Mar 2002 03:17:05 GMTt1 From: "Terry C. Shannon" <terryshannon@attbi.com>o Subject: Re: Good IBM Ad: Message-ID: <RWvo8.42076$44.15529759@typhoon.ne.ipsvc.net>  A "Tim Llewellyn" <tim.llewellyn@blueyonder.co.uk> wrote in messagec* news:3CA20170.21D27221@blueyonder.co.uk... >i >  > "Terry C. Shannon" wrote:u > >g@ > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message% > > news:3CA12FEB.C70B2BFC@fsi.net...r > > > "Stuart, Ed" wrote:hI > > > Nah - might have made them a pile of money, which is the last thingn= > > > anyone at the Q wants to see either OVMS or Alpha do...r > >tJ > > Umm, I would venture to guess that Mark Gorham, Sue Skonetski, and the UsualiH > > Compaq Lurkers in comp.os.vms would like to see VMS make big bags of > > money... >tF > just how are they going to do that without targeting new or recently > discarded markets?  H Good question. Perhaps VMS Marketing has a Better Answer, because I sure
 don't! ;-}   ------------------------------  # Date: Thu, 28 Mar 2002 15:04:15 GMTa1 From: "Terry C. Shannon" <terryshannon@attbi.com>e Subject: Re: Good IBM Ad: Message-ID: <PhGo8.42257$44.15901474@typhoon.ne.ipsvc.net>  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:6E$KGaxL9Onh@eisner.encompasserve.org...f? > In article <d7791aa1.0203270623.4664bc0a@posting.google.com>, * bob@instantwhip.com (Bob Ceculski) writes: >0J > > I still don't understand why IBM didn't step in and make a hostile bidL > > for Q ... w/alpha vms tru64 they would have ruled the high end world ... > I >    IBM is quite certain they already own the world.  That's why they're : >    one of the few companies Bill Gates cant push around. > F Well, it seems to me that IBM had a rawthuh unpleasant experience with0 Micro$oft some years back. T'was an OS/2 Moment.  J At least IBM is smart enough to keep Micro$oft at arm's length rather than  playing the role of organ donor.   ------------------------------  $ Date: Mon, 1 Apr 2002 12:47:29 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>,3 Subject: Re: Help! VT100 emulators - some problems.m3 Message-ID: <291q8.1714$fL6.34032@news.cpqcorp.net>h  " Thomas Dickey wrote in message ...5 >Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:s >oI >> support to VWS.  There was no standard ANSI definition for this, so we0F >> created a DEC-specific set of ANSI compliant sequences.  These thenD >> propagated into both "real" terminals, DECterm, and other non-DEC
 emulators.G >> Xterm, on the other hand, "hacked" in some invalid escape sequences.  >oE >hmm - aside from the misuse of ST (string terminator) for the title,oA >what else may you be referring to?   Your work on DECterm, to beeC >in the proper time-relationship for those comments would of course9 >have to be before 1988... >a  D It's been a long, long time since I had anything to do with terminalF emulation, and it predates DECterm.  I'd have to fire up a long unusedH workstation at home to even find mail that old -- mid-80's or so I would imagine.  I >(iirc, the first time I saw a usable vt100 emulator on a workstation wascF >in 1983, roughly 800 lines of Pascal - still more than the ~250 lines' >you suggest in the preceding article).e >n  H The first VT100 emulator I saw was a god-awful, but really fast Macro-32J spagetti code written for the VAXstation I on VWS -- that has to be aroundK 1983/84 or so.  I replaced that code in the mid-80's with a VT200 emulator, L that included VT100 emulation as well as VT52 emulation.  My recollection isF that the core logic of the VT100 was relatively trivial.  Of course, II haven't looked at that code for more than a decade, so it's relative sizeeD (and what it would be extracted from the VT200 code) may have shrunkI somewhat with time.  It also was on top of a graphics system with greaterrL capabilities than X11 (which pre-dated X11) - I seem to remember the DECterm/ people having to re-invent the wheel in places.n   ------------------------------  $ Date: Mon, 1 Apr 2002 12:58:10 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>i3 Subject: Re: Help! VT100 emulators - some problems.,3 Message-ID: <3j1q8.1715$fL6.34246@news.cpqcorp.net>   " Thomas Dickey wrote in message ...D >In comp.os.vms Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:G >> IMHO, this is because most of the people who write these things have, neverlH >> actually picked up a copy of the old ANSI specs.  Nor do many of themJ >> contain a real ANSI parser.  The xterm developer, for example, liked to: >> create non-ANSI compliant escape and control sequences. > 6 >a few examples would be more informative than a rant. >o  K I admit to Old-Timers disease.  Anything > a decade old isn't gonna get youEF details on gripes I had all those years ago.  I seem to remember beingD beaten up (around the time I was looking to stop working on terminalJ emulators) about adding features that were in xterm for compatability, andK that when I looked into them I found were unsupportable since the sequenceso were not valid sequences.   I >> Emulating a VT52 can be done with about a screen page worth of code, ah VT100uI >> in probably 5 times as much - and is easy to get right.  VT200/300/500a) >> requires a *lot* of code to get right.e >dG >judging by the number of poor vt100 implementations, it is not easy to  >get right., >c  H I will admit that having direct access to people who worked on, and codeK originally used on the VT200 certainly helped with correctness.  As did thenI huge amount of shakeout that occurred internally from people who used the A emulator.  Back then, DEC still had a lot of really good terminalb& architect's that could be called upon.  H Nonetheless, I can see getting a VT200/300/500 wrong - since they became; *really* complex.  But the VT100 was a pretty simple beast.   K I'll have to see if I can revive the system with my copy of the code on it.a   ------------------------------  $ Date: Mon, 1 Apr 2002 10:42:48 -0800" From: GreyCloud <mist@cumulus.com>3 Subject: Re: Help! VT100 emulators - some problems.l/ Message-ID: <uaha2n9jq6jpd9@corp.supernews.com>e   Thomas Dickey wrote:  % > GreyCloud <mist@cumulus.com> wrote:t >> Thomas Dickey wrote:A > ' >>> GreyCloud <mist@cumulus.com> wrote:a >>>> Thomas Dickey wrote:  >>> I >>>> Interesting.  Then I'd suppose they'd be happy to hear some feedbacki	 >>>> fromcF >>>> you.  Is there a site for learning more about terminfo or termcap >>>> files?? >>> J >>> not really - none that I'd find useful.  I have a copy of the O'ReillyJ >>> termcap/terminfo book, which tells some interesting stuff, but betweenE >>> that and the terminfo/termcap manpages there's a large gap.  (ThehJ >>> problem with the manpages is that most of the items "capabilities" areJ >>> documented in only one line - the O'Reilly book expands on a number ofI >>> those, but ignores color and related topics which were not of generale >>> interest in the mid 80s'). >>>  > J >> Ah!  That explains why I can't seem to find any detailed information onI >> this topic.  The only place that seems to have some detail was some ofb >> Suns' docs. > L > the printed manuals (not manpages), I assume.   SCO's manuals are reportedE > to have useful stuff also, though some things seem to have not been  > documentedJ > well by anyone.  For instance, this terminfo entry (I'm on Solaris 2.5.1K > right now) corresponds to a flavor of xterm which I've not seen much infofL > about (see the getm, kmous strings).  SVr4 curses implements mouse supportB > explicitly for that terminal - but it isn't documented any more. > H > #Reconstructed via infocmp from file: /usr/share/lib/terminfo/x/xtermc: > xtermc|xterm terminal emulator (color) @(#)xterm.ti 1.3, > am, km, mir, msgr, xenl,3 > btns#3, colors#8, cols#80, it#8, lines#24, ncv#7,s > pairs#64,n: > acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,6 > bel=^G, blink=@, bold=\E[1m, clear=\E[H\E[2J, cr=\r,3 > csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=\E[1D, 3 > cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,g2 > cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,3 > dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,t2 > ed=\E[J, el=\E[K, el1=\E[1K$<3>, enacs=\E(B\E)0,, > getm=\E[%p1%dY, home=\E[H, ht=\t, hts=\EH,3 > ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L,s/ > ind=\n, ka1=\EOq, ka3=\EOs, kb2=\EOr, kbs=\b,E- > kc1=\EOp, kc3=\EOn, kcub1=\EOD, kcud1=\EOB,n/ > kcuf1=\EOC, kcuu1=\EOA, kend=\E[Y, kent=\EOM,n6 > kf0=\EOy, kf1=\EOP, kf10=\EOY, kf11=\EOZ, kf12=\EOA,3 > kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOT, kf6=\EOU, 8 > kf7=\EOV, kf8=\EOW, kf9=\EOX, khome=\E[H, kmous=\E[^_,8 > knp=\E[U, kpp=\E[V, op=\E[100m, rc=\E8, reqmp=\E[492Z,0 > rev=\E[7m, ri=\EM, rmacs=^O, rmcup=\E@0\E[?4r, > rmso=\E[m,. > rs1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H,0 > rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,% > setab=\E[4%p1%dm, setaf=\E[3%p1%dm,i > L setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m, > L setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m, > O sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N%e^O%;,c4 > sgr0=\E[m^O, smacs=^N, smcup=\E@0\E[?4s\E[?4h\E@1, > smso=\E[7m, tbc=\E[3g, >   G Yes, I was using Solaris 8 and the online docs explained how these are dJ formed and then compiled.  But I don't use Solaris 8 at this time.  Maybe ' give docs.sun.com a  look-see perhaps??    ------------------------------   Date: 1 Apr 2002 07:54:41 -0800n  From: andylo@kc.rr.com (Andy Lo)& Subject: Re: help!!! compilation issue= Message-ID: <5a87da2e.0204010754.4cd2294c@posting.google.com>   * I didn't use the cast operator in my code. How can I fix this?c   thanks    [ Didier Morandi <Didier.Morandi@free.fr> wrote in message news:<3CA396E6.7BC276A@free.fr>...  > Frome > http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V40F_HTML/AQTLTBTE/DOCU_061.HTM#cast_op  >  > 6.4.6 The Cast Operator  > N > The cast operator forces the conversion of its scalar operand to a specifiedI > scalar data type, or to void . The operator consists of a type-name, ine8 > parentheses, that precedes an expression, as follows:  >  > ( type-name ) expression > L > The value of the expression is converted to the named data type, as if theP > expression were assigned to a variable of that type. The expression's type andO > value are not themselves changed; the value is converted to the cast type forsN > the duration of the cast operation. The type-name has the following syntax:  > 
 > type-name: C > ' >    type-specifier abstract-declaratorf > Q > In simple cases, type-specifier is the keyword for a data type, such as char or"9 > double, and abstract-declarator is empty. For example: w > 	 > (int)x;i > P > The type-specifier can also be an enum specifier, or a typedef name. The type-M > specifier can be a structure or union only if the abstract- declarator is alO > pointer. That is, the type-name can be a pointer to a structure or union, butiT > cannot be a structure or union because structures and unions are not scalar types. >  > For example:   > % > (struct abc *)x   /* allowed     */  > % > (struct abc)x     /* not allowed */m > H > The abstract-declarator in a cast operation is a declarator without an> > identifier. Abstract declarators have the following syntax:  >  > abstract-declarator: ] > 
 >    empty >    abstract-declarator >    * abstract-declarator >    abstract-declarator ( )0 >    abstract-declarator [ constant-expression ] > A > The abstract-declarator cannot be empty in the following form: . >  > (abstract-declarator)- > M > Abstract declarators can include the brackets and parentheses that indicatesS > arrays and functions. However, cast operations cannot force the conversion of any I > expression to an array, function, structure, or union. The brackets and"S > parentheses are used in operations such as the following example, which casts the_- > identifier P1 to pointer to array of int :   >  > (int (*)[10]) P1;r > Q > This kind of cast operation does not change the contents of P1 ; it only causes S > the compiler to treat the value of P1 as a pointer to such an array. For example,rQ > casting pointers this way can change the scaling that occurs when an integer isu > added to a pointer:  > 
 > int *ip;4 > ((char *)ip) + 1;   /* Increments by 1 not by 4 */ > Q > Cast operators can be used in the following conversions that involve pointers: g > M > A pointer can be converted to an integral type. A pointer occupies the samegE > amount of storage as objects of type int or long (or their unsignedoM > equivalents). Therefore, a pointer can be converted to any of these integeriR > types and back again without changing its value. No scaling takes place, and the/ > representation of the value does not change. g > N > Converting from a pointer to a shorter integer type is similar to convertingO > from an unsigned long type to a shorter integer type; that is, the high-order"% > bits of the pointer are discarded.   > R > Converting from a shorter integer type to a pointer is similar to the conversionN > from a shorter integer type to an object of unsigned long type; that is, theO > high-order bits of the pointer are filled with copies of the sign bit. DEC C, P > with the check option enabled, issues a warning message for cast operations of
 > this type. l > N > A pointer to an object or incomplete type can be converted to a pointer to aR > different object or a different incomplete type. The resulting pointer might notQ > be valid if it is improperly aligned for the type pointed to. It is guaranteed,eQ > however, that a pointer to an object of a given alignment can be converted to aeO > pointer to an object of the same alignment or less strict alignment, and back R > again. The result is equal to the original pointer. (An object of character type# > has the least strict alignment.) n > Q > A pointer to a function of one type can be converted to a pointer to a functionQN > of another type and back again; the result is equal to the original pointer. > R > If a converted pointer is used to call a function that has a type not compatibleC > with the type of the called function, the behavior is undefined.   > [end of quote] >  > D.. > Available to cast VMS operators worldwide... >  >  > Andy Lo wrote: > > F > > I'm trying to use both 32-bit and 64-bit pointers on a VMS system. > >  > > Here is my system.# > > -------------------------------b > > $cxx /versione# > > -------------------------------t > > 0 > > Here is the simple program I try to compile.# > > -------------------------------t > > #include <iostream.h>- > >  > > void main()- > > { , > >   cout << "This is just a test" << endl; > > } # > > -------------------------------u > >  > > Here is how I compile it.V# > > -------------------------------v- > > cxx /model=ansi /pointer_size=32 test.cxxi# > > -------------------------------. > > % > > Here is the error/warning messageo# > > -------------------------------d, > >   cout << "This is just a test" << endl; > > ..^EI > > $CXX-W-WAYLOSEDATA, cast from long pointer to short pointer will lose 	 > > data.r? > > at line number 5 in file $7$DKB100:[ANDY.TESTING]TEST.CXX;1 # > > -------------------------------  > > I > > It's only a warning.  It creates a TEST.OBJ file so I can use that toAJ > > link.  But I'm worry some unknown stuff will screw me later.  It'll beJ > > nice if someone can give me a solution.  Otherwise, a good explanation9 > > is good too.  If not, any idea/suggestion is welcome.  > >  > > Thanks in advance. > >  > > Andy   ------------------------------  # Date: Mon, 01 Apr 2002 14:07:05 GMT # From: "John Smith" <a@nonymous.com>o0 Subject: HP Won't Renominate W. Hewlett to BoardF Message-ID: <dQZp8.20946$dVT.730@news01.bloor.is.net.cable.rogers.com>  ' HP Won't Renominate W. Hewlett to Boarde( Last Updated: April 01, 2002 07:39 AM ET  I PALO ALTO, Calif. (Reuters) - Hewlett-Packard Co. HWP.N on Monday said iteG would not reappoint dissident board member Walter Hewlett, who has been J fighting an increasingly bitter battle to prevent the computer and printerJ maker's proposed $19 billion acquisition of personal computer maker Compaq Computer Corp. CPQ.N .  H In a statement, HP said the board's decision not to nominate Hewlett wasK based on his adversarial relationship with the company, as evidenced by hisRF recent litigation against HP. It also cited concerns about his lack of candor and issues of trust.e  E Hewlett filed suit last week in effort to prevent the deal from goingnI through. He alleged that HP management bought votes in the contentious HPhD shareholder vote last month and misled a key adviser about the deal.    HP has called the suit baseless.      C Time for all HP shareholders to send write-in ballots for their ownsJ nominees. You have to wonder how the approximately 50% of shareholders whoG voted against the merger will take their revenge on the remaining boarddL members and company officers. It is really good for Compaq and its customers% to become part of that hornet's nest?a  L While it is almost unheard-of to have a director take actions such as WalterF Hewlett has taken, equally it is almost unheard-of to have the largestL shareholder  of a company not represented on the board, especially when that' stake is as large as the Hewlett Trust.e   ------------------------------  % Date: Mon, 01 Apr 2002 10:21:57 -05004- From: JF Mezei <jfmezei.spamnot@videotron.ca>r4 Subject: Re: HP Won't Renominate W. Hewlett to Board, Message-ID: <3CA87B09.E4278316@videotron.ca>   John Smith wrote:0K > PALO ALTO, Calif. (Reuters) - Hewlett-Packard Co. HWP.N on Monday said iti< > would not reappoint dissident board member Walter Hewlett,  N While this is not a surprise, I would really hope that the Hewlett and PackardL families would find a way to force HP to swap names with Agilent so that theK original HP remains HP and Carly's folly will be called Agilent (or perhapsn" she can then use the Compaq name).   ------------------------------  % Date: Mon, 01 Apr 2002 08:07:21 -0800s' From: David Mathog <mathog@caltech.edu> 4 Subject: Re: HP Won't Renominate W. Hewlett to Board+ Message-ID: <3CA885B9.E4D9DAB6@caltech.edu>-   John Smith wrote:  > ) > HP Won't Renominate W. Hewlett to BoardF* > Last Updated: April 01, 2002 07:39 AM ET  J > In a statement, HP said the board's decision not to nominate Hewlett wasM > based on his adversarial relationship with the company, as evidenced by hislH > recent litigation against HP. It also cited concerns about his lack of > candor and issues of trust.t  P Well, they can't hardly say they're dumping him because he disagrees with Carly,J can they?  U.S. BOD elections are a joke most of the time anyway - the BODL picks the candidates and they run unopposed.  The only way alternative ideasK get onto a board is when somebody buys enough stock to force the company toeF give them one or more seats.  The thing is, Hewlett and the parties he
 represents5 are way past the point at which that normally occurs.c  N It will be interesting to see how the stockholders vote on the candidates thatP are listed on the ballot.  Normally BOD elections are a foregone conclusion - ifJ you're on the ballot, you're in.  This year might be different.  If I heldF that stock I'd vote no on all candidates (since its impossible to voteM for somebody else.) HP won't be putting on the full court press (150$M?) like  theyM did for the merger (which was half paid for, in essence, by the 50% who votedT@ against the merger) and retribution may be meted out by the PO'dL shareholders on the losing side of the merger debate.  For instance, whetherG or not the merger goes through Fiorina is up for election.  It's withinhE the realm of possiblity that she might be voted off of the BOD.  Even G some of the big players who voted for the merger may have enough doubtsI2 in her ablities to vote that way (ie, Merger good, Carly Bad). This voteeE will take place 4/26/02 which is close enough given the uncertainties A in the votes and the ongoing legal action that the merger may notr have closed by then.  6 Am I ever glad I don't work for HP or own their stock!  N > While it is almost unheard-of to have a director take actions such as WalterH > Hewlett has taken, equally it is almost unheard-of to have the largestN > shareholder  of a company not represented on the board, especially when that) > stake is as large as the Hewlett Trust.c  H Exactly.  Which sets up yet another opening for legal action against HP.   Regards,   David Mathog mathog@caltech.edu   ------------------------------  * Date: Mon, 1 Apr 2002 14:38:39 +0000 (UTC), From: "Richard Maher" <maher_rj@hotmail.c0m>= Subject: Re: INCONMMGST, Inconsistent memory management state / Message-ID: <a89rdd$lm2$1@helle.btinternet.com>    Hi Robert, Paule   Thanks for the replies..  E > Are you up-to-date on patches?  Fast I/O has been a bit of a movingi target.T  K I've got no idea what patches have been applied but I doubt _any_ have been L since the initial release of 7.3. (And probably won't be applied until 7.3-1 comes out unfortunately)  9 > If you have a support contract, then it's support time.e  G No luck here either I'm afraid. I was just fishing in case someone from I Compaq support was listening and felt like being a bit proactive about itiI given that I had a reproducer. As you implied they've probably fixed this> particular bug long ago.  K Thanks for all the sysgen tracing parameter info (You're right to think I'mgJ floundering around a bit when it comes to sysman stuff) but something PaulK Repacholi said got me thinking. (Paul replied personally but I think he wase aiming for the group).  B > Isn't IMG$IMGRESET part of image rundown? I'd guess that the  IOF > structures are ripped out from under the other process, and it finds6 > it has non-existant pages mapped... Oh dear... thud!  L I ran my example again and maybe the RMS error was output the first time andH I just didn't see it but either way the bugcheck was happening after theJ sys$io_setups. It was in fact a user mode application driven lib$stop thatC was causing all the trouble trying to report the failure to open my-E ONDISK_DB.VLM. (My FAB only had shr=<upi> and I was getting RMS$_FLK)y  J To cut a long story short, my EXEC mode rundown handler was TSTing the I/OL channel to my file and if it was zero then it was bypassing any clean-up. As; soon as I took the check out and closed file/deleted buffereJ objects/io_cleanup *every* time then the bugcheck went away. So in summaryL the default process/image rundown procedure that VMS provides for these Fast( I/O or VLM constructs is complete pants!  L Exactly which system service's house-keeping is causing the bugcheck is leftD as an exercise to the reader (or someone who likes watching a system reboot).  E Thanks again for the help. If you want to see the latest code I'll bet! posting it in the Rdb listserver.s   Regards Richard Maher.   ----- Original Message -----, From: Paul Repacholi <prep@prep.synonet.com>( To: Richard Maher <maher_rj@hotmail.com>$ Sent: Friday, March 29, 2002 6:56 PM= Subject: Re: INCONMMGST, Inconsistent memory management statee  0 > "Richard Maher" <maher_rj@hotmail.c0m> writes: >tK > > Reproduceable at will and happy to post/mail approx 1400 lines of code.. >h > > Failing Instruction:" > > MMG$IMGRESET_C+00248:   BUGCHK >'B > Isn't IMG$IMGRESET part of image rundown? I'd guess that the  IOF > structures are ripped out from under the other process, and it finds6 > it has non-existant pages mapped... Oh dear... thud! >i > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda. B >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.H > EPIC, The Architecture of the future, always has been, always will be. >s= Robert Deininger <rdeininger@mindspring.com> wrote in messageoE news:rdeininger-2803021948290001@1cust159.tnt2.nashua.nh.da.uu.net... A > In article <a7vke7$oe1$1@helle.btinternet.com>, "Richard Maher"l > <maher_rj@hotmail.c0m> wrote:} >, > >Hi, > >lD > >Has DEC launced a new phase in the NT affinity program or what??? > >[G > >Another Alpha 7.3 FAST I/O test and yet another blue screen of deathg crash= > >:-( > >2 >,E > Are you up-to-date on patches?  Fast I/O has been a bit of a movingl target.  >dD > >Can anyone shed any light on the following or is it support time? >[9 > If you have a support contract, then it's support time.L >lL > If you're impatient, start by making sure your dump file is big enough  --( > at least the autogen-recommended size. >cL > >The crash occurs when two users have the global section mapped and bufferI > >objects created and one of them has already called $io_setup. When theV( > >second user tries to call it *KABOOM* > > J > >Reproduceable at will and happy to post/mail approx 1400 lines of code. >rC > Can you reproduce it with parameter SYSTEM_CHECK enabled, or withh> > POOLCHECK if you can't stand to run with the extra weight of > SYSTEM_CHECK?  See) > SYSMAN HELP SYS_PARAM for more details.{ >=J > These parameters cause VMS to boot with special images that keep tracingF > information for key internal events.  Your system crashed because itK > detected an "impossible" internal state, and could not continue reliably. L > In most cases, the cause of the corruption happened some time in the past,E > and only the symptoms remain at the time of the crash.  The tracingeF > information _might_ reveal the actual corruption as it happens.  TheG > sooner the system crashes after the corruption occurs, the better the-K > chance that the significant event will still be in the traceback buffers.n >LJ > But this is hardly worth detailing in the newsgroup if you have support.H > The support folks will jump you through whatever diagnostic hoops they' > expect to be useful in this instance.i >rJ > I'm sure the support folks will appreciate the reproducer code.  I don't > see much point in posting it.t >4F > The crash summary below doesn't tell me very much.  The OS committed/ > suicide when it detected internal corruption.  >h* > This is way too complex for a newsgroup. >a >  >r! > >Crashdump Summary Information:y! > >------------------------------s- > >Crash Time:        28-MAR-2002 12:12:01.64cF > >Bugcheck Type:     INCONMMGST, Inconsistent memory management state+ > >Node:              xxxxx    (Standalone)h* > >CPU Type:          AlphaStation 255/300 > >VMS Version:       V7.3 > >Current Process:   _FTA15:y9 > >Current Image:     $1$DKA0:[MAHER_R]TEST_BUFFS.EXE;112n? > >Failing PC:        FFFFFFFF.80066E68    MMG$IMGRESET_C+00248n' > >Failing PS:        20000000.00000202 K > >Module:            SYSTEM_PRIMITIVES_MIN    (Link Date/Time: 17-MAR-2001s > >03:26:52.79)- > >Offset:            00040E68 > >y   ------------------------------  # Date: Thu, 28 Mar 2002 22:19:57 GMTm1 From: "Terry C. Shannon" <terryshannon@attbi.com>n Subject: Re: Itanium troublesa: Message-ID: <hGMo8.42743$44.16144271@typhoon.ne.ipsvc.net>  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messageT* news:a803d4$i7g$1@pegasus.csx.cam.ac.uk...C > In article <oBLo8.106314$7b.9574774@bin7.nnrp.aus1.giganews.com>,r+ > Bill Todd <billtodd@metrocast.net> wrote:  > >>I > >> The major detail that surfaced recently is that Intel's claim may be  thatJ > >> it's 70% faster on SPECint (with code recompiled for McKinley, rather thanH > >> running code compiler for Merced) *per clock* than Merced, in which case > >ittF > >> would be 2.1+ times as fast absolutely at 1 GHz (i.e., around 800 SPECint,J > >> though consensus expectations seem to be more in the 650 - 700 area). > >i+ > >Just to follow up on a couple of points:  > > H > >First, I haven't heard the qualification 'per clock' used again, so - well,s > >why don't we *know* yet?  >eF > My impression is that the "per clock" rumour was a misunderstanding,B > and that it is absolute.  If so, I should expect initial SpecInt > figures to be more like 600. >kG > We don't know, because even Intel realised they made a laughing stockpD > of themselves over the Itanic, and have gagged all their employeesB > on the subject of McKinley performances and dates.  And that theB > current McKinley chips are engineering samples being used withinA > Intel and OEMs only.  Software development workstations are dueaB > "real soon now", but as far as I know have not started shipping.  J HP is said to have had a few hundred McKinley workstations piled up in the3 hallways since January, but only HP knows for sure.b   >dB > A while back, I gave three criteria for McKinley maintaining itsD > plausibility, of which the first has been missed (performance dataG > at the Spring 2002 IDF).  The second is that development workstations D > are shipped to software vendors starting next week.  If Intel missD > that one, there is no chance that it will reach production systems > this summer. >tJ > >But, again, why don't we know by now?  Isn't this thing supposed to hit% > >volume ship in a couple of months?s >lF > 'Summer 2002' is the official date.  A good many OEMs were told thatF > meant June 2002, but I doubt there is a hope in hell of that, thoughA > as far as I know none of the OEMs have been told of a slippage.   J Well, "Summer" doesn't officially begin (in the Northern Hemisphere) until
 June 21...   > C > Given the way that the OEMs were shafted over the Itanic, and theiD > fact that development workstations are not yet available, my guessB > is that a 'production' date of even October will not mean volumeC > shipments.  The latter will not happen until the OEMs can deliverbB > systems, complete with software, and I cannot see that happening > before early 2003.   This bodes well for Marvel/EV7!n   ------------------------------   Date: 1 Apr 2002 17:58:35 GMTo( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Itanium troubles 0 Message-ID: <a8a74b$dc5$1@pegasus.csx.cam.ac.uk>  : In article <hGMo8.42743$44.16144271@typhoon.ne.ipsvc.net>,0 Terry C. Shannon <terryshannon@attbi.com> wrote: >eH >> We don't know, because even Intel realised they made a laughing stockE >> of themselves over the Itanic, and have gagged all their employeesqC >> on the subject of McKinley performances and dates.  And that the C >> current McKinley chips are engineering samples being used withineB >> Intel and OEMs only.  Software development workstations are dueC >> "real soon now", but as far as I know have not started shipping.y > K >HP is said to have had a few hundred McKinley workstations piled up in thes4 >hallways since January, but only HP knows for sure.  A Yeah, right :-)  I assume that you have heard that rumour applied-' to a good few systems in your time ....o  ? All the reports that I have heard indicate that the inner cabali? have had McKinley systems for a while, and that they are due to<% be let loose on ISVs round about now.   G >> 'Summer 2002' is the official date.  A good many OEMs were told thatVG >> meant June 2002, but I doubt there is a hope in hell of that, though=B >> as far as I know none of the OEMs have been told of a slippage. >hK >Well, "Summer" doesn't officially begin (in the Northern Hemisphere) until  >June 21...   D Heck, we are well into autumn by September 21st here.  It's all veryC well for you people from the deep south, but summer in the northerniA hemisphere always used to be June, July and August!  I don't know-> where this new-fangled 3 week delay comes from, but it doesn'tA correspond with the weather this far north - think LIGHT (or lackt of it)!s  D >> Given the way that the OEMs were shafted over the Itanic, and theE >> fact that development workstations are not yet available, my guesstC >> is that a 'production' date of even October will not mean volume-D >> shipments.  The latter will not happen until the OEMs can deliverC >> systems, complete with software, and I cannot see that happeninge >> before early 2003.- >   >This bodes well for Marvel/EV7!  C Well, it at least gives it a window.  Given other information, I ama" not sure what will happen with it.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679o   ------------------------------   Date: 1 Apr 2002 09:04:48 -0800n From: pranath@yahoo.com (Suhas)r Subject: Migration Toola< Message-ID: <f3ee3199.0204010904.49cce5d@posting.google.com>  K Is there a tool which can help in migration from TRU64unix to HP-UX. If yesRC please provide me links to sites which can give me more information    ------------------------------   Date: 1 Apr 2002 12:52:35 GMT ) From: leslie@clio.rice.edu (Jerry Leslie)o: Subject: OT: Microsoft Uses FreeBSD To Host Anti-Unix Site' Message-ID: <a89l6j$374$3@joe.rice.edu>n% Keywords: microsoft,hypocrisy,freebsd   *    http://www.theinquirer.net/01040207.htm0    Microsoft uses FreeBSD to host anti-Unix site  I   "THE GREAT SATAN OF software appears to have been rumbled in an attemptrG    to persuade corporate America to move from Unix to its own family ofa    operating systems.n    pH    A report on NetSlaves claims that a joint Microsoft Unisys Web site -6    wehavethewayout.com, is hosted on a FreeBSD system.    oF    That has led to Microsoft being charged with hypocrisy - surely not,    the first time it's been accused of this.    hH    Microsoft in the UK used to run its entire operation on Xenix systemsA    at the same time that Bill Gates used to trundle round telling-1    corporate resellers that Windows was wondrous.m    MD    In any case, the lads and lasses at NetSlaves are not taking this    lying down.     A    A post labelled "Microsoft: you scumbuckets", starts here.  "     O, Here's the article from www.netslaves.com...  7    NetSlaves  -- Microsoft - You scumbuckets!, (Page 1)o)    http://www.netslaves.com/cgi-bin/yabb/ 2    YaBB.pl?board=005&action=display&num=1017573497      Microsoft - You scumbuckets!   2    Posted by emesdoosuk | March 31st, 2002, 6:18am    NetSlaves Bona Fide  F    In case you didn't know, Microsoft is running new adverts about how4    unix is useless and that they have "the way out".  H    You can read about it here: http://news.com.com/2100-1001-870805.html    Now for the best part!!  F    Microsoft has a website for you to go and look at. Go now and look."    http://www.wehavethewayout.com/  H    Now go to netcraft,com and check to see what OS is being used for the    website.a?    http://uptime.netcraft.com/up/graph/?mode_u=off&mode_w=on&amw3    p;site=www.wehavethewayout.com%2F&submit=Examinec    yD    "In the end everybody dies ... but some people have never lived."    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------   Date: 1 Apr 2002 07:10:34 -0600e- From: Kilgallen@SpamCop.net (Larry Kilgallen)r! Subject: Re: Piping and recallingt3 Message-ID: <1MLB0uTDpRQz@eisner.encompasserve.org>   s In article <a86p6q$i6r$1@charm.magnus.acs.ohio-state.edu>, DAVISM@er6.eng.ohio-state.edu (Michael T. Davis) writes:  > M >         We're running OVMS 7.2-1 on an AlphaServer 800.  I'm playing aroundaI > with pipes and the RECALL command and running into a few problems.  LeteH > me start simple.  Is there some reason why you can't invoke the RECALL > command via LIB$DO_COMMAND?   @ Presumably this is the same reasoning for not having RECALL work> from Batch.  RECALL is intended for command lines entered from? the terminal.  If my memory serves me right, the implementationP> is even tightly integrated with a single-line recall mechanism built into the terminal driver.f  8 HELP RECALL seems to provide a clear statement of scope.   ------------------------------  # Date: Fri, 29 Mar 2002 23:39:37 GMTo1 From: "Terry C. Shannon" <terryshannon@attbi.com>h2 Subject: Re: Predictions - just for the hell of it: Message-ID: <ZW6p8.43657$44.17017114@typhoon.ne.ipsvc.net>  H ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU>C wrote in message news:00A0B5B7.0C9BBCA6@SSRL04.SLAC.STANFORD.EDU...(> > In article <87lmcjdgkx.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes: / > >"Bill Todd" <billtodd@metrocast.net> writes:l > >oD > >> Compaq's Q1 results will be unimpressive in revenue, profit, orE > >> both.  Funny how in the Q4 Financial Discussion they pointed out F > >> that there were "signs of returning corporate customer purchases"F > >> that accounted for the 14% up-swing from the disasterous Q3 - butH > >> still projected that revenue would *decrease* 10% in 2002Q1 back to8 > >> near-Q3 levels: nah, no fudging of numbers there... > >eH > >Part of the Q4 results could well have been folks who needed replacedH > >kit, and wanted it *NOW*, to hell with the cost. Getting a hundred orH > >so 7K vaxes at short order should provide a small profit for some one > >for instance. >nL > Judging by the plaintive emails I got from Computer Clearing House begging for J > used VAX 7000 kit, I'm guessing that someone (who got the profit) wasn't	 > Compaq.t  
 No doubt! ;-}i  L Historically CPQ's 1FQ and 3FQ are less stellar than 2FQ and 4FQ. Of course,L the little matter of a Silicon Valley Soap Opera didn't help the company one
 bit in 1FQ02!t   ------------------------------  $ Date: Mon, 1 Apr 2002 11:47:29 -0600$ From: Briony.Schreiber@metavante.com0 Subject: Seek information on FAXSR and VMS 7.3-1@ Message-ID: <OF446AAE8F.EEF7F462-ON86256B8E.00614D07@midata.com>  + This is a multipart message in MIME format.u" --=_alternative 0061BB5F86256B8E_=, Content-Type: text/plain; charset="us-ascii"  8 Does anyone know if FAXSR 4.1-027 will run on VMS 7.3-1?  F We are currntly running FAXSR 4.1-027 on Alpha VMS 7.1-2.  We will be K upgrading to VMS 7.3-1.  OMTOOL no longer supports their FAXSR product for IC VMS, and will not answer any questions on it for the VMS platform. f  G If you have tried to use this product on VMS 7.3-1, please let me know.d    
 Thank you,   Briony Schreiber Briony.Schreiber@metavante.com  " --=_alternative 0061BB5F86256B8E_=+ Content-Type: text/html; charset="us-ascii"     b <br><font size=2 face="sans-serif">Does anyone know if FAXSR 4.1-027 will run on VMS 7.3-1?</font> <br><br><font size=2 face="sans-serif">We are currntly running FAXSR 4.1-027 on Alpha VMS 7.1-2. &nbsp;We will be upgrading to VMS 7.3-1. &nbsp;OMTOOL no longer supports their FAXSR product for VMS, and will not answer any questions on it for the VMS platform. &nbsp; </font>e <br>q <br><font size=2 face="sans-serif">If you have tried to use this product on VMS 7.3-1, please let me know.</font>e <br>' <br><font size=2 face="sans-serif"><br>r Thank you,<br> <br> Briony Schreiber<br>" Briony.Schreiber@metavante.com<br> </font>c$ --=_alternative 0061BB5F86256B8E_=--   ------------------------------  % Date: Mon, 01 Apr 2002 15:29:28 -0000s- From: wspencer@ap.nospam.org (Warren Spencer) A Subject: Re: Sending Wake-up Message from NT to OpenVMS batch jobm7 Message-ID: <91E361935warrenspencer1977@209.249.90.100>e  ) cask1@yahoo.com (Kelly Donahue) wrote in  2 <f4f1188e.0203281058.117e50ff@posting.google.com>:   >Hi,E >  What's the easiest/best way to pass a wake-up message from NT to arG >program running in batch under OpenVMS?  We'd like the OpenVMS programjD >to hibernate until it receives a message then wake up, do its work,B >then go back to sleep.  The message can be as little as one byte. > 7 >  We're running OpenVMS V7.1 and UCX 4.1 update ECO 6.  >a >Thanks in advance.   K On the off chance you're looking for a minimalist solution, you could have nL the OpenVMS batch job do a TCP listen()/accept()/read() on a selected port, 0 and have the NT program open() and send() to it.   ws   -- a   Warren Spencer' Senior Software Engineer (not a writer)  The Associated Press  < ** Time flies like an arrow.  Fruit flies like a bananna. **   ------------------------------  % Date: Mon, 01 Apr 2002 12:35:28 +0200C2 From: martin@radiogaga.harz.de (Martin Vorlaender)= Subject: Re: Spring Forward, Fall Back - unfortunately not :- ; Message-ID: <3ca837f0.524144494f47414741@radiogaga.harz.de>s  * Bart Zorn (B.Zorn@xs4all.nospam.nl) wrote:G > AFAIK, when you have DTSS running, it takes control of the clock. NTPe! > can't change the time any more.r  G That is not strictly true. While the NTP TCP/IP service won't work with C DTSS in effect (or any other software that tries to use the $SETIME/G system service), one could write a time provider for DTSS that utilizes C NTP. AFAIK, this has been done - I just can't remember the details.    cu,    Martin -- yD                     | Martin Vorlaender    |    VMS & WNT programmer-   Smiert Spamionem  | work: mv@pdv-systeme.deiD                     |       http://www.pdv-systeme.de/users/martinv/4                     | home: martin@radiogaga.harz.de   ------------------------------  % Date: Mon, 01 Apr 2002 15:49:46 +0200  From: Dirk Munk <munk@home.nl>= Subject: Re: Spring Forward, Fall Back - unfortunately not :-n$ Message-ID: <3CA8657A.60400@home.nl>  H Yes, that was my impression too. That way we can combine the advantages E of DTSS with the use of a NTP timeserver. Maybe Hoff can tell us how t this is done ?   Martin Vorlaender wrote:  + >Bart Zorn (B.Zorn@xs4all.nospam.nl) wrote:  >MG >>AFAIK, when you have DTSS running, it takes control of the clock. NTP ! >>can't change the time any more.t >> > H >That is not strictly true. While the NTP TCP/IP service won't work withD >DTSS in effect (or any other software that tries to use the $SETIMEH >system service), one could write a time provider for DTSS that utilizesD >NTP. AFAIK, this has been done - I just can't remember the details. >r >cu,	 >  Martint >    ------------------------------  # Date: Mon, 01 Apr 2002 15:08:38 GMTs8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)= Subject: Re: Spring Forward, Fall Back - unfortunately not :-a3 Message-ID: <WJ_p8.1708$fL6.34024@news.cpqcorp.net>g  * In article <3CA6F351.D6EC4FA@bluewin.ch>, * Paul Sture <paul.sture@bluewin.ch> writes: ..O >> You can check if the SYSGEN parameter AUTO_DLIGHT_SAV is correctly set to 1.s >o9 >Ah, yes, it was at the default of OFF. It is a pity thateI >SYS$MANAGER:UTC$TIME_SETUP.COM does not contain the hint to look at this : >parameter. The subject of an enhancement request I think.  2 (1) This is documented in the new features manual.  E (2) For compatibility, I tried to change as little as possible in the-? existing functionality of UTC$TIME_SETUP.  However, please try:1  (     @SYS$MANAGER:UTC$TIME_SETUP.COM SHOW  G This is also documented -- I think in the V7.3 System Manager's Manual.eJ (I'm not completely certain exactly where, but I KNOW we did document it!)   NB -- H There is a bug in the V7.3 version of SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM.2 Please get the patch before you [try to] use this.   -- EK     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USA H        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  # Date: Sat, 30 Mar 2002 16:20:02 GMTn1 From: "Terry C. Shannon" <terryshannon@attbi.com>gN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64: Message-ID: <SAlp8.44336$44.17564538@typhoon.ne.ipsvc.net>  . "John Smith" <a@nonymous.com> wrote in message@ news:MNjp8.4158$dVT.1308@news01.bloor.is.net.cable.rogers.com...
 > Hey Rob, > L > Just because there's a 'boot date' contest, doesn't mean that VMS is going
 > to survive.i > F > If the HP deal goes through, you have to remember who is advising HP senior9 > management about Compaq's products - Compaq management.w >hJ > Given past managerial decisions by Compaq, which were really more in theK > mis-management vein, it's not beyond the plausible that VMS will have itshH > throat slit in the next 6 weeks. It wouldn't surprise me in the least.  J A long, long time ago, US Department of Health, Education, and Welfare JoeJ Califano called cigarette smoking "slow-motion suicide." Killing VMS would* be a far more rapid means to the same end.  $ What happens to DII-COE commitments?  ; What happens to the $2B or so in revenue that VMS drags in?d   ------------------------------  # Date: Sat, 30 Mar 2002 18:08:25 GMTt1 From: "Terry C. Shannon" <terryshannon@attbi.com>rN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64: Message-ID: <tanp8.44355$44.17628726@typhoon.ne.ipsvc.net>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagerD news:rdeininger-3003021214380001@1cust78.tnt2.nashua.nh.da.uu.net...7 > In article <3CA5D20D.EA97DC37@videotron.ca>, JF Mezeik' > <jfmezei.spamnot@videotron.ca> wrote:J >aG > >I would not be surprised if the EV7 machines are on hold pending thee releasec > >of the product roadmap. >i5 > You might not be surprised, but you would be wrong.   G C'est vrai! If Marvel systems were on hold, CPQ wouldn't be showing thenI boxes off at ENSA and the DECUS/ITUG Joint Conference. Unless the product E roadmap calls for the immediate retirement of Tru64 UNIX and OpenVMS,h they've gotta do Marvel.   ------------------------------  % Date: Mon, 01 Apr 2002 10:47:44 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>2N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64, Message-ID: <3CA88112.F314303E@videotron.ca>   "Terry C. Shannon" wrote:f& > What happens to DII-COE commitments?  I As long as HP continues to provide support for those who have signed suchlK contracts, does stopping development and sales of VMS break that contract ?cI From what marcello said during a customer presentation, it wouldn't. (eg:gW DII-CEO is a contract to ensure yoru current infrastructure continues to be supported).h  = > What happens to the $2B or so in revenue that VMS drags in?c  L Ahh, but this is where  ATNG comes into play. They will convert customers to HP products that will survive.  ' (ATNG = Affinity, The Next Generation).    ------------------------------  # Date: Mon, 01 Apr 2002 16:22:58 GMTc# From: "John Smith" <a@nonymous.com> N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64H Message-ID: <CP%p8.21671$dVT.18447@news01.bloor.is.net.cable.rogers.com>  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message4 news:SAlp8.44336$44.17564538@typhoon.ne.ipsvc.net... >eL > A long, long time ago, US Department of Health, Education, and Welfare JoeL > Califano called cigarette smoking "slow-motion suicide." Killing VMS would, > be a far more rapid means to the same end. >m& > What happens to DII-COE commitments? >"= > What happens to the $2B or so in revenue that VMS drags in?s >    Terry,  L Hate to say this, but your arguments assume rational behavior on the part of# Compaq management. Need I say more?   H No, it would not be rational for Compaq/HP to kill VMS, but that's neverI stopped Compaq/Digital and even HP from doing some bonehead thing. NoticeaG that there has never been any comments from HP during the course of theaI leadup to the merger vote on VMS by HP, but there has been on EVERY otherh platform that Compaq offers.  L Don't you think that having Carly (not that she has much credibility either)J offer some soothing words about the fate of VMS would have gone a long wayK in dispelling any doubts about the future of VMS? Instead we get resoundinge silence on the matter.  H Given the number of Compaq-types that lurk/contribute in this ng in someH official/semi-official/non-official capacity, do you think it's possibleI that word of customer concerns regarding the fate of VMS have not reachedwD senior management at Compaq? How much credibility does senior CompaqL management have in this ng, which is arguably visited/used by many customers; that Compaq would consider to be major/strategic customers?h   Figure it out:E - Compaq management has little to no credibility with many customers;aH - no offense to the VMS engineering staff, but they just do what they'reJ told - they don't set policy, so their comments in the ng on the future ofE VMS, while well intentioned, are not official (yes, we're supposed to G believe Compaq senior management, but we don't - with good reason too - I remember the old adage... "Lie to me once, shame on you. Lie to me twice,M shame on me.");iH - HP will be wearing the pants in the merged company (if it happens) andL they have offered 'No Comment' on the future of VMS - a seemingly 'We cannotH confirm nor deny that VMS has any future', yet they see fit to pronounceG life or death on other Compaq products prior to the consummation.of theoH merger, so it isn't the SEC 'quiet period' that's keeping pronouncements about VMS from surfacing.     H As to DII-COE - it's just a piece of paper, and would be subject to someK negotiation to make it go away. All they'd really have to do is say, 'We'll @ port the code for you at no charge". They'll have a big servicesG organization that's partially sitting on its thumbs through the currentD; corporate spending slowdown to put to work. Problem solved.,  L As to the $X billion in VMS revenue with $Y million profit...it would be farJ easier to exit the consumer PC market and cut the hemorrhaging at that end4 of the business, but they have not done that either.  I It takes time for customers to move from VMS to unix (whether it's HP/UX, I AIX, Solaris, Linux), so they'll still have maintenance revenue, but they L won't have to invest in major new development efforts. They can put VMS into6 maintenance mode and cut the engineering staff by 2/3.  K Killing VMS is one of those things that doesn't make sense, but I bet it'llo happen anyway.   ------------------------------  % Date: Mon, 01 Apr 2002 12:06:54 -0500n- From: JF Mezei <jfmezei.spamnot@videotron.ca> N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64, Message-ID: <3CA8939D.CDFE4ECA@videotron.ca>   John Smith wrote:sM > Killing VMS is one of those things that doesn't make sense, but I bet it'lls > happen anyway.  G It makes sense if one is out to consolidate product lines and eliminatea5 product overlaps. VMS overlaps both tandem and unix. p  H It makes sense if one is told that it would be possible to retain a good< portion of the VMS customers by proceeding in a certain way.  N Carly has made a lot of promises. The minute she realises that the integrationN isn't going smoothly, she will start to play musical chairs, layoff additionalM staff and cut additional products to rationalise the company and focus on itst core incompetancies.   ------------------------------   Date: 1 Apr 2002 09:46:57 -0800o( From: bob@instantwhip.com (Bob Ceculski)N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64= Message-ID: <d7791aa1.0204010946.4a28d467@posting.google.com>y  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3CA88112.F314303E@videotron.ca>..." > "Terry C. Shannon" wrote:o( > > What happens to DII-COE commitments? > K > As long as HP continues to provide support for those who have signed such.M > contracts, does stopping development and sales of VMS break that contract ?TK > From what marcello said during a customer presentation, it wouldn't. (eg:.Y > DII-CEO is a contract to ensure yoru current infrastructure continues to be supported).e > ? > > What happens to the $2B or so in revenue that VMS drags in?  > N > Ahh, but this is where  ATNG comes into play. They will convert customers to  > HP products that will survive. > ) > (ATNG = Affinity, The Next Generation).$  F the only customers that would migrate from vms to any other hp product would be fools and idiots!   ------------------------------  # Date: Mon, 01 Apr 2002 17:47:24 GMTe# From: "John Smith" <a@nonymous.com>sN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64H Message-ID: <M21q8.27801$09u.27759@news02.bloor.is.net.cable.rogers.com>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CA8939D.CDFE4ECA@videotron.ca... >rI > It makes sense if one is out to consolidate product lines and eliminatee6 > product overlaps. VMS overlaps both tandem and unix. > J > It makes sense if one is told that it would be possible to retain a good> > portion of the VMS customers by proceeding in a certain way. > D > Carly has made a lot of promises. The minute she realises that the integrationcE > isn't going smoothly, she will start to play musical chairs, layoff 
 additionalK > staff and cut additional products to rationalise the company and focus on  itse > core incompetancies.  J The one other thing that will kill VMS if Compaq/HP doesn't do it first isI that now there is are only two commercially viable RDBMS that are sold to G run on VMS, Rdb and Oracle, both sold by Oracle Corp. Sybase has killed1J their ASE product on VMS. DB2 doesn't run on VMS. Informix doesn't. IngresH doesn't. Not that every use of VMS is RDBMS dependent, but a huge number are.  D So now a huge part of the VMS lifeboat is controlled by a 3rd party.H Without Alpha, Oracle doesn't post such great performance numbers. IA-64J etc...just makes Compaq/HP OpenVMS on IA-64 just another average performer9 that doesn't appreciably add to sales of Oracle products.hL Once Oracle figures out that there's no money to be made on VMS, they'll EOL) the products and that'll be that for VMS.hF No new sales of db servers to new customers = no reason to continue to develop for VMS. No Oracle or Rdb = no VMS.  J You'd be smoking and inhaling if you thought that Sybase, IBM, or CA would@ create a VMS port if VMS ever went production on IA-64/McKinley.  K Betcha Larry makes all concerned - Compaq, HP, and VMS customers, bend overt= and spread 'em even more, to take advantage of the situation.e   ------------------------------  % Date: Mon, 01 Apr 2002 13:04:21 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>MN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64, Message-ID: <3CA8A110.E0E31C43@videotron.ca>   Bob Ceculski wrote:oH > the only customers that would migrate from vms to any other hp product > would be fools and idiots!  L What about all those customers who had already begun to de-emphasize VMS andJ go HP ? They would by now have a large HP investment with a few legacy VMSK boxes still running. Where do you think there would go if VMS were killed ?sM When they decided to de-emphasize VMS from their shop back in the 1990s, they>C had already written off VMS as something that would die eventually.1  N And if HP does pull the plug, those customers will remember that it was Palmer6 that screwed them, and they may not resent HP so much.   ------------------------------  # Date: Mon, 01 Apr 2002 18:00:29 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-648 Message-ID: <00A0BCEC.8470A935@SSRL04.SLAC.STANFORD.EDU>  n In article <M21q8.27801$09u.27759@news02.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes: > ; >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in messageg' >news:3CA8939D.CDFE4ECA@videotron.ca...W >>J >> It makes sense if one is out to consolidate product lines and eliminate7 >> product overlaps. VMS overlaps both tandem and unix.  >>K >> It makes sense if one is told that it would be possible to retain a good ? >> portion of the VMS customers by proceeding in a certain way.o >>E >> Carly has made a lot of promises. The minute she realises that thei >integrationF >> isn't going smoothly, she will start to play musical chairs, layoff >additionaleL >> staff and cut additional products to rationalise the company and focus on >its >> core incompetancies.a >nK >The one other thing that will kill VMS if Compaq/HP doesn't do it first is J >that now there is are only two commercially viable RDBMS that are sold toH >run on VMS, Rdb and Oracle, both sold by Oracle Corp. Sybase has killedK >their ASE product on VMS. DB2 doesn't run on VMS. Informix doesn't. IngreseI >doesn't. Not that every use of VMS is RDBMS dependent, but a huge number- >are.-  O Cache does, and is apparently big in health care markets.  Mimer does (and willhD be ported to IA64).  I haven't used either one - we're an Rdb site..   -- Alany  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056mM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210oO ===============================================================================y   ------------------------------   Date: 1 Apr 2002 18:09:14 GMTe) From: leslie@clio.rice.edu (Jerry Leslie) N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64' Message-ID: <a8a7oa$l6i$1@joe.rice.edu>r  " John Smith (a@nonymous.com) wrote:D : Betcha Larry makes all concerned - Compaq, HP, and VMS customers, I : bend over and spread 'em even more, to take advantage of the situation.- :-  # Gee, what makes you think that ?...   4    http://www.theregister.co.uk/content/4/24643.htmlH    Gartner warns of 'inappropriate' Oracle sales tactics By ComputerWire  "    Posted: 29/03/2002 at 09:18 GMT  D   "ComputerWire: IT Industry Intelligence A second research firm hasI    warned Oracle Corp customers to check license fees and further accusede.    the company of inappropriate sales tactics.  I    Gartner Inc has accused Oracle of forcing customers to choose the mostaH    expensive licensing option, attempting to pre-sell more licenses thanI    customers need and forcing customers to pay more than is necessary for >    data sourced into a data warehouse from an Oracle database.H    The criticism comes just days after another research firm, Meta GroupG    Inc, accused Oracle of overcharging some users for batch-feeding its.!    database management system..."-    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------   Date: 1 Apr 2002 12:46:19 -0600j+ From: young_r@encompasserve.org (Rob Young)aN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-643 Message-ID: <3EGIGrzIH3go@eisner.encompasserve.org>u  \ In article <3CA8939D.CDFE4ECA@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > John Smith wrote:,N >> Killing VMS is one of those things that doesn't make sense, but I bet it'll >> happen anyway.n > I > It makes sense if one is out to consolidate product lines and eliminates7 > product overlaps. VMS overlaps both tandem and unix. m > J > It makes sense if one is told that it would be possible to retain a good> > portion of the VMS customers by proceeding in a certain way. > P > Carly has made a lot of promises. The minute she realises that the integrationP > isn't going smoothly, she will start to play musical chairs, layoff additionalO > staff and cut additional products to rationalise the company and focus on itsY > core incompetancies.    : 	It doesn't make sense no matter how you slice it.  Again:  Z http://groups.google.com/groups?selm=qlrYXXqIesv3%40eisner.encompasserve.org&output=gplain  6 	Can I have another go at this from a different angle?  9 	Stealing a line .... reminds me of a Clinton saying fromr= 	recent history:  "For the chilrun"  Meaning, let's set asideaA 	reason and hold to a cause.  Never mind business sense, "we loven@ 	our customers so much we want to do what is absolutely best forC 	them."  BARF!  That doesn't work from a couple angles and I'm sureo= 	the MPE folks have some opinion... how about a few wrinkles:a  = 		1)  If they didn't want to be on MPE , they would have left. 			it long ago.   ; 		2)  It will affect your balance sheet one way or another,a/ 			to say you are ignoring the balance sheet ise. 			disingenuous at best.  You are in business.  @ 		3)  What about customers spending large sums of money to come : 			off major MPE custom applications that have worked well2 			for a couple decades.  OH... I GET it!  As long$ 			as it isn't *your* balance sheet!  ; 		4)  The hope is to save as many as they can and keep themt4 			as HP customers.  The real downer is a percentage' 			will go away mad , like this fellow:l    ) http://news.com.com/2100-1001-275878.htmlo  M "In my agency within the U.S. Department of Defense, we make extensive use of L HP 3000 systems," said Tim O'Neill, of the U.S. Army's Aberdeen Test Center.N "One certainty for our agency is that if they eliminate the 3000, we will then% act to eliminate our 9000s as well.  n  O "If HP thinks we will 'migrate' from MPE to HP-UX, they are mistaken," he said, I referring to the operating systems associated with the two server lines. .  A 	Sour grapes on his part?  Maybe he isn't relishing all the extra 7 	work ($$$) involved to come off MPE.  See 3) above.   a   ===.  A 	The VMS user base is 10 times the size of MPE.  HP/Compaq surelyk9 	wouldn't want to generate 10 times as many Tim O'Neills.n   				Robi   ------------------------------  % Date: Mon, 01 Apr 2002 12:36:36 -0500c- From: JF Mezei <jfmezei.spamnot@videotron.ca>u Subject: VAXORCIST 5.0, Message-ID: <3CA89A90.E51F3E84@videotron.ca>   (a blast from the past)n%                         THE VAXORCISTJ%                         -------------o  2              A rough draft of a video presentation+                      by Christopher Russell-9        Operations Manager, Dept of Mechanical Engineering7+                      University of Marylandi  I -------------------------------------------------------------------------   E (SCENE: Inside of a VAX computer room.  CREDITS ROLL as the SYSMGR is H sitting in front of the console terminal, typing.  He pauses, picks up aJ small magnetic tape, walks over to a tape drive, mounts it, and returns to' the console where he continues typing.)r  F (There is a knock at the door.  SYSMGR walks to the door and opens it, revealing USER.)  + USER:  Any idea when the system will be up?e  G SYSMGR:  Well, I just installed version 5.0 of VMS, so I'm going to run I some diagnostics on it overnight to make sure it works alright.  AssumingiE everything goes alright, the system should be up first thing tomorrow. morning.   USER:  Great.  Thanks.  (Exits)   4 (SYSMGR closes the door and returns to the console.)  J ROD SERLING-LIKE VOICE:  This is John Smith, University of Maryland SystemI Manager.  In an effort to make his system the best it can be, he has just8I installed VMS Version 5.0 onto his VAX.  But little does he know that the"I Version 5 documentation kit from Digital includes a one-way ticket to ...p the VMS TWILIGHT ZONE!   (ominous music - fade out)  J (Fade in.  The SYSMGR scans the console for a moment, then turns, picks upK his coat and walks to the door.  He stops at the door for a moment, looking D back at the big machine.  Finally, he turns out the light and exits, closing the door behind him.)r  H (Cut to the Console Terminal.  We read the following as it is printed on the console terminal:)   VMS V5.0 DIAGNOSTICS --q  ! DIAGNOSTICS - PHASE 1 STARTING...   , DIAGNOSTICS - PHASE 1 FINISHED SUCCESSFULLY.  ! DIAGNOSTICS - PHASE 2 STARTING...D    TESTING MICROCODE ... SUCCESSFUL   TESTING DECNET ...  SUCCESSFUL  1 TESTING LICENSE MANAGEMENT UTILITY ... SUCCESSFULe  & TESTING SYSTEM SERVICES ... SUCCESSFUL  F TESTING HIGHLY EXPERIMENTAL AND COMPLETELY UNDOCUMENTED AI ROUTINE ...  I (Cut to view of the Tape in the Tape drive.  The tape spins for a moment,) and suddenly stops.)  F (Cut to view of the Machine Room.  A fog has begun drifting across theG floor, and the hardware is slowly being backlit by a pulsing red light.eH A peal of weird laughter cuts through the silence.  A variety of bizarreD things occur:  A VT100 monitor sitting on a table slowly rotates 360F degrees; the tape drive opens and tape begins spewing out of it; slimeH begins pouring out of a disk drive; the line printer begins form-feedingG like mad.  These continue for several minutes, or for as long as we cand keep them up.  FADE OUT)  J (SCENE: Hallway outside of the computer room.  SYSMGR walks up to the door and is met by USER.)  " USER:  System going to be up soon?  G SYSMGR:  (as he speaks, he tries to open the Machine room door, but theeG door is apparently stuck.) The diagnostics should be done by now, so wetI should be up in about 15 minutes... (he succeeds in opening the door, buttF is confronted by floor to ceiling magnetic tape.  Tangled at about eyeJ level is an empty tape reel. SYSMGR takes the reel and looks at it.  CLOSEB UP of the reel so we can read the label, which reads: VAX/VMS V5.09 DIAGNOSTIC KIT.) (to USER) ...give or take a few days....'  J (SCENE:  View of TSR (Telephone Support Rep) from behind as she is sittingF in a cubicle, a terminal in front of her.  Beside her on the wall is aH poster which reads "Digital Has It Now - But You Can't Have It".  We canJ see the terminal, but we should not be able to read what is on it.  She is wearing a headset.)s  E TSR:  Colorado Customer Support.  What is your access number, please?    SYSMGR VOICE: 31576r   TSR:  And your name?   SYSMGR VOICE:  John Smith.  J (Cut to SYSMGR standing beside his console.  He his holding a phone to hisH head with his right hand, and holding a printout in his left which he is& perusing while he talks on the phone.)  4 TSR VOICE:  And what operating system are you using?   SYSMGR:  VMS version 5.t  H TSR VOICE:  And is this a problem with the operating system or a layered product?  F (As the SYSMGR looks up from the printout, his eyes suddenly widen andF he drops the printout and ducks.  At that second, a disk platter fliesF through the air where his head just was.  Slowly, SYSMGR stands up andI looks to where the disk went.  PAN BACK to reveal a stack of boxes with ag- disk embedded in one of them at neck height.)   M SYSMGR:  (into the phone) Operating System.  Definitely the Operating System.-  & (Cut back to TSR sitting at her desk.)  + TSR:  Can you describe the problem, please?.  0 (SYSMGR voice can now only be heard as mumbling)  J TSR:  Yes... Tape drive spewing tape into the air... yes...  Line printersF printing backwards... yes... miscellaneous hardware flying through theK air... uh huh...  disk drives melting... yeah... strange voices coming fromsK the CPU board... I see... yes.  Is that all?  (pause as she finishes typingrH at the terminal)  Well, I'm afraid that that team is busy at the moment,  can I have them get back to you?  E (CUT TO SCENE: MANAGER sitting behind a large desk in a plush office. < DEVELOPER is pacing in front of him, hands behind his back.)  # (SUBTITLE: Meanwhile at Maynard...)y  / MANAGER:  So tell me!  What the hell happened?!i  J DEVELOPER:  (turning to face MANAGER)  It's a glitch, a fluke.  A one in a? billion chance.  And it's not Development's fault.  Not really.   ! MANAGER:  Then who's fault is it?r  F DEVELOPER:  We traced it back to the Software Distribution Center.  ItI seems that there was a mixup and some of the code for the experimental AI9J routine was copied onto the distribution from the wrong optical disk.  (He7 removes a CD from his jacket)  This one, to be precise."   MANAGER:  And what's that?  A DEVELOPER:  (reading the label)  "Ozzy Osbourne's Greatest Hits".nG Normally, it wouldn't have made any difference, as the AI routine isn't J used yet.  But when they began running diagnostics, it hit the routine and3 the computer just sort of became a thing possessed.'  < MANAGER:  Wonderful.  Were any other distributions affected?  2 DEVELOPER:  No, just the University of Maryland's.  E MANAGER:  Well, that's a relief.  We've got to get them taken care of F before anyone finds out.  Can you imagine what Digital Review would do if they heard about this?   A DEVELOPER:  We could always blame it on the Chaos Computer Group.a  J MANAGER:  No, we've already used that one.  This calls for drastic action.D (MANAGER picks up the phone and begins flipping through the rolodex)  & DEVELOPER:  Who are you going to send?  I (CUT to the Rolodex so that we can read the cards.  The first card reads:4  -         SYSTEM PROBLEMS - Ron Jankowski, x474.   he flips to the next card:  0         BAD SYSTEM PROBLEMS - Bob Candless, x937   he flips to the next card:  :         REALLY BAD SYSTEM PROBLEMS - Michelle French, x365   he flips to the next cardt  :         OUTRAGEOUSLY BAD SYSTEM PROBLEMS - Mike West, x887  < he flips to the next card and taps the card with forefinger:  E         SYSTEM %%%%ED UP BEYOND ALL RECOGNITION - The VAXorcist, x666a    @ (CUT to Machine Room.  SYSMGR is standing by the console holdingJ an RA60 disk cover and using it as a shield to defend himself from variousE pieces of hardware which are flying at him from off-camera.  There istH a knock at the door.  Slowly, SYSMGR makes his way to the door and opensD it.  Standing there, backlit amidst outrageous amounts of fog is theG VAXORCIST, wearing a trench coat and fedora, and carrying a briefcase.)   H VAXORCIST:  (in a hushed voice)  DEC sent me.  I hear you're having some	 problems.r  F (CUT to SYSMGR OFFICE, a small but pleasant office with posters on theG walls and clutter on the desk.  As the VAXORCIST enters, he removes hisoJ coat and hat, revealing a very techie outfit beneath.  He is wearing a DEC badge.)a  I SYSMGR:  (Frantic)  Problems?  Problems?!?  You could say I'm having someaJ problems.  4.6 was fine.  4.7 was fine.  I install 5.0 and all Hell breaks< loose.  The damn thing ate two of my operators this morning!  C VAXORCIST:  Calm down, everything will be alright.  I've dealt witht situations like this before.   SYSMGR:  You have?  E VAXORCIST:  Four years ago at an installation in Oregon, a programmer F renamed his Star Trek program to VMB.EXE and copied it into the systemE directory.  When the system was rebooted the next day it phasored thenJ entire accounting department claiming that they were Klingon spies.  ThereJ was a similar problem in Texas three years ago, and then, of course, thereJ was the IRS fiasco that we're not allowed to talk about.  But don't worry.H These things can be fixed.  Before I can help you, though, I have to askE you a few questions. (The VAXorcist opens his briefcase and removes a-K clipboard) Now, according to the report, the strange occurences began aftero- you installed VMS Version 5, is that correct?p   SYSMGR:  Yes, that's correct.i  F VAXORCIST:  Now, did you carefully read the Installation Guide for VMS
 Version 5?  ' SYSMGR:  (confused) Installation Guide?n  < VAXORCIST:  Yes, it should have come with the Release Notes.  H SYSMGR:  (still confused) Release Notes? (SYSMGR begins rooting about onE his disk, shifting papers around as if he might find them underneath)f  J VAXORCIST:  (annoyed) Yes, Release Notes.  They should have come with your documentation upgrade.  E SYSMGR:  (completely confused - looks up from his rooting through the * papers on his desk) Documentation upgrade?  @ VAXORCIST:  (angry) YES!  The Documentation upgrade for your VMS Documentation Set!  J SYSMGR:  Documentation S...?  Oh, you mean the grey binders?  They're overH there. (he points to the wall behind the VAXORCIST.  The VAXORCIST turnsK and we see a closed glass-front bookcase packed with grey binders.  A small.I red sign on the front of the bookcase reads: "IN CASE OF EMERGENCY, BREAKi GLASS").  I VAXORCIST:  Right.  This is going to be tougher than I thought.  Let's go > take a look at your system and see just how bad everything is.  I (CUT to the Machine Room.  The room is neat and tidy and there is no signIF that anything is wrong.  The VAXORCIST enters the room with the SYSMGR behind him.)  ( VAXORCIST:  Everything looks okay to me.    SYSMGR:  Maybe it's hibernating.  I VAXORCIST:  Unlikely.  It's probably trying to lure us into a false senseg of security.  E SYSMGR:  Sounds like VMS alright.  (VAXORCIST gives him a dirty look)t  K VAXORCIST:  I'm going to have to test it's power.  This could get ugly, youoI may want to leave.  (The SYSMGR shakes his head no.  The VAXORCIST bringsnG hiself up to full height in front of the VAX and points a finger at it)DE By the power of DEC, I expel thee from this system! (Clap of thunder)C  H (CUT to door to the machine room.  The SYSMGR is pulling a cart on which= sits the VAXORCIST wrapped from head to toe in magnetic tape)s    SYSMGR:  Any other bright ideas?  ; VAXORCIST:  Just shut up and get this damn stuff off of me.r   (CUT to SYSMGRs office)h  H VAXORCIST:  (Writing on the clipboard)  Things look pretty bad.  I think0 we're going to need a full-scale VAXorcism here.  , SYSMGR:  Is there anything I can do to help?  I VAXORCIST:  As a matter of fact, there is.  We've got to incapacitate theeH VAX to keep it from causing any more damage until I'm ready to deal withK it.  Now, I've got some software here that will do that, but it's got to be=G installed.  (VAXORCIST hands SYSMGR a tape)  With that running, the CPU-> will be so bogged down, the VAX won't be able to harm anybody.  K SYSMGR:  (Examining the tape) What is it?  A program to calculate pi to thet last digit?   I VAXORCIST:  Better than that.  It starts up All-in-1 with a 10 user load.y  J (CUT to Hall outside of Computer Room.  The VAXORCIST approaches the door.@ As the SYSMGR approaches the door, the VAXORCIST holds him back.  J VAXORCIST:  I appreciate your help, but it won't be safe for you in there.  G SYSMGR:  What?  You're going in there to face that thing alone?  You'ree nuts!e  < VAXORCIST:  Hey, it's my job.  (VAXORCIST turns to the door)  G SYSMGR:  Wait a minute.  (VAXORCIST stops and turns around)  You bettersH take this with you.  (SYSMGR removes a very large and very nasty looking" gun from the inside of his jacket)  F VAXORCIST:  (Smiling)  No, I won't need that.  I've got something moreK powerful.  (VAXORCIST holds up a small guide-sized orange binder, opens it,eK and shows it to SYSMGR.  CUT to closeup of the book which reads:  "GUIDE TOe VAX/VMS SYSTEM EXORCISM")e  K (CUT to view of Machine room door as seen by the VAX.  The VAXORCIST entersaI the room and stands in front of the VAX.  CUT to view of the Machine Roomh' showing the SYSMGR confronting the VAX)   E VAXORCIST:  By the power of DEC, I command thee, Evil Spirit, to showr thyself.   VAX:  Bugger off.-   VAXORCIST:  (Shaken)  What?   I VAX:  I said Bugger off!  Now get out of here before I core-dump all overc you!  H VAXORCIST:  (Recovered)  Threaten me not, oh Evil one!  For I speak with5 the power of DEC, and I command thee to show thyself!c  H (A rumble is heard and again the VAX becomes backlit by red lights and aH fog begins to roll across the floor.  The VAX cabinet doors slowly creakJ open to reveal two small red lights in the dark cabinet which appear to be the creature's eyes)  G VAX:  There.  Happy?  Now get out of here before I drop a tape drive ont your private parts.   J VAXORCIST:  (Opening the orange binder, he begins intoning SHUTDOWN.COM in# gregorian chant.  The VAX screams.)r  J VAX:  Stop that!  Stop that!  You, you DOS LOVER!  Your mother manages RSX systems in Hell!  4 (The VAXORCIST continues and the VAX screams again.)  I VAX:  Stop it!  (a large wad of computer tape is thrown at the VAXORCIST,t8 apparently from the VAX).  Eat oxide, bit-bucket breath!  8 (The VAXORCIST continues and the VAX screams once more.)   VAX:  Mount me!  Mount me!  F VAXORCIST:  (finishing the intonation) And now, by the power of DEC, II banish thee back to the null-space from which you came!  (The VAX screamsn! and the scream fades to silence.)o  D (CUT to the doorway of the Machine room, which now stands open.  The< VAXORCIST is once again wearing his trench coat and fedora.)   SYSMGR:  So it's over?  / VAXORCIST: (Putting his hat on) Yes, it's over.r  K SYSMGR:  (Shaking the VAXORCISTs hand) Thank God.  Listen, thanks a lot.  IE/ don't know what we would have done without you.l  G VAXORCIST:  Hey, it's the least we could do.  The Software DistributioniG Center should be sending you a patch tape in a week or two to patch outrG that AI routine and prevent this from happening again.  Sign here.  (hebI hands SYSMGR the clipboard, SYSMGR signs at the bottom and hands it back)s% Have a good one.  (VAXORCIST leaves).s  9 (SYSMGR enters the machine room.  Camera follows him in.)e  C SYSMGR:  (Calling to someone off-camera)  Okay, you guys, let's get	F rolling.  Get those backup tapes out.  We've got a clean system again!J (cheers are heard from off-camera.  The SYSMGR leaves the picture, leavingJ only the VAX with it's cabinet doors still open in the picture.  Slow zoomF in to the LSI unit.  Slowly, the LSI unit begins to emit a pulsing red glow)    (Fade to black.  CREDITS ROLL)K ---------------------------------------------------------------------------nI Copyright (C) 1991 by Christopher Russell (crussell@eng.umd.edu).  PleasePF feel free to copy this and pass it around if it amuses you, as long as this notice is left intact.g  K Any similarity between characters appearing in this script and any persons,MI creatures, or entities living, dead, or otherwise is purely coincidental.E  D I am no longer an employee of the University of Maryland, so I'm notG particularly bothered if you think that they are responsible for any ofi) this.  Unless it's funny, then it's mine.-  E Thanks to my friends and colleagues at the University of Maryland and<E elsewhere for their help and encouragement in the developement of theA script and the video.n   ------------------------------  % Date: Mon, 01 Apr 2002 16:12:11 +0100 % From: Alan Greig <a.greig@virgin.net> ) Subject: Re: VMS To Tru64 Migration Plansn8 Message-ID: <pgtgau0ljqcn9ndlcltv91rls04rr5gv2p@4ax.com>  B On 28 Mar 2002 12:25:16 -0800, jjohnston@scvl.com (James Johnston) wrote:   [posted and mailed]   B >We are starting the process of migrating our Open VMS 7.2 ClusterG >environment running ORACLE 8.1.7 to Tru64 UNIX 5.1a and TruCluster 5.0MD >running Oracle 9iRAC.  Does anyone have migration plans for this or9 >similar.  If so it would be greatly appreciated.  Thanks,  ? Why not just migrate to Oracle 9I on VMS? Do you really want torE migrate to an operating system (Tru64) that is definitely going away?iF Last I checked VMS was scheduled to live on but Tru64 was to vanish inD favour of HP-UX - with vague promises of feature transplants. I'd beA inclined to look at moving to anything *but* Tru64 given Compaq's F recent behaviour. Different if you already run Tru64 in production but start a migration now?  C Seriously what is the driver to move away from VMS? Don't you trust A Compaq's promises (I wouldn't blame you) or is something criticali missing?  0 Real Media presentation on the future of VMS at:  U http://www.compaq.com/hps/ipf-enterprise/download/OPENVMS_ON_ITANIUM_ARCHITECTURE.RAMt -- Alan   ------------------------------  $ Date: Mon, 1 Apr 2002 17:47:00 +0200! From: "Jakob Erber" <no@spam.com>T% Subject: VMS To Tru64 Migration Plans - Message-ID: <3ca8907e$1_1@news.tiscalinet.ch>o  1 We are also planning to migrate to Tru64, resons: # 1) End of support for Sybase on VMSe= 2) End of support for Ada83 on VMS after migration to Itaniumh  K we asume, that porting from Tru64 to what UNIX comes after the merger, willn not be such a big effort.a   best regards   Jakobo  : Alan Greig <a.greig@virgin.net> schrieb in im Newsbeitrag:- pgtgau0ljqcn9ndlcltv91rls04rr5gv2p@4ax.com...ID > On 28 Mar 2002 12:25:16 -0800, jjohnston@scvl.com (James Johnston) > wrote: >  > [posted and mailed]E >TD > >We are starting the process of migrating our Open VMS 7.2 ClusterI > >environment running ORACLE 8.1.7 to Tru64 UNIX 5.1a and TruCluster 5.0NF > >running Oracle 9iRAC.  Does anyone have migration plans for this or; > >similar.  If so it would be greatly appreciated.  Thankss >sA > Why not just migrate to Oracle 9I on VMS? Do you really want tocG > migrate to an operating system (Tru64) that is definitely going away?dH > Last I checked VMS was scheduled to live on but Tru64 was to vanish inF > favour of HP-UX - with vague promises of feature transplants. I'd beC > inclined to look at moving to anything *but* Tru64 given Compaq'siH > recent behaviour. Different if you already run Tru64 in production but > start a migration now? >nE > Seriously what is the driver to move away from VMS? Don't you trustDC > Compaq's promises (I wouldn't blame you) or is something critical 
 > missing? > 2 > Real Media presentation on the future of VMS at: >o > L http://www.compaq.com/hps/ipf-enterprise/download/OPENVMS_ON_ITANIUM_ARCHITE	 CTURE.RAMe > -- > Alan   ------------------------------  % Date: Mon, 01 Apr 2002 12:13:38 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca>s) Subject: Re: VMS To Tru64 Migration Plansp, Message-ID: <3CA89531.749956C3@videotron.ca>   Jakob Erber wrote:3 > We are also planning to migrate to Tru64, resons:e% > 1) End of support for Sybase on VMSM? > 2) End of support for Ada83 on VMS after migration to Itanium' > M > we asume, that porting from Tru64 to what UNIX comes after the merger, willa > not be such a big effort.   L Since Alpha will live until at least the start of a reasonable IA64 box, whyK not wait a year or two to see how the whole Compaq fisco pans out, at whichoM point you will be in a much better position to decide what is the best targetu for your port.  L Furthermore, if you wait before starting your port, you will then be dealingL with an HP that will be under pressure not to lose customers and may be in aB better position to get better prices for your forced move to Unix.  K Secondly, since Tru64 is deader than VMS at this point in time, assume that . Sybase support on Tru64 will drop quickly too.   ------------------------------  % Date: Mon, 01 Apr 2002 12:09:15 -0500o1 From: Michael Austin <maustin@firstdbasource.com>Y) Subject: Re: VMS To Tru64 Migration Plansu2 Message-ID: <3CA8943B.5EE63A8A@firstdbasource.com>   Jakob Erber wrote: > 3 > We are also planning to migrate to Tru64, resons: % > 1) End of support for Sybase on VMSw? > 2) End of support for Ada83 on VMS after migration to Itanium  > M > we asume, that porting from Tru64 to what UNIX comes after the merger, willn > not be such a big effort.r >     B And you could be wrong... moving between Unixes is not as straightG forward as it seems.  Did you know for instance, that due to this fact,mG Oracle has a porting team for each platform.  And since the baseline isnH Sun Solaris, everything else is sometimes weeks or months behind becauseD of the difficulty in doing those "other" ports. Unix != Unix.  Never0 has. Never will. -- and the same goes for Linux.  E Sybase has been in bad shape for a long time.. a lot of people I know 0 wonder how long they will be able to hang on....     > best regards >  > JakobC --   Regards,  7 Michael Austin            Registered Linux User #261163O7 First DBA Source, Inc.    http://www.firstdbasource.com  Sr. Consultant 704-947-1089 (Office)  704-236-4377 (Mobile)W   ------------------------------   Date: 1 Apr 2002 11:50:27 -0600'- From: Kilgallen@SpamCop.net (Larry Kilgallen)e) Subject: Re: VMS To Tru64 Migration Planse3 Message-ID: <Qu9734LzGenC@eisner.encompasserve.org>O  Q In article <3ca8907e$1_1@news.tiscalinet.ch>, "Jakob Erber" <no@spam.com> writes:s3 > We are also planning to migrate to Tru64, resons:9% > 1) End of support for Sybase on VMSi? > 2) End of support for Ada83 on VMS after migration to Itaniumt  A If you are switching compiler vendors to stay with Ada83, that isE@ a mistake.  The (many) reasons to stay with Compaq Ada relate to> the fact that I have existing code (and build procedures) thatD are well tested with that compiler, not due to language enhancements	 in Ada95.h   ------------------------------  $ Date: Mon, 1 Apr 2002 13:16:57 -0500( From: Bill Gunshannon <bill@cs.uofs.edu>) Subject: Re: VMS To Tru64 Migration Plansr@ Message-ID: <20020401131312.R371-100000@server2.cs.scranton.edu>  # On Mon, 1 Apr 2002, JF Mezei wrote:u   > Jakob Erber wrote:5 > > We are also planning to migrate to Tru64, resons: ' > > 1) End of support for Sybase on VMShA > > 2) End of support for Ada83 on VMS after migration to Itaniumn > >hO > > we asume, that porting from Tru64 to what UNIX comes after the merger, willo > > not be such a big effort.  > N > Since Alpha will live until at least the start of a reasonable IA64 box, whyM > not wait a year or two to see how the whole Compaq fisco pans out, at whichiO > point you will be in a much better position to decide what is the best targeti > for your port.  F Why postpone the inevitable??  The datacenter here started considering< alternatives within days of the announcement of Alpha's EOL.   >MN > Furthermore, if you wait before starting your port, you will then be dealingN > with an HP that will be under pressure not to lose customers and may be in aD > better position to get better prices for your forced move to Unix.  I That assumes customers who are displeased with Compaq are not going to beo equally displeased with HP.t   >fM > Secondly, since Tru64 is deader than VMS at this point in time, assume thatt0 > Sybase support on Tru64 will drop quickly too. >i  I I must admit, considering that Tru64 already has been announced as havingdI no future and VMS is still just an unknown, I can't understand why anyonen would move in that direction.e   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------  # Date: Sun, 31 Mar 2002 20:00:37 GMTr1 From: "Terry C. Shannon" <terryshannon@attbi.com>0# Subject: Re: [OT] 11th of Septembern: Message-ID: <FVJp8.45296$44.18414404@typhoon.ne.ipsvc.net>  : "Didier Morandi" <Didier.Morandi@Free.fr> wrote in message! news:3CA76A23.C9E6B52B@Free.fr... J > Do you know that a book has been published last week in France about the 11th of 
 >  September?rE > Its author: Thierry Meyssan (famous in France for various reasons).nJ > Its title "11 septembre 2001 l'effroyable imposture" (awfull imposture).: > Its subtitle "No plane ever crashed onto the Pentagone".@ > Its conclusion could interest Oliver Stone for his next movie. >eF > http://www.effroyable-imposture.net/docs/index.php3 (in English too) >.K > Where could this be discussed, if it may be interesting to share advices?o   alt.conspiracy_theory?  K Mssr. Thierry undoubtedly exploited one interesting aspect of 9/11... therepI didn't seem to be much of a blast field associated with the aircraft thathH was flown into the Pentagon. (And I am glad that the terrorist vermin inL question exemplified piloting about as well as they exemplified Islam... way off target on both counts).A   ------------------------------   End of INFO-VAX 2002.180 ************************