1 INFO-VAX	Thu, 30 Aug 2001	Volume 2001 : Issue 481       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: 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: 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: C language functionality changed? % Re: C language functionality changed? % Re: C language functionality changed? % Re: C language functionality changed? 7 Compiled Languages (Was: e: My VMS Wish List (features)  Complete Alpha for USD650 ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update 2 Re: CSWS, MOD_PERL - anyone have HELLO.PM working?% Re: Does OVMS 7.1 support DAT-Drives? + DTSS Couriers - syntax problems in NCL HELP / Re: DTSS Couriers - syntax problems in NCL HELP  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 Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium FTP problems - please advise! ! Re: FTP problems - please advise!  Re: GNU screen for AXP/VMS Re: GNU screen for AXP/VMS' Re: Hobbyist/Private license og DECdoc. ' Re: Hobbyist/Private license og DECdoc. ' Re: Hobbyist/Private license og DECdoc. E Re: How to quickly replicate a global section on another network node E Re: How to quickly replicate a global section on another network node E Re: How to quickly replicate a global section on another network node  Re: IA-64 Galaxies. Re: IA-64 Galaxies (was: EV7 will never ship?). Re: IA-64 Galaxies (was: EV7 will never ship?)  Lista de Discusion DEC Argentina; Re: Looking for Digital Serial Number Identication Resource  Re: Mark Twain Promo MicroVAX II - Boot problems  Re: MicroVAX II - Boot problems  Re: MicroVAX II - Boot problems  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: 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: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  OT: Olivetti Web Appliance Re: Oxygen on OpenVMS V7.3( Q: howto get proc name from library func, Re: Q: howto get proc name from library func, Re: Q: howto get proc name from library func, Re: Q: howto get proc name from library func, Re: Q: howto get proc name from library func, Re: Q: howto get proc name from library funcG robustness and maturity (was Re: Conference: CETS-2001 Detailed Update) L Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!L Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!* Re: still can't get my UCX licensed???????* Re: still can't get my UCX licensed???????$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64 Time offset wrong in VMS Mail? Re: V5.5-2 Password Recovery8 Re: VMS's Last Stand or Conspiracy/Stupidity Theories...# Re: VMS/Alpha backend for GCC 3.x ? # Re: VMS/Alpha backend for GCC 3.x ? # Re: VMS/Alpha backend for GCC 3.x ? ' Re: Why continue with OpenVMS / Compaq? ' Re: Why continue with OpenVMS / Compaq? ' Re: Why continue with OpenVMS / Compaq? ' Re: Why continue with OpenVMS / Compaq?   F ----------------------------------------------------------------------  # Date: Thu, 30 Aug 2001 01:24:44 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>1 Subject: Re: 100 million sale for Compaq to Sabre 7 Message-ID: <wBgj7.1547$jd.300526@typhoon1.gnilink.net>   F > I wonder if VMS was even considered by SABRTE and/or Compaq for this	 contract.   L Unlikely since they wanted five 9's reliability. To my knowledge there is noK hardware currently being manufactured for either VMS or Tru64 that provides L that level of reliability.  You can build high availability Wildfires (thereD will be a session or BOF at CETS) but you can't build fault tolerant Wildfires...   ------------------------------  % Date: Wed, 29 Aug 2001 22:03:44 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: 100 million sale for Compaq to Sabre , Message-ID: <3B8D9EFA.2A07256D@videotron.ca>   Jeff Killeen wrote: N > Unlikely since they wanted five 9's reliability. To my knowledge there is noM > hardware currently being manufactured for either VMS or Tru64 that provides N > that level of reliability.  You can build high availability Wildfires (thereF > will be a session or BOF at CETS) but you can't build fault tolerant > Wildfires...  I Well, if the predecessor was IBM mainframes with MVS, and VMS wasn't good L enough to replace the IBM mainframe, and they had to go to Tandem, then what does it say for VMS ?    ------------------------------  % Date: Wed, 29 Aug 2001 20:07:07 -0600 % From: Dan O'Reilly <dano@process.com> 1 Subject: Re: 100 million sale for Compaq to Sabre B Message-ID: <5.1.0.14.2.20010829200545.00af24f8@ntbsod.psccos.com>  & At 08:03 PM 8/29/2001, JF Mezei wrote: >Jeff Killeen wrote:K > > Unlikely since they wanted five 9's reliability. To my knowledge there   > is no O > > hardware currently being manufactured for either VMS or Tru64 that provides J > > that level of reliability.  You can build high availability Wildfires  > (thereH > > will be a session or BOF at CETS) but you can't build fault tolerant > > Wildfires... > J >Well, if the predecessor was IBM mainframes with MVS, and VMS wasn't goodM >enough to replace the IBM mainframe, and they had to go to Tandem, then what  >does it say for VMS ?  K It says exactly what Jeff said above: "To my knowledge there is no hardware G currently being manufactured for either VMS or Tru64 that provides that L level of reliability."  Note the use of the word "hardware", not "software".     ------I +-------------------------------+---------------------------------------+ I | Dan O'Reilly                  |                                       | I | Principal Engineer            |  "Why should I care about posterity?  | I | Process Software              |   What's posterity ever done for me?" | I | http://www.process.com        |                    -- Groucho Marx    | I +-------------------------------+---------------------------------------+    ------------------------------  # Date: Thu, 30 Aug 2001 03:26:33 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>1 Subject: Re: 100 million sale for Compaq to Sabre 7 Message-ID: <Jnij7.1680$jd.326280@typhoon1.gnilink.net>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B8D9EFA.2A07256D@videotron.ca... > Jeff Killeen wrote: J > > Unlikely since they wanted five 9's reliability. To my knowledge there is no F > > hardware currently being manufactured for either VMS or Tru64 that providesI > > that level of reliability.  You can build high availability Wildfires  (thereH > > will be a session or BOF at CETS) but you can't build fault tolerant > > Wildfires... > K > Well, if the predecessor was IBM mainframes with MVS, and VMS wasn't good I > enough to replace the IBM mainframe, and they had to go to Tandem, then  what > does it say for VMS ?   I Nothing - period - How do you know that VMS wasn't good enough to replace J MVS?  All you know is they choose NSK.  They could have chosen NSK becauseJ of they wanted something better. It is very false logic what was suggestedF above.  It could be that VMS is better than MVS but neither MVS or VMS supplied what they wanted.  K If someone shifts from a Ford Crown Victoria to a Lexus does that than mean G that a Toyota Camry isn't good enough to replace a Ford Crown Victoria?   L It amazes me the few in this newsgroup who see everything as a proving theirC negative viewpoint of Compaq's handling of VMS.  It rained today in G Houston - that proves the point of view Compaq is trying to kill VMS...    ------------------------------  % Date: Thu, 30 Aug 2001 00:31:43 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: 100 million sale for Compaq to Sabre , Message-ID: <3B8DC1AE.2C981FB3@videotron.ca>   Dan O'Reilly wrote: M > It says exactly what Jeff said above: "To my knowledge there is no hardware I > currently being manufactured for either VMS or Tru64 that provides that N > level of reliability."  Note the use of the word "hardware", not "software".  K Folks buy a solution. That is the combination of hardware and software.  If H Sabre was previously on IBM mainframes, isn't that something which a VMSJ solution could have handled in terms of reliability/availability and whereG Tandem offered much more than necessary (compared to the IBM solution).   J If Tandem will always be pitched to customers who want a high availability% solution, where does that leave VMS ?   : Does VMS really have a place between Tandem, Unix and NT ?   ------------------------------    Date: 29 Aug 2001 23:51:31 -0500+ From: young_r@encompasserve.org (Rob Young) 1 Subject: Re: 100 million sale for Compaq to Sabre 3 Message-ID: <I3b37kzuE$If@eisner.encompasserve.org>   \ In article <3B8DC1AE.2C981FB3@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Dan O'Reilly wrote: N >> It says exactly what Jeff said above: "To my knowledge there is no hardwareJ >> currently being manufactured for either VMS or Tru64 that provides thatO >> level of reliability."  Note the use of the word "hardware", not "software".  > M > Folks buy a solution. That is the combination of hardware and software.  If J > Sabre was previously on IBM mainframes, isn't that something which a VMSL > solution could have handled in terms of reliability/availability and whereI > Tandem offered much more than necessary (compared to the IBM solution).  >   H 	Someone (W. Webb?) mentioned recently where VMS replaced IBM mainframes> 	, it does happen.  It didn't happen in this case.  Their bid @ 	criteria appears to have shut out a lot of players if they were 	5 9s on the hardware.   > L > If Tandem will always be pitched to customers who want a high availability' > solution, where does that leave VMS ?  >   > 	In places where Tandem can't or won't meet the criteria.  IBMB 	Global solutions bid a VMS cluster , Compaq bid a Tandem solutionD 	and the VMS cluster won out... according to Terry Shannon.  PerhapsG 	this customer liked some capability.  Maybe a split datacenter cluster D 	with volume shadowing across datacenters.  Who knows?  "The Shannon 	knows."  < > Does VMS really have a place between Tandem, Unix and NT ?   	Between?  How about alongside?    				Rob    ------------------------------    Date: 29 Aug 2001 16:29:10 -0700' From: tej@tbirdpac.com (Eric Josephson)  Subject: Re: 16 VLCs for sale 4 Message-ID: <slrn9oqum6.t9j.tej@calvin.tbirdpac.com>  A 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 the  1 "as-is" section.  They had no mice or MMJ cables.    Regards,   --! Eric Josephson <tej.tbirdpac.com>   B On Thu, 23 Aug 2001 15:45:19 GMT, inge@tarboo <inge@tarboo> wrote:I >Trying desperately to figure out what I could do with them.  Saw a stack I >of 16 VAXstation 4000 VLCs at REPC (PC recycler) in Tukwilla, WA.  Don't J >know the price or configurations.  No monitors, keyboards or mice. My '95J >SOC shows VLCs with 535 Mbyte RZ23s, 8 megs of memory (expandable to 24),H >6.2 VUPs. SCSI connector on back, MMJ console port, ethernet.  Could be >empty cases for all I know.   ------------------------------  + Date: Wed, 29 Aug 2001 19:05:59 +0000 (UTC) / From: Sander Vesik <sander@haldjas.folklore.ee>  Subject: Re: alpha - ia64 1 Message-ID: <999111966.87560@haldjas.folklore.ee>   2 In comp.arch Smitty <someone@microsoft.com> wrote:  ; > "Peter Watkinson" <peterw@u.genie.co.uk> wrote in message 3 > news:3b8c1543.16021359@news.cable.ntlworld.com...  >> >> >> Hi, >>H >> One thing that confuses me about the intel swallowup of Alpha is thatD >> with IA64 being EPIC and not RISC and AMD bringing out the Hammer  E > The EPIC technology used in the IA-64 Itanium's is superior to RISC  > architechure.   G Ahem. Any chance of the superior technology becoming faster than Sparc,  the well-known slowest RISC?   --   	Sander    +++ Out of cheese error +++    ------------------------------  % Date: Wed, 29 Aug 2001 15:17:00 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: alpha - ia64 ( Message-ID: <9mjf21$oa7$1@pyrite.mv.net>  : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:DmfJGVf$FU$u@eisner.encompasserve.org... < > In article <3B8CECB0.735057C8@uk.sun.com>, andrew harrison" <andrew.nospam@uk.sun.com> writes: > >  > > Bill Todd wrote: > >>6 > >> "Smitty" <someone@microsoft.com> wrote in message? > >> news:yRXi7.159620$Xr6.898841@news-server.bigpond.net.au...  > >> > >> ... > >>J > >> > The EPIC technology used in the IA-64 Itanium's is superior to RISC > >> > architechure. > >>I > >> Thanks:  it's really a relief to have an authoritative source put an  end to > >> all this speculation. > >> > > A > > Now we know where Compaqs assertion that IA64 would be better < > > 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 now ) > that Compaq says their future is IA64 ?   K Yup - glad there's finally a point we can agree on.  Too bad he didn't heed K my suggestion back at the beginning of all this that this might be a family K squabble he should stay out of:  I wouldn't object to a lot of his comments . if they weren't so transparently self-serving.   - bill   ------------------------------  + Date: Wed, 29 Aug 2001 19:23:49 +0000 (UTC) $ From: lindahl@pbm.com (Greg Lindahl) Subject: Re: alpha - ia64 , Message-ID: <9mjfg5$o25$1@feed.textport.net>  F >> The EPIC technology used in the IA-64 Itanium's is superior to RISC >> architechure. > H >Ahem. Any chance of the superior technology becoming faster than Sparc, >the well-known slowest RISC?   F While this looks like a completely pointless thread, it's worth notingF that on a significant class of applications (floating point), standardB benchmarks show that the IA-64 is significantly faster than Sparc.  A If you only care about integer, or big SMP machines, then say so. B "faster" doesn't mean anything if you don't make it more specific.   g    ------------------------------   Date: 29 Aug 2001 19:38:25 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64 0 Message-ID: <9mjgbh$gki$1@pegasus.csx.cam.ac.uk>  , In article <9mjfg5$o25$1@feed.textport.net>,% Greg Lindahl <lindahl@pbm.com> wrote: G >>> The EPIC technology used in the IA-64 Itanium's is superior to RISC  >>> architechure.N >>I >>Ahem. Any chance of the superior technology becoming faster than Sparc,o >>the well-known slowest RISC? > G >While this looks like a completely pointless thread, it's worth notingeG >that on a significant class of applications (floating point), standardaC >benchmarks show that the IA-64 is significantly faster than Sparc.  >eB >If you only care about integer, or big SMP machines, then say so.C >"faster" doesn't mean anything if you don't make it more specific.   C Strictly, this relates more to the coding style than the arithmetic B as such, but predictable (and hence optimisable) coding styles are/ associated with floating-point use, as you say.e  B The current information about McKinley is interesting, too.  Intel@ have said that it will appear at 1 GHz and be c. 70% faster than? the Itanic on SpecInt - which will make it comparable to only ad? 2 GHz Pentium 4 which, by then, should be available in 2.2 GHz.f? But a factor of 3 more memory bandwidth could mean that it is arC factor of 2 faster on SpecFP, which would make it a most impressiveU	 HPC chip.   B Nobody wants to run GUIs, databases, network management and things  like that on IA-64, do they? :-)     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: Wed, 29 Aug 2001 20:19:24 +0000 (UTC)?/ From: Sander Vesik <sander@haldjas.folklore.ee>u Subject: Re: alpha - ia64N1 Message-ID: <999116371.18600@haldjas.folklore.ee>L  2 In comp.arch Greg Lindahl <lindahl@pbm.com> wrote:G >>> The EPIC technology used in the IA-64 Itanium's is superior to RISCv >>> architechure.i >>I >>Ahem. Any chance of the superior technology becoming faster than Sparc,  >>the well-known slowest RISC?  H > While this looks like a completely pointless thread, it's worth notingH > that on a significant class of applications (floating point), standardD > benchmarks show that the IA-64 is significantly faster than Sparc.  D Oh ok, ok, ok. It's not as if epic technology being superior to riscE architecture (yes, it is comparing technology to architecture) is all  that meaningful statement.  C > If you only care about integer, or big SMP machines, then say so.eD > "faster" doesn't mean anything if you don't make it more specific.  F Ceese, it was a tongue in cheek reply to an obvious troll. Next thing D you know people start pointing me towards i960 or arm or whatever as4 not having as fast implementations as say usparciii.   > ga   -- n 	Sanderd   +++ Out of cheese error +++6   ------------------------------  % Date: Wed, 29 Aug 2001 13:31:05 -0700e0 From: "Brig Campbell" <brig.campbell@unisys.com> Subject: Re: alpha - ia64N- Message-ID: <9mjje0$m9r$1@mail.pl.unisys.com>o  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messagep* news:9mjgbh$gki$1@pegasus.csx.cam.ac.uk... > 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 ayA > 2 GHz Pentium 4 which, by then, should be available in 2.2 GHz.yA > But a factor of 3 more memory bandwidth could mean that it is ayE > factor of 2 faster on SpecFP, which would make it a most impressiveS > HPC chip.e >r  = I believe Intel demonstrated a P4 at 3.5Ghz during IDF today.t   -brige   ------------------------------   Date: 29 Aug 2001 20:36:46 GMT/ From: mccalpin@gmp246.austin.ibm.com (McCalpin)i Subject: Re: alpha - ia64t1 Message-ID: <9mjjou$qle$1@ausnews.austin.ibm.com>   O In article <9mjf21$oa7$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:g >p+ >I wouldn't object to a lot of his commentsp/ >if they weren't so transparently self-serving.t  = On the other hand, don't you prefer self-serving people to beR2 transparent?  It does limit confusion that way.... -- l9 John D. McCalpin, Ph.D.           mccalpin@austin.ibm.com/F Senior Technical Staff Member     IBM POWER Microprocessor Development-     "I am willing to make mistakes as long asr1      someone else is willing to learn from them."h   ------------------------------  + Date: Wed, 29 Aug 2001 21:02:11 +0000 (UTC) / From: Sander Vesik <sander@haldjas.folklore.ee>i Subject: Re: alpha - ia64?2 Message-ID: <999118937.563062@haldjas.folklore.ee>  6 In comp.arch Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:. > In article <9mjfg5$o25$1@feed.textport.net>,' > Greg Lindahl <lindahl@pbm.com> wrote: H >>>> The EPIC technology used in the IA-64 Itanium's is superior to RISC >>>> architechure. >>>tJ >>>Ahem. Any chance of the superior technology becoming faster than Sparc, >>>the well-known slowest RISC?- >>H >>While this looks like a completely pointless thread, it's worth notingH >>that on a significant class of applications (floating point), standardD >>benchmarks show that the IA-64 is significantly faster than Sparc. >>C >>If you only care about integer, or big SMP machines, then say so.hD >>"faster" doesn't mean anything if you don't make it more specific.  E > Strictly, this relates more to the coding style than the arithmeticrD > as such, but predictable (and hence optimisable) coding styles are1 > associated with floating-point use, as you say.s  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 a1  E The interesting question is - shall we take it at face value or scaleo8 down based on past performance vs. claims of perfomance?  A > 2 GHz Pentium 4 which, by then, should be available in 2.2 GHz.rA > But a factor of 3 more memory bandwidth could mean that it is a E > factor of 2 faster on SpecFP, which would make it a most impressivet > HPC chip.b  D > Nobody wants to run GUIs, databases, network management and things" > like that on IA-64, do they? :-)  / Can I buy a non-trivially sized IA64 somewhere?n  
 > 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 334679c   -- 1 	Sandern   +++ Out of cheese error +++s   ------------------------------  + Date: Wed, 29 Aug 2001 21:13:54 +0000 (UTC)9$ From: lindahl@pbm.com (Greg Lindahl) Subject: Re: alpha - ia64t, Message-ID: <9mjlui$2jl$1@feed.textport.net>  2 In article <999118937.563062@haldjas.folklore.ee>,1 Sander Vesik  <sander@haldjas.folklore.ee> wrote:   E >> Nobody wants to run GUIs, databases, network management and things # >> like that on IA-64, do they? :-)F > 0 >Can I buy a non-trivially sized IA64 somewhere?  B 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 ism) different today. But you didn't say that.s   gx   ------------------------------   Date: 29 Aug 2001 22:00:01 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64a0 Message-ID: <9mjol1$mn6$1@pegasus.csx.cam.ac.uk>  , In article <9mjlui$2jl$1@feed.textport.net>,% Greg Lindahl <lindahl@pbm.com> wrote:-3 >In article <999118937.563062@haldjas.folklore.ee>, 2 >Sander Vesik  <sander@haldjas.folklore.ee> wrote: > F >>> Nobody wants to run GUIs, databases, network management and things$ >>> like that on IA-64, do they? :-) >>1 >>Can I buy a non-trivially sized IA64 somewhere?o >sC >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 is* >different today. But you didn't say that.  A Origin 3000s go a bit bigger than that, but you may be right thatl4 the bigger ones are not yet shipping.  I don't know.     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 334679y   ------------------------------   Date: 29 Aug 2001 21:30:19 GMT/ From: mccalpin@gmp246.austin.ibm.com (McCalpin)l Subject: Re: alpha - ia64a1 Message-ID: <9mjmtb$i00$1@ausnews.austin.ibm.com>i  0 In article <9mjgbh$gki$1@pegasus.csx.cam.ac.uk>,) Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:l >fC >The current information about McKinley is interesting, too.  Intel A >have said that it will appear at 1 GHz and be c. 70% faster thant@ >the Itanic on SpecInt - which will make it comparable to only a@ >2 GHz Pentium 4 which, by then, should be available in 2.2 GHz.@ >But a factor of 3 more memory bandwidth could mean that it is aD >factor of 2 faster on SpecFP, which would make it a most impressive
 >HPC chip.  : 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 peak7 bandwidth, along with a significant (~40%,IIRC) latencyw= reduction, improved the sustained bandwidth by nearly 2x, bute> only improved the uniprocessor SPECfp2000 number by about 20%.  $ machine			STREAM BW	SPECfp2000	ratio4 SGI Origin3800/500        ~715		   463          1.54< SGI Origin2800/500         388             386          1.01  > By comparison, the Itanium already has more bandwidth per unit> of SPECfp2000 than the Origin3800 has, so one would expect the upside to be even smaller.    $ machine			STREAM BW	SPECfp2000	ratio2 Itanium 800MHz/4MB L2	  1403             703		2.00  B Assuming 1 GHz gives McKinley 25% on its clock speed, and from theB results above, I would estimate that it gets at most an additionalA 20% or so from tripling the bandwidth (2.4x on a clock-normalizedn@ basis), for a net of about 1.5x.   However, McKinley is going toB have a smaller L2 (not even Intel can put 4 MB on-chip this year),C and Itanium pays about a 7% penalty in SPECfp2000 for cutting the 4eB MB off-chip cache in two.   This leaves McKinley with about a 1.4xC multiplier, before corrections for microarchitectural improvements,h. leading to a SPECfp2000 estimate of about 980.    @ More bandwidth would certainly help the scaling for SPECfp_rate,=  of course.  The 4-way Dell Itanium box only gets a 2.8x rate1= improvement when using all four cpus.  The McKinley bandwidthRB improvements will certainly help here, giving a scaling of perhapsB 3.3x on four processors (analysis left to the reader).  The net onB a 4-way might then be 1.4*(3.3/2.8) = 1.65x, which is still a longC way from 2.0x per cpu....  Itanium's performance per MHz is already B pretty good on SPECfp2000 -- I don't expect the microarchitecturalC improvements in McKinley to provide the additional 20% boost needed ? to get to a 2x throughput ratio for SPECfp_rate2000, or the 40%i> boost needed to get to a 2x uniprocessor performance ratio for SPECfp2000.  -- o9 John D. McCalpin, Ph.D.           mccalpin@austin.ibm.comiF Senior Technical Staff Member     IBM POWER Microprocessor Development-     "I am willing to make mistakes as long ase1      someone else is willing to learn from them."    ------------------------------   Date: 29 Aug 2001 22:07:46 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64o0 Message-ID: <9mjp3i$n3r$1@pegasus.csx.cam.ac.uk>  1 In article <9mjmtb$i00$1@ausnews.austin.ibm.com>,p) McCalpin <mccalpin@austin.ibm.com> wrote:i1 >In article <9mjgbh$gki$1@pegasus.csx.cam.ac.uk>, * >Nick Maclaren <nmm1@cus.cam.ac.uk> wrote: >>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 alA >>2 GHz Pentium 4 which, by then, should be available in 2.2 GHz. A >>But a factor of 3 more memory bandwidth could mean that it is aeE >>factor of 2 faster on SpecFP, which would make it a most impressive	 >>HPC chip.- >-; >I don't see how increasing the bandwidth is going to help r* >the SPECfp2000 performance significantly. >:= >Consider the MIPS-based systems from SGI.  Doubling the peakt8 >bandwidth, along with a significant (~40%,IIRC) latency> >reduction, improved the sustained bandwidth by nearly 2x, but? >only improved the uniprocessor SPECfp2000 number by about 20%.a  @ I was under the impression that the Itanium was fairly seriouslyB limited by bandwidth to cache, which is a rather different problemA to the one resolved by going from the Origin 2000 to Origin 3000.e@ But I could well be wrong, as my information is second-hand, and  I haven't checked it personally.  C >Assuming 1 GHz gives McKinley 25% on its clock speed, and from theVC >results above, I would estimate that it gets at most an additionalkB >20% or so from tripling the bandwidth (2.4x on a clock-normalizedA >basis), for a net of about 1.5x.   However, McKinley is going todC >have a smaller L2 (not even Intel can put 4 MB on-chip this year),hD >and Itanium pays about a 7% penalty in SPECfp2000 for cutting the 4C >MB off-chip cache in two.   This leaves McKinley with about a 1.4xdD >multiplier, before corrections for microarchitectural improvements,/ >leading to a SPECfp2000 estimate of about 980.   > Still not bad, but not the same as 1400 :-)  You could well be> correct, as you have clearly looked at it in more depth than I: have.  So thanks very much for the more reliable estimate!     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 334679o   ------------------------------  + Date: Wed, 29 Aug 2001 22:17:55 +0000 (UTC)f7 From: dsiebert@excisethis.khamsin.net (Douglas Siebert)  Subject: Re: alpha - ia64s+ Message-ID: <9mjpmj$5fh$1@sword.avalon.net>-  2 "Brig Campbell" <brig.campbell@unisys.com> writes:  6 >"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message+ >news:9mjgbh$gki$1@pegasus.csx.cam.ac.uk...  >>E >> The current information about McKinley is interesting, too.  Intel$C >> have said that it will appear at 1 GHz and be c. 70% faster thannB >> the Itanic on SpecInt - which will make it comparable to only aB >> 2 GHz Pentium 4 which, by then, should be available in 2.2 GHz.B >> But a factor of 3 more memory bandwidth could mean that it is aF >> factor of 2 faster on SpecFP, which would make it a most impressive >> HPC chip. >>  > >I believe Intel demonstrated a P4 at 3.5Ghz during IDF today.    E Yes, it was their usual "pick the fastest chip we have in the lab andtF use liquid nitrogen to cool it" demo.  I don't know that it was liquidF nitrogen, but it has been reported by several sources it was _not_ air cooled.s  A At any rate, even if Intel could produce 3.5GHz P4s on their .13u.B process to sell in some quantity early next year, they won't.  NotG because they are worried about stealing McKinley's thunder, but becausenD they want to maximize their profits by introducing a new top end CPUF every couple months.  Sun could probably come up with a Sparc that hasG credible performance if they cherry picked a particularly good chip andt chilled it to -50C.a  D Its really no surprise that a .13u P4 could beat a .18u IA64.  Heck,D the surprise for many would be that a .18u IA64 can match a .18u P4,C especially with all the talk about how IA64 is a failure due to thetE failure of the Ti^H^HItanic to make a decent showing in SPECint.  TheuD real question is when we see a .13u McKinley.  From what Intel says,C I guess there never will be such a thing, that will be "Deerfield",CF which is apparently a tweaked McKinley design with more cache in .13u.F And the roadmaps seem to indicate it'll be a while before we see that.H I guess Intel isn't too interested in trying to win any converts to IA64E outside the HPC market just yet.  One would think IA64 would be firstf( in line for the new processes, not last.   --H Douglas Siebert                          dsiebert@excisethis.khamsin.net  M I have discovered a remarkable proof which this .sig is too small to contain!i   ------------------------------  % Date: Wed, 29 Aug 2001 18:15:22 -04005# From: Paul DeMone <pdemone@igs.net>a Subject: Re: alpha - ia64 ' Message-ID: <3B8D697A.C3840BB5@igs.net>6   Greg Lindahl wrote:  > H > >> The EPIC technology used in the IA-64 Itanium's is superior to RISC > >> architechure.  - It has a newer name so it must be better. :-)W   > >iJ > >Ahem. Any chance of the superior technology becoming faster than Sparc, > >the well-known slowest RISC?( > H > While this looks like a completely pointless thread, it's worth notingH > that on a significant class of applications (floating point), standardD > benchmarks show that the IA-64 is significantly faster than Sparc.  ? If beating SPARC on standard FP benchmarks was the criterion to > judge the benefit of RISC design (!!!) then CISC (x86) is also? better. The RISC family's tragic story - all the smart siblingsy< are dying off leaving the idiot to inherit the family server% business and be the RISC flag bearer.l   --D Paul W. DeMone       The 801 experiment SPARCed an ARMs race of EPICE Kanata, Ontario      proportions to put more PRECISION and POWER intodG demone@mosaid.com    architectures with MIPSed results but ALPHA's well $ pdemone@igs.net      that ends well.   ------------------------------  % Date: Wed, 29 Aug 2001 15:52:55 -0700n0 From: "Brig Campbell" <brig.campbell@unisys.com> Subject: Re: alpha - ia64 , Message-ID: <9mjrnv$rk$1@mail.pl.unisys.com>  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messagee* news:9mjol1$mn6$1@pegasus.csx.cam.ac.uk.... > In article <9mjlui$2jl$1@feed.textport.net>,' > Greg Lindahl <lindahl@pbm.com> wrote:-5 > >In article <999118937.563062@haldjas.folklore.ee>, 4 > >Sander Vesik  <sander@haldjas.folklore.ee> wrote: > >eH > >>> Nobody wants to run GUIs, databases, network management and things& > >>> like that on IA-64, do they? :-) > >>3 > >>Can I buy a non-trivially sized IA64 somewhere?  > > E > >Sure, you can buy a 2 or 4 cpu building block, and cluster them asn > >large as you like.n > > @ > >If you meant to say "non trivial SMP box", then the answer is, > >different today. But you didn't say that. >aC > Origin 3000s go a bit bigger than that, but you may be right thatf6 > the bigger ones are not yet shipping.  I don't know. >i  H In our case, "shipping" with Itanium is based on the availablilty of theG operating system, which in our case is Windows.NET.  We're not shippingl until next year.   -brig    >t
 > 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 334679    ------------------------------  # Date: Wed, 29 Aug 2001 23:09:59 GMT 6 From: Lorenzo Micheletto <lorenzomicheletto@libero.it> Subject: Re: alpha - ia64n) Message-ID: <3B8D7394.40130836@libero.it>    Yousuf Khan wrote:  N > One will note that when the Hammer line comes out from AMD, it's 64-bit modeI > will default to 64-bit registers for addressing operands, but to 32-bit@L > registers for data operands. Just proves that 64-bit is only good (so far)' > for addressing and nothing much more..  F Well, there are those nice *64bit* MMX and *128bit* SSE2 registers ...F Very useful when you have a bunch of matrix data to handle, isn't it ?  
 L. Michelettop   ------------------------------  + Date: Wed, 29 Aug 2001 23:15:57 +0000 (UTC)n$ From: lindahl@pbm.com (Greg Lindahl) Subject: Re: alpha - ia64r, Message-ID: <9mjt3d$cbp$1@feed.textport.net>  0 In article <9mjol1$mn6$1@pegasus.csx.cam.ac.uk>,) Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:n  ? >>If you meant to say "non trivial SMP box", then the answer is-+ >>different today. But you didn't say that.0 >0B >Origin 3000s go a bit bigger than that, but you may be right that5 >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.u  C However, you're off on a tangent. You can get a large IA64 "system"lF today, for one definition of "system". The original poster undoubtedlyB meant a SMP system, and didn't say it. My comment about SMPs was a
 throwaway.   gn   ------------------------------  # Date: Thu, 30 Aug 2001 01:17:53 GMT , From: "Sarah Warner" <sarahamiee7@yahoo.com> Subject: Re: alpha - ia64k@ Message-ID: <5vgj7.162589$Xr6.910102@news-server.bigpond.net.au>   EPIC is better than RISC, mate.    Do a bit of research.2  9 "Peter Watkinson" <peterw@u.genie.co.uk> wrote in messagel1 news:3b8c1543.16021359@news.cable.ntlworld.com...9 >1 >7 > Hi,@ >dG > One thing that confuses me about the intel swallowup of Alpha is that:C > with IA64 being EPIC and not RISC and AMD bringing out the HammerdF > range of cpu's Intel will still be in a similar situation to that itH > is in now having to cut chip prices heavily to compete with AMD. I putF > this down to the fact that IA64 was designed when Alpha was still onE > NT and thus Intel needed to go the EPIC route to compete with FX32.,G > Now that AlphaNT is no longer Intel is stuck with a cpu that needs tonF > be able to run 32bit code when if Alpha had never existed they couldG > have produced a RISC cpu. And they are still stuck in a dogfight witheH > AMD when with their tyins with M$ they could have produced a processor > without any legacy hiccups.s >lB > Looking into the future maybe one route for Intel a) could be to > re-release Alpha (dream on)l >cH > or b) could be to produce a brand new RISC cpu maybe 128bits if such a: > thing is possible to leave the competition (AMD) behind. >t >  > who knows............... >  >  regards,b >. >% > Peter Watkinson  > peterw@u.genie.co.uk > http://www.pwnavigate.com/' > http://www.windsurf-international.comh  > http://you.genie.co.uk/peterw/& > http://www.freerider-classifieds.com   ------------------------------  # Date: Thu, 30 Aug 2001 02:30:15 GMTi4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: alpha - ia64i= Message-ID: <Xyhj7.33223$mv1.6537648@typhoon.ne.mediaone.net>t  = "andrew harrison" <andrew.nospam@uk.sun.com> wrote in messagee$ news:3B8CECB0.735057C8@uk.sun.com... >t > Bill Todd wrote: > >)5 > > "Smitty" <someone@microsoft.com> wrote in message > > > news:yRXi7.159620$Xr6.898841@news-server.bigpond.net.au... > >v > > ...e > >eI > > > The EPIC technology used in the IA-64 Itanium's is superior to RISCa > > > architechure.2 > >7L > > Thanks:  it's really a relief to have an authoritative source put an end to > > all this speculation.- > >  >e? > Now we know where Compaqs assertion that IA64 would be betterG: > than Alpha comes from. What a relief, everyone can sleep> > easily and you can stop asking Compaq to explain themselves. >f
 > :):):):) >a >r2 > I bet you feel a whole lot better now you know ! >d >a  I Better than the Ultrasparc team is gonna feel when it has to contend withA out of order execution!C   ------------------------------  # Date: Thu, 30 Aug 2001 05:22:41 GMTr2 From: "Yousuf Khan" <bbbl67@nospam.yahoo.com.spam> Subject: Re: alpha - ia64t= Message-ID: <B4kj7.54329$n75.13608013@news4.rdc1.on.home.com>a  7 "Sarah Warner" <sarahamiee7@yahoo.com> wrote in message-: news:5vgj7.162589$Xr6.910102@news-server.bigpond.net.au...! > EPIC is better than RISC, mate.R >a > Do a bit of research.   K You must be the same person as Smitty, right? Both from Australia, what arenL the chances that there are two complete morons out of the millions that come
 from country?e       Yousuf Khan    ------------------------------  % Date: Wed, 29 Aug 2001 20:19:40 +0200a& From: Michael Joosten <joost@c-lab.de>. Subject: Re: C language functionality changed?$ Message-ID: <3B8D323C.493F@c-lab.de>   John Malmberg wrote: >  > Adrian Birkett wrote:o > > All, > > H > > I have a query about the C programming language. Please consider theI > > following code and also please bear in mind that I am new to C, so ifgI > > I've missed something glaringly obvious, feel free to point it out ino( > > your usual high spirited manner :-); > >e& > > /*  qui.c - does a queue exist? */ > > #include <stdio.h> > > #include <quidef.h>b > > #include <jbcmsgdef.h> > >n > > char            queue[32];6 > > unsigned int    context=0, status, iosb[2], efn=0; > >- > > struct  item > > {   short int   length;: > >     short int   code;4 > >     int         address; > >     int         retadr;e@ > > }   itemlist[2]={sizeof(queue), QUI$_SEARCH_NAME, &queue, 0, > >                  0,0}; > >,
 > > main() > > {m; > >     printf("\nEnter Queue Name: "); scanf("%s",&queue);M > D > Before logging a call with the CSC, you may want to fix your code. > C > You are setting the length field to the maximum size of the arrayi0 > queue, not the length of the current contents. > B > You are also incorrectly explicitly requesting the address of anE > array variable where you should be only passing the array variable.w > C > The compiler warnings that you say you are generally ignoring aret9 > possibly finding other non-obvious bugs in the program.s >   F And.. isn't he initializing the 'int address' field of the struct with' just this address of the char array ???0  = This is C. Don't be surprised if your number of LOE (lines ofnG errors/warnings from compiler) is as huge as your LOC (lines of codes),  or even larger...T   -- 	* 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: Wed, 29 Aug 2001 19:08:32 GMTp2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman). Subject: Re: C language functionality changed?2 Message-ID: <Q4bj7.951$bB1.44532@news.cpqcorp.net>  i In article <3B8CD6D0.339F7710@unnecessary.csc.com>, Adrian Birkett <abirkett@unnecessary.csc.com> writes:    ..E :I have a query about the C programming language. Please consider the F :following code and also please bear in mind that I am new to C, so ifF :I've missed something glaringly obvious, feel free to point it out in% :your usual high spirited manner :-);h ..  H   You don't need to tell us you are new to this stuff, we can generally :   figure that out by ourselves.  (No offense is intended.)  #   Please try the attached C code.     1   I've made a few changes :-) to what you posted.h     No claims to style, etc.  E   You *will* want to review the FAQ text on dynamic descriptors, etc.   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       	--y   #include <descrip.h> #include <jbcmsgdef.h> #include <lib$routines.h>i #include <quidef.h>  #include <ssdef.h> #include <starlet.h> #include <stdio.h> #include <stsdef.h>0   struct ItemList3     {d     short int ItemLength;r     short int ItemCode;P     void *ItemBuffer;D     void *ItemRetLen;      }; #define MAXQNAM 32 #define MAXIL   5S main()   {    int QuiCtx = -1;   int RetStat, RetLen, i;a   int Efn = 0;   unsigned long int QuiIosb[2];o    struct ItemList3 Il3[MAXIL+1];K   struct dsc$descriptor QueueD = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_D, NULL };r.   $DESCRIPTOR( PromptD, "Enter Queue Name: ");  8   RetStat = lib$get_input( &QueueD, &PromptD, &RetLen );&   if (!$VMS_STATUS_SUCCESS( RetStat ))     lib$signal( RetStat );       RetStat = lib$get_ef( &Efn );i&   if (!$VMS_STATUS_SUCCESS( RetStat ))     lib$signal( RetStat );     i = 0;,   Il3[i].ItemLength   = QueueD.dsc$w_length;)   Il3[i].ItemCode     = QUI$_SEARCH_NAME;l-   Il3[i].ItemBuffer   = QueueD.dsc$a_pointer;b   Il3[i++].ItemRetLen = NULL;n   Il3[i].ItemLength   = 0;   Il3[i].ItemCode     = 0;   Il3[i].ItemBuffer   = NULL;h   Il3[i++].ItemRetLen = NULL;G  H   RetStat = sys$getquiw(Efn,QUI$_DISPLAY_QUEUE,&QuiCtx,Il3,QuiIosb,0,0);&   if (!$VMS_STATUS_SUCCESS( RetStat ))     lib$signal( RetStat );     switch ( QuiIosb[0] )t     {w     default:=         printf("Error 0x0%08.8x on $getquiw\n", QuiIosb[0] );n         break;     case JBC$_NOSUCHQUE:2         printf("\nQueue \'%*.*s\' does not exist",K           QueueD.dsc$w_length, QueueD.dsc$w_length, QueueD.dsc$a_pointer );d         break;     case SS$_NORMAL:     case JBC$_NORMAL: *         printf("\nQueue \'%*.*s\' exists",K           QueueD.dsc$w_length, QueueD.dsc$w_length, QueueD.dsc$a_pointer );h         break;     }a     return SS$_NORMAL;   }e   ------------------------------  % Date: Wed, 29 Aug 2001 23:15:26 +0100e1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk> . Subject: Re: C language functionality changed?6 Message-ID: <3B8D778E.1DB085CA@ipl.demon.co.nospam.uk>  
 Hi Adrian,  F On OpenVMS Alpha v7.3 and Compaq C v6.2-008 it works just fine (albeitG with some warnings etc on compile and link) PROVIDED that it's run from  a privileged account :   SYS$SYSROOT:[SYSMGR]>cc/verm' Compaq C V6.2-008 on OpenVMS Alpha V7.3c& SYS$SYSROOT:[SYSMGR]>cc qui/cross/list  < }   itemlist[2]={sizeof(queue), QUI$_SEARCH_NAME, &queue, 0,3 ..................................................^ G %CC-W-CVTDIFTYPES, In the initializer for itemlist[0].address, "&queue"a of type = "pointer to array [32] of char", is being converted to "int".e5 at line number 13 in file SYS$SYSROOT:[SYSMGR]QUI.C;1a  K status=sys$getquiw(efn,QUI$_DISPLAY_QUEUE,&context,&itemlist[0],&iosb,0,0);e .......^F %CC-I-IMPLICITFUNC, In this statement, the identifier "sys$getquiw" is	 implicitlv y declared as a function.b5 at line number 21 in file SYS$SYSROOT:[SYSMGR]QUI.C;1c  (     if (!(status & 1)) sys$exit(status); .......................^C %CC-I-IMPLICITFUNC, In this statement, the identifier "sys$exit" isf implicitly d eclared as a function.5 at line number 23 in file SYS$SYSROOT:[SYSMGR]QUI.C;1g  7         printf("\nQueue \'%s\' does not exist",&queue);b0 ...............................................^F %CC-W-OUTTYPELEN, In this statement, this argument to printf is of "an	 array" ty.G pe and is not appropriate for the conversion specifier "%s".  The valuen might be0  truncated or formatted in an unintended manner.5 at line number 26 in file SYS$SYSROOT:[SYSMGR]QUI.C;1a  4         else printf("\nQueue \'%s\' exists",&queue);- ............................................^aF %CC-W-OUTTYPELEN, In this statement, this argument to printf is of "an	 array" tynG pe and is not appropriate for the conversion specifier "%s".  The valuel might be0  truncated or formatted in an unintended manner.5 at line number 30 in file SYS$SYSROOT:[SYSMGR]QUI.C;1e SYS$SYSROOT:[SYSMGR]>link quit$ %LINK-W-WRNERS, compilation warnings8         in module QUI file SYS$SYSROOT:[SYSMGR]QUI.OBJ;1 SYS$SYSROOT:[SYSMGR]>run qui   Enter Queue Name: sys$batche Queue 'sys$batch' exists    C The system services manual gives "context does not exist or must berF called from a more privileged mode" for the SS$_BADCONTEXT status fromE the getqui system service.  What's the account that's doing the work?gG If I try to run the program from an account with just TMPMBX and NETMBX   then I get the error as you do : SYS$SYSROOT:[SYSMGR]>run qui   Enter Queue Name: sys$batchl> %SYSTEM-F-BADCONTEXT, invalid or corrupted context encountered   Hope this helps. Steve.   Adrian Birkett wrote:  >  > All, > F > I have a query about the C programming language. Please consider theG > following code and also please bear in mind that I am new to C, so ifiG > I've missed something glaringly obvious, feel free to point it out in & > your usual high spirited manner :-); > $ > /*  qui.c - does a queue exist? */ > #include <stdio.h> > #include <quidef.h>d > #include <jbcmsgdef.h> >  > char            queue[32];4 > unsigned int    context=0, status, iosb[2], efn=0; >  > struct  item > {   short int   length;o >     short int   code;h >     int         address; >     int         retadr;i> > }   itemlist[2]={sizeof(queue), QUI$_SEARCH_NAME, &queue, 0, >                  0,0}; >  > main() > {e9 >     printf("\nEnter Queue Name: "); scanf("%s",&queue);i > M > status=sys$getquiw(efn,QUI$_DISPLAY_QUEUE,&context,&itemlist[0],&iosb,0,0);e > * >     if (!(status & 1)) sys$exit(status); > $ >     if (iosb[0] == JBC$_NOSUCHQUE)9 >         printf("\nQueue \'%s\' does not exist",&queue);n
 >     else >     {>0 >         if (!(iosb[0] & 1)) sys$exit(iosb[0]);6 >         else printf("\nQueue \'%s\' exists",&queue); >     }i > }t > 8 > Note: I don't have any symbols defined for CC or LINK. > F > When you compile this on any of the versions I have available (DEC C
 > V5.7-004 onl; > OpenVMS VAX V7.2 , DEC C V6.0-001 on OpenVMS VAX V7.1 and H > Compaq C V6.4-005 on OpenVMS VAX V7.2 ) you get some informational andB > warning messages (CC-I-IMPLICITFUNC, CC-W-CVTDIFTYPES) which are > generally ignored. > : > Linking gives the normal message about warning messages. > H > However, when you run this program, the one produced on DEC C V5.7-004I > on OpenVMS VAX V7.2  works fine, the other combinations give the error;t >  > $ run quir >  > Enter Queue Name: test@ > %SYSTEM-F-BADCONTEXT, invalid or corrupted context encountered > G > Has anyone else come across this or should I try to raise a call witha	 > Compaq?t > 	 > Thanks,i >  > Adec   -- rG "A shadow fell over her face; clear, as if the composure were rent likewE a veil.  And her lips parted, but only with a short intake of breath.5A Then she said, 'Well, then you are right.  Indeed, we are even.'":% 		Louis, "Interview with the Vampire"$   ------------------------------   Date: 29 Aug 2001 17:29:53 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell)n. Subject: Re: C language functionality changed?. Message-ID: <Sw$enO39TJ1Y@tachxxsoftxxconsult>  M In article <3B8D323C.493F@c-lab.de>, Michael Joosten <joost@c-lab.de> writes:l > John Malmberg wrote: >>   >> Adrian Birkett wrote:	 >> > All,n >> >I >> > I have a query about the C programming language. Please consider theaJ >> > following code and also please bear in mind that I am new to C, so ifJ >> > I've missed something glaringly obvious, feel free to point it out in) >> > your usual high spirited manner :-);  >> >' >> > /*  qui.c - does a queue exist? */u >> > #include <stdio.h>a >> > #include <quidef.h> >> > #include <jbcmsgdef.h>  >> > >> > char            queue[32];o7 >> > unsigned int    context=0, status, iosb[2], efn=0;i >> > >> > struct  item  >> > {   short int   length; >> >     short int   code; >> >     int         address;t >> >     int         retadr;A >> > }   itemlist[2]={sizeof(queue), QUI$_SEARCH_NAME, &queue, 0,i >> >                  0,0};  >> > >> > main()o >> > {< >> >     printf("\nEnter Queue Name: "); scanf("%s",&queue); >> +E >> Before logging a call with the CSC, you may want to fix your code.- >>  D >> You are setting the length field to the maximum size of the array1 >> queue, not the length of the current contents.  >> gC >> You are also incorrectly explicitly requesting the address of aniF >> array variable where you should be only passing the array variable. >> lD >> The compiler warnings that you say you are generally ignoring are: >> possibly finding other non-obvious bugs in the program. >> o > H > And.. isn't he initializing the 'int address' field of the struct with) > just this address of the char array ???s > 
 > This is C. h  L A high-quality implementation of ANSI C, as opposed to the old Kernighan and
 Ritchie crap.-  3 >Don't be surprised if your number of LOE (lines ofUI > errors/warnings from compiler) is as huge as your LOC (lines of codes),s > or even larger...@  O Which is a *good* thing compared to accepting anything you type and doing weirde0 things with it, as all C compilers used to do.    M Every version of the Compaq C compiler finds still more latent bugs that have'  been around for years and years.   -- bO ===============================================================================.M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)dO ===============================================================================iH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------    Date: 29 Aug 2001 22:33:17 -0500+ From: young_r@encompasserve.org (Rob Young).@ Subject: Compiled Languages (Was: e: My VMS Wish List (features)3 Message-ID: <U9xSyJ1zz8tt@eisner.encompasserve.org>p  [ In article <3B8DAE36.15F3721E@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  > Larry Kilgallen wrote: >> t >> That is a good list.t >> 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 floating E >> point types are minimal and the Real goal is to run Sort.  In thatn5 >> case switching to a compiled language is overkill.t > 6 > Of course, the problems with compiled languages are: >  > o they're compiled# > o unless you write Macro32, $$$$$aH > 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 Io@ 	ask around.  One fellow that is a Perl geek mentioned something+ 	about runtime issues.  He doesn't compile.   < 	I'm not interested in Perl.  The syntax is insanity.  Truly? 	insane.  But yes, you can get used to insanity I suppose.  For B 	various reasons (Uwe included), I've taken an interest in Python.? 	It can be compiled and the p-code is cross platform.  I've gotg? 	a lot going on but am about 2 chapters into "Learning Python."n   	Here is an overview:/   http://archaeopteryx.com/pythonw   			Python Overview  M Python is an open-source object-oriented programming language that offers two J to five fold programmer productivity increases over languages like C, C++, Java, and even Perl.I Because it has been developed by hundreds of contributors from around the.F world, the language is very well designed, fast, robust, portable, andO scalable. With an uncluttered, easy-to-learn syntax and well-developed advancedeI language features, Python meets or exceeds the capabilities of comparablevO commercially available solutions. It is available for most platforms, includingo! Windows, UNIX, Linux, and Mac OS.   M Unlike most languages, Python scales well from simple scripting, prototyping, K and web development, all the way up to the construction of complex businessoK solutions or full-scale GUI apps. This flexibility makes it possible to useeN fewer languages within an organization, and to reduce training and integration costs.  I Python works well with existing technologies and can be used both to wraptH legacy systems or to enhance them as a powerful extension language. ManyL high-quality modules are available for Python: Easy-to-use internet protocolG implementations, math libraries, cryptography tools, interfaces to mostuG databases, CORBA and COM support, and APIs for common windowing and GUI1G development frameworks such as MFC, X11, Motif, Tk, Gtk, and Macintosh.-  M The open source license for Python allows unrestricted use, modification, andaO redistribution of the language or anything that is based on it, commercially oriC otherwise. Full source is available and there are no license costs.e  E Support is available both for free, from a rich set of internet-based N resources, and from organizations in the business of providing paid support to
 Python users.   N Check out this resoundingly positive review, called Why Python? by open source advocate Eric Raymond.  K A substantial number of other documents have been written to compare Python 1 with Java, C/C++, Perl, TCL, and other languages.u  F Language and library documentation, additional introductory materials,L tutorials, and many other informational materials are also available online.  ! 	Which links to another overview:u  8 http://www2.linuxjournal.com/lj-issues/issue73/3882.html  < 	I figured this is the best new language there is.  Might as. 	well go with what is best.  VMS is best, etc.  / 	This knocks out all three of your detractions:s   >  > o they're compiled   	It can be compiled.  # > o unless you write Macro32, $$$$$    	It is free.  H > o too many wheels to re-invent when DCL already has many conveniences.  A 	It has many features and then some of higher level languages and0 	is truly object oriented.  ? 	The latest and greatest version for OpenVMS can be found here:   0 http://decus.decus.de/~zessin/python2/index.html  H 	and compiled and linked for me under Alpha VMS 7.2-1.  The instructions9 	can turn you around a bit... just work your way through.n   				Rob    ------------------------------  % Date: Wed, 29 Aug 2001 21:41:53 -0400 9 From: "D.B. Turner, islandco.com" <dbturner@islandco.com>e" Subject: Complete Alpha for USD650/ Message-ID: <tor60m99tev224@news.supernews.com>b   Go to:  + http://www.islandco.com/specials/433aul.htm      We sell Alpha's & Alpha Partst http://www.islandco.comr sales@islandco.com Island Computers US Corp.? 2700 Gregory Streett Savannah GA 31404u Tel: 912 447 6622n Fax: 912 201 0096i   ------------------------------  % Date: Wed, 29 Aug 2001 14:19:25 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>@2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B8D3225.2B971266@videotron.ca>   Jan C Vorbrueggen wrote:I > IBM's OS/390 upgrades are, AFAIK, all about compatibility at the binaryeH > level. When you recompile to the new models, you will uncover a lot ofE > the dirty programming tricks that were used. But then, what is new?b  > I know that this isn't the right newsgroup, but what the heck.  K In the 360/370 era, adresses used only the first 24 bits of a register. And L bit 31 was set to "1" to indicate the end of an argument list as part of theM standard calling convention. (eg: last argument has bit 31 set to 1, and bitsi6 0-23 containing the address pointing to the argument).  J When they went to 32 bit address space, how did they deal with the callingH convention ? Is it really just 31 buit adressing with the last bit still+ reserved to indicate end of argument list ?e   ------------------------------  % Date: Wed, 29 Aug 2001 14:21:19 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>w2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B8D3297.F76004C3@videotron.ca>   Jan C Vorbrueggen wrote:O > > Consider the scenario where Compaq has decided that small VMS customers canmO > > migrate to NT today because applications already exist on NT to match their-G > > needs. So there is no need to work hard to get them to stay on VMS.# > L > This is only valid if you assume that such customers would remain Compaq'sF > customers. The likelyhood of this happening is consistent with zero.  N Compaq has numbers that show what percentage of VMS customers stay with CompaqK and what percentage leave Compaq forever. And I suspect that they are quitefM comfortable with a certain attrition rate if it helps Compaq acheive its longaW term goals of migrating all remaining VMS customers to NT and shut down VMS gracefully.n   ------------------------------   Date: 29 Aug 2001 18:42:28 GMT& From: peter@abbnm.com (Peter da Silva)2 Subject: Re: Conference: CETS-2001 Detailed Update% Message-ID: <9mjd2k$oai@web.nmti.com>e  , In article <3B8C98A7.95584D84@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:eO > But didn't that occur at a time before NT became serious enough to be used asa > an enterprise system,S  F Are you talking about some hypothetical alternate universe, or is your: posting coming to us via a wormhole from the 22nd century?   -- d+  `-_-'   In hoc signo hack, Peter da Silva.nE   'U`    "A well-rounded geek should be able to geek about anything."BL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------    Date: 29 Aug 2001 13:54:37 -0500- From: koehler@encompasserve.org (Bob Koehler) 2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <$$prIAYxkjkc@eisner.encompasserve.org>a  \ In article <3B8D3225.2B971266@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > M > In the 360/370 era, adresses used only the first 24 bits of a register. AndNN > bit 31 was set to "1" to indicate the end of an argument list as part of theO > standard calling convention. (eg: last argument has bit 31 set to 1, and bits 8 > 0-23 containing the address pointing to the argument). > L > When they went to 32 bit address space, how did they deal with the callingJ > convention ? Is it really just 31 buit adressing with the last bit still- > reserved to indicate end of argument list ?c  E Binary compatablility was provided via a 360 compatability mode where G the CPU took the extra step of stripping the 24 address bits out of theRE 32 bits because the high order bits had in fact been used for lots ofGG things by 360 programmers.  Other than address size the 370 instruction]: set was pretty much a superset of the 360 instruction set.   ------------------------------    Date: 29 Aug 2001 21:25:52 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>q2 Subject: Re: Conference: CETS-2001 Detailed UpdateH Message-ID: <y4lmk2mzwf.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:U  M > In the 360/370 era, adresses used only the first 24 bits of a register. AndtN > bit 31 was set to "1" to indicate the end of an argument list as part of theO > standard calling convention. (eg: last argument has bit 31 set to 1, and bitss8 > 0-23 containing the address pointing to the argument).L > When they went to 32 bit address space, how did they deal with the callingJ > convention ? Is it really just 31 buit adressing with the last bit still- > reserved to indicate end of argument list ?u  N One of the extended architectures definitely went to _31_ bits of address. TheK current version, I think, somehow takes this higher - probably in a way VMSrJ did 64-bit addressing (new syscalls). Already the compilers know about the= 31-bit version, and put I/O buffers etc into the lower 16 MB.l   	Jan   ------------------------------   Date: 29 Aug 2001 17:48:14 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell)-2 Subject: Re: Conference: CETS-2001 Detailed Update. Message-ID: <H4BigVAheXKY@tachxxsoftxxconsult>  N In article <9mjd2k$oai@web.nmti.com>, peter@abbnm.com (Peter da Silva) writes:. > In article <3B8C98A7.95584D84@videotron.ca>,1 > JF Mezei  <jfmezei.spamnot@videotron.ca> wrote::P >> But didn't that occur at a time before NT became serious enough to be used as >> an enterprise system, > H > Are you talking about some hypothetical alternate universe, or is your< > posting coming to us via a wormhole from the 22nd century?    L It has to be an alternate universe.  NT won't be an enterprise system in the$ 22nd century, the 34th, or the 49th.  M In any universe warped enough to consider NT as enterprise, reality itself is M out of whack.  For instance, in this universe Ronald McDonald is in the White L House, Mother Teresa is a bloodthirsty terrorist, politicians are honest andI concerned about the welfare of the citizens, and Janet Reno is considered ? more gorgeous than either Catherine Zeta-Jones or Cameron Diaz.t   -- oO ===============================================================================mM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)uO ===============================================================================iH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------  % Date: Wed, 29 Aug 2001 19:22:35 -0400s' From: "Bill Todd" <billtodd@foo.mv.com>,2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mjteq$aj1$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageA. news:TX5j7.68$jd.73087@typhoon1.gnilink.net...   ...f  E > Imagine an IPF OpenVMS or TRU64 system with a really good Win32 APIU > environment.  L 'Imagining' is about as far as we'll ever get in that direction:  as someoneG else already observed, Microsoft snookered the other company that tried% this.s   >qL > > And, of course, the *way* in which Alpha was killed, and the commitmentsI > > broken in the process, make Compaq a risky bet regardless of what its 1 > > present intentions with regard to VMS may be.V >-I > As someone who looks at this from the software, and really doesn't care  what> > hardware is, I have yet to see Compaq break any commitments. >VL > I do see that there is a huge potential to break commitments but none yet.  I Then you're completely deaf and blind.  Perhaps you meant to say that younK hadn't yet seen Compaq break any commitments *that seem important to you* -mH but that's hardly reassuring, which was the point of my statement above.   >S > I am watching five issues...  K A lot of people seem to require a great deal more in the way of reassuranceI than you seem to.l  L You've talked about Compaq 'doing penance' in other posts.  Some of us thinkH that's not the point at all:  some of us think that *real, dramatic, andC externally verifiable change* is what will be required to keep many L customers from taking their VMS business, *and* their PC business, *and* the& associated service business elsewhere.  K I strongly suspect that the only question is *how* many.  In the absence of1G such kinds of change, I suspect we'll know in well under a year whetherg7 Compaq will survive in anything like its current shape.B   ...4  - > > blindly optimistic of Compaq's supportersr >sJ > Bill you seem to be of the opinion that is someone is not a Compaq haterI > they are "blindly optimistic of Compaq's supporters".  In other words aa veryJ > binary situations.  Allow me to suggest that someone might be neutral at' > this point a simply awaiting answers.   L Such a 'voice of reason' position is a bit hard to take seriously as long asF you persist in turning a blind eye to lies and unapologetically-brokenH commitments.  Those aren't opinions, they're documentable facts, and theH refusal of people like you to confront them (and Compaq) hardly enhances% your credibility in other discussion.o  L Do you think that lies from a vendor to its customers don't matter, and thatI repeated, unequivocal, written commitments from a vendor to its customersHI don't either?  If so, *that* would be an honest position to take, and not{K even very subject to debate:  other customers with differing opinions couldrI just state them, and we might even get some idea of what percentage woulduJ leave as a result.  Instead, you act as if the only significant issues areJ the mechanics of the port:  that may be true for you, but it's hardly trueK for a significant portion of the rest of the world, and every time you fail J to address *those* concerns when attempting to rebut them your objectivity becomes more questionable.   ...>  6 > Someone pointed out to me that you are an ex-DECie -  G For moderately large values of 'ex':  I left in January, 1987, after 11c years.    I was not aware oft@ > this.  This discussion is not a theoretical discussion for me.  + Perhaps you'd be more objective if it were.n     I haveK > customers with real code bases and real production systems.  When one hasrK > done platform switches, as I have, one quickly realizes the real pain andgK > effort involved.  If Compaq delivers on the business and technical issues = > doing a platform switch out of spite would be pure madness.   I You still don't get it.  Spite is not the apparent reason for most of thev: reactions here, pure-and-simple distrust of the vendor is.     I really wonder=G > Bill if you today are responsible for a large existing code base thata wouldu> > require significant effort to convert to another platform...  F Thank God, no.  But if I were, there's no chance in hell that the nextK platform would be provided by Compaq, lacking a death-bed conversion on its= part.=   - bill   ------------------------------  # Date: Thu, 30 Aug 2001 01:08:16 GMTa& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update7 Message-ID: <4mgj7.1525$jd.297113@typhoon1.gnilink.net>r  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9mjteq$aj1$1@pyrite.mv.net...I > Do you think that lies from a vendor to its customers don't matter, and  thatK > repeated, unequivocal, written commitments from a vendor to its customers  > don't either?   L As I said I look at from software - If my VMS source code all complies _and_H Compaq doesn't play games with the license pricing _and_ the deliver theL same proformance cruve them advertised for EV6 through EV8 I don't care whatG chip they used - It could be Bill Todd locked is a GS80 cabinet using aR abocus for all I care.  L The real issue for me is will Compaq attempt to "share" the development costK of IPF OpenVMS with me or will Compaq cause me to incur more expense then a J recompile - if the do I am upset - they lied to me - if they don't, from a/ software standpoint, they kept their promise...    > > I really wondereI > > Bill if you today are responsible for a large existing code base that F > > would require significant effort to convert to another platform... >i > Thank God, no.  A As I suspected - if one has a large code base, that would requireyJ conversion, this discussion becomes far more grounded in business reality.2 One would never blow off the issues of conversion.  8 > But if I were, there's no chance in hell that the nextI > platform would be provided by Compaq, lacking a death-bed conversion onr itso > part.g  D Which again demonstrates a total lack of common sense out of spite -J re-tooling your IT staff skill set for to deploy on another platform is an expensive undertaking,  L I suspect the counter argument to this will be is you can always hire new ITL staff with new skills.  That again would be a very naive argument.  BringingI new IT staff in-house to replace obsolete IT staff, because one foolishlysL switch platforms out of spite, means that while one gained the new technicalF skill sets one just lost all the in-house knowledge of business rules.  I Having done a RSTS -> VMS conversion and a VMS -> Windows co-deployment IoJ would never ever blow off the issues involved in targeting a new platform.$ It is painful - very very painful...   ------------------------------  % Date: Wed, 29 Aug 2001 21:48:09 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>r2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B8D9B54.C8D1DD59@videotron.ca>   Wayne Sewell wrote:rO > In any universe warped enough to consider NT as enterprise, reality itself isdO > out of whack.  For instance, in this universe Ronald McDonald is in the WhitesN > House, Mother Teresa is a bloodthirsty terrorist, politicians are honest andK > concerned about the welfare of the citizens, and Janet Reno is consideredaA > more gorgeous than either Catherine Zeta-Jones or Cameron Diaz.   K Have you listened to Compaq's financial announcements ? Compaq considers NTd" servers to be enterprise servers.   F If you wish to deny the reality that NT is ever so slowly invading theM enterprise market (like a cancer that propagates from your toes to eventuallyFI cover all of your body), that is your right. But if you deny that this islI happening, it also explains why you are having a lot of trouble trying to  explain Compaq's strategy.   ------------------------------  % Date: Wed, 29 Aug 2001 22:02:00 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca>o2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B8D9E92.5C01D1CC@videotron.ca>   Jeff Killeen wrote:CF > 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 What percentage of VMS shops are VMS-only ? If a shop has already begun toN deploy new applications on a different platform (NT or Unix), then maintainingH the VMS skill set is what is difficult, since you are already have staffG profficient in developping new stuff on Unix whereas your VMS staff are J proficient at maintaining existing systems since they haven't deployed new' applications in quite some time on VMS.    ------------------------------  # Date: Thu, 30 Aug 2001 02:21:20 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update7 Message-ID: <Aqhj7.1606$jd.314633@typhoon1.gnilink.net>d  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B8D9E92.5C01D1CC@videotron.ca... > Jeff Killeen wrote:dH > > Which again demonstrates a total lack of common sense out of spite -K > > re-tooling your IT staff skill set for to deploy on another platform isa an > > expensive undertaking, >  >jL > What percentage of VMS shops are VMS-only ? If a shop has already begun to> > deploy new applications on a different platform (NT or Unix)  J Really - do you know of many IT teams (defining teams as the team familiar@ with the same set of business rules) deploying high availabilityE applications on both OpenVMS and Windows?  The skill set to deploy on-H Windows clients is not the same as to use Windows as a high availability backend server?.   ------------------------------  # Date: Thu, 30 Aug 2001 02:09:49 GMT8L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr"); Subject: Re: CSWS, MOD_PERL - anyone have HELLO.PM working?e8 Message-ID: <00A01446.A33065DF@SSRL04.SLAC.STANFORD.EDU>  8 In article <00A013CA.DC3E9ACB@SSRL04.SLAC.STANFORD.EDU>,N winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") writes:  C Never mind, I figured it out, or at least got an answer that works.   L Move the HELLO*.PM modules from wherever the MOD_PERL installation deposits I them to PERL_ROOT:[LIB.SITE_PERL.APACHE]  and then you can get the samplet apps to run.  H Next question: Anybody managed to get the DBI stuff to install into the G CSWS_PERL tree?  Failing that, does MOD_PERL as supplied by Compaq work?F with other PERLs, or does it have to be the Compaq supplied PERL?  (ItJ would be nice to be able to hook up a database to MOD_PERL; otherwise I'llH have to do my database-accessing programs as CGIs that run from a scriptK that carefully redefines PERL_ROOT and PERLSHR to point to the most-current8 PERL I have installed.)c   Thanks,    -- Alan    >: >Apache users, etc --a > 5 >DS20E, VMS 7.2-1, Multinet 4.3, CSWS_PERL, MOD_PERL.  > H >PERL_ROOT is defined /JOB/EXEC in the apache login.com to point to the G >CSWS_PERL tree, although I also have 5.6.1 installed elsewhere with a SK >SYSTEM/EXEC logical.  Seems to run okay, and /perl_status/ works.  (I wentoN >to CPAN and got the DEVEL-SYMDUMP package and installed it into the CSWS_PERLB >tree, and works fine.)  I can run test .pl and .cgi scripts from  >apache$root/perl. >pL >However, I uncommented the location containers that for /world and /world2,K >and when I try to run them I get an error 500.  In ERROR_LOG perl reports a3 >that it can't find APACHE::HELLO::Handler in @INC.  >tI >I've tried placing the HELLO.PM and HELLO2.PM in different parts of the 0L >apache tree and the CSWS_PERL tree where other modules are found.  No luck; >it just can't find 'em. > L >(Incidentally, changing the definition of PERL5LIB in MOD_PERL.CONF doesn'tM >seem to make any difference to what /perl_status/ reports as the contents ofc >@INC.)t > M >I'm still learning PERL and MOD_PERL and may just be doing something stupid.  > K >Do any of you have these hello world perl-module examples working?  If so,g: >where are the .PM files located?  What else should I try? >I >Thanks, >a >-- Alan >SP >===============================================================================1 > Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDU N > Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056N > Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210P >=============================================================================== >k  O ===============================================================================e0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056iM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210tO ===============================================================================-   ------------------------------  % Date: Wed, 29 Aug 2001 22:19:05 -0500t1 From: "David J. Dachtera" <djesys.nospam@fsi.net>c. Subject: Re: Does OVMS 7.1 support DAT-Drives?' Message-ID: <3B8DB0A9.46090A9B@fsi.net>e  # Andreas.Rhein@SchmidtBank.lu wrote:c > : > Are DDS-2 / DDS-3 DAT Drives supported by OpenVMS 7.1-2? > I > I have some drives available and want to use these tape drives on local J > installed DS20 and a remote DS10 (with no data line between) in order to/ > exchange data using the OVMS backup facility.s > ? > Thank's a lot for providing me with more info/help on this...n >  > -Andreas-    Just my opinion...  + 4mm tape is prone to much stretch and skew.r  G I'd use it for interchange of non-critical data, but not for BACKUP andj$ certainly not for long-term archive.   My $0.02...g   -- y David J. Dachterao dba DJE Systemsk http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Wed, 29 Aug 2001 23:42:12 +010011 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>f4 Subject: DTSS Couriers - syntax problems in NCL HELP6 Message-ID: <3B8D7DD4.6F927A58@ipl.demon.co.nospam.uk>  H I'm probably going to regret saying this (as a supporter of DECnet-Plus) but....   F It appears that there is a potential problem with the help text withinG NCL regarding setting a DTSS server to be a Courier.  The NCL Help says 
 that using  + NCL> SET NODE nodename COURIER ROLE COURIER_  F should work (IIRC, given that my DECnet-Plus system is at work and I'm not).r  F However, this gave me a constraint violation (if nodename was "0") andE access denied if the nodename was a character string corresponding toeF the node synonym for the local node.  At first I thought that it mightF be related to whether dtss was running on the local node but disablingD and deleting dtss made no difference to the results of the commands.  	 If I use A0 NCL> SET NODE 0 DTSS DECNET COURIER ROLE COURIERG then the local node is promoted to being a courier node as expected and<, as reported by doing NCL> show dtss all char   Is this an expected issue?   Steve. -- tG "A shadow fell over her face; clear, as if the composure were rent likesE a veil.  And her lips parted, but only with a short intake of breath.aA Then she said, 'Well, then you are right.  Indeed, we are even.'"h% 		Louis, "Interview with the Vampire"t   ------------------------------  % Date: Thu, 30 Aug 2001 00:01:10 +0100c1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>a8 Subject: Re: DTSS Couriers - syntax problems in NCL HELP6 Message-ID: <3B8D8246.58654817@ipl.demon.co.nospam.uk>  A I should have also stated that this is OpenVMS Alpha v7.2-1H1 andrF DECnet-Plus v7.2.  Both are ECO'ed up to the latest and greatest ECOs. Steve.   Steve Reece wrote: > J > I'm probably going to regret saying this (as a supporter of DECnet-Plus)	 > but....= > H > It appears that there is a potential problem with the help text withinI > NCL regarding setting a DTSS server to be a Courier.  The NCL Help says  > that using > - > NCL> SET NODE nodename COURIER ROLE COURIERe > H > should work (IIRC, given that my DECnet-Plus system is at work and I'm > not).= > H > However, this gave me a constraint violation (if nodename was "0") andG > access denied if the nodename was a character string corresponding tokH > the node synonym for the local node.  At first I thought that it mightH > be related to whether dtss was running on the local node but disablingF > and deleting dtss made no difference to the results of the commands. > 
 > If I use2 > NCL> SET NODE 0 DTSS DECNET COURIER ROLE COURIERI > then the local node is promoted to being a courier node as expected andm. > as reported by doing NCL> show dtss all char >  > Is this an expected issue? >  > Steve. > --I > "A shadow fell over her face; clear, as if the composure were rent likeoG > a veil.  And her lips parted, but only with a short intake of breath. C > Then she said, 'Well, then you are right.  Indeed, we are even.'"i5 >                 Louis, "Interview with the Vampire"b   -- rG "A shadow fell over her face; clear, as if the composure were rent like-E a veil.  And her lips parted, but only with a short intake of breath.cA Then she said, 'Well, then you are right.  Indeed, we are even.'"t% 		Louis, "Interview with the Vampire"h   ------------------------------  % Date: Wed, 29 Aug 2001 14:16:19 -0400d- From: JF Mezei <jfmezei.spamnot@videotron.ca>o! Subject: Re: EV7 will never ship?y+ Message-ID: <3B8D316B.AD2EB6F@videotron.ca>    Fred Kleinsorge wrote:I > There are people still happily using Alpha systems built with EV4's andiL > Turbochannels.  They may have a hard time "upgrading" the hardware, but weN > (VMS) still support these systems, even though they were built a decade ago.A > VMS has been traditionally slow to retire support for hardware.o  M OK, for that I agree, since I still run VMS on my all mighty teenage MicrovaxbQ II. And the VMS folks do deserve a round of applause for support of old hardware.b  K However, I think that most folks saw the DII-COE thing more as a commitmenttK not to kill VMS instead of a commitment to continue to support existing VMSnH configs. In light of what you said, if, for instance, I buy a particularC config from Compaq today (alpha with VMS 7.3),  getting the DII-COEtK certification/contract would simply mean that Compaq agrees to support thiss- "fixed" configuration for X number of years ?l  P (That would mean to regular customers paying for prior version support, right ?)    N Of course, if you plan to stop developping VMS soon, it becomes much easier toL commit to support current versions of VMS for X years since they will remainK fairly recent forever. (Compares to say a commitment done in the mid 80s tolK continue to support MicroVM 4.7 rolled out around the world for 20 years atdK one customer, which would require additional hardwrae and resources to keepsC that support going even though current versions are very different.o   ------------------------------  # Date: Wed, 29 Aug 2001 19:47:02 GMT,  From: jlsue <jlsuexxxz@home.com>! Subject: Re: EV7 will never ship?I8 Message-ID: <i4hqot0p4bbg7i99v8a5ed4jfkp8g8q1uh@4ax.com>  , On Tue, 28 Aug 2001 21:23:21 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:a   >e >aN >Where I think VMS will suffer in in high end fancy stuff that nobody else hasM >(galaxies for instance).  Since neither NT nor Tru64 have these features, it:K >will be an uphill battle for the VMS folks to convince the wintel folks tofM >build boxes that support those unique VMS features. (this isn't so much chiphL >dependant , but because of the fact that the PC people will be in charge ofO >building boxes that are far more complex than the glorified desktops installedr* >in a 19" rack that they currently build.)  ? Um... we actually have two groups already building server-classnE "boxes" that are very reliable.  Both the Alphaserver systems and thetE high-end Intel servers are of very high quality and reliability.  Our ! ML/DL lines are extremely stable.   F And we aren't losing the experience of Alpha system builders.  They'll5 be working together to put together the IA64 servers.e     >tF >On the other hand, by forcing VMS to lower itself to wintel levels ofM >hardware, some can argue that VMS will run on commodity hardware and thus beo >more competitive.  A What exactly do you mean by 'wintel levels of hardware'?  Neither C Intel nor MS build systems.  Intel provides the chips - and in someaE systems, the chipset driving the motherboards as well - but that's it.D (for the most part).  Compaq, today, builds their own system boards.E The 8500 is an 8-way system with an internal switch for memory accessrF that is something like (for some definitions of "something like")  the crossbar switch in Alpha.    > M >However, the problem I see is that on the wintel el-cheapo hardware, VMS mayiO >not be good enough to please those few large remaining customers, and Compaq'sdO >total lack of marketing and its unwillingness to pit VMS against Windows won'toS >make VMS realise its potential as an OS that can work from desktop to data-centre.t  D What I'd really like to see is some set of tests that can be run, byF customers, on any hardware configuration to verify it's compatibility.B Hopefully some level of testing  that comes somewhat close to what* Compaq engineers do for their own testing.   ------------------------------    Date: 29 Aug 2001 15:20:32 -0500+ From: young_r@encompasserve.org (Rob Young)G! Subject: Re: EV7 will never ship?l3 Message-ID: <zX5eh2B1JoWv@eisner.encompasserve.org>m  \ In article <3B8D263B.CEA96993@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > I > Or has Compaq also given away the IP for galaxies to Intel, making thatdA > intellectual property freely available to all Intel customers ?  >   @ 	If they hawked it on a street corner, what leads you to believe& 	anyone would know what to do with it?   				Robn   ------------------------------  % Date: Wed, 29 Aug 2001 22:47:34 +0100s1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>e! Subject: Re: EV7 will never ship? 5 Message-ID: <3B8D7106.4FEF41F@ipl.demon.co.nospam.uk>l  H Perhaps because your legal people wouldn't want the customer details andG credit card numbers held on your web server to be held under a freewarenH (or nearly so) operating system and hence prefer the concept of security- that might be afforded by the use of Tru64???t  , Horses for courses Alan, horses for courses.   Steve.   Alan Greig wrote:v > V > I can at least confirm that the Compaq IA64 boxes intended to ship in 2004/2005 willV > have Galaxy support features according to current customer presentations. The slidesU > show one system running Windows-64, VMS, Linux, and Tru64. Although exactly why youoX > would want to run Linux, and Tru64 at the same time is a puzzle as they will be binary
 > compatible.w > -- > Alan Greig   --  G "A shadow fell over her face; clear, as if the composure were rent likeoE a veil.  And her lips parted, but only with a short intake of breath.fA Then she said, 'Well, then you are right.  Indeed, we are even.'"-% 		Louis, "Interview with the Vampire"8   ------------------------------    Date: 29 Aug 2001 17:14:03 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)g! Subject: Re: EV7 will never ship?c3 Message-ID: <fb4VRphF9xlg@eisner.encompasserve.org>e  i In article <3B8D7106.4FEF41F@ipl.demon.co.nospam.uk>, Steve Reece <SYSTEM@ipl.demon.co.nospam.uk> writes:dJ > Perhaps because your legal people wouldn't want the customer details andI > credit card numbers held on your web server to be held under a freewarenJ > (or nearly so) operating system and hence prefer the concept of security/ > that might be afforded by the use of Tru64???C  2 Ignore the legal people -- let's talk bottom line.  H Perhaps your _insurance_company_ wouldn't want the customer details etc.  I Or perhaps they would -- one insurance person told me that making profitsp1 in insurance is easy -- you just raise the rates.y   ------------------------------  # Date: Wed, 29 Aug 2001 23:18:22 GMTiL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")! Subject: Re: EV7 will never ship?-8 Message-ID: <00A0142E.AFDF647E@SSRL04.SLAC.STANFORD.EDU>  i In article <3B8D7106.4FEF41F@ipl.demon.co.nospam.uk>, Steve Reece <SYSTEM@ipl.demon.co.nospam.uk> writes:3  I >Perhaps because your legal people wouldn't want the customer details andrH >credit card numbers held on your web server to be held under a freewareI >(or nearly so) operating system and hence prefer the concept of securityn. >that might be afforded by the use of Tru64???  G Are you actually suggesting that whether an OS is secure or not can be pI usefully predicted by whether it's freeware / Open Source or not?  If so,u# let me whisper "Windows NT" to you.    -- Alan   O ===============================================================================n0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================4   ------------------------------  # Date: Thu, 30 Aug 2001 01:35:47 GMTr4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: EV7 will never ship? = Message-ID: <TLgj7.33164$mv1.6494362@typhoon.ne.mediaone.net>   K It maters not. IBM was/will ship EV7 (which is now up and running, nit API)n  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:7h0nots9ql5hjc4bhfm2jdkg89l6sfvd9q@4ax.com... >uG > Ok, now that API have decided that they will never ship an EV7 due toeB > lack of demand for Alpha systems since the June announcement whyG > should we assume that Compaq ever will? Considering that Compaq stillpB > own a large chunk of API one assumes they had influence on API'sD > decision and must know that bailing out now will destroy customersD > confidence even further. Is that really what Compaq management areH > trying to do? The more time passes the clearer it seems to become that, > they've actually lost the plot completely. >, > -- > Alan   ------------------------------    Date: 29 Aug 2001 21:00:58 -07001 From: keithparris_nospam@yahoo.com (Keith Parris)S! Subject: Re: EV7 will never ship?S= Message-ID: <dba3451e.0108292000.15878a8a@posting.google.com>i  o "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message news:<Mf7j7.930$bB1.43844@news.cpqcorp.net>...r? > JF Mezei wrote in message <3B8C4408.5D9433B0@videotron.ca>...SJ > >I would be more comfortable if VMS and Tandem sides worked together and >  builtN > >their own boxes. If you're going to relegate VMS to only a very few focusedN > >market niches at the high end (eg: cash cow), the model is nearly identical >  tobG > >Tandem's and to take advantage of all those fancy features, you needaJ > >specialised hardware that the wintel weenies don't need (or know how to
 >  build). > N > Tandem systems require higher capabilites that we couldn't duplicate or takeK > advantage of without a lot of effort - like lock-stepping.  These systemshD > fill the niche of super-high availability.  VMS fills the niche of5 > high-availability with disaster tolerance/recovery.h  E VMS once had this sort of capability with VAXft hardware.  Given that F the Tandem folks will have to continue to make significant investmentsD to provide fault-tolerant IA-64 hardware platforms, it would seem toF make sense to spread that cost beyond the Tandem base alone and in the@ process give VMS customers a fault-tolerant hardware option once again.C ------------------------------------------------------------------- C Keith Parris | parris at encompasserve dot org | VMS consulting on:pC Clusters, Disaster Tolerance, Internals, Performance, Storage & I/Ov   ------------------------------  % Date: Wed, 29 Aug 2001 15:06:56 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>u) Subject: Re: Feeling Better about Itaniumn, Message-ID: <3B8D3D44.53853B5B@videotron.ca>   Malcolm Dunnett wrote:A >    Then why did they kill off the PowerPC and Alpha versions of/A > Windows? Perhaps MS will take the same tack with Hammer as withLA > Alpha - ie if AMD wants to pay the full cost of a port MS won't  > stand in their way.   M The way I see it: Microsoft will support any platform/company that is willingWL to spend certain amounts of money of marketing to help microsoft. Had CompaqL advertised NT on Alpha as a mainstream product, I think that Microsoft wouldH have continued to support that platform with  the number of applications. proportional to the marketing/sales potential.  N Remember that initially , Alpha showed a lot of potential, so it was normal toN see Microsoft jump in. But when MS realised that the potential wasn't going to  be realised, it pulled the plug.    8 > > Why do you think a MAC version of Word et al. exist?  J Don't forget that products such as EXCELL started on the Macintosh as they" predate the arrival of GUI on DOS.  J When Microsoft started to be bothered by the anti-trust lawyers, it simplyJ renewed its MAC products which had been more or less abandonned over time.  N MS knew that the death of Apple would mean an assured breakup of Microsoft, so6 MS supported Apple financially though its tough times.   ------------------------------  % Date: Wed, 29 Aug 2001 14:58:06 -0400B' From: "Bill Todd" <billtodd@foo.mv.com>u) Subject: Re: Feeling Better about Itaniums( Message-ID: <9mjdus$nba$1@pyrite.mv.net>  E "Jan C Vorbrueggen" <vorbrjz6@sunu513.rz.ruhr-uni-bochum.de> wrote int= message news:6vbd75feywn.fsf@sunu513.rz.ruhr-uni-bochum.de...e+ > "Bill Todd" <billtodd@foo.mv.com> writes:a >iJ > > "Intel controlled about 79% of the microprocessor market in the secondL > > quarter of this year, and Sunnyvale, Calif.-based AMD had 21%, according toL > > Lehman Brothers. AMD has continually grabbed market share from Intel for theeI > > past year, which has caused Intel to react, Niles said. In the secondrG > > quarter, AMD increased its processor shipments by 23% from the samen quarterPH > > a year earlier, while Intel shipped 12% fewer processors in the same time > > frame."  >1H > Nice quote. The flea in the ointment is that the sum of 79% and 21% is 100%L > "of the microprocessor market", so VIA et al., Motorola et al., not to sayJ > various 8- and 16-bit processors no longer seem to be either a market orJ > microprocessors. Hrmph. But then, what do I know compared to some surely > high-paid "analyst"?  E Hey, it's ComputerWorld, after all.  I suspect the reporter (not IIRCsK purporting to be an 'analyst') may have been somewhat sloppily referring torL figures describing the *IA32* portion of the microprocessor market, but thatJ they do represent the relative strengths (and momentum) of that segment ofI the market (which is the segment relevant to the point under discussion),n4 since they are the same figures I've seen elsewhere.   - bill   >t > Jane   ------------------------------  % Date: Wed, 29 Aug 2001 15:07:29 -0400n' From: "Bill Todd" <billtodd@foo.mv.com>d) Subject: Re: Feeling Better about ItaniumE( Message-ID: <9mjeg7$o1u$1@pyrite.mv.net>  > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:cYENGMmCAj25@malvm6.mala.bc.ca...   ...n  6 > if AMD wants to pay the full cost of a port MS won't > stand in their way.c  L There may well be market forces that encourage MS to support hammer far moreJ than it ever supported Alpha, and in any event with 2 64-bit ports alreadyI under their belt (plus the close relationship of hammer architecture with-G existing IA32 architecture) this port should be (at least relatively) aE piece of cake).s   - bill   ------------------------------    Date: 29 Aug 2001 21:15:29 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>h) Subject: Re: Feeling Better about ItaniumnH Message-ID: <y4u1yqn0dq.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / Kilgallen@SpamCop.net (Larry Kilgallen) writes:   N > > ...which isn't the case, at least if you base this on CFP2000 peak resultsN > > and assume that the people doing the benchmarks for AMD know what they are
 > > doing.I > So are there any benchmarks that compare Intel Fortran to Compaq VisualD > Fortran ?U  H Implicitly - for the Athlon CFP2000 peak results, you can see a mix-and-: match procedure for the use of CVF and the Intel compiler.  K I have CVF but only an old beta of the Intel compiler, and I have a CPU2000mC license. Now you know what would be needed for a fair comparison...e   	Jan   ------------------------------    Date: 29 Aug 2001 21:17:37 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>i) Subject: Re: Feeling Better about Itanium H Message-ID: <y4r8tun0a6.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:s  L > > development: with their recent decision, they have pulled the floor out 0 > > from underneath a large part of the company.N > But if you don't want that part of the house, you're more than happy to tearJ > it down, just as long as it doesn't pull down the good part of the house  M Quite. It just seems that the way Compaq is trying to "remove" the Alpha parte? of the house will be doing severe damage to the whole building.l  % The next quarters' results will tell.    	Jan   ------------------------------    Date: 29 Aug 2001 21:20:11 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>n) Subject: Re: Feeling Better about Itanium-H Message-ID: <y4ofoyn05w.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  3 nothome@spammers.are.scum (Malcolm Dunnett) writes:   J >    Then why did they kill off the PowerPC and Alpha versions of Windows?  L AFAIK, they didn't - the chip vendor (IBM/Mot and Compaq, respectively) did.C In the case of MIPS, it likely _was_ MS, due to non-existant sales.a   	Jan   ------------------------------  # Date: Wed, 29 Aug 2001 19:25:17 GMTc  From: jlsue <jlsuexxxz@home.com>) Subject: Re: Feeling Better about Itanium 8 Message-ID: <f4gqotcq3ghcfac007i5e6umdo1j9mk3nn@4ax.com>  F But how do we know how long ago our engineers began working with Intel engineers on IA64?  C I don't mean to start rumors, and I have no inside knowledge, but ImE doubt this decision was brought up and decided in one week.  Probablyu not even one month.   F Is it possible that it's been a potential for a year or more?  In that7 time period, would Mckinley changes have been possible?t   I'm just wondering aloud.o  3 On Wed, 29 Aug 2001 11:10:28 +0100, andrew harrisono! <andrew.nospam@uk.sun.com> wrote:    >b >Rob Young wrote:T >> oU >> In article <9m6c4b$hv4$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:, >> o >> > >> > >> > ... >> >$ >> >> JF, what part don't you "get?" >> >M >> > I'd say that JF 'got' it pretty well, but may have left out some detailscM >> > which I've filled in above.  Just what part of it now don't *you* 'get', 	 >> > Rob?r >> > >> lK >>         The part I don't "get" is why would you trim portions to make itdL >>         appear is if the question is dangling in mid-air?  The part aboutM >>         Alpha designers.  The missing context of which leaves the question,M >>         dangling in mid-air.  That is now the part I don't get.  Actually,wL >>         I do get it.  It is again another thin attempt to twist and turn.Q >>         Someone posts (see subject line) a more positive outlook for them now,aQ >>         and it is quickly twisted.  Sorry, the Compaq folks are doing a fairlylQ >>         good job with the people that count most.  The ones invited to Diamondi >>         Forums. >> tB >>         Meanwhile, those on the fringes are still wailing away. >>  & >>                                 Rob >> t > . >Look Itanium is done and in production (ish). >a7 >Mckinley is at such a late stage that it is extremely t7 >unlikely that any changes will be made other than onese >to fix issues.  >a: >So the Alpha processor designers that Intel have aquired > >will be working on other processors, or on fixes to Mckinley. >B< >They may for example be working on the post Mckinley CPU's. >o> >Does this mean that the post Mckinley CPU's will incorporate  >Alpha IP, possibly. >a< >Does it mean that the post Mckinley CPU's will incorporate . >OpenVMS/Tru64 friendly instructions possibly. >e> >Does it mean that there will be a special IA64 CPU for Compaq
 >possibly. >l> >Of these possiblys the most likely is that some Alpha IP will; >be incorporated into some future generations of IA64, the o  >rest are increasingly unlikely. >?) >This is I think the basis of JF's point.t >pP >> "To be sober means to have a calm, clear head, to judge things after the ruleQ >> of right, and not according to mob rule.  Don't be influenced by those who crym6 >> the loudest, or by those who beat the biggest drum" >>  # >>                 -- C.H. Spurgeon    ------------------------------   Date: 29 Aug 2001 19:40:56 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)) Subject: Re: Feeling Better about Itaniuma0 Message-ID: <9mjgg8$gsg$1@pegasus.csx.cam.ac.uk>  H In article <y4r8tun0a6.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,I Jan Vorbrueggen  <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:o0 >JF Mezei <jfmezei.spamnot@videotron.ca> writes: >eM >> > development: with their recent decision, they have pulled the floor out  1 >> > from underneath a large part of the company.iO >> But if you don't want that part of the house, you're more than happy to tear K >> it down, just as long as it doesn't pull down the good part of the house- >-N >Quite. It just seems that the way Compaq is trying to "remove" the Alpha part@ >of the house will be doing severe damage to the whole building. >n& >The next quarters' results will tell.  A No - 1Q2002.  Let the dust settle, and wait for serious customers> to plan where they are going.l     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: Wed, 29 Aug 2001 14:49:10 -0700a< From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>) Subject: Re: Feeling Better about Itanium7) Message-ID: <3B8D6356.F504499B@intel.com>F   "David J. Dachtera" wrote: > "Kenneth H. Fairfield" wrote:o [...my stuff elided..] > Ken, >iI > I feel the need to make a public apology to you because I believe I maywD > have been unkind to you recently in another thread. For that, I do > apologize. >gG > I make no apologies for my opinions, and I would expect the same from 2 > anyone else. Our convictions make us who we are. >aJ > We all exceed our thresholds from time to time, but that's no excuse for& > being discourteous or disrespectful. >i8 > My apologies to you and group for being unkind to you.  B David, you're a gentleman and a scholar.  No apology is needed andB I don't recall any "unkindnesses", but thanks for the thought.  MyA recollection is that you've strongly expressed your opinions, and F been rather tenacious (not a necessarily bad thing), but never abusive or rude.       -Ken --5 I don't speak for Intel, Inteldoesn't speak for me...    ------------------------------  % Date: Wed, 29 Aug 2001 19:15:34 -0400,- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>-) Subject: Re: Feeling Better about Itanium:, Message-ID: <3B8D7796.FB40C85F@peoplepc.com>   Michael Joosten wrote: .w .  .eH > "You must pamper the shareholders, even if that means pissing off some > customers" .4 .i .d  R Jacques Nasser is the CEO of a Fortune 50 corporation, Ford Motor Company. When heQ took over a few years ago one of his major goals was to increase the P/E ratio ofrU Ford stock.  For years he failed to get that needle to budge.  Check Ford's P/E ratioe; now.  It over 20 now for the first time in who knows when !f  R How did he get that P/E Ratio so high ?  By driving down the price of the price ofO the stock to a new 4 year low while temporarily holding the dividend constant (pR http://finance.yahoo.com/q?s=F&d=c&k=c1&t=2y&l=on&z=m&q=l ).  Not many in businessS think that Ford can hold that dividend for very long despite how much cash reserves,S they have.  The Magellan mutual fund sold over 2 millions share of Ford in the pastLS month.  The little guys just don't watch the "rust belt" industries close enough toE know when to bail out.   Capellas are you listening ?    
 Jack Patteeuwp   ------------------------------  % Date: Wed, 29 Aug 2001 20:23:13 +0100c, From: "Mat Riain" <matei@no.spam.eircom.net>& Subject: FTP problems - please advise!0 Message-ID: <Albj7.5562$s5.65868@news.indigo.ie>   Hello!  L We are having a problem with an application that connects via FTP.  WheneverL we initiate an FTP session from our Alpha server between it and an NT serverK everything works fine.  However, whenever it is initiated from the NT side, J all that happens is that the application logs in and is immediately loggedJ out - without performing any of its functions.  I have tried to FTP myselfG from the server and I am logged out as well...  I don't see any obviouse/ errors, but then again I am rather new to this.o  H I have attached the server ftp logs below.  Any info provided is greatly appreciated!  ; multinet ftp "MY IP ADDRESS"/username=USER/password=PASWORD=  4 SERVER.MYNET.COM MultiNet FTP user process V4.1(119)  . Connection opened (Assuming 8-bit connections)  J <MYALPHA.MYNET.COM MultiNet FTP Server Process V4.1(16) at Wed 29-Aug-2001   12:23PMs   -GMT   [Attempting to log in as USER]   Connection closed by remote.      " This is the FTP_SERVER.log created      
 $! set verifyn   $ ! System wide login file   $ !    $ COBOL :== COBOL/STANDARD=V35   $ !m   $ set nocontrol_yo   $ ON ERROR THEN CONTINUE   $ !e  1 $ result :== "@sys$sysdevice:[operator]batresult"k   $ !a  1 $ IF "NETWORK" .NES. "INTERACTIVE" THEN $GOTO 10$    $ 10$:  ! $! assign dua5:[crf.com] l$crfcomd   $! @l$crfcom:crflogs   $ exit   $ ed*it :== edit/edt   $ qb :== sh que/all/batchA   $ set prompt = " _ALPHA:: >t  % $ set term/dev=vt100/line/insert/edits  * %SET-W-NOTSET, error modifying ALPHA$DKA0:  8 -SET-E-INVDEV, device is invalid for requested operation  * $ !@ii_system:[app.utility]iisymboldef.com   $!  # $ boldon :== "write sys$output """"   $ $ boldoff :== "write sys$output """"   $ cls :== "write sys$output ""   ""   $ MENU :== @L$LOGINS:LUNCH  # $ RWCOPY :== @DATA1:[APP]RWCOPY.COM7   $ sa :== show sym as   $ TI :== show TIME  0 $ dirmin :== dir/col=1/siz/date/select=size=min=  0 $ dirmax :== dir/col=1/siz/date/select=size=max=   $ !M   $ exit  - APP job terminated at 29-AUG-2001 12:23:58.31i   Accounting information:0  - Buffered I/O count: 33 Peak working set size:e   1648  ' Direct I/O count: 26 Peak virtual size:i   167024  ! Page faults: 182 Mounted volumes:g   0M  / Charged CPU time: 0 00:00:00.03 Elapsed time: 0h   00:00:00.65   
 _ALPHA:: >   ------------------------------  % Date: Wed, 29 Aug 2001 22:48:36 -0400l  From: John Santos <JOHN@egh.com>* Subject: Re: FTP problems - please advise!/ Message-ID: <1010829223539.26010B@Ives.egh.com>   % On Wed, 29 Aug 2001, Mat Riain wrote:    > Hello! > N > We are having a problem with an application that connects via FTP.  WheneverN > we initiate an FTP session from our Alpha server between it and an NT serverM > everything works fine.  However, whenever it is initiated from the NT side,tL > all that happens is that the application logs in and is immediately loggedL > out - without performing any of its functions.  I have tried to FTP myselfI > from the server and I am logged out as well...  I don't see any obviousb1 > errors, but then again I am rather new to this.e   [snip] > 3 > $ IF "NETWORK" .NES. "INTERACTIVE" THEN $GOTO 10$- >  > $ 10$:   [snip]  -' > $ set term/dev=vt100/line/insert/edit  > , > %SET-W-NOTSET, error modifying ALPHA$DKA0: > : > -SET-E-INVDEV, device is invalid for requested operation   Hi, Mat   5 You are trying to set the terminal characteristics on 6 something that isn't a terminal.  To prevent this, you5 need to surround the "$ set term" command with a testn( on whether it is an interactive process.  5 In the first part of your log I left here, the "$ IF"y3 is probably comparing f$mode() to "INTERACTIVE" andw5 skipping ahead if it is not.  You need to do the samet" thing at the "$ set term" command.  8 This stuff may be in your login command file (by default7 LOGIN.COM in your login default directory, but you needo5 to check AUTHORIZE to be sure), or in the system-widee2 login command file (pointed to by the logical name6 sys$sylogin, by default sys$manager:sylogin.com) or in- a command file invoked from one of those two.p  3 (It may be that sys$sylogin is skipping setting thet4 terminal characteristics for non-interactive logins,4 but login.com is not... In this case, it may be that2 the settings being made by login.com are redundant5 and you can remove them completely, which would speedl3 up interactive logins as well as letting FTP work.)o   Hope this helps.  7 P.S.  I've seen this problem a number of times.  Shoulde it be added to the FAQ?t   -- r John Santoso Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Wed, 29 Aug 2001 20:38:07 +0200o& From: Michael Joosten <joost@c-lab.de># Subject: Re: GNU screen for AXP/VMSn# Message-ID: <3B8D368F.F36@c-lab.de>    Hunter Goatley wrote:i > M > On Mon, 27 Aug 2001 21:41:58 +0200, Michael Joosten <joost@c-lab.de> wrote:  >    > >0G > This sounds a lot like BOSS, a terminal session manager that lets youBE > create multiple terminal sessions from one physical session.  CheckC > it out here: > ! > http://www.process.com/openvms/w > 6 > ftp://ftp.process.com/vms-freeware/fileserv/boss.zip >   H As it turned out, I already downloaded the BOSS sources in order to haveH a nice example for more system-level VMS programming, when you announced it in february...n  G Oh yes, it also does UW protocol. Is there still a PC client out there?sH I used it some long time ago on an Atari ST, where somebody also wrote aH terminal emulator for it. Unfortunately, this client wasn't very robust,D and UW uses a rather dumb terminal emulation  (ADM-31 and VT52, as ID just see from uw-4.2 docs). And 640x400 isn't that large a screen...    A > It doesn't keep track of the full screen layout between sessiontG > changes; for that, you might check Networking Dynamics's MultiSessionA > or used-to-be-Raxco's WINDOW.s  E IIRC, screen mimicks a vt100 to its sessions, and does screen refresheH for them. There is even the feature of running the sessions detached, soG you can power down/log off from your main session and just resume wheres? you were later. This is probably the main reason why it's stilly apreciated.m  C For a student's assignment, porting screen is probably a little toot: much... But BOSS' source is likely a good 'bag of tricks'.   -- s* 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: Wed, 29 Aug 2001 18:34:10 -05000+ From: Phil Mendelsohn <mend0070@tc.umn.edu>d# Subject: Re: GNU screen for AXP/VMStH Message-ID: <Pine.SOL.4.20.0108291831440.18922-100000@garnet.tc.umn.edu>  J Screen suffers from the same problem that SPAWN and ATTACH do -- you can'tE cut and paste between them easily.  Do BOSS or any of the other utils ( mentioned let one edit between sessions?     -- r6 "To misattribute a quote is unforgivable." --Anonymous   ------------------------------  # Date: Wed, 29 Aug 2001 18:03:28 GMTe= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)e0 Subject: Re: Hobbyist/Private license og DECdoc.0 Message-ID: <00A0141B.D7BD8F3A@SendSpamHere.ORG>  g In article <3B8D1239.F60B9695@home.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com> writes:m >Hi.< >There was an question some days ago about the special offer9 >I had got from Touch Tec. on DECdocument ($199 vs $560).nC >I ask them what I could do with this license, and the answer was :l >l; >"You can do whatever you would like with the license, justb( >as long as you keep it on your system." >u >Pretty OK with me...g >e >Regards >Jan-Erik Sderholm.  @ Let's see... I could get the Hobbyist version of DECdoc and then@ do all of my prodcut documentation with this Hobbyist version of@ DECdoc on a Hobbyist licensed VMS box... but wait..  No, doesn't2 that constitute a breach of the OpenVMS license?   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMw            tJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesi   ------------------------------  % Date: Wed, 29 Aug 2001 21:07:36 +0200u< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>0 Subject: Re: Hobbyist/Private license og DECdoc.( Message-ID: <3B8D3D78.7793D191@home.com>  0 Maybe, but note that Touch don't demand that the4 license I got in this offer *must* be installed on a9 "Hobbyist VMS systems" (even if that's what they probably' expect in my case at least).  5 Of course, if you do *any* work with *any* tool (freer9 or not free) on a Hobbyist VMS system and make money fromi9 it, that would be breach of the OpenVMS hobbyist license,d not ?v  7 (The special case is if you use your hobbyist system tos6 actualy learn something, and then use what you learned3 at some client on the clients systems, then what ?)b  9 Anyway my intend is to (try to) produce some nice lookingu6 docs for the OSU WEB server. And I don't expect to get rich on that :-)   Jan-Erik Sderholm.h  & "Brian Schenkenberger, VAXman-" wrote: > B > Let's see... I could get the Hobbyist version of DECdoc and thenB > do all of my prodcut documentation with this Hobbyist version ofB > DECdoc on a Hobbyist licensed VMS box... but wait..  No, doesn't2 > that constitute a breach of the OpenVMS license?   ------------------------------    Date: 29 Aug 2001 14:50:12 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)u0 Subject: Re: Hobbyist/Private license og DECdoc.3 Message-ID: <MfJ2XGnP1$0P@eisner.encompasserve.org>u  g In article <3B8D3D78.7793D191@home.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com> writes:   ; > Anyway my intent is to (try to) produce some nice lookings > docs for the OSU WEB server.   Bravo !    ------------------------------  % Date: Wed, 29 Aug 2001 14:37:34 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>oN Subject: Re: How to quickly replicate a global section on another network node, Message-ID: <3B8D3664.ED8CDAE9@videotron.ca>   Rembrandt wrote:L > I have an older Vax6250 system collecting data on a plant's operation, andF > that data is stored in current value tables that are global sectionsM > (updated approximately once per second).  I need to quickly access the datad; > in those sections to distribute to a more modern system.      ' Do you have access to the source code ?u  H If you are able to cluster the two machines, you can make use of the ICCK (intra cluster communicatiosn) services to quickly and efficiently exchange L packets of data. Otherwise you can ue DECnet or TCPIP. (DECnet 4 is probablyD the lightest/most efficient in an already loaded machine, correct ?)  G You could write a process on the VAX which scans the global section forlE changes and sends changes to a cooperating process on the Alpha whichtM maintains the global section there. And at regular intervals, the VAX process F would send each field (changed or not) to ensure data integrity (an to' populate the global section initially).o  N It all depends on how big that global section is and how many changes are done to it.   ------------------------------  % Date: Thu, 30 Aug 2001 11:23:49 +1000>/ From: "Phil Howell" <phowell@snowyhydro.com.au> N Subject: Re: How to quickly replicate a global section on another network node. Message-ID: <pBgj7.95$V83.4393@ozemail.com.au>  . "Rembrandt" <artist@juno.com> wrote in message, news:01c130a9$f0012e20$e329adce@satellite...I > I am looking for a method (or a best method) to update a global sectioni > across a network link. >aL > I have an older Vax6250 system collecting data on a plant's operation, andF > that data is stored in current value tables that are global sectionsH > (updated approximately once per second).  I need to quickly access the dataJ > in those sections to distribute to a more modern system.  But the VAX isL > already heavily loaded.  I have an unused Alpha attached, and I would likeG > to be able to quickly (and repeatedly) replicate or update the global6I > section from the VAX to the Alpha, then have a new program operating ono thesE > Alpha to serve the data to the modern system.  I'm just looking foreL > concepts and tools, not detailed coding information (I'm not a programmer,L > just trying to see what is possible).  The VMS version is 7.?.  Thanks for > any information. >  > Ken ) You can map global sections to disk files-% (see system services crmpsc & mgblsc)G7 in a cluster this would be visible to your Alpha system:6 otherwise you could get at it via decnet (or even nfs) Phil   ------------------------------   Date: 30 Aug 2001 02:07:26 GMT- From: Joe Heimann <heimann@nog.ecs.umass.edu>aN Subject: Re: How to quickly replicate a global section on another network node+ Message-ID: <9mk74u$8c$1@odo.ecs.umass.edu>t  3 Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote:rZ > In article <01c130a9$f0012e20$e329adce@satellite>, "Rembrandt" <artist@juno.com> writes:  $ > :I have an older Vax6250 system...  M >   Plugging in a faster VAX processor might be the easiest solution -- each oN >   of the CVAX processor modules in this system are rated at 2.8 VUPs and theM >   system is limited to 2.8 VUPs of I/O performance.  Replacing all five of  N >   your existing 200-series KA62A processor modules with even a single (used)O >   500- or 600-series processor module (the KA65A and KA66A modules at 13 and ML >   32 VUPs, respectively) will likely provide you with a significant systemM >   performance improvement.  (Knowing nothing about the particular limits of K >   the VAX 6000 model 250 system performance at your site, you'll want to eM >   check for sufficient available I/O bandwidth and you'll also want to add l >   more physical memory.)  G There are some potential problems with this approach.  Just plugging in F later modules is not possible past the 300 module rated at 3.8 VUPs inF an original 6200 series cabinet.  Upgrades to later memory modules andD some power supply and other changes were required to install 400 andE later modules as I recall.  The upgrade package for a 6000 series wasoF still available up to a few years ago, it might not be possible to get1 one now except through the used equipment market.u   (rest snipped)   Joe Heimannu   heimann@ecs.umass.edu    ------------------------------  # Date: Wed, 29 Aug 2001 20:57:08 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: IA-64 Galaxiesi2 Message-ID: <EGcj7.959$bB1.44672@news.cpqcorp.net>  R In article <9mjdfv$na8$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:  F :Are you by any chance confusing Galaxy support with hard-partitioningJ :support?  IIRC Gaxaxy involves the *dynamic* migration of resources amongJ :(and some concurrent sharing of resources by) multiple systems, and couldF :(though may not - I don't know) require hardware features that simple :hard-partitioning does not.  K   Adaptive Partioning Multi-Processing (APMP) -- the OpenVMS implementationwH   of APMP is known as OpenVMS Galaxy -- does require a sufficient numberH   of appropriate I/O widgets for the correct operation of each instance L   within the OpenVMS Galaxy -- the required I/O controllers, memory, CPU(s) H   and a console must be available to each instance -- but OpenVMS GalaxyI   does not particularly require any hardware features beyond the minimum t   requirements for widgets.m  K   This is how we got OpenVMS Galaxy to work on an AlphaServer 8400 system, oJ   and did not require particular hardware changes beyond the installation I   of the additional (required) KFE72 consoles and the installation of the&+   minimum SRM console and OpenVMS versions.h  H   We have also publicly demonstrated mixed operating systems -- a Linux H   system instance was swapping processors with an OpenVMS instance at a $   DECUS demonstration some time ago.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 29 Aug 2001 14:45:07 -0400h' From: "Bill Todd" <billtodd@foo.mv.com>h7 Subject: Re: IA-64 Galaxies (was: EV7 will never ship?)b( Message-ID: <9mjd6f$mkp$1@pyrite.mv.net>  : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:H2ixEevzjp1d@eisner.encompasserve.org... L > In article <3B8CDB78.466A6B79@virgin.net>, Alan Greig <a.greig@virgin.net> writes:i > >  > >y > > Larry Kilgallen wrote: > >g7 > >> One very good reason would be feasibility studies.  > >aG > > Such as a Compaq feasibility study on replacing Tru64 with a Compaqo supported Linux? Carried, > > out by customers at no cost to Compaq... >S: > And with customers each able to make their own decision.  I Too bad Compaq didn't apply the same philosophy to Alpha/IA64 choices forn the future.A  L Of course, the 'consolidation to industry-standard' reasoning Compaq appliedE there could easily apply to Tru64 as well, as soon as Linux becomes a. compatible replacement.E   - bill   ------------------------------  % Date: Wed, 29 Aug 2001 14:50:13 -0400O' From: "Bill Todd" <billtodd@foo.mv.com> 7 Subject: Re: IA-64 Galaxies (was: EV7 will never ship?)u( Message-ID: <9mjdfv$na8$1@pyrite.mv.net>  L > In article <3B8CD0E2.153D8125@virgin.net>, Alan Greig <a.greig@virgin.net> writes:u >[I > > I can at least confirm that the Compaq IA64 boxes intended to ship int 2004/2005 will> > > have Galaxy support features according to current customer presentations. The slides G > > show one system running Windows-64, VMS, Linux, and Tru64. Althoughv exactly why youdK > > would want to run Linux, and Tru64 at the same time is a puzzle as they= will be binary > > compatible.d  E Are you by any chance confusing Galaxy support with hard-partitioning I support?  IIRC Gaxaxy involves the *dynamic* migration of resources among:I (and some concurrent sharing of resources by) multiple systems, and couldeE (though may not - I don't know) require hardware features that simpleM hard-partitioning does not.t   - bill   ------------------------------    Date: 29 Aug 2001 14:25:14 -07004 From: userdecar@hotmail.com (Usuarios DEC Argentina)) Subject: Lista de Discusion DEC Argentinae< Message-ID: <c6c729f.0108291325.7bda7ef9@posting.google.com>  H Se inauguro una nueva lista de discusion para usuarios DEC de Argentina. La misma esta en:a+ http://ar.groups.yahoo.com/group/userdecar/o   Saludos.....   ------------------------------  % Date: Wed, 29 Aug 2001 18:27:53 -05002+ From: Phil Mendelsohn <mend0070@tc.umn.edu>2D Subject: Re: Looking for Digital Serial Number Identication ResourceH Message-ID: <Pine.SOL.4.20.0108291825300.18922-100000@garnet.tc.umn.edu>  I Bad form to answer my own post, but a relative who worked there confirmednI that AB _did_ make VAX.  Too bad that plant's closed, and I hear that thes/ Intel plant is going gangbusters out there.  :(l  + On Wed, 29 Aug 2001, Phil Mendelsohn wrote:   # > On 28 Aug 2001, Bob Kaplow wrote:  > 1 > > 	AB	Albuquerque NM?	old VAXen and early Alpha' > > 	AG	????		DECservers > > 	AS	????		DECservers$ > > 	KA	????		old VAXen, early Alpha$ > > 	ZG	????		all my HSx controllers > >  > > G > > Wasn't there once a plant on Phoenix that made terminals, and such?  > J > Albuquerque used to, don't recall about Phoenix.  Did ABQ really used toL > make VAX?  I remember when Sales and Software Services moved their officesJ > to the plant (which had been a Singer plant) -- that would be around '76< > or could be '77.  That could coincide with Star going intoC > production.  But as of '85, I'm pretty sure they were only making + > terminals and left the area before Alpha.n >  >    -- I6 "To misattribute a quote is unforgivable." --Anonymous   ------------------------------  % Date: Wed, 29 Aug 2001 16:51:13 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Mark Twain Promo,, Message-ID: <3B8D55AC.37D1DD31@videotron.ca>  N I didn't know what you guys were talking about until today when I got the box.$ Didn't bother opening it right away.   But I just noticed the stamp.k  N Mailed from: Nashua, NH. But the stamp indicates that the package was insertedN in the postal system at Zrich  (CH-8058 Zurich 58) ... Delivered to an adress4 a few hundred km north of Nahua in montreal canada.     D The book is a nice though, and the "rumours of my deaths are greatlyN exagerated" was a good choice for the cover. It does show that Gorham is aware9 that Compaq's decision has hurt VMS' image significantly.l   ------------------------------  % Date: Wed, 29 Aug 2001 19:59:06 -0000  From: sword7@speakeasy.org$ Subject: MicroVAX II - Boot problems/ Message-ID: <toqica73c3vv0c@corp.supernews.com>e   Hello folks (or Jeff Campbell)::  H Jeff, thank you for information about memory system error registers.  ItE was done in my emulator.  I tried different settings in CPMBX and seesH what happens...  I learned that I must load hex 20 into CPMBX to displayD English properly.  If I did not load hex 20, I got ?04 message errorA instead of "Failure." after "PC = 20040C9E" was printed. I added t4 BDR_HLTENB to BDR register but it resulted the same.  1 I tried different halt actions in CPMBX register.n  " 00 - Use Halt Enable in BDR 14 bit Results: BDR Step F E D C 8i    PC = 20040C9E Failure. >>>V  ! 01 - Restart, if that fails, haltt  02 - Reboot, if that fails, halt Results: BDR Step F E D C B Ai2 Nothing but endless loop in 20051C95 JMP @20051C95  Note: B - Initialize I/O acceses       A - Switch to run mode  	 03 - Haltn Results: BDR Step F E D C 8'     PC = 20040C9E  >>>e  3 Well, I have a few problems with that boot for you.s  C Does anyone know why endless loop in 20051C95 location?  To switch .@ to run mode, does it require exception or interrupt to continue?  : About 20040C9E, I found out that console TTY I/O accesses.F It checks TXCS and increase R0.  That is all.  It does not make sense.E Halt routine prints that location itself via 20040C9E.  I studied and B can't find something is wrong.  Memory probe was successful duringA BDR step C according to debug log file.  When it was done, go to  . 2004073D then it just displayed PC location...  A How do I set settings to boot system successfully?  I do not havee user's guide in my handy. :-(u  
 Thank you!   -- Tim Stark   -- o, Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  # Date: Wed, 29 Aug 2001 20:39:19 GMTD2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)( Subject: Re: MicroVAX II - Boot problems2 Message-ID: <Xpcj7.957$bB1.44606@news.cpqcorp.net>  L In article <toqica73c3vv0c@corp.supernews.com>, sword7@speakeasy.org writes:  / :...I tried different settings in CPMBX and seeiI :what happens...  I learned that I must load hex 20 into CPMBX to display-E :English properly.  If I did not load hex 20, I got ?04 message error : :instead of "Failure." after "PC = 20040C9E" was printed.   C   The format of the KA630 CPMBX is in module UV2DEF in library LIB.>  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 02:04:20 -0000i From: sword7@speakeasy.org( Subject: Re: MicroVAX II - Boot problems/ Message-ID: <tor7p4mh8esi93@corp.supernews.com>y  B In comp.os.vms Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote:N > In article <toqica73c3vv0c@corp.supernews.com>, sword7@speakeasy.org writes:  1 > :...I tried different settings in CPMBX and see K > :what happens...  I learned that I must load hex 20 into CPMBX to display(G > :English properly.  If I did not load hex 20, I got ?04 message errorl< > :instead of "Failure." after "PC = 20040C9E" was printed.   E >   The format of the KA630 CPMBX is in module UV2DEF in library LIB.-  6 Ok, thank you for information.  I will look into that.  C Well, it seems fine now.  I thought that I have some problems with bI booting.  I studied my traced executions (in debug.log) from my emulator  G and finally understand them. (Around location 20040758).  I tested halt A actions in CPMBX and compared traced executions in 20040758.  It tJ resulted different each halt action value.  Best value is 0x22 or 0x26 in G CPMBX to boot normally from turned system on.  I resolved all problems.   H In BDR step B and A, I learned that VMB was trying access Q-22 bus area.C In step B, VMB initialized Q-22 map registers, etc.  in step A, VMBt> is scanning Q-22 address I/O space like device registers, etc.B I noticed that 30000000 and up are Q-22 address I/O space.  My VAXG architecture handbook failed to mention that in MicroVAX II system map.AC VMB tried to access Q-22 memory area at starting 30000000 but found F non-existant memory.  It gave up and just switched to run-mode addressD and jump itself (endless loop) forever...  (20051C95 JMP @#20051C95)  H Well, I will try working on Q-22 bus system..  However, I does not have  Q-22 specs for MicroVAX II. :-(h  # Thank you for information and help.i   -- Tim Stark   -- -, Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  # Date: Wed, 29 Aug 2001 18:05:37 GMTt= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)-( Subject: Re: My VMS Wish List (features)0 Message-ID: <00A0141C.247FA84B@SendSpamHere.ORG>  q In article <20010829163604.38261.qmail@web20203.mail.yahoo.com>, Fabio Cardoso <fabiopenvms@yahoo.com.br> writes:r	 >In DCL ?e >a > ' >a) PRINT/OUTPUT_FORMAT=3DPDF   ;-)  orc4 >INIT/QUE/PROC=3DPDF$SYMBIONT/OUT_FILES=3Ddirectory.  1 Of course, you woudl have to have a 3DPDF printere and 3D paper too!  ;)  i  2 Please turn off the MIME/quote-printable crap when posting.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMh             J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesa   ------------------------------  % Date: Wed, 29 Aug 2001 14:20:44 -0400r0 From: "Syltrem" <syltrem@videotron.ca.spammenot>( Subject: Re: My VMS Wish List (features)5 Message-ID: <fmaj7.56480$TW.296191@tor-nn1.netcom.ca>   C > My only concern is with encouraging people to write things in DCLh2 > that would better be done in compiled languages.  D I agree completely with this. But sometimes there are cases where...  H What would be nice too is that mnemnics like SS$_NORMAL be known to DCL.& Better than hardcoding (which I hate).   --   Syltremw; http://pages.infinit.net/syltrem (OpenVMS related web site)-    G "Larry Kilgallen" <Kilgallen@SpamCop.net> a crit dans le message news:o( Qo4rEp+1Fmly@eisner.encompasserve.org... > That is a good list. >iC > My only concern is with encouraging people to write things in DCLmC > that would better be done in compiled languages.  Still there are$F > times when the steps that require dealing with any of the 6 floatingD > point types are minimal and the Real goal is to run Sort.  In that4 > case switching to a compiled language is overkill.   ------------------------------    Date: 29 Aug 2001 14:08:02 -0500- From: koehler@encompasserve.org (Bob Koehler)o( Subject: Re: My VMS Wish List (features)3 Message-ID: <JE7AFrwZWcT3@eisner.encompasserve.org>r  q In article <20010829163604.38261.qmail@web20203.mail.yahoo.com>, Fabio Cardoso <fabiopenvms@yahoo.com.br> writes:b
 > In DCL ? > ( > a) PRINT/OUTPUT_FORMAT=3DPDF   ;-)  or5 > INIT/QUE/PROC=3DPDF$SYMBIONT/OUT_FILES=3Ddirectory.e  C Adobe might have something to say about this.  If they actually diddF it something like the way they do Adobe on other systems, a PDF outputD file might end up a result of printing to a psuedo-print queue as in your second example.  
 > b) UNDELETEh    Available via freeware and such.  $ > c) ... not much more ideas in DCL. >  >  > In OpenVMS Management Consoleg > 1 > d) AUTHORIZE : users profiles like NT to createa > standard / priviliged users.  E Exists now.  Realize that "UAF> add newuser" is the same as "UAF copy  default newuser".    > In OpenVMS architecure:n > % > e) A way to "stop" RWAST processes.:  H A waste of time, but maybe SHOW SYSTEM could default to skipping them soH we wouldn't always see this question.  Better a change to the VMS KernelD to deallocate all resources not releated to the RWAST (not a trivial? change, I think some work was done there in the 5.0 timeframe).x  1 > f) A way to discover the speed of SCSI devices.s   Autodial the manufacturer ? 8-)   5 > There are a lot of requisitions I would like, but Ia > think nobody will listen me: > 4 > g) An Itanium Notebook with the possibility to run
 > OpenVMS.  H IMHO much more likely than resurecting Alpha Tadpoles.  When VMS runs on: IPF Compaq just has to pick existing platforms to qualify.  % > h) USB 2.0 x Firewire connectivity.V   Agreed.t  8 > i) The Lan Console for servers - I think people in the' > engineering is stressed to read this.i   Cult.t  3 > j) Why not create an "Open Firmware" for boot, sos5 > we can run any OS (AIX/VMS) in "standard" servers -c1 > not prepared for a specific OS like OVMS/Tru64.   D So Compaq's firmware would have to be compatable with IBM's changing6 idea of how to boot AIX?  Moving target problems lurk.   ------------------------------    Date: 29 Aug 2001 14:10:29 -0500- From: koehler@encompasserve.org (Bob Koehler)e( Subject: Re: My VMS Wish List (features)3 Message-ID: <pKgApNOSBotU@eisner.encompasserve.org>e  N In article <3B8D2C89.95FAD793@tgsmc.com>, Brad Hughes <brad@tgsmc.com> writes: > 8 > I'd like to be able to run .com files in the debugger:  > step, examine, deposit, etc...  D    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 @    ------------------------------  % Date: Wed, 29 Aug 2001 12:46:31 -0700 " From: Brad Hughes <brad@tgsmc.com>( Subject: Re: My VMS Wish List (features)) Message-ID: <3B8D4697.2B75192C@tgsmc.com>m   Bob Koehler wrote: > P > 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... > F >    This has been part of the debugger since at least VMS 2.2 (when I# >    finally learned the debugger).t > + >    HELP/LIBRARY=SYS$HELP:DBG$HELP DEBUG @-  F No, I mean I'd like to be able to debug .com files in the VMS debugger! much as I debug Fortran programs.i   Brad   ------------------------------  % Date: Wed, 29 Aug 2001 15:36:53 -0400c2 From: rdeininger@mindspring.com (Robert Deininger)( Subject: Re: My VMS Wish List (features)L Message-ID: <rdeininger-2908011536550001@user-2iveadr.dialup.mindspring.com>  ? In article <fmaj7.56480$TW.296191@tor-nn1.netcom.ca>, "Syltrem"r' <syltrem@videotron.ca.spammenot> wrote:g  E > > My only concern is with encouraging people to write things in DCL 4 > > that would better be done in compiled languages. > F > I agree completely with this. But sometimes there are cases where... > J > What would be nice too is that mnemnics like SS$_NORMAL be known to DCL.( > Better than hardcoding (which I hate).  B If DCL was enhanced to use libraries, there could be a system-wideI standard library with modules containing stuff like condition codes.  SDL-J could be trained to spit out DCL-compatible source, if it can't already do it.a  H I don't mind hardcoding condition codes.  I just hate doing it again andF again.  If I put definitions like this in external DCL files, whateverG calls them isn't portable.  If I embed the definitions, I end up with a-. zillion copies.  DCL libraries would be ideal.      ? While we're dreaming, how about user-written lexical functions?:   g$whatever()  F These could perhaps be connected to DCL through some kind of shareableI image mechanism.  Installed by the system manager for system-wide use, or1/ supplied by a user for a single process or job.C   -- 6 Robert Deininger rdeininger@mindspring.com.   ------------------------------  % Date: Wed, 29 Aug 2001 15:41:33 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)( Subject: Re: My VMS Wish List (features)L Message-ID: <rdeininger-2908011541350001@user-2iveadr.dialup.mindspring.com>  3 In article <pKgApNOSBotU@eisner.encompasserve.org>,b. koehler@encompasserve.org (Bob Koehler) wrote:  P > In article <3B8D2C89.95FAD793@tgsmc.com>, Brad Hughes <brad@tgsmc.com> writes: > > : > > I'd like to be able to run .com files in the debugger:" > > step, examine, deposit, etc... > F >    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 @l  D I think Brad means a debugger for DCL command files.  Something like  @/DEBUG, analogous to RUN/DEBUG.  I I think Bob is talking about command files of debugger commands.  Quite a  different kettle of fish!    -- u Robert Deininger rdeininger@mindspring.comp   ------------------------------  % Date: Wed, 29 Aug 2001 16:04:38 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>a( Subject: Re: My VMS Wish List (features), Message-ID: <3B8D4AC6.649EF0C4@videotron.ca>   Robert Deininger wrote: H > The problem is that RWASTed processes are waiting for _something_.  ToK > safely get rid of the process, you have to guarantee that the _something_pK > never happens; if it does, the memory that _something_ modifies may be ing4 > use for something else, and Bad Things may result.  H But Shirley, this fine engineers at VMS could find a way to artificially* induce the delivery of that _something_ ?.  N Or perhaps transfer the IO to a new temporary process whose sole purpose is to: keep the memory block alive in case the IO ever completes.  I Consider the case where you have one process that ties up a lot of systemDL resources (tapes etc), and only one resource causes RWAST. Because you can'tF kill the process, all those extra healthy resources remain tied up. ByL creating one process that takes over the resource that caused the RWAST, you* would allow the main process to be killed.  L But in the end, modifying the tape driver to support CTRL-Y (or STOP/ID) forM the process that accesses a tape would go a long way towards solving RWAST in0H my opinion. (i.e. allow CTRL-Y when a process does a DIR MUA0: on a TK50' (which would normally take  3 hours :-)r   ------------------------------  % Date: Wed, 29 Aug 2001 17:00:15 -0400 - From: "Peter Weaver" <peter.weaver@stelco.ca>e( Subject: Re: My VMS Wish List (features)2 Message-ID: <JJcj7.17967$Z2.231839@nnrp1.uunet.ca>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# news:<3B8C57F0.F6BC8828@fsi.net>...s  
 Nice list.  L One thing I have wanted for a long time (since 1986 or so, when I was calledG into the computer room by an operator so he could show me the .LOG of a J procedure that failed) is to have standard error messages display the time automatically.   Something like  	 $ pur/logf# %PURGE-I-NOFILPURG, no files purged 
 $asdadssfsF %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \ASDADSSFS\t $ exit 4( %NONAME-F-NOMSG, Message number 00000004   would become  	 $ pur/logr0 %PURGE-I-NOFILPURG, 16:51:23.01, no files purged
 $asdadssfsJ %DCL-W-IVVERB, 16:51:24.45, unrecognized command verb - check validity and spelling \ASDADSSFS\- $ exit 45 %NONAME-F-NOMSG, 16:51:25.30, Message number 00000004F  I SET MESSAGE/TIME and SET MESSAGE/NOTIME will turn the display on and off.g   ------------------------------    Date: 29 Aug 2001 16:34:57 -0500+ From: kuhrt@encompasserve.org (Marty Kuhrt) ( Subject: Re: My VMS Wish List (features)3 Message-ID: <v1M7ctU5Rb9p@eisner.encompasserve.org>s   In article <rdeininger-2908011536550001@user-2iveadr.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:aA > In article <fmaj7.56480$TW.296191@tor-nn1.netcom.ca>, "Syltrem" ) > <syltrem@videotron.ca.spammenot> wrote:  > F >> > My only concern is with encouraging people to write things in DCL5 >> > that would better be done in compiled languages.s >>  G >> I agree completely with this. But sometimes there are cases where..., >> uK >> What would be nice too is that mnemnics like SS$_NORMAL be known to DCL.o) >> Better than hardcoding (which I hate).p > D > If DCL was enhanced to use libraries, there could be a system-wideK > standard library with modules containing stuff like condition codes.  SDLoL > could be trained to spit out DCL-compatible source, if it can't already do > it.u  > I second the SDL to DCL output for message definitions.  I useC MESSAGE/SDL to turn my base .MSG file into a .SDL file.  Then I use D SDL to create the needed include files.  I then have a program parse? the .H file and turn the #defines into lib$set_symbol calls, or E create a .COM with the symbol definitions (depends on how the program @ is called).  A SDL .MSG to DCL symbol definitions in a .COM file would be nifty.-   ------------------------------  % Date: Wed, 29 Aug 2001 14:27:58 -0700n< From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>( Subject: Re: My VMS Wish List (features)( Message-ID: <3B8D5E5E.430A079@intel.com>   Peter Weaver wrote:e  N > One thing I have wanted for a long time (since 1986 or so, when I was calledI > into the computer room by an operator so he could show me the .LOG of aeL > procedure that failed) is to have standard error messages display the time > automatically. >  > Something like >c > $ pur/loga% > %PURGE-I-NOFILPURG, no files purgedt > $asdadssfsH > %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
 > \ASDADSSFS\o
 > $ exit 4* > %NONAME-F-NOMSG, Message number 00000004 >u > would become >t > $ pur/log 2 > %PURGE-I-NOFILPURG, 16:51:23.01, no files purged > $asdadssfsL > %DCL-W-IVVERB, 16:51:24.45, unrecognized command verb - check validity and
 > spelling
 > \ASDADSSFS\ 
 > $ exit 47 > %NONAME-F-NOMSG, 16:51:25.30, Message number 00000004- >-K > SET MESSAGE/TIME and SET MESSAGE/NOTIME will turn the display on and off.d  F But you can get that effect to day using SET PREFIX command at the top/ of the command file that is being logged, e.g.,l       $ SET PREFIX "(!%D)"  G puts the date-time string, enclosed in parentheses, at the beginning of G each line of _verified_ command lines.  OK, if you have SET NOVERIFY in 7 force this won't help and the SET MESSAGE/TIME would...g       -Ken --6 I don't speak for Intel, Intel doesn't speak for me...   ------------------------------  % Date: Wed, 29 Aug 2001 17:49:54 -0400n- From: "Peter Weaver" <peter.weaver@stelco.ca> ( Subject: Re: My VMS Wish List (features)2 Message-ID: <gsdj7.17982$Z2.232067@nnrp1.uunet.ca>  G "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com> wrote in message0" news:3B8D5E5E.430A079@intel.com... > Peter Weaver wrote:  >u >...H > But you can get that effect to day using SET PREFIX command at the top1 > of the command file that is being logged, e.g.,  >...  I My original draft of this message included a comment on SET PREFIX, but I-L took it out before I sent the message. SET PREFIX does usually help, but theJ problem I had when I first wished for the change was a program (SORT IIRC)B that kept spitting out -W- messages while it was running. It neverD completely failed so SET PREFIX would not have helped even if it wasL available at the time. BACKUP/LOG is another command that would benefit from having !%T in the message.  A BTW: most systems I work on have a SET PREFIX in the SYLOGIN.COM.g   ------------------------------  % Date: Wed, 29 Aug 2001 14:53:42 -0700p< From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>( Subject: Re: My VMS Wish List (features)) Message-ID: <3B8D6466.DEA19FED@intel.com>e   "David J. Dachtera" wrote:    ; I concur with other posters: this is a very nice list.  :-)     & > F$FORMAT( symbol_name, edit_string )D > - DCL interface to the BAS$FORMAT() built-in function RTL routine.  B This one puzzled me a bit, I guess because when I first (mis-)readF it, I confused it with BAS$EDIT and said to myself, what does BAS$EDITF give you that F$EDIT doesn't?  So what does BAS$FORMAT give you that'sB not available via F$EDIT and/or F$FAO?  Floating-point formatting?       -Ken --6 I don't speak for Intel, Intel doesn't speak for me...   ------------------------------  % Date: Wed, 29 Aug 2001 20:37:15 -0400i' From: Howard S Shubs <howard@shubs.net>N( Subject: Re: My VMS Wish List (features)< Message-ID: <howard-5AC597.20371529082001@enews.newsguy.com>  ) In article <3B8D6466.DEA19FED@intel.com>,g>  "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com> wrote:  D > This one puzzled me a bit, I guess because when I first (mis-)readH > it, I confused it with BAS$EDIT and said to myself, what does BAS$EDITH > give you that F$EDIT doesn't?  So what does BAS$FORMAT give you that'sD > not available via F$EDIT and/or F$FAO?  Floating-point formatting?  L If they add floating-point to DCL, adding a floating-point format to $FAO()  would be a Good Thing.  , Cleaning up DCL would be a GOOD THING, also. -- D Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Wed, 29 Aug 2001 22:08:38 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>D( Subject: Re: My VMS Wish List (features)' Message-ID: <3B8DAE36.15F3721E@fsi.net>a   Larry Kilgallen wrote: >  > That is a good list. > C > My only concern is with encouraging people to write things in DCLgC > that would better be done in compiled languages.  Still there are F > times when the steps that require dealing with any of the 6 floatingD > point types are minimal and the Real goal is to run Sort.  In that4 > case switching to a compiled language is overkill.  4 Of course, the problems with compiled languages are:   o they're compiled! o unless you write Macro32, $$$$$OF o too many wheels to re-invent when DCL already has many conveniences.  & As always, IMHO and YMMV considerably.   -- d David J. Dachterac dba DJE Systemsu http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------  % Date: Wed, 29 Aug 2001 22:16:39 -0500h1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i( Subject: Re: My VMS Wish List (features)' Message-ID: <3B8DB017.EBD1713D@fsi.net>    "Kenneth H. Fairfield" wrote:s >  > "David J. Dachtera" wrote: > = > I concur with other posters: this is a very nice list.  :-)w > ( > > F$FORMAT( symbol_name, edit_string )F > > - DCL interface to the BAS$FORMAT() built-in function RTL routine. > D > This one puzzled me a bit, I guess because when I first (mis-)readH > it, I confused it with BAS$EDIT and said to myself, what does BAS$EDITH > give you that F$EDIT doesn't?  So what does BAS$FORMAT give you that'sD > not available via F$EDIT and/or F$FAO?  Floating-point formatting?  E That, among others (floating $, floating ".", CR/DB, leading/trailingoE sign, commas (PRINT FORMAT$( 123456789, "###,###,###" ), and so on...   G ...and by the way, TMK, F$EDIT() does not strip out control characters, 5 just spaces and tabs (EDIT$( vbl, -1%), for example).d  B BASIC also has an XLATE$ function that has been very useful in the past...    -- S David J. DachteraN dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  + Date: Wed, 29 Aug 2001 10:58:40 -0700 (PDT)a. From: Fabio Cardoso <fabiopenvms@yahoo.com.br># Subject: OT: Olivetti Web Appliance0@ Message-ID: <20010829175840.41329.qmail@web20204.mail.yahoo.com>   Do you know this ?=20-  L http://www.olivettilexikon.com/cgi-bin2/olilexproduct/prodotti.asp?pd=3DB67= 66Ge  ! Do you have an idea of price ?=20M  ' For me looks like a great product whichM full market in South America.o   Regardsa   F=E1bio Cardoso2       =3D=3D=3D=3D=3DvL =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 - Brazilm 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!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/a   ------------------------------  % Date: Wed, 29 Aug 2001 22:20:48 -0500i1 From: "David J. Dachtera" <djesys.nospam@fsi.net>a# Subject: Re: Oxygen on OpenVMS V7.3 ' Message-ID: <3B8DB110.97636B63@fsi.net>s   Larry Kilgallen wrote: > ^ > In article <9miri0$6ge$1@bob.news.rcn.net>, "Kenneth Randell" <kenr@datametrics.com> writes:0 > > This is a multi-part message in MIME format. > >u/ > > ------=_NextPart_000_0103_01C1306F.15B9DD50. > > Content-Type: text/plain;c > >       charset="iso-8859-1"/ > > Content-Transfer-Encoding: quoted-printablen > >#< > > Forgive the Mime (it's what I get with Outlook Express), > ) > Others have discussed ways to avoid it.   ( ...like don't use the (Censored) P.O.S.!   --   David J. Dachteral dba DJE Systems- http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/<   ------------------------------  % Date: Wed, 29 Aug 2001 19:52:01 -0000e From: nospam@nohost.no.net1 Subject: Q: howto get proc name from library func / Message-ID: <toqhv1p0d6bp34@corp.supernews.com>e  K Is there a way through an RTL or system service to get a process's name as  G does "show system"? I see there is a "prcnam" parameter in the lexical iE function F$GETJPI but I can't seem to find a like one in LIB$ RTL or a system services.   Your help is much apreciated.s   Thanks.W   ------------------------------  # Date: Wed, 29 Aug 2001 20:07:59 GMTD2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)5 Subject: Re: Q: howto get proc name from library funcR2 Message-ID: <zYbj7.956$bB1.44576@news.cpqcorp.net>  L In article <toqhv1p0d6bp34@corp.supernews.com>, nospam@nohost.no.net writes:L :Is there a way through an RTL or system service to get a process's name as H :does "show system"? I see there is a "prcnam" parameter in the lexical F :function F$GETJPI but I can't seem to find a like one in LIB$ RTL or  :system services.m  G   The DCL lexical f$getjpi calls through to the OpenVMS system service EH   sys$getjpi/sys$getjpiw.  With the exception of the f$environment call C   and maybe one or two other lexicals, most lexicals have a direct uH   mapping through to a system service or an equivalent run-time library 
   (RTL) call.K  G   For some languages, the RTL routine lib$getjpi can be easier to call -2   than the underlying sys$getjpi/sys$getjpiw call.  G   There may be other approaches available to you, but we will need some E   background -- particularly the programming language involved.  (ThetI   usual sorts of background questions of interest to the folks answering sG   questions like yours are included in the introductory section of the .   OpenVMS FAQ.)e  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 29 Aug 2001 21:14:47 -0000s From: nospam@nohost.no.net5 Subject: Re: Q: howto get proc name from library funct/ Message-ID: <toqmq7o1lllffd@corp.supernews.com>r  3 Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote:sN : In article <toqhv1p0d6bp34@corp.supernews.com>, nospam@nohost.no.net writes: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 :   The DCL lexical f$getjpi calls through to the OpenVMS system service TJ :   sys$getjpi/sys$getjpiw.  With the exception of the f$environment call E :   and maybe one or two other lexicals, most lexicals have a direct eJ :   mapping through to a system service or an equivalent run-time library  :   (RTL) call.   H I have looked but I don't see anything that seems to return the process ; name in either LIB$ LIB$GETJPI or system services $GETJPI. e  I :   For some languages, the RTL routine lib$getjpi can be easier to call m4 :   than the underlying sys$getjpi/sys$getjpiw call.  I :   There may be other approaches available to you, but we will need some G :   background -- particularly the programming language involved.  (ThesK :   usual sorts of background questions of interest to the folks answering 0I :   questions like yours are included in the introductory section of the l :   OpenVMS FAQ.)i  K I would like to implement it in DEC C. I might have to use FORTRAN just to 0I make use of some existing subroutines more easily. The OS version is VMS - 6.2.  H I just want to create a program that will scan through the processes on H the system and return various performance related data such as CPU time ? used. I want the process name to make it easy to identify data  H collected on a detached process if the system is rebooted and it gets a 
 new PID.    I If there is a system service, etc, that returns the process name and you G7 point me to it I can probably just take it from there. ,  	 Thanks.  e  P :  ---------------------------- #include <rtfaq.h> -----------------------------P :       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    P :  --------------------------- pure personal opinion ---------------------------N :    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 29 Aug 2001 16:26:30 -0500h+ From: "Mike Kier" <michael.kier@compaq.com>.5 Subject: Re: Q: howto get proc name from library funcA2 Message-ID: <e6dj7.962$bB1.44727@news.cpqcorp.net>  ' <nospam@nohost.no.net> wrote in messagel) news:toqmq7o1lllffd@corp.supernews.com...r  I > I have looked but I don't see anything that seems to return the process < > name in either LIB$ LIB$GETJPI or system services $GETJPI.  0 Third (optional) agument in the LIB$GETJPI call.   $HELP RTL LIB$ LIB$GETJPI    RTL_Routines     LIB$       LIB$GETJPI  F          The Get Job/Process Information routine provides a simplifiedI          interface to the $GETJPI system service. It provides accounting,SJ          status, and identification information about a specified process.  J          LIB$GETJPI obtains only one item of information in a single call.            Formatr  >            LIB$GETJPI  item-code [,process-id] [,process-name]  =                        [,resultant-value] [,resultant-string]i  *                        [,resultant-length]   --	 Mike Kierm Compaq Professional Services Cincinnati, OH, USAa michael.kier@compaq.come   ------------------------------   Date: 29 AUG 2001 21:39:49 GMT+ From: Dave Greenwood <greenwoodde@ornl.gov>l5 Subject: Re: Q: howto get proc name from library func12 Message-ID: <29AUG01.21394976@feda34.fed.ornl.gov>  2 In a previous article, nospam@nohost.no.net wrote:M > Is there a way through an RTL or system service to get a process's name as tI > does "show system"? I see there is a "prcnam" parameter in the lexical  G > function F$GETJPI but I can't seem to find a like one in LIB$ RTL or I > system services.  G As others have mentioned, there's LIB$GETJPI.  There's also SYS$GETJPI.  The item code is JPI$_PRCNAM.5   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOVfH Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------  % Date: Wed, 29 Aug 2001 18:05:40 -0400i) From: "Neil Rieck" <n.rieck@sympatico.ca> 5 Subject: Re: Q: howto get proc name from library funcE: Message-ID: <ZBdj7.30917$_8.2947848@news20.bellglobal.com>  K I've created a demo in DEC-BASIC that does both a SYS$GETJPI and LIB$GETJPI  which you can download here:? http://www3.sympatico.ca/n.rieck/demo_vms/basic-demo-getjpi.zipsF This program can be easily modified for use under DEC-C (er, Compaq-C)  9 The following documentation may also be of some interest: G http://www.openvms.compaq.com:8000/72final/5932/5932pro.html RTL (LIB$)sL http://www.openvms.compaq.com:8000/72final/4527/4527pro.html system servicesH http://www.openvms.compaq.com:8000/72final/5841/5841pro.html programming concepts  I p.s. LIB$GETJPI requires that you look at the items defined in SYS$GETJPI ( (which is in the system services manual)  
 Neil Rieck Kitchener/Waterloo/Cambridge,e Ontario, Canada.! http://www3.sympatico.ca/n.rieck/o   ------------------------------    Date: 29 Aug 2001 16:30:28 -0700/ From: mark@dino.cacr.caltech.edu (Mark Bartelt) P Subject: robustness and maturity (was Re: Conference: CETS-2001 Detailed Update)0 Message-ID: <9mjtuk$qm4$1@dino.cacr.caltech.edu>   [ Jeff Killeen ]  A >>  Are you suggesting AIX or Linux is as robust and as mature askC >>  OpenVMS when it comes to being a solid enterprise class server?n  H Well, part of the answer clearly depends on how one defines "robust" andG "mature".  I have essentialy zero experience with AIX, and I think it's H fair to say that Linux still has some distance to go.  (Hey, I run LinuxG on my laptop, and in what seems to be an attempt to provide people withnG something approximating the look'n'feel of Windows, not only does LinuxdG come with window managers which try to be vaguely Windows-like, but themH OS takes the attempt at Microsoft emulation one step further, by hanging; and freezing every now and then for no apparent reason. ;-)-  H However, as for other versions of UNIX, here's some "uptime" output from a couple of our servers:  G  4:23pm  up 764 days,  1:03,  22 users,  load average: 9.12, 9.08, 9.00eF  4:23pm  up 322 days, 18:42,  3 users,  load average: 0.81, 0.78, 0.73  G The first is from a 12-processor Origin 2000; actually, IRIX's "uptime"nG has a bug, and it hasn't *really* been up for more than two years.  But H it is true that its only downtime has been for OS upgrades and scheduled* power outages, going back at least a year.  H The second is from a 64-processor HP V2500 system, and that uptime is inH fact real.  (By the way, HP-UX normalizes the load average to the numberG of CPUs, so that represents about 52 of 64 processors busy doing work.)   G Both systems have been cranking away on a wide variety of jobs, for allgF the time that they've been running.  So I'd certainly put those in theF "robust" category.  (And, for high-performance technical computing, inF the "mature" category as well.  Probably more mature than OpenVMS, for
 that matter.)t  I Mark Bartelt                                                 626 395 2522bI Center for Advanced Computing Research              mark@cacr.caltech.edugI California Institute of Technology      http://www.cacr.caltech.edu/~mark1  I "Clothes not busy being worn are busy drying."  --  Dylan, on laundry dayR?           [ singing "It's all right, ma (I'm only bleaching)" ]6   ------------------------------  % Date: Wed, 29 Aug 2001 22:10:06 +01006, From: "Richard Maher" <maher_rj@hotmail.c*m>U Subject: Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!t1 Message-ID: <9mjlij$lun$1@uranium.btinternet.com>c   Hi,    Larry wrote:  G >Regardless of what the documentation says, the behavior should be that G >which is consistent with the VMS security model.  Sometimes that means.H >correcting the documentation rather than the code.  (And another poster >indicates they have done so.)  J Although tempted to agree will Larry, I believe the future of the universeE and third-world poverty to be far more important than one man's view.l  F If we can now dispense with dubious unsubstantiated claims to the high( moral ground let us return to the facts.  F Regardless of what the documentation says, the behavior should be thatF which is consistent with the VMS security model.  Sometimes that means not fixing what ain't broke.  A Thanks to .1 for the doc ref. I found the following page as well:$  I http://www.openvms.compaq.com:8000/721final/6614/6614pro_002.html#ss_comma   3.17.4 System ServicesG The following table describes updated system services documentation forsA OpenVMS Alpha Version 7.2-1. System Service  Documentation UpdategL $CREATE_USER_PROFILE  The error messages have been updated for this service. <snip>K $PERSONA_RESERVE  As of this release, this service requires the IMPERSONATEr
 privilege.  L I was about to go balistic about upward compatibility etc when I came across this:S  K http://www.openvms.compaq.com:8000/72final/6520/6520pro_007.html#bottom_007    $PERSONA_RESERVE   Note  L ----------------------------------------------------------------------------: The persona extension services ($PERSONA_CREATE_EXTENSION,L $PERSONA_DELETE_EXTENSION, $PERSONA_DELEGATE, $PERSONA_EXTENSION_LOOKUP, andF $PERSONA_RESERVE) are under development and are subject to change in a& release following OpenVMS Version 7.2.  G So $persona_reserve is a work-in-progress but I don't think it would bei asking to muchL to get more than one line as a release note to tell us *why* the restriction has beenL introduced. How has the VMS security model been comprimised by this service?  J I could understand if a new LOITERING_WITH_INTENT privilege was introducedJ but how can $persona_assume require no privs when that is the service that? changes persona and $persona_reserve require IMPERSONATE/DETACHM1 to simply allocate a couple of memory structures.5  E My communication server process (with privs) creates execution server J processes under the username specified by the system manager at the clientK site. TIER3 does not require this username to have *any* privs but I'd likenJ the execution servers (under the control of the client code) to be able toJ assume the persona of the user that my communication server has previouslyI authorized. Now that $persona_reserve is out of secureshr.exe, and in thegK absence of a half decent reason, I'm just gonna give the client code a UWSSa on the top of $p_reserve.   7 How can $p_reserve require IMPERSONATE when $p_delegateME requires "None"????? Reserve just allocates memory Delegate writes towE it and makes it usable. Surely they've introduced this restriction ond the wrong service?   $submit/user requires CMKRNLD $run/detach doesn't require any privs if the UIC/QUOTAS are the sameA sys$p_assume and sys$p_delete requires no privs what about clone?)  G Don't talk to me about consistency. And IMPERSONATE priv lets a $creprcs@ process be TRUSTED so theres auditing out the window. How's your security model holding up now?  6 $persona_reserve requires *NO* privileges! Make it so!   Regards Richard Maher.  C PS. Who is the peanut that keeps calling a PID an EPID in the docs?,  D How can you be worried about an IA64 port when we have the resourcesL to keep these revisionists arranging the deck chairs on the good ship V.M.S. Itanic?e  F I will post a reply with a short example attached for those people whoB receive these things. This will probably lead to a mime message soK appologies in advance and just hit "block sender" if it's too much to bear.#   ------------------------------    Date: 29 Aug 2001 17:11:19 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) U Subject: Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!e3 Message-ID: <KA5JrPutpH6e@eisner.encompasserve.org>t  ` In article <9mjlij$lun$1@uranium.btinternet.com>, "Richard Maher" <maher_rj@hotmail.c*m> writes:  I > So $persona_reserve is a work-in-progress but I don't think it would beu > asking to muchN > to get more than one line as a release note to tell us *why* the restriction
 > has been
 > introduced.D  F I don't know of other such descriptions in the documentation regardingB the VMS Security Model.  I believe such descriptions _are_ presentF in the documentation provided to the NSA for C2 evaluation.  Of courseE the last time that happened was before $PERSONA_RESERVE existed.  AndeF C2 is dead, in deference to the Common Criteria.  Whether VMS is goingI for a Common Criteria evaluation and whether the supporting documentation E would be available to the public might be something someone could askp5 about at the Anaheim US DECUS symposium in two weeks.D   ------------------------------    Date: 29 Aug 2001 18:33:26 -0700- From: merritt.robert@spsd.sk.ca (rob merritt) 3 Subject: Re: still can't get my UCX licensed???????t= Message-ID: <b6bf97d5.0108291733.32cb5c50@posting.google.com>-  % where on the site do you you get them0B show license has a list of layered prods but no licenses i can seeK register licence I can get the OS license mailed to me but no layered prodsn I must be missing something     ` "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3B8C468C.DB096C55@fsi.net>... > Hoff Hoffman wrote:t
 > > [snip]M > >   I am adding a paragraph to the OpenVMS FAQ on this topic, since you aren4 > >   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, W2KtE > and so on, TCP/IP is supplied and licensed separately from VMS. ThetA > uniqueness of the paradigm may be a contributing factor in sucha > confusion. > 
 > My $0.02...- >  > -- w > David J. Dachterai > dba DJE Systemsn > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/1 >  > Poor old Terry Hardy!n > They buried him today. > He lived the life of Riley > while Riley was away...v   ------------------------------  % Date: Wed, 29 Aug 2001 22:02:52 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e3 Subject: Re: still can't get my UCX licensed???????l' Message-ID: <3B8DACDC.682CAC72@fsi.net>    rob merritt wrote: > ' > where on the site do you you get themmD > show license has a list of layered prods but no licenses i can seeM > register licence I can get the OS license mailed to me but no layered prodsf > I must be missing something   H Register for the layered product licenses. They'll be e-mailed to you in- one long message. You'll find UCX among them.w   --   David J. Dachterat dba DJE Systemsr http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  # Date: Thu, 30 Aug 2001 01:25:36 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Terry Shannon Tech Talk on Tru64h= Message-ID: <kCgj7.33151$mv1.6486216@typhoon.ne.mediaone.net>t  @ "Newbie JrSysAdmin" <utlonghornsrule@yahoo.com> wrote in message7 news:2de05464.0108081502.56624985@posting.google.com...h > "># > > Copyright 2001 Terry C. Shannonr8 > > Not affiliated with ... Compaq Computer Corporation. > F > lackey, do you even know what a good hotel room in anaheim costs, or2 > did your "non-affiliate" take care of it for you  G You can ask me, Newbie, but Newbies can't afford my rates. Try expedia.l   ------------------------------  # Date: Thu, 30 Aug 2001 01:27:01 GMTn4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Terry Shannon Tech Talk on Tru64t= Message-ID: <FDgj7.33152$mv1.6487274@typhoon.ne.mediaone.net>-  @ "Newbie JrSysAdmin" <utlonghornsrule@yahoo.com> wrote in message7 news:2de05464.0108091215.33970e1b@posting.google.com...p3 > "Ken Farmer" <kfarmer@tru64.org> wrote in messagel< news:<iDtc7.107157$TM5.15799642@typhoon.southeast.rr.com>...C > > "Robert Deininger" <rdeininger@mindspring.com> wrote in message-J > > news:rdeininger-0808012318320001@user-2iveb8l.dialup.mindspring.com...C > > > In article <2de05464.0108081502.56624985@posting.google.com>,e: > > > utlonghornsrule@yahoo.com (Newbie JrSysAdmin) wrote: > > >f
 > > > > ">) > > > > > Copyright 2001 Terry C. Shannon1> > > > > > Not affiliated with ... Compaq Computer Corporation. > > > > L > > > > lackey, do you even know what a good hotel room in anaheim costs, or9 > > > > did your "non-affiliate" take care of it for you?a > > >f< > > > What's happened to people's manners in this newsgroup? > > >  > > > -- > > > Robert Deininger > > > rdeininger@mindspring.comt > >  > >MJ > > Plus he's/she's hiding in the shadows behind some alias.  Come out Jr. >v> > oh, yes, i'm "hiding" while saying my own words, rather thanE > bullshitting you by wrapping my name around a compaq press release.qH > gotta hand it to shannon, though- compaq's lackeys could not have spun* > it any better. simply an amazing grovel.  I What a lovely anjd considered opinion, Mister Newbie. Thanks for the laffo riot!u   ------------------------------  # Date: Thu, 30 Aug 2001 01:30:18 GMTd4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Terry Shannon Tech Talk on Tru64l= Message-ID: <KGgj7.33155$mv1.6489729@typhoon.ne.mediaone.net>n  2 "GreyCloud" <wholland@tscnet.com> wrote in messageI news:8CAFA555F9CFA0C4.7AEC721B1D98EA66.0CC3172333F6BD58@lp.airnews.net...e > Terry C Shannon wrote: > H > > Lackey, eh? Please repeat that canard so I can institue legal action > > against you. > >eH > > To answet your inane rhetorical questions, a "good" room in Anhaheim goesL > > for about $150 per day. Go down the street to one of the numerous motels, > > and a room can be had for less than $50. > >e@ > > I hope this helps, Junior. You'll be hearing from my lawyer. > > + > > On 8 Aug 2001, Newbie JrSysAdmin wrote:  > >d > > > ">' > > > > Copyright 2001 Terry C. Shannont< > > > > Not affiliated with ... Compaq Computer Corporation. > > >hJ > > > lackey, do you even know what a good hotel room in anaheim costs, or7 > > > did your "non-affiliate" take care of it for you?i > > >< >aF > After reading this ng since Jan. 2001.... I think I'll invest in Sun > Microsystems..../ > Events and things seems to have deteriorated.- >- >p  K Yeah, but they're not doing so wekk, either. And I tend to take noosegroups  with a grain of salt!o   ------------------------------  # Date: Thu, 30 Aug 2001 01:31:24 GMT24 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Terry Shannon Tech Talk on Tru64r= Message-ID: <MHgj7.33157$mv1.6490752@typhoon.ne.mediaone.net>w  2 "GreyCloud" <wholland@tscnet.com> wrote in messageI news:91DBE6CD83C3C2A4.B815D01EA25CC30E.E634C65DD045CED8@lp.airnews.net...o > Rob Young wrote: >e > > In articleD <8CAFA555F9CFA0C4.7AEC721B1D98EA66.0CC3172333F6BD58@lp.airnews.net>,' GreyCloud <wholland@tscnet.com> writes:$ > > > Terry C Shannon wrote: > > >TK > > >> Lackey, eh? Please repeat that canard so I can institue legal actione > > >> against you.e > > >>K > > >> To answet your inane rhetorical questions, a "good" room in Anhaheim  goesH > > >> for about $150 per day. Go down the street to one of the numerous motels/ > > >> and a room can be had for less than $50.i > > >>C > > >> I hope this helps, Junior. You'll be hearing from my lawyer.e > > >>. > > >> On 8 Aug 2001, Newbie JrSysAdmin wrote: > > >> > > >> > ">l* > > >> > > Copyright 2001 Terry C. Shannon? > > >> > > Not affiliated with ... Compaq Computer Corporation.  > > >> >J > > >> > lackey, do you even know what a good hotel room in anaheim costs, or: > > >> > did your "non-affiliate" take care of it for you? > > >> > > > >vJ > > > After reading this ng since Jan. 2001.... I think I'll invest in Sun > > > Microsystems....3 > > > Events and things seems to have deteriorated.. > > >t > > J > >         I've been reading since 1989.  What is different?  The ebb andK > >         flow of whiners and putrid subjects has always been part of the  scene.A > >         This is Usenet,  get used to it, toughen up lad, etc.  > >m >rF > It isn't the ng in itself, that doesn't bother me...  its the actual, market of VMS in itself that's bothering me.  / We have quite a bit in common there, my friend!  >i   ------------------------------  # Date: Thu, 30 Aug 2001 01:32:39 GMT,4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Terry Shannon Tech Talk on Tru64 = Message-ID: <XIgj7.33160$mv1.6491777@typhoon.ne.mediaone.net>t  @ "Newbie JrSysAdmin" <utlonghornsrule@yahoo.com> wrote in message6 news:2de05464.0108200901.ed637c2@posting.google.com...) > eccm <eccm@swbell.net> wrote in messageG& news:<3B81C141.62F3ECF2@swbell.net>...J > > Haha! a bletcherous personal flame, born of /dev/null and drooled fromI > > the lips of a known entity, perched upon a pinnacle of its own cruft, A > > er.. from a yahoo-over-goolge account! What are we coming to?m > >oI > > Shannon's on the user society board of directors, so maybe he gets to:F > > go for free, so what if he does?. There was a time not so long agoI > > when that was not the case. Shannon Knows Anaheim Hotel Prices, yes..PJ > > but that's immaterial. Those that are of any knowledge in professionalI > > matters don't compute "shannon" with "lackey", as they are aware thatn6 > > the two are not same type variable. get knowledge. > >-B > > BTW- there aren't really any good hotel rooms in Anaheim, just > > overpriced ones. > >a >BC > for the record, i apologized to terry for my missive. he's just a2H > smart guy making a living, and you guys have freely created the market
 > for him. >]F > but, some of you need to buy a dictionary. you are misusing words ofE > as few as two syllables, words i hope my own son will master around D > the 7th grade. pardon my noting the non-coincidence of the "compaq= > enterprise unix" crowd and this basic cognitive deficiency.I >iD > and, some of you compaq cheerleaders should respond to some of theG > compaq folks who are in here critical in name. they "deserve" to have C > their posts addressed, and they have called compaq far worse than  > "lackey."u >  > but, i won't hold my breath.  I Nor will I because I don't want to look like a Smurf. Compaq has problemsmF aplenty. The aquisition of an aggressive and competitive marketing and$ strategy staff damn sure would help!   ------------------------------  % Date: Thu, 30 Aug 2001 11:00:46 +0930oA From: "Geoff Roberts" <geoffrobx@stmarksx.ppx.catholicx.edux.aux>r' Subject: Time offset wrong in VMS Mail?a. Message-ID: <CHgj7.98$V83.4989@ozemail.com.au>  ; Noted an odd problem with time in VMS mail originated msgs. / VMS 6.0 - Multinet 3.2 Rev B - IUPOP3 Ver 2.0-4y> They are showing an incorrect offset of +0900 instead of +0930H The system time is correct, NTP synced, and DST has been changing in theG correct manner, at the right time/date for years.  VMS mail doesn't get,E used much, so the issue has probably been around for a while and I'veoH only just noticed it.  Did I miss something somewhere or is this a known bug?  G When a POP3 client (Outlook Express in this case) picks it up, it showsyH the received time as half an hour in the future, ie 11:.   This can be a little confusing to some.c   (LNM$SYSTEM_TABLE)  '   "SYS$TIMEZONE_DIFFERENTIAL" = "34200" G   "SYS$TIME_ZONERULE" = "CST-09:30CSST-10:30,10.5.0/02:00,03.5.0/02:00"m  H 34200 seconds translates to 9:30min which is correct.  We are not on DST at the moment.   Headers below:  4 Received: by xxxx.xxxx.xx.xxxx.xxx.xx (OpenVMS MAIL)-  with DECNET; Thu, 30 Aug 2001 10:36:18 +0900w? Message-ID: <200108301036186112000@xxxx.xxxx.xx.xxxxxxx.xxx.xx> % Date: Thu, 30 Aug 2001 10:36:18 +0900 " From: "Name removed" <xxxx@enigma>
 Subject: TESTa
 To: xxxxxx Cc:-1 X-VMS-From: ENIGMA::xxxxxxxxxx     "Name Removed"1@ X-POP3-Server: xxxx.xxxxxx.xx.xxxxxx.xxx.xx IUPOP3 V2.0-4/NETLIB$ X-POP3-ID: 2001-08-30.10:36:58.42.11    Note the +0900 instead of +0930.   Any help appreciated.9   Cheers  
 Geoff Robertsn Computer Systems Manager Saint Mark's College Port Pirie,o South Australia 6 geoffrob at stmarks dot pp dot catholic dot edu dot au ICQ: 1970476   ------------------------------  % Date: Wed, 29 Aug 2001 14:41:01 -0400 * From: Joshua Cope <Joshua.Cope@Compaq.com>% Subject: Re: V5.5-2 Password Recoveryt* Message-ID: <3B8D373D.109BEB66@Compaq.com>   "D.Webb" wrote:h > P > if it's not too late can you add another flag to give all the non-alphanumericD > characters but retain case insensitivity of alphabetic characters.  L It's too late for the COE release, but I'll pass it along to the developers ( as a possible enhancement down the road.  < ------------------------------------------------------------7 The above opinions and information are not necessarily h% those of Compaq Computer Corporation.w< ------------------------------------------------------------   ------------------------------  % Date: Wed, 29 Aug 2001 14:45:25 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>oA Subject: Re: VMS's Last Stand or Conspiracy/Stupidity Theories...E, Message-ID: <3B8D383B.368E021B@videotron.ca>   Fred Kleinsorge wrote:J > if those making decisions were right or wrong, but I haven't seen people? > getting out of bed saying "What can I do to kill VMS" lately.t  M Have you met Mr Winkler ? I wouldn't be surprised if his wet dreams showed NT5 crushing VMS to its death. :-)  I > company.  You also miss the point that this has had as big an impact on-% > Tru64 (and Linux) as it has on VMS.x  K Linux is not a strategic product for Compaq. It is there because it is freeN$ and it helps sell some wintel boxes.  L And Tru64 doesn't have the history of management actively attempting to killM it , as has been the case with VMS.  Although I agree that Tru64 has sufferedsL through more useless name changes than VMS (Ultrix - OSI - DEC Unix - Tru64,N did I forget any ?)  as well as two architecture changes already (VAX to MIPS, then MIPS to ALPHA).  M Come to think of it, didn't the MIPS to ALPHA occur at about the same time asI Sun migrated to Solaris ?c   ------------------------------  # Date: Wed, 29 Aug 2001 18:58:59 GMT B From: Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP>, Subject: Re: VMS/Alpha backend for GCC 3.x ?4 Message-ID: <TXaj7.2770$T4.25409@www.newsranger.com>  ) On 29 Aug 2001 06:44:12 -0500, in article ? <RNjFgqsYntOu@eisner.encompasserve.org>, Larry Kilgallen wrote:  >R >In article <6vbsnebm8s1.fsf@sunu513.rz.ruhr-uni-bochum.de>, Jan C Vorbrueggen <vorbrjz6@sunu513.rz.ruhr-uni-bochum.de> writes:tG >> Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:  >> r& >>> >ACT supports GNAT on Alpha VMS.  2 >>> Yes, it's really GNAT that I am interested in. >> aP >> I thought that GNAT was DEC^H^H^HCompaq's official VMS ADA compiler, and they$ >> are paying ACT to make it happen? >I: >Compaq paid for the initial GNAT port to Alpha from Unix.B >ACT claims the port is VMS-friendly, but since there is a porting) >guide from Compaq Ada, I have my doubts.d  L I am not sure if you really mean "VMS-friendly" as in "looks and acts like aH native VMS program" or if you actually mean "DEC Ada-friendly" as in you% can easily move DEC Ada code to GNAT.   C If it's the latter, I can't give an opinion as I only became reallysC interested in Ada a couple of years ago, but I note a number of VMSe. specific Pragma options including AST support.  E If it's the former, then ACT have made a couple of efforts to make ithF more VMS-like. ACT have placed a rather nice VMS CLI frontend over theB GCC style interface. They use VMSINSTAL to install the binary kit.% Online help is in a VMS help library.c  G However, when it comes to important things, like debugging support, ACToI have chosen to use GDB instead of integrating GNAT with the VMS debugger.rG Much more annoying is that GDB is missing from the public VMS GNAT kit!cG [I've tried to track ACT's implementation of GDB down without success.]   K However (and I know it's a cliche, but it's true, at least for me :-)) this G is not the problem that it would be for other languages as the compilera is a very good debugger... :-)  I Also, I have not yet had the need to use features like tasking so I don'tt< know how well these language features have been implemented.   Simon.   -- e; Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPsK In the task of removing Microsoft from the marketplace, I have discovered atE truly remarkable plan, but this signature is too small to contain it.h   ------------------------------  % Date: Wed, 29 Aug 2001 15:25:55 -0400l2 From: rdeininger@mindspring.com (Robert Deininger), Subject: Re: VMS/Alpha backend for GCC 3.x ?L Message-ID: <rdeininger-2908011525560001@user-2iveadr.dialup.mindspring.com>  B In article <TXaj7.2770$T4.25409@www.newsranger.com>, Simon Clubley5 <simon_clubley@remove_me.excite.com-Earth.UFP> wrote:e  I > However, when it comes to important things, like debugging support, ACTnK > have chosen to use GDB instead of integrating GNAT with the VMS debugger. I > Much more annoying is that GDB is missing from the public VMS GNAT kit! I > [I've tried to track ACT's implementation of GDB down without success.]C  J I recall from discussions at the time that ACT needed some enhancements toI the VMS debugger to allow a complete solution for Ada 95.  Digital didn'tlI want to expend the effort to make those changes, so ACT used GDB.  That'si* ACT's side of the story, as I remember it.  J If that's what really happened, it's another screw-up on DEC's part.  They9 let the bulk of the VMS Ada community evaporate.  Stupid.H  I Since then, there have been some debugger enhancements on VMS, to supportoI C++ and probably other things.  I wonder if those changes would now allowi2 GNAT to use the VMS debugger?  Just speculating...  M > However (and I know it's a cliche, but it's true, at least for me :-)) thissI > is not the problem that it would be for other languages as the compilerg  > is a very good debugger... :-)  7 Good point.  Imagine C or C-- without a debugger.  Ack!J   -- m Robert Deininger rdeininger@mindspring.coml   ------------------------------    Date: 29 Aug 2001 14:47:44 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)o, Subject: Re: VMS/Alpha backend for GCC 3.x ?3 Message-ID: <RY4BS2sLrdKg@eisner.encompasserve.org>   y In article <TXaj7.2770$T4.25409@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:C  I > However, when it comes to important things, like debugging support, ACTrK > have chosen to use GDB instead of integrating GNAT with the VMS debugger.   F Actually, DEC told ACT they wanted them to use GDB rather than the VMS0 debugger.  DEC, of course, was footing the bill.   ------------------------------  % Date: Wed, 29 Aug 2001 15:00:08 -0400.- From: JF Mezei <jfmezei.spamnot@videotron.ca>e0 Subject: Re: Why continue with OpenVMS / Compaq?, Message-ID: <3B8D3BAD.90FB883A@videotron.ca>   Jan C Vorbrueggen wrote:N > The assumption behind it is that Compaq's management is behaving rationally.  I They are acting rationally. They know what and where they are going. JusteL becayuse the path they have chosen will result in Compaq stepping on you andA crushing you doesn't automatically result in it being irrational.i  H Yes, VMS is profitable. But for how long ? If they see VMS as eventuallyK sinking, then they need to start building alternate sourses of revenus thath0 will hopefully grow faster than VMS will shrink.  J Like it of not, Compaq has decided that the ex-DEC stuff is not strategic.N They are and so far have given plenty of indications that wintel remains theirN core business. And that is where they should and will invest all their efforts/ to at least get one thing right in the company.   C The 180 day commitment , to me, means that Compaq wants to leverage:K non-profitable hardware wintel sales to grow its software/support/solutionso4 arm which Compaq beleives will be highly profitable.  M After all, since wintel requires a lot of support/care, this should be a verygJ profitable business, perhaps more so than a robust system such as VMS that) purrs by itself without much maintenance.c    M Yes, Compaq COULD HAVE made Alpha maintream, and they could have re-energizedeN VMS to compate against NT and UNIX, and yes, with Alpha more mainstream, costsJ would have been more competitive for both NT, UNIX and VMS on Alpha versusL 8086. Yes, Compaq could have done a lot of things (mostly just marketing) to" bring Digital to its former glory.  K But face it, Compaq didn't do any of those things. We all see the potentialkJ for Alpha and VMS. But Compaq sees the potential for Windows. And there isL nothing we can do about it except resign ourselves to the fact that VMS willN be relinquihsed to a small dark corner where it will not make any noise in theJ market and whose customers will slowly migrate to other platforms that are more in the limelight.  K Bean counters produce numbers that support decisions that are already made.,M Compaq has decided that Wintel is its business, and you can bet that the beanaM counters will produce whatever is necessary to back this and hide any profits  generated by VMS etc.   K The only non-Compaq part that seems safe is Tandem. That is because it is anL very specialised and extremely captive market and Compaq would lose BIG TIMEL if it were to treat those customers poorly. (public relations disaster sinceH Compaq would be seen abandonning customers such as NYSE and NASDAQ etc).  M But since nobody knows about VMS and where it is used, Compaq doesn't need tom& support VMS as much as it does Tandem.   ------------------------------   Date: 29 Aug 2001 19:32:14 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)0 Subject: Re: Why continue with OpenVMS / Compaq?0 Message-ID: <9mjfvu$gga$1@pegasus.csx.cam.ac.uk>  , In article <3B8D3BAD.90FB883A@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:f >Jan C Vorbrueggen wrote:nO >> The assumption behind it is that Compaq's management is behaving rationally.l >eJ >They are acting rationally. They know what and where they are going. JustM >becayuse the path they have chosen will result in Compaq stepping on you andtB >crushing you doesn't automatically result in it being irrational.  A Not automatically, no, but there is precious little evidence thatoB they are acting rationally or know where they are going.  The sameD was true for SGI management a few years back, and it is now accepted? that it was irrational and incompetent.  Including by SGI's new = management, who have undone a lot of the previous insanities.o  > Time will tell whether Compaq's management are being visionary or merely delusional.,     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 334679o   ------------------------------  % Date: Wed, 29 Aug 2001 18:46:23 -0400E' From: "Bill Todd" <billtodd@foo.mv.com> 0 Subject: Re: Why continue with OpenVMS / Compaq?( Message-ID: <9mjram$8hc$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B8D3BAD.90FB883A@videotron.ca... > Jan C Vorbrueggen wrote:D > > The assumption behind it is that Compaq's management is behaving rationally.w >y > They are acting rationally.   C That assertion seems supportable only if one assumes that, althoughnK rational, they are incompetent.  And as it would likely be rather difficultlE to be irrational but competent, perhaps we should just avoid debatingrF 'rationality' and just go straight to incompetence as the explanation.   - bill   ------------------------------  % Date: Wed, 29 Aug 2001 18:54:34 -0400t' From: "Bill Todd" <billtodd@foo.mv.com>o0 Subject: Re: Why continue with OpenVMS / Compaq?( Message-ID: <9mjrqa$99a$1@pyrite.mv.net>  : "Alan E. Feldman" <afeldman@gfigroup.com> wrote in message7 news:af1e4ce6.0108290527.2481846e@posting.google.com...    ...0  G > Why would CPQ sacrifice ex-DEC bit by bit if that is what is proppingtE > up their PC losses? I mean, if you're in danger of falling, but are G > being saved by a rope, you don't slowly nibble away at that rope, now 8 > do you? (If you meant something else, please clarify.)   ...   + > WHY?! Why do they want to see it go away?u  G It's a lot easier to document how Compaq is acting and what effects itshH actions are likely to have on its business than to answer that question.# Possible answers certainly include:m  D incompetence/delusion (they just don't understand the business, like% children playing at being grown-ups),o  D dramatically faulty business models (not all that different from the preceding point),   H competing private agendas among the various divisions within the companyL (i.e., internal politics that doesn't have the best overall interests of the company at heart),  J active conspiracy with Intel and/or Microsoft (I don't really subscribe toD this one, though suspect that some external pressures do exist), ...   - bill   ------------------------------   End of INFO-VAX 2001.481 ************************