1 INFO-VAX	Thu, 30 Aug 2001	Volume 2001 : Issue 482       Contents:( Re: 100 million sale for Compaq to Sabre( Re: 100 million sale for Compaq to Sabre( Re: 100 million sale for Compaq to Sabre Re: 16 VLCs for sale Re: 16 VLCs for sale RE: 16 VLCs for sale RE: 16 VLCs for sale A very sad moment.!  Re: A very sad moment.!  Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64' Re: Alpha ECU - Does it work from a CD? ' Re: Alpha ECU - Does it work from a CD? P And yet another reason to come to CETS - Complimentary OpenVMS V7 and Tru64 UNIXP Re: And yet another reason to come to CETS - Complimentary OpenVMS V7 and Tru64 % Re: C language functionality changed?  Re: Comp.os.VMS session at CETS ; Re: Compiled Languages (Was: e: My VMS Wish List (features) ; Re: Compiled Languages (Was: e: My VMS Wish List (features) ; Re: Compiled Languages (Was: e: My VMS Wish List (features) ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update  Re: DCL challenge  Re: Does MOD_PERL work on VMS  Re: Does MOD_PERL work on VMS  Re: dynamic dcl menu European Contract Vacancies  Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship?  Re: Feeling Better about ItaniumE Fun error messages (was Re: VMS high reliability needed by Air Force) : Global Section Question Again (with correct email address) Re: GNU screen for AXP/VMSE Re: How to quickly replicate a global section on another network node  Re: I hate Compaq  Re: I hate Compaq P installing extensions to MOD_PERL (was Re: CSWS, MOD_PERL - anyone have HELLO.PM Re: Mark Twain Promo Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: Nits in Slides9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) 9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) 9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) & Re: open vms hobbist tcpip license???? porting macro from VAX to ALPHA # Re: porting macro from VAX to ALPHA # Re: porting macro from VAX to ALPHA ; Procedure to restart print queues/Help with $GETQUI $SNDJBC , Re: Q: howto get proc name from library func Setting up Remote Printer Queue # Re: Setting up Remote Printer Queue # Re: Setting up Remote Printer Queue * Re: still can't get my UCX licensed???????* Re: still can't get my UCX licensed??????? Tape Parity Error: How to Read?  Understanding ast ?  Re: Understanding ast ?  Re: Understanding ast ?  Re: Understanding ast ? I What are the exact steps in order to add a user account with VAX-VMS v6.0 M Re: What are the exact steps in order to add a user account with VAX-VMS v6.0 M Re: What are the exact steps in order to add a user account with VAX-VMS v6.0 P Re: What are the exact steps in order to add a user account with VAX-VMS v6.0 v6' Re: Why continue with OpenVMS / Compaq? ' onnect  Oracle 7.2.3 and DEC Rdb 6.1 ? + Re: onnect  Oracle 7.2.3 and DEC Rdb 6.1 ?   F ----------------------------------------------------------------------  % Date: Thu, 30 Aug 2001 03:25:45 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: 100 million sale for Compaq to Sabre , Message-ID: <3B8DEA76.3B7868E0@videotron.ca>   Rob Young wrote:> > > Does VMS really have a place between Tandem, Unix and NT ? > ( >         Between?  How about alongside?  L Alongside means that Compaq would be willing to allow VMS to compete againstK its own products, including NT. And we know that Compaq won't market VMS in % markets where it competes against NT.   M Do you really beleive that Compaq is capable of having competing systems that  life "alongside" each other ?   L I know that in a market abandonned by Digital (SWIFT), VMS used to be pittedL against Tandem all the time. With Tandem and VMS now in the same company, itM is no surprise that Compaq didn't fight with SWIFT to get SWIFT to reconsider L its decision to drop VMS. After all, Compaq can offer Tandem at the high end and NT at the smaller end.   ------------------------------    Date: 30 Aug 2001 02:24:32 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 1 Subject: Re: 100 million sale for Compaq to Sabre 3 Message-ID: <z5MUU0ccd+DG@eisner.encompasserve.org>   ` In article <Jnij7.1680$jd.326280@typhoon1.gnilink.net>, "Jeff Killeen" <Jeff@IDM-IO.com> writes:  N > It amazes me the few in this newsgroup who see everything as a proving theirE > negative viewpoint of Compaq's handling of VMS.  It rained today in I > Houston - that proves the point of view Compaq is trying to kill VMS...   / No, that proves _God_ is trying to kill VMS :-)    ------------------------------  % Date: Thu, 30 Aug 2001 12:50:08 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: 100 million sale for Compaq to Sabre , Message-ID: <3B8E6EC0.DD39CB65@videotron.ca>   Larry Kilgallen wrote:1 > No, that proves _God_ is trying to kill VMS :-)   L Well off, course, where have you been lately ? It is obvious that Bill GatesH would prever VMS to go away so he could inherit all of iots intellectualL prperty and engineers allowing him to improve NT enough to further penetrate the enterprise market. :-)    ------------------------------    Date: 30 Aug 2001 03:22:53 -0700+ From: chris_doran@my-deja.com (Chris Doran)  Subject: Re: 16 VLCs for sale = Message-ID: <b5f3f0d8.0108300222.349a3abd@posting.google.com>   > inge@tarboo wrote in message news:<2001Aug23.154519@tarboo>...J > Trying desperately to figure out what I could do with them.  Saw a stackJ > of 16 VAXstation 4000 VLCs at REPC (PC recycler) in Tukwilla, WA.  Don'tK > know the price or configurations.  No monitors, keyboards or mice. My '95 K > SOC shows VLCs with 535 Mbyte RZ23s, 8 megs of memory (expandable to 24), I > 6.2 VUPs. SCSI connector on back, MMJ console port, ethernet.  Could be  > empty cases for all I know.   F For those who aren't aware of it: you don't have to use them for theirC designed purpose as workstations coupled to a bigger system -- just > load VMS and you have quite a nice baby VAX which can use a VTE terminal. (Does VLC really stand for "Very Little Computer"?). Memory D seems to be the same as early PC's (not sure of speed requirements).A Don't expect the little power supply to handle anything too beefy  (like a power-hungry disk).    Chris    ------------------------------    Date: 30 Aug 2001 05:50:56 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: 16 VLCs for sale 3 Message-ID: <XwS9V+aa0GyN@eisner.encompasserve.org>   k In article <b5f3f0d8.0108300222.349a3abd@posting.google.com>, chris_doran@my-deja.com (Chris Doran) writes: @ > inge@tarboo wrote in message news:<2001Aug23.154519@tarboo>...K >> Trying desperately to figure out what I could do with them.  Saw a stack K >> of 16 VAXstation 4000 VLCs at REPC (PC recycler) in Tukwilla, WA.  Don't L >> know the price or configurations.  No monitors, keyboards or mice. My '95L >> SOC shows VLCs with 535 Mbyte RZ23s, 8 megs of memory (expandable to 24),J >> 6.2 VUPs. SCSI connector on back, MMJ console port, ethernet.  Could be >> empty cases for all I know. > H > For those who aren't aware of it: you don't have to use them for theirE > designed purpose as workstations coupled to a bigger system -- just @ > load VMS and you have quite a nice baby VAX which can use a VT@ > terminal. (Does VLC really stand for "Very Little Computer"?).   Very Low Cost.   ------------------------------  % Date: Thu, 30 Aug 2001 09:01:32 -0500 * From: WILLIAM WEBB <WWEBB1@email.usps.gov> Subject: RE: 16 VLCs for sale - Message-ID: <0033000033767224000002L042*@MHS>     =0AVLC stands for Very Low Cost.   WWWebb   > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ) > Sent: Thursday, August 30, 2001 6:24 AM D > To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET > Subject: RE: 16 VLCs for sale  >  > @ > inge@tarboo wrote in message news:<2001Aug23.154519@tarboo>...? > > Trying desperately to figure out what I could do with them.  >  Saw a stack7 > > of 16 VAXstation 4000 VLCs at REPC (PC recycler) in  > Tukwilla, WA.  Don't= > > know the price or configurations.  No monitors, keyboards  > or mice. My '95 9 > > SOC shows VLCs with 535 Mbyte RZ23s, 8 megs of memory  > (expandable to 24), 7 > > 6.2 VUPs. SCSI connector on back, MMJ console port,  > ethernet.  Could be  > > empty cases for all I know.  > H > For those who aren't aware of it: you don't have to use them for thei= r E > designed purpose as workstations coupled to a bigger system -- just @ > load VMS and you have quite a nice baby VAX which can use a VTH > terminal. (Does VLC really stand for "Very Little Computer"?). Memory=  F > seems to be the same as early PC's (not sure of speed requirements).C > Don't expect the little power supply to handle anything too beefy  > (like a power-hungry disk).  >  > Chris  >=   ------------------------------  % Date: Thu, 30 Aug 2001 09:02:50 -0500 * From: WILLIAM WEBB <WWEBB1@email.usps.gov> Subject: RE: 16 VLCs for sale - Message-ID: <0033000033767369000002L092*@MHS>   , =0AFrom what I've seen, the video cables are" worth more than the VLC carcasses.   WWWebb   > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET * > Sent: Wednesday, August 29, 2001 7:33 PMD > To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET > Subject: RE: 16 VLCs for sale  >  > C > I snagged a few of them awhile back.  They were all 24MB, no hdd, @ > though they were kind enough to leave the mounts.  At the time > they were going for $25. > = > Scrounge around in the misc cables bin and you'll find some > > 3W3 to BNC video cables.  The keyboards are in back near the3 > "as-is" section.  They had no mice or MMJ cables.  > 
 > Regards, >  > --# > Eric Josephson <tej.tbirdpac.com>  > D > On Thu, 23 Aug 2001 15:45:19 GMT, inge@tarboo <inge@tarboo> wrote:> > >Trying desperately to figure out what I could do with them.
 > Saw a stack 6 > >of 16 VAXstation 4000 VLCs at REPC (PC recycler) in > Tukwilla, WA.  Don't? > >know the price or configurations.  No monitors, keyboards or  > mice. My '958 > >SOC shows VLCs with 535 Mbyte RZ23s, 8 megs of memory > (expandable to 24), 6 > >6.2 VUPs. SCSI connector on back, MMJ console port, > ethernet.  Could be  > >empty cases for all I know. >=   ------------------------------  % Date: Thu, 30 Aug 2001 15:59:46 +0100 * From: Andrew Robinson <arobinson@hspg.com> Subject: A very sad moment.!M Message-ID: <CDA4BAD1E10ED41181AC00508B6051D3C3E379@grumpy.internal.hspg.com>   I I though I would share with you a very sad moment I had today with one of  our suppliers.  K I was discussing a problem of connectivity with a WEB Farm's technical bod, L and said that I was using VMS - He immediately asked 'What does that run on,K UNIX or NT?' After explaining that it was actually an operating system used G on Digital's VAX & Alpha boxes there was a long pause then the response G 'Wasn't that something to do with the guy who wrote NT ? I can remember 7 something about that during history lessons at college' A I had no response to this - I just felt too old, and I'm only 36!   G This email was just a sad moment in my life and was not sent to start a C bitter and twisted thread on the state of a non-mentioned companies E marketing abilities, which I have seen in many other postings. I just I thought you would like to know that you are now part of the group 'Living  History'   Regards    Andrew Robinson    ------------------------------  + Date: Thu, 30 Aug 2001 09:01:04 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>  Subject: Re: A very sad moment.!@ Message-ID: <20010830160104.48947.qmail@web20204.mail.yahoo.com>   Andrew  7 I agree with you ! I am an old man with 29 years old=20 0 too ! There arent jobs here for OpenvMS SysMans.0 Companies here (HR) dont believe I am alive !=20. They dont want me in positions for Windows NT,/ even I worked with it strictly for 3/4 years in  banking / automation. When I decided to return to OpenVMS 5 two/three years ago, I didnt know I was entering a=20 # "black hole"... without escape !=20    Regards    FC=20   / --- Andrew Robinson <arobinson@hspg.com> wrote: 5 > I though I would share with you a very sad moment I  > had today with one of  > our suppliers. >=203 > I was discussing a problem of connectivity with a  > WEB Farm's technical bod, 6 > and said that I was using VMS - He immediately asked > 'What does that run on, 4 > UNIX or NT?' After explaining that it was actually > an operating system used1 > on Digital's VAX & Alpha boxes there was a long  > pause then the response 5 > 'Wasn't that something to do with the guy who wrote  > NT ? I can remember 0 > something about that during history lessons at
 > college'6 > I had no response to this - I just felt too old, and > I'm only 36! >=205 > This email was just a sad moment in my life and was  > not sent to start a - > bitter and twisted thread on the state of a  > non-mentioned companies 6 > marketing abilities, which I have seen in many other > postings. I just6 > thought you would like to know that you are now part > of the group 'Living
 > History' >=20	 > Regards  >=20 > Andrew Robinson      =3D=3D=3D=3D=3D L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D  F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?L Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger=   http://im.yahoo.com    ------------------------------   Date: 30 Aug 2001 06:19:19 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64 0 Message-ID: <9mklt7$ev7$1@pegasus.csx.cam.ac.uk>  , In article <9mjt3d$cbp$1@feed.textport.net>,% Greg Lindahl <lindahl@pbm.com> wrote: 1 >In article <9mjol1$mn6$1@pegasus.csx.cam.ac.uk>, * >Nick Maclaren <nmm1@cus.cam.ac.uk> wrote: > @ >>>If you meant to say "non trivial SMP box", then the answer is, >>>different today. But you didn't say that. >>C >>Origin 3000s go a bit bigger than that, but you may be right that 6 >>the bigger ones are not yet shipping.  I don't know. > > >Unless SGI has changed their plans, the SN IA runs Linux in a, >clustered configuration, not as a huge SMP.  B I didn't say that they did.  Because I can't remember exactly whatE I have been told in public and what under NDA, I cannot give figures, C but I can assure you that SGI intend to support more than 4 Itanium C CPUs as a single SMP node in their clusters.  And they have said so 
 in public.  B Which is different from saying that they will support as many CPUsA as they support with MIPS chips, of course.  More than 4 does not  mean 512 :-)  D >However, you're off on a tangent. You can get a large IA64 "system"G >today, for one definition of "system". The original poster undoubtedly C >meant a SMP system, and didn't say it. My comment about SMPs was a  >throwaway.   ? And I was responding to the implication that you can't get one. = I think that you can, but you might have to arrange a special = deal with SGI to beta test their Origin 3000s with Itanium; I = really can't remember the dates, and couldn't say if I could!   < This is only a nitpick, of course, as I believe that this is@ the ONLY serious Itanium SMP system that will be marketed.  NEC,? Hitachi etc. have a chipset that supports 16-way but, as far ass? I know, have no intention of marketing it.  IBM are rumoured toe. be in the same position, though less publicly.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679e   ------------------------------   Date: 30 Aug 2001 06:21:53 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64a0 Message-ID: <9mkm21$f08$1@pegasus.csx.cam.ac.uk>  = In article <B4kj7.54329$n75.13608013@news4.rdc1.on.home.com>, 1 Yousuf Khan <bbbl67@nospam.yahoo.com.spam> wrote:e8 >"Sarah Warner" <sarahamiee7@yahoo.com> wrote in message; >news:5vgj7.162589$Xr6.910102@news-server.bigpond.net.au...a" >> EPIC is better than RISC, mate. >> >> Do a bit of research. > L >You must be the same person as Smitty, right? Both from Australia, what areM >the chances that there are two complete morons out of the millions that comen >from country?  ? The UK is full of civilised, witty and educated Australians who C left because they couldn't stand the density of the morons in theire native country ....o     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679l   ------------------------------    Date: 30 Aug 2001 02:28:11 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: alpha - ia64 3 Message-ID: <Avf$ztEoQ3o7@eisner.encompasserve.org>   r In article <B4kj7.54329$n75.13608013@news4.rdc1.on.home.com>, "Yousuf Khan" <bbbl67@nospam.yahoo.com.spam> writes:9 > "Sarah Warner" <sarahamiee7@yahoo.com> wrote in messagel< > news:5vgj7.162589$Xr6.910102@news-server.bigpond.net.au..." >> EPIC is better than RISC, mate. >> >> Do a bit of research. > M > You must be the same person as Smitty, right? Both from Australia, what areAN > the chances that there are two complete morons out of the millions that come > from country?S  < What are the chances we can get a little civility on Usenet.  5 "The other guy started it" would be no excuse at all.i   ------------------------------  % Date: Thu, 30 Aug 2001 09:14:40 +0200e3 From: Terje Mathisen <terje.mathisen@hda.hydro.com>  Subject: Re: alpha - ia64r- Message-ID: <3B8DE7E0.6815693F@hda.hydro.com>V   Nick Maclaren wrote: > ? > In article <B4kj7.54329$n75.13608013@news4.rdc1.on.home.com>, 3 > Yousuf Khan <bbbl67@nospam.yahoo.com.spam> wrote:F: > >"Sarah Warner" <sarahamiee7@yahoo.com> wrote in message= > >news:5vgj7.162589$Xr6.910102@news-server.bigpond.net.au...l$ > >> EPIC is better than RISC, mate. > >> > >> Do a bit of research. > >rN > >You must be the same person as Smitty, right? Both from Australia, what areO > >the chances that there are two complete morons out of the millions that come: > >from country? > A > The UK is full of civilised, witty and educated Australians whoRE > left because they couldn't stand the density of the morons in theira > native country ....?   Ouch.e  E I assume you've seen the news about the norwegian ship that picked up  483 boat refugees?  D The _australian_ coast guard asked them to assist an overloaded boatB that was about to sink, and the norwegian vessel of course did so.  ; At this point australia turned around and said (against allaF international maritime laws) that the ship could not go to the nearestH harbour (Australian Christmas Island) and offload the same refugees they had been asked to pick up.  5 It is an election year in Australia, but even so! :-(p   Terjen -- O  - <Terje.Mathisen@hda.hydro.com>; Using self-discipline, see http://www.eiffel.com/discipline-@ "almost all programming can be viewed as an exercise in caching"   ------------------------------   Date: 30 Aug 2001 08:36:40 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64g0 Message-ID: <9mktuo$kgh$1@pegasus.csx.cam.ac.uk>  0 In article <9mjp3i$n3r$1@pegasus.csx.cam.ac.uk>,* nmm1@cus.cam.ac.uk (Nick Maclaren) writes:4 |> In article <9mjmtb$i00$1@ausnews.austin.ibm.com>,, |> McCalpin <mccalpin@austin.ibm.com> wrote: |> >> |> >I don't see how increasing the bandwidth is going to help - |> >the SPECfp2000 performance significantly.T |> >@ |> >Consider the MIPS-based systems from SGI.  Doubling the peak; |> >bandwidth, along with a significant (~40%,IIRC) latencynA |> >reduction, improved the sustained bandwidth by nearly 2x, butiB |> >only improved the uniprocessor SPECfp2000 number by about 20%. |>  C |> I was under the impression that the Itanium was fairly seriouslycE |> limited by bandwidth to cache, which is a rather different problemaD |> to the one resolved by going from the Origin 2000 to Origin 3000.C |> But I could well be wrong, as my information is second-hand, ande# |> I haven't checked it personally.0  A I was misremembering.  Upon checking, I have reminded myself thate@ what I was told wasn't that simple.  But, please note that it isB NOT based on hands-on testing, and I should VERY much like someone? competent to investigate real Itania and tell me what is reallyr	 going on!e  A The L3 cache can transfer 16 bytes every clock cycle, though I amoB not absolutely sure if the cycle is 266 MHz or 733/800 MHz (givingB either 12.8 or 4.26 GB/sec), and it has a 21/24 cycle latency.  SoC nothing unusual and, as usual, prefetching and parallel streams areM@ critical for performance.  And we know that the IA-64 in general@ and the Itanium in particular has a lot of fancy logic for that.  < What my sources indicated that the prefetching logic did notA work in real codes on the Itanic (though it did in simple tests),I= that it was likely that the major revamp in early 2000 was at < attempt to correct this, that all evidence is that it failed= and the problem needs a complete redesign to correct.  So thee@ EFFECTIVE bandwidth to L3 cache is little more than that to mainB memory - except for the simplest and cleanest codes, like STREAMS.  A Now, I cannot confirm any of this, but it is obviously plausible.3< If it is so, then the McKinley has the potential to do a lot< better on SpecFP.  If it is hooey, then there is less scope.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679w   ------------------------------  % Date: Thu, 30 Aug 2001 09:52:27 +0100U( From: Nic Clews <sendspamhere@127.0.0.1> Subject: Re: alpha - ia64 ) Message-ID: <3B8DFECB.22A0C9B8@127.0.0.1>h   Sarah Warner wrote:o > ! > EPIC is better than RISC, mate.i >  > Do a bit of research.c   Sarah,   Ignore the witless comments.  C The only 'research' I have been pointed to really are Paul DeMone'se@ articles, who hates Intel with a vengance (opinion), not exactlyE balanced. Can you provide references, either web or other material. IeF have an open mind, and I'd also appreciate you posting here, perhaps a= summary of what you feel the strengths of EPIC are over RISC.a  & (Please also wear flameproof clothes).   -- p( Regards, Nic Clews CSC Computer Sciences nclews at csc dot coms   ------------------------------  % Date: Thu, 30 Aug 2001 11:12:01 +010006 From: Christian Bau <christian.bau@isltd.insignia.com> Subject: Re: alpha - ia64 2 Message-ID: <3B8E1171.65631D7D@isltd.insignia.com>   Sarah Warner wrote:n > ! > EPIC is better than RISC, mate.d >  > Do a bit of research.   H Most likely that is exactly _why_ people laugh when someone claims "EPICH is better than RISC". EPIC is quite useless unless you through the E andC the P away. And if you do that then it is just a very clumsy way ofd doing RISC.    ------------------------------  + Date: Thu, 30 Aug 2001 10:26:14 +0000 (UTC)p/ From: Sander Vesik <sander@haldjas.folklore.ee>n Subject: Re: alpha - ia64a2 Message-ID: <999167181.421529@haldjas.folklore.ee>  6 In comp.arch Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:. > In article <9mjlui$2jl$1@feed.textport.net>,' > Greg Lindahl <lindahl@pbm.com> wrote:f4 >>In article <999118937.563062@haldjas.folklore.ee>,3 >>Sander Vesik  <sander@haldjas.folklore.ee> wrote:0 >>G >>>> Nobody wants to run GUIs, databases, network management and thingsL% >>>> like that on IA-64, do they? :-)7 >>>02 >>>Can I buy a non-trivially sized IA64 somewhere? >>D >>Sure, you can buy a 2 or 4 cpu building block, and cluster them as >>large as you like. >>? >>If you meant to say "non trivial SMP box", then the answer isg+ >>different today. But you didn't say that.u  C > Origin 3000s go a bit bigger than that, but you may be right thatw6 > the bigger ones are not yet shipping.  I don't know.  G Well, SGI doesn't even mention IA64 on the server pages so far. So it'si/ not 'not shipping' but rather 'not announced'. a  
 > Regards, > Nick Maclaren,, > University of Cambridge Computing Service,@ > New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. > Email:  nmm1@cam.ac.uk1 > Tel.:  +44 1223 334761    Fax:  +44 1223 334679M   -- l 	Sander    +++ Out of cheese error +++t   ------------------------------   Date: 30 Aug 2001 10:36:44 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64t0 Message-ID: <9ml4vs$qa6$1@pegasus.csx.cam.ac.uk>  2 In article <999167181.421529@haldjas.folklore.ee>,1 Sander Vesik <sander@haldjas.folklore.ee> writes:t |> oF |> > Origin 3000s go a bit bigger than that, but you may be right that9 |> > the bigger ones are not yet shipping.  I don't know.y |> aJ |> Well, SGI doesn't even mention IA64 on the server pages so far. So it's2 |> not 'not shipping' but rather 'not announced'.   > Yes, that is right.  They decided that it was a bit late to beA worth going in to full release, but I recall them being available0? if you ask for them specially.  I am sorry, but I really cannott? remember the details and it is, of course, possible that I havegB misremembered completely about their availability.  You would have. to ask SGI directly to get the correct answer.  > If they AREN'T available, then there are definitely no serious= SMP systems using the Itanium, even for testing, and won't bei> any until the McKinley.  There are certainly some in-house, in? at least SGI, NEC/Hitachi and I believe IBM, so the claims made2< about Itanium Linux scalability above 4 CPUs aren't entirely+ theoretical.  Just not easily checkable :-(b     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  + Date: Thu, 30 Aug 2001 10:33:58 +0000 (UTC)t/ From: Sander Vesik <sander@haldjas.folklore.ee>e Subject: Re: alpha - ia64 2 Message-ID: <999167645.480391@haldjas.folklore.ee>  2 In comp.arch Greg Lindahl <lindahl@pbm.com> wrote:2 > In article <9mjol1$mn6$1@pegasus.csx.cam.ac.uk>,+ > Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:b  @ >>>If you meant to say "non trivial SMP box", then the answer is, >>>different today. But you didn't say that. >>C >>Origin 3000s go a bit bigger than that, but you may be right thati6 >>the bigger ones are not yet shipping.  I don't know.  ? > Unless SGI has changed their plans, the SN IA runs Linux in a - > clustered configuration, not as a huge SMP.m  E > However, you're off on a tangent. You can get a large IA64 "system"lH > today, for one definition of "system". The original poster undoubtedlyD > meant a SMP system, and didn't say it. My comment about SMPs was a > throwaway.  D Right. Saying that 'large system' also covers 'large cluster' is notE really productive or possibly even honest - by the same notion, I cantE get a 1024P Mac - just get 512 of the dual processor ones and run PVM  under MacOSX on all of them. c   > g    --   	Sanders   +++ Out of cheese error +++,   ------------------------------  % Date: Thu, 30 Aug 2001 21:22:47 +1000o  From: Sean Case <gsc@zip.com.au> Subject: Re: alpha - ia64 > Message-ID: <gsc-CC5713.21224730082001@nostril.pacific.net.au>  2 In article <999118937.563062@haldjas.folklore.ee>,1  Sander Vesik <sander@haldjas.folklore.ee> wrote:v  1 > Can I buy a non-trivially sized IA64 somewhere?-  4 Maybe not right away, but you can see a demo of one:  9 http://www.unisys.com/news/releases/2001/aug/08288049.aspm  7 Disclaimer: I work for Unisys, but not on these things.3  	 Sean Case.   -- e. Sean Case                       gsc@zip.com.au  / Code is an illusion.  Only assertions are real.    ------------------------------  % Date: Thu, 30 Aug 2001 13:35:50 +0200e* From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: alpha - ia64I/ Message-ID: <3B8E2516.3080801@brussels.sgi.com>n   Sander Vesik wrote:d > 1 > Can I buy a non-trivially sized IA64 somewhere?d > F He *was* talking about McKinley. And while you can't buy a non-trivial1 IA64 machine, that doesn't mean they don't exist..  A Given the current IA32 performance on integer codes, I can assure = you that people *will* want to run databases on any successors that's  # -*only* slightly slower than P4 [1]a -likely to stay around for longt -can address 64 bits.e  G [1] to base myself on Nick's extrapolation, regardless of its validity.n -- h? <these messages express my own views, not those of my employer>X) Alexis Cousein				Senior Systems Engineerh. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------    Date: 30 Aug 2001 07:39:32 -0400# From: Chris Morgan <cm@mihalis.net>g Subject: Re: alpha - ia64t/ Message-ID: <87ae0hojyj.fsf@tweety.mihalis.net>=  9 dsiebert@excisethis.khamsin.net (Douglas Siebert) writes:   @ > >I believe Intel demonstrated a P4 at 3.5Ghz during IDF today. >  > G > Yes, it was their usual "pick the fastest chip we have in the lab andhH > use liquid nitrogen to cool it" demo.  I don't know that it was liquidH > nitrogen, but it has been reported by several sources it was _not_ air	 > cooled.   D I wonder if that chip was the same core design as currently shippingD models - they have some "double-pumped" circuits, right? I make that9 7GHz. I guess they're the kings of the overclocking hill!. -- rH Chris Morgan <cm at mihalis.net>                  http://www.mihalis.net        Temp sig. - Enquire within   ------------------------------  % Date: Thu, 30 Aug 2001 13:42:45 +0200a* From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: alpha - ia64 / Message-ID: <3B8E26B5.8070106@brussels.sgi.com>g   Brig Campbell wrote:C >>Origin 3000s go a bit bigger than that, but you may be right thats6 >>the bigger ones are not yet shipping.  I don't know. >> >> > G > In our case, "shipping" with Itanium is based on the availablilty of i< > the operating system, which in our case is Windows.NET.     H Did I hear "Windows" and "non-trivial SMP sizes[1]" in one sentence ;) ?  F [1] That run, and produce good AIM7/9,specfp_rate numbers and Spec OMPG numbers, and perhaps NAS Parallel bench scores, not where the kernel isi! just claiming to manage the CPUs.d     -- .? <these messages express my own views, not those of my employer>n) Alexis Cousein				Senior Systems Engineer . SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  % Date: Thu, 30 Aug 2001 13:47:40 +0200I* From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: alpha - ia64 / Message-ID: <3B8E27DC.3050603@brussels.sgi.com>n   Nick Maclaren wrote:D > I didn't say that they did.  Because I can't remember exactly whatG > I have been told in public and what under NDA, I cannot give figures, E > but I can assure you that SGI intend to support more than 4 ItaniumnE > CPUs as a single SMP node in their clusters.  And they have said sos > in public. > D "Support" (i.e. sells) is also different from "works". The supportedC sizes will certainly depend more on the ability of the OS to make al@ decent job of managing lots of CPUs giving useful throughput (orF turnaround times) for applications, and there's good reason to believe@ the sizes that "work" are going to be larger than those that are
 supported.  @ And, of course, much depends on what you call an SMP or close toF an SMP. Is a T3E (with lots of kernels, but the possibility to harness* many CPUs in one application) a quasi-SMP? -- b? <these messages express my own views, not those of my employer>r) Alexis Cousein				Senior Systems Engineero. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------   Date: 30 Aug 2001 11:57:16 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64.0 Message-ID: <9ml9ms$14v$1@pegasus.csx.cam.ac.uk>  / In article <3B8E27DC.3050603@brussels.sgi.com>,6, Alexis Cousein <al@brussels.sgi.com> writes: |> Nick Maclaren wrote:aG |> > I didn't say that they did.  Because I can't remember exactly what<J |> > I have been told in public and what under NDA, I cannot give figures,H |> > but I can assure you that SGI intend to support more than 4 ItaniumH |> > CPUs as a single SMP node in their clusters.  And they have said so |> > in public.  |> > SG |> "Support" (i.e. sells) is also different from "works". The supportedaF |> sizes will certainly depend more on the ability of the OS to make aC |> decent job of managing lots of CPUs giving useful throughput (or?I |> turnaround times) for applications, and there's good reason to believebC |> the sizes that "work" are going to be larger than those that aree
 |> supported.   @ Quite.  And this is an area where responsible vendors (like SGI)? will support different sizes for different users - for example,n? a research customer who wants to develop applications for large2? SMP systems is a different matter from a commercial transaction  user.1  C |> And, of course, much depends on what you call an SMP or close topI |> an SMP. Is a T3E (with lots of kernels, but the possibility to harnessc- |> many CPUs in one application) a quasi-SMP?.  @ Not in my book, no.  No more than a Hitachi SR2201 was, and that= is even more closely integrated than a T3E.  No transparently7 shared memory.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679e   ------------------------------  % Date: Thu, 30 Aug 2001 12:48:47 +0100t0 From: andrew harrison <andrew.nospam@uk.sun.com> Subject: Re: alpha - ia64a* Message-ID: <3B8E281F.27767847@uk.sun.com>   Larry Kilgallen wrote: > _ > In article <3B8CECB0.735057C8@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:j > >R > > Bill Todd wrote: > >>6 > >> "Smitty" <someone@microsoft.com> wrote in message? > >> news:yRXi7.159620$Xr6.898841@news-server.bigpond.net.au...m > >> > >> ... > >>J > >> > The EPIC technology used in the IA-64 Itanium's is superior to RISC > >> > architechure. > >>P > >> Thanks:  it's really a relief to have an authoritative source put an end to > >> all this speculation. > >> > >fA > > Now we know where Compaqs assertion that IA64 would be betterB< > > than Alpha comes from. What a relief, everyone can sleep@ > > easily and you can stop asking Compaq to explain themselves. > A > Has anyone else noticed what an Alpha fan Andrew has become nowR) > that Compaq says their future is IA64 ?n    4 I always thought that the Alpha was a well designed 4 high performance CPU, depending on timing sometimes ) the highest performing CPU sometimes not.?  8 I have also always thought that Digital and subsequently? Compaq have done a terrible job of providing a balanced system  * design for systems using Alpha processors.  7 There have been a few exceptions, the ES40 for example.l  @ And it isn't just poor memory and I/O subsystems as exemplified A by the WildFire its was also the Alpha workstations particularly d= running OpenVMS were hampered because of lack of support for o* high performance 3D graphics accelerators.   -- . Andrew Harrisond Enterprise IT Architect.   ------------------------------  % Date: Thu, 30 Aug 2001 15:09:23 +0200eB From: Christian Simmendinger <christian.simmendinger@debis-sfr.de> Subject: Re: alpha - ia64s+ Message-ID: <3B8E3B03.8080303@debis-sfr.de>a   Nick Maclaren wrote: >> > E > Strictly, this relates more to the coding style than the arithmeticaD > as such, but predictable (and hence optimisable) coding styles are1 > associated with floating-point use, as you say.c > D > The current information about McKinley is interesting, too.  IntelB > have said that it will appear at 1 GHz and be c. 70% faster thanA > the Itanic on SpecInt - which will make it comparable to only a A > 2 GHz Pentium 4 which, by then, should be available in 2.2 GHz.cA > But a factor of 3 more memory bandwidth could mean that it is auE > factor of 2 faster on SpecFP, which would make it a most impressive  > HPC chip.s  2 Hm - well i mentioned this in a different thread -7 McKinley seems to be heading into a familiar direction.e3 Strange direction though: Hitachi SR8000 direction. < bandwidth to main memory (8 cpu SR8000 SMP node) of 32 GB/s,A 128 fp (rotating) registers, strong emphasis on prefetch/preload,i   etc. ( a lot of etc.)i  > I've never run a SpecFP on the thing, but i'd guess you'll see# the most imbalanced SpecFP to date.l  < McKinley will probably do a little better due to it's bigger9 caches/L3 cache. Latency might be better as well - dunno.n   > D > Nobody wants to run GUIs, databases, network management and things" > like that on IA-64, do they? :-)   N   	 Christianr   ------------------------------   Date: 30 Aug 2001 12:25:11 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64,0 Message-ID: <9mlbb7$2jc$1@pegasus.csx.cam.ac.uk>  + In article <3B8E3B03.8080303@debis-sfr.de>, D Christian Simmendinger <christian.simmendinger@debis-sfr.de> writes: |> r5 |> Hm - well i mentioned this in a different thread -g: |> McKinley seems to be heading into a familiar direction.6 |> Strange direction though: Hitachi SR8000 direction.? |> bandwidth to main memory (8 cpu SR8000 SMP node) of 32 GB/s, D |> 128 fp (rotating) registers, strong emphasis on prefetch/preload, |>   etc. ( a lot of etc.)  > Yes, and that is precisely why I said back in 1994/5 that theyA would have major trouble with the optimisation.  Those techniques,@ work, no doubt about it, but need the predictable codes that are0 fairly common in HPC and fairly rare outside it.  A |> I've never run a SpecFP on the thing, but i'd guess you'll see.& |> the most imbalanced SpecFP to date.  ; Naah.  Try a vector machine.  I never ran it on the HitachiS> S-3600, but that was a machine that really DID run at anywhere@ between 10 MFlops and 1.75 GFlops depending on the coding style!  ? |> McKinley will probably do a little better due to it's biggerl< |> caches/L3 cache. Latency might be better as well - dunno.  < Smaller L3 cache, I believe, but the latency should be a lot better.C     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679a   ------------------------------  % Date: Thu, 30 Aug 2001 13:42:43 +0100b6 From: Christian Bau <christian.bau@isltd.insignia.com> Subject: Re: alpha - ia64,2 Message-ID: <3B8E34C3.B52A714F@isltd.insignia.com>   Chris Morgan wrote:  > ; > dsiebert@excisethis.khamsin.net (Douglas Siebert) writes:e > B > > >I believe Intel demonstrated a P4 at 3.5Ghz during IDF today. > >- > > I > > Yes, it was their usual "pick the fastest chip we have in the lab anduJ > > use liquid nitrogen to cool it" demo.  I don't know that it was liquidJ > > nitrogen, but it has been reported by several sources it was _not_ air > > cooled.  > F > I wonder if that chip was the same core design as currently shippingF > models - they have some "double-pumped" circuits, right? I make that; > 7GHz. I guess they're the kings of the overclocking hill!t  B If you count that way, you should also tell us the cycle count forF shift, integer multiply, fscale (I almost fell off my chair when I saw that one) after doubling them.   ------------------------------  % Date: Thu, 30 Aug 2001 16:26:52 +0200aB From: Christian Simmendinger <christian.simmendinger@debis-sfr.de> Subject: Re: alpha - ia642+ Message-ID: <3B8E4D2C.1080903@debis-sfr.de>d   Nick Maclaren wrote:- > In article <3B8E3B03.8080303@debis-sfr.de>,eF > Christian Simmendinger <christian.simmendinger@debis-sfr.de> writes: > |>  7 > |> Hm - well i mentioned this in a different thread ->< > |> McKinley seems to be heading into a familiar direction.8 > |> Strange direction though: Hitachi SR8000 direction.A > |> bandwidth to main memory (8 cpu SR8000 SMP node) of 32 GB/s,kF > |> 128 fp (rotating) registers, strong emphasis on prefetch/preload, > |>   etc. ( a lot of etc.) > @ > Yes, and that is precisely why I said back in 1994/5 that theyC > would have major trouble with the optimisation.  Those techniqueskB > work, no doubt about it, but need the predictable codes that are2 > fairly common in HPC and fairly rare outside it. > C > |> I've never run a SpecFP on the thing, but i'd guess you'll seep( > |> the most imbalanced SpecFP to date. >  > Naah.  Try a vector machine.  < Okay  - i implicitly excluded (real) vector architectures ;)   > I never ran it on the Hitachi @ > S-3600, but that was a machine that really DID run at anywhereB > between 10 MFlops and 1.75 GFlops depending on the coding style!  5 Try a nec SX5 - keep the 10 - replace 1.75 with ~3.5.a  Then multiply with no. of procs.  A > |> McKinley will probably do a little better due to it's biggerh> > |> caches/L3 cache. Latency might be better as well - dunno. >  > Smaller L3 cache, I believe,   FYI: SR8000 has zero L3 cache.  ! > but the latency should be a lota	 > better.S  
 Think so too.e  	 Christian    ------------------------------  % Date: Thu, 30 Aug 2001 16:48:24 +0200oB From: Christian Simmendinger <christian.simmendinger@debis-sfr.de> Subject: Re: alpha - ia64u+ Message-ID: <3B8E5238.8050502@debis-sfr.de>0   Nick Maclaren wrote:   |>7 > |> Hm - well i mentioned this in a different thread -s< > |> McKinley seems to be heading into a familiar direction.8 > |> Strange direction though: Hitachi SR8000 direction.A > |> bandwidth to main memory (8 cpu SR8000 SMP node) of 32 GB/s,eF > |> 128 fp (rotating) registers, strong emphasis on prefetch/preload, > |>   etc. ( a lot of etc.) > @ > Yes, and that is precisely why I said back in 1994/5 that theyC > would have major trouble with the optimisation.  Those techniquestB > work, no doubt about it, but need the predictable codes that are2 > fairly common in HPC and fairly rare outside it. > 1 I'm under the impression that the Titanic startedeA out with way more equipment than those 256 (rotating) registers ?:< And yet - judging by what i've seen, this is the thing which? drives the ship. The rest of the engine somehow seems wrecked ?1    : If they don't get it working real quick McKinley will find( itself in unknown (and unwanted) waters.    6 But probably they will. This is Intel ($$$) after all.    	 Christianl   ------------------------------   Date: 30 Aug 2001 13:24:15 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64n0 Message-ID: <9mlepv$5fv$1@pegasus.csx.cam.ac.uk>  + In article <3B8E4D2C.1080903@debis-sfr.de>, D Christian Simmendinger <christian.simmendinger@debis-sfr.de> writes: |> >" |> > I never ran it on the HitachiC |> > S-3600, but that was a machine that really DID run at anywhereuE |> > between 10 MFlops and 1.75 GFlops depending on the coding style!e |> y8 |> Try a nec SX5 - keep the 10 - replace 1.75 with ~3.5.# |> Then multiply with no. of procs.t  A Does a SX5 really drop to 10 MFlops (NOT Gflops)?  I thought thatt" it was faster as a scalar machine.  D |> > |> McKinley will probably do a little better due to it's biggerA |> > |> caches/L3 cache. Latency might be better as well - dunno.s |> > i! |> > Smaller L3 cache, I believe,g |> 2! |> FYI: SR8000 has zero L3 cache.   < I thought that you meant relative to the Itanic.  The SR8000= is close to a cacheless design, when used as intended, as was- the SR2201.,     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679S   ------------------------------  % Date: Thu, 30 Aug 2001 10:11:44 -0400a- From: daytripper <day_trippr@REMOVEyahoo.com>w Subject: Re: alpha - ia64o8 Message-ID: <6bisot8p9idqnghos4dn23b8pctqjvdrlh@4ax.com>  N On Thu, 30 Aug 2001 12:48:47 +0100, andrew harrison <andrew.nospam@uk.sun.com> wrote:5 >I always thought that the Alpha was a well designed o5 >high performance CPU, depending on timing sometimes -* >the highest performing CPU sometimes not. >09 >I have also always thought that Digital and subsequentlyo@ >Compaq have done a terrible job of providing a balanced system + >design for systems using Alpha processors.  > 8 >There have been a few exceptions, the ES40 for example.   <blush> Thank you!   /daytripperu   ------------------------------  % Date: Thu, 30 Aug 2001 18:44:26 +0200.B From: Christian Simmendinger <christian.simmendinger@debis-sfr.de> Subject: Re: alpha - ia64w+ Message-ID: <3B8E6D6A.8000106@debis-sfr.de>s   Nick Maclaren wrote: > C > Does a SX5 really drop to 10 MFlops (NOT Gflops)?  I thought thate$ > it was faster as a scalar machine.   True - in general - C - if the compiler recognizes this is in fact a scalar part of code. G If otoh the compiler vectorizes over a loop with unknown length and the ' vector length happens to be short .....-     > F > |> > |> McKinley will probably do a little better due to it's biggerC > |> > |> caches/L3 cache. Latency might be better as well - dunno.o > |> > w# > |> > Smaller L3 cache, I believe,t > |> m# > |> FYI: SR8000 has zero L3 cache.  > > > I thought that you meant relative to the Itanic.  The SR8000? > is close to a cacheless design, when used as intended, as was 
 > the SR2201.    Uhm -dK The SR8000 actually relies quite a bit on cache - even if the (L2) cache is F fairly small - 8x128kb. For indirect access the compiler prefetches a 	 cacheline I twice the latency ahead - and loads into register one time latency ahead.e$ (works pretty well for long vectors)  . Moreover bandwidth to cache is 32 bytes/cycle.2 Bandwidth to main memory is 'just' 16 bytes/cycle.0 In order to saturate the two muladds you need to block the data in cache.    	 Christian-   ------------------------------   Date: 30 Aug 2001 15:18:34 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia6460 Message-ID: <9mllga$b3s$1@pegasus.csx.cam.ac.uk>  p In article <3B8E6D6A.8000106@debis-sfr.de>, Christian Simmendinger <christian.simmendinger@debis-sfr.de> writes: |> Nick Maclaren wrote:d |> > oF |> > Does a SX5 really drop to 10 MFlops (NOT Gflops)?  I thought that' |> > it was faster as a scalar machine.  |>   |> True - in general -F |> - if the compiler recognizes this is in fact a scalar part of code.J |> If otoh the compiler vectorizes over a loop with unknown length and the* |> vector length happens to be short .....  > Oh, in THAT case, the S-3600 was down in the 10 KFlop area :-)  < The factor of over 100 was between optimised scalar code and= long vectors.  What was impressive was the proportion of peak = that could be obtained by just compiling clean code with full-8 optimisation - no system-dependent changes.  Often 75%+.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679l   ------------------------------  + Date: Thu, 30 Aug 2001 16:14:43 +0000 (UTC) 7 From: dsiebert@excisethis.khamsin.net (Douglas Siebert)a Subject: Re: alpha - ia64i+ Message-ID: <9mlopj$kfu$1@sword.avalon.net>v  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  @ >|> McKinley will probably do a little better due to it's bigger= >|> caches/L3 cache. Latency might be better as well - dunno.j  = >Smaller L3 cache, I believe, but the latency should be a lotu >better.    F Not all that much smaller.  IIRC, Itanium comes with either 2MB or 4MBE external L3.  McKinley will come with 1.5MB and 3MB of on chip L3, soeC while it is smaller, I'm sure it'll be more than made up for by the(F greatly reduced latency.  Its successor (Deerfield or Madison, I can'tF keep the codenames straight) done in .13u will double those L3 caches.   --H Douglas Siebert                          dsiebert@excisethis.khamsin.net  M I have discovered a remarkable proof which this .sig is too small to contain!0   ------------------------------  % Date: Thu, 30 Aug 2001 19:48:25 +0200RB From: Christian Simmendinger <christian.simmendinger@debis-sfr.de> Subject: Re: alpha - ia646' Message-ID: <3B8E7C69.509@debis-sfr.de>l   Nick Maclaren wrote: > |> N > |> True - in general -H > |> - if the compiler recognizes this is in fact a scalar part of code.L > |> If otoh the compiler vectorizes over a loop with unknown length and the, > |> vector length happens to be short ..... > @ > Oh, in THAT case, the S-3600 was down in the 10 KFlop area :-) >    Awwwww. You win ;-)>C But this is one of those problems where you need a run time jump torH the scalar / vector-pipelined version and i have yet to stumble across a3 compiler which gets this done in convincing fashiono  	 Christianv   ------------------------------   Date: 30 Aug 2001 17:14:21 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64g0 Message-ID: <9mls9d$gk6$1@pegasus.csx.cam.ac.uk>  ' In article <3B8E7C69.509@debis-sfr.de>,nD Christian Simmendinger  <christian.simmendinger@debis-sfr.de> wrote: >Nick Maclaren wrote:  >> |>  >> |> True - in general -lI >> |> - if the compiler recognizes this is in fact a scalar part of code.cM >> |> If otoh the compiler vectorizes over a loop with unknown length and the - >> |> vector length happens to be short .....s >> eA >> Oh, in THAT case, the S-3600 was down in the 10 KFlop area :-)t >) >Awwwww. You win ;-)D >But this is one of those problems where you need a run time jump toI >the scalar / vector-pipelined version and i have yet to stumble across a 4 >compiler which gets this done in convincing fashion  E Our experience of Hitachi's compilers (both on the S-3600 and SR2201)lA was that it was one of the better in this respect, and its choice2@ of methods wasn't too bad.  It did do a run-time selection, whenB necessary, and the split point was rarely completely crazy (though often far from optimal).  ? However, if your code was complex, then the compilers certainly > got confused and often did the wrong thing - right answer, butD wrong performance.  I doubt that it is a completely soluble problem.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  % Date: Thu, 30 Aug 2001 13:58:33 -0400e' From: "Bill Todd" <billtodd@foo.mv.com>a Subject: Re: alpha - ia64c( Message-ID: <9mlur9$qok$1@pyrite.mv.net>  5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in messageA# news:3B8DFECB.22A0C9B8@127.0.0.1...o > Sarah Warner wrote:y > >y# > > EPIC is better than RISC, mate.t > >l > > Do a bit of research.  >i > Sarah, >l > Ignore the witless comments.  K Well, when one makes witless assertions, IMO one *should* be prepared for a ) certain lack of respect in the responses.    >dE > The only 'research' I have been pointed to really are Paul DeMone's B > articles, who hates Intel with a vengance (opinion), not exactly > balanced.i  J Certainly as balanced as your own opinions appear to be, I'd say.  But theJ main reason Paul's articles have been referred to is that they're the mostJ readily-accessible information available:  you've had ample opportunity toL research other sources of information that might be more to your liking, and have yet to present any.  F (Oh, by the way, you've also been pointed to a Compaq white paper thatJ explained the relative disadvantages of EPIC in great detail:  forget that one?)   <  Can you provide references, either web or other material. IH > have an open mind, and I'd also appreciate you posting here, perhaps a? > summary of what you feel the strengths of EPIC are over RISC.t  D Such references would be welcomed even by those of us who are highlyJ skeptical of EPIC's performance potential, since Intel has been remarkablyJ chary about providing any details of why EPIC's long-term future should beE expected to be much more impressive than its present (especially when K compared with the kinds of future features and the performance potential of ) each that the Alpha road maps presented).    >,( > (Please also wear flameproof clothes).  I They'll only be necessary if that summary of perceived strengths is *not*rB accompanied by supporting evidence of a more authoritative nature.   - bill   >- > --* > Regards, Nic Clews CSC Computer Sciences > nclews at csc dot comg   ------------------------------  % Date: Thu, 30 Aug 2001 16:12:28 +0100c( From: Nic Clews <sendspamhere@127.0.0.1>0 Subject: Re: Alpha ECU - Does it work from a CD?) Message-ID: <3B8E57DC.F642237F@127.0.0.1>i   Steve Reece wrote: >  > You mean like :a   Don't call us.   - results so far -  6 We've played around a little with an Alphaserver 1000.  ; Brought it up into ARC, then in the boot menu to the Run...a  6 For the program, we put in: scsi(0)cdrom(4)fdisk(0)\cf  E (Explanation: This came from the device config in a different part oftB the ARC menu. SCSI board 0, ID 4, partition 0, root level, cf.exe)  6 It beings up CF from the CD, then baulks with an error  " ERROR: Can't find file \SERIAL.TXT  F ...after the floppy light pulses. So it appears that a:\ is hard-coded	 in CF.EXE<E If the floppy is in place, it runs the program from CD, then picks upm the files from the floppy.  ? I'm rummaging through it [CF] in dump. There's an A: as well as> \serial.TXTm  C It's probably a non starter, so we've opted to buy an RX23 with the: additional PCI cage.  
 Thanks anywayh -- a( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comn   ------------------------------  % Date: Thu, 30 Aug 2001 11:51:47 -0400c4 From: John Malmberg <Malmberg@dskwld.zko.dec.compaq>0 Subject: Re: Alpha ECU - Does it work from a CD?4 Message-ID: <3B8E6113.3080704@dskwld.zko.dec.compaq>  = > ...after the floppy light pulses. So it appears that a:\ isC > hard-coded in CF.EXE  ? IIRC: a: is not hardcoded in the ARC menu, it is an environmentl< variable that can be set through the ARC menu item to update the environment variables.  5 I do not now how to do this with the newer Alpha Bios  consoles though.   > E > It's probably a non starter, so we've opted to buy an RX23 with the  > additional PCI cage.  9 A supported configuration is probably better than a hack.    -Johni Personal Opinion Only  Malmberg@dskwld.zko.dec.compaq   ------------------------------  % Date: Thu, 30 Aug 2001 09:03:09 -0400e2 From: "Sue Skonetski" <susan.skonetski@compaq.com>Y Subject: And yet another reason to come to CETS - Complimentary OpenVMS V7 and Tru64 UNIX+2 Message-ID: <UPqj7.993$bB1.45138@news.cpqcorp.net>   Folks,  G I just got this via email,  this maybe useful for folks in your groups.    suei      8 Complimentary OpenVMS V7 and Tru64 UNIX V5 Exam Vouchers  F Compaq's High Performance Server Group is offering a limited number ofH complimentary exam vouchers to certificants who wish to update or expandI their current Tru64 UNIX or OpenVMS certifications. The vouchers are alsoeC available to new candidates who do not hold a Tru64 UNIX or OpenVMS H certification. Interested Compaq Accredited Professionals who attend theE CETS2001 event in Anahiem, September 10-14, should stop by the Compaq_B Accredited Professional Hospitality Suite to obtain a voucher. NewC candidates should stop by the information table located outside the H hospitality suite. IT professionals not attending the CETS2001 event canH contact Roland Toscano (Roland.Toscano@Compaq.com) to request a voucher.F Each voucher is good for one exam, and must be redeemed at a PrometricF Testing Center by the expiration date printed on the voucher. Only oneG voucher per individual, while supplies last. The following vouchers areiK available. Visit http://www.compaq.com/certification/ for more detail aboutg& the applicable certification programs.  0 Exam Title Prometric Exam Number Expiration Date  / OpenVMS System Administration 010-651 3-31-2002tF Compaq Tru64 UNIX V5.0 System Administration, Support, and Integration 010-601 3-31-2002e  F Compaq Tru64 UNIX V5 Advanced Administration, Support, and Performance 010-702 3-31-2002c  = Compaq Tru64 UNIX V5 Network Administration 010-703 6-31-2002m  L Compaq Tru64 UNIX V5 TruCluster Implementation and Support 010-704 6-31-2002   ------------------------------    Date: 30 Aug 2001 08:50:30 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)9Y Subject: Re: And yet another reason to come to CETS - Complimentary OpenVMS V7 and Tru64 k3 Message-ID: <7AkEczDjcH+Q@eisner.encompasserve.org>h  g In article <UPqj7.993$bB1.45138@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:b  : > Complimentary OpenVMS V7 and Tru64 UNIX V5 Exam Vouchers > H > Compaq's High Performance Server Group is offering a limited number ofJ > complimentary exam vouchers to certificants who wish to update or expandK > their current Tru64 UNIX or OpenVMS certifications. The vouchers are also E > available to new candidates who do not hold a Tru64 UNIX or OpenVMS1 > certification.  C Is this instead of the onsite testing that was formerly scheduled ?a  E (This is _not_ a question I expect Sue to answer, but perhaps someone D like Jeff Killeen will chime in here.  But maybe ther is nobody like Jeff Killeen :-).e   ------------------------------  % Date: Thu, 30 Aug 2001 17:58:37 +0100t3 From: Adrian Birkett <abirkett@unnecessary.csc.com> . Subject: Re: C language functionality changed?3 Message-ID: <3B8E70BD.B98FAC53@unnecessary.csc.com>s  G Thanks for the example, I shall now go away and try to understand it !!.  
 Kind regards,a   Adet   ------------------------------  % Date: Thu, 30 Aug 2001 08:33:35 -0400K2 From: "Sue Skonetski" <susan.skonetski@compaq.com>( Subject: Re: Comp.os.VMS session at CETS2 Message-ID: <9oqj7.991$bB1.45199@news.cpqcorp.net>  J Just a point of clarity - Marks session is open to everyone, the reception" on Tuesday night is by invitation.  B You can get your invitation in the campground or in Marks session.   sue4   "a   ------------------------------   Date: 30 Aug 2001 06:35:37 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)D Subject: Re: Compiled Languages (Was: e: My VMS Wish List (features)0 Message-ID: <9mkmrp$fet$1@pegasus.csx.cam.ac.uk>  3 In article <U9xSyJ1zz8tt@eisner.encompasserve.org>,n, Rob Young <young_r@encompasserve.org> wrote:\ >In article <3B8DAE36.15F3721E@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:   [ A recommendation for Python ]   @ My typically jaundiced comment is that Python is Perl written byA a computer scientist rather than a mad hacker.  I use it, largely < because it has (a) a specification and (b) pretty watertightC diagnostics.  In complete contradiction to Perl, if it isn't right,k it is wrong.  C My guess is that VMS people would find it philosophically much moreu to their tastes than Perl.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679b   ------------------------------  % Date: Thu, 30 Aug 2001 09:56:47 -0500TC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>yD Subject: Re: Compiled Languages (Was: e: My VMS Wish List (features)I Message-ID: <craig.berry-E1365B.09564730082001@newsrump.sjc.telocity.net>y  3 In article <U9xSyJ1zz8tt@eisner.encompasserve.org>,>-  young_r@encompasserve.org (Rob Young) wrote:a  > > In article <3B8DAE36.15F3721E@fsi.net>, "David J. Dachtera" ! > <djesys.nospam@fsi.net> writes:  > > Larry Kilgallen wrote: > >  > > o they're compiled% > > o unless you write Macro32, $$$$$ J > > o too many wheels to re-invent when DCL already has many conveniences. > >  > > > 	One fairly new wrinkle to this.  Perl is a pain to compile.? > 	I don't get a good answer about "why not compile it?" when I+B > 	ask around.  One fellow that is a Perl geek mentioned something- > 	about runtime issues.  He doesn't compile.a   What do you mean by compile?  <      1.) Pre-compile a script to opcodes each time it is runA      2.) Save an opcode version of a script that can be run later:)      3.) Create native binary executables.  G Perl does #1 by default and has support for various flavors of #2.  In h: addition to saving its own bytecodes, there are C and JVM G cross-compilers at the experimental stage.  The Apache module mod_perl tD does a version of #2 in that it compiles a script the first time it G sees it and subsequently runs the compiled version, but it never saves  H the compiled version to a file.  Any C program can do the same thing by + embedding a Perl interpreter within itself.-  D But the question is really "why compile it?"  If the answer is, the B start-up time is measurably impacting performance to a noticeable D level, the sure, go ahead and compile it.  Usually the milliseconds 
 don't matter.o  9 > 	I'm not interested in Perl.  The syntax is insanity.  a  E The basic syntax is pretty much identical to any other language that eH has curly braces and semicolons.  There are plenty of weird features, I G grant you, but you don't have to use any more of them than you want to.t  F Now if we had regular expressions and associative arrays in DCL... ;-)   ------------------------------   Date: 30 Aug 2001 15:26:03 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)D Subject: Re: Compiled Languages (Was: e: My VMS Wish List (features)0 Message-ID: <9mllub$bh4$1@pegasus.csx.cam.ac.uk>  I In article <craig.berry-E1365B.09564730082001@newsrump.sjc.telocity.net>,uE "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com> writes:  |> s< |> > 	I'm not interested in Perl.  The syntax is insanity.   |> 8H |> The basic syntax is pretty much identical to any other language that K |> has curly braces and semicolons.  There are plenty of weird features, I pJ |> grant you, but you don't have to use any more of them than you want to.  ? This is commonly stated, but is completely untrue.  The lack of ? a proper syntactic specifation and thorough checking means that ? you can drop into a fancy syntax by accident, with no hint that0> it is not doing what you intended.  This is one of the reasons< that unused features are NOT harmless in any language unless> they are cleanly separated from the parts of the language that you are intending to use.i  ; My first Perl program was 20 lines long, and I checked that>= every branch was taken correctly in both paths.  It then gaveh= wrong answers as soon as I ran it on real data, because I hadT> used an incorrect but undiagnosed syntax that just happened to; do what I was expecting in my tests.  Another language withs" similarly evil properties was SAS.  : Now, that was Perl 4, and Perl 5 is better.  But, from all# accounts, not all that much better.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679i   ------------------------------  % Date: Thu, 30 Aug 2001 02:33:26 -0400c' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mkmmd$ri7$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 1 news:4mgj7.1525$jd.297113@typhoon1.gnilink.net...u >04 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9mjteq$aj1$1@pyrite.mv.net...K > > Do you think that lies from a vendor to its customers don't matter, andc > thatC > > repeated, unequivocal, written commitments from a vendor to itst	 customersi > > don't either?h >L# > As I said I look at from softwaree  H You also said "I have yet to see Compaq break any commitments.  I do seeK that there is a huge potential to break commitments but none yet", and when F I called you on it above you (again) refused to address the issue, but) (again) simply attempted to side-step it.t  I So I'll repeat it:  Do you think that lies from a vendor to its customers H don't matter, and that repeated, unequivocal, written commitments from a% vendor to its customers don't either?g  L Don't just repeat yet again that hardware doesn't matter to you:  I think weK all understand that point.  The question is whether you believe that vendor-I integrity and dependability just don't matter in any significant business  sense.   ...n   > > > I really wonderiK > > > Bill if you today are responsible for a large existing code base thatiH > > > would require significant effort to convert to another platform... > >  > > Thank God, no. > C > As I suspected - if one has a large code base, that would requiretL > conversion, this discussion becomes far more grounded in business reality.4 > One would never blow off the issues of conversion.  L I've never blown them off, I just don't see them as a critical impediment ifJ the alternative is to stick with a relationship you really can't depend onK under conditions that already ensure that *some* kind of conversion will be J required in 3 - 4 years' time even if Compaq lives up to its newest set ofJ 'commitments' (which is the best-case scenario; the worst case, of course,L is that Compaq decides to discard VMS as blithely as it did Alpha, or simplyI implodes due to terminal incompetence, either of which could leave you ups( the creek with zero-to-minimal warning).  G My own approach would be to begin planning immediately for the quickest I conversion possible consistent with reasonable cost/effort, and hope thatlI was quick enough to avoid getting screwed (combined with avoiding any and % all *new* commitments to the vendor).,  D But there are certainly others here who *are* responsible for large,I existing code bases and who are also very unhappy with Compaq, and I hopee< they'll help you understand what I don't seem to be able to.   >s: > > But if I were, there's no chance in hell that the nextK > > platform would be provided by Compaq, lacking a death-bed conversion onR > its 	 > > part.  > F > Which again demonstrates a total lack of common sense out of spite -L > re-tooling your IT staff skill set for to deploy on another platform is an > expensive undertaking,  J Are you under the impression that most VMS shops are VMS-only shops?  MineL is that at least a large percentage are already conversant with other viableI platforms, and that while they may appreciate VMS there would be at leastbE some compensating consolidation advantage in eliminating it (platformeG consolidation being something even Compaq should be able to understand,mD though they don't appear very competent when it comes to applying it intelligently).-  J And you keep accusing people of 'spite' as if you had some special insightH into the reasons people have for considering such migration, whereas you@ clearly haven't a clue despite repeated attempts to educate you.   - bill   ------------------------------  % Date: Thu, 30 Aug 2001 13:20:09 +0100P% From: Alan Greig <a.greig@virgin.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <dfasotcfl7katar00gkv2lcni08444tovi@4ax.com>  0 On 29 Aug 2001 17:14:01 +0200, Jan C Vorbrueggen/ <vorbrjz6@sunu513.rz.ruhr-uni-bochum.de> wrote:   ( >Alan Greig <a.greig@virgin.net> writes: >rA >> Having been recently playing with TOPS-20 again under the simhiF >> emulator it;'s amazing just how well even TOPS-20 4.1 (around 1978)A >> stands up against VMS 7.3 from a user interface point of view.a >bK >Honest question: having used TOPS-10, how different is it in this respect,l= >and where do you see VMS's deficiencies compared to TOPS-20?o  E This could get a bit religious but... TOPS-10 was a descendent of the E original DEC timesharing O/S for the PDP-6. As such it predates a loteB of the features usually associated with something like Unix or VMS@ (limited virtual memory support, simple file names and directoryD structure, limited command interpreter, single process per job etc).E But it did have excellent timesharing capabilities, layered products,P" cusps and user written software.    D TOPS-20 grew out of BBN Tenex which was written for the first PDP-10= (KA-10) under a contract to Arpa to write a mainframe ArpanetrD operating system. BBN being Bolt Beranek and Newman of Arpanet fame.: In many ways TOPS-20 was a mainframe superset of Unix withD Arpanet/Internet support built in from 1969!!   The operating systemD was later commercialized by DEC as TOPS-20. A typical TOPS-20 systemF would require more memory than TOPS-10 to handle the same workload butA provided all the bells and whistles of a modern command interfacepB (command completion/recognition, powerful command interpretor withC scriptable extensions (PCL, MIC, .CMD files etc) available. Much ofoD what you might typically do with .COM files in DCL and utilities was= supported directly by the EXEC command processor. For example:; TDIRECTORY would give you a directory sorted by date order,6  C TOPS-20 also supported TOPS-10 code transparent to the user via the'F PA1050 emulator. So you could compile/link/run code containing TOPS-10E system calls and even run TOPS-10 executables directly. Obviously yout could also compile native code!   D One example where I still thinks TOPS-20 beats VMS is in its commandB processor. Being able to give a command to produce a list of files= sorted by date they were last read for instance. Assuring PCLeE extensions was installed then you could use an Algol like language to @ add your own commands. These could then be compiled for speed ofF execution. Filenames by default were upper case but you could prefix aC character with CTRL-V to quote it and allow lower case or any other A character in a filename.  Another point was that most of what VMSo@ provides as distinct executables (DIR, AUTHORIZE, etc) was built> directly into the command processor reducing image activation.  E The Galaxy BATCH/PRINT system and OPR Operator interface was as least-8 as powerful as that possessed by VMS today even in 1980.  ) I could go on but that will do for now.  j     -- Alan   ------------------------------  # Date: Thu, 30 Aug 2001 17:08:23 GMTd& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update5 Message-ID: <bquj7.18$DE4.46353@typhoon2.gnilink.net>i  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9mkmmd$ri7$1@pyrite.mv.net...K > So I'll repeat it:  Do you think that lies from a vendor to its customers J > don't matter, and that repeated, unequivocal, written commitments from a' > vendor to its customers don't either?g  K Bill I don't answer "when did you stop beating your wife" questions.  FirstsE the question has no context or time frame.  Second I am unsure of the-H details you are referring to. Third, and most important, I don't know ifK what you are calling a lie is what I and other reasonable people would callCC a lie.  Being in error is not a lie - telling a lie means providing3H information to you know is false at the time you provide it.  So I won'tK play your game of asking when did you stop beating your wife.  Just because G you said someone lied doesn't mean it is fact and many other reasonableo! people may feel it is not fact...   L > Are you under the impression that most VMS shops are VMS-only shops?  MineG > is that at least a large percentage are already conversant with otheri viableK > platforms, and that while they may appreciate VMS there would be at leastrG > some compensating consolidation advantage in eliminating it (platformnI > consolidation being something even Compaq should be able to understand, F > though they don't appear very competent when it comes to applying it > intelligently).   @ Many I know are effectively VMS only unless one looks at it veryJ simplistically.  The IT professionals who knows the business rules for theA applications running on the VMS servers are only deploying servers applications on VMS.  I Having done platform switches twice it is far more than just learning theeI syntax.  It is taking the IT professionals who have learned your business K and having them deploy your applications on the new platform while learning F the "black art" of how to optimize the application for that new target	 platform.o  J As people have found with high standardized Java code moving from platformA to platform one finds quirks that cause unpredictable application2 performance.   ------------------------------  % Date: Thu, 30 Aug 2001 19:25:57 +0010-% From: paddy.o'brien@zzz.tg.nsw.gov.auk Subject: Re: DCL challenge5 Message-ID: <01K7R8I9U576004JGB@tgmail.tg.nsw.gov.au>n   Didier Morandi wrote:- >  > OHM wrote: > >-@ > > > >> Think about the poor consultants who come behind... :-)) > > >                    ^^^^^^^^^^^^^^^^R > > >y  4 > > I think Didier meant   "unfortunate consultants"A > > Please excuse my compatriot's broken english ... and mine ;-)g >  > Yeman, you're right.@ > I'm having german lessons now, should I have English ones too?  H I did realise what was meant, but *chose* to interprete it differently  F (lovely to play with linguistic ambiguities -- the essence of puns).  J Perhaps I forgot a smilie at the end of the row of carets.  I have little J doubt of Didier's command of English and a native speaker would have used # the same expression in the context.a  L I did not mean to slight your English ability, merely me being frivolous as 8 above.  My apologies if anyone took it as a slur on you.   Regards, Paddy   ------------------------------  % Date: Thu, 30 Aug 2001 11:15:21 -0500lC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com> & Subject: Re: Does MOD_PERL work on VMSI Message-ID: <craig.berry-DDE7C1.11152130082001@newsrump.sjc.telocity.net>y  3 In article <TtjDoR7iucnh@eisner.encompasserve.org>,e;  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:h  L > In article <craig.berry-5622CF.01362315082001@newsrump.sjc.telocity.net>, G > "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com> writes:0 > J > > Hmm.  Perl uses $getjpi to get a list of all your identifiers when it L > > starts up.  I've heard of corruptions in the rights database that cause G > > $getjpi to report that it needs more buffer space than it actually eG > > does, though I've only heard of it leading to cpu-bound loops, not tI > > accvios.  We handle this better in Perl 5.6.0 and later, but I never -K > > had a reproducer myself to be absolutely sure I nailed it.  Thanks for i
 > > the info.u > B > Even if VMS makes outrageous memory demands, it would be good ifA > PERL could make an explicit report of the situation, to aid thez! > reporting of the VMS problem.  o   It does in 5.6.0 and later.o  ! > Perhaps that could be tested by3? > making a temporary modified version of PERL that thought some:? > small amount of buffer space (12 bytes ?) was too much.  OncemC > the error message works, then restore PERL to it's working state.h  0 I did the equivalent of that using the debugger.   > Larry Kilgallena; > not a PERL user, but a big fan of explicit error messagest  1 Explicit enough for ya? (apologies for wrappage):g  I fprintf(stderr, "vms_image_init: $getjpiw refuses to store RIGHTSLIST of s% %u bytes in buffer of %u bytes.\n%s",a9                   rsz, (unsigned long) jpilist[1].buflen,mB                   "Check your rights database for corruption.\n"); exit(SS$_ABORT);   ------------------------------    Date: 30 Aug 2001 12:11:00 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) & Subject: Re: Does MOD_PERL work on VMS3 Message-ID: <xbB0PfBrdS$K@eisner.encompasserve.org>a   In article <craig.berry-DDE7C1.11152130082001@newsrump.sjc.telocity.net>, "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com> writes:t5 > In article <TtjDoR7iucnh@eisner.encompasserve.org>,g= >  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:>   >> Larry Kilgallen< >> not a PERL user, but a big fan of explicit error messages > 3 > Explicit enough for ya? (apologies for wrappage):M > K > fprintf(stderr, "vms_image_init: $getjpiw refuses to store RIGHTSLIST of e' > %u bytes in buffer of %u bytes.\n%s",n; >                   rsz, (unsigned long) jpilist[1].buflen,oD >                   "Check your rights database for corruption.\n");   Well done !r   ------------------------------    Date: 30 Aug 2001 08:15:50 -0700) From: google@mccready.com (Gary McCready)  Subject: Re: dynamic dcl menuc= Message-ID: <6e64ea70.0108300715.72b71501@posting.google.com>s  B There are many ways to create a "changeable" menu; the two I wouldD suggest, mainly for ease of debugging, while running the actual menu arenC -have your dcl procedure "var.com" actually write another "new" dcl-A procedure that results in a menu, then have the orignal procedure C display that menu. One can type out the "new" procedure while it is 	 being run E -your procedure can define logical names to pass menu options betweenl? the procedures; if those logical names are written to the groupmF logical name table (for debugging purposes), they they can be examined while the menu is running.   --Gary McCreadyr5 ---My opinions have nothing to do with my employer's.c   "Jayasuthan ......" <suthan@eplx01.fairchildsemi.com> wrote in message news:<Pine.LNX.4.33.0108290257200.14995-100000@epss09.fairchildsemi.com>... > Hai, > K > I working on updating my shell account menu. I try to build script out of E > DCL that look alike dynamic pages. Not so fancy but consider okey..o > F > the problem is that I hving problem with variable. It work like this > 5 > menu.com --> call var.com gather system information;. >        1]--> call layout.com to display menu8 > menu.com <- return back to menu once a inquire is made3 >        2]--> return back to layout.com to displayM > I > Only use single menu.com and it pass variable to layout.com to display.aC > Now the problem is that first 1] call variable carried out to 2].u >  > here is the source:e > & > http://jjsuthan.tripod.com/alpha/vms > J > change comdir path in menu.com and layout.com. Access till fullback menu@ > and return back to main.. the fullback variable still display. >  > Please help me out.. > +------------------------+ > ||Jayasuthan             | > ||Fairchild Semiconductor| > ||System Support	 |a > ||http://epss09		 |i > ||Tel: 604-8502630 (630) | > +------------------------+   ------------------------------  % Date: Thu, 30 Aug 2001 13:02:55 +0200r7 From: "Oliver Becker" <oliver.becker@alba-software.com>t$ Subject: European Contract Vacancies/ Message-ID: <9ml6h0$qb2$00$1@news.t-online.com>N   Dear VMS Specialistu  C Alba Software is a specialist recruitment consultancy, providing ITh. specialists to Europes Leading Finance Houses.  F The VMS platform is a popular choice of operating system for financial" institutions due to its stability.  J As such we are always seeking experienced developers on VMS with knowledgeB of a combination of the following: Cobol, C, Pro*C, C++, SQL, DCL,K Oracle/Rdb. No financial experience is necessary as training will be given.A  I Contract vacancies exist across Europe, with the main sites being London,o Frankfurt, Amsterdam, Brussels.a  L Should you be interested to talk in more detail about VMS development roles, please contact us:  J Please Note - EU work permit holders only. We cannot arrange work permits.  
 Oliver Becker3 Alba Software Technology" No.1 Poultry, London, EC2R 8JR, UK   Tel:    +44 (0)20 7643 2211l Fax:   +44 (0)20 7643 2628! email  projects@alba-software.com0 web   www.alba-software.comD   ------------------------------   Date: 30 Aug 2001 06:30:59 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)! Subject: Re: EV7 will never ship?B0 Message-ID: <9mkmj3$fc7$1@pegasus.csx.cam.ac.uk>  = In article <TLgj7.33164$mv1.6494362@typhoon.ne.mediaone.net>,f3 Terry C. Shannon <terryshannon@mediaone.net> wrote:hL >It maters not. IBM was/will ship EV7 (which is now up and running, nit API)  ? Er, this isn't quite what people mean, nor what really matters.e? Manufacturing Alpha chips hasn't been a problem for some years,.@ and the problem has been finding a company that would build them2 into reasonably specified, cost effective systems.  A While I agree that API are irrelevant (in this or pretty well anyt? other context), the evidence is that they are wholly controlledoB by Compaq (my guess is that Samsung have 70% preference shares andA Compaq 30% ordinary ones, or something like that).  It isn't whati@ API do that is relevant, as distinct from what it tells us about+ Compaq's real (perhaps subconscious) plans.n  = And then there are the problems of getting the EV7 to work innA complete systems, but API aren't involved in that and never were.s     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679n   ------------------------------   Date: 30 Aug 2001 13:18:02 GMT& From: peter@abbnm.com (Peter da Silva)! Subject: Re: EV7 will never ship?s% Message-ID: <9mleea$omq@web.nmti.com>t  3 In article <fb4VRphF9xlg@eisner.encompasserve.org>,I. Larry Kilgallen <Kilgallen@SpamCop.net> wrote:k > In article <3B8D7106.4FEF41F@ipl.demon.co.nospam.uk>, Steve Reece <SYSTEM@ipl.demon.co.nospam.uk> writes:nL > > Perhaps because your legal people wouldn't want the customer details andK > > credit card numbers held on your web server to be held under a freewarecL > > (or nearly so) operating system and hence prefer the concept of security1 > > that might be afforded by the use of Tru64???d  4 > Ignore the legal people -- let's talk bottom line.  J > Perhaps your _insurance_company_ wouldn't want the customer details etc.  H The only case I know of where an insurance company charges more based onI the OS in use, it's Windows NT that's getting the short end of the stick.    --  +  `-_-'   In hoc signo hack, Peter da Silva. E   'U`    "A well-rounded geek should be able to geek about anything."rL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------   Date: 30 Aug 2001 13:26:45 GMT& From: peter@abbnm.com (Peter da Silva)! Subject: Re: EV7 will never ship?o% Message-ID: <9mleul$osu@web.nmti.com>   8 In article <i4hqot0p4bbg7i99v8a5ed4jfkp8g8q1uh@4ax.com>," jlsue  <jlsuexxxz@home.com> wrote:A > Um... we actually have two groups already building server-classrG > "boxes" that are very reliable.  Both the Alphaserver systems and the G > high-end Intel servers are of very high quality and reliability.  Oura# > ML/DL lines are extremely stable.e  J The DL360 totally surprised me. My past experience with Proliants had beenE uniformly miserable, but the DL360 and DL320 are actually nice boxes.g  K I haven't looked into the other members of the line, but if they're equallydJ compatible with non-Windows OSes and as well designed they're a good pick.  M The only thing I really miss from the Alphaservers is the nice serial commandsN line console. If you could produce a DL360 with a serial console we would snap it up like *that*.   --  +  `-_-'   In hoc signo hack, Peter da Silva.pE   'U`    "A well-rounded geek should be able to geek about anything." L                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------    Date: 30 Aug 2001 09:08:48 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)V! Subject: Re: EV7 will never ship?h3 Message-ID: <5l8ZC$G8iTog@eisner.encompasserve.org>i  N In article <9mleea$omq@web.nmti.com>, peter@abbnm.com (Peter da Silva) writes:5 > In article <fb4VRphF9xlg@eisner.encompasserve.org>,-0 > Larry Kilgallen <Kilgallen@SpamCop.net> wrote:l >> In article <3B8D7106.4FEF41F@ipl.demon.co.nospam.uk>, Steve Reece <SYSTEM@ipl.demon.co.nospam.uk> writes:M >> > Perhaps because your legal people wouldn't want the customer details andhL >> > credit card numbers held on your web server to be held under a freewareM >> > (or nearly so) operating system and hence prefer the concept of security 2 >> > that might be afforded by the use of Tru64??? > 5 >> Ignore the legal people -- let's talk bottom line.c > K >> Perhaps your _insurance_company_ wouldn't want the customer details etc.t > J > The only case I know of where an insurance company charges more based onK > the OS in use, it's Windows NT that's getting the short end of the stick.h  H Other insurance companies will not spend long ignoring a good idea aboutF finding new ways to raise the rates.  Once they grab hold of the idea,J actuaries will be pricing policies based on the data security track record1 of not only the OS but also the company using it.t  G Certainly operating system choice may not be at the top of their radar,oH but as the world settles down to a dull roar of breakins continuing with> no sign of cessation, they will find a way to charge for risk.   ------------------------------  % Date: Thu, 30 Aug 2001 12:47:07 -0400b5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>h! Subject: Re: EV7 will never ship?i3 Message-ID: <46uj7.1002$bB1.45406@news.cpqcorp.net>e  < JF Mezei wrote in message <3B8D316B.AD2EB6F@videotron.ca>... >Fred Kleinsorge wrote:oJ >> There are people still happily using Alpha systems built with EV4's andJ >> Turbochannels.  They may have a hard time "upgrading" the hardware, but weJ >> (VMS) still support these systems, even though they were built a decade ago.B >> VMS has been traditionally slow to retire support for hardware. >PE >OK, for that I agree, since I still run VMS on my all mighty teenagen MicrovaxH >II. And the VMS folks do deserve a round of applause for support of old	 hardware.x >sL >However, I think that most folks saw the DII-COE thing more as a commitmentL >not to kill VMS instead of a commitment to continue to support existing VMSI >configs. In light of what you said, if, for instance, I buy a particularoD >config from Compaq today (alpha with VMS 7.3),  getting the DII-COEL >certification/contract would simply mean that Compaq agrees to support this. >"fixed" configuration for X number of years ? >n    K Actually, you would by an ES40 (or perhaps an ES45) with V7.2-6C1 (COE).  IpF don't know the details of the support contract for this.  I  only know# details about the engineering side.    ------------------------------  % Date: Thu, 30 Aug 2001 12:54:21 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>e! Subject: Re: EV7 will never ship?C3 Message-ID: <Scuj7.1003$bB1.45307@news.cpqcorp.net>u  = JF Mezei wrote in message <3B8D263B.CEA96993@videotron.ca>...o >Alan Greig wrote:L >> have Galaxy support features according to current customer presentations.
 The slides= >> show one system running Windows-64, VMS, Linux, and Tru64.e >uK >I was under the impression that currently, Galaxy only *supports* multipler >instances of VMS. >e    G What is described above is not "Galaxy" but hard partitions.  We hackednJ something that looked like a hard partition using software partitioning onL the Turbolaser.  Currently, the only OS I know of doing soft partitioning in VMS.  I >If Galaxies will, in a couple years, support instances of Windows, Linux  and F >Tru64, that would be a huge amount of work to get it to a point where Compaq  >would be willing to support it. >a    G In a hard partitioned system, the OS instances are firewalled from eachmH other.  But you can also engineer selective breaks in the firewalling toL implement something like shared memory.  You can also potentially do dynamicH reconfiguration - but usually on a coarser granulatity that in a Galaxy.  J >I know that the engineers had demoed Linux booting with VMS , but that it wasM
 >very "demo".e > K >But to get Windows to safely participate in a galaxy inside of a couple ofr* >years, I would find that hard to believe. >     I I think that getting MS to embrace something not invented in Redmond is ai' greater challenge than the engineering.   L >*IF* Microsoft does put deep down low level integrated support for galaxies inG >Windows and makes sure that windows does behave nicely and doesn't zaps disksgL >or memory structures of another competing OS next to it, it would mean thatK >Compaq truly does have a special relationship with gates since only Compaq 4 >would be building galaxy-capable machines (right ?) >b  K Galaxy requires no special hardware, it's all software - even if some of ita may be firmware.  H >Or has Compaq also given away the IP for galaxies to Intel, making that@ >intellectual property freely available to all Intel customers ?  I No idea.  There are a bunch of Galaxy patents, a couple have issued, most  are pending.   ------------------------------  % Date: Thu, 30 Aug 2001 12:56:02 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>L! Subject: Re: EV7 will never ship?73 Message-ID: <qeuj7.1004$bB1.45344@news.cpqcorp.net>e  ! Keith Parris wrote in message ...TA >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message . news:<Mf7j7.930$bB1.43844@news.cpqcorp.net>... >>J >> Tandem systems require higher capabilites that we couldn't duplicate or takeL >> advantage of without a lot of effort - like lock-stepping.  These systemsE >> fill the niche of super-high availability.  VMS fills the niche ofm6 >> high-availability with disaster tolerance/recovery. >oF >VMS once had this sort of capability with VAXft hardware.  Given thatG >the Tandem folks will have to continue to make significant investmentsfE >to provide fault-tolerant IA-64 hardware platforms, it would seem to G >make sense to spread that cost beyond the Tandem base alone and in the A >process give VMS customers a fault-tolerant hardware option onceo >again.t    $ It is certainly an interesting idea.   ------------------------------  % Date: Thu, 30 Aug 2001 13:06:45 -0400m- From: JF Mezei <jfmezei.spamnot@videotron.ca>e! Subject: Re: EV7 will never ship? , Message-ID: <3B8E72A4.5B9E97A4@videotron.ca>   Larry Kilgallen wrote:J > Other insurance companies will not spend long ignoring a good idea aboutH > finding new ways to raise the rates.  Once they grab hold of the idea,L > actuaries will be pricing policies based on the data security track record3 > of not only the OS but also the company using it.s  H The minute the charging of higher insurance for users of Windows becomesI important enough, you can bet that Microsoft will sue the hilt out of the N insurance companies and prove that its OS is secure when well managed and whenI the system managers check the microsoft web site at regular intervals for , available patches. (interval = each hour :-)  M Furthermore, Microsoft could argue that NT is not yet fault tolerant and thatoM customers who use NT in situations requiring fault tolerance should not blame D microsoft but blame themselves for using the wrong tool for the job.  K However, it is also possible that Microsoft will simply pay those insuranceoJ companies under the table to stop such a practice since going public wouldL only attract the attention to the fact that NT isn't high enough quality yetM and that customers should not install Nt in true enterprise applications evene' though MS and Compaq would want you to.    ------------------------------  # Date: Thu, 30 Aug 2001 17:01:22 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: EV7 will never ship?o= Message-ID: <Cjuj7.36410$mv1.7062127@typhoon.ne.mediaone.net>j  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:Scuj7.1003$bB1.45307@news.cpqcorp.net...)? > JF Mezei wrote in message <3B8D263B.CEA96993@videotron.ca>...s > >Alan Greig wrote:? > >> have Galaxy support features according to current customerA presentations. > The slides? > >> show one system running Windows-64, VMS, Linux, and Tru64.E > >rD > >I was under the impression that currently, Galaxy only *supports* multiple > >instances of VMS.  F What folks fail to understand is that comp.os.vms is a Romper Room for whiners!   ------------------------------  % Date: Thu, 30 Aug 2001 13:46:00 -0400r5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>l! Subject: Re: EV7 will never ship? 3 Message-ID: <hZuj7.1012$bB1.45495@news.cpqcorp.net>e   Are we haveing a bad day Terry?a  L It's a nice day to golf.  Hop in the car and head to Overlook (although theyC have problems with their greens) or maybe up past me to Amherst CC."  K Or maybe just head over to Silver Lake (make sure your shots are up-to-date  ;-).      % Terry C. Shannon wrote in message ..." > A >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message0. >news:Scuj7.1003$bB1.45307@news.cpqcorp.net...@ >> JF Mezei wrote in message <3B8D263B.CEA96993@videotron.ca>... >> >Alan Greig wrote:o@ >> >> have Galaxy support features according to current customer >presentations.w
 >> The slidesm@ >> >> show one system running Windows-64, VMS, Linux, and Tru64. >> >E >> >I was under the impression that currently, Galaxy only *supports*r	 >multiplel >> >instances of VMS.  > G >What folks fail to understand is that comp.os.vms is a Romper Room forr	 >whiners!i >  >n >u   ------------------------------    Date: 30 Aug 2001 09:16:50 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>o) Subject: Re: Feeling Better about ItaniumtH Message-ID: <y48zg2c90d.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  " jlsue <jlsuexxxz@home.com> writes:  E > I don't mean to start rumors, and I have no inside knowledge, but I G > doubt this decision was brought up and decided in one week.  Probablyi > not even one month.a  H From Compaq's own statements on the 25 June decision, it seems clear theG process took about a month, with as few people involved as possible. ItoI seems unlikely that there were intensive contact between the EV7, EV8 andk! the IPF design teams before that..   	Jan   ------------------------------    Date: 30 Aug 2001 05:29:36 -0700- From: afeldman@gfigroup.com (Alan E. Feldman)iN Subject: Fun error messages (was Re: VMS high reliability needed by Air Force)< Message-ID: <af1e4ce6.0108300429.2d5a86b@posting.google.com>  e Alan Greig <a.greig@virgin.net> wrote in message news:<dv2cotk1jcmjd1n5n61q0lcinkf5n57pjd@4ax.com>... F > On 24 Aug 2001 01:08:50 GMT, Joe Heimann <heimann@nog.ecs.umass.edu> > wrote: [snip]> C > I recall a VAX with an add in processor card running some libraryvF > software. The second processor/OS crashed with the error "Full power > to the shields Mr. Sulu"  : One of my all-time favorties is the first one in the book:    AAA,  'file-spec'  i5   Facility:     RUNOFF, DIGITAL Standard Runoff (DSR)-  +7   Explanation:  This message should never be displayed.0  1;   User Action:  Submit a Software Performance Report (SPR).t  e  + Oh no!!! I just displayed this message! :-)e   Disclaimer: JMHO Alan E. Feldmani afeldman@gfigroup.come   ------------------------------   Date: 30 Aug 2001 12:36:31 GMT, From: "Ken Hackenjos" <khackenjos@yahoo.com>C Subject: Global Section Question Again (with correct email address)y2 Message-ID: <01c13158$55cd8560$91a770d8@satellite>  I My last post was my first post to a newsgroup, and I was surprised to seedH the username and email address that it posted under!  I think I've fixedE that now, and I would appreciate any assistance that can be provided.n   The original post:  G I am looking for a method (or a best method) to update a global sectione across a network link.  J I have an older Vax6250 system collecting data on a plant's operation, andD that data is stored in current value tables that are global sectionsK (updated approximately once per second).  I need to quickly access the datatH in those sections to distribute to a more modern system.  But the VAX isJ already heavily loaded.  I have an unused Alpha attached, and I would likeE to be able to quickly (and repeatedly) replicate or update the globalrK section from the VAX to the Alpha, then have a new program operating on theeC Alpha to serve the data to the modern system.  I'm just looking for3J concepts and tools, not detailed coding information (I'm not a programmer,J just trying to see what is possible).  The VMS version is 7.?.  Thanks for any information.   Ken    ------------------------------  % Date: Thu, 30 Aug 2001 15:46:46 +0200r& From: Michael Joosten <joost@c-lab.de># Subject: Re: GNU screen for AXP/VMSe$ Message-ID: <3B8E43C6.48EE@c-lab.de>   Phil Mendelsohn wrote: > L > Screen suffers from the same problem that SPAWN and ATTACH do -- you can'tG > cut and paste between them easily.  Do BOSS or any of the other utilsc* > mentioned let one edit between sessions? >   G I vaguely remeber that the UW clients did this. The UW-4.2 tarball came @ with the Mac client, as uw.sit.hqx for an old 68k MacOS. Time toG download a trial emulator from www.emulators.com, grab an old MacOS andn give it a try...  H BTW, www.emulators.com has a hefty rant about the Pentium IV. Very long, but very detailled.  --  * Michael Joosten, SBS C-LAB, joost@c-lab.de* Fuerstenallee 11, 33094 Paderborn, Germany, Phone: +49 5251 606127, Fax: +49 5251 6060658 C-LAB is a cooperation of University Paderborn & SIEMENS   ------------------------------  # Date: Thu, 30 Aug 2001 13:59:53 GMTA2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)N Subject: Re: How to quickly replicate a global section on another network node2 Message-ID: <tFrj7.995$bB1.45204@news.cpqcorp.net>  ` In article <pBgj7.95$V83.4393@ozemail.com.au>, "Phil Howell" <phowell@snowyhydro.com.au> writes:* :You can map global sections to disk files& :(see system services crmpsc & mgblsc)8 :in a cluster this would be visible to your Alpha system7 :otherwise you could get at it via decnet (or even nfs)   H   Yes, I've seen folks try this.  This approach requires the applicationF   programmer explicitly avoid the inconsistencies that can result fromF   the local memory caching and the memory paging -- and to coordinate H   the writes and the page flushes and the page reloads across the nodes.H   By the time you get done solving the interlocking and caching problemsH   that are usually involved here, you end up with ICC, MessageQ, or RTR A   or similar.  Or you can use RMS with global buffers, of course.l  D   One of the few approaches to this shared-across-a-cluster sectionsF   problem I've seen (mostly) work has involved exactly one writer and D   multiple readers, and particularly with the one writer performing B   only "careful updates" -- very careful writes; sequencing of allF   writes to prevent partial updates from ever becoming visible to any E   readers -- and a writer that very regularly flushed all pages back o<   to disk.  (But I'd recommend avoiding even this approach.)  E   Coherency on one node is relatively easy.  See Ask The Wizard topicrC   (2681) for some of the local requirements for memory barriers andtE   such.  Also realize that there is no data synchronization afforded LA   to a file mapped to sections across a cluster, and there are nonD   memory-level primitives that are cluster-distributed accessable.  C   (You'd need the distributed lock manager or other similar tools.)y  =   Coherency across multiple nodes is a rather harder problem.e  F   The suggested approach of NFS makes things even more interesting, asG   that makes disk respond like memory paging -- the typical NFS server 0I   block caching parallels the typical host-based caching of memory pages.IG   Put another way, the last block written to disk -- whether or not it b<   was originally loaded with the most recent data -- "wins".       N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Thu, 30 Aug 2001 13:22:36 +0200.* From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: I hate Compaq/ Message-ID: <3B8E21FC.2080308@brussels.sgi.com>a   Nick Maclaren wrote: > 6 > "Not the current platform" != "Necessarily the EV7". > @ In theory. But given the development cycle for a (new) platform,9 either Compaq knew for long time that EV7 would be canneda2 (and the silicon people have told me runs seems to= point to the contrary), or any new platform would rely on EV7t< features. In other words, I think it would be more costly to8 develop another platform without EV7 than anything you'd8 save by scrapping EV7 deployment, and the platform would
 appear later.h  A That doesn't mean it's impossible -- but then you really wouldn't > be able to attribute it to Compaq's malevolence, only to their
 stupidity ;).n   -- l? <these messages express my own views, not those of my employer>a) Alexis Cousein				Senior Systems Engineeri. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------   Date: 30 Aug 2001 11:34:07 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq/ Message-ID: <9ml8bf$3r$1@pegasus.csx.cam.ac.uk>d  / In article <3B8E21FC.2080308@brussels.sgi.com>,s, Alexis Cousein <al@brussels.sgi.com> writes: |> Nick Maclaren wrote:- |> > -9 |> > "Not the current platform" != "Necessarily the EV7".m |> >  C |> In theory. But given the development cycle for a (new) platform,e< |> either Compaq knew for long time that EV7 would be canned5 |> (and the silicon people have told me runs seems too@ |> point to the contrary), or any new platform would rely on EV7? |> features. In other words, I think it would be more costly toT; |> develop another platform without EV7 than anything you'd>; |> save by scrapping EV7 deployment, and the platform wouldl |> appear later.  ? The EV69 was on their roadmaps for a long time, and was dropped ? only recently.  I have no idea how far the project got, nor how : ambitious it was, but it is extremely likely that there is= something along those lines that could be resuscitated fairlyh cheaply and quickly.  = But I agree that it is a less likely scenario than a completed@ meltdown of the Alpha line (i.e. an inability to get the EV7 out< and working in a realistic timescale, with no fallback), and? even that is not the way that I would bet.  However, I wouldn'tI> say that it is implausible, either, as some people are saying.  D |> That doesn't mean it's impossible -- but then you really wouldn'tA |> be able to attribute it to Compaq's malevolence, only to theirC |> stupidity ;).  A I don't feel the need to introduce malevolence - assuming maximale2 stupidity gives a pretty good fit to the data ....     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679M   ------------------------------  % Date: Thu, 30 Aug 2001 11:05:30 -0500tC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>sY Subject: installing extensions to MOD_PERL (was Re: CSWS, MOD_PERL - anyone have HELLO.PM I Message-ID: <craig.berry-A21189.11053030082001@newsrump.sjc.telocity.net>r  8 In article <00A01446.A33065DF@SSRL04.SLAC.STANFORD.EDU>,H  winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")   wrote:t  J > Next question: Anybody managed to get the DBI stuff to install into the  > CSWS_PERL tree?  r  F I haven't tried it but it should be straightforward if your PERL_ROOT H logical is pointing to the right place.  But you will need to clean out F your DBI directory tree and rebuild if you've already built against a 6 different version of Perl.  So, for example, you'd do:   $ mmk realcleanc $ perl Makefile.PL $ mmko
 $ mmk test
 $ mmk installi  8 > Failing that, does MOD_PERL as supplied by Compaq workE > with other PERLs, or does it have to be the Compaq supplied PERL?  n  ? In principle it could work with a Perl 5.005_03 that you built e; yourself, but there'd be no advantage to doing so.  Binary rC compatibility across versions is not something we've done; for one  D thing, I think you can only add new symbols at the end of your list > when building a shareable image if you want it to be backward @ compatible but we just assemble an alphabetical list on the fly.   ------------------------------  % Date: Thu, 30 Aug 2001 13:35:57 -0400n0 From: "Syltrem" <syltrem@videotron.ca.spammenot> Subject: Re: Mark Twain Promog5 Message-ID: <iOuj7.56878$TW.298784@tor-nn1.netcom.ca>   , I just got the book today. Also in Montreal.  G I kinda like it. Just hopes it will help the software vendors and otherl9 decidors be more confortable on spending more on OpenVMS.e  H For my part it brings hope up one notch. But can we really have trust inL Compaq? That's the real question. And I certainly don't have an answer or ifE I do, it's not positive. Nevertheless we will have to undergo another.I migration in a couple' years or let go of VMS (or Tru64 for that matter).d  K I would very much like to know who got that book though. People like me (us J at cov), or people looking for a good OS and not having reached a decision yet?   --   Syltremg; http://pages.infinit.net/syltrem (OpenVMS related web site)s    G "JF Mezei" <jfmezei.spamnot@videotron.ca> a crit dans le message news:e! 3B8D55AC.37D1DD31@videotron.ca...3K > I didn't know what you guys were talking about until today when I got thea box.& > Didn't bother opening it right away. >  > But I just noticed the stamp.c >tG > Mailed from: Nashua, NH. But the stamp indicates that the package wasS insertedI > in the postal system at Zrich  (CH-8058 Zurich 58) ... Delivered to anS adress5 > a few hundred km north of Nahua in montreal canada.h >  >eF > The book is a nice though, and the "rumours of my deaths are greatlyJ > exagerated" was a good choice for the cover. It does show that Gorham is awareo; > that Compaq's decision has hurt VMS' image significantly.p   ------------------------------    Date: 29 Aug 2001 23:52:41 -0700, From: ian.burgess@start.com.au (Ian Burgess)( Subject: Re: My VMS Wish List (features)= Message-ID: <6b63fc08.0108292252.2cede043@posting.google.com>m  S Brad Hughes <brad@tgsmc.com> wrote in message news:<3B8D4697.2B75192C@tgsmc.com>...v > Bob Koehler wrote: > > R > > In article <3B8D2C89.95FAD793@tgsmc.com>, Brad Hughes <brad@tgsmc.com> writes: > > >i< > > > I'd like to be able to run .com files in the debugger:$ > > > step, examine, deposit, etc...  P Well you can litter your procedure with breakpoints and do examine (show symbol)$ etc followed by continue (Control_z) A breakpoint in DCL?   $ @TT:   IanW   ------------------------------  % Date: Thu, 30 Aug 2001 03:00:37 -0400i- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>h( Subject: Re: My VMS Wish List (features), Message-ID: <3B8DE495.88CA5172@peoplepc.com>   Yeah Frank !    S You beat me to the punch in explaining to these "youngsters" where the real originst  of command completion came from.  T While we are at it, can we have a debugger like DDT that lets us enter assembly codeT and execute it in place, without ever creating a file or even starting the assembler !!??  
 Jack Patteeuwo   Frank da Cruz wrote: > > > In article <cdbc7707.0108290401.b13d9ec@posting.google.com>,# > Pierre <moi_is_me@usa.net> wrote:d0 > : My wish list is fairly simple (in principle) > :hL > :  As much as UNIX annoys me - I do like the auto completion functionality/ > :  found in the bash shell (perhaps others ?)u > :nJ > Few people remember that this feature was pioneered by DEC itself in itsL > TOPS-20 operating system, 1975-1988, RIP.  That's where Bash, Tcl, and allI > the others got it from.  (Strictly speaking, it appeared first in BBN'soC > TENEX, which became TOPS-20, but TOPS-20 took the radical step ofmE > integrating it into the operating system kernel as a system serviceeL > available to all applications, and basing its command processor, the EXEC,	 > on it.)s   ------------------------------    Date: 30 Aug 2001 02:21:49 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen),( Subject: Re: My VMS Wish List (features)3 Message-ID: <YxmXAothfgYr@eisner.encompasserve.org>o  [ In article <3B8DAE36.15F3721E@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:R > Larry Kilgallen wrote: >> - >> That is a good list.- >> aD >> My only concern is with encouraging people to write things in DCLD >> that would better be done in compiled languages.  Still there areG >> times when the steps that require dealing with any of the 6 floatingrE >> point types are minimal and the Real goal is to run Sort.  In thata5 >> case switching to a compiled language is overkill.  > 6 > Of course, the problems with compiled languages are: >  > o they're compiled# > o unless you write Macro32, $$$$$r   Don't forget Bliss.e  H > o too many wheels to re-invent when DCL already has many conveniences.   ------------------------------  % Date: Thu, 30 Aug 2001 19:39:08 +0010n% From: paddy.o'brien@zzz.tg.nsw.gov.aua( Subject: Re: My VMS Wish List (features)5 Message-ID: <01K7R8YLZHJ6004IVH@tgmail.tg.nsw.gov.au>p   Ian Burgess wrote:  / >Brad Hughes <brad@tgsmc.com> wrote in message  & >news:<3B8D4697.2B75192C@tgsmc.com>... >> Bob Koehler wrote:a >> > nL >> > In article <3B8D2C89.95FAD793@tgsmc.com>, Brad Hughes <brad@tgsmc.com>  writes:t >> > >= >> > > I'd like to be able to run .com files in the debugger: % >> > > step, examine, deposit, etc...- > J >Well you can litter your procedure with breakpoints and do examine (show  symbol).% >etc followed by continue (Control_z)i >A breakpoint in DCL?    >$ @TT:D  K I think I got it off an old SIGtape from DECUS -- probably still available x1 in their library.  DEBUG_DCL by Laurent Quivogne.o  J I use it a bit and find it effective with complex code or some third-part 1 I've picked up and found difficult to understand.o  H But, yes, it would be nice to have something fully supported by our VMS 
 engineers.   Regards, Paddy   ------------------------------    Date: 30 Aug 2001 08:12:58 -0500- From: koehler@encompasserve.org (Bob Koehler)E( Subject: Re: My VMS Wish List (features)3 Message-ID: <vsHVJIVSWv8Y@eisner.encompasserve.org>a  N In article <3B8D4697.2B75192C@tgsmc.com>, Brad Hughes <brad@tgsmc.com> writes: > Bob Koehler wrote: >> wQ >> In article <3B8D2C89.95FAD793@tgsmc.com>, Brad Hughes <brad@tgsmc.com> writes:2 >> >; >> > I'd like to be able to run .com files in the debugger: # >> > step, examine, deposit, etc...0 >> fG >>    This has been part of the debugger since at least VMS 2.2 (when I@$ >>    finally learned the debugger). >>  , >>    HELP/LIBRARY=SYS$HELP:DBG$HELP DEBUG @ > H > No, I mean I'd like to be able to debug .com files in the VMS debugger# > much as I debug Fortran programs.l >   E I understand there were at least two such tools running around insideiD DEC. DCL_DEBUG.COM and DCL_DEBUG_FAST.COM by Manfred Drechsel of DECH Munich (info from a friend who was a Deccie).  They were never released.H Maybe someone in VMS engineering can track them down and get them on theB next freeware CD?  Or at least get permission to make them public?   ------------------------------    Date: 30 Aug 2001 08:22:23 -0500- From: koehler@encompasserve.org (Bob Koehler)k( Subject: Re: My VMS Wish List (features)3 Message-ID: <snMUNtgUvyak@eisner.encompasserve.org>s  \ In article <3B8DE495.88CA5172@peoplepc.com>, Jack Patteeuw <jjpatteeuw@peoplepc.com> writes: > V > While we are at it, can we have a debugger like DDT that lets us enter assembly codeV > and execute it in place, without ever creating a file or even starting the assembler  $ Done that many times with VMS debug.   ------------------------------  % Date: Thu, 30 Aug 2001 12:21:09 +0100.0 From: andrew harrison <andrew.nospam@uk.sun.com> Subject: Re: Nits in Slides * Message-ID: <3B8E21A5.B1AEBB0F@uk.sun.com>   Jan C Vorbrueggen wrote: > 4 > andrew harrison <andrew.nospam@uk.sun.com> writes: > B > > Incedentally if you are prepared to accept that IA64 really is= > > available then its also faster than Alpha as well for alll; > > that SPEC results prove. Or hadn't you noticed that thep8 > > IA64 SPECfp results are faster than Alpha as well as > > being faster than USIII. > K > No I hadn't, because it is a false statement. The IA-64 CFP2000 result ismJ > 701, and there are five (really three different systems) with results inP > the range 756-784 in front of it, using 21264C-1001 and 21264B-833 processors.N > Oh, and the CINT2000 result is even worse than that of the US-III, and worse) > than current Alphas by a factor of 2.5.i >   7 Humm, you are using Peak CFP2000 results and I am not. // 701 is the fastest current CFP2000 base result.l   regards  Andrew Harrisone Enterprise IT Architectp   ------------------------------  % Date: Thu, 30 Aug 2001 12:13:35 +0100e0 From: andrew harrison <andrew.nospam@uk.sun.com>B Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)* Message-ID: <3B8E1FDF.7B677D1A@uk.sun.com>   Fred Kleinsorge wrote: > D > andrew harrison wrote in message <3B8BA0A7.A3584F74@uk.sun.com>... > >w > >Fred Kleinsorge wrote:  > >>G > >> andrew harrison wrote in message <3B869B1C.D520C45C@uk.sun.com>...h > >> >Fred Kleinsorge wrote: > >> >>i3 > >> >> andrew harrison pontificated like a baboon:.	 > >> >> >n0 > >> >> >Are you sure you are an engineer ??????	 > >> >> >a > >> >>5N > >> >> Well I sure as heck am not a self-styled "Enterprise Architect".  I've
 > >> still" > >> >> to see *your* credentials. > >> >7 > >> >Since you didn't even get the title right I guess 9 > >> >you are displaying more post the 25th inexactitude.n > >> > > >>H > >> Come on you horses ass.  You are a slippery as an eel.  If there isA > >> something you don't want to answer, you simply sidetrack it.c > >>M > >> Tell us exactly who you are, and what makes you qualified to be listenedp > to.b7 > >> Give us the readers digest version of your resume.y > >>@ > >> I've shared mine here when *you* challenged my credentials. > >  > >f, > >Actually yet again you have got it wrong. > >i+ > >I havn't challenged your credentials yets+ > >so I have yet to see your CV, which I amo > >sure is very impressive.i > >  > K > I'm sure you'll find it in deja from the last time we had this go around. ( > And again you've avoided the question.     Why not produce the posting.  1 Actually on second thoughts don't bother grow up p= instead Fred, what do you want a my CV is better/longer/more  , sexually attractive than yours conversation.  0 Isn't that rather like your complaints about my  benchmark is better than yours.l     Regards  Andrew Harrisone Enterprise IT Architectr   ------------------------------  # Date: Thu, 30 Aug 2001 17:26:48 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)B Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)3 Message-ID: <sHuj7.1009$bB1.45447@news.cpqcorp.net>s  ] In article <3B8E1FDF.7B677D1A@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes: 2 :Actually on second thoughts don't bother grow up > :instead Fred, what do you want a my CV is better/longer/more - :sexually attractive than yours conversation.i  ,   I will resist rising to the straight line.,   I will resist rising to the straight line.,   I will resist rising to the straight line.,   I will resist rising to the straight line.0   I will resist rising to the straight line. :-)    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Thu, 30 Aug 2001 13:41:27 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>-B Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)3 Message-ID: <1Vuj7.1011$bB1.45459@news.cpqcorp.net>   B andrew harrison wrote in message <3B8E1FDF.7B677D1A@uk.sun.com>... >Fred Kleinsorge wrote:- >>E >> andrew harrison wrote in message <3B8BA0A7.A3584F74@uk.sun.com>...a >> > >> >Fred Kleinsorge wrote: >> >>-H >> >> andrew harrison wrote in message <3B869B1C.D520C45C@uk.sun.com>... >> >> >Fred Kleinsorge wrote:I >> >> >>4 >> >> >> andrew harrison pontificated like a baboon:
 >> >> >> >1 >> >> >> >Are you sure you are an engineer ??????c
 >> >> >> > >> >> >>I >> >> >> Well I sure as heck am not a self-styled "Enterprise Architect".C I've >> >> still # >> >> >> to see *your* credentials.t >> >> >n8 >> >> >Since you didn't even get the title right I guess: >> >> >you are displaying more post the 25th inexactitude. >> >> >  >> >>tI >> >> Come on you horses ass.  You are a slippery as an eel.  If there isgB >> >> something you don't want to answer, you simply sidetrack it. >> >>tE >> >> Tell us exactly who you are, and what makes you qualified to be' listened >> to.8 >> >> Give us the readers digest version of your resume. >> >> A >> >> I've shared mine here when *you* challenged my credentials.y >> > >> >- >> >Actually yet again you have got it wrong.u >> >, >> >I havn't challenged your credentials yet, >> >so I have yet to see your CV, which I am >> >sure is very impressive. >> > >>L >> I'm sure you'll find it in deja from the last time we had this go around.) >> And again you've avoided the question.u >l >g >Why not produce the posting.u >l    8 Can't find it offhand, but someone with the dersire can.  1 >Actually on second thoughts don't bother grow up>= >instead Fred, what do you want a my CV is better/longer/more - >sexually attractive than yours conversation.  >t  0 >Isn't that rather like your complaints about my  >benchmark is better than yours. >     H This is a continuation of something entirely different.  You question myH credentials "Are you sure you are an engineer?".  And I ask once again -I what the hell are yours?  And you once again deflect the question.  Don'tp# want to answer?  Something to hide?h   Readers digest condensed form:  L I started as a OS 360 operator in the days when you needed to be able to useJ a sorter, and wire an adding machine.  I next wrote software for store andE forward messaging (telex and the like), doing device drivers, writing I routine database software, etc.  I then joined DEC, some 22 years ago.  ItH (strangely enough) wrote device drivers and other software for store andJ forward FAX machines at a customer site, wrote synchronous device drivers,H and supported commercial NYC customers (banks, stock exchanges, etc).  IK joined engineering, and wrote more device drivers, and library code for the-K Pro-350 (the SIGHT graphics editor to be specific).  I then got involved inlJ terminal emulators, writing a VT240 emulator for VWS (which later was usedG as the basis for DECterm/dxterm).  I project led and developed the UISXeJ libraries to allow VSW applications to run unchanged on X11.  I then wroteE many drivers and DDXs for X11 devices, mostly low-end 2D, and was the.K Technical Director for drivers and windows in our workstation organization. K I became the Technical Leader for the OpenVMS Systems group, and redesignedmG device configuration (adding file based configuration), and implemented:I foreign device booting.  I helped design some of the basic infrastructureLI for Galaxy and have 2 patents on it, with 2 pending.  I've helped work onyL the features for the IO7 - the IO controller for the EV7 systems.  I managedH the graphics group in VMS back into existance.  I was one of the projectK leads for DII/COE.  And I am now working on the IPF port, in particular the  console interfaces and ACPI.  C I am a Senior Member of Technical Staff (what used to be ConsultingaD Engineer), which required an engineering review board certification.  G So.  Now.  No more deflections or evasions.  I showed you mine, show usr yours.   ------------------------------    Date: 30 Aug 2001 07:50:05 -0700- From: merritt.robert@spsd.sk.ca (rob merritt) / Subject: Re: open vms hobbist tcpip license????m= Message-ID: <b6bf97d5.0108300650.58790a21@posting.google.com>s  ; I wasn't paying attention at the license registration page 5> last choice option box "Layered Products" sorry for noise post    _ WILLIAM WEBB <WWEBB1@email.usps.gov> wrote in message news:<0033000032155754000002L042*@MHS>...i > First you join Encompass,l$ > then give it a little time for the" > info to filter over to Montagar. > $ > Then you fill out the forms on the > pertinent web pages, > & > the licenses come via email that can > be cut and run as .COM files.1 > 
 > Regards, >  > WWWebb >  > > -----Original Message-----3 > > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET8) > > Sent: Monday, August 13, 2001 7:03 PMgH > > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET/ > > Subject: open vms hobbist tcpip license????b > >e > >oE > > OK i asked this once before here and waas flamed buy someone "forn. > > cluttering up the NG with vague questions.* > > so i will make this short and specific > > I > > I loaded up vms 7.2 on my vax 4000/50 loaded UCX went in to configure  >  g4 > > it as Ive done a million times at work and I seeH > >                  1  -  BIND Resolver        Requires TCPIP-IP-CLIENT > > PAKkH > >                  2  -  Domain               Requires TCPIP-IP-CLIENT > > PAKnH > >                  3  -  Routing              Requires TCPIP-IP-CLIENT > > PAKn > >eF > > I realize I need paks but I recieved no paper, and can find no DCLB > > scripts on the Montgar cd ??? do you have to purchase licenses > >o   ------------------------------    Date: 30 Aug 2001 10:27:10 -0700% From: rosj01@hotmail.com (James Ross) ( Subject: porting macro from VAX to ALPHA= Message-ID: <9026b6ac.0108300927.23db0deb@posting.google.com>k  F I a trying to port a VAX macro assembly program to OpenVms Alpha and I am getting an error.  / I use the following line to compile my program:a& MACRO/LIST/SYMBOL/MIGRATION FRQCNT.MAR  ! and the following error shows up:s  E %AMAC-I-OCTAWORD, octaword data type not supported at line number 381  in file FRQCNT.MAR9        CLRO (R4)[R11]      ;Clear OCTA word in FRQ3 tablet  9 Would any one have a clue on what I can do to solve this?3   ------------------------------  % Date: Thu, 30 Aug 2001 13:50:18 -0400 * From: John Reagan <john.reagan@compaq.com>, Subject: Re: porting macro from VAX to ALPHA) Message-ID: <3B8E7CDA.5040104@compaq.com>s   James Ross wrote:7H > I a trying to port a VAX macro assembly program to OpenVms Alpha and I > am getting an error. > 1 > I use the following line to compile my program:i( > MACRO/LIST/SYMBOL/MIGRATION FRQCNT.MAR > # > and the following error shows up:. > G > %AMAC-I-OCTAWORD, octaword data type not supported at line number 381w > in file FRQCNT.MAR; >        CLRO (R4)[R11]      ;Clear OCTA word in FRQ3 tablea > ; > Would any one have a clue on what I can do to solve this?: >   F  From looking at the code, it seems that none of the octaword opcodes E are supported (CLRO, MOVO, MOVAO, PUSHAO).  You'll have to recode it  I into a couple of CLRQs or a MOVC3/5.  You'll have do the 'multiply by 8' tC yourself since you used that indexed-addressing mode with the CLRO.l  F This restriction about the octaword opcodes isn't in the "Porting VAX E MACRO Code to OpenVMS Alpha".  That is an oversight.  I'll make sure tI something gets added to the release notes and the future revision of the   manual.e   John Reagan2 MACRO Project Leader   ------------------------------  % Date: Thu, 30 Aug 2001 13:40:05 -0400r- From: "Richard D. Piccard" <piccard@ohio.edu> , Subject: Re: porting macro from VAX to ALPHA( Message-ID: <3B8E7A71.CECCD9DE@ohio.edu>  > Did you try the naive approach of replacing that line with two5 instructions, each clearing one of the two quadwords?t  #                                 RDPr     James Ross wrote:   H > I a trying to port a VAX macro assembly program to OpenVms Alpha and I > am getting an error. >,1 > I use the following line to compile my program:n( > MACRO/LIST/SYMBOL/MIGRATION FRQCNT.MAR >s# > and the following error shows up:i >iG > %AMAC-I-OCTAWORD, octaword data type not supported at line number 381- > in file FRQCNT.MAR; >        CLRO (R4)[R11]      ;Clear OCTA word in FRQ3 tablee >L; > Would any one have a clue on what I can do to solve this?e   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------    Date: 30 Aug 2001 10:49:20 -0700/ From: on_the_move4ever@yahoo.com (Rick Nickles)wD Subject: Procedure to restart print queues/Help with $GETQUI $SNDJBC= Message-ID: <b2faac46.0108300949.47273986@posting.google.com>a  
 Greetings!  B       I am trying to write a procedure to restart all print queuesF that go into a stopped or stalled state.  I have a job that checks forD various things to see if they are running, and I'll add this programB to that job so that every so many minutes we can check for stoppedE queues.  (i.e. so I don't get a page at 3:00 am)    I am aware that IjF can use F$getqui and the $getqui and $sndjbc services.  I first wanted9 to see if anyone knew of any freeware, any Decus Software<E specifically, or anything that could do this - or code samples   - or.' some pointers on how to implement this.I thanks   Rick Nickles Stora Enso North America on_the_move4ever@yahoo.com   ------------------------------  % Date: Thu, 30 Aug 2001 12:38:40 -0000  From: nospam@nohost.no.net5 Subject: Re: Q: howto get proc name from library funch/ Message-ID: <toscug8jsdak7b@corp.supernews.com>c  K Thanks to all for your responses. I could not for the life of me find that n item code in the help.  , Dave Greenwood <greenwoodde@ornl.gov> wrote:4 : In a previous article, nospam@nohost.no.net wrote:N :> Is there a way through an RTL or system service to get a process's name as J :> does "show system"? I see there is a "prcnam" parameter in the lexical H :> function F$GETJPI but I can't seem to find a like one in LIB$ RTL or  :> system services.-  I : As others have mentioned, there's LIB$GETJPI.  There's also SYS$GETJPI.v : The item code is JPI$_PRCNAM.:   : Dave : --------------; : Dave Greenwood                Email: Greenwoodde@ORNL.GOVaJ : Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------    Date: 30 Aug 2001 04:42:10 -0700! From: apuscas@msn.com (Ana-Maria)t( Subject: Setting up Remote Printer Queue= Message-ID: <5b91db83.0108300342.124b56be@posting.google.com>c  
 Greetings!  A I was hoping someone could give me some advice on how to set up a@@ remote print queue under VMS.  We have two VMS systems here that0 coexist with our NT network, all running TCP/IP.  8 I am a beginner with VMS, so please excuse the question!   Anae   ------------------------------  % Date: Thu, 30 Aug 2001 14:10:06 +0200l< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>, Subject: Re: Setting up Remote Printer Queue( Message-ID: <3B8E2D1E.199AC4EE@home.com>  / Check the LPD part of the TCP/IP documentation.g/ Or what's your definition of a "remote queue" ?e Jan-Erik Sderholm.t   Ana-Maria wrote: > C > I was hoping someone could give me some advice on how to set up a8" > remote print queue under VMS.Ana   ------------------------------  % Date: Thu, 30 Aug 2001 09:28:20 -0400-4 From: John Malmberg <Malmberg@dskwld.zko.dec.compaq>, Subject: Re: Setting up Remote Printer Queue4 Message-ID: <3B8E3F74.8070801@dskwld.zko.dec.compaq>   Ana-Maria wrote: > Greetings! > C > I was hoping someone could give me some advice on how to set up awB > remote print queue under VMS.  We have two VMS systems here that2 > coexist with our NT network, all running TCP/IP. > : > I am a beginner with VMS, so please excuse the question!  7 Welcome to OpenVMS, and the question is appropriate for ' this newsgroup, so no excuse is needed.F  : I would first refer you to the OpenVMS FAQ and then to the= "Ask the Wizard" web pages, as what you want to do is common.o6 Both are available from http://www.openvms.compaq.com/    7 A lot depends on how your printers are connected to thet network.  9 If they are directly connected to the network, then it ise9 much better for OpenVMS to print directly to the printersa& instead of going though the NT system.  ; The simplest way to do this is to use DCPS, otherwise knownt9 as DECPrint Supervisor, if the printers are ones that are 6 supported by it.  The right to use the current DCPS is# included with your OpenVMS license.n  9 If you are using the Compaq TCP/IP as your TCP/IP programa9 on your OpenVMS system, and you can not use DCPS for some 7 reason, your next best option would be to use TELNETSYM 8 to the printer, or LPR.  Instructions for this is in the7 TCP/IP documentation also available at the URL I listed-< above.  There is more detail available in the Ask The Wizard that will be useful.  4 If you can not use DCPS to do the printing, you will= probably need to set up a device control library as describedD: in Ask The Wizard.  Topic 1020 is the best starting point.  7 You need a device control library to make sure that the.: special print formatting from a previous job does not stay6 in effect for the new print job you are sending to the printer.  : Device Control libraries are a good idea to use generally,9 but in the case of sharing a printer with Windows NT theyo: are usually required.  OpenVMS print jobs generally expect9 the printer margins and page size to be set to the common.  factory defaults of the printer.  5 For some models of printers, Windows NT changes these 5 margins persistently with each print job.  I have notm found a way to disable this.  6 DCPS comes with prebuilt device control libraries that5 will normally save you the work of building your own.n    7 Printing through LPR to Windows NT should be avoided if ; you have other than extremely simple printing requirements.s  9 The LPD receiver in Windows NT is documented by Microsoftu9 to only accept one print file per print job.  OpenVMS canl( send multiple files with each print job.    6 It is possible to use the Pathworks or Advanced Server9 product on OpenVMS to allow NT systems to print to queuesr on the OpenVMS systems.   4 Other options are to use SAMBA on OpenVMS, but it is5 unsupported freeware, and usually requires a bit more  experience to set up.d   -Johnt malmberg@dskwld.zko.dec.compaq Personal Opinion Onlye   ------------------------------    Date: 30 Aug 2001 07:42:57 -0700- From: merritt.robert@spsd.sk.ca (rob merritt)t3 Subject: Re: still can't get my UCX licensed???????e= Message-ID: <b6bf97d5.0108300642.7f82261d@posting.google.com>   > Ah yes there it is right in front of me, sorry for the copious< postings I think I will sit quietly now and config my system    ` "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3B8DACDC.682CAC72@fsi.net>... > rob merritt wrote: > > ) > > where on the site do you you get themsF > > show license has a list of layered prods but no licenses i can seeO > > register licence I can get the OS license mailed to me but no layered prodsi > > I must be missing somethingy > J > Register for the layered product licenses. They'll be e-mailed to you in/ > one long message. You'll find UCX among them.i   ------------------------------  # Date: Thu, 30 Aug 2001 17:22:45 GMTa2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)3 Subject: Re: still can't get my UCX licensed???????)3 Message-ID: <FDuj7.1006$bB1.45590@news.cpqcorp.net>>  m In article <b6bf97d5.0108291733.32cb5c50@posting.google.com>, merritt.robert@spsd.sk.ca (rob merritt) writes:-` "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3B8C468C.DB096C55@fsi.net>... : Hoff Hoffman wrote:r
 : > [snip]M : >   I am adding a paragraph to the OpenVMS FAQ on this topic, since you are14 : >   not the first to make this particular mistake. : I : It might be a good idea to mention that unlike UN*X and W/9x, W/NT, W2KoE : and so on, TCP/IP is supplied and licensed separately from VMS. ThehA : uniqueness of the paradigm may be a contributing factor in suchl : confusion.  *   You are quite welcome to make that case.  E   TCP/IP is supplied on the OpenVMS distribution media, and the same -H   installation menu that provides OpenVMS provides for the installation E   of TCP/IP Services.  That you don't have it automatically installedn:   when you install (or upgrade) OpenVMS is certainly true.  G   I have commented in various discussions that -- since TCP/IP Services G   client is normally licensed with OpenVMS (though not with the OpenVMS>-   PAK) -- we might be able to simplify this. >  E   I would personally doubt that this change -- even if made, it wouldsC   only affect TCP/IP Services and not the other products  -- would eF   resolve the original (and more general) hobbyist license acquisitionC   discussions, placing a solution more centrally on a change to the G   current pick-two-of-three sets of PAKs model at the hobbyist website.i    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 30 Aug 2001 17:12:25 GMT$ From: Mikec@netins.net (Mike Czizek)( Subject: Tape Parity Error: How to Read?+ Message-ID: <9mls5p$avm$1@ins21.netins.net>   L We have an Alpha server running OpenVMS version 7.1.  We received a 9 track M magnetic tape the other day which has a tape parity error about 80% into the tI file.  We were able to retrieve the 80% but do not know how or if we can n/ retrieve the information past the parity error.n  M I realize that there will be some loss of data but is it possible to somehow y< retrieve the bulk of that 20% of data past the parity error?   -- g Mike Czizek    Iowa Network Services, Inc.l   mikec@netins.com   ------------------------------    Date: 30 Aug 2001 06:04:27 -0700+ From: andreas.kanon@home.se (Andreas Kanon)  Subject: Understanding ast ?= Message-ID: <dbbc6dc6.0108300504.230f8b27@posting.google.com>   A I have tried to find a good explanation what (if any) limitations B there is on the number of AST you can have on a vms (7.2-1) system running on a alpha.,? I have a number of detached processes and they are started withgD $CREPRC and are started with a user other than the system user. DoesF that mean that the limititation of ast:s are the number defined in UAF7 (ASTlm) for that user or is there more to it than that.t  E If it in fact is that the ASTlm for that user is the upper limit willdA that be the total ast count for all processes or for each processt started?  D All input is greatly appreciated since i am trying to understand the way this works.s   /Andreas   ------------------------------    Date: 30 Aug 2001 09:03:53 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)1  Subject: Re: Understanding ast ?3 Message-ID: <k1FBfmQNCmGh@eisner.encompasserve.org>.  k In article <dbbc6dc6.0108300504.230f8b27@posting.google.com>, andreas.kanon@home.se (Andreas Kanon) writes:oC > I have tried to find a good explanation what (if any) limitationsdD > there is on the number of AST you can have on a vms (7.2-1) system > running on a alpha.mA > I have a number of detached processes and they are started with,F > $CREPRC and are started with a user other than the system user. DoesH > that mean that the limititation of ast:s are the number defined in UAF9 > (ASTlm) for that user or is there more to it than that./  F You really need to read the description of the $CREPRC system service.  F file:///VMSDOC073/v73/4527/4527pro_018.html#jun_147 is the location on the latest documentation CDROM.h  A The UAF limit is what you get only if you specify LOGINOUT as the B program to run (to get a process that runs DCL). Otherwise you get? the system default, unless you specify otherwise in the call to7 $CREPRC.  B But see the part of the description called "Use of the Quota List" for more details.m  G > If it in fact is that the ASTlm for that user is the upper limit willtC > that be the total ast count for all processes or for each processi
 > started?    ASTLM is not a deductible quota.  F > All input is greatly appreciated since i am trying to understand the > way this works.H  F You really need to read the description of the $CREPRC system service.   ------------------------------  # Date: Thu, 30 Aug 2001 15:48:47 GMTn= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)   Subject: Re: Understanding ast ?0 Message-ID: <00A014D2.3139F162@SendSpamHere.ORG>  c In article <k1FBfmQNCmGh@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:tl >In article <dbbc6dc6.0108300504.230f8b27@posting.google.com>, andreas.kanon@home.se (Andreas Kanon) writes:D >> I have tried to find a good explanation what (if any) limitationsE >> there is on the number of AST you can have on a vms (7.2-1) systemG >> running on a alpha.B >> I have a number of detached processes and they are started withG >> $CREPRC and are started with a user other than the system user. Does I >> that mean that the limititation of ast:s are the number defined in UAF : >> (ASTlm) for that user or is there more to it than that. > G >You really need to read the description of the $CREPRC system service.  > G >file:///VMSDOC073/v73/4527/4527pro_018.html#jun_147 is the location onA  >the latest documentation CDROM. >uB >The UAF limit is what you get only if you specify LOGINOUT as theC >program to run (to get a process that runs DCL). Otherwise you get-@ >the system default, unless you specify otherwise in the call to	 >$CREPRC.a > C >But see the part of the description called "Use of the Quota List"a >for more details.  E You mean that the optional QUOTA parameter isn't there *just* to make % the $CREPRC parameter list larger! ;)r   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMR            nJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  # Date: Thu, 30 Aug 2001 17:33:40 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)  Subject: Re: Understanding ast ?3 Message-ID: <UNuj7.1010$bB1.45370@news.cpqcorp.net>o  k In article <dbbc6dc6.0108300504.230f8b27@posting.google.com>, andreas.kanon@home.se (Andreas Kanon) writes:e  @ :I have a number of detached processes and they are started withE :$CREPRC and are started with a user other than the system user. DoespG :that mean that the limititation of ast:s are the number defined in UAF 8 :(ASTlm) for that user or is there more to it than that.  H   Detached process quotas get what you set via the $creprc quota array, C   or (if not specified or specified below the system minimums) the nC   process get the system defaults and will get at least the system nA   minimums.  (IIRC, the authorization file is not involved in thepG   detached process quota settings, even if you specify the AUTH flag --uE   to get the SYS$SCRATCH and SYS$LOGIN logical names defined based one%   the target user profile in SYSUAF.)n  I   When presented with a quota argument on an OpenVMS system service, you nF   will always want to explicitly use it.  Why?  Because if you don't, F   your application will function (or not function) at the whim of the    system-wide quota settings.e  H   In SYSGEN/SYSMAN, you can view the system-wide process quota settings 6   and process quota minimums via the SHOW/PQL command.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 30 Aug 2001 09:57:44 -07001 From: alex.Feliziani@space.gc.ca (Alex Feliziani)pR Subject: What are the exact steps in order to add a user account with VAX-VMS v6.0= Message-ID: <2f6dcd69.0108300857.36d9dbdf@posting.google.com>t   Hi,   E I would really appreciate it if someone would give me the exact steps D in order to add a user account on a vax station 4000-90 with VAX-VMS v6.0 operating system.   Thanks!    Alex   ------------------------------  % Date: Thu, 30 Aug 2001 13:45:18 -0400   From: jamese@beast.dtsw.army.milV Subject: Re: What are the exact steps in order to add a user account with VAX-VMS v6.00 Message-ID: <01083013451804@beast.dtsw.army.mil>  M Didier Morandi <Didier.Morandi@gmx.ch> wrote in <3B8E7A5E.34873648@gmx.ch> on7  Thu, 30 Aug 2001 19:39:41 +0200:   > Alex Feliziani wrote:: > >  > > Hi,e > > I > > I would really appreciate it if someone would give me the exact steps2H > > in order to add a user account on a vax station 4000-90 with VAX-VMS > > v6.0 operating system. > >  > > Thanks!n > >  > > Alex >  > step one:  > L > $ if f$search("sys$manager:adduser.com) .nes. "" then @sys$manager:adduser  N   $ if f$search("sys$examples:adduser.com) .nes. "" then @sys$examples:adduser  $ On our system it is in sys$examples.  : Ed James                           ed.james@telecomsys.com5 TeleCommunications Systems, Inc.   voice 410-295-1919n; 2024 West Street, Suite 300              800-810-0827 x1919 5 Annapolis, MD 21401-3556           fax   410-280-1094.   ------------------------------  + Date: Thu, 30 Aug 2001 17:44:01 +0000 (UTC)r' From: david20@alpha2.mdx.ac.uk (D.Webb) V Subject: Re: What are the exact steps in order to add a user account with VAX-VMS v6.0+ Message-ID: <9mlu11$mko$1@aquila.mdx.ac.uk>n  q In article <2f6dcd69.0108300857.36d9dbdf@posting.google.com>, alex.Feliziani@space.gc.ca (Alex Feliziani) writes:  >Hi,   > F >I would really appreciate it if someone would give me the exact stepsE >in order to add a user account on a vax station 4000-90 with VAX-VMSr >v6.0 operating system.h >g >Thanks! >y >Alexr    3 Look in sys$examples for a file called adduser.com.I  9 I'm pretty sure it should exist on a VAX running VMS 6.0.o  7 Then either read it or  run it from the system account.o   @sys$examples:adduser.com     ; I've never actually run this so can't totally guarantee it.E  0 The basic steps to creating a VMS account are :-  1 1)  Login to a privileged account such as system.i 2)  SET DEFAULT to SYS$SYSTEM  3)  RUN AUTHORIZE   U 4)  UAF>ADD fred99/uic=[1000,1]/password=xxxxxx/flag=nodisuser/dev=disk1/dir=[fred99]e     UAF>EXIT  N     Creates a user called fred99 with a uic of [1000,1] (Group 1000, member 1)+     with a home directory on disk1:[fred99]1  5     This does not actually create the home directory.g    , 5)  If disk quotas are enabled on disk1 then         mcr diskquotae     DISKQ> use disk1*     DISKQ> add/perm=20000/over=1000 fred99     DISKQ> exitn  6     Grants fred99 20000 blocks (10M) of space on disk1  ( 6)  create/dir disk1:[fred99]/own=fred99  B     Actually creates the home directory and makes fred99 the owner      # Fred99 should now be able to login.oL The account created should have the minimum privs (TMPMBX and NETMBX) unless1 someone has altered the template account DEFAULT.c    M However you really need to read the manuals which are available online see :-t  W http://www.openvms.compaq.com:8000/72final/6017/6017pro_contents_002.html#toc_chapter_6     J The differences between VMS 6.0 and later versions of VMS in this area are minimal.    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Thu, 30 Aug 2001 19:39:41 +02007, From: Didier Morandi <Didier.Morandi@gmx.ch>Y Subject: Re: What are the exact steps in order to add a user account with VAX-VMS v6.0 v6 & Message-ID: <3B8E7A5E.34873648@gmx.ch>   Alex Feliziani wrote:  >  > Hi,x > G > I would really appreciate it if someone would give me the exact steps F > in order to add a user account on a vax station 4000-90 with VAX-VMS > v6.0 operating system. > 	 > Thanks!  >  > Alex  	 step one:o  J $ if f$search("sys$manager:adduser.com) .nes. "" then @sys$manager:adduser   Hope that helps.7 If you do not have this procedure, I'll send it to you.o   D.   ------------------------------    Date: 30 Aug 2001 10:12:41 -0700- From: afeldman@gfigroup.com (Alan E. Feldman)d0 Subject: Re: Why continue with OpenVMS / Compaq?= Message-ID: <af1e4ce6.0108300912.10acadd8@posting.google.com>   d Chuck McCrobie <mccrobie@cablespeed.com> wrote in message news:<3B8B08E4.886C2B44@cablespeed.com>...H > Why do I persist in reading this newsgroup?  Its just plain depressing > :( > G > Between the constant rants and raves about Compaq and the messages ofaA > Compaq's inadequancies, I've given up on OpenVMS and all CompaqaI > equipment.  Why just today I read about Compaq's backhanded approach ofN > killing its R&D department :(I > H > My suggestion to you die-hards is to abandon OpenVMS, Tru64, and Alpha > _IMMEDIATELY_.    B And just who are you? Perhaps you're working for the competition?!  B Well, the fewer VMS customers there are, the eaiser it will be forE Compaq to pull the plug on VMS (and all that money wasted on the portrD thereof). It sounds like you're trying to start a run on the bank. AD self-fulfilling prophecy. Hey, I hear the banks are not trustworthy. Better pull your money out NOW!   7 >Go call Sun or IBM - at least those companies want andeF > understand enterprise customers.  Better yet, run Windows 2000/XP onH > Dell machines - that should hasten Compaq's demise into the bankruptcy	 > courts!b  4 Yep, rush into inferior equipment. O, kaaayyyyyyyyy.   > G > I'm wondering just why anyone would continue/start another product onpG > OpenVMS or Tru64?  Perhaps to gouge the OpenVMS suckers^H^H^H^H^H^H^HjD > die-hards with high prices before Compaq pulls the plug?  FirewireG > support looked like a good niche product for OpenVMS, but why bother?i > I > So, even though I'm a lurker here, I'm signing off and saying good luck 1 > to all you talented but betrayed professionals.r  : Yeah, thanks for feeding the run-on-the-bank syndrome. :-|  8 Fortunately, AFAWK, they are working on the port to IPF.   Disclaimer: JMHO     Alan E. Feldmanr afeldman@gfigroup.coms   ------------------------------  % Date: Thu, 30 Aug 2001 12:46:47 +0400T) From: "S_Svettsov" <S_Svettsov@stinol.ru>S0 Subject: onnect  Oracle 7.2.3 and DEC Rdb 6.1 ?H Message-ID: <EC0DB93033E9D411B47100A0C945C0796E9F4C@exchange.stinol.int>  
 Hello All.   Prompt, please! % DEC and OpenVMS so exotic for us ....l  F 1. What software it is possible to connect databases Oracle 7.2.3 ( OSI HP-UNIX B.10.20) and DEC Rdb 6.1 (OpenVMS6.2-1H3)? Where it can be found?i  B 2. We use a control system on base old DEC AlphaStation 200 4/233.H Gradually something fails. Than modern it is possible to replace network@ Bridges DECbridge150 and streamer DEC TLZ07 (SCSI-2, bands DDS)?     Regards, Sergej Svettsov Lipetsk, Russiae   ------------------------------    Date: 30 Aug 2001 15:19:19 +0300& From: costello@iki.fi (Antti Jrvinen)4 Subject: Re: onnect  Oracle 7.2.3 and DEC Rdb 6.1 ?3 Message-ID: <m31yltagfs.fsf@muikku.baana.suomi.net>   + "S_Svettsov" <S_Svettsov@stinol.ru> writes:aH > 1. What software it is possible to connect databases Oracle 7.2.3 ( OSK > HP-UNIX B.10.20) and DEC Rdb 6.1 (OpenVMS6.2-1H3)? Where it can be found?n  B If you upgrade your rdb to 7.something, you can buy sql*net for itE and it will begin to look like oracle database and you can use oraclez+ tools to select/insert/update/etc the rdb. i  F If you have data units (records?) of known size and format and contentD to be transferred from one database to another, I'd go on doing two J small programs; first one selects non-transferred data from first database? (and you need to implement a way of figuring out which data has9E changed or is new), then makes records that would be in ASCII format, B then send the record to another host, tcp/ip is available for bothD operating systems, the other end reads and parses the ASCII format, K inserts/updates/deletes the data accordingly and sends an acknowledgement;  G after ack is received in sending end, the data is marked as having beenaD sent. This is easy to implement (say, no more that 100 lines of codeC in C) but suitable only for transferring fixed-content records..in n0 industrial applications this is often the case.    -- n Antti Jrvinen, costello@iki.fif5             "concerto for two faggots and orchestra" o   ------------------------------   End of INFO-VAX 2001.482 ************************