1 INFO-VAX	Sun, 01 Jul 2001	Volume 2001 : Issue 361       Contents:P 36-bit addressing ( was Re: The death of VMS has been greatly exaggerated) exagg! Re: 64 systems don't NEED windows  C-Kermit 8.0 Beta @ Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?D Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?D Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?D Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?D Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? Re: Copying "foreign" tapes... Re: Copying "foreign" tapes... Re: FUD  Re: FUD   Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.7 I  (of all people) just got a letter from Rich Marcello ; Re: I  (of all people) just got a letter from Rich Marcello ; Re: I  (of all people) just got a letter from Rich Marcello  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World % Re: Itanium, non-issue, stop the mail - Re: OpenVMS/VAX hang on boot - SECURESHRP.EXE 6 Re: Question to Charlie Matco - reply to Terry Shannon Re: Tapesys and VMS 7.3 ' Re: Thanks Compaq for the new business! ' Re: Thanks Compaq for the new business! 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated * Re: Upgrade to 7.3 migrating CA Ingres 6.4 Re: Wailing and moaning....  Re: Wailing and moaning....  Re: Wailing and moaning....  What is lockstep ?! Re: where should SYSUAF.DAT live? ! RE: where should SYSUAF.DAT live? ! Re: where should SYSUAF.DAT live? ! Re: where should SYSUAF.DAT live? + Re: Why Compaq won't succeed on IA64 either  will the irony never cease Re: will the irony never cease% Re: Windows Images Running Under iVMS   Write record to accounting file?  F ----------------------------------------------------------------------  # Date: Sat, 30 Jun 2001 18:38:05 GMT + From: Ryan Moore <rmoore@rmoore.dyndns.org> Y Subject: 36-bit addressing ( was Re: The death of VMS has been greatly exaggerated) exagg < Message-ID: <Pine.LNX.4.31.0106301131560.9218-100000@jaipur>  ( On Sat, 30 Jun 2001, John Vottero wrote:M > I'm wrong?  Care to explain how a Xeon accesses memory beyond 4GB with a 32  > bit pointer?  D I think you're confusing physical address space with virtual addressG space.  It's certainly conceivable that processes could be limited to a I 32-bit address space, yet the processor can support physical addresses of * 36 bits allowing for more than 4GB of RAM.  D Remember that when your processes accesses any address, the physicalG address is retrieved from your process' page tables.  If the "physical" ? addresses somehow allowed 36 bits worth of addresses, then your F machine could have more than 4GB of RAM even if one process could only address up to 4GB.  I I believe some of the later VAX processors had 36-bit physical addressing J extensions to allow for more than 4GB of RAM.  I have to idea how it works
 for Xenon.   -Ryan    ------------------------------  % Date: Sat, 30 Jun 2001 23:07:44 +0100 4 From: "John D. Peedle" <john@peedle.freeserve.co.uk>* Subject: Re: 64 systems don't NEED windows. Message-ID: <9hlhm6$dlo$1@news8.svr.pol.co.uk>  : Steven P. Underwood <StevenU@POBoxes.com> wrote in message, news:3b3d1b5e.564902758@news.telocity.com...  C > That's it.  Compaq's next announcement will be the sale of VMS to H > Microsoft, so they can concentrate on their "core" business of selling > boxes ;-)  >  > Steve  > Steven P. Underwood,DNRC > Whitinsville,MA  > StevenU@POBoxes.com   C There is but one God called Microsoft, and Groves is his prophet...    ------------------------------   Date: 30 Jun 2001 21:21:19 GMT0 From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: C-Kermit 8.0 Beta5 Message-ID: <9hlfsf$10m$1@newsmaster.cc.columbia.edu>   C I announced C-Kermit 8.0 Beta.02 yesterday on the Kermit newsgroup:      comp.protocols.kermit.misc   You can find it here:   *   http://www.columbia.edu/kermit/ck80.html  B Of course I still keep the VMS version current, and built this oneA on 5.5 through 7.2 with and without various TCP/IP packages (TGV,  UCX, TCPware, etc).   A Can somebody who has VMS 7.3 and a C compiler please try building / it there?  (Was VMS 7.3 also released for VAX?)    Other builds are needed too:    . Any pre-5.5 VMS version  . VMS 6-point-anything on VAX  G By the way, the new release of C-Kermit includes a built-in FTP client, F which, because it's built-in to C-Kermit, is also fully scriptable andA has all the other Kermit file transfer features, such as restart, D automatic text/binary-mode switching, character-set translation, andJ cross-platform recursive directory-tree transfer.  But it's only for UNIX.G That's because it would take a better VMS programmer than I am to adapt G it to VMS, mainly because of all the RMS aspects and the associated FTP F protocol tricks used for VMS-to-VMS transfers and/or exporting bizarreF VMS file formats to non-VMS systems, etc.  If anybody is interested in taking this on, let me know.  D C-Kermit 8.0 also includes all sorts of security: Kerberos IV and V,E SSL/TLS, and SRP.  That hasn't been ported to VMS either.  Same deal.    - Frank <fdc@columbia.edu>   ------------------------------   Date: 30 Jun 2001 20:08:06 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)I Subject: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? , Message-ID: <9hlbj6$keb@gap.cco.caltech.edu>  F It would be nice if once Q managements' eyes stop spinning they could G clarify the repercussions on the hobbyist and education programs of the G sale of their compiler divisions to Intel.  Products have at times been I pulled from the CSLG following such sales, and if the CSLG is a bad deal  G now, it's going to be completely unworkable if the compilers go away.   C Ditto for the hobbyist and (still unusable, but who cares anymore?) > educational license program.  Ditto for Linux/Alpha compilers.   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                       RIP VMS & ALPHA                                  *J **************************************************************************   ------------------------------  % Date: Sat, 30 Jun 2001 15:37:02 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? ' Message-ID: <3B3E386E.53C0C8FB@fsi.net>    David Mathog wrote:  > [snip]E > Ditto for the hobbyist and (still unusable, but who cares anymore?) & > educational license program.  [snip]  + Sorry, David - couldn't let that one go by.   F The hobbyist program is about the only one they got right to any great= degree. The caveat is the "hobby" aspect - no commercial use.   G Where they screwed up is not having an accompanying affordable end-user ? license to maximize the usefulness of the development licenses.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------  % Date: Sat, 30 Jun 2001 15:44:39 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? ' Message-ID: <3B3E3A37.18CAF73C@fsi.net>    "David J. Dachtera" wrote: >  > David Mathog wrote: 
 > > [snip]G > > Ditto for the hobbyist and (still unusable, but who cares anymore?) ( > > educational license program.  [snip] > - > Sorry, David - couldn't let that one go by.  > H > The hobbyist program is about the only one they got right to any great? > degree. The caveat is the "hobby" aspect - no commercial use.   E ...but you're quite right: there's still a lot of grumbling about the 7 new educational license. I don't get it either, FWIW...    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------  # Date: Sat, 30 Jun 2001 21:24:16 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? ; Message-ID: <4sr%6.732$9r6.1190944@typhoon.ne.mediaone.net>   3 A damn good one to have a bunch of people feed into  www.compaqworkinggroup.org    ? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in message & news:9hlbj6$keb@gap.cco.caltech.edu...G > It would be nice if once Q managements' eyes stop spinning they could I > clarify the repercussions on the hobbyist and education programs of the I > sale of their compiler divisions to Intel.  Products have at times been J > pulled from the CSLG following such sales, and if the CSLG is a bad dealG > now, it's going to be completely unworkable if the compilers go away. E > Ditto for the hobbyist and (still unusable, but who cares anymore?) @ > educational license program.  Ditto for Linux/Alpha compilers. > 
 > Regards, >  > David Mathog > mathog@caltech.edu@ > Manager, sequence analysis facility, biology division, CaltechL > **************************************************************************L > *                       RIP VMS & ALPHA                                  *L > **************************************************************************   ------------------------------  # Date: Sat, 30 Jun 2001 21:30:30 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? ; Message-ID: <Wxr%6.734$9r6.1193182@typhoon.ne.mediaone.net>   < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B3E3A37.18CAF73C@fsi.net...  > "David J. Dachtera" wrote: > >  > > David Mathog wrote:  > > > [snip]I > > > Ditto for the hobbyist and (still unusable, but who cares anymore?) * > > > educational license program.  [snip] > > / > > Sorry, David - couldn't let that one go by.  > > J > > The hobbyist program is about the only one they got right to any greatA > > degree. The caveat is the "hobby" aspect - no commercial use.  > G > ...but you're quite right: there's still a lot of grumbling about the 9 > new educational license. I don't get it either, FWIW...   L A month ago Mark Gorham said he was gonna fix the educational license, dunno: if the Grand Transition will have any effect on this plan.   ------------------------------  % Date: Sat, 30 Jun 2001 13:10:32 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ' Subject: Re: Copying "foreign" tapes... ' Message-ID: <3B3E1618.236E98A5@fsi.net>    "James L. Wiley" wrote:  > M > I am trying to figure out how to copy some tapes from a non-VMS system (CDC M > Cyber) to files on disk.  I don't want any kind of conversion or changes to M > the data.  I even want all the label information and any end of file marks, N > etc to go along.  My plan is to download these "container" files to a PC andH > burn CD's.  The tape drive on the VMS system is a SCSI attached TSZ07. > M > I have tried mounting a tape with the /over=all parameter, but I get errors , > if I just try to use the VMS copy command. > 0 > Could someone point me in the right direction?   My best recommendations:  < $ MOUNT/FOREIGN/BLOCK=32767 ddcu:	! MOUNT the tape drive and $					! allow for large blocks.     If the tape datsets have labels:   Repeat for each dataset: $ COPY ddcu: filename_HDR.DAT  $ COPY ddcu: filename.DAT  $ COPY ddcu: filename_EOF.DAT   E When the "filename_HDR.DAT" file has a zero length, end-of-tape (EOT)  has been reached.   # If the tape datsets have NO labels:    Repeat for each dataset: $ COPY ddcu: filename.DAT   E When the "filename.DAT" file has a zero length, end-of-tape (EOT) has 
 been reached.   G I don't have a system handy to test that, but based on past experience, ( its a good place to start experimenting.  F Before transferring the files to a PC, you may need to CONVERT them toF STREAM format (RFM=STM). This will depend upon the app. that will read
 the files.   Then, transfer them as binary.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------  # Date: Sat, 30 Jun 2001 19:05:32 GMT  From: ebh@home.com' Subject: Re: Copying "foreign" tapes... ( Message-ID: <3B3E2462.FA87C5A9@home.com>   > "James L. Wiley" wrote:  > > O > > I am trying to figure out how to copy some tapes from a non-VMS system (CDC O > > Cyber) to files on disk.  I don't want any kind of conversion or changes to O > > the data.  I even want all the label information and any end of file marks, P > > etc to go along.  My plan is to download these "container" files to a PC andJ > > burn CD's.  The tape drive on the VMS system is a SCSI attached TSZ07. > > O > > I have tried mounting a tape with the /over=all parameter, but I get errors . > > if I just try to use the VMS copy command. > > 2 > > Could someone point me in the right direction? >   8 http://www.openvms.compaq.com/freeware/FREEWARE50/ETAPE/   ------------------------------    Date: 30 Jun 2001 16:03:18 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)  Subject: Re: FUD3 Message-ID: <f+2C4W37Ub5$@eisner.encompasserve.org>   [ In article <3B3E0D77.E03ECA98@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  > Larry Kilgallen wrote: >>  [ >> In article <3B3CF79E.FD041A24@infopuls.com>, Christof Brass <brass@infopuls.com> writes:  >>  < >> > My experience with Slowaris on SPARC isn't quite good -> >> > especially the NFS and NIS+ related parts are a source of= >> > problems. Some servers with certain functions have to be ! >> > rebooted monthly (at least).  >>  I >> I know a Solaris-centric shop that wanted to reboot their VMS machines 5 >> each month because that is "normal" for computers.  > J > Recent real-life lesson: it is possible to get so accustomed to machinesC > that *DON'T* need to be rebooted that the procedures to shutdown, I > startup and/or reboot become lost artifacts due to a number of factors.  > @ > Unless uptime demands are such that scheduled downtime is near: > impossible, I don't necessarily view this as a negative.  E I view procedures as negative if people do not know why they do them. D The proper time to reboot a VMS machine is not every 30 days becauseC of nonpaged pool leaks.  The proper time to reboot a VMS machine is C after changes have been made to the bootup procedures, even if that  means every day for a month.   ------------------------------  % Date: Sat, 30 Jun 2001 15:32:43 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: FUD' Message-ID: <3B3E376B.F17A8227@fsi.net>    Larry Kilgallen wrote: > ] > In article <3B3E0D77.E03ECA98@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  > > Larry Kilgallen wrote: > >>] > >> In article <3B3CF79E.FD041A24@infopuls.com>, Christof Brass <brass@infopuls.com> writes:  > >>> > >> > My experience with Slowaris on SPARC isn't quite good -@ > >> > especially the NFS and NIS+ related parts are a source of? > >> > problems. Some servers with certain functions have to beE# > >> > rebooted monthly (at least).l > >>K > >> I know a Solaris-centric shop that wanted to reboot their VMS machinese7 > >> each month because that is "normal" for computers.r > >tL > > Recent real-life lesson: it is possible to get so accustomed to machinesE > > that *DON'T* need to be rebooted that the procedures to shutdown,hK > > startup and/or reboot become lost artifacts due to a number of factors.  > >nB > > Unless uptime demands are such that scheduled downtime is near< > > impossible, I don't necessarily view this as a negative. > G > I view procedures as negative if people do not know why they do them. F > The proper time to reboot a VMS machine is not every 30 days becauseE > of nonpaged pool leaks.  The proper time to reboot a VMS machine isrE > after changes have been made to the bootup procedures, even if thatc > means every day for a month.  G By that measure, I'd recommend a shutdown and manual reboot every eightuE weeks or as often as scheduled downtime allows, making sure to rotate.F between operator shifts so there is no shortage of people who know howF to do it, and to insure that the necessary portions of the system disk" have not been rendered unreadable.  3 YMMV ... I'm very old-school, reliability-oriented.e   --   David J. DachteraS dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/e  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------  # Date: Sat, 30 Jun 2001 21:56:59 GMTh' From: Steve Thompson <smt@twcny.rr.com>h) Subject: Re: Full port of VMS to Itanium.tG Message-ID: <Pine.LNX.4.33.0106301755560.1924-100000@vger.vgersoft.com>n  , On Fri, 29 Jun 2001, Terry C. Shannon wrote:  H > The first "real" analyst briefing for Alpha was in February 1992, nineL > months before the official launch. And on the offficial launch date, AlphaL > might have been ready to ship, but it's for sure that no OSes or apps were > ready.  H ...but I had my first Alpha system, a 3000/400 w/s complete with AXP VMSH 1.0, ordered on the official launch date, and delivered 9 days later. It% worked, and in a mixed cluster too...    Steves   ------------------------------  % Date: Sat, 30 Jun 2001 23:27:16 +0100g% From: Alan Greig <a.greig@virgin.net>d) Subject: Re: Full port of VMS to Itanium.a* Message-ID: <3B3E5244.E1474145@virgin.net>   Steve Thompson wrote:c  J > ...but I had my first Alpha system, a 3000/400 w/s complete with AXP VMSJ > 1.0, ordered on the official launch date, and delivered 9 days later. It' > worked, and in a mixed cluster too...s >a  N Can't recall exactly when I got my first 300-400 but it was shortly before theI official release IIRC. The clustering code was not supported in the first N Alpha/VMS release but it seemed to work fine if you turned it on. What annoyedK the hell out of me was the absence of an IP stack. The machine was releasedIK before a UCX port was completed. I think Multinet was available from Day 1.-   >  > Stevea   --
 Alan Greig   ------------------------------  # Date: Sat, 30 Jun 2001 23:58:58 GMTc4 From: "Terry C. Shannon" <terryshannon@mediaone.net>) Subject: Re: Full port of VMS to Itanium. ; Message-ID: <6Jt%6.746$9r6.1232971@typhoon.ne.mediaone.net>5  4 "Steve Thompson" <smt@twcny.rr.com> wrote in messageA news:Pine.LNX.4.33.0106301755560.1924-100000@vger.vgersoft.com...h. > On Fri, 29 Jun 2001, Terry C. Shannon wrote: >iJ > > The first "real" analyst briefing for Alpha was in February 1992, nineH > > months before the official launch. And on the offficial launch date, AlphasI > > might have been ready to ship, but it's for sure that no OSes or apps2 were
 > > ready. >aJ > ...but I had my first Alpha system, a 3000/400 w/s complete with AXP VMSJ > 1.0, ordered on the official launch date, and delivered 9 days later. It' > worked, and in a mixed cluster too...  >   K Cool. Here's hoping that the first VMS-based IPF systems perform as well ind 2004!t   ------------------------------  # Date: Sun, 01 Jul 2001 00:21:53 GMTh' From: bad bob <sfmc68@bellatlantic.net>u) Subject: Re: Full port of VMS to Itanium.a0 Message-ID: <3B3E7002.2B0BA936@bellatlantic.net>   "Terry C. Shannon" wrote:  > 6 > "Steve Thompson" <smt@twcny.rr.com> wrote in messageC > news:Pine.LNX.4.33.0106301755560.1924-100000@vger.vgersoft.com...a0 > > On Fri, 29 Jun 2001, Terry C. Shannon wrote: > >iL > > > The first "real" analyst briefing for Alpha was in February 1992, nineJ > > > months before the official launch. And on the offficial launch date, > AlphasK > > > might have been ready to ship, but it's for sure that no OSes or appsa > were > > > ready. > >eL > > ...but I had my first Alpha system, a 3000/400 w/s complete with AXP VMSL > > 1.0, ordered on the official launch date, and delivered 9 days later. It) > > worked, and in a mixed cluster too...  > >c > M > Cool. Here's hoping that the first VMS-based IPF systems perform as well int > 2004! A I don't mean to geez, but isn't the charon vax already available?k? isn't the ISP alpha kicking around?  So, vms port = really not,s6 but rather a container including an alpha emulator.... just a thought bad bob    ------------------------------    Date: 30 Jun 2001 15:21:47 -0700" From: cstranslations@msn.com (Joe)@ Subject: I  (of all people) just got a letter from Rich Marcello= Message-ID: <d56d1c2d.0106301421.751f72cb@posting.google.com>-  E I just got an email from Rich. Well technically this is my wife's MSNmD account so I guess my wife just got an email from Rich. How Rich got myE wife's email address and why he's sending her email has me wondering.t I'll have to go talk to the wife...  C I'm posting it through Google since MSN piece of cr*p that it it iseD barfing (and there's nothing unsual about that) every time I hit the post button.   Joeh   ----- Original Message -----9 From: "Rich Marcello, VP Compaq High Performance Systems"t <Rich.Marcello@CETS2001.com> To: <cstranslations@msn.com>% Sent: Saturday, June 30, 2001 7:22 AMl Subject: Itanium and CETS-2001    
 > Dear Joseph* >*8 > By now you are aware Compaq has announced that we will9 > standardize our 64-bit enterprise server product lines, ; > including the NonStop Himalaya, AlphaServer, and ProLiant*8 > families, on Intel's Itanium(tm) processor family, its9 > next-generation microprocessor targeted at the high-end  > enterprise computing market.5 > http://www.compaq.com/hps/ipf-enterprise/index.htmli > > > The question you are likely now asking yourself is what does > this mean to me? >h> > First let me assure you that Compaq will immediately begin a9 > full port of the Tru64 UNIX, OpenVMS and NonStop Kernel.8 > operating systems and development tools to the Itanium9 > processor family. This means that all of the enterprise > > features and characteristics that you have relied on will be: > there on the Itanium platform. Additionally, Compaq will9 > continue development and enhancement of these operatingl> > system environments ensuring that we can continue to deliver2 > leadership capabilities - such as clustering and9 > availability. Our intention is to have our first Compaqw< > Itanium-based systems for Tru64 UNIX and OpenVMS available: > in 2003 for early ISV testing and generally available in > 2004.  >e9 > It is of utmost importance to us, however, that you aree: > confident that Compaq is delivering significant business: > value today and complete investment protection in Alpha-6 > based solutions for many years to come. Compaq's top; > priorities for Alpha-based systems remain unchanged -- toe< > deliver improved performance and faster implementations of8 > the Alpha microprocessor to meet committed performance4 > enhancements, while continuing to provide the most1 > available, scalable systems at the lowest cost.h >a= > We will continue to supply you information via our web site < > and through other means, however I would like to alert you> > to a special upcoming opportunity to get the information you< > will need to deploy this technology. The Compaq Enterprise6 > Technology Symposium, which will be held in Anaheim,< > California, September 9-14, will be your most concentrated< > source for knowledge on how to plan fully rollout this new6 > technology as well as how to continue optimizing and5 > extending your current Alpha based environment. The/ > Symposium will focus on: >r6 > - Our strategy and product roadmaps. Compaq's senior6 > management team, including Michael Capellas, will be6 > there to help you clearly understand our directions. >d6 > - What to do and what not to do to get ready for our; > Itanium based environment. Compaq's engineering community 9 > will present what should be done to prepare for Itaniumm8 > and what you need to think about and what you will not > have to worry about. >i; > - Compaq will provide the technical knowledge to not onlye7 > assist you in planning the transition to Itanium, buti8 > also on how to achieve the best co-existence with your > existing environments. >o9 > Whether you are a Tru64 UNIX, OpenVMS, Windows 2000, ort5 > Linux technologist the Compaq Enterprise Technologyg; > Symposium in September is the place you need to be to get 7 > the jump on deploying Itanium technology. Compaq wills7 > provide the insight to show you that not only will weo> > deliver the best operating systems available for Itanium but: > also how to prepare for adopting this technology rapidly; > into your enterprise. Along with Compaq's Engineering andu; > Management teams, please join me in September in Anaheim. 5 > For more information visit http://www.CETS2001.com.  >h > Best Regards,e >e3 > Rich Marcello, Vice President and General Managerv# > High Performance Systems Division* >* >*9 > For additional information on the multi-year Compaq and 0 > Intel technology and marketing agreement visit> > http://www.compaq.com/hps/ipf-enterprise/index.html Included: > on this site is the opportunity to view a webcast of the9 > announcement, press releases, customer quotes and more.  >n >" >e   ------------------------------   Date: 30 Jun 2001 22:40:39 GMT- From: Joe Heimann <heimann@nog.ecs.umass.edu>DD Subject: Re: I  (of all people) just got a letter from Rich Marcello+ Message-ID: <9hlkh7$i0$1@odo.ecs.umass.edu>   # Joe <cstranslations@msn.com> wrote:DG > I just got an email from Rich. Well technically this is my wife's MSN F > account so I guess my wife just got an email from Rich. How Rich got > myG > wife's email address and why he's sending her email has me wondering.  > I'll  > have to go talk to the wife...  E > I'm posting it through Google since MSN piece of cr*p that it it is F > barfing (and there's nothing unsual about that) every time I hit the > post button.   > Joes  F I got the same message, looks like it may have been sent to all DECUS/  Encompass registered membership.   Joe Heimanna   heimann@ecs.umass.edud   ------------------------------  # Date: Sat, 30 Jun 2001 23:57:54 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>D Subject: Re: I  (of all people) just got a letter from Rich Marcello; Message-ID: <6It%6.745$9r6.1232620@typhoon.ne.mediaone.net>s  : "Joe Heimann" <heimann@nog.ecs.umass.edu> wrote in message% news:9hlkh7$i0$1@odo.ecs.umass.edu... % > Joe <cstranslations@msn.com> wrote:m" > > I just got an email from Rich.   > > Joet >yH > I got the same message, looks like it may have been sent to all DECUS/" > Encompass registered membership.  G Yep, this appears to be the case. Given the timing of the announcement, E CETS2001 will likely be the earliest opportunity to get all the luridc  details on the Alpha-->IPF move.  H Of course, this throws the CETS2001 content development team in overtimeK mode, as the existing session schedule will have to be overhauled big-time!e   ------------------------------   Date: 30 Jun 2001 17:33:49 GMT/ From: mccalpin@gmp246.austin.ibm.com (McCalpin)   Subject: Re: IA64 Rocks My World1 Message-ID: <9hl2ht$fic$1@ausnews.austin.ibm.com>Y  @ In article <3b3dde25$0$1915$b45e6eb0@senator-bedfellow.mit.edu>,  John F Carr <jfc@mit.edu> wrote:> >In article <203e73fa.0106291456.67240057@posting.google.com>, >Wow <chfong@yahoo.com> wrote:E >>IBM did not cave in to Intel. Just look at the Power4 architecture.. > > >I've looked at the architecture.  I've looked at the pictures> >of the big bolts used to hold the modules together.  When can0 >I look at a working chip or module in a system?  ! There are a couple of options....o  9 There is a very large room full of working POWER4 systemse: in Austin.  The beginning of the lab tour goes past a nice= pile of components, so you can see the motherboard, the MCMs, : the nifty heatsink technology, etc.  So just convince your9 handy IBM salescritter that you are a potential customer,s2 sign the NDA, and come down to Austin for a visit!  9 I don't know how many machines there are in Poughkeepsie,t/ which is a bit closer to MIT than Austin is....  -- r9 John D. McCalpin, Ph.D.           mccalpin@austin.ibm.comaF Senior Technical Staff Member     IBM POWER Microprocessor Development-     "I am willing to make mistakes as long asa1      someone else is willing to learn from them."u   ------------------------------   Date: 30 Jun 2001 17:36:38 GMT/ From: mccalpin@gmp246.austin.ibm.com (McCalpin)   Subject: Re: IA64 Rocks My World1 Message-ID: <9hl2n6$l0k$1@ausnews.austin.ibm.com>   > In article <name99-2906011608320001@il0203a-dhcp93.apple.com>,' Maynard Handley <name99@mac.com> wrote:l >e- >Were the low-end RS/6000s available in 1989   >(a) not single chip orp >(b) not super scalar? >o? >It was my understanding that even the very first RS/6000s were H >superscalar, and I would have thought the low-end ones were single CPU.  : I got one of the earliest RS/6000's in the Spring of 1990.7 They were not single-chip systems -- maybe eight chips?e  : The PowerPC 601 was the first single-chip processor in the extended family.  ; The POWER side of the line did not become single-chip until  P2SC (POWER2 single-chip). --  9 John D. McCalpin, Ph.D.           mccalpin@austin.ibm.comcF Senior Technical Staff Member     IBM POWER Microprocessor Development-     "I am willing to make mistakes as long asa1      someone else is willing to learn from them."i   ------------------------------  # Date: Sat, 30 Jun 2001 18:51:28 GMTi+ From: Anne & Lynn Wheeler <lynn@garlic.com>   Subject: Re: IA64 Rocks My World) Message-ID: <uithdol7w.fsf@earthlink.net>l  1 mccalpin@gmp246.austin.ibm.com (McCalpin) writes:>   > < > I got one of the earliest RS/6000's in the Spring of 1990.9 > They were not single-chip systems -- maybe eight chips?i > < > The PowerPC 601 was the first single-chip processor in the > extended family. > = > The POWER side of the line did not become single-chip untilo > P2SC (POWER2 single-chip).  E I've got a paper weight on my desk with six chips in it ... that says 9 150 million ops, 60 million flops, 7 million transistors.   E there was a RSC ... referred to as RIOS .9. I don't remember how mucheE influence it had on somerset (aka powerpc). It was used in (live) oak B (i.e. 4-way SMP box that got around the lack of cache coherence byE flagging virtual segments as to cach'able or non cach'able; aka if iteB really needed to be shared, it was flagged as never going thru the cache).   ; during part of the 6000 period my wife was manager, rs/6000 C engineering achitecture and her manager went on to head up somerseteF with the motorola people (he had previously worked for motorola beforeE joining ibm to work on rios; he later went on to be president of MIPstC and then later returned to austin w/ibm). Also, when we started the.0 HA/CMP project, it started out reporting to him.  ? the way i remember rios was that (at least) non-cache coherence9A permeated whole sections of the design (even RSC) which had to besA significantly reworked for power/pc (as well as the whole virtualo memory segment register stuff).n   random refs:/ http://www.garlic.com/~lynn/subtopic.html#hacmpr  _ http://www.garlic.com/~lynn/93.html#22 Assembly language program for RS600 for mutual exclusiona: http://www.garlic.com/~lynn/94.html#41 baddest workstation@ http://www.garlic.com/~lynn/94.html#47 Rethinking Virtual Memory] http://www.garlic.com/~lynn/95.html#9 Cache and Memory Bandwidth (was Re: A Series Compilers)e5 http://www.garlic.com/~lynn/95.html#11 801 & power/pc E http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party f http://www.garlic.com/~lynn/97.html#5 360/44 (was Re: IBM 1130 (was Re: IBM 7090--used for business orS http://www.garlic.com/~lynn/97.html#25 Early RJE Terminals (was Re: First Network?)tX http://www.garlic.com/~lynn/98.html#25 Merced & compilers (was Re: Effect of speed ... )X http://www.garlic.com/~lynn/98.html#26 Merced & compilers (was Re: Effect of speed ... )X http://www.garlic.com/~lynn/98.html#27 Merced & compilers (was Re: Effect of speed ... )4 http://www.garlic.com/~lynn/98.html#28 Drive lettersl http://www.garlic.com/~lynn/99.html#23 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve  Y2K)@ http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art1 http://www.garlic.com/~lynn/99.html#66 System/1 ?e1 http://www.garlic.com/~lynn/99.html#67 System/1 ? @ http://www.garlic.com/~lynn/99.html#129 High Performance PowerPCU http://www.garlic.com/~lynn/2000.html#49 IBM RT PC (was Re: What does AT stand for ?)MZ http://www.garlic.com/~lynn/2000.html#59 Multithreading underlies new development paradigmG http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size schemel- http://www.garlic.com/~lynn/2000c.html#4 TF-1dG http://www.garlic.com/~lynn/2000c.html#9 Cache coherence [was Re: TF-1] H http://www.garlic.com/~lynn/2000c.html#12 Cache coherence [was Re: TF-1]X http://www.garlic.com/~lynn/2000d.html#2 IBM's "ASCI White" and "Big Blue" architecture?Q http://www.garlic.com/~lynn/2000d.html#24 Superduper computers--why RISC not 390?0N http://www.garlic.com/~lynn/2000d.html#28 RS/6000 vs. System/390 architecture?N http://www.garlic.com/~lynn/2000d.html#31 RS/6000 vs. System/390 architecture?I http://www.garlic.com/~lynn/2000d.html#39 Future hacks [was Re: RS/6000 ]aq http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition) n http://www.garlic.com/~lynn/2000f.html#13 Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?- http://www.garlic.com/~lynn/2000f.html#31 OT?s] http://www.garlic.com/~lynn/2000f.html#74 Metric System (was: case sensitivity in file names)<7 http://www.garlic.com/~lynn/2001.html#72 California DMVaE http://www.garlic.com/~lynn/2001b.html#33 John Mashey's greatest hitsoE http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hitsi   -- VH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  $ Date: Sun, 1 Jul 2001 01:22:27 +01001 From: "Chris Townley" <news@townleyc.demon.co.uk>o. Subject: Re: Itanium, non-issue, stop the mailA Message-ID: <993948403.10872.2.nnrp-12.d4e45fa5@news.demon.co.uk>   ? "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> wrote in messagew- news:JAo_6.1474$hz1.207511@news.uswest.net...rF > Actually, the question of having two NGs is valid.  One would be forL > technical issues and the other for General issues.  I frequently find thisI > NG gets overloaded with non-tech stuff, making it difficult to use as ar > technical group.  H I strongly disagree - I have seen other ngs go this way. What happens isC that nobody knows which group to use, so cross post to all of them.m   Net result is more noise..   -- Chris3   ------------------------------  % Date: Sat, 30 Jun 2001 19:15:41 -0400   From: John Santos <JOHN@egh.com>6 Subject: Re: OpenVMS/VAX hang on boot - SECURESHRP.EXE6 Message-ID: <1010630190037.26002A-100000@Ives.egh.com>   On 30 Jun 2001, Cthulhu wrote:  G > HW: VAXstation 3100 (using the serial console, it reports itself as aeG > 	VAXserver 3100 Model 60 - how can I know which model it really is?).c > 	8MB RAM.AG > 	170MB HDD Apple (Quantum) disk (its original disk, if there was one,l > 	is missing).d > I > SW: OpenVMS/VAX 7.2 (fresh install) + all ECOs with rating 1, installedb > 	with suggested order. > 
 > Problem: > 	 : > %%%%%%%%%%%  OPCOM  27-JUN-2001 22:49:45.00  %%%%%%%%%%%J > Operator status for operator HOGWRT::SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;18M > CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS, NETWORK, CLUSTER, SECURITY,yQ > LICENSE, OPER1, OPER2, OPER3, OPER4, OPER5, OPER6, OPER7, OPER8, OPER9, OPER10,  > OPER11, OPER12 > K > %SET-I-NEWAUDSRV, identification of new audit server process is %0000008BC4 > %DCL-W-ACTIMAGE, error activating image SECURESHRPR > -CLI-E-IMGNAME, image file HOGWRT$DKB0:[SYS0.SYSCOMMON.][SYSLIB]SECURESHRP.EXE;1; > -SYSTEM-F-PROTINSTALL, protected images must be installed 8 > %STARTUP-W-AUDITWAIT, waiting for audit server startup > & > And then it waits for ever and ever. >  > What am I supposed to do? J > Maybe I have mis-installed some ECO (but when I rebooted it last time itJ > was all fine) and now it is better to reinstall from scratch (this is an > hobbyist@home system)? > 
 > 	hangingly,e > 	 Cthulhus  D It should install secureshrp.exe automatically.  Maybe it ran out ofF global pages or global sections before getting there.  If so, the cureA is to raise GBLPAGES or GBLSECTIONS sysgen parameters.  (Start bygH increasing them about 15-20%)  The best way to do that would be by usingG ADD_GBL... commands in MODPARAMS.DAT and using AUTOGEN with feedback tomA change them, but since you can't get to DCL, you may have to do acB conversational boot (usually >>> BOOT/1, see MGMT5 in the FAQ) andI increase them that way.  If you do this, I would do an AUTOGEN w/FEEDBACK D as soon as possible, because these parameters effect the size of theB system and thus might require other changes or it could get wedged7 somewhere else or cause lots of kernel mode pagefaults.n   -- r John Santosi Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 30 Jun 2001 18:00:58 GMTo" From: Ed Wilts <ewilts@ewilts.org>? Subject: Re: Question to Charlie Matco - reply to Terry Shannon.; Message-ID: <uto%6.1152$y76.110578@typhoon.mn.mediaone.net>a  
 Joe wrote:  I > I didn't personalyy say anything to the VP of operations until ThursdayyI > afternoon. His response was centered around "would you spend $500,000 -bC > $1,000,000 on something for which will be unsupport in 2 years?" a  K Compaq/DEC made the transition from VAX to Alpha, and I see this as simply lI another transition from Alpha to Itanium.  I'm absolutely convinced that pI Compaq learned a lot the first time around, and this time should be even mI smoother than the last.  Sure, there will be speed bumps in the road (as hK others have had going from one processor to another), but overall I expect gH this to be relatively smooth - much smoother than the first time around.  J I have no intention to panic, and remain a loyal OpenVMS system manager.             .../Ed   -- r Ed Wilts, Mounds View, MN, USA mailto:ewilts@ewilts.org   ------------------------------  % Date: Sat, 30 Jun 2001 23:52:23 +0100o% From: Alan Greig <a.greig@virgin.net>h  Subject: Re: Tapesys and VMS 7.3* Message-ID: <3B3E5827.1DFE93AE@virgin.net>   Ed Wilts wrote:b  + > Here's a non-Itanium post for a change...y >uL > Has anyone upgrade to VMS 7.3 yet and experienced any Tapesys issues?  TheL > official story from Software Partners is that we need Tapesys 6.0 which isL > currently in development.  They say they've done some brief testing on 7.3M > with the current version of Tapesys (5.2.25) and it appears to work, but itnL > won't be supported.  Has anyone gone farther than that yet?  How likely amJ > I to experience problems farther down the road that brief testing hasn't > found?  Wayne, you out there?m >e  M I did a quick test of Tapesys under 7.3 EFT2 and everything seemed to work. IoL know there is a problem with ODS-5 disks but that doesn't just apply to 7.3.J The problem is not that data does not get backed up correctly but that theO index files holding the backed up files details can't deal with some ODS-5 filee names.  	 > Thanks,l >         .../Ed > --  > Ed Wilts, Mounds View, MN, USA > mailto:ewilts@ewilts.org   --
 Alan Greig   ------------------------------   Date: 30 Jun 2001 13:11 CDT ' From: carl@gerg.tamu.edu (Carl Perkins)m0 Subject: Re: Thanks Compaq for the new business!- Message-ID: <30JUN200113113188@gerg.tamu.edu>e  1 JF Mezei <jfmezei.spamnot@videotron.ca> writes...rK }All I have seen written is that Compaq will complete work of EV7, at whichuO }point those engineers are off to Intel, and that VMS will be ported to IA64. IcJ }have not seen any commitments to sell Alphas for 11 years, nor to provide }speed improvements to EV7.a } M }Perhaps those were made, but I haven't seen them. Guess what, most customers  }would also not have seen them.h  G The slideshow (which is, of course, a Powerpoint file) show an upgrade.d9 It has the EV7 followed by an "EV7.X" on the timeline(s).w  1 Which may, or may not, be assumed to be a shrink.s  G As I recall in the explanations of when the designers are disappearing,eF there was also indication that there would be a single followup before( the last of the design team went *poof*.   --- Carl   ------------------------------  # Date: Sat, 30 Jun 2001 21:27:25 GMTp4 From: "Terry C. Shannon" <terryshannon@mediaone.net>0 Subject: Re: Thanks Compaq for the new business!; Message-ID: <1vr%6.733$9r6.1192166@typhoon.ne.mediaone.net>i  4 "Carl Perkins" <carl@gerg.tamu.edu> wrote in message' news:30JUN200113113188@gerg.tamu.edu... 3 > JF Mezei <jfmezei.spamnot@videotron.ca> writes...hG > }All I have seen written is that Compaq will complete work of EV7, ate whichaI > }point those engineers are off to Intel, and that VMS will be ported toR IA64. I L > }have not seen any commitments to sell Alphas for 11 years, nor to provide > }speed improvements to EV7.  > }iE > }Perhaps those were made, but I haven't seen them. Guess what, mostm	 customersr! > }would also not have seen them.o >pI > The slideshow (which is, of course, a Powerpoint file) show an upgrade.v; > It has the EV7 followed by an "EV7.X" on the timeline(s).r  D Since the first EV7 will in fact be an EV78, t'is safe to assume the# followup will be a shrink to CMOS9.    >n3 > Which may, or may not, be assumed to be a shrink.l >eI > As I recall in the explanations of when the designers are disappearing,sH > there was also indication that there would be a single followup before* > the last of the design team went *poof*. >   J Yeah, the EV8 group goes now (or went already?), the EV7 group will remainI with the Q until EV79 is out the door, or until rival vendors make offersg that can't be refused.   ------------------------------  # Date: Sat, 30 Jun 2001 17:56:47 GMTf& From: Eric Taylor <et@rocketship1.com>: Subject: Re: The death of VMS has been greatly exaggerated/ Message-ID: <3B3E12C4.14B7B803@rocketship1.com>k   Phil Mendelsohn wrote:  ) > On Sat, 30 Jun 2001, Eric Taylor wrote:s >. > >  Anyway, 11m was merelycP > > a kernel rewrite, but they first tried to sell it as a complete new product. > J > Um, 11M wasn't *merely* anything.  There mas much sweat of the brow.  IfG > that's all it looked like to a user, then that shows that they didn't9 > break much when they did it!  K Not that it was easy, especially when there was only assembly language, but$U the file system, utilties, and even the system calls were the same (11d). Dave didn'tmQ need to write any cross assemblers or linkers or text editors. And of course, theeJ hardware was identical, except for the missing mmu. He didn't even have to! write a boot loader from scratch.o  E And  the rumor was that 11m was written in a very short time. A young  turk's bragging rights.l  D One might  say that 11m included an 11d compatibility mode. And thatP goes to my original point of why the alpha died. Lack of vax compatibility mode.  T STill, 11m was not bad for a young kid who did it before there were any C.S. courses to teach you how.p  R But there was this guy named Conroy  who had the right stuff, who wrote a completeN set of unix like utilities for rsx: an editor (that I hacked for years), and aD complete C compiler and assembler, all written in macro-11. And lotsY of C utilities ported from unix. Multi-thousand lines of beautifly written assembly code.   K And he gave away all the source code. I learned C and many assembler trickskK from that guy. That was 20 years ago. I owe him a debt of thanks. Never mett him face to face.t  Q Oh yeah, all those C programs all ran under pdp-11 compatibility mode on the vax.o   eric         >o   ------------------------------  % Date: Sat, 30 Jun 2001 14:23:39 -0400 % From: "John Vottero" <John@mvpsi.com> : Subject: Re: The death of VMS has been greatly exaggerated/ Message-ID: <tjs68m3p89kn64@news.supernews.com>S  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9hiu0m$n32$1@pyrite.mv.net... >A2 > "John Vottero" <John@mvpsi.com> wrote in message+ > news:tjp72vkid095b6@news.supernews.com...e6 > > "Bill Todd" <billtodd@foo.mv.com> wrote in message& > > news:9hdrua$353$1@pyrite.mv.net... > > >a6 > > > "John Vottero" <John@mvpsi.com> wrote in message/ > > > news:tjk1j99u64spe1@news.supernews.com... F > > > > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message. > > > > news:MFVbm5gV2I4b@malvm5.mala.bc.ca...9 > > > > > In article <tji3n47ge8e60b@news.supernews.com>,i5 > > > > >     "John Vottero" <John@mvpsi.com> writes:e > > > > > >lK > > > > > > 32 bit processors are a dead end for general purpose computing.2	 > > > > >aK > > > > >     Which problem in particular do you see 32bit processors beingSF > > > > > inadequate for? Will those problems need to be solved by the* > > > > > average desktop system customer?	 > > > > >i > > > >0I > > > > It's not that all (or even many) problems need more than 32 bits.l > It's
 > > > thatI > > > > most computers are used to do more than one thing.  A 32 bit chip  canm > > only > > > > address 4GB of RAM.  > > > K > > > Tell that to Intel and its Xeons (32-bit machines supporting up to 64  GB > > ofK > > > RAM).  It's like telling people a 16-bit PDP-11 could only address 64a KB > > of$ > > > RAM (IIRC 4 MB was the limit). > > >c > >lJ > > The Xeon uses 36 bits for addressing memory.  It's a half assed 36 bit5 > > processor.  But, you already know that don't you?g > H > Without bothering to address the merits of Xeons (or PDP-11s, for thatH > matter), the fact remains that Xeons are universally considered 32-bit, > processors and that you were simply wrong. >f  K I'm wrong?  Care to explain how a Xeon accesses memory beyond 4GB with a 32  bit pointer?   ------------------------------  % Date: Sat, 30 Jun 2001 15:47:01 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> : Subject: Re: The death of VMS has been greatly exaggerated( Message-ID: <9hla53$df7$1@pyrite.mv.net>  0 "John Vottero" <John@mvpsi.com> wrote in message) news:tjs68m3p89kn64@news.supernews.com...h4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9hiu0m$n32$1@pyrite.mv.net... > >a4 > > "John Vottero" <John@mvpsi.com> wrote in message- > > news:tjp72vkid095b6@news.supernews.com...d8 > > > "Bill Todd" <billtodd@foo.mv.com> wrote in message( > > > news:9hdrua$353$1@pyrite.mv.net... > > > > 8 > > > > "John Vottero" <John@mvpsi.com> wrote in message   ...c  K > > > > > It's not that all (or even many) problems need more than 32 bits.h > > It's > > > > thatK > > > > > most computers are used to do more than one thing.  A 32 bit chipt > can 
 > > > only > > > > > address 4GB of RAM.i > > > >tJ > > > > Tell that to Intel and its Xeons (32-bit machines supporting up to 64 > GB > > > ofJ > > > > RAM).  It's like telling people a 16-bit PDP-11 could only address 64 > KB > > > of& > > > > RAM (IIRC 4 MB was the limit). > > > >g > > >.L > > > The Xeon uses 36 bits for addressing memory.  It's a half assed 36 bit7 > > > processor.  But, you already know that don't you?s > >nJ > > Without bothering to address the merits of Xeons (or PDP-11s, for thatJ > > matter), the fact remains that Xeons are universally considered 32-bit. > > processors and that you were simply wrong. > >A >mJ > I'm wrong?  Care to explain how a Xeon accesses memory beyond 4GB with a 32 > bit pointer?  J I really do try to include the pertinent material from posts I respond to,K but in this case perhaps I omitted some (since at the time it seemed whollye redundant).m  < Your text immediately following the first excerpt above was:  H Every day another pointy haired boss says "Tell me again why I can't putI more than 4GB of RAM in the server.", "Can't we just by machine with more0 DIMM slots?"  K That makes it crystal-clear that what you're talking about is the amount of J RAM that can be installed and used on the machine, not the amount directly6 addressable under any single mapping by the processor.  F Are you really so clueless as not to understand the difference betweenF virtual and physical memory, and how you can have more of one than theE other?  If so, you should be a lot more temperate in your statements.w   - bill   ------------------------------  % Date: Sun, 01 Jul 2001 01:13:14 +0200e) From: Christof Brass <brass@infopuls.com>/: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B3E5D0A.F84B94A2@infopuls.com>   Bob Koehler wrote: > Z > In article <3B392528.A01C7435@infopuls.com>, Christof Brass <brass@infopuls.com> writes: > >/C > > While there is some truth in your observation it lacks the mainp@ > > difference: All the other migrations include an HW emulationC > > (i.e. a proof by technique) that almost all apps will run rightcD > > there from the beginning. With the Alpha -> IA63 transition this > > isn't the case.. > @ > There was no hardware emulation in the VAX -> Alpha migration. > H > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences Corporationr? > NASA GSFC Flight Software       | Federal Sector, Civil GroupsG >                                 | please remove ".aspm" when replyings  ! He didn't list this migration ...w   ------------------------------  % Date: Sun, 01 Jul 2001 01:21:46 +0200/) From: Christof Brass <brass@infopuls.com>h: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B3E5F0A.F77CAC04@infopuls.com>   Alphaman wrote:i > : > Bob Koehler <koehler@encompasserve.org> wrote in message/ > news:jO1MpawdtwoI@eisner.encompasserve.org...e= > > In article <3B37E25A.57D5BD4C@bigfoot.com>, Hamlyn Mootoot > <univms@bigfoot.com> writes: > >70 > > > How much do you think it will cost to moveM > > > VMS to another platform?  There is no way to recoup this cost by new ori  > > > even existing VMS revenue. > > L > > Nonsense.  VMS revenues in one year alone would easily pay for the port. > B > Yes, they probably could, at today's Alpha-based profit margins. > I > Now, let's move that to a commodity Inhel platform.  Even with the same1K > profit margin, the profits are smaller.  Even with the same customer base:3 > (ha!) you wind up with less revenue, less profit.4 >  > Aaronn > --@ > Aaron Sakovich  http://members.home.net/sakovich/alphaman.html@ > Make April 15 just another day:        http://www.fairtax.org/M > "Oh my God, they killed Alpha!!!  You bastards!" (Anonymous Alpha Engineer)e  > There might be two ways out: increase the licence fees for VMS= (because the IA63 is so more powerful ... ? ) and/or increasei your customer base.e   ------------------------------  % Date: Sun, 01 Jul 2001 01:25:29 +0200o) From: Christof Brass <brass@infopuls.com>w: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B3E5FE9.83D17236@infopuls.com>   Alphaman wrote:- > : > Bob Koehler <koehler@encompasserve.org> wrote in message/ > news:Mh0T0Ht+Ir$3@eisner.encompasserve.org...nL > > Don't confuse hardware profit margins with software profit margins.  TheJ > > platform may be near cost to be competitive, but Compaq has shown thatH > > people will pay a little extra for VMS.  It'd Tru64 that I can't seeI > > people paying extra for.  I think it's a pretty good UNIX, but how dou7 > > you sell one UNIX over another on similar hardware?s > C > By cancelling the OpenVMS to IA64 port, move strategic components1K > (clustering, RMS compatibility, etc) out of OpenVMS and add them to Tru64OK > (what?  OpenVMS bits in Tru64???), and offer it up as a 'better UNIX thanGH > UNIX', while meeting DII COE and UNIX branding requirements.  One port( > instead of two, one OS instead of two. > M > Problem is, there won't be many OpenVMS customers left if they do that.  OfRL > course, the ones that are left will say they're happy with what the Q gave= > them, and the others will never be interviewed or surveyed.  > L > Who's going to pay $2,000 for an OS on a $1,000 platform?  A little extra,K > yes, meaning the price will have to be within 2x or so of the rest of theeN > industry, with Microsoft providing a good example.  $200 or so for a copy ofM > the workstation version, $500 for the server; OpenVMS will have to come outiK > with a workstation version and have it priced under $500 to keep everyoneoM > from laughing outright, and under $400 to even be considered by more than a N > few.  I hope this kind of a pricing and packaging structure is considered in# > future plans if OpenVMS survives.s >  > Aaronc > --@ > Aaron Sakovich  http://members.home.net/sakovich/alphaman.html@ > Make April 15 just another day:        http://www.fairtax.org/M > "Oh my God, they killed Alpha!!!  You bastards!" (Anonymous Alpha Engineer)A  ? Even Intel admits the heat problem of their new processor line.y8 Do you think the Itanic sucessor will produce less heat?+ Otherwise desktop computing will change ...A   ------------------------------  % Date: Sun, 01 Jul 2001 01:32:35 +0200E) From: Christof Brass <brass@infopuls.com>p: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B3E6193.3A96A359@infopuls.com>   Hamlyn Mootoo wrote: > F > I'd still waiting for someone to show me some numbers supporting theJ > profitability of a VMS port.  Compaq wants to go to IA64 and abandon theD > ALPHA - fine. Billyboxes are a given. Linux is a no-brainer from aF > revenue standpoint given the current climate.  True64 we could maybeI > argue has life due to installed base and revenue ( I'm sure a good manypG > people WENT to Digital Unix from VMS to escape the eventual demise ofoJ > VMS).  So why, oh why would Compaq want to port VMS? Without knowing theD > the GROSS PROFIT derived from VMS, let's try a little hypotheticalD > arithmetic, shall we? We'll keep the numbers very conservative andD > simple: 300 workers x $100,000 x 3 years= 90 Million for the port.B > Meanwhile, back at the ranch, the installed base of VMS steadilyJ > declines. So just to break even, Compaq has to make this much in PROFIT,J > over the three year period, which would imply revenues of serveral timesH > this number. From the last annual report, cosolidated gross margin wasH > 23.5%.  Let's be generous and say 25%.  So over three years they wouldF > need to pull in $360 million, or $120 million per year in revenue INE > ADDITION to what they pull in now, to just break even for the port,eJ > after year 3.  Instead, they could not do the port, take in the revenuesI > from support and say adios to VMS in 3 or so years.  And actually, they>I > would still have residuals if they chose to support VMS on Alpha, for a = > few more years past this.  Remember the above estimates aresJ > CONSERVATIVE.  It takes many more people in an organization to support aH > porting project such as this.  And remember, while this would be going? > on, you allegedly would have 2 other porting efforts going ona7 > simultaneously, with very little overlap in manpower.s >  > HM  8 This scenario seems to ignore the negative effect of not< annoucing and not substantially trying to port: the customer? base might much faster de-migrate. You should therefore compare 7 the decreasing numbers of the VMS user base with an ev.e increasing one.i  @ But supporting VMS seems not to fit into Compaq's strategy (? do7 they have one?). As a solution and service provider youe@ shouldn't have own products. This is the problem of IBM - nobody; who understands the business from a technical point of view-, takes the advice of IBM consultants serious.   ------------------------------  % Date: Sun, 01 Jul 2001 01:36:23 +0200e) From: Christof Brass <brass@infopuls.com>a: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B3E6277.93FCBE64@infopuls.com>   "Main, Kerry" wrote: > E > >>> While there is some truth in your observation it lacks the mainh> > difference: All the other migrations include an HW emulationA > (i.e. a proof by technique) that almost all apps will run righthB > there from the beginning. With the Alpha -> IA63 transition this > isn't the case.<<< > M > I suspect the OpenVMS Engineering folks don't know this yet, and you may bes# > right, but how do you know this ?e > M > Besides, while emulation techniques are typically ok for the desktop, proofdM > of concept and minor minor apps you need, it is hardly a strategy to deploya8 > your main business applications and support utilities.  > There seems to be a misunderstanding: the emulation techniques= mentioned meant that the old instruction set is understood by 9 the new processor at a lower speed. This is a warranty by-0 construction to be able to execute all old apps.  M > I am not trying to say whether this decision was the right one or the wrongTE > one. However, if one looks at the reality of all the platforms (seetI > attached), their Customers are almost all looking at some major portings# > efforts in the next 12-24 months.u > 
 > Regards, >  > Kerry Main > Senior Consultantt > Compaq Canada Inc. > Professional Servicesa > Voice: 613-592-4660  > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  $ Date: Sun, 1 Jul 2001 01:47:14 +01001 From: "Chris Townley" <news@townleyc.demon.co.uk> 3 Subject: Re: Upgrade to 7.3 migrating CA Ingres 6.4eA Message-ID: <993948829.11005.0.nnrp-12.d4e45fa5@news.demon.co.uk>    We were told the same about 7.2   * However there have been no issues to date.   -- Chris)  4 "John F" <john.fisher@ntlworld.com> wrote in message= news:_d8_6.28635$mK4.2611894@news6-win.server.ntlworld.com... 	 > Hi All,i >a. > We are about to upgrade to a DS20 with 7.3 .! > Our database is CA's Ingres 6.4oJ > CA are unwilling to tell us if Ingres is certified to this level of VMS. > Anyone done this?i   ------------------------------  % Date: Sun, 01 Jul 2001 01:52:06 +0200o) From: Christof Brass <brass@infopuls.com>e$ Subject: Re: Wailing and moaning...., Message-ID: <3B3E6626.81AB0363@infopuls.com>   Larry Kilgallen wrote: > W > In article <9hagob$dck$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk (D.Webb) writes:- > N > > Looking at some posts in comp.sys.dec and comp.unix.tru64 the TRU64 peopleJ > > are concerned about how TRU64 will survive on IA64 in competition with. > > the other Unix systems being ported there. > 5 > That is what makes for good software - competition.i  @ The UNIX market is obviously not driven by the quality of the OS9 implementation but by the number of available SW for thatd; specific UNIX version. I doubt that Tru64 will be in a good 6 position once all remaining UNIXes are there, at IA63.   ------------------------------  % Date: Sun, 01 Jul 2001 01:54:39 +0200 ) From: Christof Brass <brass@infopuls.com> $ Subject: Re: Wailing and moaning....+ Message-ID: <3B3E66BF.E34BB12@infopuls.com>l   Larry Kilgallen wrote: > W > In article <9hcgja$37j$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk (D.Webb) writes:es > > In article <lFvLl5Tv6P7O@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:nY > >>In article <9hagob$dck$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk (D.Webb) writes:s > >>P > >>> Looking at some posts in comp.sys.dec and comp.unix.tru64 the TRU64 peopleL > >>> are concerned about how TRU64 will survive on IA64 in competition with0 > >>> the other Unix systems being ported there. > >>7 > >>That is what makes for good software - competition.a > >s > >nL > > But one of the reasons for buying TRU64 rather than other Unix's was theK > > fact it ran on the Alpha chip. This was a selling point in certain highi" > > performance computing markets. > > > And now they will have to survive on software quality alone,? > meaning there is no opportunity for Tru64 Development to restt@ > on the laurels of the chip designers.  That can only be a goodB > thing for software quality.  The basic principle I am interestedC > in is software quality, rather than Tru64 success.  The same goes-
 > for VMS.  > Designing the HW according to SW needs was firstly done by the? VAX architecture and remains a valid principle to reach highest > combined quality. The more Alpha specific optimisations are in+ Tru64 the worse will be the result on IA63.8  < I personally like "optimised" SW, i.e. SW which is perfectly suited to a certain HW design.   ------------------------------  % Date: Sun, 01 Jul 2001 02:11:08 +0200e) From: Christof Brass <brass@infopuls.com>.$ Subject: Re: Wailing and moaning...., Message-ID: <3B3E6A9C.4E6BA083@infopuls.com>   Malcolm Dunnett wrote: > F > In article <Pine.SGI.4.21.0106261847380.28481-100000@world.std.com>,6 >      Terry C Shannon <shannon@world.std.com> writes: > >>2 > >> No, VMS is not going to dry up and blow away. > >gN > > Ya never know. Thanks to the generous contributions of flamers and lamers,L > > at least one Compaq competitor ALREADY is using threads from comp.os.vms > > in its FUD portfolio.r > >  >  [SNIP]   > I >      In a perverse way it's nice to know that the competitors listen touF > what we say on comp.os.vms. It's never seemed that Compaq management
 > does :-)  4 This is primarily a technical virtue: to discuss all< possibilities, reasons and aspects publicly without thinking> about marketing implications. I think this tradition should be@ kept up in this NG no matter how other people or companies might use our thoughts.a   ------------------------------  $ Date: Sun, 1 Jul 2001 01:54:27 +01001 From: "Chris Townley" <news@townleyc.demon.co.uk>6 Subject: What is lockstep ?IA Message-ID: <993948882.11027.0.nnrp-12.d4e45fa5@news.demon.co.uk>   B Loads of posts talk about Tandem using lockstep - but what is it ?  @ Sorry if I am being a bit naive, but never come across Tandem...     --
 Chris Townleya chris@townleyc.demon.co.uk townleyc@spicers.ltd.uk    ------------------------------  % Date: Sat, 30 Jun 2001 13:13:32 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net> * Subject: Re: where should SYSUAF.DAT live?' Message-ID: <3B3E16CC.37063644@fsi.net>    Tom Linden wrote:b > I > I have copies in both SYSMGR and SYSEXE on 7.3 AXP.  By trial and errora7 > I found that AUTHORIZE picks it up out of the former.d  A That's bizarre! Check to see if there's a SYSUAF logical defined:r   $ SHOW LOGICAL SYSUAF$  C The default location should be the SYS$SYSTEM path, unless this hase1 changed (haven't checked the release notes yet). l   --   David J. Dachteram dba DJE Systemse http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/9  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.e   ------------------------------  % Date: Sat, 30 Jun 2001 12:21:25 -0700e! From: Tom Linden <tom@kednos.com> * Subject: RE: where should SYSUAF.DAT live?9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEFCCOAA.tom@kednos.com>a  A No logical is defined, and If I remove the ones under sysmgr then    $ mcr authorizeiD %UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT) -RMS-E-FNF, file not found$ Do you want to create a new file? no  D after answering no, it takes unusually long to respond.  So I guess & I'll put them back for the time being    > -----Original Message-----8 > From: David J. Dachtera [mailto:djesys.nospam@fsi.net]( > Sent: Saturday, June 30, 2001 11:14 AM > To: Info-VAX@Mvb.Saic.Comn, > Subject: Re: where should SYSUAF.DAT live? >  >  > Tom Linden wrote:  > > K > > I have copies in both SYSMGR and SYSEXE on 7.3 AXP.  By trial and error 9 > > I found that AUTHORIZE picks it up out of the former.a > C > That's bizarre! Check to see if there's a SYSUAF logical defined:e >  > $ SHOW LOGICAL SYSUAFe > E > The default location should be the SYS$SYSTEM path, unless this hasa3 > changed (haven't checked the release notes yet).   >  > -- y > David J. Dachteraa > dba DJE Systems  > http://www.djesys.com/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/h > H > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. > B > Feel free to exercise your rights of free speech and expression. > H > However, attacks against individual posters, or groups of posters, are > strongly discouraged.o >    ------------------------------    Date: 30 Jun 2001 16:06:24 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) * Subject: Re: where should SYSUAF.DAT live?3 Message-ID: <8l67JSAukOU6@eisner.encompasserve.org>T  ] In article <CIEJLCMNHNNDLLOOGNJIGEFACOAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes: J > I have copies in both SYSMGR and SYSEXE on 7.3 AXP.  By trial and error 7 > I found that AUTHORIZE picks it up out of the former.   B AUTHORIZE defaults to logical name SYSUAF, and if none defaults toB SYS$DISK:[].  So absent a logical name, you always modify the copy$ of SYSUAF in your default directory.  B Of course if your intent is to modify the same copy of SYSUAF that= LOGINOUT will honor, you better modify the one in SYS$SYSTEM.    ------------------------------  % Date: Sat, 30 Jun 2001 15:21:27 -0500-1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o* Subject: Re: where should SYSUAF.DAT live?' Message-ID: <3B3E34C7.3F1F5B00@fsi.net>r   Tom Linden wrote:t > C > No logical is defined, and If I remove the ones under sysmgr thenm >  > $ mcr authorizedF > %UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT) > -RMS-E-FNF, file not found& > Do you want to create a new file? no > E > after answering no, it takes unusually long to respond.  So I guessg' > I'll put them back for the time being    AH! I see what you're doing.  9 Remember that AUTHORIZE attempts to do the equivalent of:p  : $ FSP = F$PARSE( "SYSUAF", ".DAT", F$ENVIRON( "DEFAULT" )) $ OPEN/READ UAF &FSP  % (No, AUTHORIZE is *NOT* a DCL proc.!)w  B That is, it defaults to your currentd efault disk/directory unless> "SYSUAF" is a logical name that translates to a full filespec.   Here's what you wanna do:    $ set def sys$system $ mcr authorizev  G Your SYSUAF.DAT really needs to be in the SYS$SYSTEM path! Normally, itb= is found in SYS$COMMON:[SYSEXE] along with RISGHTLIST.DAT andlF NET[$]PROXY.DAT. There are some circumstances where you will want/needB to relocate these files, such as in a cluster with multiple systemG disks, but normally they are found in SYS$COMMON:[SYSEXE] on the system ; disk or on the cluster-common system disk, if there is one.a   -- l David J. Dachterau dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/i  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.w   ------------------------------  $ Date: Sun, 1 Jul 2001 00:36:24 +01001 From: "Chris Townley" <news@townleyc.demon.co.uk>-4 Subject: Re: Why Compaq won't succeed on IA64 eitherA Message-ID: <993948400.10872.1.nnrp-12.d4e45fa5@news.demon.co.uk>o  < "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message$ news:9hfbhi$g55$1@lisa.gemair.com...+ > In article <3B3B2242.33AE171C@gtech.com>, A > Arne =?iso-8859-1?Q?Vajh=F8j?=  <arne.vajhoej@gtech.com> wrote:t > >David Mathog wrote:K > >> They could not make market inroads with the Alpha, which for all but aI fewrE > >> months of its life was the fastest CPU on the planet.  Among the  reasonseI > >> they did not do so were: noncompetitive prices, lack of advertising,M and B > >> insufficient software support, most notably, tepid support by
 Microsoft.I > >> That's not a technical problem, it's a management level problem, ande the L > >> management is still there.  If they can't sell the greatest thing since( > >> sliced bread, what can they sell??? > >h > >Unfortunatetly I agree. > > H > >IA-32 has gained a lot on Alpha regarding performanve in the last 3-4	 > >years.eH > >And I can understand that Compaq was worried about IA-64 versus Alpha > >in the future.m > >lC > >But the question is: why was Alpha sales low ? I have read a loto> > >of reasons and I am quite sure that poor marketing, too few > >applications,E > >uncertainty about the future and too high prices are all much moren > >common answers. > >iG > >And this decision does not solve those problems. Indeed it increasesy > >them. > >u$ > >So the future does not look good. > >o >d> > Another problem was product placement, which goes along with noncompetitiveI > prices.  They should have produced low-cost low-end Alpha motherboards, F > even if those systems would not outperform higher end Intel systems.  H That was always the bost of VMS - develop on an incredably slow MicroVax) 2000 and it will run on top-end hardware.n  D Mind you, there has been a lot of very reasonably priced second userK hardware out there - especially just before Y2K - for some reason it jumped  a bit then.k      F > I think a lot of hobbyists and small shops might have purchased suchH > systems which would have seeded the future.  A lot of large businessesL > with a stake in big Alpha Iron might have had a place for commodity Alphas
 > as well. >fJ > Note that this is not exactly identical with noncompetitive prices.  TheK > price/performance of high end Alpha systems wasn't there either, and thatnJ > should have been addressed separately.  They should have been willing toG > loss leader old technology Alphas and flood the market with commodityeJ > systems, even if these systems didn't exceed significantly benchmarks onI > similarly configured commodity Intel systems of the day.  This wouldn'ttG > have been cost DEC very much as they were running the Hudson plant at F > a very low utilization anyway.  It would have been better to lose 2xI > on the Hudson plant and flood the low-end Alpha market than lose 1x and / > have little market penetration at some point.0 >3G > They also had the cash on hand to carry off such a plan at one point.t       -- Chris    ------------------------------   Date: 30 Jun 2001 20:04:02 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)# Subject: will the irony never ceasem, Message-ID: <9hlbbi$keb@gap.cco.caltech.edu>  J Received an email yesterday from somebody in Compaq who must subscribe to  this group:r  G    Subj:   Out of Office AutoReply: Thanks Compaq for the new business!e  K    I will be out of the office from 2-JUL-2001 thru 8-JUL, returning 9-JUL,e6    due to the general COMPAQ-wide 4-JUL week shutdown.  H At least there was an emergency contact number supplied below the boilerF plate, so I guess they have a few people working this week.  Still, itL seems like a good 7 days not to have to try to employ your service contract.   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                       RIP VMS & ALPHA                                  *J **************************************************************************   ------------------------------  # Date: Sat, 30 Jun 2001 21:22:53 GMTr4 From: "Terry C. Shannon" <terryshannon@mediaone.net>' Subject: Re: will the irony never ceaseh; Message-ID: <Nqr%6.730$9r6.1190644@typhoon.ne.mediaone.net>i  ? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in message?& news:9hlbbi$keb@gap.cco.caltech.edu...K > Received an email yesterday from somebody in Compaq who must subscribe toe
 > this group:i >sI >    Subj:   Out of Office AutoReply: Thanks Compaq for the new business!u > F >    I will be out of the office from 2-JUL-2001 thru 8-JUL, returning 9-JUL,8 >    due to the general COMPAQ-wide 4-JUL week shutdown. >hJ > At least there was an emergency contact number supplied below the boilerH > plate, so I guess they have a few people working this week.  Still, itD > seems like a good 7 days not to have to try to employ your service	 contract.a >W  G From what I understand, the shutdown is US-specific and does not affecthG finance folks (doing end of quarter quarterbacking, etc) and, one would  hope, Services resources.   G One would also hope that the Trees War Room/Fallout Shelter will remain C active. Not an optimum time to be devoid of marketing resources....t   ------------------------------  $ Date: Sun, 1 Jul 2001 00:07:18 +01001 From: "Chris Townley" <news@townleyc.demon.co.uk>p. Subject: Re: Windows Images Running Under iVMSA Message-ID: <993948399.10872.0.nnrp-12.d4e45fa5@news.demon.co.uk>o  ? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in messages& news:9hg7u6$jpk@gap.cco.caltech.edu...H > In article <tjmrd75ved0746@news.supernews.com>, wspencer@ap.nospam.org (Warren Spencer) writes:E > >Is there any credence to the notion that Windows executables mightw+ > >eventually run under OpenVMS on Itanium?p >fK > It might happen after Microsoft takes OpenVMS away from Compaq - but then   > it will be called Windows too.   Would that be DEC Windows ?   " > > That fact that DEQ has already2 > >ported Win32 to OpenVMS 7.x has me wondering... >:9 > Huh?  You mean that affinity nonsense?  Fuhgeddaboutit.@ >p   ------------------------------  % Date: Sat, 30 Jun 2001 19:35:31 -0400+  From: Kuff@Tessco.Com (Hal Kuff)) Subject: Write record to accounting file?eO Message-ID: <8466AD1DE9452F59.AB22DD2F757A06C0.5C525EB7E8134524@lp.airnews.net>@  K I'm looking for some sample code (VMS-BASIC) would be nice to send a recordeH to the accounting file... looks like $SNDJBC, but don't seem to see what item list needs to be built....5   ------------------------------   End of INFO-VAX 2001.361 ************************