1 INFO-VAX	Thu, 05 Jul 2001	Volume 2001 : Issue 370       Contents:1 RE: 3 Reasons why VMS is alive and probably well+ 1 RE: 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+  Re: 4 mm tape drive  Re: 4 mm tape drive  Re: 4 mm tape drive  4mm tape drive's mechanism Re: Compaq switches to IA-64 Re: Compaq switches to IA-64 Re: Compaq switches to IA-64 Re: Compaq switches to IA-64 Re: Compaq switches to IA-64 Re: Compaq switches to IA-64 Re: Compaq switches to IA-64( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale? Re: Compaq's fire sale! Computing article on Alpha demise % Re: Computing article on Alpha demise % Re: Computing article on Alpha demise % Re: Computing article on Alpha demise % Re: Computing article on Alpha demise % Re: Computing article on Alpha demise  RE: CSWS 1.1 & TCPware Re: DEC Net and TCP/IP/ Disable DELETE, RENAME, and PURGE command verbs / Disable DELETE, RENAME, and PURGE command verbs 3 Re: Disable DELETE, RENAME, and PURGE command verbs 3 Re: Disable DELETE, RENAME, and PURGE command verbs 3 RE: Disable DELETE, RENAME, and PURGE command verbs & Re: Disk Cluster Size for Oracle Disks% Re: Empty SCA Storageworks canisters?   Helper applications with Mozilla$ Re: Helper applications with Mozilla" re: I didn't stick it upside down! RE: IA64 Rocks My World  RE: IA64 Rocks My World  Re: Need XML Parser for C/C++  Re: Need XML Parser for C/C++  New Mailbox 0.7 (anyone using) Re: Nodenames in cluster# Re: PointSecure site was hacked ???  POP server on tcpip5.1 Re: POP server on tcpip5.1 RE: POP server on tcpip5.1> Re: Problems Creating ODBC Connections to RDB databases on vms( Re: SSH client, FISH, -- sources anyone?( RE: SSH client, FISH, -- sources anyone?2 Re: Strange behavior of BACKUP/SINCE=BACKUP/RECORD2 RE: Strange behavior of BACKUP/SINCE=BACKUP/RECORD Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid 1 Re: The death of VMS has been greatly exaggerated 0 Re: VMS721_UPDATE V0300 ECO regresses DEC$BASRTL< Re: Wailing and moaning... (was: Question to Charlie Matco.); Re: Wailing and moaning.... (was: Compilers go to Intel...) # Re: What about performance issues?? % Re: Which group for VMS hardware ads?  Re: will the irony never cease Re: will the irony never cease Re: will the irony never cease) Re: Writing to OPA0: from a device driver ) Re: Writing to OPA0: from a device driver ) Re: Writing to OPA0: from a device driver   F ----------------------------------------------------------------------  % Date: Thu, 05 Jul 2001 08:55:49 -0500 + From: Christopher Smith <csmith@amdocs.com> : Subject: RE: 3 Reasons why VMS is alive and probably well+L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D2038@cmiexch1.cmi.itds.com>   > -----Original Message-----. > From: Alan Greig [mailto:a.greig@virgin.net]  H > Nope. I;'ve thought about it for a while and Compaq quite clearly haveE > a death wish like Digital before them. Probably the aim is to crash D > the company so badly that it is taken over by Intel. Who will take9 > over Intel five years down the line is anybody's guess.  > F > These slides do seem to  make it quite clear that Compaq has no clueH > whatsoever about ex DEC technology and will shut it down, sell it off,3 > give it away. Whatever it takes to get rid of it.   J On the other hand, does anyone think that the users will loose out if theyK give VMS to the linux people?  That would certainly make FreeVMS plausible, 7 not to mention taking care of those nasty license fees.    Regards,   Chris   ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");  '       ------------------------------   Date: 5 Jul 2001 10:28:34 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) : Subject: RE: 3 Reasons why VMS is alive and probably well+3 Message-ID: <3$W1Brvk2qZK@eisner.encompasserve.org>   z In article <3B55D7F383B0D31197D9009027541CBF0D9D2038@cmiexch1.cmi.itds.com>, Christopher Smith <csmith@amdocs.com> writes: >> -----Original Message----- / >> From: Alan Greig [mailto:a.greig@virgin.net]  > I >> Nope. I;'ve thought about it for a while and Compaq quite clearly have F >> a death wish like Digital before them. Probably the aim is to crashE >> the company so badly that it is taken over by Intel. Who will take : >> over Intel five years down the line is anybody's guess. >>  G >> These slides do seem to  make it quite clear that Compaq has no clue I >> whatsoever about ex DEC technology and will shut it down, sell it off, 4 >> give it away. Whatever it takes to get rid of it. > L > On the other hand, does anyone think that the users will loose out if theyM > give VMS to the linux people?  That would certainly make FreeVMS plausible, 9 > not to mention taking care of those nasty license fees.   G Of course users would lose out.  The strength of VMS is the engineering D group that builds it.  Without that centralized effort (supported by5 those license fees) it would not be nearly so robust.    ------------------------------  $ Date: Thu, 5 Jul 2001 12:42:06 -0400% From: "John Vottero" <John@mvpsi.com> : Subject: Re: 3 Reasons why VMS is alive and probably well+/ Message-ID: <tk96663f15d39b@news.supernews.com>   J "Wayne Sewell" <wayne@tachysoft.xxx.320117.killspam.015d> wrote in message( news:LCr0hkItFTVt@tachxxsoftxxconsult...5 > In article <9RAEVBnZDwOg@eisner.encompasserve.org>, ; Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes: 2 > > In article <+x2IDvG+Rgvz@tachxxsoftxxconsult>,? wayne@tachysoft.xxx.320117.killspam.015d (Wayne Sewell) writes:  > >>G > >> It also determines *how* they support the platform.  For instance,  softwareI > >> partners has always been forced to use its own mechanism for license  keys= > >> because of the incredible cost of the LMF PAK generator.  > > J > > I find it unbelievable that they get a higher price than LJK Software. > K > So how much is the thing now?  Last I heard, it was ten grand.  The price  may J > or may not have gone down, but that's what it was at the time we started using  > our own keys.   I When we bought it (close to 10 years ago), the ISV (now CSA) discount was F something like 65%.  We're still wondering how we upgrade to the Alpha version.   ------------------------------  % Date: Thu, 05 Jul 2001 19:02:55 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> : Subject: Re: 3 Reasons why VMS is alive and probably well+) Message-ID: <3B449DBE.AC035245@gtech.com>    John Saunders wrote:9 > "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message % > news:3B41BB9B.B896E94B@gtech.com...  > > Alphaman wrote: P > > > Don't forget, CSA membership and _site-wide_ SDK is MUCH cheaper than just& > > > ONE single-user MSDN membership. > > L > > Now - I have never believed that system/development-tools prices had any- > > significant impact on support from ISV's.  > J > That depends on the ISV. For a small ISV, costs of development tools andA > platforms can determine whether they support a platform at all.    Hmmm.   ; If the cost of a few thousand dollars is significant for an 9 ISV to decide whether they will support VMS, then I could ; not recommend anyone buying their product - or at least not - for permanent use. It would be way too risky.    Arne   ------------------------------  % Date: Thu, 05 Jul 2001 19:04:57 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> : Subject: Re: 3 Reasons why VMS is alive and probably well+) Message-ID: <3B449E39.C6682249@gtech.com>    Bob Marcan wrote:  > Arne Vajhj wrote: > > Alphaman wrote: Q > > > Actually, Tru64 is a little ahead of OpenVMS -- expect developer's kits for Q > > > Tru64 at the end of 2002; for OpenVMS, the beginning of 2003.  (Think of it , > > > like OpenVMS Alpha v1.0/1.5, I guess.) > >  > > That is the plan.  > > G > > But consider the business perspectives. There will be a lot of OS's D > > for Itanium. To get a market share you will either have to offer
 > > something J > > unique feature-wise or be very cheap. VMS is not cheap. But I do think > > thatK > > there will not be any other OS on Itanium "like" VMS. Tru64 will not be I > > cheap either. And I can not really see, what should distinguish Tru64 G > > from the many other Unix flavours on Itanium. With that perspective - > > the Tru64-Linux affinity may make sense !   < > C'mon, Arne. Did you read about clustering on Tru64 v5.1a?9 > Did you try v5.1? They have lot inherited from the VMS.   < I have noy tried Tru64 clustering, but I have read about it.  6 You are correct, that it has inherited a lot from VMS.  A But what wil prevent Compaq from porting it from Tru64 to Linux ?    Arne   ------------------------------   Date: 5 Jul 2001 13:10:45 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) : Subject: Re: 3 Reasons why VMS is alive and probably well+3 Message-ID: <jg+m40O3hSoI@eisner.encompasserve.org>   W In article <tk96663f15d39b@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes: L > "Wayne Sewell" <wayne@tachysoft.xxx.320117.killspam.015d> wrote in message* > news:LCr0hkItFTVt@tachxxsoftxxconsult...6 >> In article <9RAEVBnZDwOg@eisner.encompasserve.org>,= > Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes: 3 >> > In article <+x2IDvG+Rgvz@tachxxsoftxxconsult>, A > wayne@tachysoft.xxx.320117.killspam.015d (Wayne Sewell) writes:  >> >> H >> >> It also determines *how* they support the platform.  For instance,
 > softwareJ >> >> partners has always been forced to use its own mechanism for license > keys> >> >> because of the incredible cost of the LMF PAK generator. >> >K >> > I find it unbelievable that they get a higher price than LJK Software.  >>L >> So how much is the thing now?  Last I heard, it was ten grand.  The price > may K >> or may not have gone down, but that's what it was at the time we started  > using  >> our own keys. > K > When we bought it (close to 10 years ago), the ISV (now CSA) discount was H > something like 65%.  We're still wondering how we upgrade to the Alpha
 > version.  # No Alpha version has been released.    ------------------------------  $ Date: Thu, 5 Jul 2001 13:32:01 -0400+ From: "John Saunders" <jws@ma.ultranet.com> : Subject: Re: 3 Reasons why VMS is alive and probably well++ Message-ID: <9i28cb$7af$1@bob.news.rcn.net>   7 "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message # news:3B449DBE.AC035245@gtech.com...  > John Saunders wrote:; > > "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message ' > > news:3B41BB9B.B896E94B@gtech.com...  > > > Alphaman wrote: H > > > > Don't forget, CSA membership and _site-wide_ SDK is MUCH cheaper	 than just ( > > > > ONE single-user MSDN membership. > > > J > > > Now - I have never believed that system/development-tools prices had any / > > > significant impact on support from ISV's.  > > L > > That depends on the ISV. For a small ISV, costs of development tools andC > > platforms can determine whether they support a platform at all.  >  > Hmmm.  > = > If the cost of a few thousand dollars is significant for an ; > ISV to decide whether they will support VMS, then I could = > not recommend anyone buying their product - or at least not / > for permanent use. It would be way too risky.   5 All companies go through periods where cash is tight.   J That's something that Digital didn't always appreciate. In the days beforeJ the first "ISV Program", there were no discounts, and no help from DigitalL other than calling Colorado. That changed when they listened to the cries ofJ their ISVs and created ISV packages of hardware and software. Finally, oneH could buy a VAXstation, loaded with software development licenses, for a# reasonable price. I bought two. :-)  --
 John Saunders  jws@ma.ultranet.com    ------------------------------  $ Date: Thu, 5 Jul 2001 21:05:36 +0900& From: "David Lee" <phongle@kornet.net> Subject: Re: 4 mm tape drive+ Message-ID: <9i1l4n$knv$1@news1.kornet.net>   L I did try to power cycle the drive.  At first, it seemed to work.  The light	 indicator I went off.  But after tape backup is done, I tried dismounting it, but the I tape got stuck and the light lid up again.  It seemed like some mechanism ; went bad or something.  Does anybody know what caused this?  Thanks/ steven.reece@quintiles.com wrote in message ...  >  > H >The normal way would be to power cycle the drive (that's what the TLZ07E >recommends when the two LEDs flash at 2Hz indicating a drive fault). I >If the ES40 is anything like its AlphaServer 4100 predecessor though, it " >will probably mean a server down. >Steve.  >  >David Lee asked : >>>>J >Does anyone know how to to reset the tape drive on an ES40?  The busy andJ >status light indicator is on even though there is no tape in it.  I tried >to J >insert the tape in but it won't take it.  It seemed like the latch is not >release or somehow. ><<< >    ------------------------------  % Date: Thu, 05 Jul 2001 10:29:16 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: 4 mm tape driveL Message-ID: <rdeininger-0507011029160001@user-2ivea1v.dialup.mindspring.com>  @ In article <VA.000003f9.3b2d0e19@sture.ch>, paul@sture.ch wrote:  O > In article <rdeininger-0407011120110001@user-2ive7io.dialup.mindspring.com>,   > Robert Deininger wrote:    K > > They're putting nasty 4 mm tape drives in nice ES40 systems?  Blecchh!   > > Who thought of that? > > P > > When I get my hobbyist GS320, I'm hoping it comes with a paper tape reader.  > > A > Who pays for your electricity?  A GS320/24 uses nearly 10KW :-)   , I didn't say I'm going to turn it on, did I?   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Thu, 05 Jul 2001 10:28:22 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: 4 mm tape driveL Message-ID: <rdeininger-0507011028220001@user-2ivea1v.dialup.mindspring.com>  C In article <NLG07.4723$Ib.492412@news1.primary.net>, "Jack Peacock"  <peacock@simconv.com> wrote:  A > "Robert Deininger" <rdeininger@mindspring.com> wrote in message H > news:rdeininger-0407011120110001@user-2ive7io.dialup.mindspring.com...G > > When I get my hobbyist GS320, I'm hoping it comes with a paper tape 	 > reader.  > > # > You don't back up to punch cards?      Nah, they're too modern for me.    --   Robert Deininger rdeininger@mindspring.com    ------------------------------  $ Date: Thu, 5 Jul 2001 21:40:09 +0900& From: "David Lee" <phongle@kornet.net># Subject: 4mm tape drive's mechanism + Message-ID: <9i1n3v$1jm$1@news1.kornet.net>   L I did try to power cycle the drive.  At first, it seemed to work.  The lightK indicator went off.  But after tape backup is done, I tried dismounting it,  but the D tape got stuck and the busy light lid up again.  It seemed like some	 mechanism J went bad or something.  Does anybody know what caused this? and how to fix it?  Thanks   ------------------------------  % Date: Thu, 05 Jul 2001 01:12:53 -0700 1 From: Vance Haemmerle <vance@toyvax.Tucson.AZ.US> % Subject: Re: Compaq switches to IA-64 2 Message-ID: <3B43BF15.361EA5A@toyvax.Tucson.AZ.US>   Christof Brass wrote:  >  > Vance Haemmerle wrote:J > >   That's gonna suck.  One nice thing about the VAX to Alpha transitionL > > was that data files could stay the same even though the executables wereH > > different.  Now, with Itanium not supporting F, D and G floats, it'sI > > almost as bad as having to switch endian-ness.  Will VAX fp really be H > > emulated in software?  Compaq gave up porting Java to VAX because ofK > > the horrible performance emulating IEEE on VAX.  How bad is it going toV# > > be emulating VAX floats on IPF?u >7@ > The is a chance that the other migration direction i.e. from a: > slower CPU to a faster one would make an emulation in SW
 > acceptable.   G   You mean from Alpha to IPF?  Unlike the Tru64 side, VMS on Alpha usedlI F and G floats by default, and D-floats with a compile switch. I see lots G of VMS users with datafiles having floats in the VAX format.  With the pE VAX to Alpha migration, these data files could be left unconverted aspI Alpha had hardware support for the VAX float arithmetic.  If IPF supportspL this in only software VMS is gonna be really slow for a lot of applications.* More reason to convert off of VMS I guess.   --B Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USK Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/a   ------------------------------  % Date: Thu, 05 Jul 2001 10:26:27 +0200q From: Magnus M <mmad@tips.se> % Subject: Re: Compaq switches to IA-64 & Message-ID: <3B4424B3.5020502@tips.se>   Vance Haemmerle wrote:   > Christof Brass wrote:s >  >>Vance Haemmerle wrote: >>I >>>  That's gonna suck.  One nice thing about the VAX to Alpha transitioneK >>>was that data files could stay the same even though the executables werelG >>>different.  Now, with Itanium not supporting F, D and G floats, it'snH >>>almost as bad as having to switch endian-ness.  Will VAX fp really beG >>>emulated in software?  Compaq gave up porting Java to VAX because ofrJ >>>the horrible performance emulating IEEE on VAX.  How bad is it going to" >>>be emulating VAX floats on IPF? >>>i@ >>The is a chance that the other migration direction i.e. from a: >>slower CPU to a faster one would make an emulation in SW
 >>acceptable.  >> > I >   You mean from Alpha to IPF?  Unlike the Tru64 side, VMS on Alpha usedrK > F and G floats by default, and D-floats with a compile switch. I see lotsrI > of VMS users with datafiles having floats in the VAX format.  With the tG > VAX to Alpha migration, these data files could be left unconverted asEK > Alpha had hardware support for the VAX float arithmetic.  If IPF supportsBN > this in only software VMS is gonna be really slow for a lot of applications., > More reason to convert off of VMS I guess. >  > --D > Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USM > Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/i >   G Or one could argue that people who write performance sensitive softwareHD should be able to convert their datafiles, if they can't I wouldn't B really trust them to develop performance sensitive software in the first place...   /magnus(   ------------------------------   Date: 5 Jul 2001 07:10:50 -0500o9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)?% Subject: Re: Compaq switches to IA-64s3 Message-ID: <ntZdivg7atUv@eisner.encompasserve.org>y  f In article <3B43BF15.361EA5A@toyvax.Tucson.AZ.US>, Vance Haemmerle <vance@toyvax.Tucson.AZ.US> writes: > Christof Brass wrote:  >>   >> Vance Haemmerle wrote:iK >> >   That's gonna suck.  One nice thing about the VAX to Alpha transition-M >> > was that data files could stay the same even though the executables weretI >> > different.  Now, with Itanium not supporting F, D and G floats, it's J >> > almost as bad as having to switch endian-ness.  Will VAX fp really beI >> > emulated in software?  Compaq gave up porting Java to VAX because of.L >> > the horrible performance emulating IEEE on VAX.  How bad is it going to$ >> > be emulating VAX floats on IPF? >>A >> The is a chance that the other migration direction i.e. from a ; >> slower CPU to a faster one would make an emulation in SWo >> acceptable. > I >   You mean from Alpha to IPF?  Unlike the Tru64 side, VMS on Alpha usedqK > F and G floats by default, and D-floats with a compile switch. I see lotslI > of VMS users with datafiles having floats in the VAX format.  With the hG > VAX to Alpha migration, these data files could be left unconverted asSK > Alpha had hardware support for the VAX float arithmetic.  If IPF supportsmN > this in only software VMS is gonna be really slow for a lot of applications., > More reason to convert off of VMS I guess.  C Or to stick with Alpha until such time as IA64 is faster, even with 
 the overhead.!   ------------------------------  # Date: Thu, 05 Jul 2001 11:48:23 GMT80 From: John Santos <john.santos@post.harvard.edu>% Subject: Re: Compaq switches to IA-64a= Message-ID: <MPG.15ae1e10ecfa09c989686@news.bellatlantic.net>2  3 In article <3B43BF15.361EA5A@toyvax.Tucson.AZ.US>, 3! vance@toyvax.Tucson.AZ.US says...x > Christof Brass wrote:o > >  > > Vance Haemmerle wrote:L > > >   That's gonna suck.  One nice thing about the VAX to Alpha transitionN > > > was that data files could stay the same even though the executables wereJ > > > different.  Now, with Itanium not supporting F, D and G floats, it'sK > > > almost as bad as having to switch endian-ness.  Will VAX fp really be J > > > emulated in software?  Compaq gave up porting Java to VAX because ofM > > > the horrible performance emulating IEEE on VAX.  How bad is it going tob% > > > be emulating VAX floats on IPF?d > >sB > > The is a chance that the other migration direction i.e. from a< > > slower CPU to a faster one would make an emulation in SW > > acceptable.y > I >   You mean from Alpha to IPF?  Unlike the Tru64 side, VMS on Alpha used K > F and G floats by default, and D-floats with a compile switch. I see lotsrI > of VMS users with datafiles having floats in the VAX format.  With the dG > VAX to Alpha migration, these data files could be left unconverted as K > Alpha had hardware support for the VAX float arithmetic.  If IPF supports N > this in only software VMS is gonna be really slow for a lot of applications., > More reason to convert off of VMS I guess.  F Not really.  If you want to convert off VMS, you will have to convert D your data files and port your apps.  If you want to stay on VMS, you? will only need to convert your data files.  How is this harder?.   >  > --D > Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USM > Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/7 >    ------------------------------  $ Date: Thu, 5 Jul 2001 09:14:42 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca>o% Subject: Re: Compaq switches to IA-64o: Message-ID: <hIZ07.18969$NY.1581925@news20.bellglobal.com>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:ntZdivg7atUv@eisner.encompasserve.org...LD > In article <3B43BF15.361EA5A@toyvax.Tucson.AZ.US>, Vance Haemmerle# <vance@toyvax.Tucson.AZ.US> writes:m > > Christof Brass wrote:t > >>C > >> The is a chance that the other migration direction i.e. from aw= > >> slower CPU to a faster one would make an emulation in SW  > >> acceptable. > >%K > >   You mean from Alpha to IPF?  Unlike the Tru64 side, VMS on Alpha used-H > > F and G floats by default, and D-floats with a compile switch. I see lotsJ > > of VMS users with datafiles having floats in the VAX format.  With theI > > VAX to Alpha migration, these data files could be left unconverted as D > > Alpha had hardware support for the VAX float arithmetic.  If IPF supportsB > > this in only software VMS is gonna be really slow for a lot of
 applications. . > > More reason to convert off of VMS I guess. >tE > Or to stick with Alpha until such time as IA64 is faster, even withe > the overhead.h  G Will that be after McKinley or after Madison? And will Compaq's portingrK efforts be stable at that point? I think that Alpha may be with us for manyl years to come.  
 Neil Rieck Kitchener/Waterloo/Cambridge,o Ontario, Canada.@ http://www3.sympatico.ca/n.rieck/links/compaq_memorial_site.html   ------------------------------   Date: 5 Jul 2001 10:23:53 -0500l9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) % Subject: Re: Compaq switches to IA-64y3 Message-ID: <rZpdT9aW87yi@eisner.encompasserve.org>-  f In article <hIZ07.18969$NY.1581925@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: > H > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message/ > news:ntZdivg7atUv@eisner.encompasserve.org... E >> In article <3B43BF15.361EA5A@toyvax.Tucson.AZ.US>, Vance Haemmerlel% > <vance@toyvax.Tucson.AZ.US> writes:p >> > Christof Brass wrote: >> >>eD >> >> The is a chance that the other migration direction i.e. from a> >> >> slower CPU to a faster one would make an emulation in SW >> >> acceptable.  >> >L >> >   You mean from Alpha to IPF?  Unlike the Tru64 side, VMS on Alpha usedI >> > F and G floats by default, and D-floats with a compile switch. I seeq > lotsK >> > of VMS users with datafiles having floats in the VAX format.  With therJ >> > VAX to Alpha migration, these data files could be left unconverted asE >> > Alpha had hardware support for the VAX float arithmetic.  If IPF 
 > supportsC >> > this in only software VMS is gonna be really slow for a lot ofr > applications.y/ >> > More reason to convert off of VMS I guess.  >>F >> Or to stick with Alpha until such time as IA64 is faster, even with >> the overhead. > I > Will that be after McKinley or after Madison? And will Compaq's portingcM > efforts be stable at that point? I think that Alpha may be with us for manyr > years to come.  G I do not know (or particularly care) the schedule for McKinley, Madison1F or Monroe.  If it works out, it works out.  If it does not, Alpha willG do fine.  I don't know how long Alpha will be with _you_, but it shouldD: be with _me_ for a long time just as I also still use VAX.   ------------------------------  % Date: Thu, 05 Jul 2001 11:18:11 -0500 * From: cjt & trefoil <cheljuba@prodigy.net>% Subject: Re: Compaq switches to IA-64s+ Message-ID: <3B449343.D9B5FA3C@prodigy.net>r   Neil Rieck wrote:i > H > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message/ > news:ntZdivg7atUv@eisner.encompasserve.org...o <snip>G > > Or to stick with Alpha until such time as IA64 is faster, even with  > > the overhead.a > I > Will that be after McKinley or after Madison? And will Compaq's porting>M > efforts be stable at that point? I think that Alpha may be with us for many  > years to come.  H Then you think Compaq will be with us for many years to come?  I wonder.   >  > Neil Rieck > Kitchener/Waterloo/Cambridge,  > Ontario, Canada.B > http://www3.sympatico.ca/n.rieck/links/compaq_memorial_site.html   ------------------------------  % Date: Thu, 05 Jul 2001 05:29:52 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>o1 Subject: Re: Compaq's Alpha design team for sale?d, Message-ID: <3B443353.F34C4BC7@videotron.ca>   Peter Jackson wrote:M > FMS was one of the first batch of layered products ported to Alpha - it was-K > needed for ALL-IN-1. TDMS was the screen handler that did not get ported.a    J From what I had *heard*, FMS has been deemed "not to be ported" and it wasF only later that the ALL-IN-1 group convinced Digital to port it (and IU wouldn't be surprised if it was the ALL-IN-1 group that would have done the porting).o   ------------------------------  % Date: Thu, 05 Jul 2001 19:46:27 +0010s% From: paddy.o'brien@zzz.tg.nsw.gov.auc1 Subject: Re: Compaq's Alpha design team for sale?t5 Message-ID: <01K5L0WCDFTU002CI2@tgmail.tg.nsw.gov.au>h   JF Mezei wrote"N  K >From what I had *heard*, FMS has been deemed "not to be ported" and it wassG >only later that the ALL-IN-1 group convinced Digital to port it (and IpM >wouldn't be surprised if it was the ALL-IN-1 group that would have done the d
 >porting).  2 This then begs the question, what is to be ported?  M As I said in another thread? -- I've lost track -- my applications rely very rI heavily on FMS and GKS, for which I pay a large software maintenance fee.e  N With the Compaq compiler guys going to Inhel, what is being supported?  Steve K Lionel seems to be one of the first to go.  Will I still have support from sM fortran@compaq.com?  Will compaq VMS (and T64) compilers still be maintained?e  J If the PC CVF is now IVF, what has Compaq got left?  These appeared to be K developed in parallel, but probably no longer.  Reading c.l.f, I was under nM the impression that this was one of Compaq's most successful compilers.  Now eJ just folded over to Inhel because Compaq could not understand how to deal  with successful products.i  7 When is John Reagan being told to take Pascal to Inhel?.  M Bloody hell, a PC box vendor not capable of seeing a wider world!!!!!  And a r8 failure at selling boxes or of being a service industry.  N (The latter comment personal to our corporate -- We had a "deal" with Digital > that sort of worked, when Compaq took over it screwed totally)   I'll omit the company name :-)   Regards, Paddy   ------------------------------  % Date: Thu, 05 Jul 2001 11:17:51 +0100e% From: Alan Greig <a.greig@virgin.net>o1 Subject: Re: Compaq's Alpha design team for sale?n8 Message-ID: <2kf8kt0vvge2rrl4j2ohhopc3ta58hq2bd@4ax.com>  C On Thu, 05 Jul 2001 19:46:27 +0010, paddy.o'brien@zzz.tg.nsw.gov.auT wrote:    O >With the Compaq compiler guys going to Inhel, what is being supported?  Steve  L >Lionel seems to be one of the first to go.  Will I still have support from N >fortran@compaq.com?  Will compaq VMS (and T64) compilers still be maintained?  7 Steve is going to Intel??  Can you provide a reference?u     > K >If the PC CVF is now IVF, what has Compaq got left?  These appeared to be hL >developed in parallel, but probably no longer.  Reading c.l.f, I was under N >the impression that this was one of Compaq's most successful compilers.  Now K >just folded over to Inhel because Compaq could not understand how to deal R >with successful products. > 8 >When is John Reagan being told to take Pascal to Inhel? >oN >Bloody hell, a PC box vendor not capable of seeing a wider world!!!!!  And a 9 >failure at selling boxes or of being a service industry.d >iO >(The latter comment personal to our corporate -- We had a "deal" with Digital r? >that sort of worked, when Compaq took over it screwed totally)  >  >I'll omit the company name :-)0 >' >Regards, Paddy    -- Alan   ------------------------------   Date: 5 Jul 2001 12:23:41 GMTu) From: leslie@clio.rice.edu (Jerry Leslie)i1 Subject: Re: Compaq's Alpha design team for sale? ' Message-ID: <9i1m8d$j57$1@joe.rice.edu>-  & Alan Greig (a.greig@virgin.net) wrote: :19 : Steve is going to Intel??  Can you provide a reference?n :e1 http://www.compaq.com/fortran/ipf-enterprise.htmln  ?   "...The Compaq Fortran engineering team is very excited to betC    part of this technology agreement which we believe will solidifyoC    Visual Fortran as the clear choice for end-users and Independent.    Software Vendors."     E Plus some of Steve's recent posts in the comp.lang.fortran newsgroup.    --Jerry Leslie   ------------------------------  % Date: Thu, 05 Jul 2001 14:41:29 +0100o% From: Alan Greig <a.greig@virgin.net>a Subject: Re: Compaq's fire sale 8 Message-ID: <lrq8ktc1vhp0fvc80sbhtbmh1l8qejnnct@4ax.com>  F On 5 Jul 2001 12:23:41 GMT, leslie@clio.rice.edu (Jerry Leslie) wrote:  ' >Alan Greig (a.greig@virgin.net) wrote:4 >:: >: Steve is going to Intel??  Can you provide a reference? >:2 >http://www.compaq.com/fortran/ipf-enterprise.html >i@ >  "...The Compaq Fortran engineering team is very excited to beD >   part of this technology agreement which we believe will solidifyD >   Visual Fortran as the clear choice for end-users and Independent >   Software Vendors."  @ Yeh, I've had a look at www. compaq.com/fortran and I see CompaqA Fortran is to become Intel Fortran except on VAX and Alpha. There F doesn't seem to be any mention of future development plans for FortranA on VMS or indeed any mention at all of Fortran on iVMS or iTRU64.UD There is mention of future support for Fortran on Windows and Linux.     >aF >Plus some of Steve's recent posts in the comp.lang.fortran newsgroup.   Yes, such as this:B >> More of interest to this group is the involvement of the CompaqH >> compiler teams.  Several of Compaq's compiler teams will move over toI >> Intel - some immediately (next few months), some over a longer period. E >> Fortran is the first to make the move, something Intel wanted verymH >> much.  (We will be located elswhere in the Nashua area - not "moving"
 >> very far!)u >>    B So who develops the compilers for iVMS then? Intel presumably? AndE won;t having the compiler teams working for Intel hamper the VMS IA64 A port. What does this mean for hobby licenses, DECCampus/CSLG etc?a  E What will Intel charge for a Fortran license on iVMS? Is this anothers RDB rip-off in the making?   >--Jerry Leslieo   -- Alan   ------------------------------  % Date: Thu, 05 Jul 2001 11:14:37 +0100e% From: Alan Greig <a.greig@virgin.net>s* Subject: Computing article on Alpha demise8 Message-ID: <4ae8kts9rtvd7ifgp4okcnf9vhgrp1ea7q@4ax.com>  ? In "Computing" dated 5th July 2001 appears the following (pg 3)   , Compaq sells off Alpha chip - Maggie Holland <maggie_holland@vnu.co.uk>  @ Users have welcomed Compaq's decision to sell off its Alpha chip division to Intel.  D The hardware giant has radical plans to take on IBM by concentrating@ more heavily on software and services. The approach has the full> backing of the Compaq user organisation (CUO), formerly DECUS.  F CUO says Alpha will fill holes in Intel's Itanium technology and allow3 both companies to concentrate on what they do best.A  F 'For Intel to finally get a 64-bit chip fully working with a user baseE is an amazing stroke. This is a fairly good move for the users on the,D understanding that several Compaq systems will need to remain for atB least the next 10 to 20 years. With this development the potential= scope could see revivals and opportunities far wider than aremA available at present,' said John Ferguson, vice president of CUO.l ----- END---  C John Ferguson is vice chair of DECUS UK (soon to be CUO if they get @ their way). Interesting to see the user organisations taking theE Compaq party line without even bothering to consult the members. Johne? Ferguson specialises in PC solutions and Windows NT integrationi3 according to the DECUS UK web site and his email is " mailto:John.Ferguson@scg-ltd.co.uk  @ So there we have it. I fully back Compaq's decision. I know this: because the vice chair of DECUS UK has just told me I do.  -- Alan   ------------------------------  % Date: Thu, 05 Jul 2001 12:24:50 +0000e  From: Steve.Spires@yellgroup.com. Subject: Re: Computing article on Alpha demise/ Message-ID: <00256A80.0044337C.00@quegw01.btyp>n  L Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza    N I have taken this opportunity to email John with my thoughts on his statement.< Should I receive a reply [I WAS couteous] I'll let you know.   Steve Spires        9 Alan Greig <a.greig@virgin.net> on 07/05/2001 10:14:37 AMi    To:        Info-VAX@Mvb.Saic.Com+ cc:         (bcc: Steve Spires/YellowPages) C From:      Alan Greig <a.greig@virgin.net>, 5 July 2001, 10:14 a.m.n  ! Computing article on Alpha demise:        ? In "Computing" dated 5th July 2001 appears the following (pg 3)e  , Compaq sells off Alpha chip - Maggie Holland <maggie_holland@vnu.co.uk>  @ Users have welcomed Compaq's decision to sell off its Alpha chip division to Intel.  D The hardware giant has radical plans to take on IBM by concentrating@ more heavily on software and services. The approach has the full> backing of the Compaq user organisation (CUO), formerly DECUS.  F CUO says Alpha will fill holes in Intel's Itanium technology and allow3 both companies to concentrate on what they do best.a  F 'For Intel to finally get a 64-bit chip fully working with a user baseE is an amazing stroke. This is a fairly good move for the users on the>D understanding that several Compaq systems will need to remain for atB least the next 10 to 20 years. With this development the potential= scope could see revivals and opportunities far wider than arenA available at present,' said John Ferguson, vice president of CUO.  ----- END---  C John Ferguson is vice chair of DECUS UK (soon to be CUO if they gete@ their way). Interesting to see the user organisations taking theE Compaq party line without even bothering to consult the members. John ? Ferguson specialises in PC solutions and Windows NT integrationF3 according to the DECUS UK web site and his email ise" mailto:John.Ferguson@scg-ltd.co.uk  @ So there we have it. I fully back Compaq's decision. I know this9 because the vice chair of DECUS UK has just told me I do.r -- Alan   ------------------------------  % Date: Thu, 05 Jul 2001 08:21:01 -0400m( From: Hamlyn Mootoo <univms@bigfoot.com>. Subject: Re: Computing article on Alpha demise+ Message-ID: <3B445BAD.F3371FE6@bigfoot.com>t  E I would think that an email to Maggie Holland is more in order, as itcB has more chance to have an effect than writing John Ferguson.  Mr.F Ferguson can't print a followup article, but I bet she can.  ReportersB love opposing points of view, especially when they get it from the horse's mouth. g :)   HM  ! Steve.Spires@yellgroup.com wrote:w > N > Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza > P > I have taken this opportunity to email John with my thoughts on his statement.> > Should I receive a reply [I WAS couteous] I'll let you know. >  > Steve Spires > ; > Alan Greig <a.greig@virgin.net> on 07/05/2001 10:14:37 AMI > " > To:        Info-VAX@Mvb.Saic.Com- > cc:         (bcc: Steve Spires/YellowPages)wE > From:      Alan Greig <a.greig@virgin.net>, 5 July 2001, 10:14 a.m.  > # > Computing article on Alpha demisek > A > In "Computing" dated 5th July 2001 appears the following (pg 3)D > . > Compaq sells off Alpha chip - Maggie Holland > <maggie_holland@vnu.co.uk> > B > Users have welcomed Compaq's decision to sell off its Alpha chip > division to Intel. > F > The hardware giant has radical plans to take on IBM by concentratingB > more heavily on software and services. The approach has the full@ > backing of the Compaq user organisation (CUO), formerly DECUS. > H > CUO says Alpha will fill holes in Intel's Itanium technology and allow5 > both companies to concentrate on what they do best.t > H > 'For Intel to finally get a 64-bit chip fully working with a user baseG > is an amazing stroke. This is a fairly good move for the users on theyF > understanding that several Compaq systems will need to remain for atD > least the next 10 to 20 years. With this development the potential? > scope could see revivals and opportunities far wider than arepC > available at present,' said John Ferguson, vice president of CUO.7 > ----- END--- > E > John Ferguson is vice chair of DECUS UK (soon to be CUO if they getoB > their way). Interesting to see the user organisations taking theG > Compaq party line without even bothering to consult the members. John A > Ferguson specialises in PC solutions and Windows NT integration 5 > according to the DECUS UK web site and his email ist$ > mailto:John.Ferguson@scg-ltd.co.uk > B > So there we have it. I fully back Compaq's decision. I know this; > because the vice chair of DECUS UK has just told me I do.A > -- > Alan   ------------------------------  % Date: Thu, 05 Jul 2001 13:30:06 +0000s  From: Steve.Spires@yellgroup.com. Subject: Re: Computing article on Alpha demise/ Message-ID: <00256A80.004A2DE0.00@quegw01.btyp>   L Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza    L I agree with what you say, but I made contact not to get a retraction in theP press [although that maybe an outcome, who knows] but to ask with what authority John might make the statement.   Steve Si        < Hamlyn Mootoo <univms@bigfoot.com> on 07/05/2001 12:21:01 PM    To:        Info-VAX@Mvb.Saic.Com+ cc:         (bcc: Steve Spires/YellowPages)tF From:      Hamlyn Mootoo <univms@bigfoot.com>, 5 July 2001, 12:21 p.m.  % Re: Computing article on Alpha demiseC        E I would think that an email to Maggie Holland is more in order, as it-B has more chance to have an effect than writing John Ferguson.  Mr.F Ferguson can't print a followup article, but I bet she can.  ReportersB love opposing points of view, especially when they get it from the horse's mouth. :)   HM  ! Steve.Spires@yellgroup.com wrote:l >mN > Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza >eP > I have taken this opportunity to email John with my thoughts on his statement.> > Should I receive a reply [I WAS couteous] I'll let you know. >c > Steve Spires >n; > Alan Greig <a.greig@virgin.net> on 07/05/2001 10:14:37 AM  >>" > To:        Info-VAX@Mvb.Saic.Com- > cc:         (bcc: Steve Spires/YellowPages)wE > From:      Alan Greig <a.greig@virgin.net>, 5 July 2001, 10:14 a.m.  >># > Computing article on Alpha demise? >nA > In "Computing" dated 5th July 2001 appears the following (pg 3)u > . > Compaq sells off Alpha chip - Maggie Holland > <maggie_holland@vnu.co.uk> >lB > Users have welcomed Compaq's decision to sell off its Alpha chip > division to Intel. > F > The hardware giant has radical plans to take on IBM by concentratingB > more heavily on software and services. The approach has the full@ > backing of the Compaq user organisation (CUO), formerly DECUS. >rH > CUO says Alpha will fill holes in Intel's Itanium technology and allow5 > both companies to concentrate on what they do best.h >.H > 'For Intel to finally get a 64-bit chip fully working with a user baseG > is an amazing stroke. This is a fairly good move for the users on the F > understanding that several Compaq systems will need to remain for atD > least the next 10 to 20 years. With this development the potential? > scope could see revivals and opportunities far wider than arelC > available at present,' said John Ferguson, vice president of CUO.  > ----- END--- > E > John Ferguson is vice chair of DECUS UK (soon to be CUO if they get0B > their way). Interesting to see the user organisations taking theG > Compaq party line without even bothering to consult the members. JohnyA > Ferguson specialises in PC solutions and Windows NT integrations5 > according to the DECUS UK web site and his email isa$ > mailto:John.Ferguson@scg-ltd.co.uk > B > So there we have it. I fully back Compaq's decision. I know this; > because the vice chair of DECUS UK has just told me I do.r > -- > Alan   ------------------------------   Date: 5 Jul 2001 11:05:52 GMTt3 From: gartmann@immunbio.mpg.de (Christoph Gartmann)c. Subject: Re: Computing article on Alpha demise0 Message-ID: <9i1hmg$g21$1@n.ruf.uni-freiburg.de>  ` In article <4ae8kts9rtvd7ifgp4okcnf9vhgrp1ea7q@4ax.com>, Alan Greig <a.greig@virgin.net> writes:@ >In "Computing" dated 5th July 2001 appears the following (pg 3) >h- >Compaq sells off Alpha chip - Maggie Holland< ><maggie_holland@vnu.co.uk>o >uA >Users have welcomed Compaq's decision to sell off its Alpha chip3 >division to Intel.n >>E >The hardware giant has radical plans to take on IBM by concentratingrA >more heavily on software and services. The approach has the fullh? >backing of the Compaq user organisation (CUO), formerly DECUS.h >dG >CUO says Alpha will fill holes in Intel's Itanium technology and allow 4 >both companies to concentrate on what they do best. >nG >'For Intel to finally get a 64-bit chip fully working with a user basetF >is an amazing stroke. This is a fairly good move for the users on theE >understanding that several Compaq systems will need to remain for at'C >least the next 10 to 20 years. With this development the potentiall> >scope could see revivals and opportunities far wider than areB >available at present,' said John Ferguson, vice president of CUO.
 >----- END---  >uD >John Ferguson is vice chair of DECUS UK (soon to be CUO if they getA >their way). Interesting to see the user organisations taking thesF >Compaq party line without even bothering to consult the members. John@ >Ferguson specialises in PC solutions and Windows NT integration4 >according to the DECUS UK web site and his email is# >mailto:John.Ferguson@scg-ltd.co.ukl >gA >So there we have it. I fully back Compaq's decision. I know thist; >because the vice chair of DECUS UK has just told me I do. s  C DECUS Germany started a poll soon after the decision became public.n  I don't know the result, though.   Regards,    Christoph GartmanneH -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, FRG                                               |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------  % Date: Thu, 05 Jul 2001 15:12:19 +0100o% From: Alan Greig <a.greig@virgin.net> . Subject: Re: Computing article on Alpha demise8 Message-ID: <uos8kt874i6re6k0sd3vsfcvi3k0tsomij@4ax.com>  E On Thu, 05 Jul 2001 13:30:06 +0000, Steve.Spires@yellgroup.com wrote::  M >Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza  >i >tM >I agree with what you say, but I made contact not to get a retraction in theTQ >press [although that maybe an outcome, who knows] but to ask with what authority  >John might make the statement.   C Because DECUS UK believes its current function is to support Compaqe@ through this transition as far as I can gather.  And here was me% thinking it was to support the users!   E It is far too early for DECUS spokesman to be making positive noises.rE That's Compaq's job. At best it should be ambivalent until we see howh? things pan out and can have a few more hard questions answered.g  E But to me it just looks as if Compaq has said all the soothing thingsmC to the right people to keep them onside until the final kick in thec5 teeth later. That's Compaq's track record after all. u   -- Alan   ------------------------------  + Date: Thu, 05 Jul 2001 12:49:44 -0500 (CDT) & From: Drew Shelton <drew@sematech.org> Subject: RE: CSWS 1.1 & TCPwaref- Message-ID: <01K5KMNB8CNS007M49@SEMATECH.Org>n  J >> >I get the same error when disabling SSL and listening on port 8080, soH >> >I think this has nothing to do with the privileged port problem that >> >DRIVERS V5.1 fixed.t >>J >> >The foremost problem seems to be the logical name APACHE$SHARED_SOCKETN >> >that somehow is not set (444 = %SYSTEM-F-NOLOGNAM, no logical name match). >>K >> FWIW, I don't have that logical defined either, but Apache works anyway.5  K >I believe CSWS V1.1 plays a lot with job-wide logicals, so it doesn't haveiM >to exist in the system table. As the APACHE$00 process is the master, a look/I >into LNM$JOB_xxx would be more revealing (Reminder to self: have to lookx5 >up how the job number in LNM$JOB_xxx is calculated).h  H Like you, I don't know how the job number is calculated for logical nameE tables.  So I did a SHOW LOG/TABLE=*/OUT=X.X and searched X.X for therF logical you mentioned.  It's not there.  In fact, the only tables thatI contained APACHE$* logical names were APACHE$LOGICAL_NAMES and the systemm table.   Drew  L ============================================================================6 Drew Shelton                         drew@sematech.org9 VMS Systems Manager                  office: 512-356-7575r9 Sematech                             fax:    512-356-7600I 2706 Montopolis Drive K Austin, TX 78741-6499                I speak for myself only, not Sematech."B     "OpenVMS is today what Microsoft wants Windows NT v8.0 to be!"I                                                         - Compaq, 9/22/98FL ============================================================================   ------------------------------  % Date: Thu, 05 Jul 2001 10:27:38 -0400t2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: DEC Net and TCP/IPyL Message-ID: <rdeininger-0507011027380001@user-2ivea1v.dialup.mindspring.com>  @ In article <3B437636.9A41843C@iee.org>, arcarlini@iee.org wrote:     > Phase IV boxes run only NSP.# > Phase V boxes can run one or bothe' > of NSP and OSI Transport (aka OSITP).r( > The usual mistake is to have a Phase V$ > running both but trying to talk to) > a Phase IV box. The Phase V box decides , > whether to use OSITP or NSP for it's first > attempt base on the transport  > precedence
 > (check withe< >         $ MC NCL SHOW SESSION CONTROL TRANSPORT PRECEDENCE; > you can abbreviate much of this if you don't like typing)i > : > The default was (and may still be) to use OSITP followed
 > by NSP.   H The default at V7.2-1 is "unspecified", which the documents for V7.1 say? means OSI only.  That won't mix well with phase IV, as you say.s  J (nsp,osi) seems to work fine, but if we had any nodes that only spoke osi,E I guess there would be a long delay while the nsp attempts timed out.    -- r Robert Deininger rdeininger@mindspring.com-   ------------------------------  # Date: Thu, 05 Jul 2001 15:14:02 GMT.- From: skulker <skulker@mailops.com.yourpants>o8 Subject: Disable DELETE, RENAME, and PURGE command verbs, Message-ID: <_u%07.2$O_5.1717@nnrp3.sbc.net>  
 Hello all,  E I was wondering if there is a quick and easy way to do the following:m  U One of our customers wants to take away the DELETE, RENAME, and PURGE commnads from ah] subset of users (long story!). He wants to replace the command with a short message that says e something to the effect "Call me". I have advised this customer against this - but he pays the bills!o  ] I am planning on these users executing a specific login command procedure that this "point ofw] contact" customer will maintain for his subset of users. I know the verbs can be removed fromi their tables with aa   $ SET COMMAND/DELETE=DELETEe  ! and then creating a global symbolu   $ DEL*ETE == "Whatever"   a This works OK unless you add a qualifier, such as /LOG. Then you get the "unrecognized qualifier"l error.  a Anyone have a hint on how to handle this? Is there something already out there that will do this?s  5 Oh yeah, this is a 5.5-2 system (another long story)!    Thanks in advance!   skulkerD email replies remove .yourpantse   ------------------------------  # Date: Thu, 05 Jul 2001 15:14:10 GMTp- From: skulker <skulker@mailops.com.yourpants> 8 Subject: Disable DELETE, RENAME, and PURGE command verbs, Message-ID: <6v%07.3$O_5.1823@nnrp3.sbc.net>  
 Hello all,  E I was wondering if there is a quick and easy way to do the following:a  U One of our customers wants to take away the DELETE, RENAME, and PURGE commnads from as] subset of users (long story!). He wants to replace the command with a short message that says4e something to the effect "Call me". I have advised this customer against this - but he pays the bills!D  ] I am planning on these users executing a specific login command procedure that this "point of,] contact" customer will maintain for his subset of users. I know the verbs can be removed fromt their tables with ac   $ SET COMMAND/DELETE=DELETE'  ! and then creating a global symbol    $ DEL*ETE == "Whatever"g  a This works OK unless you add a qualifier, such as /LOG. Then you get the "unrecognized qualifier"s error.  a Anyone have a hint on how to handle this? Is there something already out there that will do this?A  5 Oh yeah, this is a 5.5-2 system (another long story)!a   Thanks in advance!   skulkero email replies remove .yourpantse   ------------------------------  $ Date: Thu, 5 Jul 2001 16:25:37 +0100* From: "Richard Brodie" <R.Brodie@rl.ac.uk>< Subject: Re: Disable DELETE, RENAME, and PURGE command verbs, Message-ID: <9i20th$1u5a@newton.cc.rl.ac.uk>  a "skulker" <skulker@mailops.com.yourpants> wrote in message news:_u%07.2$O_5.1717@nnrp3.sbc.net...   W > One of our customers wants to take away the DELETE, RENAME, and PURGE commnads from a _ > subset of users (long story!). He wants to replace the command with a short message that saysa` > something to the effect "Call me". I have advised this customer against this - but he pays the bills!  ] How about making the global symbol a foreign command? Then it will swallow all the qualifierse happily.   ------------------------------  $ Date: Thu, 5 Jul 2001 11:34:41 -0400- From: "Peter Weaver" <peter.weaver@stelco.ca>r< Subject: Re: Disable DELETE, RENAME, and PURGE command verbs4 Message-ID: <xO%07.259967$Z2.3086333@nnrp1.uunet.ca>  : "skulker" <skulker@mailops.com.yourpants> wrote in message& news:_u%07.2$O_5.1717@nnrp3.sbc.net... > Hello all, >JG > I was wondering if there is a quick and easy way to do the following:c >dG > One of our customers wants to take away the DELETE, RENAME, and PURGEl commnads from aeG > subset of users (long story!). He wants to replace the command with ai short message that saysjI > something to the effect "Call me". I have advised this customer against, this - but he pays the bills!r > K > I am planning on these users executing a specific login command proceduree that this "point of4K > contact" customer will maintain for his subset of users. I know the verbs  can be removed fromi > their tables with ah >  > $ SET COMMAND/DELETE=DELETEg >n# > and then creating a global symbolu >r > $ DEL*ETE == "Whatever"R >rJ > This works OK unless you add a qualifier, such as /LOG. Then you get the "unrecognized qualifier" > error.   If you make the DEL*ETE symbol#    $ DEL*ETE == "@dir:new_delete X"r/ then you won't have any problems with the /LOG.a  J But remember that if the user spawns a new process they can get the DELETE verb back. i.e.;   TSTBED::PWEAVER $ rename x y@ %RENAME-E-SEARCHFAIL, error searching for SYS$USERS:[PWEAVER]X.; -RMS-E-FNF, file not found+ TSTBED::PWEAVER $ set command/delete=rename  TSTBED::PWEAVER $ rename x yF %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \RENAME\ TSTBED::PWEAVER $ spawni) %DCL-S-SPAWNED, process PWEAVER_1 spawnedd; %DCL-S-ATTACHED, terminal now attached to process PWEAVER_1q TSTBED::PWEAVER $ rename x y@ %RENAME-E-SEARCHFAIL, error searching for SYS$USERS:[PWEAVER]X.; -RMS-E-FNF, file not found TSTBED::PWEAVER $     F So if you^Jyour customer really wants to do this, I would create a newL DCLTABLES.EXE just for these users. I would also write a little program thatI simply writes out your message and then copy the DELETE, RENAME and PURGE K command definitions to call the new image. Also remember to take the modify 0 the SET COMMAND verb to point to your new image.   ------------------------------  % Date: Thu, 05 Jul 2001 16:59:16 +0100e- From: "POWERS, John" <John.POWERS@sema.co.uk>y< Subject: RE: Disable DELETE, RENAME, and PURGE command verbs= Message-ID: <D30A62ABC710D211AEE100A0C9D615EE0152901B@REAES2>   A Various people have suggest ways around this (the simplest that Ie, would use is do define the symbol like say..9 $ DEL*ETE == "@<dir>CALLME !" , so the rest is a comment.   A I would just like to rail against the wisdom of this entire idea.U  D If your customers are not captive (presumably not, or they would notB have access to call commands directly), then the command procedureB idea can be easily subverted, not just by people being sneaky, but0 simply by newbies, not sure what they are doing.  > Remember that symbols are not translated iteratively. One veryB common trick that people with dislike of typing, (especially those@ coming from a Unix environment, and liking familiar commands) is2 to stick various symbols in the login.com, such as $ RM :== DELETEh? This would completely stymie the idea. When our newbie wants to = delete a file s/he types 'rm filename', and without realising2; it, has spoiled the wonderful idea. The file just goes - noI 'please contact me' message.  A If they really must do this, then the better way to do this wouldc@ be to write a home-brewed command - a DELETE.CLD, which calls an; image to either output the message directly, or just run a m> LIB$DO_COMMAND to do what the customer wanted. This would then> be put into a new clitables, which would have to be installed,B and the SYSUAF modified to point the customers to the new clitable file.o  ? Beware that even this idea can be circumvented by a clever user A who wants to delete a file, and writes a few lines of programminggC to call LIB$DELETE_FILE. However it would certainly protect againstc3 innocent newbies accidentally bypassing the system.i  9 Best of all, talk your customer out of the whole idea :-)p   - John     -----Original Message-----? From: skulker [mailto:skulker@mailops.com.yourpants.sema.co.uk]o Sent: 05 July 2001 16:14 To: Info-VAX@Mvb.Saic.Comn8 Subject: Disable DELETE, RENAME, and PURGE command verbs    
 Hello all,  E I was wondering if there is a quick and easy way to do the following:i  E One of our customers wants to take away the DELETE, RENAME, and PURGE  commnads from aiK subset of users (long story!). He wants to replace the command with a shortC message that saysbL something to the effect "Call me". I have advised this customer against this - but he pays the bills!  I I am planning on these users executing a specific login command procedure  that this "point ofoI contact" customer will maintain for his subset of users. I know the verbs_ can be removed froml their tables with ae   $ SET COMMAND/DELETE=DELETE   ! and then creating a global symbol    $ DEL*ETE == "Whatever"s  H This works OK unless you add a qualifier, such as /LOG. Then you get the "unrecognized qualifier" error.  H Anyone have a hint on how to handle this? Is there something already out there that will do this?  5 Oh yeah, this is a 5.5-2 system (another long story)!m   Thanks in advance!   skulkery email replies remove .yourpantsi      -- Cheers, John  F  - Note  This message represents my opinions and nothing else, not theI   opinion of SEMA, my family, or the cricket club - though my dog Meg didmE   nod in agreement whilst I was typing. If you have any problems thensD   please complain to her (or me, but not SEMA, my family or the CC).      K ___________________________________________________________________________ B This email is confidential and intended solely for the use of the H individual to whom it is addressed. Any views or opinions presented are E solely those of the author and do not necessarily represent those of t Sema. M If you are not the intended recipient, be advised that you have received thiseI email in error and that any use, dissemination, forwarding, printing, or J- copying of this email is strictly prohibited.a  B If you have received this email in error please notify the Sema UK. Helpdesk by telephone on +44 (0) 121 627 5600.K ___________________________________________________________________________    ------------------------------   Date: 5 Jul 2001 04:05:19 -0700m  From: nclews@csc.com (Nic Clews)/ Subject: Re: Disk Cluster Size for Oracle Disks = Message-ID: <a720d610.0107050305.3cce6532@posting.google.com>r  
 Someone said:iG > This is either bogus or misunderstood advice.  Disk cluster size only J > plays a part in file allocation and plays no part in IO transfer sizes. > > Set the cluster size according to the disk size and the fileE > creation/extension behavior of the applications that use that disk.   E When working with a Cincom Supra/C:M database, I set our cluster size B at 8 to accommodate the database transfer size. (I was sys man and DBA).i  ; I had complaints the next day that the system was too fast.o  F Before you go thinking it was a file fragmentation issue, the database? files are not 'extended' they are formatted to hold a number of F records, and I knew from regular work to keep the data contiguous thatA the only two items that changed was the LBN for each file, and ofo1 course the cluster size. Disks held nothing else.e  @ I actually made the change based on what I learned about the PDMF (physical data manager) and how it accesses files, it does not use RMSF but performs its IO to an LBN using the key hash value. I thought thatF the cluster size of 8 may help, and it certainly appeared to. May have< been another factor of course, like the speed of the hashing> algorithm, but in programming I thought there were performance( benefits to aligning data to page sizes.  ) Regards, Nic Clews CSC Computer Sciences.g nclews at csc dot comt   ------------------------------  % Date: Thu, 05 Jul 2001 06:33:36 -0700h& From: Tom Crabtree <tccrab@sunset.net>. Subject: Re: Empty SCA Storageworks canisters?* Message-ID: <3B446CB0.63729B2B@sunset.net>   Tim:  E Check with Don Hyde at Hess Electronics in Tustin, CA.  He might havet some.  714-669-9838   Tell him I sent ya!-   Tom Crabtree   Tim Shoppa wrote:-  A > I once had a local source for empty (well, filled with dead SCAn; > drives) Storageworks canisters, but that's dried up.  Can 9 > anyone recommend dealers who sell such things?  I'm noth> > picky about grey vs blue, but it does have to be SCA inside. >- > Tim.   --A -----------------------------------------------------------------h My father used to tell me,> "Son, there is nothing wrong with being scared. . . as long as5 you don't let it affect you until the danger is over.n> Being hysterical is okay, too . . . afterwards and in private.A Tears are not unmanly . . . in the bathroom with the door locked.o; The difference between a coward and a brave man is mostly ao matter of timing"C  0       --------- Robert A. Heinlein -------------A -----------------------------------------------------------------    ------------------------------  + Date: Thu, 05 Jul 2001 17:10:23 +0200 (MET)o' From: ZINSER@sysdev.deutsche-boerse.comr) Subject: Helper applications with Mozillae; Message-ID: <01K5KV993DV68ZEP28@sysdev.deutsche-boerse.com>m   Hello,  B 	I've tried to setup helper applications with Mozilla, but without5 	success. Specifically I used the following settings:o   	Name: Adobe PDF files 	Extension: PDFs 	MIME Type: application/pdf  	Handled By Application xpdf  B 	Also after setting this, mozilla just saves the file to disk and A 	make no attempt to launch xpdf. Anybody can point out the error h 	in my ways?   	Environment: OpenVMS Alpha 7.3h 		     Mozilla 0.9.2   					Greetings, MartinP Dr. Martin P.J. Zinser                                 zinser@sysdev.exchange.de2 Deutsche Boerse Systems AG                        O Neue Boersenstr. 1                                     Tel: +49 69 2101 5634    L 60487 Frankfurt                                        FAX: +49 69 2101 3411P Germany                                                Private:  zinser@decus.de   ------------------------------   Date: 5 Jul 2001 11:46:52 -0500 - From: koehler@encompasserve.org (Bob Koehler)l- Subject: Re: Helper applications with Mozilla 3 Message-ID: <7cRwe9uKNy2X@eisner.encompasserve.org>t  e In article <01K5KV993DV68ZEP28@sysdev.deutsche-boerse.com>, ZINSER@sysdev.deutsche-boerse.com writes:  > Hello, > D > 	I've tried to setup helper applications with Mozilla, but without7 > 	success. Specifically I used the following settings:  >  > 	Name: Adobe PDF files > 	Extension: PDFe > 	MIME Type: application/pdfo > 	Handled By Application xpdf >   D Mozilla probably can't find your xpfd utility.  Bring up your HelperD Applications window, select application/pdf and hit the edit button.H Make sure Application is selected, then use Choose... to find and select the xdpf application.i  F For example, my Application is (on my ODS-5 volume I have XPDF.COM andD xpdf.exe, I don't really know how mozilla decides whether to use the .COM or the .exe).  *    /USER1/KOEHLER/TOOLS/xpdf-092/xpdf/XPDF  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationn= NASA GSFC Flight Software       | Federal Sector, Civil GrouprE                                 | please remove ".aspm" when replyings   ------------------------------  % Date: Thu, 05 Jul 2001 12:34:33 +0100 / From: Nigel Arnot <sysmgr@maxwell.ph.kcl.ac.uk>=+ Subject: re: I didn't stick it upside down!=7 Message-ID: <009FE8D7.4F04970F.20@maxwell.ph.kcl.ac.uk>    > P > > Actually, it's not hard and should be every bit as reliable as a normal one. > >C> > > All you do is ping the front off the storageworks canisterK > > ( not easy!) and then if the connections are wires rather than flexibleaE > > printed circuit stuff, rotate it 180 degrees and push it back on.e > ? > No problem. I have the correct tool to open the SBB carriers.h& > I have just rotated the front plate.  G Shame. I had visions of some Compaq production person getting bored andeJ planting a joker in the pack. Or someone dropping a canister from a great E height, jamming the front back on, jamming it back in the shelf, and OK discovering that the disk had survived undamaged so no need to confess ....k > J > > You might succeed with the flexi printed circuit stuff as well, but an1 > > engineer would call that seriously bad taste.h > # > I am afraid I didn't get that :-(   I I usually have a well-developed sense of "the right thing" and "the wrongwI thing" with respect to software and engineering. Putting the front onto a K storageworks canister so that the flexible PCB material has a half-twist in G it is clearly the wrong thing, compared to the same with no half-twist,,G even if there's no significant extra strain on the flexi PCB because ofoB the twist. (If there is much extra strain, it's no longer mere bad taste, it's unspeakable!).  D I'm assuming that the original DEC Storageworks designers didn't do E it the "wrong" way, in which case your southern-hemisphere version is " actually an aesthetic improvement!  J If anybody wants to further baffle their field circus, I think it ought toM be possible to remove the flexible PCB carrying the LEDs from the front panelsJ and insert it with the lead-out to the right instead of the left (or vice E versa). This will swap the lights, or in the case of the upside-down  I version put them back into the canonical top and bottom relationship ....a   	Yours,d
 		Nigel Arnota- 		NRA@MAXWELL.PH.KCL.AC.UK                      7 		"In the beginning there was nothing, which exploded."r   ------------------------------  % Date: Thu, 05 Jul 2001 08:59:40 -0500t+ From: Christopher Smith <csmith@amdocs.com>e  Subject: RE: IA64 Rocks My WorldL Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D2039@cmiexch1.cmi.itds.com>  @ ia64prince?  Shouldn't that be theuserformerlyknownasia64prince?  6 Ah well.  Are we gonna let the elevator bring us down?   Regards,   Chrise  ! Christopher Smith, Perl Developerm Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");D '6  7   > -----Original Message-----> > From: ia64prince@hotmail.com [mailto:ia64prince@hotmail.com]  	 > Hey!!!!i  C >      You know in many ways it is much better than the fate of the G > abandoned dog I saw this morning. Its owner took this old dog removedeF > the collar and left it on the streets. I am sure Animal shelter will > take good care of it.h  B >      At least Compaq had the decency to take it to Intel. It mayD > survive and maybe even thrive. I feel more sorry for the dog. Stop
 > whining!   > > Andy Grove's Bitch,i > > 
 > > IA69QUEENs > > " > > PS I Like EPIC Sized Hardware. >    ------------------------------  * Date: Thu, 5 Jul 2001 15:57:32 +0000 (UTC)' From: david20@alpha2.mdx.ac.uk (D.Webb)h  Subject: RE: IA64 Rocks My World+ Message-ID: <9i22pc$9ts$2@aquila.mdx.ac.uk>n  z In article <3B55D7F383B0D31197D9009027541CBF0D9D2039@cmiexch1.cmi.itds.com>, Christopher Smith <csmith@amdocs.com> writes:A >ia64prince?  Shouldn't that be theuserformerlyknownasia64prince?s > 7 >Ah well.  Are we gonna let the elevator bring us down?  >-	 >Regards,-? >> From: ia64prince@hotmail.com [mailto:ia64prince@hotmail.com]c >d
 >> Hey!!!! >dD >>      You know in many ways it is much better than the fate of theH >> abandoned dog I saw this morning. Its owner took this old dog removedG >> the collar and left it on the streets. I am sure Animal shelter willt >> take good care of it. >sC >>      At least Compaq had the decency to take it to Intel. It may E >> survive and maybe even thrive. I feel more sorry for the dog. Stoph >> whining!h >s >> > Andy Grove's Bitch, >> > C  ; As you say the dog may be taken care of by Animal Shelter. sA Alpha is in a much worse position. Compaq have just taken it to adM vivisectionist who will cut it up to find out how it ticks and might possibly-: try and use some of it's organs in a transplant operation.6 It is very doubtful Alpha will survive such treatment.    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------   Date: 5 Jul 2001 09:11:56 -0500 - From: koehler@encompasserve.org (Bob Koehler)b& Subject: Re: Need XML Parser for C/C++3 Message-ID: <SR$extRyPmCz@eisner.encompasserve.org>o  g In article <e18dc10e.0107040120.350b7304@posting.google.com>, subodh_sd@infy.com (Subodh Damle) writes:u > Hi, A > Does anyone know any XML Parser for C/C++ available under VMS ? N > Alternatively, has anyone tried porting any parser library for UNIX to VMS ?  = A Java based parser has been ported.  Try www.compaq.com/javan  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporations= NASA GSFC Flight Software       | Federal Sector, Civil GrouptE                                 | please remove ".aspm" when replyingb   ------------------------------  % Date: Thu, 05 Jul 2001 19:06:53 +0200a= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>u& Subject: Re: Need XML Parser for C/C++) Message-ID: <3B449EAD.206DA145@gtech.com>e   Subodh Damle wrote:hA > Does anyone know any XML Parser for C/C++ available under VMS ?pN > Alternatively, has anyone tried porting any parser library for UNIX to VMS ?  3 There are one available at www.openvms.compaq.com !    Anything wrong with that ?   Arne   ------------------------------  $ Date: Thu, 5 Jul 2001 09:36:19 -0400. From: "Jerry Alan Braga" <jabraga@flanagan.ca>' Subject: New Mailbox 0.7 (anyone using)R4 Message-ID: <G3_07.259841$Z2.3085573@nnrp1.uunet.ca>   Has anyone got this working.   Config:r   OpenVMS 7.1-1H2t Compaq TCPIP 5.1 ECO-1 Compaq C V6.4-005a  L I downloaded the new version and installed it. but I try to run it I get the banner but then this stack dumpA   $mc mlb_main  ; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtualn address=000000000000& 000A, PC=000000000003AE60, PS=0000001B8                         Version 0.7 -  ESME Sudria 20012   Improperly handled condition, image exit forced.1     Signal arguments:   Number = 0000000000000005t1                         Name   = 000000000000000Ce1                                  0000000000010000 1                                  000000000000000Ah1                                  000000000003AE60D1                                  000000000000001B        Register dump:J     R0  = 0000000000000001  R1  = 00000000000500A8  R2  = 0000000000012920J     R3  = 0000000000000001  R4  = 0000000000000007  R5  = 0000000000000000J     R6  = 000000007AF7D840  R7  = 000000007AF7D7A0  R8  = 000000007AF7D700J     R9  = 000000007AF7D660  R10 = FFFFFFFDFF7FE000  R11 = 000000000000000AJ     R12 = 000000007AF7D510  R13 = 000000007AF7D520  R14 = 0000000000000000J     R15 = 00000000009FE8B7  R16 = 00000000000101B0  R17 = 000000007AF7D520J     R18 = 000000007AF7D510  R19 = 000000000000000A  R20 = 000000007AF7D518J     R21 = FFFFFFFDFF7FE000  R22 = 0000000000000001  R23 = 0000000000000001J     R24 = 0000000000000012  R25 = 0000000000000005  R26 = 0000000000030690J     R27 = 0000000000012920  R28 = 00000000000BDD48  R29 = 000000007AF7D420J     SP  = 000000007AF7D410  PC  = 000000000003AE60  PS  = 100000000000001B   ------------------------------  $ Date: Thu, 5 Jul 2001 11:32:53 +0200) From: "Pbo" <philippe.bocher@euriware.fr> ! Subject: Re: Nodenames in cluster-$ Message-ID: <3b442672@news.euriware>  . <Ingemar Olson > a crit dans le message news:$ 01K5J92BKZTG90NMI5@dairyworld.com... > I Bingo'd too soon.E >DF > The other thing I need to be able to find out is whether the node isB > actually up and running. (and I can't shut anything down while I experiment)t > K > Does the f$csid only return info for nodes that are "up", or will it alsopC > include (eg) nodes that it knows have been up but now may not be?i >dH > If it's the latter, which argument to f$getsyi will let me distinguish1 > between the functional vs non-functional nodes?E >F >.G > btw: the reason I want this is that we have a menuing system and somel app'ssB > are only supposed to run on a specific node. Unless that node is unavailable, > in which case any node is ok.-  ( OK VMS7.3, the CSID reapears just after:  , %CNXMAN: Now a vmscluster member--system XXX   Hope this help   ------------------------------  # Date: Thu, 05 Jul 2001 15:37:15 GMT 0 From: "P. Thompson" <thompson-nospam@new.rr.com>, Subject: Re: PointSecure site was hacked ???J Message-ID: <Pine.LNX.4.33.0107051036240.31583-100000@malacandra.localnet>  E There was a hack several weeks ago where NT based domain servers werewF sending false addresses for various domains.  Perhaps this is similar.  * On Wed, 4 Jul 2001, Paul Blenderman wrote:  N > Unless the DNS servers are VMS-based, this is OT. www.pointsecure.com is OK. > M > The problem is that you have a 50% chance of getting the wrong address fromt > DNS.+ > (IE, Netscape, etc., etc. is irrelevant.)h > D > Two of the four DNS servers responsible for pointsecure.com are in > inetlabs.com. 2 > They supply the correct address: 65.104.226.166. >dA > The other two are at gobase2.com. They supply the wrong addresse > 63.149.157.92.J > This address is in the same subnet as www.gobase2.com. The SOA record is > also+ > completely different and doesn't point to  >oF > gobase2.com, phatchip.com and pointsecure.com all belong to the same > companiesiL > at the same address that is also listed at the "real" www.pointsecure.com.H > Unless this was a very thorough hacker, I'd say an admin probably just > deliberately orm > undeliberately screwed up. > 4 > "Alan Greig" <a.greig@virgin.net> wrote in message4 > news:0ac6ktofnqcecofnndrf8nqpch186ai2cq@4ax.com...' > > On Wed, 04 Jul 2001 10:29:51 -0300,_. > > fabio_compaq@ep-bc.petrobras.com.br wrote: > >l: > > >I am connecting to the homepage and it is appearing : > > >lC > > > Name                    Last modified       Size  Descriptiony > >eN > >--------------------------------------------------------------------------- > -----t6 > > > Parent Directory        15-Jun-2000 01:46      -6 > > > Get out of here/        20-Jun-2001 17:01      - > > >r > > >  > > N > >--------------------------------------------------------------------------- > -----r > > > : > > >Apache/1.3.14 Server at phatchat.phatchip.com Port 80 > >. > > FC,_ > >_E > > I see the same as you but I suspect config problems rather than a-C > > hacker. If you click on get out of here it does bring up a pagec > >c > >m > > -- > > Alan >: >: >s   -- e* Leave the nospam in, correct email address   ------------------------------  % Date: Thu, 05 Jul 2001 08:25:53 -0700i! From: Tom Linden <tom@kednos.com>  Subject: POP server on tcpip5.1 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIAEMGCOAA.tom@kednos.com>s  K Just installed tcpip5.1 on 7.3 AXP.  How do I configure SMTP to support POPi clientsiL logging (to SMTP) from their PCs? Specifically, suppose a client is assignedI and IP and node name, NODE, such that his address is John@NODE.kednos.coma  9 1.  Do I have to run TCPIP$config to make the associationpH xx.xxx.xxx.xxx  NODE.kednos.com ?    Is there no HOSTS source file here?  F 2.  How do I configure SMTP to allow the client to login from his mail programr to retrieve is mail?  J I find the documentation much too general.  This is a simple routine task. Is there anyK How To, documentation anywhere?  I looked in the VMS FAQ but nothing there.r   ------------------------------  % Date: Thu, 05 Jul 2001 12:32:33 -0400t2 From: rdeininger@mindspring.com (Robert Deininger)# Subject: Re: POP server on tcpip5.1uL Message-ID: <rdeininger-0507011232330001@user-2ivea1v.dialup.mindspring.com>  D In article <CIEJLCMNHNNDLLOOGNJIAEMGCOAA.tom@kednos.com>, Tom Linden <tom@kednos.com> wrote:c  M > Just installed tcpip5.1 on 7.3 AXP.  How do I configure SMTP to support POPr	 > clientsoN > logging (to SMTP) from their PCs? Specifically, suppose a client is assignedK > and IP and node name, NODE, such that his address is John@NODE.kednos.coma > ; > 1.  Do I have to run TCPIP$config to make the associationsJ > xx.xxx.xxx.xxx  NODE.kednos.com ?    Is there no HOSTS source file here?  I See the SET HOST command in TCPIP.  This is like the unix HOSTS file, but F it's not a plain text file you edit.  You use the command interface toI change it.  You don't need to do this if you have a nameserver configuredo on the network.l  H > 2.  How do I configure SMTP to allow the client to login from his mail	 > programo > to retrieve is mail?  H You'll have to enable and start the POP service, if you haven't already.   $ @sys$manager:tcpip$config    then option 3 on the menu-2      then option 13 is POP (in the version I have)  $ Note that POP is separate from SMTP.    O Also, the POP user will have to have a VMS account, with a valid password, etc.r    L > I find the documentation much too general.  This is a simple routine task. > Is there anyM > How To, documentation anywhere?  I looked in the VMS FAQ but nothing there.n  C Well, POP is in the TCPIP management manual.  I don't know if it istI sufficiently step-by-step.  But I figured it out, so the docs must not be-I too bad.  My intuition on things tcpip is not very good -- I have to rely05 on the manuals.  Maybe I've just gotten used to them.b   -- o Robert Deininger rdeininger@mindspring.come   ------------------------------  % Date: Thu, 05 Jul 2001 09:46:50 -0700 ! From: Tom Linden <tom@kednos.com>t# Subject: RE: POP server on tcpip5.1e9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEMJCOAA.tom@kednos.com>A  G So the user does not have a separate POP account, pre se, but has a VMS  account?   > -----Original Message-----; > From: Robert Deininger [mailto:rdeininger@mindspring.com]t' > Sent: Thursday, July 05, 2001 9:33 AMe > To: Info-VAX@Mvb.Saic.Comv% > Subject: Re: POP server on tcpip5.1z >a >9F > In article <CIEJLCMNHNNDLLOOGNJIAEMGCOAA.tom@kednos.com>, Tom Linden > <tom@kednos.com> wrote:e >aC > > Just installed tcpip5.1 on 7.3 AXP.  How do I configure SMTP tos
 > support POP  > > clients = > > logging (to SMTP) from their PCs? Specifically, suppose a  > client is assigned8 > > and IP and node name, NODE, such that his address is > John@NODE.kednos.com > > = > > 1.  Do I have to run TCPIP$config to make the association L > > xx.xxx.xxx.xxx  NODE.kednos.com ?    Is there no HOSTS source file here? > K > See the SET HOST command in TCPIP.  This is like the unix HOSTS file, butnH > it's not a plain text file you edit.  You use the command interface toK > change it.  You don't need to do this if you have a nameserver configured  > on the network.e >pJ > > 2.  How do I configure SMTP to allow the client to login from his mail > > programn > > to retrieve is mail? >fJ > You'll have to enable and start the POP service, if you haven't already. >t > $ @sys$manager:tcpip$configy >   then option 3 on the menu 4 >      then option 13 is POP (in the version I have) >t& > Note that POP is separate from SMTP. >  >lB > Also, the POP user will have to have a VMS account, with a valid > password, etc. >  >m@ > > I find the documentation much too general.  This is a simple > routine task.e > > Is there any@ > > How To, documentation anywhere?  I looked in the VMS FAQ but > nothing there. >xE > Well, POP is in the TCPIP management manual.  I don't know if it is-K > sufficiently step-by-step.  But I figured it out, so the docs must not be K > too bad.  My intuition on things tcpip is not very good -- I have to rely 7 > on the manuals.  Maybe I've just gotten used to them.  >- > -- > Robert Deininger > rdeininger@mindspring.com1 >4   ------------------------------   Date: 5 Jul 2001 08:53:45 -0700:+ From: msfrancisusa@netscape.net (M.Francis)-G Subject: Re: Problems Creating ODBC Connections to RDB databases on vmss= Message-ID: <a6cbd3e3.0107050753.67bd8022@posting.google.com>   4 oracle technet has the driver download available...:< http://otn.oracle.com/software/products/rdbodbc/content.html   and release notes..:B http://technet.oracle.com/products/rdbodbc/htdocs/odbc_rn_3012.htm  A check the client and server that they are setup for connectivity.a   1. rdb server...:s9 Check the server to determine that sqlservices is runningC  / $ sqlsrv_manage   :== $SYS$SYSTEM:sqlsrv_manageg $ sqlsrv_managea SQLSRV> connect to server; Connecting to server ...	 Connected    -- what services are running SQLSRV> show services;   -- check a specific serviceu4 SQLSRV> show service user_defined_service_name full;  B -- check service attributes that access is granted to the user via identifier(role) or username0 Access to service USER_DEFINED_SERVICE_NAME_HERE     Granted to users:a&  	 PRIVILEGED_USER 'FRANCIS_M' 'TESTX' .h .h ."   2. windows client ...:<     use odbc driver manager to view details of the rdb dsn  (     configured to access the rdb driver 9     should specify the server/service[or use the service  <    'generic' to access any database the user has access to].  1 if using a named/database service, verify on the B> server that the service is running and that the said user has  access to the same.t  9 for a universal/generic service the database is accessed S? by specifying the file/path and the logical/location in the dsns configuration.  = 3. check that the configuration is valid by performing a testa
 connection/ through the oracle test app or ms-access(duck).   E 4. lastly, just a warning, this scenario could wreak havoc on the db hB where unintentional dml can take place, (a keystroke in ms-access F along with an up or down arrowkey combination can accidentally change  lookup values to gibberish)o  5 if there are no db constraints or dbroles/identifiersn= to exert business rules then using apps such as Access/Excel .B allow writes that are as easy as typing and the db is only as good as the data that goes in...-  ? sorry bout the long answer. a lot more than you ever wanted to   know bout odbc connections,eh?A parting words, check out technet, it's tops for just this type ofD info.0   cheers,0 mary   ------------------------------  % Date: Thu, 05 Jul 2001 09:01:57 +0200n5 From: Klaus-Werner Gurgel <gurgel@ifm.uni-hamburg.de>a1 Subject: Re: SSH client, FISH, -- sources anyone?p2 Message-ID: <3B442D05.6B73284E@ifm.uni-hamburg.de>  ? I found FISH006.ZIP and FISHU1006.ZIP in my archive. I rememberk< there also was a patch concerning logical names, which I did& not apply. I have put the two files to0 http://ifmaxp1.ifm.uni-hamburg.de/ftp/VMS_Progs/ Hope it helps, Klaus-Wernere   Ian Burgess wrote: > @ > I've just scanned the web for the source of a good SSH client. > A recurring message is...fO > "The OpenVMS SSH1 client is done by Christer Weinigel and Richard Levitte and 0 > is available at  http://www.free.lp.se/fish/." > = > It seems unanimous that FiSH is the way to go, but there isfM > a sad story -- a disk head crash has put LP (www.free.lp.se) out of action.  > A > If someone has the distribution from there I would be grateful.- > ' > I think Richard Levitte would be too.0 > 
 > Ian Burgess2 > University of Queensland > I.Burgess[at]its.uq.edu.au > www.its.uq.edu.au2   ------------------------------  " Date: Thu,  5 Jul 01 09:27:11 +200' From: huber@mppmu.mpg.de (Joseph Huber)s1 Subject: RE: SSH client, FISH, -- sources anyone?c, Message-ID: <9i14sk$22cg$1@kiosk.rzg.mpg.de>  - In Article <9i0ni6$d25$1@bunyip.cc.uq.edu.au>l7 ccburgess@uqstu.jdstory.uq.edu.au (Ian Burgess) writes:c? >I've just scanned the web for the source of a good SSH client.d >A recurring message is...N >"The OpenVMS SSH1 client is done by Christer Weinigel and Richard Levitte and/ >is available at  http://www.free.lp.se/fish/."a< >It seems unanimous that FiSH is the way to go, but there isL >a sad story -- a disk head crash has put LP (www.free.lp.se) out of action.@ >If someone has the distribution from there I would be grateful.& >I think Richard Levitte would be too.
 >Ian Burgess   >University of Queenslands >I.Burgess[at]its.uq.edu.au  >www.its.uq.edu.au  - I zipped my working directory (V 0.6-1) into a  >   http: or ftp://wwwvms.mppmu.mpg.de/~huber/pds/fish_0_6_1.zip   Is it the latest ?   -- tI This message does not represent the policies of the Max-Planck-Institute.iB Joseph "Sepp" Huber, MPI Physik, http://wwwvms.mppmu.mpg.de/~huber   ------------------------------  / Date: Thu, 05 Jul 2001 08:15:30 +0200 (MET DST)-& From: Rudolf Wingert <win@fom.fgan.de>; Subject: Re: Strange behavior of BACKUP/SINCE=BACKUP/RECORDe6 Message-ID: <200107050615.IAA19561@sinet1.fom.fgan.de>   Hello,   Jean-Fran=E7ois Marchal wrotes:0   <<<2 Did you check the system time ?u <<<s  % Yes. It was the actual date and time.    Regards Rudolf Wingert   ------------------------------  / Date: Thu, 05 Jul 2001 08:39:53 +0200 (MET DST) & From: Rudolf Wingert <win@fom.fgan.de>; Subject: RE: Strange behavior of BACKUP/SINCE=BACKUP/RECORDn6 Message-ID: <200107050639.IAA19656@sinet1.fom.fgan.de>   Hello,  N thank's to John Macallister. I think that the two commands: SET VOLUME/REBUILDJ and ANAL/DISK/REPAIR are good to be a solution for our problem. I will try it and report the result.v   Regards Rudolf Wingert   ------------------------------  $ Date: Thu, 5 Jul 2001 02:35:39 -0400' From: "Bill Todd" <billtodd@foo.mv.com>r" Subject: Re: The Alpha/IA64 Hybrid' Message-ID: <9i11ku$mk$1@pyrite.mv.net>3  1 "Rich Walker" <rw@shadow.org.uk> wrote in message * news:m33d8cvsy7.fsf@lin-pc.shadow.local...+ > "Bill Todd" <billtodd@foo.mv.com> writes:a   ...r  K > > The above diagram - with all the 'fileserver' entries removed - is whatw waseB > > being recently discussed in comp.arch/comp.arch.storage in the
 'commodityJ > > storage servers' thread (the storage boxes cooperate to serve files or spaceg, > > on logical volumes directly to clients). >uF > AFAICT that discussion was more about what would go *in* the storageF > boxes. The issue of how to coherently generate a filesystem across aF > collection of collaborating boxes seemed to get glossed over, though > could have missed it.g  I The discussion originated with a question on my part about whether anyone K knew of a reason why approaches rooted in Stonebraker & Schloss' early work0G on expanding RAID concepts to distributed servers (such as the BerkeleySJ "Serverless Network File System" xFS work and Ed Lee's 'Petal' project forJ DEC) had never resulted in commodity commercial products.  I never got anyE kind of an answer, I assume because either  a) the topic is a bit too L specialized for most readers of those newsgroups or  b) the readers for whom( it's not too specialized aren't talking.  F So the topic wasn't intended to be an architecture discussion, and theG architecture includes both some things that I'm not free to discuss and0I other things that I'm not sure I want to discuss at the moment (having an0. interest in product development in this area).   >7G > I can see how you might generate a load-balancing logical volume with0F > an intra-storage-box broadcast protocol for attach and detach, whichJ > raises an interesting question of what amount of redundancy is necessaryE > in such a system given reasonable rates of removal of components...0  L Increased redundancy costs write performance (though you may get a bit of itE back on reads).  It can also cost complexity if it attempts to handle0C frequent failures.  So I'm inclined to think, especially given that K component costs are low and continuing to decrease, that the minimal amount K of redundancy consistent with the desired availability under the assumption1H that outages are only failure-related rather than simply the result of a workstation reboot makes sense.3   ...@  & > > But the clients have to trust eachI > > other a lot more than when they're separated from the storage serverso andnE > > can rely upon storage-server protection mechanisms.  Clients thatn	 cooperatecI > > to export a single, stable application to a much wider external worldt (e.g.,I > > Web servers) tend to fall into this category, but clients that may be I > > running virtually anything (which can compromise their robustness) or  are inK > > the service of individuals (e.g., workstations) who may elect to reboot  themE > > at any time may better be kept separate from the storage servers.s >aF > That's the redundancy problem. I assume that someone, somewhere, hasG > done the equivalent of merging the spare disk space on a network intonI > one big storage pool, and has dealt with the "random reboot" problem bya > a RAID-type technique. >XH > I've been considering it from the low-end, where each machine has diskI > space of a few tens of GB, and reboot probabilities are fairly low, butcC > machines might be very slow from time to time. However, without a0E > implementation of a filesystem that supports multiple machines eachlE > generating the same logical volume as each other from the available ! > data, I can't see how to do it.i  I That sounds something like the Berkeley 'Network of Workstations' ('NOW')sG effort, of which the work I mentioned above was a part.  But as I said,rL components are cheap enough that using anything other that relatively stableD nodes to serve the storage (such that additional redundancy would beF required to make up for the vastly decreased reliability) may not makeF sense:  it doesn't take a very large average percentage of nodes beingL off-line to start consuming inordinate resources as they recover and must beL brought back up to date (well, I suppose that could be considered a researchH area, but I'm not sure that the problem justifies it given that it wouldI almost certainly increase the complexity of an already-complex system andr. that an inexpensive hardware solution exists).   >.L > So, my next question is: is there a filesystem that allows each machine inH > the network to generate the same image as all the others, and maintainH > synchronisation between them, and cope with permanent loss of parts of > the storage?  G Not that I know of.  VMS's ODS-2 file system might, if it had much morecH comprehensive underlying volume management (effectively virtualizing theL distributed storage in a more-than-RAID-like manner).  IBM's GPFS on AIX mayK be somewhat similar to VMS in this regard (and VSAM on Parallel Sysplex has-J some similar capabilities, but is otherwise a bit weirder than many peopleA wish to deal with, at least as a common file system).  Most other I distributed file systems either partition the data (like the Unix systems-L previously mentioned in this thread) or have a central meta-data server thatL tells the clients how to access shared storage devices directly and performsF centralized synchronization (IBM's - nee Mercury Computer's - SANergy,? HP's - nee Transoft Networks' - <forget the name>, Adic's - nee L Mountaingate's - <another name I forget>, the new extensions to EMC's Celera5 server, Avid's Unity/Trilligent file server product).i  C The (new) Tru64 file system is a bit of a hybrid, since it combines C mount-point-style aggregation of single-node-served (fail-overable)sK filesystems with a distributed caching/locking mechanism.  And I don't knowiF what the Tricord Lunar Flare stuff looks like inside, but AFAIK it's a. storage-level rather than a file-level server.  L There are a whole raft of file systems under development on Linux.  The mainI one that supports shared access to storage devices is GFS, which has someuI underlying similarities to the VMS clustering approach but got off on thefL wrong foot by being based on device-level lock support (Seagate may have seeL n this as a potential market differentiator, but unfortunately it just isn'tD a good idea) and AFAIK has never really recovered (though it now hasL modularized its distributed lock management and provides an alternate flavorK that requires no special device firmware support).  Several other ambitious L Linux cluster file system efforts have started and then appeared to languishH over the past couple of years - at least a couple having gotten divertedH into more basic cluster infrastructure work (since a cluster file systemL requires things like heartbeat and membership facilities that are central to. other aspects of cluster functioning as well).  K So while all the technology necessary to build the kind of distributed file K system you describe certainly exists, AFAIK no one has put it together intoxL anything like the product you're interested in (though the Berkeley work may come fairly close).h   - bill   >u > thanks for the commentsn >a > cheers, Rich.y >e > --J > rich walker | technical person | Shadow Robot Company | rw@shadow.org.uk9 > front-of-tshirt space to let     251 Liverpool Road   | J >                                  London  N1 1LX       | +UK 20 7700 2487   ------------------------------  % Date: Thu, 05 Jul 2001 09:58:44 +0200c* From: Alexis Cousein <al@brussels.sgi.com>" Subject: Re: The Alpha/IA64 Hybrid- Message-ID: <3B441E34.60001@brussels.sgi.com>r   Bill Todd wrote:  N > I think IBM just released JFS in something that may no longer be a beta-test" > version, so that might qualify.      So would XFS (on Linux).     -- o? <these messages express my own views, not those of my employer> ) Alexis Cousein				Senior Systems Engineere. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  $ Date: Thu, 5 Jul 2001 04:05:50 -0400' From: "Bill Todd" <billtodd@foo.mv.com> " Subject: Re: The Alpha/IA64 Hybrid( Message-ID: <9i16tv$64p$1@pyrite.mv.net>  7 "Alexis Cousein" <al@brussels.sgi.com> wrote in message ' news:3B441E34.60001@brussels.sgi.com...g > Bill Todd wrote: >-F > > I think IBM just released JFS in something that may no longer be a	 beta-testi# > > version, so that might qualify.P >s >e > So would XFS (on Linux).  . Sorry - missed the release (May 1, I now see).   - bill   >s >t > --A > <these messages express my own views, not those of my employer>O( > Alexis Cousein Senior Systems Engineer/ > SGI Belgium and Luxemburg al@brussels.sgi.com  >r   ------------------------------  % Date: Thu, 05 Jul 2001 10:27:33 +0200P* From: Alexis Cousein <al@brussels.sgi.com>" Subject: Re: The Alpha/IA64 Hybrid/ Message-ID: <3B4424F5.8010502@brussels.sgi.com>e   Bill Todd wrote:   >>So would XFS (on Linux). >> > 0 > Sorry - missed the release (May 1, I now see). > 7 BTW, SGI and Suse have ported much of the IRIX FailSafe   2 functionality over to Linux (including some agents> for monitoring common services), and Professional Services hasD implemented failover clusters of Linux systems using it (IIRC, using? reiserfs before May, 1, or clusters that didn't need filesystem 
 failover).      ? <these messages express my own views, not those of my employer>t) Alexis Cousein				Senior Systems Engineer . SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  % Date: Thu, 05 Jul 2001 09:56:37 +0100 # From: Nick Hill <n.m.hill@rl.ac.uk>o" Subject: Re: The Alpha/IA64 Hybrid( Message-ID: <3B442BC5.189CEA20@rl.ac.uk>   Peter Mayne wrote:   > M > Last time I worked with Tru64 (V5.1 I think), the Cluster File System (CFS)pM > worked by having one of the nodes in the cluster serve the underlying AdvFSeL > file system to the other nodes over the cluster memory channel. Therefore,N > only that node could directly access the underlying file system, and it onlyI > looked like the other nodes had direct access, with CFS server failoveroM > happening as necessary. This is somewhat different to VMS, where nodes in anD > cluster can access the file system concurrently and independently.  H Indeed, and this can be a performance problem. We have seen instances onH our cluster where some I/O bottlenecks are apparent when the I/O is to aF file system served from another node which do not appear if the I/O is to local devices.s  G Having also managed VMS clusters with disks on shared busses where if a4@ host can see the disk it can access the file system this seems a0 drawback of Trucluster compared to VMS clusters.  C In the defence of Trucluster I would quickly add that Trucluster ismD getting there as more functionality is rolled out. While it would beG great for Trucluster to have the same functionality that has been builtoF up over the years in VMS clusters on day one this is probably a little? optimistic. I have also been informed by a Tru64 engineer that hF multi-node concurrent/independent access to file systems if the deviceE is visible to a node is on the list for development in Trucluster. Atn< that point file systems will only be served over the clusterH interconnect if a host cannot access the device directly. No time scales given. w   -- v	 Nick Hilln   Scientific Computing Services- Rutherford Appleton Labs UK   ------------------------------   Date: 5 Jul 2001 07:05:16 -0500e9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)i" Subject: Re: The Alpha/IA64 Hybrid3 Message-ID: <fMXgTmML6PIw@eisner.encompasserve.org>e  N In article <3B442BC5.189CEA20@rl.ac.uk>, Nick Hill <n.m.hill@rl.ac.uk> writes:  E > In the defence of Trucluster I would quickly add that Trucluster isgF > getting there as more functionality is rolled out. While it would beI > great for Trucluster to have the same functionality that has been built H > up over the years in VMS clusters on day one this is probably a littleA > optimistic. I have also been informed by a Tru64 engineer that eH > multi-node concurrent/independent access to file systems if the deviceG > is visible to a node is on the list for development in Trucluster. At > > that point file systems will only be served over the clusterJ > interconnect if a host cannot access the device directly. No time scales	 > given. n  G As I read that description, however, it is not a feature that was builtaE up over the years on VMS but was there with the launch of clusters atwE VMS V4.0.  (Nobody in their right mind counts the hack in VMS V3.7 as  really being clustering.)a   ------------------------------  * Date: Thu, 5 Jul 2001 11:24:01 +0000 (UTC)' From: david20@alpha2.mdx.ac.uk (D.Webb)s" Subject: Re: The Alpha/IA64 Hybrid+ Message-ID: <9i1ioh$4t8$1@aquila.mdx.ac.uk>t  R In article <9i0k2s$i8u$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: >a; >"Jack Patteeuw" <jjpatteeuw@peoplepc.com> wrote in messageo' >news:3B43BBB2.27ABEBAF@peoplepc.com...- >- >....- >-H >For most of the last decade processor cycles and memory have been cheapL >enough to avoid the necessity for a great many of the options that made RMSJ >so complex to approach at the FAB/RAB/NAM/XAB level:  it could be so muchK >simpler now.  There aren't too many people any more interested in making anJ >career out of understanding the intricacies of some vendor's file system,G >and it would be nice to be able to offer the rest of the world a thirdeI >option to either using Oracle (and the human DB administrator that comes < >along with such use) or kludging up something on their own. >H >- billi >o  M Most of the high level languages have support for ISAM files built into them.rK It is only when using C (C++ ?) that you are forced into using FAB/RAB etc.e  E I don't really see that even at the FAB/RAB etc level RMS is any moretC complex than say writing X-windows programs or any number of other d: applications where you need to call specialised functions.  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Thu, 05 Jul 2001 07:53:18 -0400 - From: Jack Patteeuw <jjpatteeuw@peoplepc.com>." Subject: Re: The Alpha/IA64 Hybrid, Message-ID: <3B44552E.55938055@peoplepc.com>   Rich Walker wrote:  H > Missed that. Thanks. So, if "fileserver down for a while" is very bad,H > then we need a filesystem that is always consistent, so we can replaceC > the fileserver. Or, we need a filesystem that can be generated by B > multiple fileservers concurrently, which is the interesting one.    M The "original" VMScluster (with star couplers and HSC50's, anybody need some h6 spare HSC50's) could do what you described on day 1 !!  
 Jack Patteeuw    ------------------------------  % Date: Thu, 05 Jul 2001 08:09:28 -0400n- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>a" Subject: Re: The Alpha/IA64 Hybrid, Message-ID: <3B4458F8.73F31823@peoplepc.com>   Bill Todd wrote: > 2 > "Jack Patteeuw" <jjpatteeuw@peoplepc.com> wrote  > ...o > M > > I can not imagine why any owner of a "group" of NFS mounted systems wouldaM > > want to allow **SILENT** multiple write accesses to the same file !!!  ItIL > > sends shudders down my spine knowing that what "Joe" just wrote, "Suzie"O > > can overwrite in a blink, and with out file version numbering, there is no D4 > >way that the original data can be save/recovered. > J > I must be missing something here:  VMS certainly allows concurrent write+ > (and over-write) access to files as well.n  L Not **SILENTLY** !!  Yes, multiple writers are allowed, but the **DEFAULT** / file access allows only one reader or writer !!  .o .W .eK > Versioning only comes into play when an application deliberately creates  F > a new version of a file and then (typically, as with an editor)  ...  G Yep, a "stupid user trick" that happens to too many MS users who get on63 big "system" where there are more than one user !!!a    
 Jack Patteeuwa   ------------------------------  $ Date: Thu, 5 Jul 2001 09:10:00 -0400' From: "Bill Todd" <billtodd@foo.mv.com> " Subject: Re: The Alpha/IA64 Hybrid( Message-ID: <9i1oo8$t52$1@pyrite.mv.net>  4 "D.Webb" <david20@alpha2.mdx.ac.uk> wrote in message% news:9i1ioh$4t8$1@aquila.mdx.ac.uk...j   ...:  I > Most of the high level languages have support for ISAM files built intok them.@H > It is only when using C (C++ ?) that you are forced into using FAB/RAB etc.   Unfortunately,  E 1.  While the languages help make doing simple operations simple, RMS'L Indexed Files have a fair amount of inherent complexity (not all of which isL necessary) that needs to be understood in order to do even simple operations *efficiently*.  J 2.  Most of the languages provide some means of getting at the less commonJ RMS options - via use of utilities if nothing else - which means that evenK though one may not need them for most of one's work, they're still there in I the documentation (and thus things you tend to need to read about just too know that you don't need them).s   >oG > I don't really see that even at the FAB/RAB etc level RMS is any moresD > complex than say writing X-windows programs or any number of other< > applications where you need to call specialised functions.  K Which is to say that RMS isn't any more complex than a lot of other complexrJ areas.  Most people prefer to avoid *unnecessary* complexity in their workJ even if they're capable of dealing with it where they must:  that's one ofC the attractions of Unix programing (as distinct from the ridiculous % interfaces to Unix utility programs).a   - bill   >e > David Webb > VMS and Unix team leader > CCSS > Middlesex University   ------------------------------  $ Date: Thu, 5 Jul 2001 09:17:05 -0400' From: "Bill Todd" <billtodd@foo.mv.com>a" Subject: Re: The Alpha/IA64 Hybrid' Message-ID: <9i1p5h$nj$1@pyrite.mv.net>7  K Late-night brain-fade:  Lunar Flare is a file-server, not a storage server,n product.   - bill  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message! news:9i11ku$mk$1@pyrite.mv.net...a   ...f   ------------------------------  * Date: Thu, 5 Jul 2001 15:50:08 +0000 (UTC)' From: david20@alpha2.mdx.ac.uk (D.Webb)c" Subject: Re: The Alpha/IA64 Hybrid+ Message-ID: <9i22bg$9ts$1@aquila.mdx.ac.uk>l  R In article <9i1oo8$t52$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: >k5 >"D.Webb" <david20@alpha2.mdx.ac.uk> wrote in messageo& >news:9i1ioh$4t8$1@aquila.mdx.ac.uk... >n >....r >nJ >> Most of the high level languages have support for ISAM files built into >them.I >> It is only when using C (C++ ?) that you are forced into using FAB/RABo >etc.s >n >Unfortunately,  >uF >1.  While the languages help make doing simple operations simple, RMSM >Indexed Files have a fair amount of inherent complexity (not all of which isoM >necessary) that needs to be understood in order to do even simple operationsa >*efficiently*.u >w  L I think the level of knowledge needed to do things fairly efficiently in RMSG is generally less than that required to do things fairly efficiently ino Databases such as Oracle.     K >2.  Most of the languages provide some means of getting at the less commonoK >RMS options - via use of utilities if nothing else - which means that evensL >though one may not need them for most of one's work, they're still there inJ >the documentation (and thus things you tend to need to read about just to  >know that you don't need them). >   N Generally I read about things when I need them. I am extremely happy when I do' need them to find them well documented.      >>H >> I don't really see that even at the FAB/RAB etc level RMS is any moreE >> complex than say writing X-windows programs or any number of otheri= >> applications where you need to call specialised functions.l >aL >Which is to say that RMS isn't any more complex than a lot of other complexK >areas.  Most people prefer to avoid *unnecessary* complexity in their workBK >even if they're capable of dealing with it where they must:  that's one ofoD >the attractions of Unix programing (as distinct from the ridiculous& >interfaces to Unix utility programs). >b  N No. Most things in computing are complex. However complexity is hidden by the M use of different levels of abstraction. For some things in RMS (like in othernK areas of computing) you will need to delve into lower more complex layers -sN most of the time you can just use the simpler higher level interfaces provided& by most of the higher level languages.  
 David Webb VMS and Unix team leader CCSS Middlesex University   >- billt >u >>
 >> David Webby >> VMS and Unix team leadern >> CCSSc >> Middlesex Universitya >n >e   ------------------------------  % Date: Thu, 05 Jul 2001 05:08:54 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> : Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B442E6A.AC9772F6@videotron.ca>   Christopher Smith wrote:N > Linux is clearly an inferior product in terms of design to VMS.  It makes noM > sense to me that one would migrate to something which is "worse" (to chooset# > a term) than what they have now. a  J The OS is useless to a company. It is something seen by low level techies." APPLICATIONS ARE WHAT ARE THE KEY.  K And if you can't get the apps you need on VMS but they exist on Linux, thenn, you move to Linux even if Linux is inferior.   ------------------------------  % Date: Thu, 05 Jul 2001 19:05:59 +0200o= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>s9 Subject: Re: VMS721_UPDATE V0300 ECO regresses DEC$BASRTL ) Message-ID: <3B449E77.3E9CD31D@gtech.com>s   John Santos wrote:A > It installs V01-021 (according to internal version identifier).eC > with a date of 29-Dec-1999, replacing V01-025, 11-Apr-2000, which / > I beleived was installed with DEC BASIC V1.4.e   Shame on VMS engineering !  " That is a classic "windows error".   Arne   ------------------------------  % Date: Thu, 05 Jul 2001 04:58:34 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca>oE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)i, Message-ID: <3B442BFF.4CDBD9EE@videotron.ca>   Paul Nankervis wrote:oE > However my current impression is that after one look in here no-onelB > will ever buy VMS again - despite it being an excellent product!  N When Compaq annouced it was buying Digital, there were great hopes that CompaqM which had succeeeded in marketing to the masses its 8086 boxes, would be ableoL to do its magic and fix what was wrong At Digital.  Within days appeared theK fuel-pump ads in magaznes with the word "VMS" (no "open") on the first fuel B pump. That showed great promise and hopes were raised even higher.  N However, that was short lived and VMS quickly went back to its silent self. AtF least Compaq had stopped the Digital practice of actively killing VMS.  M However, consider that Compaq had just announced a 20 year DII-COE commitmenttN for VMS. Consider that Compaq had made commitments to Alpha. Now Compaq breaksK the Alpha commitment. How much credibility is there for their commitment tom1 DII-COE ? How much credibility does Compaq have ?i  L It isn't just the dropping of Alpha and breaking commitments. But it is alsoN the apparent roadmap of Compaq giving away all of the intellectual property itI had inherited from Digital since it is of no use in its Microsoft centricn world. k  J I would find it very interesting to see how many customers with previouslyJ done NDAs got a very rude awakening 2 mondays ago when they found out thatL Compaq was going in a different direction than their NDAs stipulated. Or didK NDAs include information about the death of Alpha a long time before it was 
 made public ?   I The technical aspect of the port to IA64 isn't a big issue in my opinion.-L There is confidence that the VMS engineers will find a way to do it if givenN time and budgets. However, this port comes at a critical time where Compaq hadL once again raised hopes for VMS but now, the fear is that the resources willL be focused on doing the port instead of working on improving VMS's fortunes.H During the years that this port will take, VMS cannot really be marketed. because it will exist only on a dead platform.    & So, what are customers supposed to do:L -VMS will be going through a rough time because it isn't strong enough to go1 through this period of uncertainty and transitiont  J -Compaq is fully able to break previous commitments. What's to stop Compaq" from breaking its VMS commitment ?  M -Compaq seems to returning to a box maker shop with no intellectual property.gG As a result, one must wonder about the place of VMS in such a company. t  N This story is forcing customers to rething their involvment/investment in VMS.D Is VMS strong enough to widthstand this difficult and long period ofN transition to IA64 ? If not, then the lack of confidence in Compaq keeping itsH commitments means that VMS might be killed due to falling revenus or any( efforts to expand VMS will be curtailed.  I ISV's do not port to a platform with negative growth. And this transition ) period will probably put negative growth.   I Compaq chose the way the announcement was made and its timing. One has toiM assume that Compaq is run by very smart people and that they knew exactly howsK customers would react to the way it was announced and as a result, one must M assume that Compaq has already factored in any negative reaction by customerso to Compaq's killing of Alpha.P  N We stuck it out during the Digital years and we stuck iot out during the earlyI Compaq years because we knew that Compaq would take a while to digest theeN acquisition and decide what to do with the Digital products. But Compaq is nowH starting to give clearer signals on where it intends to go. If customersI interpret that direction as excluding a bright future for VMS, then it is M perfectly legitimate for customers to rethink their investment in VMS for theeK long term. You do not buy serious products unless you know that the companyrN considers it a long term core product that will survive internal staff musicalL chairs over the years.  Ask yourself this: would you trust compaq if it wereN to nominate some very pro wintel guy as the head of the committee that decides3 the future of former Digital products such as VMS ?e    L If the interpretation, by customers, of Compaq's directions is wrong then itC is Compaq's fault for not tending to the PR aspect in a better way.e   ------------------------------   Date: 5 Jul 2001 07:09:11 -0500l9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)sD Subject: Re: Wailing and moaning.... (was: Compilers go to Intel...)3 Message-ID: <SSrt0G4b9ARc@eisner.encompasserve.org>i  o In article <StR07.154305$%i7.102630651@news1.rdc1.sfba.home.com>, "Nikita V. Belenki" <public@kits.net> writes:aH > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message/ > news:3muriWXVncvJ@eisner.encompasserve.org...a > K >> > I can see where Intel would need the GEM backend, and the Q (and otherr > OSF >> > mfg's) would need specific frontends.  However, the question then	 > becomesuK >> > does Q pay Inhel royalties for the backend?  If so, does that kill anytH >> > ability to include the compilers in the free kits (hobbyist, etc.)?F >> Doesn't anybody _read_ what has been posted here?  Michael CapellasH >> is quoted as saying the transfer to Intel was _non_exclusive_rights_,/ >> meaning there can be no royalty requirement.e > N > No exclusive rights on code written by Intel? Is Compaq going to be a second > Microsoft?  I No exclusive rights on the intellectual property transferred from Compaq.   G As to code written by Intel, if it uses Compaq intellectual property itaD may be covered by the agreement in such a way as to avoid royalties.   ------------------------------   Date: 5 Jul 2001 08:34:22 -0700u( From: kparris@my-deja.com (Keith Parris), Subject: Re: What about performance issues??= Message-ID: <cb85fed2.0107050734.4eca2e2c@posting.google.com>r  W "Bill Todd" <billtodd@foo.mv.com> wrote in message news:<9ht7va$qi9$1@pyrite.mv.net>... 7 > "Keith Parris" <kparris@my-deja.com> wrote in messagee9 > news:cb85fed2.0107030817.7abe3d38@posting.google.com...iH > > And this level of I/O performance was being achieved with the older,F > > slower HSJ50 and CI hardware, not the hot new Fibre Channel stuff;H > > with no XFC; with plain old RMS indexed files, without using the newE > > Fast_IO interface that is significantly streamlined compared withe	 > > $QIO.T > K > But, I suspect, by taking advantage of mirrored, stable, controller-level L > write-back caching.  Suitable hardware can always make up for a great dealI > in the way of software inadequacy - but most of the discussion involved N > write performance on lesser hardware where enabling write-back caching wouldI > potentially compromise integrity.  (Yes, to some extent read-caching aslB > well, and XFS has helped in that area, but it did take a while.)  C HSJ50s don't have mirrored cache.  We covered for that by shadowinge> across different pairs of controllers, so that the one time weC actually did suffer an HSJ50 cache module failure, Volume ShadowingiF did its job, kicked out all the units on the failed controller, and we- continued to run on the other shadow members.2  F In my measurements, write-back cache didn't seem to make a significantC difference in performance on solid-state disk units.  Based on thatsF data, when we built our 2nd cluster, we disabled caching on SSD units,3 leaving all the cache space for the magnetic disks.h  # This workload had about 30% writes.p  F My point was that to make a blanket statement that I/O on VMS is slow,> inefficient, etc. based on anecdotal evidence (as has happenedC frequently in this ng recently) doesn't present a true and complete F picture.  If VMS I/O was really slow and inefficient, we wouldn't have= been able to drive the SSDs to the level of I/O rates we saw.o   Keitho   ------------------------------  % Date: Thu, 05 Jul 2001 14:32:50 -0000t- From: wspencer@ap.nospam.org (Warren Spencer)e. Subject: Re: Which group for VMS hardware ads?/ Message-ID: <tk8ukik7k3k297@news.supernews.com>r  , jon@eoin.demon.co.uk (Jon Laughton) wrote in& <9hdkio$pkt$2@INDY.eoin.demon.co.uk>:    >Hello,e >oE >I'm new here, and don't want to rock the boat, so I'd be grateful ifCH >anyone could tell me if there is a suitable/preferred group to post VMS >hardware for sale ads in. >m >Thanks in advance.t >u   Intel or Alpha based hardware?   ws   -- y   Warren Spencer Senior Software Engineer The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------   Date: 5 Jul 2001 04:32:55 -0700a  From: nclews@csc.com (Nic Clews)' Subject: Re: will the irony never cease = Message-ID: <a720d610.0107050332.21d3b705@posting.google.com>.  f mathog@seqaxp.bio.caltech.edu (David Mathog) wrote in message news:<9hlbbi$keb@gap.cco.caltech.edu>...L > Received an email yesterday from somebody in Compaq who must subscribe to 
 > this group:eM >    I will be out of the office from 2-JUL-2001 thru 8-JUL, returning 9-JUL,m8 >    due to the general COMPAQ-wide 4-JUL week shutdown. > J > At least there was an emergency contact number supplied below the boilerH > plate, so I guess they have a few people working this week.  Still, itN > seems like a good 7 days not to have to try to employ your service contract.  D I had to raise a call at 0700 hours Mountain Time on July 4th, and IF had a specialist on the problem in less than 30 minutes, and complete,0 correct problem diagnosis by 0745 Mountain Time.  E If you pay for the service, you still get it. Therefore I can't agreet with your cynisism David.   B (This is nothing unusual for the folks in Colorado, a finer set of@ professionals you could not wish to deal with, but we do have an* assigned team. All credit to Rick Abbott.)  ( Regards, Nic Clews CSC Computer Sciences nclews at csc dot como   ------------------------------  # Date: Thu, 05 Jul 2001 14:37:25 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>' Subject: Re: will the irony never ceasen< Message-ID: <FY_07.7336$tH1.2468262@typhoon.ne.mediaone.net>  - "Nic Clews" <nclews@csc.com> wrote in message 7 news:a720d610.0107050332.21d3b705@posting.google.com...9? > mathog@seqaxp.bio.caltech.edu (David Mathog) wrote in messageR( news:<9hlbbi$keb@gap.cco.caltech.edu>...J > > Received an email yesterday from somebody in Compaq who must subscribe to > > this group:$H > >    I will be out of the office from 2-JUL-2001 thru 8-JUL, returning 9-JUL,: > >    due to the general COMPAQ-wide 4-JUL week shutdown. > >+L > > At least there was an emergency contact number supplied below the boilerJ > > plate, so I guess they have a few people working this week.  Still, itF > > seems like a good 7 days not to have to try to employ your service	 contract.e > F > I had to raise a call at 0700 hours Mountain Time on July 4th, and IH > had a specialist on the problem in less than 30 minutes, and complete,2 > correct problem diagnosis by 0745 Mountain Time. >-  I A reseller friend of mine had a similar experience on the Fourth of July.tE The marketeers might be hibernating, but the services folks are stillnA manning the frontiers of availability and the bastions of uptime.    ------------------------------   Date: 5 Jul 2001 11:55:01 -0500r9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)m' Subject: Re: will the irony never ceasee3 Message-ID: <aRK7W1lfhp98@eisner.encompasserve.org>h  s In article <FY_07.7336$tH1.2468262@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes:y > / > "Nic Clews" <nclews@csc.com> wrote in messaget9 > news:a720d610.0107050332.21d3b705@posting.google.com...i@ >> mathog@seqaxp.bio.caltech.edu (David Mathog) wrote in message* > news:<9hlbbi$keb@gap.cco.caltech.edu>...K >> > Received an email yesterday from somebody in Compaq who must subscribe- > to >> > this group:I >> >    I will be out of the office from 2-JUL-2001 thru 8-JUL, returningc > 9-JUL,; >> >    due to the general COMPAQ-wide 4-JUL week shutdown.t >> >M >> > At least there was an emergency contact number supplied below the boilervK >> > plate, so I guess they have a few people working this week.  Still, iteG >> > seems like a good 7 days not to have to try to employ your service- > contract.  >>G >> I had to raise a call at 0700 hours Mountain Time on July 4th, and IcI >> had a specialist on the problem in less than 30 minutes, and complete,a3 >> correct problem diagnosis by 0745 Mountain Time.i >> > K > A reseller friend of mine had a similar experience on the Fourth of July.eG > The marketeers might be hibernating, but the services folks are stillMC > manning the frontiers of availability and the bastions of uptime.o  H For those outside the US, July 4 is a major national holiday in addition> to being in the middle of Compaq's company-wide vacation week.   ------------------------------   Date: 5 Jul 2001 09:21:52 -0500v- From: koehler@encompasserve.org (Bob Koehler) 2 Subject: Re: Writing to OPA0: from a device driver3 Message-ID: <ELRXNPvGNNjJ@eisner.encompasserve.org>l  z In article <s4I07.7053$Kf3.69664@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes: > P > What are the various methods used by VMS device drivers to write (for example,K > debugging text) to the system console and which method do people prefer ?v  F Generally they don't.  It's somewhat difficult in any device driver to8 write to any device other than the one being controlled.  @ I've got device drivers that use the OPCOM mailbox, they haven'tG successfully sent out a message in years.  I haven't bothered debugginga8 this because the messages they did send out are useless.  B Writing the the system error log works as documented, and is quiteB helpfull in deciphering device errors, sometimes due to the device5 getting into a state the driver writer didn't expect.t  F XDELTA is my primary debugging tool for drivers (mostly on VAXen), butC if you have two Alphas, I think there's a better debugger that runsc+ across the network from a host to a target.*  F You can also log traces of things in buffers you add to the UCB.  This1 is helpfull when you can't stop for a breakpoint.t  E It is possibly to construct an IRP and queue it to OPA0, but it's not  trivial.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationi= NASA GSFC Flight Software       | Federal Sector, Civil Group E                                 | please remove ".aspm" when replyingi   ------------------------------  # Date: Thu, 05 Jul 2001 14:19:11 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) 2 Subject: Re: Writing to OPA0: from a device driver0 Message-ID: <009FE8C4.65AA3B66@SendSpamHere.ORG>  c In article <ELRXNPvGNNjJ@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:0{ >In article <s4I07.7053$Kf3.69664@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:e >> -Q >> What are the various methods used by VMS device drivers to write (for example,yL >> debugging text) to the system console and which method do people prefer ? >oG >Generally they don't.  It's somewhat difficult in any device driver ton9 >write to any device other than the one being controlled.t > A >I've got device drivers that use the OPCOM mailbox, they haven't H >successfully sent out a message in years.  I haven't bothered debugging9 >this because the messages they did send out are useless.  >-C >Writing the the system error log works as documented, and is quite C >helpfull in deciphering device errors, sometimes due to the devicec6 >getting into a state the driver writer didn't expect. >gG >XDELTA is my primary debugging tool for drivers (mostly on VAXen), but D >if you have two Alphas, I think there's a better debugger that runs, >across the network from a host to a target. >cG >You can also log traces of things in buffers you add to the UCB.  Thisn2 >is helpfull when you can't stop for a breakpoint. > F >It is possibly to construct an IRP and queue it to OPA0, but it's not	 >trivial.F >zG >----------------------------------------------------------------------w@ >Bob Koehler                     | Computer Sciences Corporation> >NASA GSFC Flight Software       | Federal Sector, Civil GroupF >                                | please remove ".aspm" when replying    M I use IOC$BROADCAST and/or IOC$CONBRDCST extensively for outputting messages.gM You need to observe IPL requirements so you might not be able to invoke thesetL routinese everywhere you might wish.  In general, you can use these as you'd like at fork IPL.h  d --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMr            pJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  # Date: Thu, 05 Jul 2001 14:17:51 GMTe- From: goathunter@goatley.com (Hunter Goatley) 2 Subject: Re: Writing to OPA0: from a device driver1 Message-ID: <3b4473ce.176341756@news.process.com>s  L On 5 Jul 2001 09:21:52 -0500, koehler@encompasserve.org (Bob Koehler) wrote:  { >In article <s4I07.7053$Kf3.69664@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:l >> hQ >> What are the various methods used by VMS device drivers to write (for example,nL >> debugging text) to the system console and which method do people prefer ? > G >Generally they don't.  It's somewhat difficult in any device driver toy9 >write to any device other than the one being controlled.e >oA >I've got device drivers that use the OPCOM mailbox, they haven'tNH >successfully sent out a message in years.  I haven't bothered debugging9 >this because the messages they did send out are useless.  >eL If you want a real way to write to the actual console and not just to OPCOM,G there are (I think still undocumented) routines that will do just that.sI They can be called from device IPL and they write directly to the consoler device.e  G I wrote about this in the January 1995 issue of DIGITAL SYSTEMS JOURNAL E as part of my series (co-authored with Ed Heinrich) on writing kernelaF mode code.  In the assumption that others might find it useful, here's5 the section of the article discussing these routines.s  K (I also have some MACRO macros that make using these routines even simpler;tH if you'd like to see those, drop me a line and I'll e-mail them to you.)  O ===============================================================================b$ 1.4  Writing Messages to the Console  A Invoking XDELTA while debugging systems code works very well, butyE there are cases when it is not practical to use XDELTA. One such casenE is a device driver that interacts with an external peripheral device.eE If the device driver starts some operation on the peripheral and thenoD invokes XDELTA, the system will stop, but the peripheral may not. ByE the time the system is allowed to continue, the peripheral may or maytB not still be in the desired state, which can skew testing with theD peripheral. In cases like this, messages to the system error log mayD be useful, but they cannot be examined in "real-time"; the error log< buffers must be flushed to disk before they can be examined.  B A time-honored method of debugging is the writing of informationalF messages to a video or hardcopy terminal. Such messages could indicateF which subroutine is executing or the status of certain operations. ForE example, it is not uncommon when writing applications code to write a  routine like the following:w   --------------------      .      .   int do_the_work (int x)    {  int i;t  &      printf("Inside do_the_work()\n");      for (i = 0; i < x; i++)         printf("%d\n", i);  '      printf("Leaving do_the_work()\n");         return 1;   }  --------------------  ? When the program calling this routine is run, the informational < messages "Inside do_the_work()"  and "Leaving do_the_work()"@ will be written to the current output device. This can speed theA debugging process---if the second message is never printed, there = must be a problem inside the loop that keeps it from exiting..  F Obviously, any method that uses RMS to do the output is of limited-use? in privileged code, since a kernel-mode routine cannot call the E executive-mode RMS services. $QIO system service calls would work fortD process-context code that is not executing at elevated IPL. But whatB about real systems code, that may not have any process context andF executes at elevated IPL? These code threads can write output directlyA to the system console using some little-known executive routines.i   1.4.1  The Console I/O Routinesg  F OpenVMS module [SYS]CONSOLIO.LIS contains I/O routines for the consoleF terminal.  On a VAX, the routines all expect the address of a terminal> device's CSR (Control Status Register) to be passed in generalB register R11. If R11 has the value 0, the system console device is@ used by calling CPU-specific routines named beginning with CON$.  E Under OpenVMS AXP, the CSR address is ignored by the EXE$ console I/OeC routines. The system console device is used for all I/O operations.dB Also, the OpenVMS AXP source module [OPDRIVER] contains the source- code for OPDRIVER, the console device driver.e  < The characters are written and read from the physical deviceB registers, bypassing the normal device drivers for the device. TheE console I/O routines should be called from device IPL or higher, withrF any spinlock held. This makes them ideal for use in device drivers andD other elevated-IPL code. The routines will work for non-elevated IPLE as long as the system console is not being used for other purposes ati
 that time.  @ Table 1-2 describes the EXE$ routines for writing to the consoleE terminal. However, before the routines can be called, interrupts must-D be disabled on the console and then re-enabled. This is accomplished> by calling two CON$ routines: CON$SAVE_CTY to save the currentB settings, and CON$RESTORE_CTY to restore the saved settings. These> routines are defined in OPDRIVER (found in [SYSLOA] in the VAXC listings and [OPDRIVER] in the AXP listings). CON$SAVE_ CTY returnseD the current console state in R0 and R1; CON$RESTORE_ CTY expects the( console state to be passed in R0 and R1.  B Table_1-2:__EXE$_Console_I/O_Routines_____________________________  B Routine_______________Description_________________________________  F EXE$OUTBYTE           Convert and output hex byte (value passed in R1)J EXE$OUTHEX            Convert and output hex longword (value passed in R1), EXE$OUTBLANK          Output blank character? EXE$OUTCHAR           Output character (character passed in R0)a; EXE$OUTCRLF           Output carriage return/line feed pair B EXE$OUTCSTRING        Output counted string (address passed in R1)< EXE$OUTZSTRING        Output zero terminated string (addressB ______________________passed_in_R1)_______________________________  E Example 1-5 shows a VAX MACRO-32 module that defines two subroutines,dF PUT_CONSOLE_ASCIC and PUT_CONSOLE_HEX. These routines save the current@ console state, perform the specified output with some additionalE linefeeds and carriage returns, then restore the saved console state.k@ The following fragment shows how these routines would be called:   --------------------2   MSG:    .ASCIC  /This is a test console message/           .m           .g;           MOVAQ   MSG,R0     ; Get address of ASCIC message.C           JSB     PUT_CONSOLE_ASCIC       ; Write it to the consolec           .n           . @           MOVL    #^XDEAD00ED,R0          ; Move the value to R0C           JSB     PUT_CONSOLE_HEX         ; Write it to the consoleh           .            .f --------------------  % Example 1-5:  PUT_CONSOLE SubroutinesqE _____________________________________________________________________r  7         .TITLE  PUT_CONSOLE - Write messages to console          .IDENT  /01-000/ ;+ ;  ;  File:        PUT_CONSOLE.MARo ;  ;  Author:      Hunter Goatley ;-! ;  Date:        November 10, 19922 ;  ;  Description:e ;rB ;       The module contains two routines for performing device I/OE ;       to the system console: PUT_CONSOLE_ASCIC and PUT_CONSOLE_HEX.o ;d ;  Modified by:a ;tA ;       01-000          Hunter Goatley          10-NOV-1992 13:09o ;  Genesis.r ;a ;-         .DSABL  GLOBAL  ;         .EXTRN  CON$RESTORE_CTY    ;* Restore console state 8         .EXTRN  CON$SAVE_CTY       ;* Save console state7         .EXTRN  EXE$OUTCHAR        ;* Print a characters4         .EXTRN  EXE$OUTCRLF        ;* Print <CR><LF>8         .EXTRN  EXE$OUTCSTRING     ;* Print ASCIC string7         .EXTRN  EXE$OUTHEX         ;* Dump a HEX string    ;+ ; G ;  PUT_CONSOLE_ASCIC    Expects ASCIC address in R0, preserves all regs  ;e ;- PUT_CONSOLE_ASCIC::u@         PUSHR   #^M<R0,R1,R2,R3,R4,R11>         ; Save registersE         CLRL    R11                             ; Show I/O to consoleDH         PUSHL   R0                              ; Save address of stringD         JSB     G^CON$SAVE_CTY                  ; Save console state?         MOVQ    R0,                             ; Save the data-C         MOVL    #10,                            ; Move a <LF> to R0d?         JSB     G^EXE$OUTCHAR                   ; Send the <LF>tK         POPL    R1                              ; Restore address of stringp>         JSB     G^EXE$OUTCSTRING                ; Write it outC         MOVL    #13,                            ; Move a <CR> to R0c?         JSB     G^EXE$OUTCHAR                   ; Send the <CR>iL         MOVQ    R3,                             ; Restore console state dataG         JSB     G^CON$RESTORE_CTY               ; Restore console state @         POPR    #^M<R0,R1,R2,R3,R4,R11>         ; Save registersB         RSB                                     ; Return to caller ;+ ; K ;  PUT_CONSOLE_HEX      Expects hex value address in R0, preserves all regs  ;R ;- PUT_CONSOLE_HEX::,@         PUSHR   #^M<R0,R1,R2,R3,R4,R11>         ; Save registersE         CLRL    R11                             ; Show I/O to console H         PUSHL   R0                              ; Save address of stringD         JSB     G^CON$SAVE_CTY                  ; Save console state?         MOVQ    R0,R3                           ; Save the data2H         JSB     G^EXE$OUTCRLF                   ; Follow with a <CR><LF>C         MOVL    #10,R0                          ; Move a <LF> to R0l?         JSB     G^EXE$OUTCHAR                   ; Send the <LF>mC         POPL    R1                              ; Restore hex value >         JSB     G^EXE$OUTHEX                    ; Write it outC         MOVL    #13,R0                          ; Move a <CR> to R0a?         JSB     G^EXE$OUTCHAR                   ; Send the <CR>rL         MOVQ    R3,R0                           ; Restore console state dataG         JSB     G^CON$RESTORE_CTY               ; Restore console stateo@         POPR    #^M<R0,R1,R2,R3,R4,R11>         ; Save registersB         RSB                                     ; Return to caller  	      .ENDd  E _____________________________________________________________________e  ' 1.4.2  Using the $SNDOPR System Servicen  @ Non-privileged code can send messages to the operator console byC calling the $SNDOPR system service to queue a message to OPCOM, the E operations communication manager. Messages received by OPCOM are sent A to appropriate operator terminals, including the console, and are B recorded in the system operator log (OPERATOR.LOG in SYS$MANAGER).C Unfortunately, $SNDOPR cannot be called from kernel mode because it3E initially executes in executive mode. $SNDOPR uses the executive modeoD stack for temporary storage space for the message text, then changesB mode to kernel to actually write the message to the OPCOM mailbox,* whose address is stored in SYS$AR_ OPRMBX.  F The system routine EXE$SNDOPR actually writes the message to the OPCOMF mailbox by calling the system routine EXE$SNDMSG. This routine ensures@ that the memory holding the message text is faulted in and callsE EXE$WRTMAILBOX to write the message to the OPCOM mailbox. In order toCF ensure that all the necessary pages have been faulted into memory, the@ address of the message text is rounded down to the previous pageC boundary. If the message is small and near the top of the executivesC stack, this can cause an overrun into the kernel stack, which workstD because the routine is executing in kernel mode. If the message were? allowed to reside on the kernel stack, the rounding down of the0C address could result in the access of the page preceding the kerneliC stack, which is not a valid page. The system would then generate ane access violation exception.h  B Still, $SNDOPR can be useful in non-privileged portions of systemsF code as a means of notifying the system manager of a particular event.D Even at the driver-level, if a code thread needs to produce an alarm@ associated with a particular process, it may be able to queue an? executive-mode AST to that process (to be discussed in a future0C article); the executive-mode AST could then call the $SNDOPR systemi service.I =========================================================================g   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/m9 goathunter@goatley.com     http://www.goatley.com/hunter/h   ------------------------------   End of INFO-VAX 2001.370 ************************