1 INFO-VAX	Tue, 07 May 2002	Volume 2002 : Issue 252       Contents: Re: (remaining) GBLPAGFIL  Re: (remaining) GBLPAGFIL  Re: (remaining) GBLPAGFIL > Re: 1.1 mill new jobs in the IT industry in US next 12 months.5 Re: 3rd party support for Alpha hardware and software 3 A Bridge Too Far (was ... Itanium 3 will be Alpha!) " Alpha to ia64: where is the issue?3 An Invitation from CUO-EMEA President Terje Bruvoll 7 Re: An Invitation from CUO-EMEA President Terje Bruvoll 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix   Re: CSWS / CSWB / MX Speculation  Re: CSWS / CSWB / MX Speculation  Re: CSWS / CSWB / MX Speculation  Re: CSWS / CSWB / MX Speculation  Re: CSWS / CSWB / MX Speculation  Re: CSWS / CSWB / MX Speculation DCL Question Re: DCL Question Re: DCL Question  Re: DCPS Help Required..........' Re: ES-40 x Oracle RDB *** PROBLEMS ***   Re: Fix for EDT emulation in EVE  Re: Fix for EDT emulation in EVE Re: Gold key Re: Gold key HP is taking over really fast!" Re: HP is taking over really fast!" Re: HP is taking over really fast!" Re: HP is taking over really fast! HP Roadmap: OpenVMS, Tru64 safe # Re: HP Roadmap: OpenVMS, Tru64 safe / Re: Itanium 2 hits ... Itanium 3 will be Alpha! / Re: Itanium 2 hits ... Itanium 3 will be Alpha!  Just got this from BEA+ leading tabs (was: RE: Revisionist history) 8 RE: MacOS/X is the leading Unix (was "Itanium Troubles")8 Re: MacOS/X is the leading Unix (was "Itanium Troubles")8 RE: MacOS/X is the leading Unix (was "Itanium Troubles")# Memo:  Help restoring a system disk ; Old RAID 230 logical init very slow (63% done after 5 days) ? Re: Old RAID 230 logical init very slow (63% done after 5 days) ? Re: Old RAID 230 logical init very slow (63% done after 5 days) ? Re: Old RAID 230 logical init very slow (63% done after 5 days)  Re: OpenVMS Certification ( Re: Questions on the new structire at HP  Re: Removing AS1000A front panel Re: Revisionist history  RE: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  RE: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history % Re: Running CSWS 1.2 on Alpha VMS 7.2 ! Re: Sayonara DS10, new org charts ! Re: Sayonara DS10, new org charts  set info-vax nomail  simh VAX VMS users?  Re: simh VAX VMS users? ' Re: SKC Morphs Again... We're Now SKHPC ' Re: SKC Morphs Again... We're Now SKHPC ' Re: SKC Morphs Again... We're Now SKHPC ' Re: SKC Morphs Again... We're Now SKHPC ' Re: SKC Morphs Again... We're Now SKHPC ' Re: SKC Morphs Again... We're Now SKHPC ' Re: SKC Morphs Again... We're Now SKHPC 
 smtp.config ?  Re: smtp.config ?  RE: smtp.config ? " software to produce histograms (?)- SOT: Yo Andrew, you guys on a roll this week? * Re: UK/EU OpenVMS job market: non-existant Re: USB on OpenVMS Re: USB on OpenVMS Re: USB on OpenVMS Re: USB on OpenVMS@ Re: Using LD from OpenVMS 7.2-1 Installation CD, Can it be done? VAXELN Documentation( Re: VMS Bigots Unite To Form New Company( Re: VMS Bigots Unite To Form New Company( Re: VMS Bigots Unite To Form New Company( Re: VMS Bigots Unite To Form New Company( Re: VMS Bigots Unite To Form New Company6 Re: Why is security so important in a VMS environment?6 Re: Why is security so important in a VMS environment?6 Re: Why is security so important in a VMS environment?6 Re: Why is security so important in a VMS environment?6 Re: Why is security so important in a VMS environment?6 Re: Why is security so important in a VMS environment?  www.compaq.com is link to hp.com$ Re: www.compaq.com is link to hp.com$ Re: www.compaq.com is link to hp.com$ RE: www.compaq.com is link to hp.com$ Re: www.compaq.com is link to hp.com$ RE: www.compaq.com is link to hp.com Re: X-Win32  RE: X-Win32 / RE: ZIPped .PCSI container arrives OK on VMS??? / RE: ZIPped .PCSI container arrives OK on VMS??? & [Q]Terminators in Terminal Driver QIOW  F ----------------------------------------------------------------------  # Date: Tue, 07 May 2002 11:40:00 GMT 1 From: CSABA  HARANGOZO   <csabah@zipworld.com.au> " Subject: Re: (remaining) GBLPAGFIL7 Message-ID: <k2PB8.1379$06.190592@nasal.pacific.net.au>   0 Mark D. Jilson <jilly@clarityconnect.com> wrote: > Joe,P >        GBLPAGFILE is the quota that says how many GBLPAGES can have the systemB > paging files as their backing store.  GBLPAGFIL does NOT reserveJ > anything in the page files.  It is only a gate at the time that a global > page gets created.  B > Yes MMG$GL_GBLPAGFIL is still the cell that contains how much isI > available and from DCL the only way to access it is to parse SDA output F > or to 'know' what the SVA is of the data cell and to use the EXAMINE
 > command.  - 	One could have a peek into this file maybe :  	SYS$SYSTEM:SYS$BASE_IMAGE.MAP 						Cheers,   Csaba      > SDA> EVAL MMG$GL_GBLPAGFILJ > Hex = FFFFFFFF.83806328   Decimal = -2088738008         MMG$GL_GBLPAGFIL > SDA> EXAM MMG$GL_GBLPAGFIL3 > MMG$GL_GBLPAGFIL:  00000000.002DC467   "g?-....."  > $ GBLPAGCNT = %x83806328 > $ EXAM/LONG GBLPAGCNT  > 83806328:  002DC467   H > Enhancement requests have been logged to allow F$GETSYI to return thisH > item thus it may show up in some future version.  If you would like toC > add your request to the pile then call your local CSC and log it.     I    ---------------------------------------------------------------------- E    * Csaba I. Harangozo     |    'To err is human', said the hedgehog E    * csabah@zipworld.com.au |           as he dismounted a wirebrush. I    ---------------------------------------------------------------------- ;    EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:    ------------------------------  % Date: Tue, 07 May 2002 10:08:27 -0400 1 From: "Mark D. Jilson" <jilly@clarityconnect.com> " Subject: Re: (remaining) GBLPAGFIL2 Message-ID: <3CD7DFDB.F81FC6B0@clarityconnect.com>  H Why don't you use your own backing store file and not worry at all about GBLPAGFIL ??  
 Joe wrote: > m > "Mark D. Jilson" <jilly@clarityconnect.com> wrote in message news:<3CD6A69D.7BFB274D@clarityconnect.com>...  > E > Well to uh, make a long story short, I'm setting up a collection of E > processes that will share information via a global section(s). When F > (if) the process that creates and writes data (to be processed) intoE > the section(s) can't create a section I would like to write as much F > (current) "state" information as possible concerning what went wrong8 > for as many senarios as possible into the process log. > H > As far as I'm concerned; when it comes down to it, jumping into kernelF > mode (not necessary in this case) to retreive the contents of a cellF > is no biggie(we're not say - attempting a device driver as it were).B > For the rest of the staff who are somewhere between "deer in theF > headlights", "what's a global section", wouldn't know to go into SDAF > and examine MMG$GL_GBLPAGFIL, get a final exit code using ACCOUNTING> > (among other things) in order to diagnose what went wrong...G > ...introducing inner access mode code is something best avoided if at  > all possible.  >  > Thanks > Joe  >  > > Joe,Q > >       GBLPAGFILE is the quota that says how many GBLPAGES can have the system D > > paging files as their backing store.  GBLPAGFIL does NOT reserveL > > anything in the page files.  It is only a gate at the time that a global > > page gets created. > > D > > Yes MMG$GL_GBLPAGFIL is still the cell that contains how much isK > > available and from DCL the only way to access it is to parse SDA output H > > or to 'know' what the SVA is of the data cell and to use the EXAMINE > > command. > >  > > SDA> EVAL MMG$GL_GBLPAGFILL > > Hex = FFFFFFFF.83806328   Decimal = -2088738008         MMG$GL_GBLPAGFIL > > SDA> EXAM MMG$GL_GBLPAGFIL5 > > MMG$GL_GBLPAGFIL:  00000000.002DC467   "g-....."  > > $ GBLPAGCNT = %x83806328 > > $ EXAM/LONG GBLPAGCNT  > > 83806328:  002DC467  > > J > > Enhancement requests have been logged to allow F$GETSYI to return thisJ > > item thus it may show up in some future version.  If you would like toE > > add your request to the pile then call your local CSC and log it.  > >  > > Joe wrote: > > >  > > > OpenVMS 7.1-1H2  > > > K > > > If I'm not mistaken GBLPAGFIL is the SYSGEN parameter determining how E > > > much of the pagefile is ultimately available for use in section ( > > > backing - ie $CRMPSC/SEC$M_PAGFIL. > > > L > > > Is MMG$GL_GBLPAGFIL the correct place to look to determine how much ofH > > > this is currently available? If so - is there a "supported" way to0 > > > collect this bit of information other than > > >  > > > $ analyze/system > > > SDA> read/exec > > > .  > > > .  > > > . # > > > SDA> examine mmg$gl_gblpagfil  > > > 	 > > > TIA 	 > > > joe    --  C Jilly	- Working from Home in the Chemung River Valley - Waverly, NY 0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------  # Date: Tue, 07 May 2002 16:37:10 GMT 0 From: Jeffrey Chimene <jeff.nospam@systasis.net>" Subject: Re: (remaining) GBLPAGFIL, Message-ID: <3CD80671.78826CF5@systasis.net>  & Not to engender a design review - but:D     Did you investigate mailboxes? You brief description sounds like& that *might* be a more efficient tool.D Also, I recall using map to section from VAX BASIC, and all that wasC required was to tell the compiler and linker to map a shared memory F area. I think most DEC-based FORTRAN data collection routines also didG the same thing. The only issue was to ensure that a writer had excusive H access to the area; which access was coordinated using the Lock Manager.  C I acknowledge you may have already investigated and discarded these  solutions...  E > Well to uh, make a long story short, I'm setting up a collection of E > processes that will share information via a global section(s). When F > (if) the process that creates and writes data (to be processed) intoE > the section(s) can't create a section I would like to write as much F > (current) "state" information as possible concerning what went wrong8 > for as many senarios as possible into the process log. >  --  microsoft free by 2003   ------------------------------   Date: 7 May 2002 09:34:14 -0500 + From: young_r@encompasserve.org (Rob Young) G Subject: Re: 1.1 mill new jobs in the IT industry in US next 12 months. 3 Message-ID: <COfHtztELyIG@eisner.encompasserve.org>   o In article <fDHB8.55590$Q42.3075148@typhoon.austin.rr.com>, LESLIE@JRLVAX.HOUSTON.RR.COM (Jerry Leslie) writes: < > Jan-Erik =?iso-8859-1?Q?S=F6derholm?= (aaa@aaa.com) wrote:E > : From the "Information Technology Association of America (ITAA)" :  > : E > : http://www.itaa.org/news/pr/PressRelease.cfm?ReleaseID=1020695700  > : / > : Hm, how many of those will be VMS related ?  > :  > : Jan-Erik Sderholm.  > 1 >    http://www.newsbytes.com/news/02/175304.html > >    Defense Dept. Foreign Workers Policy Irks High-Tech GroupK >                                                                           G >    "America's defense readiness depends on having ready access to the H >    best available technology and technical skill sets," ITAA PresidentI >    Harris Miller wrote in a letter to Defense Department Undersecretary ? >    for Acquisition, Technology and Logistics Edward Aldridge.  >     J >    Foreign nationals have long been barred from working on classified ITD >    projects within the federal government. Yet, earlier this monthH >    Pentagon officials said they planned to extend that ban to projects0 >    considered "sensitive," but not classified. >     C >    "Precipitous action here could make it much more difficult and D >    expensive for the military services to acquire the requisite IT >    services," Miller said. >       ? 	I've read this and thought this to be a fascinating reason NOT F 	to bar workers from select fields.  Because it will drive costs up.  4 	That's pitiful.  Fascinating?  Make that very poor.  F 	I can understand the reasoning to err on the cautious side.  It would> 	be a very nasty thing to find out that someone in a sensitiveD 	position was passing information.  Just as likely to be an AmericanE 	citizen as a foreign national.  Of course if a foreign national, the B 	political implications (heads would roll) are much higher and youE 	can see how the Pentagon is almost forced in that direction (barring / 	foreign nationals from "sensitive" positions).   
 				   Rob 	    ------------------------------  % Date: Tue, 07 May 2002 10:50:16 +0100  From: Roy Omond <Roy@Omond.net> > Subject: Re: 3rd party support for Alpha hardware and software) Message-ID: <3CD7A358.8A8832F3@Omond.net>    "Randy B." wrote:   F > Does anyone know of 3rd party alternatives to Compaq for support for: > support of Alpha hardware (4100) and software (openVMS)?  0 You might like to state which country you're in.  - In the UK, for hardware there are (at least):    Maindec  Synstar  IBM  ICL (now Fujitsu)   ' For software there is (shameless plug):    Perseus   5 I do quite a bit of contract work for Perseus, so I'm  ever so slightly biased.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  " Date: Tue, 7 May 2002 16:46:23 GMT- From: Terry C Shannon <shannon@world.std.com> < Subject: A Bridge Too Far (was ... Itanium 3 will be Alpha!)C Message-ID: <Pine.SGI.4.30.0205071244590.5595-100000@world.std.com>   < On Tue, 7 May 2002, Andrew Harrison SUNUK Consultancy wrote:   >  >  > Terry C. Shannon wrote:  > > M > > I don't think so. IIRC the city fathers of Lake Havasu City, Arizona, USA O > > bought that bridge over 30 years ago. The "bridge over water that shouldn't K > > be there" was still standing when I flew over it a couple of weeks ago.  > >  > >  >  > ? > We have a new London Bridge built to replace the old one from > > now on called London Bridge 95. Now if we could interest Bob > in buying both.  > @ > Incedentally the story was that Lake Havasu City bought LondonC > Bridge thinking it was Tower Bridge (much more interesting bridge & > if you are into that sort of thing). >   J This would not surprise me a bit. And you are correct, the Tower Bridge is infinitely more interesting.   ------------------------------  % Date: Tue, 07 May 2002 19:20:59 +0200 - From: Didier Morandi <Didier.Morandi@Free.fr> + Subject: Alpha to ia64: where is the issue? ' Message-ID: <3CD80CFB.CE733B7E@Free.fr>   E What is to you the main problem(s) about the Alpha to ia64 migration?    D. --  2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  % Date: Tue, 07 May 2002 19:22:07 +0200 - From: Didier Morandi <Didier.Morandi@Free.fr> < Subject: An Invitation from CUO-EMEA President Terje Bruvoll' Message-ID: <3CD80D3F.807A2CC7@Free.fr>   = Subject:  An Invitation from CUO-EMEA President Terje Bruvoll # Date:     Tue, 07 May 2002 19:18:51 1 From:     "ITUG/DECUS" <mailer@associationhq.com>     
 Dear friends,   H If you want to know the truth about the future of OpenVMS, what will be K happening with Tru64 Unix, or what HP really intends to do about the Alpha  G Road Map, do not bother with local rumors and the opinions of industry  	 analysts.   J Where you need to be for Compaq, Digital and HP questions is in Lyon next G week. Hear from the people who REALLY know the inside track. Learn how   you can work with the new HP!   G I am looking forward to welcoming you at the ITUG/DECUS Joint European  " Conference from 13-15 May in Lyon.  
 Terje BruvollN President CUO-EMEA    L It's not too late to register for the ITUG/DECUS Joint European Conference. I For more information on the programme, including more than 125 technical eB sessions, more than 40 exhibitors, and numerous community-building opportunities, w   visit www.jointconference.org. n  J One-day conference registrations (includes all scheduled meals and social I functions, exhibition, and access to all technical sessions for your day nH of choice) are available for Monday, Tuesday, OR Wednesday for only 500 L Euro. Full pricing information is also available on the conference website:  www.jointconference.org.     (FYI)l   D. -- W2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  # Date: Tue, 07 May 2002 17:46:58 GMT * From: "Bill Todd" <billtodd@metrocast.net>@ Subject: Re: An Invitation from CUO-EMEA President Terje BruvollA Message-ID: <mqUB8.102096$v7.8411439@bin6.nnrp.aus1.giganews.com>k  : "Didier Morandi" <Didier.Morandi@Free.fr> wrote in message! news:3CD80D3F.807A2CC7@Free.fr...l? > Subject:  An Invitation from CUO-EMEA President Terje Bruvoll,% > Date:     Tue, 07 May 2002 19:18:51T3 > From:     "ITUG/DECUS" <mailer@associationhq.com>A >a >  > Dear friends,s >.I > If you want to know the truth about the future of OpenVMS, what will beRL > happening with Tru64 Unix, or what HP really intends to do about the AlphaH > Road Map, do not bother with local rumors and the opinions of industry > analysts.U > K > Where you need to be for Compaq, Digital and HP questions is in Lyon nextlH > week. Hear from the people who REALLY know the inside track. Learn how > you can work with the new HP!a  J Right.  Just as you could have found out 'the truth about the future' from$ such people in early June last year.   - bill   ------------------------------   Date: 7 May 2002 08:00:17 -0500c- From: koehler@encompasserve.org (Bob Koehler)e< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix3 Message-ID: <mG9Vjvksy6eO@eisner.encompasserve.org>s  V In article <ab6sbv$170@web.eng.baileynm.com>, peter@abbnm.com (Peter da Silva) writes:5 > In article <myakn8kA$vQW@eisner.encompasserve.org>, 0 > Bob Koehler <koehler@encompasserve.org> wrote:H >>    Since when?  I've never seen a UNIX that didn't have some vendor'sK >>    proprietary stamp on it, was limitted to thier hardware, and required * >>    the use of thier system admin tools. > L > I guess you've never seen Xenix, SCO UNIX, Solaris, ESIX, Unixware, or anyL > other commercial UNIX that runs on commodity PCs. Some of these are fairlyL > dependent on custom admin suites, yes, but most are quite happy to let youD > manage them with generic plain text file and common command lines.  F    No, I haven't.  I do know they exist, except that I thought Solaris4    only ran on some PCs, no generic commodity types.  A    But the discussion was on "proprietary".  If you're suggestingdA    Solaris isn't proprietary to Sun then you're lost in the hype.   A    Even my kid's Linux is available only from one vendor, runs onSC    only certain hardware, and can be managed only via that vendor'soD    choice of admin tools.  If he had to change to another Linux he'd0    have to learn his admin stuff all over again.   ------------------------------  % Date: Tue, 07 May 2002 14:51:00 +0100y/ From: Simon Waters <Simon@wretched.demon.co.uk>M< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix4 Message-ID: <3CD7DBC4.29D909B6@wretched.demon.co.uk>   Bob Koehler wrote: > C >    Even my kid's Linux is available only from one vendor, runs on  >    only certain hardware,   ? All operating systems run only on limited hardware, that is them? nature of things that control hardware. Linux runs on more than. most.c  . >    and can be managed only via that vendor'sF >    choice of admin tools.  If he had to change to another Linux he'd2 >    have to learn his admin stuff all over again.  ? Only if he choose to use non-free vendor supplied tools and notE= the many excellent free software based tools bundled, you canI> always choose to use proprietary software, but as an admin who= crosses Unix flavours it is more useful to learn more general-+ tools whether it be webmin, useradd, or vi.1  = Face it, HP's SAM was for a long time the only GUI based Unix @ admin tool worth using, (SMIT wasn't bad), but the other vendors@ bundled tools were pretty much useless. SAM's main advantage was> the extensive checks it would do before letting you reallocate9 disk space - saved my data from typos a couple of times -h= otherwise most admins just scripted the things they needed toh do.e  ? I think SuSE is the only major Linux vendor supplying extensiver> collections of non-free admin tools to the consumer market, so< within flavours of Linux you are unlikely to have to relearn> substantial amounts, just install your favourite tools and you	 are away.   = I find SuSE admin tools just get in the way so whilst it is a @ great Desktop OS, I won't be using it for server side stuff if I get to specify the flavour.$   ------------------------------   Date: 7 May 2002 14:10:58 GMT & From: peter@abbnm.com (Peter da Silva)< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix- Message-ID: <ab8n9i$hb7@web.eng.baileynm.com>B  N In article <ab704u$92n$2@aquila.mdx.ac.uk>,  <david20@alpha1.mdx.ac.uk> wrote:H > Are you sure I thought Redhat , Suse etc added their own installationsN > routines, public domain applications etc but I thought the Kernel was prettyO > strictly controlled. Linus doesn't want Linux to split into umpteem thousands-! > of incompatible Linux variants.g  L Linus controls the "standard" kernels pretty tightly, but I can't see how heK can prevent people from shipping modified kernels without keeping them from-G adding their own bugfixes. If he was doing that, then you'd see lots ofAL little "patchkit" fixes being distributed along, the way you did with 386BSD9 when Jolitz was in charge, or the way you get with qmail.l  I It can't be that Linus and his minions are so fast at integrating changes.H that nobody ever needs to do this. First, it would be insanely difficultH for them to integrate every possible kernel tweak that anyone might needJ into the kernel... second, the behaviour of Linux users when a new release$ is coming up suggests otherwise. :->   -- aO I've seen things you people can't imagine. Chimneysweeps on fire over the roofsrO of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All L these things will be lost in time, like chalk-paintings in the rain.   `-_-'K Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`c   ------------------------------  $ Date: Tue, 7 May 2002 16:03:22 +0200) From: Stefaan A Eeckels <hoendech@ecc.lu> < Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix5 Message-ID: <20020507160322.1bbf5726.hoendech@ecc.lu>s   On 7 May 2002 08:00:17 -0500. koehler@encompasserve.org (Bob Koehler) wrote:  C >    Even my kid's Linux is available only from one vendor, runs on"E >    only certain hardware, and can be managed only via that vendor'sMF >    choice of admin tools.  If he had to change to another Linux he'd2 >    have to learn his admin stuff all over again.  9 Nonsense. He could have chosen to ignore the custom tools : and edit the configuration files. That's exactly the point; with an open system like Unix: you can get it from a numberE; of vendors, and the core technology is the same. Hence, ther5 disappearance of a vendor (or his desire to bleed youe; financially) isn't an insurmountable problem. The fact thate2 there are minor differences is wholly irrelevant.    --   Stefaan  -- iJ Microsoft treats IT managers the way Proctor & Gamble treats nine-year-oldH prospective consumers: lots of noise, bright colors, and jumping around.= Other software vendors just wish they could be so successful.A. 				         -- Cameron Laird in comp.lang.tcl   ------------------------------   Date: 07 May 2002 15:30:36 GMT& From: Volker Birk <bumens@dingens.org>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix< Message-ID: <3cd7f31b$0$229$4d4ebb8e@businessnews.de.uu.net>  B In comp.sys.hp.hpux Bob Koehler <koehler@encompasserve.org> wrote:. >    But the discussion was on "proprietary".   F It is obvious in this discussion that people use different definitionsA of "proprietary". But I also think this discussion is irrelevant.   	 F'up set.    VB.n -- sC *** ebios Informationssysteme, Germany      ***  kangu:~ $ cd /pub/oG *** Gut-Betha-Platz 1, 88339 Bad Waldsee    ***  kangu:/pub $ more beer H *** Phone +49-7524-93421 Fax +49-7524-93423 ***  Aaahhhh! That was good!? *** mailto:vb@ebios.de                      ***  kangu:/pub $ _v   ------------------------------  # Date: Tue, 07 May 2002 16:54:11 GMT * From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix@ Message-ID: <TETB8.37835$M7.4677121@bin7.nnrp.aus1.giganews.com>  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:mG9Vjvksy6eO@eisner.encompasserve.org...oI > In article <ab6sbv$170@web.eng.baileynm.com>, peter@abbnm.com (Peter dah Silva) writes:7 > > In article <myakn8kA$vQW@eisner.encompasserve.org>,-2 > > Bob Koehler <koehler@encompasserve.org> wrote:J > >>    Since when?  I've never seen a UNIX that didn't have some vendor'sD > >>    proprietary stamp on it, was limitted to thier hardware, and required, > >>    the use of thier system admin tools. > >fJ > > I guess you've never seen Xenix, SCO UNIX, Solaris, ESIX, Unixware, or anyuG > > other commercial UNIX that runs on commodity PCs. Some of these arel fairlyJ > > dependent on custom admin suites, yes, but most are quite happy to let youtF > > manage them with generic plain text file and common command lines. >eH >    No, I haven't.  I do know they exist, except that I thought Solaris6 >    only ran on some PCs, no generic commodity types. >aC >    But the discussion was on "proprietary".  If you're suggestinghC >    Solaris isn't proprietary to Sun then you're lost in the hype.e  K If you look at what he chose to include from your own post, it's clear thatsK what he's suggesting is that your phrase 'was limitted [sic] to thier [sic]cG hardware' was in error, with a secondary comment on your 'system admin'm
 statement.   - bill   ------------------------------  % Date: Tue, 07 May 2002 09:39:32 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>-) Subject: Re: CSWS / CSWB / MX Speculation ) Message-ID: <3CD784B3.6AA08BD0@gtech.com>    "David J. Dachtera" wrote:F > I couldn't help wondering if CSWS + CSWB + MX + Multinet (or TCPwareJ > (Hi, Bob!)) + OpenVMS would do as a rather secure, very reliable, highly. > virus/worm resistant mail server platform...  6 At least the server would be very safe from infection.  & But I doubt it would be a big success:A   - email servers are usually standardized within an organizationpH     limiting the target market to either very VMS friendly organizations3     or small organization with just one mail server F   - lack of client compatibility. How many of the "big" mail protocols     does MX support:        - Exchanges        - Notes        - GroupWise
        - POP3         - IMAP4     ?    Arne   ------------------------------  % Date: Tue, 07 May 2002 09:48:36 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>c) Subject: Re: CSWS / CSWB / MX Speculation ) Message-ID: <3CD786D3.BD4FF47B@gtech.com>e   Tom Linden wrote: 9 > >From: David J. Dachtera [mailto:djesys.nospam@fsi.net]eG > >I couldn't help wondering if CSWS + CSWB + MX + Multinet (or TCPwarecK > >(Hi, Bob!)) + OpenVMS would do as a rather secure, very reliable, highlym/ > >virus/worm resistant mail server platform...o > # > Isn't kind of what MQSeries does?e   ????   No."  < MQ is a message queue middleware software. It has nothing to do with email messages.c  A Message queue middleware like IBM MQ Series, SonicMQ, DECmessageQu: etc. is used to communication between software components.   Arne   ------------------------------  % Date: Tue, 07 May 2002 09:51:45 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>a) Subject: Re: CSWS / CSWB / MX Speculationu) Message-ID: <3CD78791.E616934B@gtech.com>o   "Craig A. Berry" wrote:e; > In article <CIEJLCMNHNNDLLOOGNJIAEMEEOAA.tom@kednos.com>,t' >  "Tom Linden" <tom@kednos.com> wrote:e% > > Isn't kind of what MQSeries does?e > B > My understanding is that MQSeries is a general-purpose web-based > application server   No.m  . MQ Series is message queue middlware software.  ) The IBM application servers is WebSphere.r  F >                                                                    IF > hate to say it, but Microsoft Outlook Web Access is a very well done@ > implementation of a fully functional mail client done as a web > application.  ; There are a lot of web interface to email packages floatingB around.   " For VMS we could mention YAHMAIL !   Arne   ------------------------------  * Date: Tue, 7 May 2002 10:31:54 +0000 (UTC) From: david20@alpha1.mdx.ac.uk) Subject: Re: CSWS / CSWB / MX Speculationf+ Message-ID: <ab8aeq$lrh$1@aquila.mdx.ac.uk>   i In article <3CD784B3.6AA08BD0@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:b >"David J. Dachtera" wrote:uG >> I couldn't help wondering if CSWS + CSWB + MX + Multinet (or TCPware-K >> (Hi, Bob!)) + OpenVMS would do as a rather secure, very reliable, highlyr/ >> virus/worm resistant mail server platform...B >g7 >At least the server would be very safe from infection.  >n' >But I doubt it would be a big success:dB >  - email servers are usually standardized within an organizationI >    limiting the target market to either very VMS friendly organizationsI4 >    or small organization with just one mail server  J Usually not true. Most large organisations either for historic reasons or G due to recent aquisitions tend to have a standard + isolated pockets ofe' various other proprietary mail systems.   G >  - lack of client compatibility. How many of the "big" mail protocolsn >    does MX support:o >       - Exchange >       - Notes  >       - GroupWisee >       - POP3 >       - IMAP4b >    ? >n  K I don't know about MX but replace it with PMDF and you have support for alluN those plus many others. PMDF can either talk to Exchange, Notes and Groupwise M over it's standard SMTP channels (which can be setup with special options to -N correct standards problems in for instance Exchange). Or via special channels M such as the Lotus Notes or MHS channels if you don't want or can't set these g* systems to talk SMTP to the outside world.N PMDF is specifically designed to be a Mime based Mailhub capable of talking toN almost anything X400, PROFS, MHS, Message-Router etc It deals with content and4 character-set mappings, address format mappings etc     M PMDF also comes with POP3 and IMAP servers although MULTINET and TCPWARE alsoEO provide these. DEC TCPIP services currently provides just a POP3 server but the-. next version will have an inbuilt IMAP server.  0 PMDF also provides its own mail and list server.  I I'd also add in Sophos Vsweep to deal with Viruses and the public domain t1 YAHMAIL as a web interface to the VMS Mail store..  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Tue, 07 May 2002 13:46:39 +0200s= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> ) Subject: Re: CSWS / CSWB / MX Speculationl) Message-ID: <3CD7BE9F.553FF1BD@gtech.com>    david20@alpha1.mdx.ac.uk wrote:ak > In article <3CD784B3.6AA08BD0@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes: D > >  - email servers are usually standardized within an organizationK > >    limiting the target market to either very VMS friendly organizationst6 > >    or small organization with just one mail server > K > Usually not true. Most large organisations either for historic reasons orrI > due to recent aquisitions tend to have a standard + isolated pockets ofD) > various other proprietary mail systems.i  8 Those others tend to get shut down rather fast. At least that is my experience.  I > >  - lack of client compatibility. How many of the "big" mail protocolsw > >    does MX support:  > >       - Exchange > >       - Notesd > >       - GroupWisea > >       - POP3 > >       - IMAP4d > >    ? > >t > M > I don't know about MX but replace it with PMDF and you have support for allWO > those plus many others. PMDF can either talk to Exchange, Notes and Groupwiseo" > over it's standard SMTP channels   ????  < SMTP is a standard for sending email not for reading email !  D And "talk to other mail servers" and "act as server for clients" are two very different things.  C There are not that much value in an email server that just deliversn to other email servers.r  O > PMDF also comes with POP3 and IMAP servers although MULTINET and TCPWARE also-Q > provide these. DEC TCPIP services currently provides just a POP3 server but theb0 > next version will have an inbuilt IMAP server. > 2 > PMDF also provides its own mail and list server.  - I did use PMDF fo rmany years. Great product.k  > And if were in charge of all the MIS departments in the world,> then IMAP4 were declared the only allowed standard for reading email in the corporations.  = Then employees could choose the email clients they preferred./  
 But I am not.s  : MS, IBM and Novell has managed to sell their email clients# depending on proprietary protocols.    Arne   ------------------------------  * Date: Tue, 7 May 2002 13:00:49 +0000 (UTC) From: david20@alpha2.mdx.ac.uk) Subject: Re: CSWS / CSWB / MX Speculationo+ Message-ID: <ab8j61$olr$1@aquila.mdx.ac.uk>d  i In article <3CD7BE9F.553FF1BD@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:e  >david20@alpha1.mdx.ac.uk wrote:l >> In article <3CD784B3.6AA08BD0@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:E >> >  - email servers are usually standardized within an organization-L >> >    limiting the target market to either very VMS friendly organizations7 >> >    or small organization with just one mail servers >> eL >> Usually not true. Most large organisations either for historic reasons orJ >> due to recent aquisitions tend to have a standard + isolated pockets of* >> various other proprietary mail systems. >r9 >Those others tend to get shut down rather fast. At least  >that is my experience.  >n0 Very much depends on the organisations involved.    J >> >  - lack of client compatibility. How many of the "big" mail protocols >> >    does MX support: >> >       - Exchange' >> >       - Notes >> >       - GroupWise >> >       - POP3  >> >       - IMAP4	 >> >    ?n >> > >> iN >> I don't know about MX but replace it with PMDF and you have support for allP >> those plus many others. PMDF can either talk to Exchange, Notes and Groupwise# >> over it's standard SMTP channelst >I >????w >e= >SMTP is a standard for sending email not for reading email !, > E >And "talk to other mail servers" and "act as server for clients" are  >two very different things.l >s  L MX and PMDF are both mail servers not mail clients. Hence I assumed when youJ mentioned MX support for these protocols you were talking about the systemF being able to act as a central mail hub passing mail to these systems.N Note. The only "BIG" mail protocols I am aware of are SMTP, IMAP, POP and X400L - Exchange, Lotus Notes and Groupwise also have their own "LITTLE" internal  proprietary protocols.    M I assumed that the client compatibility was VMS support (either within MX ande, PMDF or elsewhere) for IMAP and POP servers.  P If you are talking about clients accessing mail stores on Lotus notes, Exchange,8 Groupwise then this depends how those systems are setup.N If they are setup so that you can access them via IMAP, POP or a web interfaceL then you do have clients on VMS eg PINE for POP and IMAP access, Mozilla for web access. M If you are talking about proprietary clients specific to Notes etc then thosetD don't exist on VMS (or as far as I am aware on most Unix platforms).O The Exchange servers, Lotus Notes servers etc can of course be setup to forwardeN all their mail to the PMDF based VMS system and the clients can then access it via IMAP, POP or web access.  N Basically I'm not sure what you really want. If it's Exchange, Lotus Notes andK groupwise running on VMS then sorry that isn't available and as far as I amy- ware it also isn't available on Unix systems. I (I will amend that slightly since I believe their are a couple of drop-in I replacements for Exchange which run on Unix systems. However I know of nooK plans to port them to VMS. It would have been nice if DEC had got a port ofeJ Exchange to VMS when they sacrificed their ALL-IN-ONE product for exchange$ but that is water under the bridge).    
 David Webb VMS and Unix team leader CCSS Middlesex University    D >There are not that much value in an email server that just delivers >to other email servers. >nP >> PMDF also comes with POP3 and IMAP servers although MULTINET and TCPWARE alsoR >> provide these. DEC TCPIP services currently provides just a POP3 server but the1 >> next version will have an inbuilt IMAP server.- >> -3 >> PMDF also provides its own mail and list server.  >m. >I did use PMDF fo rmany years. Great product. >p? >And if were in charge of all the MIS departments in the world,$? >then IMAP4 were declared the only allowed standard for reading. >email in the corporations.a >k> >Then employees could choose the email clients they preferred. >n >But I am not. >o; >MS, IBM and Novell has managed to sell their email clientse$ >depending on proprietary protocols. >s >Arnet   ------------------------------  % Date: Tue, 07 May 2002 09:41:33 -0700n  From: Jon <jsmyth69@hotmail.com> Subject: DCL Questiont8 Message-ID: <0f0gduo6l6n9e4863oojeq4bsn50oj94ju@4ax.com>  F Ok, I've got a DCL question that has stumped me for a while.  I've gotA a piece of code that is attempting to located certain data on theiA system (a code specific database) which could exist on any of thetE mounted volumes.  I need to track to size of the database.  We've gotnF a logical that points to the location of the database.  It's simple toD get that specific one, but there can be "extensions" to the database2 which would create other logicals.  As an example:   $ sho log database*e  . (LNM$PROCESS_TABLE)r    (LNM$JOB_80D13780)  r (LNM$GROUP_000001)  g (LNM$SYSTEM_TABLE)      "DATABASE" = "$1$DKA0:"p   "DATABASE_1" = "$1$DKA100:"e   "DATABASE_2" = "$1$DKA200:"L  o (LNM$SYSCLUSTER_TABLE)  s (DECW$LOGICAL_NAMES) $d  A The problem lies in that the primary logical is there (database),n? however, the extensions may or may not be there (depends on the|< structuring of the data).  I've done some code where I do a A "sho log database*/out=<Filename>" and attempted to parse out the D locations, but the quotes are causing me a problem.  Anyone have any9 suggestions as to the best way to get this info?  Thanks!e   ------------------------------  * Date: Tue, 7 May 2002 17:35:04 +0000 (UTC), From: lewis@PROBE.mitre.org (Keith A. Lewis) Subject: Re: DCL Questiond. Message-ID: <ab9387$b1l$1@newslocal.mitre.org>   Jon <jsmyth69@hotmail.com> writes in article <0f0gduo6l6n9e4863oojeq4bsn50oj94ju@4ax.com> dated Tue, 07 May 2002 09:41:33 -0700: >(LNM$SYSTEM_TABLE)  >  >  "DATABASE" = "$1$DKA0:" >  "DATABASE_1" = "$1$DKA100:" >  "DATABASE_2" = "$1$DKA200:"  L You should be using f$trnlnm() in your DCL code.  It would be fairly easy toK write a loop that would check DATABASE_1..DATABASE_n, but I would recommend  a different approach.o  J $ DEFINE/SYSTEM DATABASE $1$DKA0:,$1$DKA100:,$1$DKA200: /trans=(conc,term)  B Then you don't have to parse them at all, as long as the directoryM structures are parallel, a file search will find it on any of the 3 volumes. aE But you can parse using f$trnlnm() if you want, changing the value ofa& "index" on each pass through the loop.  K I would also recommend a couple of extra layers of logical names -- you getmF a DISK$volname logical for free from the MOUNT command, and you shouldI create a top-level directory in case you want to combine volumes someday.x   Here's something from my setup:e  ? $ def/sys/nolog/exec/tran=conc data1          disk$data:[data.]mA $ def/sys/nolog/exec/tran=conc data3          disk$data3:[data3.]BA $ def/sys/nolog/exec/tran=conc data4          disk$data4:[data4.]iA $ def/sys/nolog/exec/tran=conc cdata          disk$data4:[cdata.]uB $ def/sys/nolog/exec/tran=conc data6          disk$data6a:[data6.]K $ def/sys/nolog/exec           data           cdata,data1,data3,data4,data6   J CDATA: and DATA4: are now on the same volume, and the users didn't have toK change a single app.  All I had to change was SYLOGICALS.COM and delete thel other MOUNT command.  + --Keith Lewis              klewis$mitre.org-> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Tue, 07 May 2002 19:57:44 +0200d) From: Bart Zorn <B.Zorn@xs4all.nospam.nl>T Subject: Re: DCL Questionr/ Message-ID: <3CD81598.5040409@xs4all.nospam.nl>c   Keith A. Lewis wrote:m > Jon <jsmyth69@hotmail.com> writes in article <0f0gduo6l6n9e4863oojeq4bsn50oj94ju@4ax.com> dated Tue, 07 May 2002 09:41:33 -0700: >  >>(LNM$SYSTEM_TABLE) >> >> "DATABASE" = "$1$DKA0:" >> "DATABASE_1" = "$1$DKA100:" >> "DATABASE_2" = "$1$DKA200:" >  > N > You should be using f$trnlnm() in your DCL code.  It would be fairly easy toM > write a loop that would check DATABASE_1..DATABASE_n, but I would recommend  > a different approach.d > L > $ DEFINE/SYSTEM DATABASE $1$DKA0:,$1$DKA100:,$1$DKA200: /trans=(conc,term)  H I agree, but the /trans=(conc,term) is not required here. Note that the 0 /tran=conc *are* required in the examples below.   > D > Then you don't have to parse them at all, as long as the directoryO > structures are parallel, a file search will find it on any of the 3 volumes.  G > But you can parse using f$trnlnm() if you want, changing the value of,( > "index" on each pass through the loop. > M > I would also recommend a couple of extra layers of logical names -- you getoH > a DISK$volname logical for free from the MOUNT command, and you shouldK > create a top-level directory in case you want to combine volumes someday.  > ! > Here's something from my setup:  > A > $ def/sys/nolog/exec/tran=conc data1          disk$data:[data.]'C > $ def/sys/nolog/exec/tran=conc data3          disk$data3:[data3.]-C > $ def/sys/nolog/exec/tran=conc data4          disk$data4:[data4.]?C > $ def/sys/nolog/exec/tran=conc cdata          disk$data4:[cdata.]pD > $ def/sys/nolog/exec/tran=conc data6          disk$data6a:[data6.]M > $ def/sys/nolog/exec           data           cdata,data1,data3,data4,data6T > L > CDATA: and DATA4: are now on the same volume, and the users didn't have toM > change a single app.  All I had to change was SYLOGICALS.COM and delete thee > other MOUNT command. > - > --Keith Lewis              klewis$mitre.orgm@ > The above may not (yet) represent the opinions of my employer.  	 Bart Zornt   ------------------------------   Date: 7 May 2002 03:15 CDT' From: carl@gerg.tamu.edu (Carl Perkins)e) Subject: Re: DCPS Help Required..........a, Message-ID: <7MAY200203150992@gerg.tamu.edu>  : mgattaura@collins-stewart.com (Mandeep Gattaura) writes... }32 dict dup begin }/BBox [0 0 595 842] def }/FormType 1 def }/Matrix [1 0 0 1 0 0] def% }%%BeginResource: procset xpdf 1.00 0  }/xpdf 75 dict def xpdf begin< }% PDF special state! }/old_showpage /showpage load defp
 }/showpage }{ old_showpage8 }   contract_note execform }} def [...] D }Now when I do my Print/form= statement with a dummy postscript data* }file, no form is printed - just the data.  D Your test file wouldn't happen to be trying to produce only one page of output, would it?  E PostScript is a strange beast, but what this looks like to me is thatdH when the new showpage is executed it will do the original showpage firstC which results in all the data for the page being put onto the paperuB and the page printed. Only then does it put the form into the pageF buffer (or whatever it is called), but it is too late - the first pageG is already done since the original showpage function has been executed.=B The data for the form is on the next page, since it came after theJ showpage. Then it hits the end of the job and the partial page information7 that is hanging around in the buffer is just wiped out.I  @ At least, that is what it looks like to me. If this is the case,C printing something that normally produce two pages of output shouldh? have the form printed on the second page, but not the first. If B this is what happens, then you should have it put the data for the: form on the page before it calls the old_showpage routine.  E If that isn't the case, then I don't understand how it is supposed toi< work and we can blame it all on PostScript for being a mess.   --- Carl   ------------------------------  * Date: Tue, 7 May 2002 08:43:41 -0700 (PDT). From: Fabio Cardoso <fabiopenvms@yahoo.com.br>0 Subject: Re: ES-40 x Oracle RDB *** PROBLEMS ***@ Message-ID: <20020507154341.77029.qmail@web20210.mail.yahoo.com>   Norm  6 I think the problem was reported to Oracle Engineering5 from Oracle Brazil last week. Oracle still working inm, this case and we are waiting for a solution.   Regardsr   FC o0 --- norm lastovica <norman.lastovica@oracle.com> wrote:4 > It appears that this problem was formally reported > to Rdb engineering5 > last week and we've been able to reproduce at leastd > a problem with5 > using a left outer join and hashed indexes with thea > queries provided.B3 > I suspect that continuing to work with Oracle Rdbf > support would be ofu > value to you.b >  > Fabio Cardoso wrote: > > / > > Last month we migrated one application from + > > AS-4100 to a ES-40, but we had problemsV, > > with the Oracle RDB Database. It was too/ > > slow and some queries and joins were giving  > > us mismatched data.t > >  > > Our configuration waso > > / > > ES-40 + OpenVMS 7.2-1H + Oracle  RDB 7.0-63  > > ) > > So, there is a case openend at Oraclea, > > to try to solve our problem. May be they3 > > will suggest migrating to OVMS 7.3 an ORDB 7.1.  > > / > > Is Anyone here using this configuration ???  > >  > > Regards  > >  > > FC > > 	 > > =====  > > ========================== > > Fbio dos Santos Cardoso > > OpenVMS System Manager > > Rio de Janeiro - BrazilF > > fabiopenvms@yahoo.com.br > > ========================== > > 6 > > __________________________________________________ > > Do You Yahoo!?5 > > Yahoo! Health - your guide to health and wellnessl > > http://health.yahoo.com  >  > -- S3 > norman lastovica / oracle rdb engineering / usa /t 610.696.4685     =====u ========================== Fbio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazily fabiopenvms@yahoo.com.br ==========================  2 __________________________________________________ Do You Yahoo!?1 Yahoo! Health - your guide to health and wellnesso http://health.yahoo.coma   ------------------------------   Date: 7 May 2002 04:35 CDT' From: carl@gerg.tamu.edu (Carl Perkins) ) Subject: Re: Fix for EDT emulation in EVEr, Message-ID: <7MAY200204354454@gerg.tamu.edu>  2 spamsink2001@yahoo.com (Alan E. Feldman) writes...B }You just made my case for why EDT is useful. Years ago when I wasF }working in physics, it happened from time to time that I needed to doF }global substitutes in many "input" files. With EDT, this is trivially= }easy as seen in the quote above. With EVE it becomes a total @ }nightmare. I can't use the "Do command line mode commands" in aG }script. I have to write (and waste time learning yet another language,CB }debugging, etc.) or dig up examples of how to do this, reject theE }worthless ones (GSR.TPU, for example, which still no one can tell me - }how to make work), find one that works, etc.g } : }All this because I can't simply put the Do commands I runC }interactively into a script. And I wouldn't call global search and < }replace a rare, oddball, no-one-will-ever-need-it function. }  }Disclaimer: JMHO  }Alan E. Feldman# }afeldman atski gfigroup dotski comT  A You can, in fact, put DO type commands in a script. Try somethingn
 like this:  
 $ type gr.tmpx global replace a z exit   $ type tmp.tmp aa bb ab ba  / $ edit/tpu/init=gr.tmp/nocommand/nodisp tmp.tmp/4 4 lines read from file SYS$SYSROOT:[SYSMGR]TMP.TMP;1G EDT keypad defined (for more information, see help on EDT DIFFERENCES).iG Executing commands in initialization file: SYS$SYSROOT:[SYSMGR]GR.TMP;2e5 4 lines written to file SYS$SYSROOT:[SYSMGR]TMP.TMP;2d   $ type tmp.tmp zz bb zb bz  I It is somewhat irritating how it produces lines of output in /nodisp modeoF (there are a dozen or so more when I don't use /nocommand as it printsF a line of output for every command in the TPU$COMMAND.TPU file). AsideF from redirecting SYS$OUTPUT to NL:, I don't see any way of eliminatingD this output. My preference would be for there to be a way (qaulifierE or logical) to eliminate either all of them or all of them except theBF first (X lines read...) and last (Y lines written...) lines of output.   --- Carl   ------------------------------  % Date: Tue, 07 May 2002 15:54:22 -0000w/ From: Michael Zarlenga <zarlenga@conan.ids.net>4) Subject: Re: Fix for EDT emulation in EVE / Message-ID: <udfu5e81r8glb2@corp.supernews.com>E  / Alan E. Feldman <SPAMSINK2001@YAHOO.COM> wrote:"H : I agree that both EDT and EVE/tpu are useful. I use both. But I preferB : the feel of EDT. And I mention the advantages of EDT mainly as aG : counterpoint to those who say to just forget EDT and use only EVE anda : TPU.  = You like only seeing 24 lines of text in a 50-line ws window?s  > What I like most about EDT is the application keypad and I get" it with SET KEYPAD EDT in EVE/TPU.     -- i -- Mike Zarlenga  '       A good friend will help you move.r.       A best friend will help you move a body.   ------------------------------  % Date: Tue, 07 May 2002 09:55:40 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>v Subject: Re: Gold keye) Message-ID: <3CD7887C.FD49C157@gtech.com>l   Hoff Hoffman wrote:fi > In article <ucraltqve6to7b@corp.supernews.com>, "Sandeep Yelwatkar" <Sandeep_Yelwatkar@bmc.com> writes:o; > :I am a novice to VMs system and learning the EDT editor.c > C >   Please use TPU or other editor, EDT was retired some years ago.    Retired ????  @ EDOT/TPU is default editor in VMS 6.x & 7.x, but I was not aware of that EDI/EDT was retired !k  , > :I am at present going through the manual. > C >   With TPU and newer editors, you can get help from the keyboard.cB >   (Again, EDT really isn't the best editor for a new user -- andC >   this is not intended to start an editor war, as I do prefer and B >   do use the EDT-style keyboard layout daily.  EDT is simply notC >   as advanced as other more recent editors -- TPU and EVE and LSEe( >   all have keypad help, for instance.)   ????   But EDT do have keypad help !N   Arne  E PS: I agree on your recommendation - unless very special requirementso.     exist, then EDIT/TPU should be the choice.   ------------------------------   Date: 7 May 2002 09:27:32 -0500:- From: koehler@encompasserve.org (Bob Koehler)e Subject: Re: Gold keyp3 Message-ID: <8386ZJuClaGZ@eisner.encompasserve.org>e  i In article <3CD7887C.FD49C157@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:9 > Hoff Hoffman wrote:1j >> In article <ucraltqve6to7b@corp.supernews.com>, "Sandeep Yelwatkar" <Sandeep_Yelwatkar@bmc.com> writes:< >> :I am a novice to VMs system and learning the EDT editor. >>  D >>   Please use TPU or other editor, EDT was retired some years ago. >  > Retired ???? >   C    I don't get it.  That's the secobnd time Hoff has said that, yettE    I looked in the SPD last time and it was still there as supported.       Is the SPD wrong?   ------------------------------  % Date: Tue, 07 May 2002 18:09:38 +0200t) From: Bart Zorn <B.Zorn@xs4all.nospam.nl>w' Subject: HP is taking over really fast! / Message-ID: <3CD7FC42.7010106@xs4all.nospam.nl>t  G I just got an e-mail from a friend from inside Compaq. I am absolutely  D sure that HE didn't change his e-mail address, but what I got was a  <someone>@hp.com address.c   That's really fast!   	 Bart Zornb   ------------------------------  $ Date: Tue, 7 May 2002 11:28:14 -05001 From: "Dave Gudewicz" <david.gudewicz@abbott.com> + Subject: Re: HP is taking over really fast!g8 Message-ID: <ab8vf3$47d$1@fizban.fizban.pprd.abbott.com>  3 They've had about 8 months to prepare for this day.    Dave...m  6 "Bart Zorn" <B.Zorn@xs4all.nospam.nl> wrote in message) news:3CD7FC42.7010106@xs4all.nospam.nl...uH > I just got an e-mail from a friend from inside Compaq. I am absolutelyE > sure that HE didn't change his e-mail address, but what I got was an > <someone>@hp.com address.  >n > That's really fast!  >i > Bart Zorni >o   ------------------------------  * Date: Tue, 7 May 2002 16:39:29 +0000 (UTC) From: david20@alpha2.mdx.ac.uk+ Subject: Re: HP is taking over really fast! + Message-ID: <ab9001$spr$1@aquila.mdx.ac.uk>j  [ In article <3CD7FC42.7010106@xs4all.nospam.nl>, Bart Zorn <B.Zorn@xs4all.nospam.nl> writes:mH >I just got an e-mail from a friend from inside Compaq. I am absolutely E >sure that HE didn't change his e-mail address, but what I got was a s ><someone>@hp.com address. >t >That's really fast! > K I would assume someone has setup the Compaq mailhubs to do a simple reverseh3 address rewrite. Probably a one or two line change.g  N The bigger question is whether they co-ordinated this well enough that you can; reply to this address and get it go to the correct person ?rK Not a major problem if the <someone> part is sufficiently different betweenl9 companies but a major problem if you have any duplicates.       
 David Webb VMS and Unix team leader CCSS Middlesex University    
 >Bart Zorn >l   ------------------------------  # Date: Tue, 07 May 2002 16:50:47 GMTr5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> + Subject: Re: HP is taking over really fast!49 Message-ID: <HBTB8.35$dF5.376846@cacnews.cac.cpqcorp.net>r  D Yes.  Except in some cases where there are overlapping names in bothL companies, which is always problematic.  You can send me mail at both hp and compaq - both will reach me.      - david20@alpha2.mdx.ac.uk wrote in message ...=: >In article <3CD7FC42.7010106@xs4all.nospam.nl>, Bart Zorn! <B.Zorn@xs4all.nospam.nl> writes: H >>I just got an e-mail from a friend from inside Compaq. I am absolutelyE >>sure that HE didn't change his e-mail address, but what I got was a_ >><someone>@hp.com address.  >> >>That's really fast!e >>L >I would assume someone has setup the Compaq mailhubs to do a simple reverse4 >address rewrite. Probably a one or two line change. > K >The bigger question is whether they co-ordinated this well enough that youM canr< >reply to this address and get it go to the correct person ?L >Not a major problem if the <someone> part is sufficiently different between: >companies but a major problem if you have any duplicates. >  >p >h >David Webbo >VMS and Unix team leader- >CCSS- >Middlesex University: >C >  >>Bart Zornr >>   ------------------------------  $ Date: Tue, 7 May 2002 16:38:52 +00002 From: John Eisenschmidt <jweisen@eisenschmidt.org>( Subject: HP Roadmap: OpenVMS, Tru64 safe4 Message-ID: <20020507163852.B11726@eisenschmidt.org>   --gj572EiMnwbLXET9* Content-Type: text/plain; charset=us-ascii Content-Disposition: inlineu+ Content-Transfer-Encoding: quoted-printablei  * http://zdnet.com.com/2100-1103-900907.html  L As for the new company's Enterprise Systems Group, it will maintain Compaq'=L s ProLiant server brand. The group "is dedicated to delivering on the ProLi=L ant roadmap and to working with its partners to create industry-defining te=A chnologies based on unifying open standards," the site states.=20    --=20 / John W. Eisenschmidt <jweisen@eisenschmidt.org> 6  Homepage URL    | http://www.eisenschmidt.org/jweisenL  PGP Public Key  | http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.a= scD  PGP Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2  L FOO MANE PADME HUM: "Our first obligation is to keep the FOO counters turni= ng."   --gj572EiMnwbLXET9' Content-Type: application/pgp-signature  Content-Disposition: inlinec   -----BEGIN PGP SIGNATURE-----t Version: GnuPG v1.0.6 (OpenBSD)i* Comment: For info see http://www.gnupg.org  @ iD8DBQE82AMcH5fmozfjvvIRAvB+AJ9whGY3gSeGx1BB+3aMHQvxM5bdPQCgshKJ l0rf1uJ+0W0J8O5+YwWllAo= =3MXv  -----END PGP SIGNATURE-----n   --gj572EiMnwbLXET9--   ------------------------------  # Date: Tue, 07 May 2002 17:48:30 GMTF* From: "Bill Todd" <billtodd@metrocast.net>, Subject: Re: HP Roadmap: OpenVMS, Tru64 safe@ Message-ID: <OrUB8.38025$M7.4716340@bin7.nnrp.aus1.giganews.com>  ? "John Eisenschmidt" <jweisen@eisenschmidt.org> wrote in messaget. news:20020507163852.B11726@eisenschmidt.org...  J While VMS and Tru64 may not have been killed today, calling them 'safe' in5 any normal sense of the term is still a real stretch.a   - bill   ------------------------------   Date: 7 May 2002 03:53 CDT' From: carl@gerg.tamu.edu (Carl Perkins)h8 Subject: Re: Itanium 2 hits ... Itanium 3 will be Alpha!, Message-ID: <7MAY200203534834@gerg.tamu.edu>  5 "Terry C. Shannon" <terryshannon@attbi.com> writes... 7 }"Paul Sture" <p_sture@elias.decus.ch> wrote in messageo$ }news:0FQSb6NeQY8Z@elias.decus.ch...
 }<deletiaLF }> >> I really don't want to believe that you're that gullible. If you	 }believedmM }> >> this was at all meant seriously I've got a bridge here I'd like to selld
 }> >> you. }> >A }> > And I have a little 100 bedroom mansion called Buck house to-C }> > go with the bridge, now if I could only get Queeny to move out  }> > so that Bob can move in.  }> >A }> > There are also some guys in France who would like to talk toi3 }> > Bob about the Eifel tower (this was real con).. }> >% }> And I'm selling him London Bridge.j } J }I don't think so. IIRC the city fathers of Lake Havasu City, Arizona, USAL }bought that bridge over 30 years ago. The "bridge over water that shouldn'tH }be there" was still standing when I flew over it a couple of weeks ago.  F Maybe he's a "Secret City Father of Lake Havasu" and they're tyring to unload the thing.   / It could be true, at least as far as Bob knows.    --- Carl   ------------------------------  % Date: Tue, 07 May 2002 16:22:26 +0100dU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>r8 Subject: Re: Itanium 2 hits ... Itanium 3 will be Alpha!0 Message-ID: <ab8rfj$lf3$1@new-usenet.uk.sun.com>   Terry C. Shannon wrote:e  8 > "Paul Sture" <p_sture@elias.decus.ch> wrote in message% > news:0FQSb6NeQY8Z@elias.decus.ch...  > <deletiaLs > D >>>>I really don't want to believe that you're that gullible. If you >>>>
 > believed > K >>>>this was at all meant seriously I've got a bridge here I'd like to sello >>>>you. >>>> >>>> >>>i? >>>And I have a little 100 bedroom mansion called Buck house toPA >>>go with the bridge, now if I could only get Queeny to move outs >>>so that Bob can move in.? >>> ? >>>There are also some guys in France who would like to talk to,1 >>>Bob about the Eifel tower (this was real con).  >>>r >>>c$ >>And I'm selling him London Bridge. >> > K > I don't think so. IIRC the city fathers of Lake Havasu City, Arizona, USAyM > bought that bridge over 30 years ago. The "bridge over water that shouldn't I > be there" was still standing when I flew over it a couple of weeks ago.e >  >     = We have a new London Bridge built to replace the old one from < now on called London Bridge 95. Now if we could interest Bob in buying both.r  > Incedentally the story was that Lake Havasu City bought LondonA Bridge thinking it was Tower Bridge (much more interesting bridge $ if you are into that sort of thing).   Regardsn Andrew Harrison    ------------------------------  # Date: Tue, 07 May 2002 12:57:21 GMTy2 From: "Sue Skonetski" <susan.skonetski@compaq.com> Subject: Just got this from BEAb9 Message-ID: <RaQB8.13$MC5.285853@cacnews.cac.cpqcorp.net>   $       You asked - BEA is delivering!=       Announcing the first ever BEA Customer Support Webinar!t   Dear  Customer,   E We have received numerous inquiries on how to optimize performance of J underutilized CPUs and build a scalable fault-tolerant environment. If youI need to accelerate your time to market, increase your ROI or improve yoursF technical knowledge of BEA products, then this webinar is for you. BEAK Customer Support invites you to attend a free one-hour Web-based seminar onoE "BEA WebLogic Server 6.x Clustering." This webinar is one of the manyb= benefits you receive with your BEA Customer Support contract.v  H Clustering is integral to developing highly scalable, fault tolerant webL applications. BEA WebLogic Enterprise Platform developers and administratorsH alike will come away from this seminar with an understanding of the coreI issues associated with cluster configuration, deployment and development.   J The BEA WebLogic Server 6.x Clustering webinar will cover some of the mostK frequently asked questions, as well as basic BEA WebLogic Server clusteringiG concepts and configuration. Specific topics include: how to configure aLJ cluster - including licensing concerns, network set-up (IP and Multicast),C server configuration and other related concerns such as applicationIB deployment. In addition, this webinar will identify additional BEAI informational resources, including educational offerings, to help furtheriK expand your knowledge of BEA WebLogic Server clustering. Upon conclusion of K the webinar, you will have the opportunity to ask specific questions to theeI BEA Developer Relations Engineer Host who is a WebLogic Server clusteringo technology expert.  F This webinar is ideal for developers, system administrators and othersL interested in doing simple configuration of BEA WebLogic Server clusters, orK who may need to deploy applications in a clustered environment. Anyone withoJ 2-3 months BEA WebLogic Server 6.x experience will gain valuable knowledge( on how a WebLogic cluster is configured.   AGENDA:e    #   a.. Clustering top of mind topicst   b.. Key assumptionso2   c.. Design considerations for planning a cluster   d.. Informational resources B   e.. An opportunity to submit questions to our technology experts  : WHAT: Webinar exploring BEA WebLogic Server 6.x Clustering   WHERE: Your Desktop   3 WHEN: Tuesday, May 14, 2002, 10:00am PT / 1:00pm ETc   HOW: Register Now!*g  K *Please note: The link above is customized just for your individual use. IfLL you would like to recommend this event to colleagues, please direct them to:E http://contact2.beasys.com/bea/www/webinars/suplogin.jsp?PC=SUPWB-REF1  / You must be a BEA Support Customer to register.O   See you online!    Regards, BEA Systems, Inc.i   ------------------------------  + Date: Tue, 07 May 2002 18:15:17 +0100 (MET)r9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>m4 Subject: leading tabs (was: RE: Revisionist history); Message-ID: <01KHGETF3AP08Y8ZDE@sysdev.deutsche-boerse.com>   I Do people who put leading tabs in their email do so because VMS MAIL has  H a tab after each field, i.e. so that the text lines up with the text of 9 the header fields (and not with the flush-left keywords)?   K ----------------<8---------------------------------------------------------a  < From:	IN%"young_r@encompasserve.org"  7-MAY-2002 18:11:05.09 To:	IN%"Info-VAX@Mvb.Saic.Com" CC:	 Subj:	RE: Revisionist history1  E 	It *should* be price performance competitive with EV7 when McKinley A 	ships.    ------------------------------   Date: 7 May 2002 08:31:39 -0500$- From: koehler@encompasserve.org (Bob Koehler)eA Subject: RE: MacOS/X is the leading Unix (was "Itanium Troubles") 3 Message-ID: <wQt6U1D98yvU@eisner.encompasserve.org>S  x In article <7E008308CD77154485FEF878168D078E01784542@CMIMAIL1.amdocs.com>, Christopher Smith <csmith@amdocs.com> writes: > A > Not to get into another off-topic argument, but actually, thereo? > are at least two other Unixes with good interfaces -- I wouldtB > say better.  NeXTSTEP (Yes, it's now defunct, so may not count), > and IRIX.r  H    I admit to not having seen NeXTSTEP and suspect it has some influence
    over OS X.f  F    But I use IRIX and can't fathom you're statement.  Have you used OS    X?e   ------------------------------   Date: 7 May 2002 08:33:01 -0500y- From: koehler@encompasserve.org (Bob Koehler)rA Subject: Re: MacOS/X is the leading Unix (was "Itanium Troubles")[3 Message-ID: <0duEaQIQgKjG@eisner.encompasserve.org>a  U In article <H+eOtOM5D6tC@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:O  I > There's a flaw to this argument about MacOS/X having the leading share, K > since OS/X does not come installed with a new machine. New Macs _do_ come H > with an OS/X CD, but it is _not_ factory installed. That may of course > vary by country and supplier.   J    All the Macs I've bought since last summer came with factory installed D    OS X.  For some strange reason Apple is still setting the defaultD    boot to OS 9, but changing the boot is not doing an installation.   ------------------------------  $ Date: Tue, 7 May 2002 09:02:03 -0500+ From: Christopher Smith <csmith@amdocs.com> A Subject: RE: MacOS/X is the leading Unix (was "Itanium Troubles")aJ Message-ID: <7E008308CD77154485FEF878168D078E01784577@CMIMAIL1.amdocs.com>   --=_IS_MIME_Boundary Content-Type: text/plain;V 	charset="iso-8859-1"8   > -----Original Message-----D > From: koehler@encompasserve.org [mailto:koehler@encompasserve.org]  H >    But I use IRIX and can't fathom you're statement.  Have you used OS >    X?n  E Briefly, and this may not be fair since it's been a while, but at thesC time, my impression was definitely that IRIX had a nicer interface.   0 Not so flashy, of course, but I liked it better.   Chriso    ! Christopher Smith, Perl Developerg Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");  '     --=_IS_MIME_Boundary) Content-Type: text/plain;charset=us-ascii- Content-Transfer-Encoding: 7bit0 Content-Disposition: inlinei  U -------------------------------------------------------------------------------------D  C The information contained in this message is proprietary of Amdocs,t1 protected from disclosure, and may be privileged.SN The information is intended to be conveyed only to the designated recipient(s)L of the message. If the reader of this message is not the intended recipient,P you are hereby notified that any dissemination, use, distribution or copying of ? this communication is strictly prohibited and may be unlawful. eN If you have received this communication in error, please notify us immediately> by replying to the message and deleting it from your computer.
 Thank you.  U -------------------------------------------------------------------------------------    --=_IS_MIME_Boundary--   ------------------------------  % Date: Tue, 07 May 2002 09:39:08 +0100e From: paul.beaudoin@hsbc.com, Subject: Memo:  Help restoring a system diskE Message-ID: <OF600C43C1.4CA96B47-ON80256BB2.002C0914@systems.uk.hsbc>e   A tale of woe and frustration:H After adding a few disks to my system, one error compounding another has$ left me without a system at present. Basics:7(      DPW 500au  VMS 7.3  9GB system diskK The disks added were 2 x 4.3 GB disks added to the front bay and while theycE were not the right physical format (a bit tall and too skinny)  a fewoI screws and gaffer's tape secures them well. They worked just fine but thee/ system disk could not be accessed after reboot.c Error:;      Media is not present or disabled by Run/Stop switch...m  K This is at console level. Disk appears OK and test scsi produces same error 8 and interestingly enough reports this disk as a printer!  H Not being sure what the error meant, I installed a new version of VMS on= one of the new disks and booted it. This worked fine (Whew!).hJ The ex system disk showed up on a Sho Dev but would not mount. Same error.  G Being of sound mind and having backups, I proceeded to restore a recentnH backup of the system onto the other of the new disks. The restore worked without error.J Booting off this disk starts as normal but hangs with the last line on the screen reading something like:      Starting QIO$CONFIGUREbK I tried booting minimum with the same result but left it and after about 10aI min, VMS crashes. Being on a VT320 I was unable to see the primary reason4' for crash. The dump is in the pagefile.w   It boils down to 3 questions: 2 What is wrong with the original system disk? (9GB)2 What is wrong with the new system disk? (restored)K How do I access the crash dump on the restored disk's pagefile? I can stilla boot the newly installed VMS.   $ Additional/significant/red herrings:  I I noticed a bent pin on the 9GB disk when inspecting it. It is possible I E have pulled a jumper off by accident and this is the Run/Stop switch? G The backup was made with the system up and using the /IGNORE=INTERLOCK.iK Also a /VERIFY. The verification pass only complained about log files. Note07 this is a two node cluster and this is the common disk.sI The disks keep disappearing from the console. Upon power up all is normal I but after an init only the CD shows up. A power down and up brings it allsG back.. This may be as I normally have a 'pizza box' attached and wasn't B during initial testing. The 'b' side of the scsi was therefore notJ terminated. Could this have affected the 'a' side? This is a minor issue -I I have always found this console to be a bit weird - If I don't init on aeG reboot VMS crashes very late into the boot. Never figured it out and itqJ always works after init (and always fails without). Firmware upgraded some& 6 months ago. Not sure of the version.  H Any ideas/ advice / help is most gratefully received. I already know theF moral: This is what happened when you give a programmer a screwdriver.   Many thanks    Paul          ' ** HSBC's website is at www.hsbc.com **   D ********************************************************************B  This message and any attachments are confidential to the ordinaryB  user of the e-mail address to which it was addressed and may also>  be privileged. If you are not the addressee you may not copy,8  forward, disclose or use any part of the message or itsC  attachments and if you have received this message in error, pleasepB  notify the sender immediately by return e-mail and delete it from
  your system.   =  Internet communications cannot be guaranteed to be secure or A  error-free as information could be intercepted, corrupted, lost,r>  arrive late or contain viruses. The sender therefore does not?  accept liability for any errors or omissions in the context ofc?  this message which arise as a result of Internet transmission.e   D  Any opinions contained in this message are those of the author and ?  are not given or endorsed by the HSBC Group company or office  =  through which this message is sent unless otherwise clearly pA  indicated in this message and the authority of the author to so j3  bind the HSBC entity referred to is duly verified.e  D ********************************************************************   ------------------------------  $ Date: Tue, 7 May 2002 12:09:37 +01004 From: "Chris Sharman" <chris.sharman@ccagroup.co.uk>D Subject: Old RAID 230 logical init very slow (63% done after 5 days)B Message-ID: <1020769806.27115.0.nnrp-12.9e989e7e@news.demon.co.uk>  < I've dusted off & powered up our old 2100A 5/300 + RAID 230.' I've installed a clean copy of VMS,etc. ; I've booted from the RAID floppy, and reconfigured my RAID.o8 (We used to have 6 2Gb mirror sets, + 2 9Gb JBOD disks).L I deleted the JBOD disks & the last mirror set, and created a 9Gb mirror set + two 2Gb hot spares. I It wanted me to initialise the 9Gb set, and I wanted to reinitialise 4 of , the 5 mirror sets (all but the system disk).K The docs said it could do several at a time, and I thought it might be more ( efficient, so I set it going (Thursday).L It started well enough, and I figured I'd come back in a couple of hours and see how it was going.eH By the end of the day, it looked like it would need overnight to finish.J By the following morning (Friday) it seemed to be going slower, and by theL end of Friday I hoped the bank holiday would give it time to finish (the 2Gb% sets were on 70-80%, the 9Gb on 20%).oJ This morning (Tuesday), the 2Gb sets are finally all done, but the 9Gb set! is on 63%, and still progressing.:/ Is this for real, or is there something wrong ?tL I'm loathe to reboot, because I might lose the configuration (which I didn'tI save to floppy before the initialisation), and I might wind up restarting % the week-long initialisation process.-   Any suggestions appreciated.; Time is (fortunately) not critical at present for this box..   Thanks,c
 Chris Sharmana   ------------------------------  % Date: Tue, 07 May 2002 07:35:23 -0400g* From: Chuck Chopp <ChuckChopp@rtfmcsi.com>H Subject: Re: Old RAID 230 logical init very slow (63% done after 5 days)* Message-ID: <3CD7BBFB.8070109@rtfmcsi.com>   Chris Sharman wrote:  > > I've dusted off & powered up our old 2100A 5/300 + RAID 230.) > I've installed a clean copy of VMS,etc.-= > I've booted from the RAID floppy, and reconfigured my RAID.e: > (We used to have 6 2Gb mirror sets, + 2 9Gb JBOD disks).N > I deleted the JBOD disks & the last mirror set, and created a 9Gb mirror set > + two 2Gb hot spares.cK > It wanted me to initialise the 9Gb set, and I wanted to reinitialise 4 ofw. > the 5 mirror sets (all but the system disk).M > The docs said it could do several at a time, and I thought it might be morem* > efficient, so I set it going (Thursday).N > It started well enough, and I figured I'd come back in a couple of hours and > see how it was going.eJ > By the end of the day, it looked like it would need overnight to finish.L > By the following morning (Friday) it seemed to be going slower, and by theN > end of Friday I hoped the bank holiday would give it time to finish (the 2Gb' > sets were on 70-80%, the 9Gb on 20%).mL > This morning (Tuesday), the 2Gb sets are finally all done, but the 9Gb set# > is on 63%, and still progressing.g1 > Is this for real, or is there something wrong ?oN > I'm loathe to reboot, because I might lose the configuration (which I didn'tK > save to floppy before the initialisation), and I might wind up restartingn' > the week-long initialisation process.l >  > Any suggestions appreciated.= > Time is (fortunately) not critical at present for this box.1 > 	 > Thanks,  > Chris Sharmani >  >  >     6 I just had to tangle with one of these not long ago...  L 1)  Make sure that your AlphaServer is up to date w/respect to its firmware.  B 2)  Make sure that your SWXCR card is up to date w/respect to its I firmware and the version of the Raid Confinguration Utility that you are . using to configure it.  H 3)  Even if you don't have battery backup for the cache RAM on the RAID D controller, change the caching policy from write-thru to write-back H while you are initializing the logical drives and while you are copying G data onto them.  After those tasks are done, go back in and change the iC policy back to write-thru, provided that you don't have the batter  C backup module.  This change in caching policy drastically improves ,9 performance of write activities on RAID-5 logical drives.     F Also, of note, the KZPSC-xx controllers [and KZESC-xx] let you create G very large volume groups that are greater than 32GB in size, but there eI is a limit to how large a logical drive you can create.  The RCU program  H sets the maximum size at 32,768 MB, but OpenVMS' DRDRIVER device driver E can only handle logical drives on these cards with a maximum size of lC 32,000 MB [65,535,000 disk blocks under OpenVMS "SHOW DEVICE/FULL"  E command].  If you exceed the size that OpenVMS supports then certain eJ write activities on the large volume will cause a system bugcheck & crash.     HTH,   Chuckg --   Chuck Choppr  8 ChuckChopp@rtfmcsi.com            http://www.rtfmcsi.com1                                    ICQ # 22321532s@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 774 0718 pager8                                    8007740718@skytel.com   ------------------------------  $ Date: Tue, 7 May 2002 13:39:01 +01004 From: "Chris Sharman" <chris.sharman@ccagroup.co.uk>H Subject: Re: Old RAID 230 logical init very slow (63% done after 5 days)A Message-ID: <1020775162.3169.0.nnrp-01.9e989e7e@news.demon.co.uk>p  7 "Chuck Chopp" <ChuckChopp@rtfmcsi.com> wrote in messaget$ news:3CD7BBFB.8070109@rtfmcsi.com... > Chris Sharman wrote:  > > Any suggestions appreciated.? > > Time is (fortunately) not critical at present for this box.o8 > I just had to tangle with one of these not long ago... >tD > 1)  Make sure that your AlphaServer is up to date w/respect to its	 firmware.r  H Installed the latest (5.9 firmware update CD which came with the 7.3 VMS kit).r  C > 2)  Make sure that your SWXCR card is up to date w/respect to itsiJ > firmware and the version of the Raid Confinguration Utility that you are > using to configure it.  9 Doesn't the firmware CD do the SWXCR card automatically ?BJ I wondered about the RAID software, but I don't know where to get updates, or whether there are any.LG I've got a few floppies: RAID array 200 s/w V2.2 for vms - AK-QGTMC-CA.tJ The standalone s/w bills itself onscreen as Config Utility V3.11 04/05/95, Firmware V2.36.tJ The floppy that's in the machine is labelled AK-Q6TFE-CA (that's all I can read without ejecting it).K Is any of this shipped with VMS or layered product CD dist, or via internetU ?   I > 3)  Even if you don't have battery backup for the cache RAM on the RAIDeE > controller, change the caching policy from write-thru to write-back I > while you are initializing the logical drives and while you are copyingeH > data onto them.  After those tasks are done, go back in and change theD > policy back to write-thru, provided that you don't have the batterD > backup module.  This change in caching policy drastically improves; > performance of write activities on RAID-5 logical drives.w  G Ah, yes - that would make a big difference. Possibly that's a lot of my  problem.J 4Gb was as big as disks got when we bought this kit - the 9Gb disks were a much later addition.  G > Also, of note, the KZPSC-xx controllers [and KZESC-xx] let you createpH > very large volume groups that are greater than 32GB in size, but thereJ > is a limit to how large a logical drive you can create.  The RCU programI > sets the maximum size at 32,768 MB, but OpenVMS' DRDRIVER device driver F > can only handle logical drives on these cards with a maximum size ofD > 32,000 MB [65,535,000 disk blocks under OpenVMS "SHOW DEVICE/FULL"F > command].  If you exceed the size that OpenVMS supports then certainL > write activities on the large volume will cause a system bugcheck & crash.  " No plans to exceed 9Gb at present.   Thanks,: Chris0   ------------------------------  % Date: Tue, 07 May 2002 09:59:00 -0400j* From: Chuck Chopp <ChuckChopp@rtfmcsi.com>H Subject: Re: Old RAID 230 logical init very slow (63% done after 5 days)* Message-ID: <3CD7DDA4.4030605@rtfmcsi.com>   Chris Sharman wrote:  9 > "Chuck Chopp" <ChuckChopp@rtfmcsi.com> wrote in messaget& > news:3CD7BBFB.8070109@rtfmcsi.com... >  >>Chris Sharman wrote: >> >>>Any suggestions appreciated.-> >>>Time is (fortunately) not critical at present for this box. >>>@8 >>I just had to tangle with one of these not long ago... >>D >>1)  Make sure that your AlphaServer is up to date w/respect to its >> > firmware.  > J > Installed the latest (5.9 firmware update CD which came with the 7.3 VMS > kit).  >  > C >>2)  Make sure that your SWXCR card is up to date w/respect to itsuJ >>firmware and the version of the Raid Confinguration Utility that you are >>using to configure it. >> > ; > Doesn't the firmware CD do the SWXCR card automatically ?5L > I wondered about the RAID software, but I don't know where to get updates, > or whether there are any.oI > I've got a few floppies: RAID array 200 s/w V2.2 for vms - AK-QGTMC-CA.oL > The standalone s/w bills itself onscreen as Config Utility V3.11 04/05/95, > Firmware V2.36.nL > The floppy that's in the machine is labelled AK-Q6TFE-CA (that's all I can > read without ejecting it).M > Is any of this shipped with VMS or layered product CD dist, or via internet- > ?- >  >   I IIRC, no, the AlphaServer firmware CD will update many peripheral cards' vC firmware, but not the SWXCR.  I found the updates in an un-obvious I location, at this URL:  H http://ftp.digital.com/pub/Digital/Alpha/firmware/v6.2/utility/swxcrmgr/  C You can get the latest SWXCR firmware and RCU [both GUI and serial rF versions] from this location.  The SWXCR card that I was working with G had really old firmware on it dating back to 1995, and the performance  F of the logical drive initialization was just terrible using the newer D 9GB drives.  After I upgraded the firmware and turned on write-back F caching I was able to initialize a 32,000 MB logical drive in about 1  hour and 50 minutes.     HTH,   Chuckt -- b Chuck Choppb  8 ChuckChopp@rtfmcsi.com            http://www.rtfmcsi.com1                                    ICQ # 223215329@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 774 0718 pager8                                    8007740718@skytel.com   ------------------------------  * Date: Tue, 7 May 2002 08:50:24 -0700 (PDT). From: Fabio Cardoso <fabiopenvms@yahoo.com.br>" Subject: Re: OpenVMS Certification@ Message-ID: <20020507155024.17205.qmail@web20203.mail.yahoo.com>   Michaelr  0 I have just 11 years of experience with OpenVMS.4 I begans as computer operator, installing Decservers etc ....5 Some companies which I worked for didnt have interest 3 to pay me the courses. Nowadays the OpenVMS coursesP5 are rares in Brazil. I am waiting since the last year 2 to do the Troubleshooting and Performance courses 1 for example ! I dont know if in anyday of my lifeo6 I will have the Crash Dump Anal. and System Internals 3 Courses here in .BR ! I dont feel a complete Sysman-5 because I dont have this background. There is no good-2 literature about OpenVMS except those books at BH.1 Some are a little bit obsolete, like David Millerr( book, which explain the VMS architecure.     Regardsn   FC o6 --- Michael Austin <maustin@firstdbasource.com> wrote: > Fabio Cardoso wrote: > > 
 > > Hi peoplei > > , > > How many guys are cetified in OpenVMS in2 > > this newsgroup ??? Was it worthful for you ???/ > > May be there is a possibility for me to gety > > a certification. > >  > > Regardsu > >  > > FC > > 	 > > =====o > > ========================== > > Fbio dos Santos Cardoso > > OpenVMS System Manager > > Rio de Janeiro - Brazil  > > fabiopenvms@yahoo.com.br > > ========================== > > 6 > > __________________________________________________ > > Do You Yahoo!?5 > > Yahoo! Health - your guide to health and wellnessl > > http://health.yahoo.comM > 3 > Gee, why would one need a "certification" with 18C > years experience.  I0 > feel sorry for those who hire "certified" over > experience...  I have hadd4 > to clean up after way too many "certified" this or > that to have anythinga > good to say about it...D >  > -- M
 > Regards, > 1 > Michael Austin            Registered Linux User 	 > #261163t > First DBA Source, Inc.   t > http://www.firstdbasource.com  > Sr. Consultant > 704-947-1089 (Office)f > 704-236-4377 (Mobile)e >      =====  ========================== Fbio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.br ==========================  2 __________________________________________________ Do You Yahoo!?1 Yahoo! Health - your guide to health and wellness  http://health.yahoo.comr   ------------------------------  # Date: Tue, 07 May 2002 06:02:19 GMTb* From: "Bill Todd" <billtodd@metrocast.net>1 Subject: Re: Questions on the new structire at HPoA Message-ID: <L5KB8.113378$Lj.8807744@bin4.nnrp.aus1.giganews.com>e  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CD75578.DE46D3E5@videotron.ca...B > While cycling tonight, I got to wonder about that new structure. > 1 > Marcello is in charge of Alpha , Tru64 and VMS.   I Actually, IIRC responsibility for Tru64 is split between Marcello and thel. HP/UX people trying to carve organs out of it.    There someone in charge of thet. > Tandem business, and one in charge of HP-UX. >aF > The wording of the memo I read mentioned something about "easing the; > transition to IA64 servers" as one of Mr Marcello's jobs.k  K I suspect his main job:  everything else may look a lot like maintenance by  comparison.o   >eJ > *at this point in time* *with only that information at hand*, I am a bit
 concerned. >hI > The way I see it, HP created a "Legacy" department, put Marcello as itsb headL > and gave him all the old digital stuff HP doesn't care about but can't get rid of.g  L That's certainly the impression I had, and it seems to follow along the sameL lines as the 'promotion' Compaq gave him a while ago (I recall that I wasn'tH the only one who thought that smelled a bit like extending his duties toJ include the entire mortuary rather than just the piece of it he previously	 oversaw)..   - bill   ------------------------------  $ Date: Tue, 7 May 2002 09:40:42 +0100; From: "Colin Butcher" <colinDOT.butcher@xdeltaDOT.coDOT.uk>d) Subject: Re: Removing AS1000A front paneliA Message-ID: <eqMB8.31875$%1.3544808@news-binary.blueyonder.co.uk>w  F There are 3 more screws under the hinged side of the door. You need toL remove the door to gain access to them - do that by pushing the hinge pin upG through the top edge of the door and be careful not to lose the spring.   G There are yet more screws which come in from behind - take off the side:K panels to gain access to them. The side panels come off once you've removedkI the top panel by sliding it backwards - carefully so as not to crunch the* wiring to the interlock switch.*  J Fixing the door lock is a pain - the biggest hassle is getting it all backI together after you've made up and fitted new hinge pins. My first attemptaH used "super glue" to fix back the broken plastic pins. My second (ratherJ more successful) attempt uses tiny steel screws with the heads removed andI the screw bonded into the body of the door lock by screwing them in whilea hot enough to melt the plastic.i   See manuals in PDF available at H http://www.compaq.com/alphaserver/archive/1000a/1000a_tech.html for more information.   -- Hope this helps. Colinr# (colinDOTbutcherATxdeltaDOTcoDOTuk)e    5 "Alder" <PGDEHMKOKIMD@spammotel.com> wrote in messages& news:3CD72289.4020603@spammotel.com... > [NEWBIE ALERT] >sI > The AS1000A (pedestal model) I just got has a broken door lock I'd likeeB > to fix, which will require that I remove the front panel.  AfterF > removing the 3 screws located below the top-panel lock, I ran out ofF > clues on how to proceed.  Can anyone help me find the hidden screws? >h > Many thanks, >b > AlderS >e   ------------------------------  * Date: Tue, 7 May 2002 12:59:28 +0000 (UTC)* From: Osmo Kujala <kujala@tukki.cc.jyu.fi>  Subject: Re: Revisionist history, Message-ID: <ab8j3g$rfg$1@mordred.cc.jyu.fi>  4 Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:  L > In my opinion, Alpha was and is a superior approach and architecture.  ButM > the decision was made that we could not afford to continue to support it asAJ > a niche product.  The decision was made to consolidate enterprise serverG > development using a single architecture, with a wider selection of OSrE > choices, and to not invest in CPU chip development.  Intel had beenrM > sucessful with a really crappy ISA (the X86).  Given enough time and money,nK > I am sure Alpha could have sustained a lead in performance - but probablyaE > not by "huge" margins over the competition - and to date, the AlphaaL > advantage has not turned it into a market share leader.  IA64 will soon beK > on par or better than everything except a couple chips - including Alpha. J > Over time, Intel has a track record of driving performance and cost withJ > IA32, and I would expect the same with IA64.  The volumes will be higherI > than Alpha, the cost per-chip lower (with no NRE cost), and we can have N > fewer system platform development teams.  While the gap exists between AlphaJ > performance and IA64 performance - the EV7 systems will continue to be aN > great system.  We have provided a roadmap that provides a large overlap whenL > both systems will be available, and when EV7 runs out of gas, IA64 will beK > there.  VMS will be running on the same platforms with HP-UX, with a muchnE > larger market share than Tru64., and HP-UX will get an injection ofaB > technology from Tru64.  Sun will over the next few years go fromK > uncompetetive on price/performance in the low end today (a IA32 system is0M > cheaper and faster), and marginally competetive on the high end today (onlyaF > the Fujitsu systems are leaders right now) - to uncompetetive on allN > fronts - as they will continue to fall behind with Sparc.  Sun will probablyL > have to abandon Sparc in a few years (or less) - maybe for x86-64, but whoJ > knows what they will do - it's not clear that Hammer et al will scale toN > very large CPU counts and big enterprise servers.  The only real competitionK > will be IBM.  Intel now has the bulk of the Alpha development team, and IeI > expect that in the middle of the decade, their expertise will push IA64r2 > quite faster than the doom-sayers would predict.  + Now, lets try next substitutes to the text:  /Alpha/VMS/m /CPU/OS/
 /Intel/MS/ /OS/application/ /performance/reliability/u
 /X86/Windows/e /IA64/NT64/c etc.  I What we get is how Fred<<<<Barney will explain how it was not the end of o+ the world when HP announced end of VMS. :-)   J --- edited text ---(Note: this does not contain Fred's opinions nor mine) H In my opinion, VMS was and is a superior approach and architecture.  ButJ the decision was made that we could not afford to continue to support it  E as a niche product.  The decision was made to consolidate enterprise lB solution development using a single OS, with a wider selection of F application choices, and to not invest in OS development.  MS had beenH sucessful with a really crappy OS (the Windows).  Given enough time and F money, I am sure VMS could have sustained a lead in reliability - but J probably not by "huge" margins over the competition - and to date, the VMSJ advantage has not turned it into a market share leader.  NT64 will soon beE on par or better than everything except a couple OSs - including VMS.eE Over time, MS has a track record of driving performance and cost withWE Windows, and I would expect the same with NT64.  The volumes will be hH higher than VMS, the cost per-sold lower (with no XYZ cost), and we can E have fewer solution development teams.  While the gap exists between  G VMS reliability and NT64 reliability - the VMS 7.4 will continue to be lK a great version.  We have provided a roadmap that provides a large overlap tI when both systems will be available, and when V7.4 runs out of gas, NT64 cH will be there.  Applications will be running on the same OS, with a muchA larger market share, and HP-applications will get an injection of 5 technology.  Sun will over the next few years go fromoE uncompetetive on price/performance in the low end today (NT&Linux areyF cheaper and faster), and marginally competetive on the high end today H (only the Fujitsu? systems are leaders right now) - to uncompetetive on J all fronts - as they will continue to fall behind with Solaris.  Sun will F probably have to abandon Solaris in a few years (or less) - maybe for K NT64-A, but who knows what they will do - it's not clear that Hammer et al  J will scale to very large CPU counts and big enterprise servers.  The only G real competition will be IBM and Linux. Wintel now has the bulk of the  K VMS development team, and I expect that in the middle of the decade, their fI expertise will push NT64 quite faster than the doom-sayers would predict.n   Barney --- end of edited text ---   Osmo   ------------------------------   Date: 7 May 2002 08:04:55 -05002- From: koehler@encompasserve.org (Bob Koehler)   Subject: RE: Revisionist history3 Message-ID: <GO0Nltp2LeCJ@eisner.encompasserve.org>    In article <BE56C50EA024184DAF48F0B9A47F5CF401AB1F0F@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@Compaq.com> writes: > F > Remember that when the Alpha was first introduced, the initial AlphaH > systems were slower than some of the big VAX systems. It was only overI > time when newer Alpha systems began to rapidly pull away from those big  > VAX systems performance.  F    Just barely.  When Pathworks for OpenVMS Alpha 1.5 was announced, IG    bought the cheapest, slowest Alpha DEC shipped (DEC 3000 Model 200? hC    I'm not sure about the model number) to replace an MV II we weretE    using as our server.  It was only slightly slower than a VAX 9000.i   ------------------------------   Date: 7 May 2002 08:06:16 -0500t- From: koehler@encompasserve.org (Bob Koehler)C  Subject: Re: Revisionist history3 Message-ID: <NBpmzAOHxNS6@eisner.encompasserve.org>   K In article <ab6457$63$1@aquila.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:o >>I >>   Turing showed that this is always possible.  However emulating a VAXpE >>   on a system with (for example) no mempoy protection would not bewH >>   anywhere near the same as porting VMS to such a machine.  The firstH >>   may be doable, but excruciatingly slow.  The latter would result in% >>   something that just waasn't VMS.o >> > H > Of course this is true. But my understanding is that Charon Vax is NOT > excruciatingly slow.  H    No, its not.  But then it's running on hardware that does have memoryF    protection.  I wonder if they the emulator takes advantage of that?   ------------------------------  # Date: Tue, 07 May 2002 14:04:50 GMTo5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>b  Subject: Re: Revisionist history9 Message-ID: <6aRB8.16$UD5.327745@cacnews.cac.cpqcorp.net>c   Bill Todd wrote in message8 <_4AB8.106429$Lj.8149512@bin4.nnrp.aus1.giganews.com>... >vA >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message 4 >news:dtvB8.13$v65.362645@cacnews.cac.cpqcorp.net...D >> David Froble wrote in message <3CD5E545.2050703@tsoft-inc.com>... >l >... >tF >> >> "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message >> >H >> >>>The decision was made to not stay in the CPU development business. >> > >> >G >> >Now this is a statement that cannot be argued with.  Many have seen3 >through >> allJ >> >the BS, and plainly Compaq didn't want to be in the CPU business, even if >> theym9 >> >had and would continue to have the best in the world.M >> >& >> >But then one more rationalization: >> >
 >> >>>  SinceVH >> >>>Intel is in the CHIP business, and not in the system business - it >wouldA >> >>>seem to me to make much better sense than the alternatives.s >> > >> >K >> >And as with every other rationalization that has come out of Compaq, asr >> seen = >> >above, this one like all others cannot withstand reality.a >> >L >> >Why can't these people just come out and say that they didn't want to be >inh >> theJ >> >chip business, and quit trying to justify their actions with any other >> reasons..K >> >  There are no other reasons.  Treating their customers as if they werep >> gullable>L >> >idiots (not mentioning anyone specific) is almost, but not quite as bad, >as  >> >breaking commitments.t >> > >> >> What is the rationalization?  >h* >For Christ's sake, Fred - can't you read? >i  K Was anything in this post directed at you?  When it is I'll use small wordse
 and all caps.)  I Why don't *you* read.  Better yet, why don't you do something productive.t   >>   ------------------------------  # Date: Tue, 07 May 2002 14:07:16 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>e  Subject: Re: Revisionist history9 Message-ID: <ocRB8.17$WD5.329768@cacnews.cac.cpqcorp.net>w   Bill Todd wrote in message ... >tA >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messagef4 >news:UBvB8.16$R65.376857@cacnews.cac.cpqcorp.net...K >> Russell Wallace wrote in message <3cd6501c.339152210@news.eircom.net>...p7 >> >On Sun, 05 May 2002 20:44:47 GMT, "Fred Kleinsorge"a( >> ><kleinsorge@star.zko.dec.com> wrote: >> >J >> >>What does this mean?  Do you know any company that delegates critical. >> >>business decisions to "technology types"? >> >J >> >No (except in the cases where the CEO is from a technical background). >> >$ >> >>Several important technologists' >> >>were part of the decision process.t >> >I >> >However, AFAIK it was made for business reasons rather than technical ( >> >ones, as you yourself suggest below: >> > >>F >> Most decisions in a business are business decisions, but it was not# >> decoupled from technical advice.e >rH >Indeed - it was just decoupled from competent and/or unbiased technical >advice. >   E Again Jack, who's talking to you?  Is there every an unbiased opinon? J Everyone comes to the party with their own point of view.  Just because weI don't share your opinion doesn't mean that it wasn't good advice, or well > informed advice - as opposed to your arm chair quarterbacking.  J It's easy to be the jerk who sits on the outside and plays the all knowing critic.    ------------------------------  # Date: Tue, 07 May 2002 14:11:52 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>   Subject: Re: Revisionist history9 Message-ID: <IgRB8.18$vE5.342102@cacnews.cac.cpqcorp.net>8  A David Froble wrote in message <3CD6FECF.2080802@tsoft-inc.com>...u >Fred Kleinsorge wrote:i >iD >> David Froble wrote in message <3CD5E545.2050703@tsoft-inc.com>... >> >>>John Smith wrote: >>>a >>> H >>>>Intel is the largest 'white box' server manufacturer/supplier in the
 >>>>business.  >>>> >>>>D >>>>"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message >>>>G >>>>>The decision was made to not stay in the CPU development business.a >>>>>d >>> F >>>Now this is a statement that cannot be argued with.  Many have seen througho >>>l >> all >>L >>>the BS, and plainly Compaq didn't want to be in the CPU business, even if >>>  >> theye >>8 >>>had and would continue to have the best in the world. >>>i% >>>But then one more rationalization:k >>>B >>>o >>>>> SincelG >>>>>Intel is in the CHIP business, and not in the system business - itr would @ >>>>>seem to me to make much better sense than the alternatives. >>>>>  >>>iJ >>>And as with every other rationalization that has come out of Compaq, as >>>p >> seen  >>< >>>above, this one like all others cannot withstand reality. >>> K >>>Why can't these people just come out and say that they didn't want to be  in >>>  >> the >>I >>>chip business, and quit trying to justify their actions with any otherM >>>t >> reasons.  >>I >>> There are no other reasons.  Treating their customers as if they were= >>>= >> gullable  >>K >>>idiots (not mentioning anyone specific) is almost, but not quite as bad,! as >>>breaking commitments. >>>w >>>s >>K >> What is the rationalization?  If you decide that you don't want to be in  the1K >> CPU business, then the next step is to see if there is someone who wants  to= >> take over or at least partner with you to supply the chip,t >e >tK >Yep, and there are/were three (3) such entities.  Intel, Samsung, and IBM.e Was,I >there any consideration of having any of these 3 continue with the AlphasK >research and design?  I'm guessing not.  There are/were incentives for any  ofL >them to do so.  First would be the Alpha design team.  And never forget theL >compiler talent.  The CPU manufacturer would get some top notch talent, andF >would get paid to FAB CPUs.  Hey, isn't that the business they're in? >_H >Is there any evidence that Compaq would have continued to use Alpha, if theyK >could get out of the R&D end of things?  I'd be greatly surprised if there- isJ >any.  Compaq not only wanted out of the chip business, they wanted out of' >anything but 'me too' type of systems.  >   H Lets say, that every time the story is told, it starts out as a quest to find a partner for Alpha.<   ------------------------------  $ Date: Tue, 7 May 2002 07:19:08 -0700# From: "Tom Linden" <tom@kednos.com>,  Subject: RE: Revisionist history9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIENBEOAA.tom@kednos.com>V   Fred,c  = There has occassionaly been references to starting a new listn? to separate technical from "other" discussions.  Let me suggests@ instead of using the acronym os for Operating system comp.os.vms> we use the german equivalent Betrieb System or bs, comp.bs.vms
 How's that:-)t   >-----Original Message-----s; >From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com]e$ >Sent: Tuesday, May 07, 2002 7:05 AM >To: Info-VAX@Mvb.Saic.Com! >Subject: Re: Revisionist historyt >n >t >Bill Todd wrote in messagem9 ><_4AB8.106429$Lj.8149512@bin4.nnrp.aus1.giganews.com>...e >>B >>"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message5 >>news:dtvB8.13$v65.362645@cacnews.cac.cpqcorp.net... E >>> David Froble wrote in message <3CD5E545.2050703@tsoft-inc.com>...l >> >>...e >>G >>> >> "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messaget >>> >nI >>> >>>The decision was made to not stay in the CPU development business.  >>> >i >>> >uH >>> >Now this is a statement that cannot be argued with.  Many have seen	 >>through- >>> all-K >>> >the BS, and plainly Compaq didn't want to be in the CPU business, evenl >if. >>> they: >>> >had and would continue to have the best in the world. >>> >s' >>> >But then one more rationalization:r >>> >o >>> >>>  SinceI >>> >>>Intel is in the CHIP business, and not in the system business - ito >>wouldoB >>> >>>seem to me to make much better sense than the alternatives. >>> >  >>> >eL >>> >And as with every other rationalization that has come out of Compaq, as >>> seen> >>> >above, this one like all others cannot withstand reality. >>> >.B >>> >Why can't these people just come out and say that they didn't >want to bea >>in >>> the K >>> >chip business, and quit trying to justify their actions with any other  >>> reasons.L >>> >  There are no other reasons.  Treating their customers as if they were >>> gullable? >>> >idiots (not mentioning anyone specific) is almost, but notr >quite as bad, >>as >>> >breaking commitments. >>> >t >>>u  >>> What is the rationalization? >>+ >>For Christ's sake, Fred - can't you read?  >> >rL >Was anything in this post directed at you?  When it is I'll use small words >and all caps. >eJ >Why don't *you* read.  Better yet, why don't you do something productive. >  >> >t >. >---' >Incoming mail is certified Virus Free.h; >Checked by AVG anti-virus system (http://www.grisoft.com).oA >Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002W >  ---]& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002   ------------------------------  # Date: Tue, 07 May 2002 14:17:40 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>h  Subject: Re: Revisionist history9 Message-ID: <8mRB8.20$nB5.238744@cacnews.cac.cpqcorp.net>   # Entertaining, but rather pointless.   J Do I believe that there is a danger of this happening soon?  No.  Is thereL the prospect that some day this might happen to VMS?  Sure, if Bill Todd andJ his ilk have his way, VMS would be further marginalized to the point whereH it has little or no profit, and a small and shrinking customer base - atL which point it would make very little sense to do anything else except place it into maintenance mode.           Osmo Kujala wrote in message ...5 >Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:h >dH >> In my opinion, Alpha was and is a superior approach and architecture. ButGK >> the decision was made that we could not afford to continue to support itn asK >> a niche product.  The decision was made to consolidate enterprise servertH >> development using a single architecture, with a wider selection of OSF >> choices, and to not invest in CPU chip development.  Intel had beenG >> sucessful with a really crappy ISA (the X86).  Given enough time andi money,L >> I am sure Alpha could have sustained a lead in performance - but probablyF >> not by "huge" margins over the competition - and to date, the AlphaJ >> advantage has not turned it into a market share leader.  IA64 will soon beL >> on par or better than everything except a couple chips - including Alpha.K >> Over time, Intel has a track record of driving performance and cost withiK >> IA32, and I would expect the same with IA64.  The volumes will be higher J >> than Alpha, the cost per-chip lower (with no NRE cost), and we can haveI >> fewer system platform development teams.  While the gap exists betweenl AlphanK >> performance and IA64 performance - the EV7 systems will continue to be a J >> great system.  We have provided a roadmap that provides a large overlap whenJ >> both systems will be available, and when EV7 runs out of gas, IA64 will beL >> there.  VMS will be running on the same platforms with HP-UX, with a muchF >> larger market share than Tru64., and HP-UX will get an injection ofC >> technology from Tru64.  Sun will over the next few years go from6L >> uncompetetive on price/performance in the low end today (a IA32 system isH >> cheaper and faster), and marginally competetive on the high end today (onlyeG >> the Fujitsu systems are leaders right now) - to uncompetetive on alleF >> fronts - as they will continue to fall behind with Sparc.  Sun will probablyI >> have to abandon Sparc in a few years (or less) - maybe for x86-64, bute whobK >> knows what they will do - it's not clear that Hammer et al will scale to C >> very large CPU counts and big enterprise servers.  The only realt competitionwL >> will be IBM.  Intel now has the bulk of the Alpha development team, and IJ >> expect that in the middle of the decade, their expertise will push IA643 >> quite faster than the doom-sayers would predict.d > , >Now, lets try next substitutes to the text: >/Alpha/VMS/	 >/CPU/OS/w >/Intel/MS/f >/OS/application/  >/performance/reliability/ >/X86/Windows/ >/IA64/NT64/ >etc.l >tI >What we get is how Fred<<<<Barney will explain how it was not the end ofi, >the world when HP announced end of VMS. :-) > J >--- edited text ---(Note: this does not contain Fred's opinions nor mine)I >In my opinion, VMS was and is a superior approach and architecture.  ButdI >the decision was made that we could not afford to continue to support it E >as a niche product.  The decision was made to consolidate enterprise B >solution development using a single OS, with a wider selection ofG >application choices, and to not invest in OS development.  MS had beennH >sucessful with a really crappy OS (the Windows).  Given enough time andF >money, I am sure VMS could have sustained a lead in reliability - butK >probably not by "huge" margins over the competition - and to date, the VMShK >advantage has not turned it into a market share leader.  NT64 will soon belF >on par or better than everything except a couple OSs - including VMS.F >Over time, MS has a track record of driving performance and cost withE >Windows, and I would expect the same with NT64.  The volumes will beiH >higher than VMS, the cost per-sold lower (with no XYZ cost), and we canE >have fewer solution development teams.  While the gap exists between G >VMS reliability and NT64 reliability - the VMS 7.4 will continue to beuK >a great version.  We have provided a roadmap that provides a large overlap I >when both systems will be available, and when V7.4 runs out of gas, NT64 I >will be there.  Applications will be running on the same OS, with a much B >larger market share, and HP-applications will get an injection of6 >technology.  Sun will over the next few years go fromF >uncompetetive on price/performance in the low end today (NT&Linux areF >cheaper and faster), and marginally competetive on the high end todayH >(only the Fujitsu? systems are leaders right now) - to uncompetetive onJ >all fronts - as they will continue to fall behind with Solaris.  Sun willF >probably have to abandon Solaris in a few years (or less) - maybe forK >NT64-A, but who knows what they will do - it's not clear that Hammer et al2J >will scale to very large CPU counts and big enterprise servers.  The onlyG >real competition will be IBM and Linux. Wintel now has the bulk of theeK >VMS development team, and I expect that in the middle of the decade, theiraJ >expertise will push NT64 quite faster than the doom-sayers would predict. >w >Barneyi >--- end of edited text ---  >y >Osmoe   ------------------------------  # Date: Tue, 07 May 2002 15:22:39 GMT ( From: spam@devnull.com (Russell Wallace)  Subject: Re: Revisionist history0 Message-ID: <3cd7f052.445718471@news.eircom.net>  3 On Tue, 07 May 2002 14:07:16 GMT, "Fred Kleinsorge"h$ <kleinsorge@star.zko.dec.com> wrote:  K >It's easy to be the jerk who sits on the outside and plays the all knowing  >critic.  F For my part, I actually wish you guys the best of luck - you've done a@ good job by all accounts and you deserve to succeed. (Note: that< applies to Compaq's engineers, not its senior management :))  C I am, however, still interested both in what will end up happening,gF and in the reasons why people reckon IA64 will ever become competitive in either performance or price.d   -- h3 "Mercy to the guilty is treachery to the innocent." ! http://www.esatclear.ie/~rwallacem mail:rw(at)eircom(dot)netb   ------------------------------   Date: 7 May 2002 11:01:29 -0500e+ From: young_r@encompasserve.org (Rob Young)y  Subject: Re: Revisionist history3 Message-ID: <os$4onasESxt@eisner.encompasserve.org>f  [ In article <3cd7f052.445718471@news.eircom.net>, spam@devnull.com (Russell Wallace) writes:  > E > I am, however, still interested both in what will end up happening, H > and in the reasons why people reckon IA64 will ever become competitive! > in either performance or price.e >   E 	It *should* be price performance competitive with EV7 when McKinley o 	ships.b  < 	Today a 4 processor Itanium box with 16 GBytes of memory isA 	considerably cheaper than a 4 processor 16 GByte AlphaServer and8A 	probably on parity price performance wise.  But that is a bit ofnA 	a game.  Because McKinley is better performing, I am officially .B 	prognosticating that a 4 processor McKinley box with 4 GBytes of E 	memory will be better from a price performance perspective than a 4 lE 	processor EV7 AlphaServer when it ships(1).  Of course the EV7 will hA 	be higher performing and a better solution, but the 4 processor >@ 	McKinley will win a "value proposition" contest (i.e. cheaper).     				Robe    K (1)  Doller per specint and dollar per specfp ratio.  Dollar per tpmC ratio D 	also (using larger memories here naturally, so this isn't a "game")   ------------------------------  % Date: Tue, 07 May 2002 17:20:10 +0100>U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>w  Subject: Re: Revisionist history0 Message-ID: <ab8urq$mhu$1@new-usenet.uk.sun.com>   Fred Kleinsorge wrote:  J > Russell Wallace wrote in message <3cd64d58.338443807@news.eircom.net>... > 5 >>On Sun, 05 May 2002 20:48:08 GMT, "Fred Kleinsorge">& >><kleinsorge@star.zko.dec.com> wrote: >> >>8 >>>"Russell Wallace" <spam@devnull.com> wrote in message >>>qI >>>>I got the impression their plan was to dump x86 ultimately when IA-64r >>>>replaced it. >>>>J >>>Not in any near term future.  x86 is cheap and fast for the desktop and >>>small servers.c >>>  >>*nod* Fair enough. >> >>J >>>>Now that IA-64 seems unlikely to outlive Alpha let alone x86, probablyJ >>>>their only option will be to switch to x86-64. It'll be interesting to* >>>>see how late they leave it to do this. >>>>I >>>Only if you are listening to Bill Todd.  Intel hasn't backed away fromy >>>  > IA64,  >  >>>and I don't think they will.- >>>-G >>But at the end of the day it's not what Intel does that matters, it's  >>what the customers do. >>H >>Why do you think customers will pay large sums of money to switch to aE >>chip that's slower than what they have already? (Serious question.)n >> >> > N > Anyone running a Sparc ;-)  It *isn't* slower than what the vast majority ofL > customers are currently running, it's just not faster than a number of HPS > CPU's. >     ; Freddy boy still hawking the old SPARC slow everything else>0 fast argument to anyone who doesn't know better.  5 When you have actual benchmarks to back this claim upe9 then share them with us, help Kerry out at the same time.   " Otherwise its a tired sorry story.   Regardss Andrew Harrison    ------------------------------  # Date: Tue, 07 May 2002 16:44:53 GMTo* From: "Bill Todd" <billtodd@metrocast.net>  Subject: Re: Revisionist historyA Message-ID: <9wTB8.118462$Lj.9198621@bin4.nnrp.aus1.giganews.com>o  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message3 news:6aRB8.16$UD5.327745@cacnews.cac.cpqcorp.net...e > Bill Todd wrote in message   ...   , > >For Christ's sake, Fred - can't you read? > >  > , > Was anything in this post directed at you?   Well, in fact, yes.   6 Here's a quick explanation of how to use a newsreader:  L When you want to direct something to one specific individual, use the 'reply" to sender' (or equivalent) option.  L When you want to direct a comment to the entire newsgroup, use the 'reply to group' (or equivalent) option.   Hope that helps,   - bill   ------------------------------  # Date: Tue, 07 May 2002 16:48:06 GMTe* From: "Bill Todd" <billtodd@metrocast.net>  Subject: Re: Revisionist historyA Message-ID: <azTB8.96140$Ii2.8544700@bin2.nnrp.aus1.giganews.com>i  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message3 news:ocRB8.17$WD5.329768@cacnews.cac.cpqcorp.net...s  > Bill Todd wrote in message ...   ...   J > >Indeed - it was just decoupled from competent and/or unbiased technical
 > >advice. > >s >l# > Again Jack, who's talking to you?>  K You - see previous response.  If you have difficulty understanding it, help>
 is available.   $   Is there every an unbiased opinon?L > Everyone comes to the party with their own point of view.  Just because weK > don't share your opinion doesn't mean that it wasn't good advice, or wellm@ > informed advice - as opposed to your arm chair quarterbacking. >>L > It's easy to be the jerk who sits on the outside and plays the all knowing	 > critic.t  I Actually, not so easy:  it's harder to obtain the information you need to  make informed comments.i  E As the jerk sitting on the inside, however, you don't appear to thinkt. information quality is particularly important.   - bill   ------------------------------  * Date: Tue, 7 May 2002 16:45:39 +0000 (UTC) From: david20@alpha2.mdx.ac.uk  Subject: Re: Revisionist history+ Message-ID: <ab90bj$spr$2@aquila.mdx.ac.uk>i  a In article <os$4onasESxt@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:t\ >In article <3cd7f052.445718471@news.eircom.net>, spam@devnull.com (Russell Wallace) writes: >> iF >> I am, however, still interested both in what will end up happening,I >> and in the reasons why people reckon IA64 will ever become competitive>" >> in either performance or price. >> i > F >	It *should* be price performance competitive with EV7 when McKinley  >	ships. >e= >	Today a 4 processor Itanium box with 16 GBytes of memory is B >	considerably cheaper than a 4 processor 16 GByte AlphaServer andB >	probably on parity price performance wise.  But that is a bit ofB >	a game.  Because McKinley is better performing, I am officially C >	prognosticating that a 4 processor McKinley box with 4 GBytes of iF >	memory will be better from a price performance perspective than a 4 F >	processor EV7 AlphaServer when it ships(1).  Of course the EV7 will B >	be higher performing and a better solution, but the 4 processor A >	McKinley will win a "value proposition" contest (i.e. cheaper).t >  >p >				Rob >  >tL >(1)  Doller per specint and dollar per specfp ratio.  Dollar per tpmC ratioE >	also (using larger memories here naturally, so this isn't a "game")t >c  M Are you talking the overpriced Compaq (I suppose it should now be HPQ) memory 2 or the much cheaper third party memory for Alphas.M As I recall from previous discussions that makes a vast difference when doing- comparisons.  
 David Webb VMS and Unix team leader CCSS Middlesex University4                                                        ------------------------------  # Date: Tue, 07 May 2002 16:57:17 GMTy5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>e  Subject: Re: Revisionist history9 Message-ID: <NHTB8.36$5H5.426111@cacnews.cac.cpqcorp.net>t  E Here's a quick explanation, I don't really care what your opinion is.,K Please add me to your killfile so that we don't continue to respond to eachi* other.  I in turn will return you to mine.  @ Again, when I want your opinon (like we don't know it) I'll ask.       Bill Todd wrote in message8 <9wTB8.118462$Lj.9198621@bin4.nnrp.aus1.giganews.com>... >9A >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messagen4 >news:6aRB8.16$UD5.327745@cacnews.cac.cpqcorp.net... >> Bill Todd wrote in messageo >n >... >>- >> >For Christ's sake, Fred - can't you read?0 >> > >>- >> Was anything in this post directed at you?o >" >Well, in fact, yes. >.7 >Here's a quick explanation of how to use a newsreader:a >tF >When you want to direct something to one specific individual, use the 'reply# >to sender' (or equivalent) option.. >aJ >When you want to direct a comment to the entire newsgroup, use the 'reply to >group' (or equivalent) option.  >. >Hope that helps,d >d >- billn >u >o >v   ------------------------------  # Date: Tue, 07 May 2002 16:59:41 GMTr5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>u  Subject: Re: Revisionist history9 Message-ID: <1KTB8.37$6H5.427092@cacnews.cac.cpqcorp.net>    Bill Todd wrote in message ... > A >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messageo4 >news:ocRB8.17$WD5.329768@cacnews.cac.cpqcorp.net...! >> Bill Todd wrote in message .... >> >... > K >> >Indeed - it was just decoupled from competent and/or unbiased technical  >> >advice.  >> > >>$ >> Again Jack, who's talking to you? >eL >You - see previous response.  If you have difficulty understanding it, help >is available. >o  J See previous reply.  Please add me (and maybe we can start a new thread ofK people that would also like to be added) to your kill file so that we don't 8 have to exchange opinions.  I'm adding you back to mine.  % >  Is there every an unbiased opinon?rJ >> Everyone comes to the party with their own point of view.  Just because weL >> don't share your opinion doesn't mean that it wasn't good advice, or wellA >> informed advice - as opposed to your arm chair quarterbacking.  >>E >> It's easy to be the jerk who sits on the outside and plays the all  knowing 
 >> critic. > J >Actually, not so easy:  it's harder to obtain the information you need to >make informed comments. >G  @ Let someone (other than me) know when you finally accomplish it.  F >As the jerk sitting on the inside, however, you don't appear to think/ >information quality is particularly important.  >e  3 Let someone (other than me) know when you have any.R   ------------------------------   Date: 7 May 2002 12:08:47 -0500c+ From: young_r@encompasserve.org (Rob Young)t  Subject: Re: Revisionist history3 Message-ID: <NuWIAmN9Tuv+@eisner.encompasserve.org>h  L In article <ab90bj$spr$2@aquila.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:c > In article <os$4onasESxt@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:n] >>In article <3cd7f052.445718471@news.eircom.net>, spam@devnull.com (Russell Wallace) writes:n >>> G >>> I am, however, still interested both in what will end up happening, J >>> and in the reasons why people reckon IA64 will ever become competitive# >>> in either performance or price.s >>>  >>G >>	It *should* be price performance competitive with EV7 when McKinley t	 >>	ships.c >>> >>	Today a 4 processor Itanium box with 16 GBytes of memory isC >>	considerably cheaper than a 4 processor 16 GByte AlphaServer andrC >>	probably on parity price performance wise.  But that is a bit ofsC >>	a game.  Because McKinley is better performing, I am officially yD >>	prognosticating that a 4 processor McKinley box with 4 GBytes of G >>	memory will be better from a price performance perspective than a 4  G >>	processor EV7 AlphaServer when it ships(1).  Of course the EV7 will eC >>	be higher performing and a better solution, but the 4 processor >B >>	McKinley will win a "value proposition" contest (i.e. cheaper). >> >>	 >>				Robe >> >>M >>(1)  Doller per specint and dollar per specfp ratio.  Dollar per tpmC ratioeF >>	also (using larger memories here naturally, so this isn't a "game") >> > O > Are you talking the overpriced Compaq (I suppose it should now be HPQ) memoryl4 > or the much cheaper third party memory for Alphas.O > As I recall from previous discussions that makes a vast difference when doingg > comparisons. >   I 	Yes.  And to be fair, original OEM.  Since an OEMed Compaq - HP box willlI 	contain HPQ memory.  But to throw a guess, 4 GByte Kingston memory in anwF 	McKinley and 4 GByte RDRAM Kingston (does it exist?  If not 3rd party> 	RDRAM if it would work) in a EV7 will bring things closer to A 	parity, but the McKinley would still squeek a price performance   	advantage.i  H 	Of course 16 GBytes of AlphaServer memory skewers things.  That was my ? 	"game" above.  But major RFPs (often) won't let you buy memorylB 	free boxes.  When that happens, it is amazing how much less of a G 	discount you get and much nastier issues, etc.  Been there, done that.u   				Robb   ------------------------------  % Date: Tue, 07 May 2002 17:57:50 +0100 U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>   Subject: Re: Revisionist history0 Message-ID: <ab912e$n3r$1@new-usenet.uk.sun.com>   Rob Young wrote:  ] > In article <3cd7f052.445718471@news.eircom.net>, spam@devnull.com (Russell Wallace) writes:e > E >>I am, however, still interested both in what will end up happening,wH >>and in the reasons why people reckon IA64 will ever become competitive! >>in either performance or price.S >> >> > G > 	It *should* be price performance competitive with EV7 when McKinley  	 > 	ships.t > > > 	Today a 4 processor Itanium box with 16 GBytes of memory isC > 	considerably cheaper than a 4 processor 16 GByte AlphaServer andtC > 	probably on parity price performance wise.  But that is a bit ofMC > 	a game.  Because McKinley is better performing, I am officially oD > 	prognosticating that a 4 processor McKinley box with 4 GBytes of G > 	memory will be better from a price performance perspective than a 4 oG > 	processor EV7 AlphaServer when it ships(1).  Of course the EV7 will cC > 	be higher performing and a better solution, but the 4 processor lB > 	McKinley will win a "value proposition" contest (i.e. cheaper). >     5 Why limit yourself to Alpha boxes in your comparison.b  C Humm could it be that Alpha boxes arn't price competitive currently    regardsa Andrew Harrisont   ------------------------------  # Date: Tue, 07 May 2002 16:38:28 GMTe# From: "Dan" <io_crater@hotmail.com> . Subject: Re: Running CSWS 1.2 on Alpha VMS 7.2; Message-ID: <8qTB8.39487$uE2.2659393@news2.calgary.shaw.ca>l  L While I am happy to have helped find a bug, this is one I hope you aren't inK a hurry to fix. At least until the VMS hobbyist kit version can catch up tot the CSWS requirements.   Dan Henigman    6 "Rick Barry" <barry@star.zko.dec.com> wrote in message3 news:57gA8.24$Bt2.605318@cacnews.cac.cpqcorp.net...o< > Hmmm...looks like our minimum version check isn't working. >a > You got lucky :) >  > Rick Barry* > Compaq Secure Web Server Deveopment Team  > OpenVMS Systems Software Group > Compaq Computer Corporationn > Nashua, NH > 0 > "Dan" <io_crater@hotmail.com> wrote in message5 > news:rh_z8.4182$uE2.276765@news2.calgary.shaw.ca.../H > > I installed CSWS 1.2 on a VMS 7.2 hobbyist system. No changes to theI > > downloaded kit were required.  I had been running the beta 1.2 and itr wasd3 > > nicely removed during the released 1.2 install.s > > 
 > > [snip] >o >l   ------------------------------  + Date: Tue, 07 May 2002 14:57:42 +0100 (MET)s9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>l* Subject: Re: Sayonara DS10, new org charts; Message-ID: <01KHG7XR6VA88Y8ZDE@sysdev.deutsche-boerse.com>.  L > Interesting that thew new DS20 has a SCISI controller  with a mention "for > Linux only".   This is the DS20L.                 ^d1 > Can anyone care to explain what this is about ?   I There was a thread here a while back about this being a very specialised d? box and not supported on VMS---or do you have another question?a   ------------------------------  # Date: Tue, 07 May 2002 13:37:47 GMTc. From: peter@langstoeger.at (Peter LANGSTOEGER)* Subject: Re: Sayonara DS10, new org charts5 Message-ID: <LMQB8.162437$vc2.1876214@news.chello.at>e  w In article <01KHG7XR6VA88Y8ZDE@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes: M >> Interesting that thew new DS20 has a SCISI controller  with a mention "forj >> Linux only".s >d >This is the DS20L.e >                ^2 >> Can anyone care to explain what this is about ? >)J >There was a thread here a while back about this being a very specialised @ >box and not supported on VMS---or do you have another question?  F I think someone is mangling the not-so-new but limited-to-the-telecomsE DS20L (already mentioned in a thread here some weeks/months ago) witht) the coming DS25 (sp?) entry level system.- Or did the plans change ?1  Or is this confusion intended...   -- v Peter "EPLAN" LANGSTOEGER:% Network and OpenVMS system specialisto E-mail  peter@langstoeger.atP A-1030 VIENNA  AUSTRIA              I'm looking for (a) Network _and_ VMS Job(s)   ------------------------------  $ Date: Tue, 7 May 2002 15:36:47 +0400 From: biv@MCI.CBR.RU Subject: set info-vax nomail3 Message-ID: <16023849694.20020507153647@mci.cbr.ru>e   set info-vax nomaili   ------------------------------  % Date: Tue, 07 May 2002 12:23:00 -0400i2 From: norm lastovica <norman.lastovica@oracle.com> Subject: simh VAX VMS users?* Message-ID: <3CD7FF64.8288465F@oracle.com>  D I've been playing around with running VMS on the SIMH VAX simulator.F Most things are working OK.  I've installed VMS V7.3, a DEC C compiler? and Rdb.  I'm trying to debug a problem where a process in the wD simulated environment seems to get stuck waiting for a disk write to" the system disk seems to complete.  < Anyone else got this up and running?  Any tricks to share?     -- o> norman lastovica / oracle rdb engineering / usa / 610.696.4685   ------------------------------  % Date: Tue, 07 May 2002 12:29:19 -0400 2 From: norm lastovica <norman.lastovica@oracle.com>  Subject: Re: simh VAX VMS users?* Message-ID: <3CD800DF.6DDF5BEE@oracle.com>  : here's the contents my "setup.ini" procedure for SIMH VAX:    load -r sys$disk:[.vax]KA655.BIN
 set DBGLOG 40U set log q.qc set rq0 ra92 set rq1 ra92 set rq2 ra92
 at rq0 x0.dsk:
 at rq1 x1.dskt
 at rq2 x2.dskg boot cpu  : To manipulate the disk image files from the host system, I9 installed the LDDRIVER (from the OpenVMS freeware CD) and.< created disk files of about 4 million blocks each.  When the6 simulator is down, I can mount the LD devices and copy; files around or whatever.  Then dismount and disconnect thee* LD devices and go back into the simulator.  : I also need to learn how to hook up the DZ ports to telnet; ports so that I can use my regular terminal emulator rathert3 than just the console.  Anyone set this up already?r   norm lastovica wrote:  > F > I've been playing around with running VMS on the SIMH VAX simulator.H > Most things are working OK.  I've installed VMS V7.3, a DEC C compiler@ > and Rdb.  I'm trying to debug a problem where a process in theF > simulated environment seems to get stuck waiting for a disk write to$ > the system disk seems to complete. > < > Anyone else got this up and running?  Any tricks to share? >  > --@ > norman lastovica / oracle rdb engineering / usa / 610.696.4685   -- g> norman lastovica / oracle rdb engineering / usa / 610.696.4685   ------------------------------  # Date: Tue, 07 May 2002 13:25:07 GMTa# From: "John Smith" <a@nonymous.com>h0 Subject: Re: SKC Morphs Again... We're Now SKHPCD Message-ID: <TAQB8.328$j0I.202@news02.bloor.is.net.cable.rogers.com>  : "Terry C Shannon" <shannon@world.std.com> wrote in message> news:Pine.SGI.4.30.0205061905271.27402-100000@world.std.com... >lF > Whatever, I wouldn't be overly worried about HPQ's impact on the VMSL > roadmap. I have told my subscribers that I anticipate no change whatsoeverH > to the roadmap. VMS on Marvel will happen. VMS on IPF will happen. TheI > only concern I have is the level of investment HPQ maintains in the OS,s > and in the marketing thereof.8 >8  F Which brings us sort-of full circle to the mid/late-'80's when VMS wasH heavily invested in by DEC, marketing was substantially greater, but theE price/performance sucked. And thence began the great sucking sound assL customers went to Sun, not for technical superiority but because it appearedD to be cheaper. And we will likely see a similar set of migrations toI Power-AIX (probably) with Intel-cpu based VMS / Tru64-HP/UX, for the same  reasons.   ------------------------------  # Date: Tue, 07 May 2002 14:20:48 GMTd5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 0 Subject: Re: SKC Morphs Again... We're Now SKHPC9 Message-ID: <4pRB8.21$Tv5.151689@cacnews.cac.cpqcorp.net>u  = JF Mezei wrote in message <3CD6CE0F.7CD91300@videotron.ca>...s >Fred Kleinsorge wrote:s: >> We'll see.  The next few months may give an indication. >a >. >NO !s >mF >Carly has told everyone that there would be a very clear and detailed roadmap8G >available within days of the signing of the deal. We have waited since.< >September 7th to find out what the hell will happen to VMS. >d  I And what's your point.  You have ALSO said you won't believe anything sheyH says.  I expect what *you* are asking for to be available real-soon-now.  K >She must first divulge a clear roadmap. Then the next few months will showcK >whether she really means it or not, and the next few quarters will also sor ifF >the various games of musical chairs that will happen will change that roadmap  >or not.  ) There you go.  Just what I said.  Sheesh.s   ------------------------------  % Date: Tue, 07 May 2002 16:32:53 +0100rU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>a0 Subject: Re: SKC Morphs Again... We're Now SKHPC0 Message-ID: <ab8s35$ll3$1@new-usenet.uk.sun.com>   Fred Kleinsorge wrote:    > Bill Todd wrote in message ... > : >>"Rob Young" <young_r@encompasserve.org> wrote in message/ >>news:lGELmlXAGUYz@eisner.encompasserve.org...: >>I >>>In article <uPgA8.32040$q8.3459454@bin3.nnrp.aus1.giganews.com>, "Billt >>><( >>Todd" <billtodd@metrocast.net> writes: >> >>...p >> >>D >>>>Sorry - UltraSPARC III.  You know, the processor line Rob always >>>> >>denigrates >>D >>>>for being such a pig that Itanic will quickly usurp Sun's entire >>>>
 >>customer >>I >>>>base as its start on conquering the world.  That's why it would be soo >>>> >>funnyi >>2 >>>>if McKinley turned out to be slower after all. >>>> >>>>4 >>>Is that an "official" prognostication, or a wish? >>> I >>I made a quantitive prediction (based on publicly-available informationbL >>which I described) some time ago that McKinley would weigh in at 600 - 700L >>SPECint2K (and most likely in the middle of that range), and I stand by itG >>(unless it gets delayed so long that Intel can skip the first releaseMB >>entirely and go directly to what would have been the first majorL >>post-release process tweak - which is looking increasingly possible).  TheI >>best USIII SPECint2K currently is 610, but since such values do tend to  >> > rise > M >>as new configurations appear I'd say there's a distinct possibility, thoughpI >>perhaps not a better-than-even chance, that if McKinley doesn't in factD >> > wait > J >>for a process-tweak before releasing it will at introduction have a hard) >>time equalling USIII's SPECint2K speed.a >> >> > K > So there you go.  Assuming your predictions are right, McKinley will beatpL > USIII (and even your outside estimate of USIII getting faster doesn't takeN > into account the tricked up compiler that caused the temportary "upgrade" of > USIII speed).  >     @ There you go again posting about something you don't understand.  C 1. The optimisation used by Sun only effected SPECfp note that BillkF is talking about SPECint. Even you should be aware of the differences.  F 2, It wasn't a trick and if you think it was perhaps you could back up< your claim with evidence other than suppostion on your part.      L > So IA64 systems will at minimum be performance competetive with USIII, and3 > from what I understand will be priced much lower.  >     E This would have been an interesting point had your previous ones beenT) correct since they were not it isn't :):)s   Regards9 Andrew Harrisong   ------------------------------  % Date: Tue, 07 May 2002 16:39:38 +01004U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>i0 Subject: Re: SKC Morphs Again... We're Now SKHPC0 Message-ID: <ab8sfq$lmt$1@new-usenet.uk.sun.com>   Fred Kleinsorge wrote:  < > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3CD33DC4.C4E3C02B@videotron.ca... >   D >>of the big guys such as Oracle said that they would continue theirJ >>"commitment" to VMS, but these same people's definition of commitment isI >>different since they don't port all of Oracle to VMS, only the database  >>
 > backend. >  > H > You don't have to listen exclusively to Bill.  It's not all that slow,4 > especially if you are currently using Sun systems. >  >     > When you can come up with evidence that your statement is true= for Oracle then come back to me. At the moment the balance of"= evidence is in favour of you being so out of luck performance7 wise if you are on Alpha.c  C How about backing your claim up with credible comparative benchmarkdA data instead of appearing to be in search of a marketing diploma.   @ I have provided plenty of publically available benchmark results which disprove your claim.     Regardsd   Andrew Harrisond   ------------------------------  " Date: Tue, 7 May 2002 16:42:46 GMT- From: Terry C Shannon <shannon@world.std.com>t0 Subject: Re: SKC Morphs Again... We're Now SKHPCC Message-ID: <Pine.SGI.4.30.0205071241400.5595-100000@world.std.com>o  % On Tue, 7 May 2002, John Smith wrote:p   >r< > "Terry C Shannon" <shannon@world.std.com> wrote in message@ > news:Pine.SGI.4.30.0205061905271.27402-100000@world.std.com... > >sH > > Whatever, I wouldn't be overly worried about HPQ's impact on the VMSN > > roadmap. I have told my subscribers that I anticipate no change whatsoeverJ > > to the roadmap. VMS on Marvel will happen. VMS on IPF will happen. TheK > > only concern I have is the level of investment HPQ maintains in the OS, ! > > and in the marketing thereof.o > >a > H > Which brings us sort-of full circle to the mid/late-'80's when VMS wasJ > heavily invested in by DEC, marketing was substantially greater, but theG > price/performance sucked. And thence began the great sucking sound as-N > customers went to Sun, not for technical superiority but because it appearedF > to be cheaper. And we will likely see a similar set of migrations toK > Power-AIX (probably) with Intel-cpu based VMS / Tru64-HP/UX, for the samei
 > reasons. >a  G Plausible. Possible. And likely, unless The New HP has read its history@: books and chooses not to repeat the sins of the fathers...   ------------------------------  # Date: Tue, 07 May 2002 16:48:11 GMTn5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>t0 Subject: Re: SKC Morphs Again... We're Now SKHPC9 Message-ID: <fzTB8.33$uF5.390298@cacnews.cac.cpqcorp.net>e  6 Andrew Harrison SUNUK Consultancy wrote in message ... >c >e >Fred Kleinsorge wrote:h >7! >> Bill Todd wrote in message ...> >>; >>>"Rob Young" <young_r@encompasserve.org> wrote in messagec0 >>>news:lGELmlXAGUYz@eisner.encompasserve.org... >>>rJ >>>>In article <uPgA8.32040$q8.3459454@bin3.nnrp.aus1.giganews.com>, "Bill >>>>) >>>Todd" <billtodd@metrocast.net> writes:m >>>I >>>... >>>y >>>>E >>>>>Sorry - UltraSPARC III.  You know, the processor line Rob alwaysm >>>>>i
 >>>denigrateso >>>rE >>>>>for being such a pig that Itanic will quickly usurp Sun's entiree >>>>>i >>>customeru >>>hJ >>>>>base as its start on conquering the world.  That's why it would be so >>>>>  >>>funny >>>l3 >>>>>if McKinley turned out to be slower after all.> >>>>>> >>>>>e5 >>>>Is that an "official" prognostication, or a wish?f >>>>J >>>I made a quantitive prediction (based on publicly-available informationI >>>which I described) some time ago that McKinley would weigh in at 600 -s 700eJ >>>SPECint2K (and most likely in the middle of that range), and I stand by itH >>>(unless it gets delayed so long that Intel can skip the first releaseC >>>entirely and go directly to what would have been the first majorEH >>>post-release process tweak - which is looking increasingly possible). ThegJ >>>best USIII SPECint2K currently is 610, but since such values do tend to >>>i >> rise  >>G >>>as new configurations appear I'd say there's a distinct possibility,t thoughJ >>>perhaps not a better-than-even chance, that if McKinley doesn't in fact >>>O >> wait1 >>K >>>for a process-tweak before releasing it will at introduction have a hard * >>>time equalling USIII's SPECint2K speed. >>>e >>>e >>L >> So there you go.  Assuming your predictions are right, McKinley will beatH >> USIII (and even your outside estimate of USIII getting faster doesn't takeL >> into account the tricked up compiler that caused the temportary "upgrade" of >> USIII speed). >> >o >mA >There you go again posting about something you don't understand.  >sD >1. The optimisation used by Sun only effected SPECfp note that BillG >is talking about SPECint. Even you should be aware of the differences.l >l  H It should beat Sparc using any measurment.  Heck, an old guy with a hand1 calculator will give it a good run for the money.k  G >2, It wasn't a trick and if you think it was perhaps you could back up>= >your claim with evidence other than suppostion on your part.E >w  L They tricked up the computer to beat a specific test.  It wont take long forF everyone else to bite te bullet and add the same optimization to their
 compilers.  K There was no leap in hardware speed, and almost no user code will be fasterm because of the trick.    >rI >> So IA64 systems will at minimum be performance competetive with USIII,l andx4 >> from what I understand will be priced much lower. >> >fF >This would have been an interesting point had your previous ones been* >correct since they were not it isn't :):) >p  H Alright, let's ignore the future, and talk about the present.  Why wouldF anyone run slowaris on a uniprocessor Sparc when an IA32 is faster and cheaper?  = Eventually, even Sun users will wake up and smell the coffee.    ------------------------------  # Date: Tue, 07 May 2002 17:10:49 GMT-* From: "Bill Todd" <billtodd@metrocast.net>0 Subject: Re: SKC Morphs Again... We're Now SKHPCA Message-ID: <tUTB8.101774$v7.8386910@bin6.nnrp.aus1.giganews.com>D  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message3 news:fzTB8.33$uF5.390298@cacnews.cac.cpqcorp.net...a8 > Andrew Harrison SUNUK Consultancy wrote in message ... > >e > >  > >Fred Kleinsorge wrote:r   ...e  I > >> So there you go.  Assuming your predictions are right, McKinley willa beatJ > >> USIII (and even your outside estimate of USIII getting faster doesn't > takeD > >> into account the tricked up compiler that caused the temportary	 "upgrade"S > of > >> USIII speed). > >> > >p > > C > >There you go again posting about something you don't understand.  > > F > >1. The optimisation used by Sun only effected SPECfp note that BillI > >is talking about SPECint. Even you should be aware of the differences.i > >s >., > It should beat Sparc using any measurment.  J Not only questionable (memory access latency and perhaps bandwidth as wellL come immediately to mind, SPARC having on-chip memory glue today that hasn'tB yet appeared in any Itanic forecast - right through 2004) but alsoG irrelevant to Andrew's comment (which was specifically about your gaffer above).e     Heck, an old guy with a hand3 > calculator will give it a good run for the money.t  - Perhaps you're confusing SPARC with Merced...t   ...t   > Why woulduH > anyone run slowaris on a uniprocessor Sparc when an IA32 is faster and
 > cheaper?  H A better question is why anyone would run *any* OS on Itanic when HammerG (and for a while Alpha) will be both faster and cheaper (and most other K competition at least one of those two).  I guess if you want to run VMS you4G won't have much choice after a while, but most other Itanic OSs will benF available elsewhere (either natively or in some similar form of Unix).   - bill   ------------------------------  $ Date: Tue, 7 May 2002 07:57:44 -0700# From: "Tom Linden" <tom@kednos.com>m Subject: smtp.config ?9 Message-ID: <CIEJLCMNHNNDLLOOGNJIEENEEOAA.tom@kednos.com>n  5 The documentation is terse if not condensed, but I am 8 wondering if there is a more complete description on the9 usage of the fields and their effect on how smtp behaves,s$ perhaps an overall logic flow graph?  3 Also is there any syntax checking done? If so, how?   ? And also, just curious why  the tcpip directories are scatterede@ about, dir sys$sysdevice:[000000...]tcpip$*.dir, some are at the8 root level and the others in [sys0] and [sys0.syscommon] ---t& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002   ------------------------------  + Date: Tue, 07 May 2002 17:22:22 +0100 (MET)-9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>7 Subject: Re: smtp.config ?; Message-ID: <01KHGCTFKSWI8Y8ZDE@sysdev.deutsche-boerse.com>0  7 > The documentation is terse if not condensed, but I am-: > wondering if there is a more complete description on the; > usage of the fields and their effect on how smtp behaves,c& > perhaps an overall logic flow graph? > 5 > Also is there any syntax checking done? If so, how?  > A > And also, just curious why  the tcpip directories are scatteredvB > about, dir sys$sysdevice:[000000...]tcpip$*.dir, some are at the: > root level and the others in [sys0] and [sys0.syscommon]  C I asked a similar question a while back and never got any response.o  H If you have a pretty straightforward setup, then TCPIP$CONFIG and TCPIP C SET CONFIGURATION SMTP are (fairly) straightforward and do what is 5 needed.-  G However, if a machine has several CNAME aliases, if /SUBSTITUTE_DOMAIN oH is being used (incoming? outgoing?), if MX records are in use etc, then A often SMTP will not work when all other protocols will.  This is tF definitely due to some sort of checking, but I would like to know, in , the sense of a flow chart, how this is done.  I For example, to allow the machine to receive email for several different gH addresses, aliases in the LOCAL TCPIP$HOSTS.DAT, entries in a text file I (the name escapes me now) or (allegedly---never tried this myself) LOCAL l MX entries are needed.  B The situation with SMTP is more complex since one has to consider I various combinations of /[NO]RELAY and various names in the To: field of vH the email.  With other protocols, there is no relay function, so if the ) machine is reached at all, things are OK.a   ------------------------------  $ Date: Tue, 7 May 2002 08:48:04 -0700# From: "Tom Linden" <tom@kednos.com>i Subject: RE: smtp.config ?9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGENHEOAA.tom@kednos.com>    >-----Original Message-----IA >From: Phillip Helbig [mailto:HELBPHI@sysdev.deutsche-boerse.com] $ >Sent: Tuesday, May 07, 2002 9:22 AM >To: Info-VAX@Mvb.Saic.Com >Subject: Re: smtp.config ?a >s >r8 >> The documentation is terse if not condensed, but I am; >> wondering if there is a more complete description on the-< >> usage of the fields and their effect on how smtp behaves,' >> perhaps an overall logic flow graph?d >>6 >> Also is there any syntax checking done? If so, how? >>B >> And also, just curious why  the tcpip directories are scatteredC >> about, dir sys$sysdevice:[000000...]tcpip$*.dir, some are at thes; >> root level and the others in [sys0] and [sys0.syscommon]o > D >I asked a similar question a while back and never got any response. >G6 I saw that, and I was watching for a response as well.  H >If you have a pretty straightforward setup, then TCPIP$CONFIG and TCPIPC >SET CONFIGURATION SMTP are (fairly) straightforward and do what isv >needed. >rG >However, if a machine has several CNAME aliases, if /SUBSTITUTE_DOMAINnH >is being used (incoming? outgoing?), if MX records are in use etc, thenA >often SMTP will not work when all other protocols will.  This is F >definitely due to some sort of checking, but I would like to know, in- >the sense of a flow chart, how this is done.f >aI >For example, to allow the machine to receive email for several different H >addresses, aliases in the LOCAL TCPIP$HOSTS.DAT, entries in a text fileI >(the name escapes me now) or (allegedly---never tried this myself) LOCAL) >MX entries are needed.   J Since this file is generated from scripts, unlike other systems, you can't edit. it.  I think this was a wrong design decision.   > B >The situation with SMTP is more complex since one has to considerI >various combinations of /[NO]RELAY and various names in the To: field of H >the email.  With other protocols, there is no relay function, so if the* >machine is reached at all, things are OK. >t >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002a >W ---e& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002   ------------------------------   Date: 7 May 2002 05:50:43 -0700 4 From: francesco.gennai@iat.cnr.it (Francesco Gennai)+ Subject: software to produce histograms (?)e< Message-ID: <72f5654.0205070450.48fd0918@posting.google.com>  3 Currently we are using GNUPLOT on Alpha/OpenVMS 7.3lT to produce some monthly Postscript or GIF images reporting email traffic statistics., It seems that GNUPLOT is more approriate for scientific applications.7 I would know if there are any other software on OpenVMSi: platform that I could try to produce "offline" (batch job)1 such histograms, charts, and save it us an image.n  	 Francesco>   ------------------------------  $ Date: Tue, 7 May 2002 10:44:22 -0400# From: "Dan Allen" <dallen@nist.gov>r6 Subject: SOT: Yo Andrew, you guys on a roll this week?: Message-ID: <NEBBIALHDHJMJINPGMOAKEFOEJAA.dallen@nist.gov>   ----- Original Message -----% From: "FedCIRC" <fedcirc@fedcirc.gov>i To: <FedCIRC-Community:>" Sent: Monday, May 06, 2002 4:45 PMD Subject: FedCIRC Advisory FA-2002-11 Heap Overflow in Cachefs Daemon
 (cachefsd)     >t >c$ > -----BEGIN PGP SIGNED MESSAGE----- >>H > FedCIRC Advisory FA-2002-11 Heap Overflow in Cachefs Daemon (cachefsd) >o( >    Original release date: May 06, 2002 >    Last revised: >    Source: CERT/CC >>F >    A complete revision history can be found at the end of this file. >e >   Systems Affected >(I >      * Sun Solaris 2.5.1, 2.6, 7, and 8 (SPARC and Intel Architectures)o >a
 > Overview >dK >    Sun's  NFS/RPC  file  system  cachefs daemon (cachefsd) is shipped andnK >    installed  by default with Sun Solaris 2.5.1, 2.6, 7, and 8 (SPARC and K >    Intel  architectures).  A remotely exploitable vulnerability exists inrK >    cachefsd that could permit a remote attacker to execute arbitrary codelK >    with  the  privileges of the cachefsd, typically root. The CERT/CC haseK >    received  credible  reports  of  scanning  and exploitation of Solarisi >    systems running cachefsd. >  > I. Description >nK >    A  remotely  exploitable  heap overflow exists in the cachefsd programwK >    shipped and installed by default with Sun Solaris 2.5.1, 2.6, 7, and 8IK >    (SPARC   and   Intel  architectures).  Cachefsd  caches  requests  foriK >    operations on remote file systems mounted via the use of NFS protocol.fK >    A  remote  attacker  can  send  a  crafted RPC request to the cachefsda* >    program to exploit the vulnerability. >p> >    Logs of exploitation attempts may resemble the following: >tG > May 16 22:46:08 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd: " > Segmentation Fault - core dumped >v; > May 16 22:46:21 victim-host last message repeated 7 timest >kG > May 16 22:46:22 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:n > Bus Error- core dumped >oG > May 16 22:46:24 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:i" > Segmentation Fault - core dumped >sG > May 16 22:46:56 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:t > Bus Error - core dumped  >s: > May 16 22:46:59 victim-host last message repeated 1 time > G > May 16 22:47:02 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:0" > Segmentation Fault - core dumped >o; > May 16 22:47:07 victim-host last message repeated 3 timesc >iG > May 16 22:47:09 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:m > Hangup >tG > May 16 22:47:11 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:i" > Segmentation Fault - core dumped >DK >    According  a  Sun  Alert Notification, failed attempts to exploit thishK >    vulnerability  may  leave  a core dump file in the root directory. ThedK >    presence  of the core file does not preclude the success of subsequentoK >    attacks.  Additionally,  if  the  file  /etc/cachefstab exists, it maye >    contain unusual entries.l >h: >    This issue is also being referenced as CAN-2002-0085: > B >      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0085 >rK >    The  Australian  Computer  Emergency  Response Team has also issued ani? >    advisory related to incident activity exploiting cachefsd:  > L >   http://www.auscert.org.au/Information/Advisories/advisory/AA-2002.01.txt >d > II. Impact > K >    A  remote  attacker may be able to execute code with the privileges ofo* >    the cachefsd process, typically root. >  > III. Solutioni > # >    Apply a patch from your vendor- >-K >    Appendix A contains information provided by vendors for this advisory.  >nK >    If  a  patch  is not available, disable cachefsd in inetd.conf until aC >    patch can be applied. >0K >    If  disabling  the  cachefsd  is  not  an option, follow the suggestede. >    workaround in the Sun Alert Notification. >m" > Appendix A. - Vendor Information >0K >    This  appendix  contains  information  provided  by  vendors  for thisbK >    advisory.  As  vendors  report new information to the CERT/CC, we willuK >    update this section and note the changes in our revision history. If aMK >    particular  vendor is not listed below, please check the Vulnerabilitye6 >    Note (VU#635811) or contact your vendor directly. >t	 >     IBMg >eC >      IBM's AIX operating system, all versions, is not vulnerable.t >8	 >     SGIS >sF >      SGI does not ship with SUN cachefsd, so IRIX is not vulnerable. >e	 >     Sune >rJ >      See     the     Sun     Alert     Notification     available     atG >      http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F44309.hF >    _________________________________________________________________ >pK >    The CERT/CC acknowledges the eSecurity Online Team for discovering andaK >    reporting  on this vulnerability and thanks Sun Microsystems for their  >    technical assistance.F >    _________________________________________________________________ >u/ >    Feedback  can  be directed to the authors:r, >    Jason A. Rafail and Jeffrey S. HavrillaK >    ______________________________________________________________________e >c% >    This document is available from:U7 >    http://www2.fedcirc.gov/advisories/FA-2002-11.htmlrK >    _______________________________________________________________________ >n > FedCIRC Contact Informationg >  >    Email: fedcirc@fedcirc.govp> >           Phone: +1 888-282-0870 (24-hour toll-free hotline)4 >           Phone: +1 703-375-2222 (24-hour hotline)  >           Fax: +1 703-375-2427 >>H >    FedCIRC personnel answer the hotline 24 hours a day, 7 days a week. >R >     Using encryption >gK >    We  strongly  urge you to encrypt sensitive information sent by email.e) >    Our public PGP key is available froms >s& >    http://www2.fedcirc.gov/keys.html > K >    If  you  prefer  to  use DES, please call the FedCIRC hotline for more  >    information.  >>" >     Getting security information >rK >    FedCIRC publications and other security information are available from  >    our web sitei >r >    http://www.fedcirc.gov/ >eK >    FedCIRC  (Federal Computer Incident Response Center) provides securitytK >    services  to U.S. Federal civilian agencies. FedCIRC is managed by thedK >    U.S.  General  Services  Administration.  The CERT Coordination CentercH >    performs incident and vulnerability analysis and issues advisories. > K >    *  "CERT"  and  "CERT  Coordination Center" are registered in the U.S.n! >    Patent and Trademark Office.oK >    ______________________________________________________________________  >i >    NO WARRANTYK >    Any  material furnished by Carnegie Mellon University and the SoftwaretK >    Engineering  Institute  is  furnished  on  an  "as is" basis. Carnegie K >    Mellon University makes no warranties of any kind, either expressed oreK >    implied  as  to  any matter including, but not limited to, warranty ofyK >    fitness  for  a  particular purpose or merchantability, exclusivity ordK >    results  obtained from use of the material. Carnegie Mellon UniversityaK >    does  not  make  any warranty of any kind with respect to freedom fromb2 >    patent, trademark, or copyright infringement. >i/ >    Copyright 2002 Carnegie Mellon University.  >l >    Revision HistoryC& >       May 06, 2002:  Initial release >e > -----BEGIN PGP SIGNATURE-----c > Version: PGP 6.5.8 >eB > iQEVAwUBPNbqgIBMzw7XZGn/AQEJwggAgEFMO8YIsP/0I2XHStYlZLJDoBx5jB9MB > MuUWsTtYBbrnoyu6sJhpo3GjshT+k2k5kj9PjbmFLmqfUShmM3G/W3yc21D2w8M3B > 9ogIpwBZXAYIEiLRKkqFdBqcUn2dE8mixAOW3AvrqZb54CwQxkVFLVshkYHIRSsNB > lJz7zfAaw7bDqXTc9OrI/TBFdkPR9rHBJpyQgtxzKzThcawwTu+LfEl8ZlxQizaOB > Ofu1cA/4phBe4WO/KnSQKmKACHhFZsoO2hSTdRwx9t3hq9zaoleS2oB1EHHspuqm: > k6LqSobTuYsD3sHE2c9bGPyNj4KUkyLpYicYRxzPEn3RWtDQbebvzw== > =MrUen > -----END PGP SIGNATURE-----u >    ------------------------------  % Date: Tue, 07 May 2002 09:33:19 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>o3 Subject: Re: UK/EU OpenVMS job market: non-existantf) Message-ID: <3CD7833F.D115F948@gtech.com>t   Chris Bardell wrote:! > If anyone has a view on this...i > F > Does anyone think the job market for OpenVMS tech support / sys mgrs< > will ever take off again, specifically in the UK & Europe? > E > One month into the new financial year, but hardly any upturn in thee  > amount of vacancies available. > E > Any light at the end of the tunnel / recession / whatever? Or is itBD > that, by & large, OpenVMS boxes just run too damn well and require
 > less staff?    I think it is a complex matter.0  6 The economic upturn may easily wait 6-12 months before@ materializing and many companies are reluctant investing/hiring.  3 Many IT & Telecom companies has been specially hardo hit and ar even more reluctant.   9 In general the VMS base has shrinked a lot. The number of 4 VMS capable people has also shrinked, so it is not a< demand>supply problem, but it is often a geographic problem: job at X people at Y.n  : To even worsen things for VMS, then a lot of companies are( waiting to see what HP will do with VMS.   Arne   ------------------------------   Date: 7 May 2002 08:24:40 -0500n- From: koehler@encompasserve.org (Bob Koehler)i Subject: Re: USB on OpenVMSt3 Message-ID: <7viwdx8q4kkL@eisner.encompasserve.org>.  q In article <VIvB8.19$S65.377946@cacnews.cac.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:e  , > Eh?  What's a two-cylinder VSXXX-AA mouse? >   I    The original round DEC corporate mouse (also known as the hockey-puck)t<    was built in two styles, both under part number VSXXX-AA.  E    Some had a traditional ball underneath with all the usual problemsaB    of picking up hair and debris and handing it off to the rollers
    inside.  B    The ones I prefer (I'm using one right now) have a vertical andA    horizontal "cylinder".  That is a pair of rollers to track theuB    two motions that the rollers inside a ball-based mouse use, but?    instead of following a ball the rollers are tiltled and drag +    directly on the surface below the mouse.n  C    Simple, direct, and no need to clean it.  It's stamped with whatg0    appears to be the manufacturer's name Hawley.   ------------------------------   Date: 7 May 2002 08:28:54 -0500l- From: koehler@encompasserve.org (Bob Koehler)m Subject: Re: USB on OpenVMS-3 Message-ID: <TXzenYJhocPB@eisner.encompasserve.org>5  q In article <icwB8.20$rZ4.124025@cacnews.cac.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:o > & > Oh.  Yuck.  I hated that mechanism.   F    Why?  It was the first mouse design I ever saw that never had to beG    cleaned.  the only trouble I've ever had with one is that my current E    mouse sometimes double clicks on release of the right button (its'n    getting old).  F    OK, On a USB I'd settle for a nice padless optical mouse, just likeE    the one on my Mac.  It's as trouble free as the two-cylinder modelv&    so far, and has fewer moving parts.   ------------------------------  # Date: Tue, 07 May 2002 14:26:44 GMTt5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>3 Subject: Re: USB on OpenVMSl9 Message-ID: <EuRB8.23$TE5.360500@cacnews.cac.cpqcorp.net>a  K Interesting, since I think I wrote the code from the logitech documentationv ;-)s    # Keith A. Lewis wrote in message ...g6 >Bart Zorn <B.Zorn@xs4all.nospam.nl> writes in articleJ <3CD68BE4.3090607@xs4all.nospam.nl> dated Mon, 06 May 2002 15:57:56 +0200: >>Fred Kleinsorge wrote:. >>> Eh?  What's a two-cylinder VSXXX-AA mouse? >>> J >>> The mouse will be a standard 3-button USB mouse.  As an added bonus, I put D >>> support for the thumbwheel in for anyone that wants to plug in a
 thumbwheel
 >>> mouse. >>A >>There were two versions of the VS-XXX-AA mouse. One had the thecG >>traditional ball mechanism which we all hate because it collects dirtsF >>and therefore it becomes inaccurate over time. The other version youI >>could call "two-cylinder". It had two tilted shafts with a little wheelII >>each wich did the motion sensing. The only dirt they collected remaineda5 >>on the outside of the mouse and was easily cleaned.N >>I >>I seem to remember that Digital won an Industry Prize with it. ProbablyXC >>they were so shocked by this prize that they dropped the product.e >rF >I tried a Google search on "two cylinder mouse" and came up basically empty.F >It sounds interesting, I'd like to read more if anybody has a link... >lK >Of course, no matter how good it is mechanically I can't see it collectingaJ >less dirt than a modern optical mouse.  I would love to be able to plug a( >USB optical mouse into an alphastation. >m@ >And a USB keyboard too.  I tried a Logitech PS-2 keyboard on myJ >Alphastation, and it hung twice in 20 minutes.  I'm hoping the Digital PC1 >keyboard I just bought on ebay will fare better.i > , >--Keith Lewis              klewis$mitre.org? >The above may not (yet) represent the opinions of my employer.-   ------------------------------  # Date: Tue, 07 May 2002 14:28:53 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>g Subject: Re: USB on OpenVMSL9 Message-ID: <FwRB8.24$PE5.356510@cacnews.cac.cpqcorp.net>-  I I hated it because I had problems with "accurate" tracking on a number ofn: surfaces.  In fact, I ended up using it on a pad of paper.        Bob Koehler wrote in message ...L >In article <icwB8.20$rZ4.124025@cacnews.cac.cpqcorp.net>, "Fred Kleinsorge"% <kleinsorge@star.zko.dec.com> writes:- >>& >> Oh.  Yuck.  I hated that mechanism. >wG >   Why?  It was the first mouse design I ever saw that never had to betH >   cleaned.  the only trouble I've ever had with one is that my currentF >   mouse sometimes double clicks on release of the right button (its' >   getting old).r >oG >   OK, On a USB I'd settle for a nice padless optical mouse, just likenF >   the one on my Mac.  It's as trouble free as the two-cylinder model' >   so far, and has fewer moving parts.f >a   ------------------------------   Date: 7 May 2002 08:09:25 -0700e4 From: wcoltters@yahoo.com (Wilson Guerrero-Coltters)I Subject: Re: Using LD from OpenVMS 7.2-1 Installation CD, Can it be done?i= Message-ID: <ff6f1d30.0205070709.5123b103@posting.google.com>   s hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<p5EB8.54$Ji5.905319@cacnews.cac.cpqcorp.net>....v > In article <ff6f1d30.0205061314.314b7a11@posting.google.com>, wcoltters@yahoo.com (Wilson Guerrero-Coltters) writes: > A > :I would appreciate if someone can tell me if this is possible.  > E >   So if I understand correctly, you want to archive the contents ofeC >   your system disk to a sequential saveset created across severali* >   file-backed logical disk partitions.     EXACTLY! :-); Then I can burn the sequential savesets in the logical diskc= partitions to CDs. I already tested the procedure with online ; image backups, but the problem is the open files during theo= online backup. I would like to assure all or almost all filesn" are closed when I take the backup.   > Why?  You have no otheroC >   storage available to you, and no storage that can be transfered.& >   over onto this system temporarily?   EXACTLY! :)C@ Well, to be honest, we indeed have a spare IDE disk we used onceA to backup the system disk, so we can use it again. Also, we have -? an external SCSI tape drive but we don't have the proper cable iH yet to connect it to the SCSI connector on the backup of the alpha DS10.? You see, the whole idea is to explore the possibilities I have.    > 7 > :$ BACKUP/IMAGE $1$DIA0: LDA1:DIA0.SAV/SAV,LDA2: /LOGrA >   DIA0:?  I've not seen particularly many DSSI disks configurede" >   on an AlphaServer DS10 series.? >   Does this particular AlphaServer DS10 box have IDE or SCSI?l  @ IDE, and an SCSI controller (Symbios SYM8952U PCI to Ultra2 SCSI5 Host Adapter), but the disks are IDE. The line above OE was cutted and pasted from a VAX, where I was testing the procedure. r< Sorry if I made the thing confuse. The line would have to be1 $ BACKUP/IMAGE DQA0: LDA1:DIA0.SAV/SAV,LDA2: /LOG,= Also I forgot to mention we have to IDE disks, DQA0 and DQA1.-1 The sequential savesets would be created on DQA1.2   > H > :The problem is, LD is not on the installation CD as you already know.F > :So, if I make a copy of the installation CD, can I add the LD filesC > :to it, so I can use it when I boot from the CD? If so, I will bed > :able to load the driver withy > :   $ RUN SYS$SYSTEM:SYSGEN47 > :              CONNECT LDA0/NOADAPTER/DRIVER=LDDRIVERw8 > :if LDDRIVER (and LD by the way) is present on the CD?  H >   You could certainly tweak the distribution kit to your requirements, >   and burn your own CD-R.  > F >   I would also assume you might be able to connect the LDDRIVER fromI >   the target disk -- this approach could potentially also involve some sF >   "creative" remapping of some of the core SYS$ system logical namesE >   during the duration of the $$$ operations on the bootable CD-ROM.s  A Well, I think that would be extraordinarily beyond my scopes. ;-)    > G > :Any help ,suggestions, comments or critics will be very appreciated.  > $ >   This is ugly.  (You did ask. :-) > = > :If I have to RTFM o STFW, I would like someone to point mee > :to any related URL :-)b >  > D >   Since this whole sequence and this configuration is, well, ugly,? >   I'd probably simply do the backup "hot", after performing a C >   system shutdown and a minimal startup -- drop the saveset rightsD >   back onto the target system disk.  (Yes, some of the open files B >   on the system disk might not be consistently copied.  Then youC >   have to figure out how to get the saveset somewhere safe -- andr. >   more importantly, how to then restore it.)  C So, I assume there will no problem using LD from a minimal startup,  right?   > D >   If you DO create these disks and if you do create the sequentialD >   saveset, testing will be interesting -- if the test restoration 4 >   fails, well, you could clobber your system disk. > A >   If it were me, I'd scrounge another disk (or off-load anothernB >   disk temporarily), or I'd scrounge a tape...  Cheaper, easier, >   and more reliable... > P >  ---------------------------- #include <rtfaq.h> -----------------------------P >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    P >  --------------------------- pure personal opinion ---------------------------N >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com  ? Nothing but to thank you, David and Tom for the suggestions and:
 your time.   Regards,   Wilson.l   ------------------------------   Date: 7 May 2002 10:05:05 -0700a* From: john.krautkramer@micrel.com (Krauty) Subject: VAXELN Documentation7= Message-ID: <e721b46f.0205070905.5cdf4bd5@posting.google.com>a   Hi,t  F I need to develope in C on an old MicroVAX III running VAXELN V4.0 but< I have very limited documentation. Any ideas on where to get developers docs on this?  1 Specifically, I need to find the structure of thea! FILE$ATTRIBUTES_RECORD data type.o   Any help would be great!   Regards,   John   ------------------------------   Date: 7 May 2002 12:40:47 GMTd1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)i1 Subject: Re: VMS Bigots Unite To Form New Companyi, Message-ID: <ab8i0f$29os$1@info.cs.uofs.edu>  = In article <d7791aa1.0205050407.3a794231@posting.google.com>,N+  bob@instantwhip.com (Bob Ceculski) writes:r |>E |> and you think unix/linux is any better ... if so, I have a millionc? |> cert advisories to email to you ... sorry, vms stands alone!o  A No it doesn't.  RT-11, RSTS/E, RSX-11 and Primos all have exactlytA zero CERT advisories.  VMS has 10.  You loose.  Time to change to  a really secure OS, Bob.   bill   -- ,J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 7 May 2002 12:45:02 GMTs1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)w1 Subject: Re: VMS Bigots Unite To Form New Companye, Message-ID: <ab8i8e$29os$2@info.cs.uofs.edu>  3 In article <2DaKmADx6nxq@eisner.encompasserve.org>,f0  koehler@encompasserve.org (Bob Koehler) writes:k |> In article <d7791aa1.0205050407.3a794231@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:I |> >  G |> > and you think unix/linux is any better ... if so, I have a millioneA |> > cert advisories to email to you ... sorry, vms stands alone!  |>  F |>    Carefull, everytime someone mentions cert, it becoes a troll for
 |>    Andrew.S  E Why??  His OS isn't very secure either.  See my previous post on thisl subject!!      :-)   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   e   ------------------------------   Date: 7 May 2002 12:50:11 GMTn1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) 1 Subject: Re: VMS Bigots Unite To Form New Company_, Message-ID: <ab8ii3$29os$3@info.cs.uofs.edu>  , In article <3CD6D391.692B6A7C@videotron.ca>,0  JF Mezei <jfmezei.spamnot@videotron.ca> writes: |>J |> The assholes at Compaq should have clearly seen the mistake that costedO |> Digital's life. Compaq's stock ceased trading last friday. Obviously, Compaqv* |> didn't see the mistake and repeated it.  H Actually, CPQ and HPW both stopped trading last friday.  It is now HPQ!!   bill   -- mJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   n   ------------------------------  " Date: Tue, 7 May 2002 16:37:34 GMT- From: Terry C Shannon <shannon@world.std.com>r1 Subject: Re: VMS Bigots Unite To Form New CompanyaC Message-ID: <Pine.SGI.4.30.0205071222130.5595-100000@world.std.com>I  % On 7 May 2002, Bill Gunshannon wrote:t  . > In article <3CD6D391.692B6A7C@videotron.ca>,2 >  JF Mezei <jfmezei.spamnot@videotron.ca> writes: > |>L > |> The assholes at Compaq should have clearly seen the mistake that costedQ > |> Digital's life. Compaq's stock ceased trading last friday. Obviously, Compaqt, > |> didn't see the mistake and repeated it. >eJ > Actually, CPQ and HPW both stopped trading last friday.  It is now HPQ!!    E Not to put too fine of a point on it, but since the New HP officiallyrF launched on Tuesday May 7, and Compaq shuffled off its mortal coils onH Friday last, the Compaq contingent of the New HP was in a state of limbo on Monday May 6.   ------------------------------   Date: 7 May 2002 17:40:23 GMT_1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) 1 Subject: Re: VMS Bigots Unite To Form New Companyv, Message-ID: <ab93i7$2mc2$1@info.cs.uofs.edu>  C In article <Pine.SGI.4.30.0205071222130.5595-100000@world.std.com>,n0  Terry C Shannon <shannon@world.std.com> writes: |> s |> e( |> On 7 May 2002, Bill Gunshannon wrote: |> u1 |> > In article <3CD6D391.692B6A7C@videotron.ca>,a5 |> >  JF Mezei <jfmezei.spamnot@videotron.ca> writes:d |> > |>sO |> > |> The assholes at Compaq should have clearly seen the mistake that costednT |> > |> Digital's life. Compaq's stock ceased trading last friday. Obviously, Compaq/ |> > |> didn't see the mistake and repeated it.t |> >M |> > Actually, CPQ and HPW both stopped trading last friday.  It is now HPQ!!  |> i |> lH |> Not to put too fine of a point on it, but since the New HP officiallyI |> launched on Tuesday May 7, and Compaq shuffled off its mortal coils onbK |> Friday last, the Compaq contingent of the New HP was in a state of limboF |> on Monday May 6.Z |> Q  G Then somebody needs to inform Yahoo and probably the NYSE (as I am sure8I that's where Yahoo gets their data) because my graphs show a whole day ofm+ trading for HPQ on Monday, 6 May 2002.  :-)n   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   e   ------------------------------  % Date: Tue, 07 May 2002 11:42:41 +0100n( From: Nic Clews <sendspamhere@127.0.0.1>? Subject: Re: Why is security so important in a VMS environment?l) Message-ID: <3CD7AFA1.7EC0C35F@127.0.0.1>K   Rich wrote:  > 4 > Why is security so important in a VMS environment?  < It was designed in from the ground up as opposed to being an
 afterthought.h  D In summary I guess they decided what they needed to protect, and didC that job well, then did the job of securing access into any 'mode'*t( which could allow access to those areas.  C The great trick was making it so that from the program level thingssG could be accessed with perfect safety and control, so the high level ofsG security does not hinder a non privileged user from performing anythings; that a system manager allows / application designer allows.a  C * mode = basic login thru to being in privileged mode under programg) control. Mixed use of the word and a pun.   . (Question answered as I thought you meant it).   = > Why did VMS become a dominant Operating System in the early-+ > 80s and 90s and then fall into obscurity?2  B There was nothing around doing what VMS was doing at the time, andD people were prepared to pay for it. These days, systems are tuppenceD ha'penny for a dozen and average Joe Systembuyer hasn't a clue about> what is in fact important when investing in a computer system.  C Properly set up systems far outshine what many other so called highED availability systems are capable of (expect perhaps for the likes ofD Himalaya, but that has it's own interesting set of limitations - andC cost). VMS allows itself to be run fairly badly set up as well, and E tends to run and run. Also it doesn't have a point and shoot gimmicky ? interface that impresses pointy haired bosses, and belongs in anG datacentre, not really on a portable. The net effect is old systems runtD and run, no need for upgrade, no one is employed with an appropriateE skillset to look after the systems, and when the brown stuff hits theaH whirly air mover, VMS gets the blame cos they employed an incompetent in the first place.  H For some bizarre reason, viruses and other breaches, as well as needs 25H minesweeper and solitaire consultants to tend to idiotic, sometimes selfD induced faults, is overlooked when picking platforms for processing.  H I'd agree it is partly marketing, but I feel that volume sales should beH allowed to bring the cost down. To those I have introduced to VMS from aE Microsoft or UNIX users who have open minds (a rare thing), they haves never failed to be impressed.n  E I'm not sure if this answers what you're looking for... But the aboveh
 leads onto  C UNIX - a so-called open operating system used by people with closeds minds.  E A bit more waffle. I've used quite a number of operating systems, andsC some have their strengths over VMS in some applications. The gap iscG getting narrow though, the only things that may just be off-putting are-C firstly, knowing of its existence, and secondly the apparently highl@ initial pricing and being unable to have an appreciation of TCO.  F Finally, Thank you for asking the questions, I hope this inspires yourF curiosity. Ask here, you'll get answers, but there's an FAQ linked off http://www.openvms.compaq.com/   -- g( Regards, Nic Clews CSC Computer Sciences nclews at csc dot com3   ------------------------------  # Date: Tue, 07 May 2002 14:53:51 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>r? Subject: Re: Why is security so important in a VMS environment? 9 Message-ID: <3URB8.27$UD5.327745@cacnews.cac.cpqcorp.net>   A David J. Dachtera wrote in message <3CD7379F.865C6A0A@fsi.net>...s >Rich wrote: >>5 >> Why is security so important in a VMS environment?c >>D >Security is important in *ANY* environment. In VMS, however, it wasG >designed in from the start, not added on as an after thought as is the  >case with Micro$lop and UN*X. >    Agreed.s  > >> Why did VMS become a dominant Operating System in the early, >> 80s and 90s and then fall into obscurity? >t >Say: "marketing". >a   Simplistic.d  K The VAX and VMS came about during a time when the "super-mini" was stealinglH new business from the traditional mainframe market.  Most customers wereA using custom written software, and they had their own programmingsL departments.  It was fast, and reliable.  It had great tools, and libraries.  L Where did it all go wrong?  Well, the VAX architecture ran out of gas.  RISCK systems came along that were faster and cheaper.  At first this just pulledtA away the technical market - who could cope with the obscurity andkF unreliability of UNIX, because what they needed was *speed*.  Then theB commercial side started to erode.  VMS stubbornly clung to the VAXJ architecture until it had already begun a substantial slide in new sales -H the architecture that could have been the basis of VMS's replacement wasJ cancelled, and it's architect took his marbles to Microsoft, and wrote NT.I DEC neglected the educational market that it was once big in, assuming itUI was simply a profit center - and igoring the fact that it is also primary C indoctination for the future high-priests and decision makers.  ThebI replacement architecture for VAX (Alpha) was started too late, and wasn'toK binary compatable, and in a declining market - many ISV's chose not to movecF to the new architecture.   At the same time, the joke x86 architectureK started eating things from the bottom up.  Yes, it was a joke - but anybodyuL could afford one, and lots of useful software started being written.  Entire@ businesses could run on out-of-the-box software on a handfull ofI decentralized PCs, instead of having a programming staff, and centralizedK computing resources.  I When the VAX and VMS started to falter, DEC became unfocused.  Instead of I having an entire corporation that knew exactly what to sell (VAX/VMS), itrG went into a mode of trying to figure out how to replace VAX/VMS.  UNIX,0L Windows, NT - we spread our resources that once were focused on VAX/VMS intoH trying to be-all to everyone and everything, succeeding at none (few) ofL them.  Something internal to DEC also helped things along.  When VMS was theI 800-lb gorilla, it threw it's weight around in the company, and made manycA enemies along the way.  When it slipped, the knives all came out.o  K So.  Now we are here with a still good/great basic OS product - which stilldH has many of the more popular OS's beat in reliability and functionality.L But it has shrunk to a small market.  But's it's a little like a BetaMax VCRJ in a world full of VHS.  It's better, but the competition is cheaper, moreJ available, and is getting better all the time - and it's where all the newJ media comes out for (and you have to copy someones VHS tape to Beta to use it on your machine).  B The good news, is that the "media" is changing, and becomming lessD architecture and OS specific - JAVA and web enabled technologies areC beginning to make the underlying architecture transparent.  So, the K qualities of VMS that make it secure and reliable, may make it a choice for?L a new generation.  We have a way to go in some areas to make this a reality,H but we're on our way... and the CPU isn't really important to us either.  Alpha or IA64.  It's just a CPU.   ------------------------------  $ Date: Tue, 7 May 2002 10:19:20 -05001 From: "Dave Gudewicz" <david.gudewicz@abbott.com>i? Subject: Re: Why is security so important in a VMS environment?M8 Message-ID: <ab8rdt$3h4$1@fizban.fizban.pprd.abbott.com>  I Thanks Fred.  IMO a very good summary, with a glimmer of hope at the end.S   Dave...   @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message3 news:3URB8.27$UD5.327745@cacnews.cac.cpqcorp.net...UC > David J. Dachtera wrote in message <3CD7379F.865C6A0A@fsi.net>...a > >Rich wrote: > >>7 > >> Why is security so important in a VMS environment?I > > F > >Security is important in *ANY* environment. In VMS, however, it wasI > >designed in from the start, not added on as an after thought as is theA  > >case with Micro$lop and UN*X. > >o > 	 > Agreed.o >Q@ > >> Why did VMS become a dominant Operating System in the early. > >> 80s and 90s and then fall into obscurity? > >s > >Say: "marketing". > >  >f
 > Simplistic.  >ID > The VAX and VMS came about during a time when the "super-mini" was stealingJ > new business from the traditional mainframe market.  Most customers wereC > using custom written software, and they had their own programming C > departments.  It was fast, and reliable.  It had great tools, ando
 libraries. >,H > Where did it all go wrong?  Well, the VAX architecture ran out of gas. RISCF > systems came along that were faster and cheaper.  At first this just pulledC > away the technical market - who could cope with the obscurity andSH > unreliability of UNIX, because what they needed was *speed*.  Then theD > commercial side started to erode.  VMS stubbornly clung to the VAXL > architecture until it had already begun a substantial slide in new sales -J > the architecture that could have been the basis of VMS's replacement wasL > cancelled, and it's architect took his marbles to Microsoft, and wrote NT.K > DEC neglected the educational market that it was once big in, assuming itlK > was simply a profit center - and igoring the fact that it is also primary E > indoctination for the future high-priests and decision makers.  The K > replacement architecture for VAX (Alpha) was started too late, and wasn'tsH > binary compatable, and in a declining market - many ISV's chose not to moveH > to the new architecture.   At the same time, the joke x86 architectureE > started eating things from the bottom up.  Yes, it was a joke - buta anybodysF > could afford one, and lots of useful software started being written. EntireB > businesses could run on out-of-the-box software on a handfull ofK > decentralized PCs, instead of having a programming staff, and centralized  > computing resources. > K > When the VAX and VMS started to falter, DEC became unfocused.  Instead oftK > having an entire corporation that knew exactly what to sell (VAX/VMS), it-I > went into a mode of trying to figure out how to replace VAX/VMS.  UNIX,iI > Windows, NT - we spread our resources that once were focused on VAX/VMS- intoJ > trying to be-all to everyone and everything, succeeding at none (few) ofJ > them.  Something internal to DEC also helped things along.  When VMS was theuK > 800-lb gorilla, it threw it's weight around in the company, and made many,C > enemies along the way.  When it slipped, the knives all came out.: >0G > So.  Now we are here with a still good/great basic OS product - whichu stilloJ > has many of the more popular OS's beat in reliability and functionality.J > But it has shrunk to a small market.  But's it's a little like a BetaMax VCRvL > in a world full of VHS.  It's better, but the competition is cheaper, moreL > available, and is getting better all the time - and it's where all the newL > media comes out for (and you have to copy someones VHS tape to Beta to use > it on your machine). > D > The good news, is that the "media" is changing, and becomming lessF > architecture and OS specific - JAVA and web enabled technologies areE > beginning to make the underlying architecture transparent.  So, the2I > qualities of VMS that make it secure and reliable, may make it a choice  fordE > a new generation.  We have a way to go in some areas to make this ar reality,J > but we're on our way... and the CPU isn't really important to us either." > Alpha or IA64.  It's just a CPU. >l >  >o >R >d   ------------------------------  # Date: Tue, 07 May 2002 16:33:41 GMTS* From: "Bill Todd" <billtodd@metrocast.net>? Subject: Re: Why is security so important in a VMS environment?cA Message-ID: <FlTB8.96019$Ii2.8532096@bin2.nnrp.aus1.giganews.com>i  < "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message2 news:ab8rdt$3h4$1@fizban.fizban.pprd.abbott.com...K > Thanks Fred.  IMO a very good summary, with a glimmer of hope at the end.   H Since the 'glimmer' referred to Itanic, the old 'light at the end of the tunnel' quip seems appropriate.>   - bill   ------------------------------  # Date: Tue, 07 May 2002 17:02:32 GMTg5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>4? Subject: Re: Why is security so important in a VMS environment?i9 Message-ID: <IMTB8.38$AG5.406576@cacnews.cac.cpqcorp.net>t   Bill Todd wrote in message ... >>= >"Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message 3 >news:ab8rdt$3h4$1@fizban.fizban.pprd.abbott.com...,L >> Thanks Fred.  IMO a very good summary, with a glimmer of hope at the end. > I >Since the 'glimmer' referred to Itanic, the old 'light at the end of then  >tunnel' quip seems appropriate. >m   Re-read it.  Ploink.   ------------------------------  # Date: Tue, 07 May 2002 17:45:28 GMT.* From: "Bill Todd" <billtodd@metrocast.net>? Subject: Re: Why is security so important in a VMS environment?-A Message-ID: <YoUB8.96697$Ii2.8591981@bin2.nnrp.aus1.giganews.com>t  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message3 news:IMTB8.38$AG5.406576@cacnews.cac.cpqcorp.net...f >s  > Bill Todd wrote in message ... > >6? > >"Dave Gudewicz" <david.gudewicz@abbott.com> wrote in messagee5 > >news:ab8rdt$3h4$1@fizban.fizban.pprd.abbott.com...eI > >> Thanks Fred.  IMO a very good summary, with a glimmer of hope at theg end. > >yK > >Since the 'glimmer' referred to Itanic, the old 'light at the end of the " > >tunnel' quip seems appropriate. > >d >  > Re-read it.  Ploink.  J I have no problem with Fred killfiling me, since his responses to my postsL are usually content-free anyway.  However, I have no intention of killfilingK him, since his posts often merit a response (unfortunately, most frequentlyd& these days because they're so flawed).  I However, if he believes that the 'glimmer at the end' did *not* contain anH reference to Itanic (as I stated it did), then he's the one who needs to re-read it.n   - bill   ------------------------------   Date: 7 May 2002 08:41:37 -0500s- From: koehler@encompasserve.org (Bob Koehler)7) Subject: www.compaq.com is link to hp.comn3 Message-ID: <ZRIFM7Vtdmk9@eisner.encompasserve.org>C  F    Well, there it is.  Enter www.compaq.com and end up a hp.com.  Even"    www.digital.com gets you there.  @    I could find VMS by following the Software and OS link, but I5    couldn't find Alpha by following the servers link.g   ------------------------------  $ Date: Tue, 7 May 2002 09:01:02 -05001 From: "Dave Gudewicz" <david.gudewicz@abbott.com>a- Subject: Re: www.compaq.com is link to hp.coml8 Message-ID: <ab8mr4$2og$1@fizban.fizban.pprd.abbott.com>  G My first impressions after poking around the new hp.com site from a VMS  perspective.  E VMS still in the closet with the door shut.  No sign of door opening.j  L I await the new h-p webcast scheduled for later today with hopes of changing my first impression.   Dave...S  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:ZRIFM7Vtdmk9@eisner.encompasserve.org...> > H >    Well, there it is.  Enter www.compaq.com and end up a hp.com.  Even$ >    www.digital.com gets you there. ><B >    I could find VMS by following the Software and OS link, but I7 >    couldn't find Alpha by following the servers link.s >n   ------------------------------  + Date: Tue, 07 May 2002 16:07:53 +0100 (MET)o9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>>- Subject: Re: www.compaq.com is link to hp.comn; Message-ID: <01KHGACB17MU8Y8ZDE@sysdev.deutsche-boerse.com>o  B >    I could find VMS by following the Software and OS link, but I7 >    couldn't find Alpha by following the servers link.s   Just:F      Products and services  
    Servers      Compaq AlphaServeri    Three clicks from the main page.  H It would be nice if under "desktops, workstations and appliances" there G were a remark to the effect that folks interested in a VMS workstation  1 can buy a low-end server with graphics card.  :-|l   ------------------------------  $ Date: Tue, 7 May 2002 10:11:17 -0400- From: "kenrbnsn1@rcn.com" <kenrbnsn1@rcn.com>h- Subject: RE: www.compaq.com is link to hp.com > Message-ID: <RELAY14fQbPmhjM8osI000022a4@relay1.softcomca.com>  " You are not looking hard enough...  - I found a mention of OpenVMS in two clicks...0   Click on "products & services" Then on "Servers"cG There is a link to "Compaq AlphaServer" and OpenVMS is mentioned there.3  i I think that's pretty good. I never had that much luck seeing OpenVMS from the original Compaq home page.w   Ken Robinson kenrbsn1@rcn.com   Original Message:n ----------------- . From:  koehler@encompasserve.org (Bob Koehler) Date: 7 May 2002 08:41:37 -0500l To: Info-VAX@Mvb.Saic.Comr) Subject: www.compaq.com is link to hp.coml      F    Well, there it is.  Enter www.compaq.com and end up a hp.com.  Even"    www.digital.com gets you there.  @    I could find VMS by following the Software and OS link, but I5    couldn't find Alpha by following the servers link.a  D --------------------------------------------------------------------+ mail2web - Check your email from the web atl http://mail2web.com/ .   ------------------------------  # Date: Tue, 07 May 2002 14:23:07 GMTh0 From: "warren sander" <warren.sander@compaq.com>- Subject: Re: www.compaq.com is link to hp.comn9 Message-ID: <frRB8.22$Uv5.152714@cacnews.cac.cpqcorp.net>r  L Compaq AlphaServers is the 3rd hunk/link down on the left site (compaq side) of the servers page.F http://thenew.hp.com/country/us/eng/prodserv/servers.html which is the/ 'servers' link on the products & software page.s     --B ------------------------------------------------------------------6 Warren Sander                        OpenVMS Marketing? Hewlett Packard Company      Work:  warren.sander@remove.hp.com E 200 Forest Street MR01-3/J1   Personal: sander@remove.ma.ultranet.come/ Marlboro, MA 01752               (508) 467-4875r5    My opinions are my own and I only speak for myselfi,          Read http://www.openvms.compaq.com/B ------------------------------------------------------------------        : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:ZRIFM7Vtdmk9@eisner.encompasserve.org...o >aH >    Well, there it is.  Enter www.compaq.com and end up a hp.com.  Even$ >    www.digital.com gets you there. >oB >    I could find VMS by following the Software and OS link, but I7 >    couldn't find Alpha by following the servers link.i >r   ------------------------------  $ Date: Tue, 7 May 2002 07:33:10 -0700# From: "Tom Linden" <tom@kednos.com>e- Subject: RE: www.compaq.com is link to hp.com 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGENCEOAA.tom@kednos.com>s  ; And the SEARCH function seems to work, this is a good sign.U   >-----Original Message-----a6 >From: warren sander [mailto:warren.sander@compaq.com]$ >Sent: Tuesday, May 07, 2002 7:23 AM >To: Info-VAX@Mvb.Saic.Com. >Subject: Re: www.compaq.com is link to hp.com >r >n@ >Compaq AlphaServers is the 3rd hunk/link down on the left site  >(compaq side) >of the servers page.sG >http://thenew.hp.com/country/us/eng/prodserv/servers.html which is thee0 >'servers' link on the products & software page. >  >  >--bC >------------------------------------------------------------------h7 >Warren Sander                        OpenVMS Marketinga@ >Hewlett Packard Company      Work:  warren.sander@remove.hp.comF >200 Forest Street MR01-3/J1   Personal: sander@remove.ma.ultranet.com0 >Marlboro, MA 01752               (508) 467-48756 >   My opinions are my own and I only speak for myself- >         Read http://www.openvms.compaq.com/-C >------------------------------------------------------------------F >  >i >r > ; >"Bob Koehler" <koehler@encompasserve.org> wrote in messages. >news:ZRIFM7Vtdmk9@eisner.encompasserve.org... >>I >>    Well, there it is.  Enter www.compaq.com and end up a hp.com.  Evens% >>    www.digital.com gets you there.R >>C >>    I could find VMS by following the Software and OS link, but I>8 >>    couldn't find Alpha by following the servers link. >> >t >s >---' >Incoming mail is certified Virus Free.a; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002n >e ---y& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002   ------------------------------   Date: 7 May 2002 12:52:41 GMTt1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)  Subject: Re: X-Win32, Message-ID: <ab8imp$29os$4@info.cs.uofs.edu>  4 In article <200205051818.PAA09670@wilde.uol.com.br>,  valdemir-@uol.com.br writes:t |> Hello VMS gurus:. |> CB |>  In my job we are using X-Win32 to connect in our Sun machines,@ |>  and I=B4d like know if I can use X-win32 to connect with ourC |>  VAXes machines. Reading X-win32 help I didn=B4t find referencese |>  about VMS systems. |>  Thanks in advance...  G Being as X has nothing to do with operating systems, I'm not surprised.   F We have been using X-Win32 here with pretty much every kind of machineJ that supports X including both VAX and Alpha running VMS with no problems.   bill   -- fJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   e   ------------------------------  $ Date: Tue, 7 May 2002 15:55:38 +0200( From: "Bruin, J.M. de" <Bruin@WT.TNO.NL> Subject: RE: X-Win32C Message-ID: <86BE4031AD3CD611AC170008C7F37BC2472AC7@wt15.wt.tno.nl>8  N I have started to make use of X-Win 32 quite recently and have found it prettyK much usable. Though I must say I did have some difficulties in defining theeG correct environment on the Alpha and in the definition of the keyboard. O About the latter, there are still some points left open. F.i. the definition ofoH the F6 key. I am not able to get the mapping of the key as I want it to.H At first I wanted to map the <shift>/Fn keys to simulate F13 and higher.H But that did not work at all. So I ended up defining he <alt>/Fn keys toM simulate F13 and higher, but I can not get the <alt>/f6 mapped to emulate thef f16 key.  P For the rest, things work are working fine. Even copying the DecWindows fonts toP a directory within the fonts directory of X-Win 32 and creating FONTS.DIR workedG fine and I am now able to use the same fonts on the Alpha as on the PC.c  ( SO I am only stuck on the keyboard side.  F Mapping the <alt>/<Fn> keys forced me to change the <alt>/<fn> keys inD DecWindows, to make sure both definitions do intere with each other.   Mark   -----Original Message-----B From: bill@triangle.cs.uofs.edu [mailto:bill@triangle.cs.uofs.edu] Sent: dinsdag 7 mei 2002 14:53 To: Info-VAX@Mvb.Saic.Comt Subject: Re: X-Win32    4 In article <200205051818.PAA09670@wilde.uol.com.br>,  valdemir-@uol.com.br writes:  |> Hello VMS gurus:  |> pB |>  In my job we are using X-Win32 to connect in our Sun machines,@ |>  and I=B4d like know if I can use X-win32 to connect with ourC |>  VAXes machines. Reading X-win32 help I didn=B4t find referencesn |>  about VMS systems. |>  Thanks in advance...  G Being as X has nothing to do with operating systems, I'm not surprised.t  F We have been using X-Win32 here with pretty much every kind of machineJ that supports X including both VAX and Alpha running VMS with no problems.   bill   -- .J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   a   ------------------------------   Date: 7 May 2002 09:22:08 -0500y- From: koehler@encompasserve.org (Bob Koehler)d8 Subject: RE: ZIPped .PCSI container arrives OK on VMS???3 Message-ID: <A9ilzJau2YG5@eisner.encompasserve.org>c  _ In article <CIEJLCMNHNNDLLOOGNJIEELFEOAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:R > E > The source and the destination could both be VMS systems but if you ? > have a Windows box in between, it will change the block size.v >   >    Every FTP product for VMS I've seen has a technique to deal?    with this.  The caveat is that you must use a VMS FTP clientg@    for both the copy to the non-VMS box, and the copy from.  You.    can't use a Windows client for either step.  ?    You also have to know the command.  On Multinet it's put/fdlI!    and get/fdl.  UCX is simmilar.n   ------------------------------  $ Date: Tue, 7 May 2002 07:37:39 -0700# From: "Tom Linden" <tom@kednos.com>m8 Subject: RE: ZIPped .PCSI container arrives OK on VMS???9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGENDEOAA.tom@kednos.com>a  @ Well that isn't the point I was trying make.  Changing the block? size happens a lot.  Doesn't matter for what reason.  The logict? to fix it is simple enough that it could easily be handled as a  condition in backup itself.m   >-----Original Message----- 5 >From: Bob Koehler [mailto:koehler@encompasserve.org]h$ >Sent: Tuesday, May 07, 2002 7:22 AM >To: Info-VAX@Mvb.Saic.Com9 >Subject: RE: ZIPped .PCSI container arrives OK on VMS???i >a >l@ >In article <CIEJLCMNHNNDLLOOGNJIEELFEOAA.tom@kednos.com>, "Tom ! >Linden" <tom@kednos.com> writes:V >> rF >> The source and the destination could both be VMS systems but if you@ >> have a Windows box in between, it will change the block size. >> s >c? >   Every FTP product for VMS I've seen has a technique to dealg@ >   with this.  The caveat is that you must use a VMS FTP clientA >   for both the copy to the non-VMS box, and the copy from.  Youe/ >   can't use a Windows client for either step.s > @ >   You also have to know the command.  On Multinet it's put/fdl" >   and get/fdl.  UCX is simmilar. >  >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002t >e ---n& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002   ------------------------------   Date: 7 May 2002 02:24:47 -0700 5 From: Hiroyuki_Tanaka4@excite.co.jp (Hiroyuki Tanaka)c/ Subject: [Q]Terminators in Terminal Driver QIOWS= Message-ID: <68cfa44d.0205070124.61f67899@posting.google.com>c  
 Dear Readers,i  C I am writing a program that communicates to a device via the serial/E port tta0: on my alpha workstation.  I have set-up the program, usingtB the terminal driver, such that the QIOW is terminated on a colon :2 (ASCII 58), using the long form of the terminator.  > Is it possible to define the terminator to be a combination ofD characters, ie colon + space together?  In this I mean that the QIOWD would only terminate in this combination, not on their own.  It sortD of implies in the ISOB, size of terminator that the terminator could" be larger than a single character.   Thanks for any comments.   ------------------------------   End of INFO-VAX 2002.252 ************************