1 INFO-VAX	Sat, 11 May 2002	Volume 2002 : Issue 259       Contents:$ Re: Bob Palmer and the demise of DEC$ Re: Bob Palmer and the demise of DEC$ Re: Bob Palmer and the demise of DEC Bug in ANALYZE/AUDIT ? Re: Bug in ANALYZE/AUDIT ?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 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix   Re: CSWS / CSWB / MX Speculation& Re: Encompass US associate membership?  Re: Fix for EDT emulation in EVE4 Re: Gartner rides again (was Re: HP Product Roadmap)4 Re: Gartner rides again (was Re: HP Product Roadmap) Re: Help with ?setparams.dat? & Re: High Water Concurrent Users Count?& Re: High Water Concurrent Users Count?& Re: High Water Concurrent Users Count?& Re: High Water Concurrent Users Count?& Re: High Water Concurrent Users Count?& Re: High Water Concurrent Users Count?& HP Merger - Encompass food for thought RE: HP Product Roadmap Re: HP Product Roadmap6 Re: Invalid Directory File Sequence - Best way to fix?6 Re: Invalid Directory File Sequence - Best way to fix? Re: Itanium troubles Re: Itanium troubles Re: Itanium troublesE LORIA ANNOUNCES RELEASE -0.74 OF SMALLEIFFEL, THE GNU EIFFEL COMPILER 8 Re: MacOS/X is the leading Unix (was "Itanium Troubles") Re: MPE "clusters" Re: MPE "clusters" Re: MPE "clusters"N Re: MPE "clusters" (Was: Re: Capellas: Linux, Windows Will 'Eviscerate'  Unix)P MPE "clusters" (Was: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix) Unix)U Non-interactive TECO? % Re: Non-interactive TECO? (of course) % Re: Non-interactive TECO? (of course) % Re: Non-interactive TECO? (of course)  nu/tpu on nt 4.0 sp6; Re: Only one brief mention of OpenVMS on the HP whitesheet? ; Re: Only one brief mention of OpenVMS on the HP whitesheet? $ Oracle Rdb Technical Forums for 2002! Pathworks Macintosh >2GB support? % Re: Pathworks Macintosh >2GB support?  Re: Powered by HP  Re: Powered by HP  RE: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: Powered by HP  Re: simh VAX VMS users? " Re: simple disk-shadowing question1 Re: SOT: Yo Andrew, you guys on a roll this week?  Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! RE: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Switching the console mode Re: Switching the console mode Re: Switching the console mode Tektronix 4207! Re: Time for comp.sys.hp.vms? SSA  TS10/VAX with DHV11 0 Re: What is good model for disk i/o w/shadowing?0 Re: What is good model for disk i/o w/shadowing?0 Re: What is good model for disk i/o w/shadowing? Re: [announce] FreeVMS 0.0.14  Re: [announce] FreeVMS 0.0.14  Re: [announce] FreeVMS 0.0.14  Re: [announce] FreeVMS 0.0.14 ) [ANNOUNCE] OpenSSL 0.9.6d beta 1 released   F ----------------------------------------------------------------------  % Date: Fri, 10 May 2002 14:03:41 -0400 - From: "Peter Weaver" <peter.weaver@stelco.ca> - Subject: Re: Bob Palmer and the demise of DEC 5 Message-ID: <abh22j$i23dt$1@ID-141708.news.dfncis.de>   > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:abgv9p$ejl$4@info.cs.uofs.edu...  >...I > It will happen no more than one year from the day HP decides it will no H > longer issue License Paks for VMS.  Unless you figure all those reallyH > big businesses that are still running VMS will be willing to run their< > DP operations on a machine with the clock set back a year.   >...  J Bill, you're thinking about educational licenses and/or hobbyist licenses." The licenses we buy do not expire.   -- Peter WeaverL Opinions are my own, and do not reflect the opinions of my employer, nor theK company that it sub-contracts to, nor the company that it sub-contracts to.    ------------------------------  # Date: Fri, 10 May 2002 19:45:08 GMT 0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)- Subject: Re: Bob Palmer and the demise of DEC 9 Message-ID: <3cdc2288.2421983588@proxy.news.easynews.com>   @ On 8 May 2002 12:16:21 -0700, bob@instantwhip.com (Bob Ceculski) wrote:  ; >exactly what I have been saying for years ... Palmer was a 9 >Gates crony, paid off by Bill and Intel to give them all 7 >the little Alpha - VMS secrets while slowly destroying ' >Digital ... this just confirms it ...    ; There's no need to invoke any grand Gates/Grove conspiracy. > GQ Bob's own personal greed is more than enough to explain it.A From almost day 1, Bob Palmer's game plan was to sell off Digital < to another company and cash in on his golden parachute.  AllF the discontinued business units, the lack of effort to invest to build> a market for Alpha, were aimed towards that goal.  The Hudston= fab and the semiconductor business had to go because it was a 9 cash drain that was messing up the balance sheet.  GQ Bob C eventually had to sue Intel to force them to take it off his hands. @ Even the terms of the Compaq merger betray the self-interest--asD a last stab in the back to Digital shareholders, they did the mergerE so that it would be a taxable event for the Digital shareholders, but # not Compaq/Digital the corporation.   
 ---------- Remove 'Z' to reply by email.    ------------------------------    Date: 10 May 2002 16:48:44 -0700( From: bob@instantwhip.com (Bob Ceculski)- Subject: Re: Bob Palmer and the demise of DEC = Message-ID: <d7791aa1.0205101548.113eadcc@posting.google.com>   j "Peter Weaver" <peter.weaver@stelco.ca> wrote in message news:<abh22j$i23dt$1@ID-141708.news.dfncis.de>...@ > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message' > news:abgv9p$ejl$4@info.cs.uofs.edu...  > >...K > > It will happen no more than one year from the day HP decides it will no J > > longer issue License Paks for VMS.  Unless you figure all those reallyJ > > big businesses that are still running VMS will be willing to run their> > > DP operations on a machine with the clock set back a year. >    > >... > L > Bill, you're thinking about educational licenses and/or hobbyist licenses.$ > The licenses we buy do not expire.  D maybe Bill calls in every 30 days and gets another trial license ...   ------------------------------  + Date: Fri, 10 May 2002 21:32:57 +0000 (UTC) * From: bleau@umtof.umd.edu (Lawrence Bleau) Subject: Bug in ANALYZE/AUDIT ? 0 Message-ID: <abhea9$ejo$1@grapevine.wam.umd.edu>  I I posted this a couple of weeks ago but received no response, so I'll try K again.  This should be considered a bug report.  If anyone has a workaround  I would like to know.   I I'm having a problem with ANAL/AUDIT.  My system is OpenVMS AXP V7.1-2. I J have auditing enabled for file deletions that fail.  Unfortunately, I haveJ many audit records for events such as a PURGE on .LOG files that are stillF open by network tasks.  I'd like to exclude these - as well as severalJ other - "noise level" audit records from my nightly report of the security audit file.   J I am using the command ANAL/AUDIT/IGNORE=(things-to-ignore) in a batch job that runs each night.   I It seems that while there is a way to ignore multiple status values, only K one of the values specified is actually used.  Maybe a parsing error in the - ANAL/AUDIT utility?  Anyway, here's a demo.     J In the example below I want to ignore status codes %X800 (ACCONFLICT, fileJ access conflict) and %XD38064 (CMDINPUT, error reading  command input).  IK first do a bland ANAL/AUD/SIN/OUT=X. followed by a SEARCH X. to demonstrate J that there do exist records with the ACCONFLICT status.  I then do severalF ANAL/AUDIT comamnds, each with a different permutation of options, andK search the output file it generates.  If records with the ACCONFLICT status K are successfully ignored, the output file should not contain any lines with C ACCONFLICT in them; if it does, then ANAL/AUD/IGNORE didn't work as 	 expected.   I Notice that when more than one status code is specified to be ignored, it G appears that only the last status is used.  That is, when I reverse the E order of the two status values, the behavior changes.  This is a bug.   F In addition, HELP ANAL/AUDIT/SELECT (which has the same format used by  /IGNORE), subtopic STATUS, says:         STATUS              STATUS=type(,...)  I            Specifies the type of success status to be used when selecting A            event records. Choose from the following status types:   ?            SUCCESSFUL             Specifies any success status. ?            FAILURE                Specifies any failure status. I            CODE=(value,...)       Specifies a specific completion status. 	           H This seems to indicate that the values to ignore should be in () *after*K the keyword CODE, yet I get a syntax error when using that format.  Perhaps H this is just an error in the CLD for ANAL/AUDIT?  I don't know.  Anyway, it's yet another bug.   @ Does anyone know if this has been fixed in a patch, or know of a workaround?    Here's the tests I did:    $ ANAL/AUD/SIN/FUL/OUT=X.  $ SEA X. ACCONFLIC/NOOUT/STAT   E Files searched:                 1       Buffered I/O count:         4 E Records searched:            2577       Direct I/O count:          16 E Characters searched:       118991       Page faults:               19 H Records matched:              102       Elapsed CPU time:  0 00:00:00.02H Lines printed:                  0       Elapsed time:      0 00:00:00.01  8 This demonstrates there were 102 instances of ACCONFLIC.  1 $ ANAL/AUD/SIN/FUL/OUT=X./IGN=(STATUS=CODE=%X800)  $ SEA X. ACCONFLIC/NOOUT' %SEARCH-I-NOMATCHES, no strings matched   H The above command successfully filtered out all ACCONFLIC audit records.  A $ ANAL/AUD/SIN/FUL/OUT=X./IGN=(STATUS=(CODE=%X800,CODE=%XD38064))  $ SEA X. ACCONFLIC/NOOUT  I The above command did not produce the "no strings matched" message, which H means there were some ACCONFLIC records in the output file.  This should not have happened.  A $ ANAL/AUD/SIN/FUL/OUT=X./IGN=(STATUS=(CODE=%XD38064,CODE=%X800))  $ SEA X. ACCONFLIC/NOOUT' %SEARCH-I-NOMATCHES, no strings matched   I In the above command the order of the two statuses to ignore is reversed, J and the behavior changes: now there are no ACCONFLIC records.  This is theK right result, but it is inconsistent.  In fact, while I did not check, I'll 2 bet that it contains records with status %XD38064.  F $ ANAL/AUD/SIN/FUL/OUT=X./IGN=(STATUS=CODE=%X800,STATUS=CODE=%XD38064) $ SEA X. ACCONFLIC/NOOUT  J Here I try a slightly different syntax for CODE, and it fails on filtering) out ACCONFLIC records; SEARCH found some.   F $ ANAL/AUD/SIN/FUL/OUT=X./IGN=(STATUS=CODE=%XD38064,STATUS=CODE=%X800) $ SEA X. ACCONFLIC/NOOUT' %SEARCH-I-NOMATCHES, no strings matched   @ Again, I reverse the two status values and the behavior changes.  < $ ANAL/AUD/SIN/FUL/OUT=X./IGN=(STATUS=CODE=(%X800,%XD38064))B %DCL-W-ONEVAL, list of values not allowed - check use of comma (,)  \13860964)\  J Here is a list of values in () after the CODE keyword, which is the syntaxJ one would expect from the HELP topic (above).  Yet DCL tells me I can't doF it.  Clearly, this is either a bug in ANAL/AUDIT, an error in the .CLDE description for ANAL/AUDIT, or a mistake in HELP.  Anyone know which?   = $ ANAL/AUD/SIN/FUL/OUT=X./IGN=(STATUS=CODE=(%XD38064,%X800))) B %DCL-W-ONEVAL, list of values not allowed - check use of comma (,)  \2048)\   Same as previous case.   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edu    ------------------------------  % Date: Fri, 10 May 2002 17:48:10 -0400 2 From: norm lastovica <norman.lastovica@oracle.com># Subject: Re: Bug in ANALYZE/AUDIT ? ) Message-ID: <3CDC401A.DEBB7B0@oracle.com>    Lawrence Bleau wrote:  > K > I posted this a couple of weeks ago but received no response, so I'll try 2 > again.  This should be considered a bug report.   ; 	Seems like you'd then want to formally report it to Compaq & instead of repeatedly posting it here.   ------------------------------  % Date: Fri, 10 May 2002 14:24:16 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> < Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix, Message-ID: <3CDC104D.938DB683@videotron.ca>   Bob Ceculski wrote: H > it already has survived, and I would say that jstars, miltary, DOD, USI > gov use, Cerner, Pitts. Super Computing and the list goes on and on are K > the reason vms will survive ... MPE was 16 bit, neglected, no clustering,   H Consider some recent "super computing" deal that HP signed, promising toL deliver a super machine with over 1000 CPus based on IA64. Sounds to me thatI HP isn't even interested in selling Alphas NOW, they prefer to delay cash # input until IA64 is actually ready.   J Secondly, jstarts, military etc are just like existing MPE customers: theyL will continue to receive support. They do not mean that VMS will continue to be developped.   ------------------------------  # Date: Fri, 10 May 2002 18:56:47 GMT . From: peter@langstoeger.at (Peter LANGSTOEGER)< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix1 Message-ID: <PJUC8.5595$5a4.53735@news.chello.at>   h In article <d7791aa1.0205100914.5b708bc7@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:h >peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:<m8QC8.1749$5a4.19388@news.chello.at>...k >> In article <d7791aa1.0205090634.3aee3af2@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes: I >> >I have been on vms 17+ years now still waiting for my first os crash,  >>  
 >> Try to: >>   >> 1) Enable XFC >> 2) Install&Run PATHWORKS  >> 3) Install&Run DECnet/OSI >> 4) Install&Run UCX - >> 5) any other kernel mode program with bugs  >>  J >> and the probability of VMS crashes raises about umpteen thousand if not >> million percent.  >>  N >> Yes, there is no better Opsys than VMS, but it definetely has seen crashes. >  >not in my it world yet ...  >  >1) do not need xfc   D XFC is enabled by default. And if you don't know the warnings (maybeO because you were an early adopter of V7.3) then your system would have crashed.    >2) do not need pathworks   @ What else do you use ? SAMBA ? (V1.* is/was a big piece of shit)A But you're maybe right, we had no crashes caused by SAMBA so far.    >3) Install&Run DECnet/Phase IV   I We had few crashes caused by Ph4, too. But that was in the 80. We use Ph5 7 since DECnet VAX Extensions (which also crashed a lot).    >4) Install&Run TCPware   C We had a lot of crashes caused by the PWIPDRIVER in TCPware V5.0B ! J A simple non-privileged user doing a COPY was sufficient to crash the sys.  = But OTOH we had no crashes caused by TCPIP so far (only UCX).   % >5) run kernel mode software w/o bugs  > 0 >and the probability of VMS crashes drops to 0%.  M Where is the smiley ? A probability of 0% doesn't exist in the IT business...    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atP A-1030 VIENNA  AUSTRIA              I'm looking for (a) Network _and_ VMS Job(s)   ------------------------------  % Date: Fri, 10 May 2002 13:23:42 -0700 0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix, Message-ID: <3CDBC9DE.36D28074@Mvb.Saic.Com>   Peter LANGSTOEGER wrote: > S > In article <d7791aa1.0205090634.3aee3af2@posting.google.com>, bob@instantwhip.comn > (Bob Ceculski) writes:H > >I have been on vms 17+ years now still waiting for my first os crash, > 	 > Try to:f >  > 1) Enable XFCA  + Did that.  It wasn't on a cluster, however.s   > 2) Install&Run PATHWORKS   Does Advanced Server count?,   > 3) Install&Run DECnet/OSI   3 Did that.  I've NEVER had an issue with DECnet/OSI.    > 4) Install&Run UCX   Does Multinet count?  , > 5) any other kernel mode program with bugs   Apparently, I don't have any.W   > I > and the probability of VMS crashes raises about umpteen thousand if noti > million percent. > M > Yes, there is no better Opsys than VMS, but it definetely has seen crashes.     B Yes, crashes of VMS systems occur.  But I've done all the above as indicated without any crashes.  
 Next contest?e  
 Mark Berrymans   ------------------------------    Date: 10 May 2002 16:40:47 -0700( From: bob@instantwhip.com (Bob Ceculski)< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix= Message-ID: <d7791aa1.0205101540.1b62cdc9@posting.google.com>r   Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<abgrtf$1ib$1@new-usenet.uk.sun.com>...t > Bob Ceculski wrote:e > \ > > Ken Green <Ken.Green@kgcc.co.uk> wrote in message news:<3CD2DE32.D354B6B0@kgcc.co.uk>... > >  > > J > > it already has survived, and I would say that jstars, miltary, DOD, USK > > gov use, Cerner, Pitts. Super Computing and the list goes on and on are M > > the reason vms will survive ... MPE was 16 bit, neglected, no clustering,iL > > smaller user base, and quite frankly, not on the level of vms, or it tooL > > would have made it ... thank goodness some in our government and DOD areO > > not idiots, or our defense would get hacked to death in the coming attacks, M > > for the depts. that use vms, they will survive, others I think will be in  > > trouble ...e > > ; > Your information about MPE is lets say a bit out of date.  >  > MPE has clusters > 1 > http://www.hp.com/products1/mpeix/ha/index.htmla > ? > MPE runs on 64 bit HW suppoting up to 16 GB of RAM if runningH0 > on an HP N-4000 (Hard to do with a 16 bit OS). > @ > http://www.hp.com/products1/mpeix/operating/mpeix70/specs.html >  > It even supports Java 1.3. > 	 > Regardso > Andrew Harrisono  C I just got updated by an mpe support firm owner who got my name off A of Q, but didn't realize we run vms ... we had a nice little talkoD about vms and mpe ... what I meant was he said mpe's file system wasC still 16 bit, and he described their "switch-over" cluster solutiono@ which most customers don't do ... useless and they will not evenF support it unless you get into a habit of switching over, and comparedB w/vms clustering, I call it and the support person called it a badE solution ... so you might as well say they have none ... he also saida> mpe was neglected and a port would have been a nightmare ... a* conversation several days ago is outdated?   ------------------------------    Date: 11 May 2002 07:27:44 +0800, From: Paul Repacholi <prep@prep.synonet.com>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix- Message-ID: <874rhffurz.fsf@prep.synonet.com>l  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:   = > Consider some recent "super computing" deal that HP signed, C > promising to deliver a super machine with over 1000 CPus based onoD > IA64. Sounds to me that HP isn't even interested in selling AlphasD > NOW, they prefer to delay cash input until IA64 is actually ready.  E At about $24,000 per CPU... HP got their snout in the tax trough? No, " they wouldn't do that, would they.   -- ?< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.S@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   Date: 11 May 2002 01:26:30 GMT& From: peter@abbnm.com (Peter da Silva)< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix- Message-ID: <abhs06$kpr@web.eng.baileynm.com>$  3 In article <tnAnGQUzgVBh@eisner.encompasserve.org>,t, Rob Young <young_r@encompasserve.org> wrote:W > In article <abgni8$ck@web.eng.baileynm.com>, peter@abbnm.com (Peter da Silva) writes:eA > > In article <d7791aa1.0205090634.3aee3af2@posting.google.com>,o- > > Bob Ceculski <bob@instantwhip.com> wrote:a> > >> > >>|> The best hackers in the country tried to hack VMS:  J > > The best hackers in the country aren't the guys who break into systems  > > and talk about it at DEFCON.   > 	Boulder-dash.  K > 	Of the hundreds/thousands that attend DEFCON there are varying levels ofnC > 	intelligence and ability.  Maybe the percentage of top talent ise> > 	in the range of 5%, that would still leave 50 or 100 of the) > 	attendees at the truly talented level.    I see.  D There are 50-100 of the top 5% of the H/P/A/V/C community at DEFCON.  C So there's not even a significant percentage of the top 5% of that r@ community, let alone the larger hacker community (which includes8 many of the people who design these systems), at DEFCON.  B And how many of the ones who *are* there, know anything about VMS?   -- tO I've seen things you people can't imagine. Chimneysweeps on fire over the roofssO of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  AllmL 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`t   ------------------------------  # Date: Sat, 11 May 2002 01:46:43 GMTr1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix' Message-ID: <3CDC7B1D.F88BCDF5@fsi.net>n   Mark Berryman wrote: >  > Peter LANGSTOEGER wrote: > >sU > > In article <d7791aa1.0205090634.3aee3af2@posting.google.com>, bob@instantwhip.come > > (Bob Ceculski) writes:J > > >I have been on vms 17+ years now still waiting for my first os crash, > >h > > Try to:  > >o > > 1) Enable XFCr > - > Did that.  It wasn't on a cluster, however.a >  > > 2) Install&Run PATHWORKS >  > Does Advanced Server count?- >  > > 3) Install&Run DECnet/OSIb > 5 > Did that.  I've NEVER had an issue with DECnet/OSI.  >  > > 4) Install&Run UCX >  > Does Multinet count? > . > > 5) any other kernel mode program with bugs >  > Apparently, I don't have any.D  D Um (*Sheepish grin*), I had Multinet's SNMPD cause a "BUGCHECK whileA above ASTDEL" recently. Really caught it from the UN*X-weenies....  5 MNet V4.3A, VMS V7.3 (Alpha, GS160 partition 1 of 2).    -- d David J. Dachtera  dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/i   ------------------------------  # Date: Fri, 10 May 2002 20:44:59 GMT  From: lbohan@spamless..dbc.com) Subject: Re: CSWS / CSWB / MX Speculationa8 Message-ID: <csbodu8dftadacm00fp62k73u2bk83qppo@4ax.com>  / On Fri, 10 May 2002 10:25:48 +0200, Arne Vajhjy <arne.vajhoej@gtech.com> wrote:.  ? >The rumours is that the Exchange storage is based on MS Access25 >technology, which is not exactly "enterprise" level.l  / earlier on,  MSEXCH used a modified version of   msft's SQL engine (jet?)  4 modified for speed (at the expense of?  reliability?& long restore/repair times, who knows?)  / the engine behind MSEXCH may have branched off e( entirely from the mainline sql by now.    0 the white papers I've read inre MSEXCH recovery,4 seem to imply, that someone with good DBA skills is ) needed to restore a failed MSEXCH server.    ------------------------------  # Date: Sat, 11 May 2002 00:00:21 GMTe* From: 2damncommon <2damncommon@nospam.com>/ Subject: Re: Encompass US associate membership?e6 Message-ID: <paZC8.101751$k%2.16961@news.easynews.com>   Steve Pfister wrote:  G > Is there still an associate membership option to Encompass US? I keephE > sending in applications via the online form over the past week, butlE > all I get is an email response with my form in it. There's an emaildC > address for membership questions, but no response there either...   L I sympathize with you. Nowhere is mention made of what to expect, or in how = long. I think I got more info in an email in about 2-3 weeks.g	 Good Luckn   ------------------------------    Date: 10 May 2002 13:37:06 -0700. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman)) Subject: Re: Fix for EDT emulation in EVEl= Message-ID: <343f30ae.0205101237.22b4867a@posting.google.com>i  k DCantor@shore.net (David A. Cantor) wrote in message news:<mBUy8.39972$sI3.9279014@news02.optonline.net>...d= > I published this in the encompaserve DEC-SOFTWARE notesfileTN > a couple of years ago, but perhaps people reading this newsgroup might like  > it.h >  > Enjoy. > K > The EDT emulator in EVE (activated with SET KEYPAD EDT), doesn't quite do 
 > the trick. i > L > In particular, setting the keypad as above alone, you cannot cut an empty P > string and then use it to replace a found string (e.g., say you want to delete( > all occurences of the string 'fnord'). > = > The following code, when placed into your TPU$COMMAND file,s   [snip]  	 Thanks toa   David A. Cantor  Peter Weaver Bob Koehlert	 Rob Youngh Dave Greenwood
 Mike Rechtmant Carl Perkins Jeffry Chimene  F for their helpful tips on EVE and TPU. (Apologies if I missed anyone.)  C And thanks to Paul Sture for reporting that EDT now supports larger  files (more lines, i.e.).t  A If anyone has any other EVE/TPU tips, I'd sure like to see them. g  B And if anyone wants to work on converting my EDT init file to EVE,( send me a mail! (Use the address below.)  
 Thanks again.    Disclaimer: JMHO Alan E. Feldmann" afeldman atski gfigroup dotski com   ------------------------------    Date: 10 May 2002 16:53:45 -0700( From: bob@instantwhip.com (Bob Ceculski)= Subject: Re: Gartner rides again (was Re: HP Product Roadmap) = Message-ID: <d7791aa1.0205101553.2b76a7e5@posting.google.com>   { Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]> wrote in message news:<20020510162816.20744.qmail@gacracker.org>...u; > On 10 May 2002, bob@instantwhip.com (Bob Ceculski) wrote: K > >Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]> wrote in messagel4 > >news:<20020510090821.6703.qmail@gacracker.org>... > > be the alternative to  > >> >Internet Exploder! F > >> XN > >> There are a number of newsreaders available for VMS, even using a WindowsJ > >> newsreader would be a vast improvement over accessing comp.os.vms viaM > >> Google. You could even subscribe to the Info-VAX mailing list and access6% > >> the group from VMS in that way. b > >  mP > >> Anyway, don't you feel foolish saying "windoze isn't suitable for any task"E > >> then having to admit you use it to participate in the newsgroup?. > >> N	 > >> Doc.F > >T > >No! >  > Then you're a hypocrite. >  > Doc.  F as soon as the mozilla browser gets up to snuff for decwindows, I willD not need windows again, esp. w/ericoms vt sessions inside a browser 8 w/html side bar functionality for the menuing system ...   ------------------------------   Date: 11 May 2002 05:27:06 GMT- From: djweath@attglobal.net (Dave Weatherall)c= Subject: Re: Gartner rides again (was Re: HP Product Roadmap)A5 Message-ID: <DTiotGxQ0bj6-pn2-IieKdQOb8xKT@localhost>C  4 On Thu, 9 May 2002 17:11:45 UTC, "Terry C. Shannon"  <terryshannon@attbi.com> wrote:    > > > "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message4 > news:abe4fc$30b$1@fizban.fizban.pprd.abbott.com...J > > Who was the fellow that came from Gartner, went to DEC and started theK > > affinity program?  Forgot his name but when he rode off into the sunset/ > many	 > > said:X > H > That would have been Wes Melling. He was the architect of the AffinityN > Program, one of the most damnfool exercises in self-destruction that the VMS# > Group ever inflicted upon itself.o  E I hate to say this but at the time it was first mooted, it seemed to sD me to be a good idea. I had visions of developing the GUI on NT and F moving it to VMS V6.??. X/Motif seemed (or so I was led to believe) toD be a pain. It never happened and our UI is still VT100 esc-sequence  based.   -- l Cheers - Dave.   ------------------------------    Date: 10 May 2002 11:26:51 -0700. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman)& Subject: Re: Help with ?setparams.dat?= Message-ID: <343f30ae.0205101026.2ebf165c@posting.google.com>0  { "Lucas, Edward A (SAIC)" <Edward.Lucas@bp.com> wrote in message news:<EF1DC894691AD5118AF000508BB85FDE034CC5E7@AMCLVX11>...46 > Can someone please provide me the assistance I need. > M > If I am not mistaken setparams.dat is the file that is used when the systemi > boots and needs to set prams.uH > Now, If my system crash's (I hope not) and the system goes to boot andM > cannot boot because of a parameter error, how do I rename the file back anda > use the previous pram file.0 >   9 SETPARAMS.DAT is used by AUTOGEN to make VAXVMSSYS.PAR or:? ALPHAVMSSYS.PAR which is what's used by the system during boot.DF AUTOGEN also saves the old parameters in a file that has the same name8 but file type .OLD!. That is what you want to boot from.   Here's what to do:  @ Perform a conversational boot: On a VAX, that would typically be   >>> B/R5:1 .  A The command may be different on your machine. Check your hardware" manual.p  D At the SYSBOOT> prompt, run USE VAXVMSSYS.OLD or USE ALPHAVMSSYS.OLDE depending on whether this is a VAX or an Alpha. Then run CONTINUE anddD you'll boot with the old parameter set. If that doesn't work, repeat? the conversational boot and run USE DEFAULT. That will load thekD default system parameters which are supposed to always allow a boot.  
 Good luck.   Dislcaimer: JMHO Alan E. Feldmane" afeldman atski gfigroup dotski com   ------------------------------    Date: 10 May 2002 13:42:13 -06009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)i/ Subject: Re: High Water Concurrent Users Count?.3 Message-ID: <H3ht$jZf2v0L@eisner.encompasserve.org>0  
 $ anal/sys" OpenVMS (TM) Alpha system analyzer SDA> eval sys$gl_ijobcntF Hex = FFFFFFFF.8E886508   Decimal = -1903663864         SYS$GL_IJOBCNT SDA>  Exit 8 $!H $!	This remains constant on my system, but is different on each system. D $!	YMMV. I evaluate it by hand, then hard code it in the line below.$ $!	No parsing of output is needed... $!= $ write sys$output f$cvui(0, 32, f$fao("!AD", 4, %x8E886508))2 233t    I         We must have faith in our democratic system and our Constitution, K         and in our ability to protect at the same time both the freedom and '         the security of all Americans. n  1 	26-October, 2001: A day that will live in infamye4 	Support Freedom: http://www.indefenseoffreedom.org/   ------------------------------  % Date: Fri, 10 May 2002 20:23:00 +0100a From: "Ian" <ian@127.0.0.1>o/ Subject: Re: High Water Concurrent Users Count? . Message-ID: <abh6ri$e27$1@news8.svr.pol.co.uk>  ! doesn't f$getsyi("IJOBCNT") work?o   ------------------------------  % Date: Fri, 10 May 2002 21:59:53 +0200u9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>f/ Subject: Re: High Water Concurrent Users Count?d' Message-ID: <3CDC26B9.9DDD8574@aaa.com>    On what version ?    "OpenVMS V7.2-1" just gives :   & $ write sys$output f$getsyi("IJOBCNT")A %DCL-W-IVKEYW, unrecognized keyword - check validity and spellingi
  \IJOBCNT\ $    Jan-Erik Sderholm.e    
 Ian wrote: > # > doesn't f$getsyi("IJOBCNT") work?    ------------------------------  # Date: Fri, 10 May 2002 21:55:03 GMT ' From: Rick Dyson <Rick-Dyson@UIowa.EDU>t/ Subject: Re: High Water Concurrent Users Count?r) Message-ID: <3CDC41B6.6E9B65CD@UIowa.EDU>'   Rick Dyson wrote:i > P > Is there any counter that can be grabbed via lexical or program API that wouldQ > hold the highest number of concurrent users on an OpenVMS node or cluster sincea > the last reboot?  Or ever? > P > Or do I have to write something to sniff the current value and compare it with > a saved max?  P Thanks for all the pointers and solution suggestions.  I have a couple differentO ways to get the value now and have implemented a simple one to keep writing thenM max value to a file.  But I guess there is not already this 'high water mark'n# value stored somewhere by VMS then?    rick   ------------------------------  # Date: Fri, 10 May 2002 23:15:24 GMT ( From: "Tom Simpson" <simpsont@attbi.com>/ Subject: Re: High Water Concurrent Users Count?W: Message-ID: <gwYC8.20839$2m.4503232@typhoon1.se.ipsvc.net>  J Not unless all of your users connect via telnet.  TCPIP keeps a max telnet session number.s   Regards, Tom   4 "Rick Dyson" <Rick-Dyson@UIowa.EDU> wrote in message# news:3CDC41B6.6E9B65CD@UIowa.EDU...  > Rick Dyson wrote:S > >hL > > Is there any counter that can be grabbed via lexical or program API that wouldbE > > hold the highest number of concurrent users on an OpenVMS node ora
 cluster sincet > > the last reboot?  Or ever? > >vJ > > Or do I have to write something to sniff the current value and compare it with- > > a saved max? > H > Thanks for all the pointers and solution suggestions.  I have a couple	 different:E > ways to get the value now and have implemented a simple one to keep1 writing the0I > max value to a file.  But I guess there is not already this 'high water_ mark'h% > value stored somewhere by VMS then?m >a > rick   ------------------------------  # Date: Sat, 11 May 2002 02:16:43 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e/ Subject: Re: High Water Concurrent Users Count? ' Message-ID: <3CDC8228.670C1FB1@fsi.net>s  
 Ian wrote: > # > doesn't f$getsyi("IJOBCNT") work?P  G You may be thinking of IJOBLIM, which is the most you can have, not thew most you've had /SINCE=BOOT.   -- c David J. Dachterai dba DJE Systemsr http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/s   ------------------------------  % Date: Fri, 10 May 2002 16:58:06 -0400g& From: "Encompass" <KilleenJ@toast.net>/ Subject: HP Merger - Encompass food for thoughtr/ Message-ID: <udod36eo268a5c@corp.supernews.com>e  I (Note 5 URL's appear at the end of this message pointing to more in-depthP
 materials)   Dear HP Technologist  L Now that the HP-Compaq merger is official, what's next? Encompass offers theI following information and food for thought about the HP product roadmaps.   H Hewlett-Packard has published its product roadmaps. There is likely moreL information available about HP products for the next three years than existsI for any competitors. A Roadmap white paper, presentation, letter from JimrK Milton (HP Americas Managing Director and Sr. VP Enterprise Systems Group),II expanded version of Encompass' views on the roadmaps, and other materialseF are available at: http://www.encompassus.org/resources/hp_compaq.html.  < So what do these roadmaps mean to you and your organization?  H Essentially, HP is implementing an "adopt-and-go" strategy: Where HP andK Compaq had similar products, pick the best of breed and incorporate it into J the product set. Encompass is pleased to present this snapshot perspective on the main issues.i  K Six Operating Systems: HP has committed long-term support for six operatingMG systems: HP-UX with Tru64 enhancements, HP Non-Stop Kernel, HP OpenVMS,jH Linux, Novell NetWare, and Microsoft Windows. HP-UX will gain from Tru64I technologies. Compaq's OpenVMS roadmap remains intact. HP-UX, HP Non-StoprL Kernel, and HP OpenVMS will gain from running on the same family of servers.H HP-UX with Tru64 Enhancements: HP-UX will be the adopt-and-go enterpriseG class UNIX. If you're a Tru64 technologist, pay close attention to HP's G engineering plans for HP-UX. Key capabilities of Tru64 will be added to0 HP-UX over time.  E Storage and SANs (Storage Area Networks): Here, it's almost an "adopt.K everything" strategy - and for good reason. The two major storage platforms0J will be Compaq's Enterprise Virtual Array and HP's Surestore Disk Array XPK series. Compaq's Enterprise Network Storage Architecture (ENSA) will be thehI design model going forward. Compaq's VersaStor approach will continue andiK eventually HP's SANlink will be merged in. The software tools will begin torK blend. Pay attention to the storage roadmap, because here it's not simply aiI case of one product replacing another. Instead, products and technologiesaK will merge together to offer new levels of sophistication and capabilities.sG 64-Bit Servers: HP is headed toward a single family of servers based onbF Intel's Itanium Processor Family (IPF). These servers will support theI spectrum of HP's supported operating systems. Compaq's latest AlphaServera roadmap remains intact.cL Managing Beyond the Server: Pay close attention to the developing concept ofJ placing resource management outside the server operating system. These areI important developments that will be part of HP's strategy moving forward.r  G OpenView: OpenView ties many pieces together. Compaq components such as C Insight Manager, Integrated Lights Out, and the SANworks Management00 Appliance will integrate into this architecture.  F Linux: HP has a full-line Linux strategy based on six pillars: ManagedK Linux, Secure Linux, Pervasive Linux, Fast-Ignition Linux, Clustered Linux,hD and Standard Linux. Get to know how HP perceives its Linux strategy.  K Full Breadth of Technologies: HP is now a soup-to-nuts technology provider.hL The merger of the HP world and the Compaq world brings many new technologies to both worlds.g  J Have we, the customers, gained as a result of this merger? Time will tell.H On paper, it seems that we will begin seeing some new gains within 18-24 months.l  E One way to look at the merger is that HP and Compaq joined forces forSL business reasons.  The more interesting way to examine the merger is lookingH at it as the product of the paradigm shifts that are so prominent in theJ technology industry.  I encourage you to begin exploring and understandingJ the product roadmaps. Recall that you can get additional information underK non-disclosure agreements (NDA). Work with Encompass so we can collectively2 provide HP withoG feedback about how HP is -- or isn't -- hitting the mark, and so we can D guide HP's development plans. Join us at the HP Enterprise TechnicalK Symposium 2002 in St. Louis this October and learn the technical details ofvB how HP is going to implement what it is promising in the roadmaps.  B I hope this overview is helpful in bringing you up to speed on theK anticipated effects of the merger. Please continue to look to Encompass foriI news, training, and peer interchange opportunities that will enable us toeA help ourselves and our employers exploit the new HP product line.S   Joseph PollizziE President, Encompass U.S., Inc.   H Jim Milton Letter - http://www.encompassus.org/images/pdfs/miltonlet.pdf  @ Roadmap - http://www.encompassus.org/images/pdfs/prodroadmap.pdf  ! Customer Presentation (6MB ppt) -i7 http://www.encompassus.org/images/MC_customer_final.pptm  " Food For Thought (Complete Text) -3 http://www.encompassus.org/news/foodforthought.htmlb   OpenVMS/Tru64 Newsletter -7 http://www.encompassus.org/images/pdfs/hpnewsletter.pdf8   ------------------------------  % Date: Fri, 10 May 2002 11:06:36 -0400 1 From: "Farrell, Michael" <MFarrell@voltdelta.com>T Subject: RE: HP Product RoadmaptO Message-ID: <025766C9BBC5D511A4ED00B0D0F08C23163452@ny_exchange1.maintech1.com>l  L On the other hand, from the sound of what I'm hearing here, with the way the management of both HP and I the former CPQ are described, touting Sue to senior management would only ( either get her in trouble or squelched, L especially if the real intent is to slowly strangle VMS.  Sometimes it seems$ that "no good deed goes unpunished."   Mike Farrell   > -----Original Message-----6 > From:	Terry C. Shannon [SMTP:terryshannon@attbi.com]$ > Sent:	Friday, May 10, 2002 9:55 AM > To:	Info-VAX@Mvb.Saic.Com ! > Subject:	Re: HP Product RoadmapR >  > B > "Jeff Coffield" <Jeffrey@DigitalSynergyInc.com> wrote in message1 > news:3CDBCC6C.29F2B132@DigitalSynergyInc.com...t > > "Terry C. Shannon" wrote:h > >tB > > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message; > > > news:1kZB8.95042$WV1.28883107@typhoon.ne.ipsvc.net...p > > > > B > > > > "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in message > > > >r > > > L > news:92EFB80E551BD511B39500D0B7B0CDCC0642C3D7@ohms.electric.ci.austin.tx.u > s.
 > > > > ..1 > > > > > The HP Product Roadmap can be found at:t> > > > > > http://www.hp.com/hpinfo/newsroom/press/07may02b.htm	 > > > > >29 > > > > > There is one and only one reference to OpenVMS.e > > > >uC > > > > Yep. No change to committed roadmap, products, or IPF port.0 > > > >8I > > > > Whether HPQ plans to get stabilize the base and (try to) minimizes
 > customerG > > > > and ISV attrition, or whether the firm plans to try to grow theh > business,e > > > > remains to be seen.  > > > >  > > >gJ > > > Perhaps some positively-worded (at this point NOBODY in HPQ wants to	 > receivehF > > > any more bashing, deserved or not) suggestions and statements of	 > supportc% > > > might help. They couldn't hurt.k > > >sE > > > Wouldn't hurt to highlight Sue S as a valuable asset to the VMSl > franchise, > > > either...o > >t' > > To whom should the message be sent?g > L > I would try Mark.Gorham@hp.com as he is still in charge of the best server > OS on the planet.  > I > And Richard.Marcello@hp.com as he is in charge of the what is still thee! > fastest processor on the planeti > 9 > And Scott.Stallard@hp.com as he is in the catbird seat.m > K > Remember, the marching orders inside HPQ are customer retention, customerrK > retention, and customer retention. It will be some number of years before J > IPF is ready to supplant Alpha, and these folks know it. The VMS port to > IPFiJ > lives on. Exhorting these folks to broaden the VMS market and to solicit > newrJ > customers/ISVs would IMHO be a good thing. But that's just my opinion... >    ------------------------------  # Date: Sat, 11 May 2002 01:54:57 GMT.1 From: "David J. Dachtera" <djesys.nospam@fsi.net>n Subject: Re: HP Product Roadmape' Message-ID: <3CDC7D0A.12AD066F@fsi.net>o   "Terry C. Shannon" wrote:h > B > "Jeff Coffield" <Jeffrey@DigitalSynergyInc.com> wrote in message1 > news:3CDBCC6C.29F2B132@DigitalSynergyInc.com...1 > > "Terry C. Shannon" wrote:  > >CB > > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message; > > > news:1kZB8.95042$WV1.28883107@typhoon.ne.ipsvc.net...l > > > >rB > > > > "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in message > > > >> > > >aN > news:92EFB80E551BD511B39500D0B7B0CDCC0642C3D7@ohms.electric.ci.austin.tx.us.
 > > > > ..1 > > > > > The HP Product Roadmap can be found at: > > > > > > http://www.hp.com/hpinfo/newsroom/press/07may02b.htm	 > > > > >s9 > > > > > There is one and only one reference to OpenVMS.y > > > >tC > > > > Yep. No change to committed roadmap, products, or IPF port.t > > > >gI > > > > Whether HPQ plans to get stabilize the base and (try to) minimize 
 > customerG > > > > and ISV attrition, or whether the firm plans to try to grow theo > business,t > > > > remains to be seen.l > > > >d > > >sJ > > > Perhaps some positively-worded (at this point NOBODY in HPQ wants to	 > receive N > > > any more bashing, deserved or not) suggestions and statements of support% > > > might help. They couldn't hurt.  > > >eE > > > Wouldn't hurt to highlight Sue S as a valuable asset to the VMSp > franchise, > > > either...n > >K' > > To whom should the message be sent?2 > L > I would try Mark.Gorham@hp.com as he is still in charge of the best server > OS on the planet.d > I > And Richard.Marcello@hp.com as he is in charge of the what is still thet! > fastest processor on the planeta > 9 > And Scott.Stallard@hp.com as he is in the catbird seat.p > K > Remember, the marching orders inside HPQ are customer retention, customerX$ > retention, and customer retention.  % Evidence to date indicates otherwise.   ( > It will be some number of years beforeN > IPF is ready to supplant Alpha, and these folks know it. The VMS port to IPFN > lives on. Exhorting these folks to broaden the VMS market and to solicit new, > customers/ISVs would IMHO be a good thing.  ? Agreed. However, to date, our "exhortations" have been met with C everything from opposition to apathy, but very little (if anything)0	 positive.c   > But that's just my opinion...    ...and one which I share, FWIW.    -- 0 David J. Dachtera- dba DJE SystemsI http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/5   ------------------------------  # Date: Fri, 10 May 2002 20:02:19 GMTL) From: DCantor@shore.net (David A. Cantor)4? Subject: Re: Invalid Directory File Sequence - Best way to fix?a: Message-ID: <fHVC8.32696$C8.10729466@news02.optonline.net>  = In article <abeeb4de.0205090501.63b38348@posting.google.com>,o/ > toddnelson_@hotmail.com (Todd Nelson) writes: 
 >> Hello all.   L >> I ran $analyze disk_structure /repair /confirm on one of the disks on ourM >> Alpha 4000 and got the following message.  I chose not to repair the errorPI >> within this context - I would like to know more about what is going toc >> happen if I do, etc.y   >> The error is as follows:oK >> -ANALDISK-I-BAD_DIRFIDSEQ, invalid file sequence number in directory filDI >> %ANALDISK-W-DIRNAME, directory file [OFFICE]THERAPY.DIR;2 is not namedo >> '.DIR;1'b  $ >> $dir [.office]therapy.dir returns  L >> THERAPY.DIR;2                13   9-JUN-2001 09:59:21.67  [(UIC REMOVED)]L >> THERAPY.DIR;1                25   9-JUN-2001 09:57:48.27  [(UIC REMOVED)]  K >> When I do $set def [.THERAPY], I get into a directory and can see files,dH >> etc.  However, I do not know if I am in version 1 or version 2 of the4 >> directory.  I would guess that I am in version 2.  N In article <37L97$TS4Dp8@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) 	 answered:   D >I believe that you are in fact seeing the contents of therapy.dir;1  L >Rename therapy.dir;2 to something else. Maybe try DUMP on it to see what it
 >contains.  E Here's a little more.  When you do $ DIRE [.OFFICE.THERAPY], you are tF _definitely_ seeing the contents of THERAPY.DIR;1.  That's the way theF file system works.  Now, if version 2 is really a correctly-formatted F directory file, you can see it by renaming it, but the version number ? must be ;1, so $ RENAME [.OFFICE]THERAPY.DIR;2  THERAPY_2.DIR;1 F will allow you to access it as $ DIRE [.OFFICE.THERAPY_2], but only if the directory bit is set.  N  E You can do $ DUMP/DIR, as suggested earlier to try to get some clues.fJ If it is not a directory file, use $ DUMP (without the /DIR) like for any D file, and for heaven's sake, rename it to something other than .DIR.  N The most likely scenario IMAO for this is (based on 20+ years of managing VMS M systems) is that someone did EDIT THERAPY.DIR, or equivalent.  Unfortunately,tN the software doesn't prevent an editor (or anything) from opening a file that G has the directory bit set.  If someone did indeed attempt to edit that HO directory file, the newer version almost certainly does not have the directory >	 bit set.     Dave C.J   ------------------------------    Date: 11 May 2002 09:07:23 +0800, From: Paul Repacholi <prep@prep.synonet.com>? Subject: Re: Invalid Directory File Sequence - Best way to fix?r- Message-ID: <87znz7eblg.fsf@prep.synonet.com>5  + p_sture@elias.decus.ch (Paul Sture) writes:V   ...j  E > I believe that you are in fact seeing the contents of therapy.dir;1r  gD > > What is the best/safest way to correct this problem while makingC > > sure that if there are indeed files in the first version of thek' > > directory, that I do not lose them.a   E > Rename therapy.dir;2 to something else. Maybe try DUMP on it to seet > what it contains.a  F My very flacky memory is that VMS would not let you rename a directoryD if it clashed. IE, you could not create mumble.dir;2 by renaming. OrD by several oter methods AIR. But I got bitten by this; relied on theB system barfing if there was a name collision :( Can anyone remeber for sure what VMS used to do?e  ! VMS engineering has this one BTW.e   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.t@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 10 May 2002 13:45:00 -0400# From: Chris Morgan <cm@mihalis.net>m Subject: Re: Itanium troubles ( Message-ID: <86helfoq1v.fsf@mihalis.net>  1 Sander Vesik <sander@haldjas.folklore.ee> writes:s  ? > In comp.arch David J. Dachtera <djesys.nospam@fsi.net> wrote:C
 > >> And they H > >> are not exceptional.  The modern BSDs are better than the old ones, > >> but are still pretty bad. > > L > > Well, if you're total VMS bigot like me, yeah. On the other hand, if youE > > recall AT&T System 3.7 or older, you'll think some of today's GnutI > > utilities (as found in the average Linux or *BSD distro) are, as theyt > > say, "the cat's ass".e > >  > 4 > *bsds mostly use their own and not gnu utilities.   # gcc being a notable counter-example  --   Chris Morgan  &    "Not so bad offer to discuss about"  ( 		- Best recent email spam subject line    ------------------------------  % Date: Fri, 10 May 2002 18:15:39 -0400 ( From: Bill Gunshannon <bill@cs.uofs.edu> Subject: Re: Itanium troubles B Message-ID: <20020510181106.L27592-100000@server2.cs.scranton.edu>  $ On 10 May 2002, Nick Maclaren wrote:   >,D > They are.  And they can be very good.  NAG started as open source, > for example.  E By NAG, do you mean The Numerical Algorithms Group?? If so, they were1F never open source when I was the maintainer as far back as 1982.  JustD because they shipped the source to their product didn't make it openB source any more than SLAM or the Primos OS (all of which came withB full sources.)  The source was provided as the way the product wasF distributed but your license required that no one bu the administrator have access to them.  E A better example of early open source would be the comp.sources.* and: mod.sources newsgroups.o   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   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------   Date: 10 May 2002 22:42:22 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Itanium troubles 0 Message-ID: <abhice$ldg$1@pegasus.csx.cam.ac.uk>  B In article <20020510181106.L27592-100000@server2.cs.scranton.edu>,* Bill Gunshannon  <bill@cs.uofs.edu> wrote:% >On 10 May 2002, Nick Maclaren wrote:c >>E >> They are.  And they can be very good.  NAG started as open source,v >> for example.a > F >By NAG, do you mean The Numerical Algorithms Group?? If so, they wereG >never open source when I was the maintainer as far back as 1982.  JustgE >because they shipped the source to their product didn't make it openyC >source any more than SLAM or the Primos OS (all of which came withnC >full sources.)  The source was provided as the way the product waseG >distributed but your license required that no one bu the administratorm >have access to them.g  ? My association with NAG dates from 1972, formally, and slightlym earlier informally :-)  C The open source period was when they were the Nottingham Algorithmsl? Group!  Yes, it had stopped well before 1982, and the cessationiG happened roughly when NAG was incorporated as a not-for-profit company. F Also, I agree that it was never quite the same as current open source, but it was pretty close.  ( Please note that I said "started as" :-)     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679i   ------------------------------    Date: 10 May 2002 15:23:08 -0700< From: gnu_eiffel_announce@yahoo.com (GNU Eiffel press agent)N Subject: LORIA ANNOUNCES RELEASE -0.74 OF SMALLEIFFEL, THE GNU EIFFEL COMPILER= Message-ID: <e416d3df.0205101423.188a6c97@posting.google.com>o   FOR IMMEDIATE RELEASEv  ! Contact:     smalleiffel@loria.fri  E LORIA ANNOUNCES RELEASE -0.74 OF SMALLEIFFEL, THE GNU EIFFEL COMPILER   A France -- May 10, 2002 -- Loria, a leading research laboratory inn? information technology, is pleased to announce release -0.74 ofeB SmallEiffel, the GNU Eiffel compiler. SmallEiffel supports over 20% operating systems, including OpenVMS.m  C The most significant improvement in this new release is support for F agents, which are similar to closures in functional languages.  AgentsD allow a programmer to specify part or all of a computation for laterC evaluation. The agent mechanism has applications in everything fromnC number crunching to user interface design, and provides a type-safe  callback mechanism.s  3 Among the many other improvements in release -0.74:   E * Support for the latest standards on interfacing to C and C++ source E code. This allows most if not all of the glue code between Eiffel andp! C or C++ to be written in Eiffel.c  E * Added agent-based features in class COLLECTION, ARRAY, FIXED_ARRAY,r@ LINKED_LIST, TWO_WAY_LINKED_LIST, DICTIONARY, and SET. Names and6 signatures comes from ETL: do_all, for_all and exists.  D * The new create instruction/expression is now fully implemented andE correctly pretty-printed. The new default_create feature mechanism isd also implemented.l  D * The new manifest string notation for a verbatim manifest string is now implemented.  D * Added examples for the new TUPLE type in directory tutorial/tuple.  = * Added many new features in class MEMORY to tune the garbageoB collector. Those features may be useful for embedded applications.# (See tutorial/memory for examples.)e  D * Added flag -high_memory_compiler to compile_to_c. On machines withD ample RAM, this option can significantly increase compilation speed.    C Dr. Bertrand Meyer invented Eiffel in the 1980's. Designed from theo> ground up to be an efficient, statically typed object-orientedA language, Eiffel is unique in its support for "Design by ContracttA (DbC)" -- sophisticated assertion mechanisms that aid the design,o1 development and documentation of Eiffel software.t  E Dr. Dominique Colnet began the SmallEiffel project in 1994. "I do notlF believe in the future of languages such as Java or C++. I do not claimD that Eiffel is the language of the future (if any), but I think thatE Eiffel is probably the best current tool for safe software productiono= in the context of large teams. Another important point is therE SmallEiffel compilation strategy, which demonstrates that Eiffel codep! can run as fast as plain C code."i  F The ELJ project is actively developing SmallEiffel bindings to variousC databases and GUI libraries. Geoff Eldridge, who founded ELJ, likesaD Eiffel for it's clear syntax and semantics, and the self-documenting? aspects of Eiffel contracts that reduces his need for referencecC materials. "So I am self-contained in my code development and henceeB have more time to think about the problem and its solution." GeoffD also believes that DbC "is just brilliant. Once you have experiencedF DbC you feel exposed with other languages without the facility." GeoffF also finds Eiffel to be very malleable, even though it is a statically typed language.-  E Uwe Sander, the workhorse of the ELJ project who is currently writing E much of the code, agrees. "Design and development are closely relatedw@ when working with Eiffel, not strictly separated foes." Uwe alsoE appreciates SmallEiffel's support for interfacing to C and C++.  "The E integration with existing C code is now much better than it is in any.B other language I know, including C++. You can easily mess up a C++C project and let the old C style rule the project. Such a thing willPD never happen in an Eiffel project. It is always clear which language contains the top level logic."  R Linksr  ! To download release -0.74, visit e1 http://smalleiffel.loria.fr/general/download.htmle  - For more information about SmallEiffel, visit. http://smalleiffel.loria.fro  D The SmallEiffel team is fond of receiving postcards. They are a nice
 motivator.1 http://SmallEiffel.loria.fr/support/support.html t  - Subscribe to the SmallEiffel mailing list at:u5 http://smalleiffel.loria.fr/support/mailing-list.htmle  4 Details about the agent mechanism can be found here:; http://www.eiffel.com/doc/manuals/language/agent/page.html RC Or after downloading SmallEiffel, see the examples in the directory/ tutorial/agent.m    * The home page for the ELJ project is here: http://elj.sourceforge.net/   uD For more information on Eiffel in general, visit one of these sites: http://eiffel.com ) http://www.cetus-links.org/oo_eiffel.html    ------------------------------  % Date: Fri, 10 May 2002 15:10:28 -0400h+ From: John Johnstone <jj_usenet2@yahoo.com>eA Subject: Re: MacOS/X is the leading Unix (was "Itanium Troubles")e) Message-ID: <3CDBE2E4.339F056A@yahoo.com>    Bob Koehler wrote: > W > In article <9eZdYVhxpdW8@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:  > > P > > Can you please suggest a decent Mac newsgroup for a computer literate person > > who is a Mac novice? > I >    No, sorry.  There's so much noise in those groups I prefer to ask my G >    Mac questions here.  Never got an answer to a real question in any 6 >    Mac group I've tried, but someone in c.o.v knows.  H I'd say the noise level here has gotten pretty high lately and yet we'reG still here aren't we?  I'd say you could give comp.sys.mac.system a trytG anyway.  There are some good comments in there.  The problem is finding,7 them.  But we've gotten pretty good at doing that.  :-)b   ------------------------------   Date: 10 May 2002 18:19:15 GMT From: phn@icke-reklam.ipsec.nu Subject: Re: MPE "clusters"x) Message-ID: <abh2v3$lfg$1@nyheter.crt.se>e  6 In comp.os.vms Jan-Erik Sderholm <aaa@aaa.com> wrote:* > Andrew Harrison SUNUK Consultancy wrote: >>   >> MPE has clusters- >> -2 >> http://www.hp.com/products1/mpeix/ha/index.html >> J    7 > Well, there are clusters and then there are CLUSTERS. ? > If one take a closer look at the documents on the link above,hD > one will find that the "clusters" that MPE supports are in short :  G > - Multiple systems sharing a number of disks ("cluster-volume-sets").T   > But :n  : > - Only one system at a time can "mount" a specific disk.  = > - One system is "primary" and the other(s) are "secondary".h  ? > - When the "primary" system goes down, the "operator" HAVE totD >   enter some command MANUALY to re-mount the "cluster-volume-sets"D >   on one of the seconday systems and then restart the application.C >   The secondary system now becomes primary and when/if the former/D >   primary system comes up again, it will become the new secondary.   > As the document says :  A > "HA Cluster/iX gives you full control over when to switch over.oA > There are no internal automated controls to detect and exchange = > an unavailable server with one that is available. Operators ? > will need to monitor system availability through OpenView ITO C > manager or other system management tools. This allows you to make 6 > the switch over decision on the case by case basis."   > And then the next sentence :    H > "A fully automation version is planned for the next release."  :-) :-)    E > There is also an option called "High Availability FailOver/iX", butgG > thats only a failover on a *single* system between multiple I/O paths 1 > to some disk array. Not using multiple systems.   = > So, in short, the cluster solution in MPE isn't what I haveb > learned to call clusters.t    A Maybe you should have a look on Tandem non-stop technology then ?    > Best Regards > Jan-Erik Sderholm.a   --   Peter Hkanson         .7         IPSec  Sverige      ( At Gothenburg Riverside )aJ            Sorry about my e-mail address, but i'm trying to keep spam out,; 	   remove "icke-reklam" if you feel for mailing me. Thanx.    ------------------------------  % Date: Fri, 10 May 2002 20:31:18 +0200p9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>n Subject: Re: MPE "clusters"o' Message-ID: <3CDC11F6.AB62F0E0@aaa.com>    Peter Hkanson wrote :8 > In comp.os.vms Jan-Erik Sderholm <aaa@aaa.com> wrote:, > [compairing MPE and VMS cluster solutions] > >i? > > So, in short, the cluster solution in MPE isn't what I have  > > learned to call clusters.. > C > Maybe you should have a look on Tandem non-stop technology then ?m >    I ?w Why ?y( You seems out-of-sync with the thread...* What has Tandem to do with the comparision* between VMS and MPE "clusters" solutions ?  	 Jan-Erik.2   ------------------------------   Date: 10 May 2002 18:54:39 GMT From: phn@icke-reklam.ipsec.nu Subject: Re: MPE "clusters"s) Message-ID: <abh51f$mm7$1@nyheter.crt.se>o  6 In comp.os.vms Jan-Erik Sderholm <aaa@aaa.com> wrote: > Peter Hkanson wrote :9 >> In comp.os.vms Jan-Erik Sderholm <aaa@aaa.com> wrote: - >> [compairing MPE and VMS cluster solutions]f >> >@ >> > So, in short, the cluster solution in MPE isn't what I have >> > learned to call clusters. >> PD >> Maybe you should have a look on Tandem non-stop technology then ? >> c   > I ?e > Why ?,* > You seems out-of-sync with the thread..., > What has Tandem to do with the comparision, > between VMS and MPE "clusters" solutions ?  H To get a distance to what "cluster" can do for reliability.(very little)  F Besides all 3 are part of h-placq now, if they used half a brain they 6 could offer really good solutions for many customers.   I All 3 ( tandem, MPE and VMS) plays in different ballyards, have differento8 customers and runs different ( most of the time ) apps.   K Phasing out anyone won't make the customers migrate to the remaing. PhasingeB out all tree is suicide. ( not to mantion other products currently	 in stock)D  * Yours ( having heavily used 2 out of tree)   > Jan-Erik.w   --   Peter Hkanson          7         IPSec  Sverige      ( At Gothenburg Riverside )hJ            Sorry about my e-mail address, but i'm trying to keep spam out,; 	   remove "icke-reklam" if you feel for mailing me. Thanx.A   ------------------------------    Date: 10 May 2002 16:46:27 -0700( From: bob@instantwhip.com (Bob Ceculski)W Subject: Re: MPE "clusters" (Was: Re: Capellas: Linux, Windows Will 'Eviscerate'  Unix)g= Message-ID: <d7791aa1.0205101546.4aa0838a@posting.google.com>T  U Jan-Erik Sderholm <aaa@aaa.com> wrote in message news:<3CDC0CC1.6CEDD5F8@aaa.com>...,* > Andrew Harrison SUNUK Consultancy wrote: > >  > > MPE has clusters > > 3 > > http://www.hp.com/products1/mpeix/ha/index.htmla > >  >  > 7 > Well, there are clusters and then there are CLUSTERS. ? > If one take a closer look at the documents on the link above, D > one will find that the "clusters" that MPE supports are in short : > G > - Multiple systems sharing a number of disks ("cluster-volume-sets").a >  > But :o > : > - Only one system at a time can "mount" a specific disk. > = > - One system is "primary" and the other(s) are "secondary".  > ? > - When the "primary" system goes down, the "operator" HAVE toeD >   enter some command MANUALY to re-mount the "cluster-volume-sets"D >   on one of the seconday systems and then restart the application.C >   The secondary system now becomes primary and when/if the formernD >   primary system comes up again, it will become the new secondary. >  > As the document says : > A > "HA Cluster/iX gives you full control over when to switch over.hA > There are no internal automated controls to detect and exchangeo= > an unavailable server with one that is available. Operatorsi? > will need to monitor system availability through OpenView ITOoC > manager or other system management tools. This allows you to make 6 > the switch over decision on the case by case basis." >   E exactly, and an mpe support guru just explained to me that the switch.= over is something that most do not do, and that they will notrG support it unless regular switch overs are done, or else it is useless!i? he agreed compared to vms clusters, this was not even close ...w2 no one does clustering better than vms ... no one!   ------------------------------  % Date: Fri, 10 May 2002 20:09:05 +0200,9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> Y Subject: MPE "clusters" (Was: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix) Unix)U ' Message-ID: <3CDC0CC1.6CEDD5F8@aaa.com>u  ( Andrew Harrison SUNUK Consultancy wrote: >  > MPE has clusters > 1 > http://www.hp.com/products1/mpeix/ha/index.htmlr >     5 Well, there are clusters and then there are CLUSTERS.e= If one take a closer look at the documents on the link above,aB one will find that the "clusters" that MPE supports are in short :  E - Multiple systems sharing a number of disks ("cluster-volume-sets").n   But :m  8 - Only one system at a time can "mount" a specific disk.  ; - One system is "primary" and the other(s) are "secondary".,  = - When the "primary" system goes down, the "operator" HAVE tolB   enter some command MANUALY to re-mount the "cluster-volume-sets"B   on one of the seconday systems and then restart the application.A   The secondary system now becomes primary and when/if the formersB   primary system comes up again, it will become the new secondary.   As the document says :  ? "HA Cluster/iX gives you full control over when to switch over.-? There are no internal automated controls to detect and exchanger; an unavailable server with one that is available. Operatorst= will need to monitor system availability through OpenView ITOsA manager or other system management tools. This allows you to makea4 the switch over decision on the case by case basis."   And then the next sentence :    F "A fully automation version is planned for the next release."  :-) :-)    C There is also an option called "High Availability FailOver/iX", butyE thats only a failover on a *single* system between multiple I/O pathsr/ to some disk array. Not using multiple systems.i  ; So, in short, the cluster solution in MPE isn't what I haveu learned to call clusters.r   Best Regards Jan-Erik Sderholm.a   ------------------------------  + Date: Fri, 10 May 2002 14:18:31 -0600 (MDT) * From: Ingemar Olson <IOLSON@dairyland.com> Subject: Non-interactive TECO?- Message-ID: <01KHKE1LIYR88XAV6E@dairyland.ca>s  > I would like to use TECO's built-in file conversion capability5 (from VFC/print cc  to variable/CR cc) in a com file.c  ' It works like a hot-damn interactively:s $ edit/teco <filename>
 *EX<esc><esc>- $ $   and it's converted my file. Magic!  > But I can't figure out how I can get it to work in a com file.  5 I've tried it with: /command=<a file containing "EX">u@           and       /execute=<same file>                 (no go)  K The help refers to the PDP-11 TECO Editor Reference Manual but of course I r neither have nor can find one.  / Does anyone know whether this is even possible?e And how to do it!a   TIA ... Ingemaro   ------------------------------    Date: 10 May 2002 18:27:27 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) . Subject: Re: Non-interactive TECO? (of course)3 Message-ID: <Il4My8c2uVHt@eisner.encompasserve.org>e  Z In article <01KHKE1LIYR88XAV6E@dairyland.ca>, Ingemar Olson <IOLSON@dairyland.com> writes:@ > I would like to use TECO's built-in file conversion capability7 > (from VFC/print cc  to variable/CR cc) in a com file.m > ) > It works like a hot-damn interactively:f > $ edit/teco <filename> > *EX<esc><esc>: > $ & >   and it's converted my file. Magic! > @ > But I can't figure out how I can get it to work in a com file. > 7 > I've tried it with: /command=<a file containing "EX">pB >           and       /execute=<same file>                 (no go) > M > The help refers to the PDP-11 TECO Editor Reference Manual but of course I h  > neither have nor can find one.  : Order one from Hewlett Packard; it will keep them busy :-)  1 > Does anyone know whether this is even possible?2   Yes, someone does.   > And how to do it!   ! In general terms, something like:4   	$ mung = "$teco32 mung"$ 	$ define/user sys$command sys$input 	$ teco <filename> 	ex$$a  C "EX" does not count unless it is followed by two escape characters.L   ------------------------------    Date: 10 May 2002 20:33:29 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) . Subject: Re: Non-interactive TECO? (of course)3 Message-ID: <F4Met$BGeLbE@eisner.encompasserve.org>L  c In article <Il4My8c2uVHt@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:      Or even closer:y  # > In general terms, something like:o >    	$ teco = "$teco32 teco"& > 	$ define/user sys$command sys$input > 	$ teco <filename> > 	ex$$e > E > "EX" does not count unless it is followed by two escape characters.o   ------------------------------  % Date: Sat, 11 May 2002 03:18:04 +0100 ' From: Elliott Roper <elliott@yrl.co.uk> . Subject: Re: Non-interactive TECO? (of course)2 Message-ID: <110520020318041305%elliott@yrl.co.uk>  C In article <Il4My8c2uVHt@eisner.encompasserve.org>, Larry Kilgallenl <Kilgallen@SpamCop.net> wrote:  = > In article <01KHKE1LIYR88XAV6E@dairyland.ca>, Ingemar Olsone  > <IOLSON@dairyland.com> writes:B > > I would like to use TECO's built-in file conversion capability9 > > (from VFC/print cc  to variable/CR cc) in a com file.  > > + > > It works like a hot-damn interactively:A > > $ edit/teco <filename> > > *EX<esc><esc>I > > $ ( > >   and it's converted my file. Magic! > > B > > But I can't figure out how I can get it to work in a com file. > > 9 > > I've tried it with: /command=<a file containing "EX"> D > >           and       /execute=<same file>                 (no go) > > O > > The help refers to the PDP-11 TECO Editor Reference Manual but of course I  " > > neither have nor can find one. > < > Order one from Hewlett Packard; it will keep them busy :-)  D Feel free to swipe a copy from http://www.yrl.co.uk/elliott/teco.docF It's proper plain text, don't let MS weenies convince you ".doc" means "Word" > 3 > > Does anyone know whether this is even possible?h >  > Yes, someone does. >  > > And how to do it!o > # > In general terms, something like:i >  >  $ mung = "$teco32 mung"& >  $ define/user sys$command sys$input >  $ teco <filename> >  ex$$- > E > "EX" does not count unless it is followed by two escape characters.t  C Unless I'm missing a subtlety, should that not  be $mung <filename>e4 above? Nah, something else I'm  not understanding...C You also have the problem of having a non-teco editor inserting the  escape characters.   It would be more fun to have   fix_crlf.com be something like   $mung fix_crlf.tec,'p1'   " and fix_crlf.tec be something like   hxahken^eqa`<:en`;eb^eq*`ec`>eis  / That way you can have a wildcard filespec in p1e   invoke it like @fix_crlf  *.mem  3 The mung filespec,text syntax is on page 26 and 147t@  (the filespec lands in teco's buffer at the start of execution)  ? the macro above throws it into q register a, clears the buffer.a0 the en^qa sets up the wildcard mechanism in tecoG inside the <...> is a loop to open every file till no more for read andc write and write it all out.o  D The old joke about mung is that it is short for "mung until no good"  9 Hmm, That wildcard teco works, but whines at the end with 6 ?ERR    %RMS-F-SYN, file specification syntax error ""B I'm not handling the end of the loop properly.. bugger. It's a bit. early in the morning. I'll fix it up tomorrow.   ------------------------------  % Date: Fri, 10 May 2002 21:22:33 -0500i% From: "Headman" <headman@aaahawk.com>  Subject: nu/tpu on nt 4.0 sp6J, Message-ID: <abhvmn$4o8$1@news.chatlink.com>  L Has any one tried and used the nu/tpu demo ver. 5 successfully on windows nt	 4.0 sp 6?   C The Prompt command line is hidden behind the lower scroll bar.  Anyo recoomdations?  " Thanks for your time and response.   ------------------------------  % Date: Fri, 10 May 2002 14:26:42 -0400,- From: "Peter Weaver" <peter.weaver@stelco.ca>rD Subject: Re: Only one brief mention of OpenVMS on the HP whitesheet?5 Message-ID: <abh3do$hso2g$1@ID-141708.news.dfncis.de>c  . "John Smith" <a@nonymous.com> wrote in messageC news:YoxC8.26094$GLp1.20642@news01.bloor.is.net.cable.rogers.com...f  > So, what did they have to say?   >...  $ Write to them yourself and find out.   -- Peter WeaverL Opinions are my own, and do not reflect the opinions of my employer, nor theK company that it sub-contracts to, nor the company that it sub-contracts to.t   ------------------------------  % Date: Fri, 10 May 2002 14:46:08 -0500n1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>aD Subject: Re: Only one brief mention of OpenVMS on the HP whitesheet?1 Message-ID: <abh86e$jt7$1@fizban.pprd.abbott.com>    I'll second that emotion.u   -- Dave...   ) Adam and Eve had many advantages, but the:- principle one was that they escaped teething.f -----Mark Twainl  8 "Peter Weaver" <peter.weaver@stelco.ca> wrote in message/ news:abh3do$hso2g$1@ID-141708.news.dfncis.de...-0 > "John Smith" <a@nonymous.com> wrote in messageE > news:YoxC8.26094$GLp1.20642@news01.bloor.is.net.cable.rogers.com...c" > > So, what did they have to say? >  > >... >o& > Write to them yourself and find out. >h > -- > Peter WeaverJ > Opinions are my own, and do not reflect the opinions of my employer, nor the(I > company that it sub-contracts to, nor the company that it sub-contractsu to.  >o >t   ------------------------------  % Date: Fri, 10 May 2002 17:18:55 -0400s2 From: norm lastovica <norman.lastovica@oracle.com>- Subject: Oracle Rdb Technical Forums for 2002a* Message-ID: <3CDC393F.1EC844DD@oracle.com>  ; I am pleased to announce the schedule for the Rdb Technicale> Forums for 2002.  These training events, offered at no charge,; have become a very popular way for managers, developers andw= database administrators to meet the engineers who produce thed< Oracle Rdb product family and to learn how to use the newestA capabilities of the product.  Attendance has more than doubled inT: the last two years.  You'll hear about our plans to follow? OpenVMS to Itanium Processor Family based systems.  You'll hearJA how customers use Rdb's performance enhancing features to delivers< more work at lower cost.  You'll have an opportunity to meet5 other customers who face issues similar to your own. l  ? The Rdb Technical Forums will be offered in these cities on the  indicated dates: d  7 June 4-5          Nashua, New Hampshire, United States s& June 17-18        Zrich, Switzerland * June 20-21        Reading, United Kingdom & June 27-28        Copenhagen, Denmark $ August 19-20      Sydney, Australia / November 9-10     San Francisco, United States p  > You can register for any of these events at the Rdb web page,        http://www.oracle.com/rdb/    > We'll post more information on the presentation topics, travel@ options and exact locations for these events at this same site.   > I hope you'll be able to attend one of these events and I look forward to seeing you there. r  	 Regards, s Kevin Duffy  Oracle Rdb Development Director    ------------------------------  % Date: Fri, 10 May 2002 21:04:01 -0500e/ From: Clay M. Denton <denton@orison.dsserv.com>a* Subject: Pathworks Macintosh >2GB support?8 Message-ID: <imuoduc4gpb5m76ofibdnh2604v1kdo28d@4ax.com>  Z Back when Pathworks Macintosh was a current product, Mac volumes/files were limited to 2GBX in size.  Pathworks Mac server on VMS reported no more than 2GB free on a volume back toQ the Mac - even if the VMS drive had more available space to as not to confuse then
 Macintosh.  V Mac OS 8 and newer support larger drives and files.  Does anyone have a hack/patch forS Pathworks Mac server on VMS to allow it to report actual free space instead of 2GB?    Thanks,k Clay   ------------------------------  % Date: Sat, 11 May 2002 03:33:29 +0100P' From: Elliott Roper <elliott@yrl.co.uk>l. Subject: Re: Pathworks Macintosh >2GB support?2 Message-ID: <110520020333296766%elliott@yrl.co.uk>  G In article <imuoduc4gpb5m76ofibdnh2604v1kdo28d@4ax.com>, Clay M. Dentone! <denton@orison.dsserv.com> wrote:   M > Back when Pathworks Macintosh was a current product, Mac volumes/files were  > limited to 2GBK > in size.  Pathworks Mac server on VMS reported no more than 2GB free on a  > volume back toO > the Mac - even if the VMS drive had more available space to as not to confuse  > the: > Macintosh. > I > Mac OS 8 and newer support larger drives and files.  Does anyone have an > hack/patch forM > Pathworks Mac server on VMS to allow it to report actual free space instead]	 > of 2GB?   D Probably won't work. Even late model macs see every remote volume asD 2GB for free space reporting to each other even when they are biggerD and have far more free space. It is the remote Mac telling lies, not VMS getting it wrong.h   ------------------------------   Date: 10 May 2002 17:21:26 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)- Subject: Re: Powered by HP+ Message-ID: <abgvim$ejl$5@info.cs.uofs.edu>u  , In article <siQC8.17141$WR1.6711@sccrnsc01>,4  "Terry C. Shannon" <terryshannon@attbi.com> writes: |> hH |> I'll be staying in the Lyon Hilton along with my comely secretary and  |> administrative assistant. ;-}   Does your wife know??  ;-)   bill   -- oJ 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>   t   ------------------------------  % Date: Fri, 10 May 2002 14:18:26 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>c Subject: Re: Powered by HP, Message-ID: <3CDC0EF0.4B113528@videotron.ca>   Didier Morandi wrote:iR > No, Terry. We are not interested to "show 'em" anything. We are interested to doM > something to keep alive VMS, this is different. Remember that you are now aoP > journalist, you will continue to do business with SKHP, we not. We will be out> > of business in five years if VMS Customers "decommission ...  M Well, this is the question isn't it. It the past, attempts to change Compaq's L mind always resulted in us being sent back down the chain to levels friendlyK with VMS but with no powers or guts to do anything against the Winklers and  Capellas higher up.l  L Is it worth fighting ? If so, it should be a unified large scale attack, notH small individual attempts which will just wast etime of the VMS managersN having to repond with words that reassure you even they *may* know that we are perfectly right.  H But if it isn't worth fighting , we should just give up MUCH FASTER than? HP/Compaq had anticipated, thus inflicting the most harm on HP.<  K One day, they will write in history book that all those that tried to bringr" down VMS went down before VMS did.   ------------------------------  % Date: Fri, 10 May 2002 13:11:54 -0500x/ From: "Stuart, Ed" <Ed.Stuart@austinenergy.com>a Subject: RE: Powered by HPT Message-ID: <92EFB80E551BD511B39500D0B7B0CDCC0642C401@ohms.electric.ci.austin.tx.us>  L I agree, now how do we start?  We have folks with strong technical opinions,J someone with media access (Hi Terry), and a user groups like Encompass, orI DECUS at our disposal.  We also could probably recruit the folks handlingp the openvms.org site.)   --> EdE **Please apply a generous amount of all the usual disclaimers here.**A     > -----Original Message-----> > From: wspencer@ap.nospam.org [mailto:wspencer@ap.nospam.org]% > Sent: Friday, May 10, 2002 10:22 AMl > To: Info-VAX@Mvb.Saic.Comy > Subject: Re: Powered by HP >  > 4 > terryshannon@attbi.com (Terry C. Shannon) wrote in$ > <siQC8.17142$WR1.6805@sccrnsc01>:  >  > >n? > >"Dave Gudewicz" <david.gudewicz@abbott.com> wrote in messageo. > >news:abgi46$g96$1@fizban.pprd.abbott.com...H > >> Please write to Mr. Stallard and let him know how you feel.  I did,	 > >> and e > >got > >> an encouraging response.s > >>9 > >> You might also try writing to:  Peter Blackmore and   > Michael Capellas.s > >>G > >> If you think this effort will be "futile" (long "i"), then show me  > >> proof a > >ofp> > >> anything getting fixed by wailing and moaning on this ng. > >> > >tH > >Correct. I believe it would be prudent to emphasize one's interest inF > >the platform in question, and to provide constructive criticism andG > >suggestions. I am not an eternal optimist but I do believe we shoulds0 > >give the new regime the benefit of the doubt! > >  > 8 > If ever we, as a group, decided to put our collective  > shoulder into pushing F > OpenVMS in a positive direction, now would likely be the right time. >  > ws >  > -- ) >  > Warren Spencer) > Senior Software Engineer (not a writer)U > The Associated Press > > > ** Time flies like an arrow.  Fruit flies like a bananna. ** >    ------------------------------  % Date: Fri, 10 May 2002 14:32:41 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>i Subject: Re: Powered by HP+ Message-ID: <3CDC1246.F4AD65D@videotron.ca>o   Dave Gudewicz wrote: > M > Please write to Mr. Stallard and let him know how you feel.  I did, and gote > an encouraging response.  L And you'll find that while he tells you want you want to hear, he will stillK continue to say thigs publicly that caused you to write to him in the firstc place. N  L The policy has been set. Folks like Stallard are just implementing it. FolksN like Marcello are reluctantly forced to implement it or they are out of a job.  L Only Carly can change things and tell her underlings to change the policy onK VMS and stop badmouthing VMS. As long as Carly doesn't change her mind, herr underlings won't.r   ------------------------------  % Date: Fri, 10 May 2002 14:38:12 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>r Subject: Re: Powered by HP, Message-ID: <3CDC1390.95746E93@videotron.ca>   "Terry C. Shannon" wrote:eM > I am not an eternal optimist but I do believe we should give the new regimee > the benefit of the doubt!   M I am not so sure about that. The new Regime began June 25 when commitments to)K Alpha were "changed". And then they stayed silent for 11 months, telling usyM that everything had been decided, talked about all other OSes except VMS, andm1 now the final, carefully worded plan is unveiled.n  L Sorry Terry. We were patient during those 11 months, we gave them benefit ofG the doubt. Now they delivered, and they mucty be judged on that. Unless-K *CARLY*  *PUBLICLY* states that HP has no plans to migrate VMS customers to@7 HP-UX, then then Stallard policy will remain in effect.D  J What Stallard said *MUST* be corporate policy. They spent 8 months or moreN setting it up. The decision was made. And only CArly can change that decision.   ------------------------------  % Date: Fri, 10 May 2002 14:42:31 -0500s1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>  Subject: Re: Powered by HP1 Message-ID: <abh7vm$jt3$1@fizban.pprd.abbott.com>i   -- Dave...d  ) Adam and Eve had many advantages, but the - principle one was that they escaped teething.  -----Mark Twain   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message% news:3CDC1246.F4AD65D@videotron.ca...a > Dave Gudewicz wrote: > >eK > > Please write to Mr. Stallard and let him know how you feel.  I did, and- got- > > an encouraging response. >-H > And you'll find that while he tells you want you want to hear, he will stilleG > continue to say thigs publicly that caused you to write to him in the  firstt > place. >LH > The policy has been set. Folks like Stallard are just implementing it. Folks K > like Marcello are reluctantly forced to implement it or they are out of a  job. >lK > Only Carly can change things and tell her underlings to change the policy  onI > VMS and stop badmouthing VMS. As long as Carly doesn't change her mind,a her  > underlings won't.u   ------------------------------  % Date: Fri, 10 May 2002 14:43:10 -0500c1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>  Subject: Re: Powered by HP1 Message-ID: <abh80t$jt4$1@fizban.pprd.abbott.com>P  " How do you know all this?  Really.   -- Dave...   ) Adam and Eve had many advantages, but the - principle one was that they escaped teething.) -----Mark Twain   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message% news:3CDC1246.F4AD65D@videotron.ca...s > Dave Gudewicz wrote: > > K > > Please write to Mr. Stallard and let him know how you feel.  I did, ande got  > > an encouraging response. >sH > And you'll find that while he tells you want you want to hear, he will still0G > continue to say thigs publicly that caused you to write to him in the  first: > place. >rH > The policy has been set. Folks like Stallard are just implementing it. Folks K > like Marcello are reluctantly forced to implement it or they are out of ar job. >lK > Only Carly can change things and tell her underlings to change the policy  onI > VMS and stop badmouthing VMS. As long as Carly doesn't change her mind,  hern > underlings won't.    ------------------------------   Date: 10 May 2002 19:47:23 GMT1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>  Subject: Re: Powered by HP1 Message-ID: <abh84b$jt5$1@fizban.pprd.abbott.com>:   ------------------------------  % Date: Fri, 10 May 2002 15:05:15 -0500@1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>p Subject: Re: Powered by HP1 Message-ID: <abh9aa$k38$1@fizban.pprd.abbott.com><  L My opinion.  Don't wait for a group to form to craft a message to the powers that be at hp.  Do it now.L Most everyone here has similar thoughts on this subject.  While a collectiveI message sounds good, it'll take longer than forever to get the thing "outA
 the door".  J Of course, others here may have different opinions on this subject.  Thats fine.!   -- Dave...   ) Adam and Eve had many advantages, but then- principle one was that they escaped teething.m -----Mark Twaina  : "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in messageL news:92EFB80E551BD511B39500D0B7B0CDCC0642C401@ohms.electric.ci.austin.tx.us. ..D > I agree, now how do we start?  We have folks with strong technical	 opinions,rL > someone with media access (Hi Terry), and a user groups like Encompass, orK > DECUS at our disposal.  We also could probably recruit the folks handlingS > the openvms.org site.o >m > --> EdG > **Please apply a generous amount of all the usual disclaimers here.**s >o >d > > -----Original Message-----@ > > From: wspencer@ap.nospam.org [mailto:wspencer@ap.nospam.org]' > > Sent: Friday, May 10, 2002 10:22 AMs > > To: Info-VAX@Mvb.Saic.Com  > > Subject: Re: Powered by HP > >e > > 6 > > terryshannon@attbi.com (Terry C. Shannon) wrote in% > > <siQC8.17142$WR1.6805@sccrnsc01>:u > >i > > >eA > > >"Dave Gudewicz" <david.gudewicz@abbott.com> wrote in messagev0 > > >news:abgi46$g96$1@fizban.pprd.abbott.com...J > > >> Please write to Mr. Stallard and let him know how you feel.  I did,
 > > >> and > > >got > > >> an encouraging response._ > > >>: > > >> You might also try writing to:  Peter Blackmore and > > Michael Capellas.i > > >>I > > >> If you think this effort will be "futile" (long "i"), then show met > > >> proof > > >ofn@ > > >> anything getting fixed by wailing and moaning on this ng. > > >> > > >aJ > > >Correct. I believe it would be prudent to emphasize one's interest inH > > >the platform in question, and to provide constructive criticism andI > > >suggestions. I am not an eternal optimist but I do believe we shouldo2 > > >give the new regime the benefit of the doubt! > > >  > >,9 > > If ever we, as a group, decided to put our collectiveR > > shoulder into pushingiH > > OpenVMS in a positive direction, now would likely be the right time. > >  > > ws > >a > > -- > >r > > Warren Spencer+ > > Senior Software Engineer (not a writer)  > > The Associated Press > >3@ > > ** Time flies like an arrow.  Fruit flies like a bananna. ** > >    ------------------------------  # Date: Fri, 10 May 2002 19:56:02 GMTe1 From: "Terry C. Shannon" <terryshannon@attbi.com>i Subject: Re: Powered by HP, Message-ID: <mBVC8.19378$WR1.7008@sccrnsc01>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CDC1390.95746E93@videotron.ca... > "Terry C. Shannon" wrote:2H > > I am not an eternal optimist but I do believe we should give the new regime > > the benefit of the doubt!o >hL > I am not so sure about that. The new Regime began June 25 when commitments toJ > Alpha were "changed". And then they stayed silent for 11 months, telling usK > that everything had been decided, talked about all other OSes except VMS,r ando3 > now the final, carefully worded plan is unveiled.n  G Seems to me that there's a new new regime. Run by a lady named Fiorina.o >nK > Sorry Terry. We were patient during those 11 months, we gave them benefit- ofI > the doubt. Now they delivered, and they mucty be judged on that. UnlessvJ > *CARLY*  *PUBLICLY* states that HP has no plans to migrate VMS customers to9 > HP-UX, then then Stallard policy will remain in effect.i  L It might be nice to ask Carly what her plans are in this regard, I haven't a clue.d >nL > What Stallard said *MUST* be corporate policy. They spent 8 months or moreF > setting it up. The decision was made. And only CArly can change that	 decision.$   ------------------------------  # Date: Fri, 10 May 2002 19:56:46 GMTt1 From: "Terry C. Shannon" <terryshannon@attbi.com>b Subject: Re: Powered by HP, Message-ID: <2CVC8.18340$RR3.8900@sccrnsc02>  > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:abgvim$ejl$5@info.cs.uofs.edu...d. > In article <siQC8.17141$WR1.6711@sccrnsc01>,6 >  "Terry C. Shannon" <terryshannon@attbi.com> writes: > |>J > |> I'll be staying in the Lyon Hilton along with my comely secretary and" > |> administrative assistant. ;-} >  > Does your wife know??  ;-)  2 Marsha Shannon knows. We divorced three years ago.  # Besides, I took her to France once.D   ------------------------------  # Date: Fri, 10 May 2002 19:57:43 GMTa1 From: "Terry C. Shannon" <terryshannon@attbi.com>d Subject: Re: Powered by HP, Message-ID: <XCVC8.19391$WR1.6837@sccrnsc01>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message% news:3CDC1246.F4AD65D@videotron.ca...l > Dave Gudewicz wrote: > >aK > > Please write to Mr. Stallard and let him know how you feel.  I did, ando gots > > an encouraging response. > H > And you'll find that while he tells you want you want to hear, he will stilltG > continue to say thigs publicly that caused you to write to him in thel firsts > place. >vH > The policy has been set. Folks like Stallard are just implementing it. Folks K > like Marcello are reluctantly forced to implement it or they are out of a  job.  8 If it's all set in stone, why even bother discussing it?   ------------------------------   Date: 10 May 2002 20:35:41 GMT3 From: bobd@araminta.uts.ohio-state.edu (Bob DeBula)m Subject: Re: Powered by HP: Message-ID: <abhaut$9ar$1@charm.magnus.acs.ohio-state.edu>  L JF Mezei  <jfmezei.spamnot@videotron.ca> carefully crafted electrons to say: > Dave Gudewicz wrote: > > O > > Please write to Mr. Stallard and let him know how you feel.  I did, and got  > > an encouraging response. > N > And you'll find that while he tells you want you want to hear, he will stillM > continue to say thigs publicly that caused you to write to him in the firste	 > place.   > N > The policy has been set. Folks like Stallard are just implementing it. FolksP > like Marcello are reluctantly forced to implement it or they are out of a job. > N > Only Carly can change things and tell her underlings to change the policy onM > VMS and stop badmouthing VMS. As long as Carly doesn't change her mind, herz > underlings won't.v  E cHomPaQ isn't a new opportunity. cHomPaQ is two delusional companies,vE sharing the same delusion of commodity PC profitability, if only they E play nicely enough with the Redmond Baron, becoming a reality if they ? focus *everything* on it, instead of just most of the revenues.wE Ironically, both companies have sunken lower, faster, than might have-F been the case by earlier embracing "visionary" CEOs that might as wellF have been the Baron's Black Knights come to do his bidding, who helpedF to divert lifeblood to the very same false dream. They haven't learned	 anything.<  @ In their low corporate cunning way (displaying the same order ofF magnitude of "intelligence" as a monkey that will continue to clutch aG nut when releasing it would allow it to remove it's paw from the hole),h@ they realize that switching over will take some time, so they're> willing to keep dragging colorful pieces of yarn in front of aE community of customers, which they probably consider akin to a basketdG of hyperactive kittens, to keep their interest in the interim.  Make nohD mistake, I don't think they want any part of HP-UX in the longer runE either.  From their lofty pinnacles, Windows Omega DS will eventually D conquer all markets, no doubt.  Might as well get on board early and@ the Baron may remember who his loyal ring kissers were when he'sA handing out parcels of land later.  As a corporate power, they're-D deceased, they just haven't had the decency to realize it yet and toG lie down and to stop clutching the children that might survive on their-; own if unfettered by the rotting corp before it's too late.4  C So, pack up and head for one of the two companies that haven't soldiD their dreams for the promise of paperclips dancing in their heads orG head for the Linux camp and try to reconstruct some of what's been lost A or help to build something better.  The Rebel alliance won't helpmG defend VMS, they're concentrating their efforts elsewhere, on survivingiB and eventually coming up with an effective counterattack. Join the? Alliance and help to build an offense that'll take out the evil-F empires' domination of the market. The legal system can't/won't do it,F the politicians can't/won't do it, only the techies can do it en masseG by offering a better alternative.  Sorry, but VMS isn't it, though some B piece of it may survive if you contribute some of your visions andD talents from the old dream into the new dream and help to perpetuate  the good in the next generation.  A Yes, I know I'll hear a lot of "you're soooo wrong" comments, but = let's get together over a cup of java in about five years and  compare notes again, shall we?    J ==========================================================================9               Disclaimer: These are my views, not the U'sw  ?         "If it's in the paper it must be true!" --- D. Doright e   ------------------------------  % Date: Fri, 10 May 2002 16:13:27 -0500r1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>c Subject: Re: Powered by HP1 Message-ID: <abhda6$koq$1@fizban.pprd.abbott.com>a  L Some of the Rebel alliance lurk here and know this, the alliance can and hasJ claimed victory despite overwhelming odds.  Let us not give in to the dark
 side.  Never.n   -- Dave...s  ) Adam and Eve had many advantages, but the - principle one was that they escaped teething.r -----Mark Twaino  @ "Bob DeBula" <bobd@araminta.uts.ohio-state.edu> wrote in message4 news:abhaut$9ar$1@charm.magnus.acs.ohio-state.edu...I > JF Mezei  <jfmezei.spamnot@videotron.ca> carefully crafted electrons to1 say: > > Dave Gudewicz wrote: > > >tI > > > Please write to Mr. Stallard and let him know how you feel.  I did,t and gotn > > > an encouraging response. > >cJ > > And you'll find that while he tells you want you want to hear, he will stillsI > > continue to say thigs publicly that caused you to write to him in the  firstl
 > > place. > >rJ > > The policy has been set. Folks like Stallard are just implementing it. Folks K > > like Marcello are reluctantly forced to implement it or they are out ofy a job. > >2F > > Only Carly can change things and tell her underlings to change the	 policy oneK > > VMS and stop badmouthing VMS. As long as Carly doesn't change her mind,r her> > > underlings won't.G >wG > cHomPaQ isn't a new opportunity. cHomPaQ is two delusional companies,fG > sharing the same delusion of commodity PC profitability, if only theynG > play nicely enough with the Redmond Baron, becoming a reality if theyeA > focus *everything* on it, instead of just most of the revenues. G > Ironically, both companies have sunken lower, faster, than might havelH > been the case by earlier embracing "visionary" CEOs that might as wellH > have been the Baron's Black Knights come to do his bidding, who helpedH > to divert lifeblood to the very same false dream. They haven't learned > anything.t >rB > In their low corporate cunning way (displaying the same order ofH > magnitude of "intelligence" as a monkey that will continue to clutch aI > nut when releasing it would allow it to remove it's paw from the hole),eB > they realize that switching over will take some time, so they're@ > willing to keep dragging colorful pieces of yarn in front of aG > community of customers, which they probably consider akin to a baskettI > of hyperactive kittens, to keep their interest in the interim.  Make no*F > mistake, I don't think they want any part of HP-UX in the longer runG > either.  From their lofty pinnacles, Windows Omega DS will eventuallywF > conquer all markets, no doubt.  Might as well get on board early andB > the Baron may remember who his loyal ring kissers were when he'sC > handing out parcels of land later.  As a corporate power, they'renF > deceased, they just haven't had the decency to realize it yet and toI > lie down and to stop clutching the children that might survive on their.= > own if unfettered by the rotting corp before it's too late.l >nE > So, pack up and head for one of the two companies that haven't sold F > their dreams for the promise of paperclips dancing in their heads orI > head for the Linux camp and try to reconstruct some of what's been lostrC > or help to build something better.  The Rebel alliance won't help-I > defend VMS, they're concentrating their efforts elsewhere, on surviving<D > and eventually coming up with an effective counterattack. Join theA > Alliance and help to build an offense that'll take out the evil H > empires' domination of the market. The legal system can't/won't do it,H > the politicians can't/won't do it, only the techies can do it en masseI > by offering a better alternative.  Sorry, but VMS isn't it, though someeD > piece of it may survive if you contribute some of your visions andF > talents from the old dream into the new dream and help to perpetuate" > the good in the next generation. >rC > Yes, I know I'll hear a lot of "you're soooo wrong" comments, but ? > let's get together over a cup of java in about five years anda  > compare notes again, shall we? >s >aL > ==========================================================================; >               Disclaimer: These are my views, not the U'sr >a@ >         "If it's in the paper it must be true!" --- D. Doright >a   ------------------------------  # Date: Fri, 10 May 2002 23:26:48 GMT-# From: "John Smith" <a@nonymous.com>: Subject: Re: Powered by HPH Message-ID: <YGYC8.36976$GLp1.3995@news01.bloor.is.net.cable.rogers.com>  K HP can take one submission/petition, signed by thousands, and circular filem it very quickly.  J Hundreds of individual letters arriving daily from different customers are> harder to ignore. (It's the same way you  influence Congress).  I Get the Chairman/CEO/President/COO/CFO etc...as high as you can get to iniK your own organization to send the letter to Carly......you write it for hime if you have to   Get them in the mail asap.  G Hell, maybe we can get them to port any useful features from HP-UX into  TRU64 on Alpha. :-)a      < "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message+ news:abh9aa$k38$1@fizban.pprd.abbott.com...sG > My opinion.  Don't wait for a group to form to craft a message to thel powers > that be at hp.  Do it now.C > Most everyone here has similar thoughts on this subject.  While at
 collectiveK > message sounds good, it'll take longer than forever to get the thing "outa > the door". >nL > Of course, others here may have different opinions on this subject.  Thats > fine.  >m > --	 > Dave...  >v+ > Adam and Eve had many advantages, but thed/ > principle one was that they escaped teething.o > -----Mark Twainy >k< > "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in message >dL news:92EFB80E551BD511B39500D0B7B0CDCC0642C401@ohms.electric.ci.austin.tx.us. > ..F > > I agree, now how do we start?  We have folks with strong technical > opinions,@K > > someone with media access (Hi Terry), and a user groups like Encompass,a orD > > DECUS at our disposal.  We also could probably recruit the folks handling > > the openvms.org site.w > >h
 > > --> EdI > > **Please apply a generous amount of all the usual disclaimers here.**a > >s > >u  > > > -----Original Message-----B > > > From: wspencer@ap.nospam.org [mailto:wspencer@ap.nospam.org]) > > > Sent: Friday, May 10, 2002 10:22 AM  > > > To: Info-VAX@Mvb.Saic.Comn  > > > Subject: Re: Powered by HP > > >n > > >y8 > > > terryshannon@attbi.com (Terry C. Shannon) wrote in' > > > <siQC8.17142$WR1.6805@sccrnsc01>:S > > >n > > > >yC > > > >"Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message-2 > > > >news:abgi46$g96$1@fizban.pprd.abbott.com...L > > > >> Please write to Mr. Stallard and let him know how you feel.  I did, > > > >> and
 > > > >got! > > > >> an encouraging response.- > > > >>< > > > >> You might also try writing to:  Peter Blackmore and > > > Michael Capellas.d > > > >>K > > > >> If you think this effort will be "futile" (long "i"), then show mer > > > >> proof	 > > > >ofnB > > > >> anything getting fixed by wailing and moaning on this ng. > > > >> > > > >iL > > > >Correct. I believe it would be prudent to emphasize one's interest inJ > > > >the platform in question, and to provide constructive criticism andK > > > >suggestions. I am not an eternal optimist but I do believe we shouldh4 > > > >give the new regime the benefit of the doubt! > > > >m > > >a; > > > If ever we, as a group, decided to put our collectiveg > > > shoulder into pushingrJ > > > OpenVMS in a positive direction, now would likely be the right time. > > >B > > > ws > > >h > > > -- > > >s > > > Warren Spencer- > > > Senior Software Engineer (not a writer)t > > > The Associated Press > > >nB > > > ** Time flies like an arrow.  Fruit flies like a bananna. ** > > >U >t >r   ------------------------------  # Date: Sat, 11 May 2002 00:17:19 GMTn1 From: "Terry C. Shannon" <terryshannon@attbi.com>n Subject: Re: Powered by HP- Message-ID: <iqZC8.19745$RR3.11005@sccrnsc02>a  < "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message+ news:abh9aa$k38$1@fizban.pprd.abbott.com...0G > My opinion.  Don't wait for a group to form to craft a message to the  powers > that be at hp.  Do it now.C > Most everyone here has similar thoughts on this subject.  While a>
 collectiveK > message sounds good, it'll take longer than forever to get the thing "out  > the door". >1L > Of course, others here may have different opinions on this subject.  Thats > fine.u  L Well, how much would it cost to run an advertisement in a high-profile venueE (WSJ, ComputerWorld, whatever?). Back when I was in the trade press a I full-page single-insertion B&W ad was a bit over $5K in a magazine with a" BPA audited circulation of 90K.   K I suspect it would be bigger bucks these days! I wouldn't mind contributing K ten bucks (plus some writing assistance) to the effort, but it's gonna taket2 an awful lot more people to belly up to the bar...   ------------------------------    Date: 10 May 2002 18:38:06 -0700$ From: bdhobbs18@acm.org (Bill Hobbs) Subject: Re: Powered by HP= Message-ID: <74ca5032.0205101738.3a890a11@posting.google.com>p   "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in message news:<92EFB80E551BD511B39500D0B7B0CDCC0642C401@ohms.electric.ci.austin.tx.us>... N > I agree, now how do we start?  We have folks with strong technical opinions,L > someone with media access (Hi Terry), and a user groups like Encompass, orK > DECUS at our disposal.  We also could probably recruit the folks handlinge > the openvms.org site.0  D I wonder if HP could be convinced to resurrect the Digital name as a) wholly owned company.  Just a thought ...1   ------------------------------  % Date: Fri, 10 May 2002 21:50:33 -0400a2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: Powered by HPK Message-ID: <rdeininger-1005022150340001@1cust113.tnt2.nashua.nh.da.uu.net>   H In article <YGYC8.36976$GLp1.3995@news01.bloor.is.net.cable.rogers.com>,$ "John Smith" <a@nonymous.com> wrote:  L >HP can take one submission/petition, signed by thousands, and circular file >it very quickly.  > K >Hundreds of individual letters arriving daily from different customers are,? >harder to ignore. (It's the same way you  influence Congress).a >wJ >Get the Chairman/CEO/President/COO/CFO etc...as high as you can get to inL >your own organization to send the letter to Carly......you write it for him >if you have to  >t >Get them in the mail asap.    An excellent suggestion.  H I would add that copies of the letters should go to Scott Stallard, MarkI Gorham, and Peter Blackmore.  VMS gets Mark's undivided attention, and isrE a significant part of Scott's territory.  Scott is the new guy in thed# picture with high-octane authority.n  J Carly and Mike have a lot on their plate for the forseeable future, and weG have to admit that VMS is a pretty small part of the whole HP pie.  The1G only sane way for them to treat a small business like VMS is to rely onm4 the advice and wisdom of their lower-level managers.  I If Scott can be convinced of the value to HP of a healthy VMS business, I J expect he will help VMS whenever possible.  I suspect he is still learning> about the various business units he took charge of on Tuesday.   ------------------------------  # Date: Sat, 11 May 2002 02:32:49 GMTm1 From: "Terry C. Shannon" <terryshannon@attbi.com>n Subject: Re: Powered by HP- Message-ID: <lp%C8.20531$RR3.14526@sccrnsc02>e  1 "Bill Hobbs" <bdhobbs18@acm.org> wrote in messagen7 news:74ca5032.0205101738.3a890a11@posting.google.com...a< > "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in messageL news:<92EFB80E551BD511B39500D0B7B0CDCC0642C401@ohms.electric.ci.austin.tx.us >...F > > I agree, now how do we start?  We have folks with strong technical	 opinions,5K > > someone with media access (Hi Terry), and a user groups like Encompass,l orD > > DECUS at our disposal.  We also could probably recruit the folks handling > > the openvms.org site.t >iF > I wonder if HP could be convinced to resurrect the Digital name as a+ > wholly owned company.  Just a thought ...h  F Well, Digital India (now Digital GlobalSoft) has a lock on the name, I think...   ------------------------------  # Date: Sat, 11 May 2002 02:56:32 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Powered by HPB Message-ID: <AL%C8.137925$v7.12428408@bin6.nnrp.aus1.giganews.com>  < "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message+ news:abh80t$jt4$1@fizban.pprd.abbott.com...P$ > How do you know all this?  Really.  G Perhaps he simply takes Carly & Curly & Co. at their word that detailedyJ planning would be completed by the date of the merger and revealed at thatL time.  If one does believe that, then one would have to believe that cHomPaqL was so sensitive to the desires of its customers that it would be willing toI change its corporate mind after having devoted so much time and effort tor  making it up in the first place.  J But since neither company showed any such sensitivity separately, it's notG clear why one would hope that they would behave differently after beingaG merged.  Rather, since Compaq has certainly proven adept in the past atnI telling people what they want to hear while planning exactly the oppositeyK (and HP showed signs of doing the same with its treatment of MPE), it wouldp4 be reasonable to expect *that* behavior to continue.  4 Of course, some people never learn.  Fool me once...   - bill   >y > --	 > Dave...t >h+ > Adam and Eve had many advantages, but the / > principle one was that they escaped teething.  > -----Mark Twainn >l< > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message' > news:3CDC1246.F4AD65D@videotron.ca...i > > Dave Gudewicz wrote: > > >aI > > > Please write to Mr. Stallard and let him know how you feel.  I did,v andi > got  > > > an encouraging response. > >vJ > > And you'll find that while he tells you want you want to hear, he will > stillrI > > continue to say thigs publicly that caused you to write to him in theh > firsth
 > > place. > >oJ > > The policy has been set. Folks like Stallard are just implementing it. > FolkslK > > like Marcello are reluctantly forced to implement it or they are out ofn a  > job. > >oF > > Only Carly can change things and tell her underlings to change the policy > onK > > VMS and stop badmouthing VMS. As long as Carly doesn't change her mind,i > her  > > underlings won't.i >h >o >r   ------------------------------  # Date: Sat, 11 May 2002 02:58:24 GMTl* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Powered by HPB Message-ID: <jN%C8.129069$q8.13379173@bin3.nnrp.aus1.giganews.com>  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message& news:XCVC8.19391$WR1.6837@sccrnsc01... >e< > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message' > news:3CDC1246.F4AD65D@videotron.ca...  > > Dave Gudewicz wrote: > > >cI > > > Please write to Mr. Stallard and let him know how you feel.  I did,n andh > gotn > > > an encouraging response. > >eJ > > And you'll find that while he tells you want you want to hear, he will > stilluI > > continue to say thigs publicly that caused you to write to him in the  > firstw
 > > place. > >dJ > > The policy has been set. Folks like Stallard are just implementing it. > FolksmK > > like Marcello are reluctantly forced to implement it or they are out ofa af > job. >l: > If it's all set in stone, why even bother discussing it?  J There's certainly little point in discussing it with cHomPaq.  But as longL as people persist in the delusion that 'change for the better is just aroundG the corner, if we only believe hard enough' there's plenty of reason to  discuss it here.   - bill   ------------------------------  # Date: Sat, 11 May 2002 03:01:13 GMTh* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Powered by HPB Message-ID: <ZP%C8.137933$v7.12434191@bin6.nnrp.aus1.giganews.com>  < "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message+ news:abh9aa$k38$1@fizban.pprd.abbott.com...=G > My opinion.  Don't wait for a group to form to craft a message to thew powers > that be at hp.  Do it now.C > Most everyone here has similar thoughts on this subject.  While aa
 collectiveK > message sounds good, it'll take longer than forever to get the thing "out  > the door".  K Besides, some of us already tried the 'well-thought-out collective message' I approach, two years ago.  Failed completely.  At least if people just letiH their feelings be known individually, not nearly as much time and effort will be wasted.e   - bill   ------------------------------  # Date: Sat, 11 May 2002 03:07:37 GMTa* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Powered by HPB Message-ID: <ZV%C8.129090$q8.13390211@bin3.nnrp.aus1.giganews.com>  < "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message+ news:abhda6$koq$1@fizban.pprd.abbott.com...dJ > Some of the Rebel alliance lurk here and know this, the alliance can and has L > claimed victory despite overwhelming odds.  Let us not give in to the dark > side.  Never.h  J Let the Dark Side dangle some hope for VMS before the Rebels, and the manyK with weak minds will be suddenly convinced that they can deal with it after B all.  By the time they realize otherwise, all will have been lost.   - bill   >  > --	 > Dave...r >e+ > Adam and Eve had many advantages, but theo/ > principle one was that they escaped teething.h > -----Mark Twainn >lB > "Bob DeBula" <bobd@araminta.uts.ohio-state.edu> wrote in message6 > news:abhaut$9ar$1@charm.magnus.acs.ohio-state.edu...K > > JF Mezei  <jfmezei.spamnot@videotron.ca> carefully crafted electrons ton > say: > > > Dave Gudewicz wrote: > > > >fK > > > > Please write to Mr. Stallard and let him know how you feel.  I did,m	 > and gotb  > > > > an encouraging response. > > >yL > > > And you'll find that while he tells you want you want to hear, he will > still K > > > continue to say thigs publicly that caused you to write to him in the" > first" > > > place. > > >eL > > > The policy has been set. Folks like Stallard are just implementing it. > FolksrJ > > > like Marcello are reluctantly forced to implement it or they are out of > a job. > > >cH > > > Only Carly can change things and tell her underlings to change the > policy onmG > > > VMS and stop badmouthing VMS. As long as Carly doesn't change her  mind,e > her' > > > underlings won't.  > >rI > > cHomPaQ isn't a new opportunity. cHomPaQ is two delusional companies,eI > > sharing the same delusion of commodity PC profitability, if only they I > > play nicely enough with the Redmond Baron, becoming a reality if theyoC > > focus *everything* on it, instead of just most of the revenues.iI > > Ironically, both companies have sunken lower, faster, than might havetJ > > been the case by earlier embracing "visionary" CEOs that might as wellJ > > have been the Baron's Black Knights come to do his bidding, who helpedJ > > to divert lifeblood to the very same false dream. They haven't learned
 > > anything.w > >hD > > In their low corporate cunning way (displaying the same order ofJ > > magnitude of "intelligence" as a monkey that will continue to clutch aK > > nut when releasing it would allow it to remove it's paw from the hole), D > > they realize that switching over will take some time, so they'reB > > willing to keep dragging colorful pieces of yarn in front of aI > > community of customers, which they probably consider akin to a basketlK > > of hyperactive kittens, to keep their interest in the interim.  Make no H > > mistake, I don't think they want any part of HP-UX in the longer runI > > either.  From their lofty pinnacles, Windows Omega DS will eventuallyiH > > conquer all markets, no doubt.  Might as well get on board early andD > > the Baron may remember who his loyal ring kissers were when he'sE > > handing out parcels of land later.  As a corporate power, they'reoH > > deceased, they just haven't had the decency to realize it yet and toK > > lie down and to stop clutching the children that might survive on theirr? > > own if unfettered by the rotting corp before it's too late.  > >iG > > So, pack up and head for one of the two companies that haven't soldoH > > their dreams for the promise of paperclips dancing in their heads orK > > head for the Linux camp and try to reconstruct some of what's been lost=E > > or help to build something better.  The Rebel alliance won't help K > > defend VMS, they're concentrating their efforts elsewhere, on surviving F > > and eventually coming up with an effective counterattack. Join theC > > Alliance and help to build an offense that'll take out the eviloJ > > empires' domination of the market. The legal system can't/won't do it,J > > the politicians can't/won't do it, only the techies can do it en masseK > > by offering a better alternative.  Sorry, but VMS isn't it, though somenF > > piece of it may survive if you contribute some of your visions andH > > talents from the old dream into the new dream and help to perpetuate$ > > the good in the next generation. > >aE > > Yes, I know I'll hear a lot of "you're soooo wrong" comments, butuA > > let's get together over a cup of java in about five years and " > > compare notes again, shall we? > >s > >f > >eJ =========================================================================== > >               Disclaimer: These are my views, not the U's. > >tB > >         "If it's in the paper it must be true!" --- D. Doright > >e >  >l   ------------------------------  # Date: Sat, 11 May 2002 02:34:19 GMTt+ From: "Kenneth Farmer" <kfarmer@farmer.org>e Subject: Re: Powered by HP? Message-ID: <Lq%C8.61409$gd5.25266752@typhoon.southeast.rr.com>   : "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in messageL news:92EFB80E551BD511B39500D0B7B0CDCC0642C401@ohms.electric.ci.austin.tx.us. ..D > I agree, now how do we start?  We have folks with strong technical	 opinions, L > someone with media access (Hi Terry), and a user groups like Encompass, orK > DECUS at our disposal.  We also could probably recruit the folks handling  > the openvms.org site.w >  > --> EdG > **Please apply a generous amount of all the usual disclaimers here.**a >c     Ed,e  K I have put up a forum on OpenVMS.org.  Anyone is welcome to place a commentsH in this forum (as long as they remain civil).  The comments will then be2 viewable by all, including HP's command structure.  I Folks.  If your going to leave a comment say something that will help thesH cause.  I can assure you they are more likely to be visiting OpenVMS.orgJ then reading the newsgroups, don't spoil the opportunity to speak directly. to the management (mid-level managers anyway).  	 <soapbox> G Also, just to let you know, I will not allow the forum to be used for a1L constant, nonstop (sorry, that just came out) barrage of insults.  Remember,K Logical arguments are much harder to ignore, and they WILL ignore the forum. if it becomes hostile.
 </soapbox>  I I would like to see it became a repository of testimonials promoting VMS. I You will then be able to point Scott Stallard or whomever directly to the E forum where an archive can be read.  I would post as few responses asIL possible and make each comment a new topic.  Much easier to read and follow.  $ Here is your chance to build a case:  * http://www.openvms.org/phorum/list.php?f=4     Ken    --   Kenneth Farmer http://www.Tru64.org http://www.OpenVMS.org http://www.LinuxHPTC.com   ------------------------------  % Date: Sat, 11 May 2002 00:16:32 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>d Subject: Re: Powered by HP, Message-ID: <3CDC9B20.21963696@videotron.ca>   Robert Deininger wrote:fL > Carly and Mike have a lot on their plate for the forseeable future, and weI > have to admit that VMS is a pretty small part of the whole HP pie.  ThetI > only sane way for them to treat a small business like VMS is to rely on 6 > the advice and wisdom of their lower-level managers.  K I am not 100% sure about that. Next monday start the rounds of layoffs thatb will last 6 to 9 months.    M Carly, Curly, Winkler and the gang have set out a very clear product roadmap,TN and for any manager to go and tell them it isn't right would increase of their losing their job.3  L At this pont in time, the most effective way to reach Carly woudl be through the media and advertising.  I Imagine the effect of VMS customers purchasing a full page ad in the WallaN Street Journal with a letter addressed to Carly explaining the great potentialM of VMS, mentioning its high profitability, and how its dismissal brought down,N both Digital and Compaq and that she should take a close look at its potentialE not only to grow and expand, but also to make HP far more profitable.   N Carly would have to take notice, especially if the letter were signed by a few very large VMS customers.,  N Heck, one might go further and if there is support from customers even mentionL how HP and Compaq lied when they said they had support from their customers.   ------------------------------   Date: 11 May 2002 05:27:18 GMT- From: djweath@attglobal.net (Dave Weatherall)s Subject: Re: Powered by HP5 Message-ID: <DTiotGxQ0bj6-pn2-doZHNzWPkN2d@localhost>   B On Thu, 9 May 2002 15:20:45 UTC, prune@ZAnkh-Morpork.mv.com (Paul  Winalski) wrote:  D > On Thu, 9 May 2002 10:59:54 -0400, "John Vottero" <John@mvpsi.com> > wrote: > K > >It will be interesting to see what the Compaq sponsored Williams F1 carscL > >look like this weekend.  Of course, they're doing much better than the HP< > >sponsored Jordan team so maybe they'll stick with Compaq. > C > Even more interesting is whether HPQ will continue to sponsor twoH1 > F1 teams, and if not, which one will they drop?E  D More problems for Eddie - maybe that's why he right-sized his staff - recently. I've never noticed the Hp stickers.u   -- o Cheers - Dave.   ------------------------------  % Date: Fri, 10 May 2002 16:57:25 -0400-2 From: norm lastovica <norman.lastovica@oracle.com>  Subject: Re: simh VAX VMS users?* Message-ID: <3CDC3435.5119912F@oracle.com>  F This isn't exactly an Rdb-specific event, but I thought that I'd shareE some information about the SIMH VAX simulator running VAX/VMS and RdboK on a W2000 PC and an OpenVMS Alpha system.  You might find this interesting B (and, of course, if not, please delete before reading further :-).  7 Visit http://simh.trailing-edge.com where you can read:r  B "The Computer History Simulation Project is a loose Internet-basedF collective of people interested in restoring historically significant F computer hardware and software systems by simulation.  The goal of theE project is to create highly portable system simulators and to publish B them as freeware on the Internet, with freely available copies of ( significant or representative software."  H There are a bunch of machines simulated (including DG, IBM, DEC, and HP)K But of most interest here is Digital Equipment Corporation VAX.  Check backsJ often, as they've been actively improving the simulator.  Disk performanceI improvements are expected along with some work on an network interface of 
 some sort.  < You can also use the commercial Charon-VAX simulator.  Visit. www.charon-vax.com for more information on it.  J Some hints to get going... It was, for me, easiest to use my OpenVMS AlphaJ system to get going.  Install the LDDRIVER tool (from the OpenVMS freeware CD)lG on an Alpha/VMS system to help make things much easier by allowing easyu( manipulation of container file contents.   On the Alpha/VMS system:  - 	$! create a couple contained files to be them" 	$! disks for the simulator system< 	$ MCR SYSGEN CREATE D0.DSK /SIZE=1953300 ! RA72 device size) 	$ MCR SYSGEN CREATE D1.DSK /SIZE=1953300b) 	$ SET FILE/CACHE=NO D%.DSK ! if VMS V7.3e. 	$! mount the container file as a logical disk. 	$! and copy the VAX/VMS distribution media CD 	$ LD CONN D1.DSK LDA101:< 	$ MOU/FOR LDA101:3 	$ BACKUP/IMAGE <yourCDwithVAXdistribution> LDA101:. 	$ DISM LDA101:n 	$ MOU/OVER=ID LDA101:8 	$! copy any PAKs & products (Rdb, C, BLISS, and so on),6 	$! command procedures or whatever to LDA101:[000000]. 	$ DISM LDA101:  	$ LD DISC LDA101:  = 	Then, if you want to use a PC, FTP these two container filesp? to your PC.  Edit the SETUP.INI file on the PC to reference ther correct D0/D1 files.@ 	Next, run SIMH.  At the prompt in the window, type DO SETUP.INIC and press return.  Once you get to the VAX >>> prompt, "BOOT DUA1". A At the standalone backup $ prompt, do "BACKUP/IMAGE VMS073.B/SAVE E DUA0:".  When that finishes, type CTRL/E to get back to SIMH and thenbH type "BOOT CPU" to get back to the VAX >>>.  Then "BOOT DUA0" and follow0 the instructions to finish the VMS installation.? 	Once VAX/VMS is running and you've installed the various PAKS, < you should be able to have your regular terminal emulator (IE prefer CRT from www.vandyke.com if you don't already have one) TELNETe? to localhost port 4000 and you should get to a username prompt.o9 	SIMH can be built on VMS or PC.  On VMS, use the commandqB UNZIP "-a" to make all of the text files have text file attributes< when you unpack.  Execute BUILD_VMS.COM to compile and link.C I use the latest C compiler (V6.5) and modified the build procedurec- to turn on lots of optimization just for fun.e= 	On the PC, I used visual studio.  The only tricky parts werehH adding the library for socket/network interface on the link information.D That and I had to change the references from, as I recall, fmod to aE unique name (I called it xfmod) in one of the modules when I compileda with optimization.   	Contents of my SETUP.INI:   load -r c:\simh\ka655.bino
 at dz 4000 set rq0 ra72 set rq1 ra72 att rq0 c:\simh\d0.dsk att rq1 c:\simh\d1.dsk set cpu 64m. boot cpu   ------------------------------    Date: 10 May 2002 14:51:03 -0700. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman)+ Subject: Re: simple disk-shadowing questionr< Message-ID: <343f30ae.0205101351.24b88ab@posting.google.com>  | Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KHKJ1BZLN0984VLY@sysdev.deutsche-boerse.com>...I > > > MUST members of shadow sets use allocation-class names, rather thana& > > > node-based names.  The docs say: > > > E > > >    In all of the following examples, the shadow set members usei8 > > >    the $allocation-class $ddcu: naming convention. > > > > > > > but don't say (at least not here) that this is REQUIRED. > > M > > I wrestled with that too.  (I wanted to keep "nodenames"$dev).  I believeCM > > the answer is "you have to define allocation class for shadowing", for at L > > least v7.3 which is where I was testing.  I would bet it is true for all > > versions though. > J > I found that this requirement is stated later on in the docs.  I'm sure F > it goes back to really old versions of VMS, and is still true today. > K > IIRC, it is because the name of the disk in the Storage Control Block is  ! > limited to a particular length.t    B The answer has already been posted (see quote below). Actually, itC doesn't quite add up. The allocation class can be from 0 to 255. SoDC $255$12char_label is actually 17 characters, which is one more than D allowed according to the quoted message. So something is wrong here,: unless the dollar signs are not included in the lock name.  E Disclaimer: JMHO; Alan E. Feldman; afeldman atski gfigroup dotski comt  
 [begin quote]e   Message 5 in thread / From: Mark D. Jilson (jilly@clarityconnect.com) ( Subject: Re: host-based shadow question  Newsgroups: comp.os.vmsa View this article only   Date: 2001-11-02 07:43:10 PST   u  F This is correct.  A volume label may be up to 12 characters and an SCSC node name is 6 characters thus too many characters for a lock valuei" block.  $n$label is 15 characters.   Keith Parris wrote:g > ~ > Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KA6WLFSLIQ8YAE79@sysdev.deutsche-boerse.com>...L > > Since allocation-port names ($n$) only make sense for dual-ported disks,I > > is it necessary to use these names, rather than the NODE$ names, wheneB > > specifying the members of a shadow set?  This is stated in the6 > > documentation, but I see no obvious reason for it. > G > I'm told it is because Volume Shadowing uses lock value blocks (whichrB > are limited to 16 bytes in size), and there is at least one caseD > where, given the data that needed to be included in the lock valueH > block, there was enough room for an allocation class field, but not anB > entire SCS nodename, in the space available for the device name.E > -------------------------------------------------------------------hE > Keith Parris | parris at encompasserve dot org | VMS consulting on:tF > Clusters, Disaster Tolerance, Internals, Performance, Storage & I/O  --  D Jilly - Working from Home in the Chemung River Valley - Lockwood, NY0  - jilly@clarityconnect.com   - Brett Bodine fan.  - Mark.Jilson@Compaq.com   - since 1975 or so,  - http://www.jilly.baka.com               -   [end quote]9   ------------------------------  % Date: Fri, 10 May 2002 15:05:29 -0400c* From: "rob kas" <rob@paychoice.nospam.com>: Subject: Re: SOT: Yo Andrew, you guys on a roll this week?3 Message-ID: <3cdc19f9$0$3341$8e9e3842@news.atx.net>    > Your cache drop a bit?      No More then XFS        >v8 > Andrew Harrison SUNUK Consultancy wrote in message ...	 > >Blimeyo > >r# > >Has Bob got a lost twin brother.  > >w
 > >Regards > >Andrew Harrison > >t > >Dan Allen wrote:h > >f! > >> ----- Original Message -----e* > >> From: "FedCIRC" <fedcirc@fedcirc.gov> > >> To: <FedCIRC-Community:> ' > >> Sent: Monday, May 06, 2002 4:45 PMhI > >> Subject: FedCIRC Advisory FA-2002-11 Heap Overflow in Cachefs Daemonl > >> (cachefsd)< > >> > >> > >> > >>>a' > >>>-----BEGIN PGP SIGNED MESSAGE-----a > >>>rK > >>>FedCIRC Advisory FA-2002-11 Heap Overflow in Cachefs Daemon (cachefsd)c > >>>y+ > >>>   Original release date: May 06, 2002d > >>>   Last revised:  > >>>   Source: CERT/CCr > >>>aI > >>>   A complete revision history can be found at the end of this file.i > >>>o > >>>  Systems Affectedo > >>>nL > >>>     * Sun Solaris 2.5.1, 2.6, 7, and 8 (SPARC and Intel Architectures) > >>> 
 > >>>Overviewc > >>> J > >>>   Sun's  NFS/RPC  file  system  cachefs daemon (cachefsd) is shipped andiJ > >>>   installed  by default with Sun Solaris 2.5.1, 2.6, 7, and 8 (SPARC andiK > >>>   Intel  architectures).  A remotely exploitable vulnerability existso inI > >>>   cachefsd that could permit a remote attacker to execute arbitrarye codeJ > >>>   with  the  privileges of the cachefsd, typically root. The CERT/CC has F > >>>   received  credible  reports  of  scanning  and exploitation of Solariso! > >>>   systems running cachefsd.c > >>>s > >>>I. Descriptiona > >>>sF > >>>   A  remotely  exploitable  heap overflow exists in the cachefsd program L > >>>   shipped and installed by default with Sun Solaris 2.5.1, 2.6, 7, and 8 I > >>>   (SPARC   and   Intel  architectures).  Cachefsd  caches  requestsl for D > >>>   operations on remote file systems mounted via the use of NFS	 protocol. E > >>>   A  remote  attacker  can  send  a  crafted RPC request to theh cachefsd- > >>>   program to exploit the vulnerability.r > >>>fA > >>>   Logs of exploitation attempts may resemble the following:r > >>>rJ > >>>May 16 22:46:08 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:% > >>>Segmentation Fault - core dumped  > >>>a> > >>>May 16 22:46:21 victim-host last message repeated 7 times > >>>hJ > >>>May 16 22:46:22 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd: > >>>Bus Error- core dumpedg > >>>uJ > >>>May 16 22:46:24 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:% > >>>Segmentation Fault - core dumpedh > >>>iJ > >>>May 16 22:46:56 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd: > >>>Bus Error - core dumped > >>>-= > >>>May 16 22:46:59 victim-host last message repeated 1 timeW > >>>OJ > >>>May 16 22:47:02 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:% > >>>Segmentation Fault - core dumpeda > >>>b> > >>>May 16 22:47:07 victim-host last message repeated 3 times > >>>fJ > >>>May 16 22:47:09 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd: > >>>Hangupe > >>>rJ > >>>May 16 22:47:11 victim-host inetd[600]: /usr/lib/fs/cachefs/cachefsd:% > >>>Segmentation Fault - core dumpedt > >>>yI > >>>   According  a  Sun  Alert Notification, failed attempts to exploitr thisJ > >>>   vulnerability  may  leave  a core dump file in the root directory. ThecC > >>>   presence  of the core file does not preclude the success ofo
 subsequentJ > >>>   attacks.  Additionally,  if  the  file  /etc/cachefstab exists, it mayi  > >>>   contain unusual entries. > >>> = > >>>   This issue is also being referenced as CAN-2002-0085:v > >>>yE > >>>     http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0085h > >>>bK > >>>   The  Australian  Computer  Emergency  Response Team has also issuedr anB > >>>   advisory related to incident activity exploiting cachefsd: > >>>, > >>>hJ > http://www.auscert.org.au/Information/Advisories/advisory/AA-2002.01.txt > >>>  > >>>II. Impacts > >>> K > >>>   A  remote  attacker may be able to execute code with the privilegese of- > >>>   the cachefsd process, typically root.t > >>>t > >>>III. Solution > >>>e& > >>>   Apply a patch from your vendor > >>> D > >>>   Appendix A contains information provided by vendors for this	 advisory.f > >>>nL > >>>   If  a  patch  is not available, disable cachefsd in inetd.conf until a= > >>>   patch can be applied.= > >>>=D > >>>   If  disabling  the  cachefsd  is  not  an option, follow the	 suggested 1 > >>>   workaround in the Sun Alert Notification.e > >>>s% > >>>Appendix A. - Vendor Informationl > >>>-I > >>>   This  appendix  contains  information  provided  by  vendors  forK thisI > >>>   advisory.  As  vendors  report new information to the CERT/CC, we% willL > >>>   update this section and note the changes in our revision history. If ay@ > >>>   particular  vendor is not listed below, please check the
 Vulnerabilityi9 > >>>   Note (VU#635811) or contact your vendor directly.  > >>>l > >>>    IBM > >>>cF > >>>     IBM's AIX operating system, all versions, is not vulnerable. > >>>E > >>>    SGI > >>> I > >>>     SGI does not ship with SUN cachefsd, so IRIX is not vulnerable.  > >>>. > >>>    Sun > >>> F > >>>     See     the     Sun     Alert     Notification     available atJ > >>>     http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F44309.I > >>>   _________________________________________________________________e > >>>lJ > >>>   The CERT/CC acknowledges the eSecurity Online Team for discovering andoH > >>>   reporting  on this vulnerability and thanks Sun Microsystems for theiru > >>>   technical assistance.iI > >>>   _________________________________________________________________t > >>> 2 > >>>   Feedback  can  be directed to the authors:/ > >>>   Jason A. Rafail and Jeffrey S. Havrilla  > >>>tF ______________________________________________________________________ > >>>t( > >>>   This document is available from:: > >>>   http://www2.fedcirc.gov/advisories/FA-2002-11.html > >>>.F ______________________________________________________________________ > >>>o  > >>>FedCIRC Contact Information > >>>i" > >>>   Email: fedcirc@fedcirc.govA > >>>          Phone: +1 888-282-0870 (24-hour toll-free hotline)d7 > >>>          Phone: +1 703-375-2222 (24-hour hotline)a# > >>>          Fax: +1 703-375-2427t > >>>aK > >>>   FedCIRC personnel answer the hotline 24 hours a day, 7 days a week.p > >>>i > >>>    Using encryption  > >>>tG > >>>   We  strongly  urge you to encrypt sensitive information sent byP email., > >>>   Our public PGP key is available from > >>> ) > >>>   http://www2.fedcirc.gov/keys.htmle > >>>oI > >>>   If  you  prefer  to  use DES, please call the FedCIRC hotline for6 more > >>>   information. > >>>w% > >>>    Getting security informationt > >>>aI > >>>   FedCIRC publications and other security information are availables from > >>>   our web site > >>>t > >>>   http://www.fedcirc.gov/a > >>>lE > >>>   FedCIRC  (Federal Computer Incident Response Center) providesw securityJ > >>>   services  to U.S. Federal civilian agencies. FedCIRC is managed by thesG > >>>   U.S.  General  Services  Administration.  The CERT Coordinationh CenterK > >>>   performs incident and vulnerability analysis and issues advisories.t > >>>rI > >>>   *  "CERT"  and  "CERT  Coordination Center" are registered in theh U.S.$ > >>>   Patent and Trademark Office. > >>>hF ______________________________________________________________________ > >>>a > >>>   NO WARRANTYWE > >>>   Any  material furnished by Carnegie Mellon University and thee SoftwareE > >>>   Engineering  Institute  is  furnished  on  an  "as is" basis.o CarnegieK > >>>   Mellon University makes no warranties of any kind, either expressedi orK > >>>   implied  as  to  any matter including, but not limited to, warrantyl ofK > >>>   fitness  for  a  particular purpose or merchantability, exclusivityl orC > >>>   results  obtained from use of the material. Carnegie Mellont
 UniversityI > >>>   does  not  make  any warranty of any kind with respect to freedomo from5 > >>>   patent, trademark, or copyright infringement.  > >>>22 > >>>   Copyright 2002 Carnegie Mellon University. > >>>a > >>>   Revision History) > >>>      May 06, 2002:  Initial releasez > >>>l" > >>>-----BEGIN PGP SIGNATURE----- > >>>Version: PGP 6.5.8r > >>>.E > >>>iQEVAwUBPNbqgIBMzw7XZGn/AQEJwggAgEFMO8YIsP/0I2XHStYlZLJDoBx5jB9MoE > >>>MuUWsTtYBbrnoyu6sJhpo3GjshT+k2k5kj9PjbmFLmqfUShmM3G/W3yc21D2w8M3oE > >>>9ogIpwBZXAYIEiLRKkqFdBqcUn2dE8mixAOW3AvrqZb54CwQxkVFLVshkYHIRSsNkE > >>>lJz7zfAaw7bDqXTc9OrI/TBFdkPR9rHBJpyQgtxzKzThcawwTu+LfEl8ZlxQizaOrE > >>>Ofu1cA/4phBe4WO/KnSQKmKACHhFZsoO2hSTdRwx9t3hq9zaoleS2oB1EHHspuqmn= > >>>k6LqSobTuYsD3sHE2c9bGPyNj4KUkyLpYicYRxzPEn3RWtDQbebvzw== 
 > >>>=MrUe  > >>>-----END PGP SIGNATURE----- > >>>o > >>>  > >> > >> > >> > >i >- >e   ------------------------------  % Date: Fri, 10 May 2002 13:10:02 -0700s0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com># Subject: Re: Stallards smoking gun!r+ Message-ID: <3CDBC6AA.542D047@Mvb.Saic.Com>o   Carl Karcher wrote:A > B > In a previous article, bob@instantwhip.com (Bob Ceculski) wrote: > L > ->I could care less about anyone else ... as long as I have vms and I haveL > ->support, let everyone else get shut down ... I will be up, the company IO > ->work for will be up 99.9999, and I will be just fine ... for those who fail  > ->...f > D > Come on Bob, while I have a similar mantra, that's six nines or 31H > seconds of downtime a year if I did the math correctly. Even VMS would% > be hard pressed to accomplish that.  >   E Hard pressed, perhaps, but doable.  I've got a cluster that's been upsF steady for over 2 years (which is when I built it), with zero downtimeE to the user community.  However, every node in the cluster is runningh8 the current version of VMS and is up-to-date on patches.  G Rolling upgrades and rolling maintenance with zero downtime to users is D a big benefit of VMS.  So, yes, six nines is most definitely doable.  
 Mark Berrymanc Mark.Berryman@Mvb.Saic.Com   ------------------------------    Date: 10 May 2002 13:11:11 -0700( From: bob@instantwhip.com (Bob Ceculski)# Subject: Re: Stallards smoking gun! = Message-ID: <d7791aa1.0205101211.395e8bb5@posting.google.com>n  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3CDAFA0F.5C8CCF08@videotron.ca>...O > Bob Ceculski wrote: L > > > Where is that famous secret letter you were so proudly talking about ? > > G > > vms has survived and will survive as I said, however, that does notnD > > mean the fight has ended ... this proves the same mentality that@ > > existed in Q has popped up in HP, and it must be confronted! > L > Go back to your original statement about the letter. HP was supposed to be9 > doing great things with VMS tyat we all be happy about.  > K > None of that has happened. The statement by Stallard puts VMS on the sameVN > footing as Tru64. You cannot take the product roadmap by itself. You have toP > consider that Carly has , for 8 months, taken active steps NOT to mention VMS.H > You have to consider that, in the roadmap,  VMS takes up one line thatN > essentially says that HP won't break contractual commitments that Compaq hadM > made with customers. Nothing about fixing the lack of marketing or allowingy > VMS to grow. > J > And then comes the Stallard golden nugget about HP wishing VMS customers > migrate to HP-UX.n > M > HP hasn't had the guts to make the same declaration as it did for Tru64. ItpP > doesn't need to because VMS is obscure and HP need not explain it to the mediaP > (HP had to for Tru64 because HP had to show it was eliminating the duplication > of 2 proprietary Unix).e > O > But the fact remains that HP has given strong hints of its intentions. If youoM > choose not to heed this, you will be caught with your pants down. Check outdM > how quickly Carly moved on the logos etc etc. She won't be wasting any time. > with VMS.n  G Sorry, but because of jstars and the DOD and others (i.e. Cerner), theyaF can't do that ... a little thing called contracts ... and those in theF gov. who are smart will not step backwards onto a no-security platformG like windoze or unix or linux ... nope, I am all set thru at least 2011h7 and if the itanium port goes well, longer than that ...r   ------------------------------  % Date: Fri, 10 May 2002 16:38:47 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>t# Subject: Re: Stallards smoking gun!c, Message-ID: <3CDC2FD3.633AB951@videotron.ca>  > Just read the famous PDF containing the STallard damning text.  L What I found interesting is the wording used to specify that VMS developmentE will continue ON ALPHASERVERS until 2006. And very separately, almoste; deemphasized, it is stated that the port to IA64 continues.s  R If HP had long term intentions with VMS, they would have worded something such as:I "We plan to continue to provide new versions on ALPHA servers until 2006,:6 after which new versions will appear only on Itanium".  T It sesms to me that HP doesn't really have any intentions to productize VMS on IA64.   ------------------------------  % Date: Fri, 10 May 2002 16:56:08 -0400c- From: "Peter Weaver" <peter.weaver@stelco.ca>l# Subject: Re: Stallards smoking gun! 5 Message-ID: <abhc5v$i9kmm$1@ID-141708.news.dfncis.de>I  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CDC2FD3.633AB951@videotron.ca...@ > Just read the famous PDF containing the STallard damning text. >tB > What I found interesting is the wording used to specify that VMS developmentaG > will continue ON ALPHASERVERS until 2006. And very separately, almostc= > deemphasized, it is stated that the port to IA64 continues.a >eK > If HP had long term intentions with VMS, they would have worded somethingh such as:K > "We plan to continue to provide new versions on ALPHA servers until 2006,y8 > after which new versions will appear only on Itanium". >tI > It sesms to me that HP doesn't really have any intentions to productizee VMS on IA64.   JF PLEASE LEARN TO READ!  I "Finally, hp OpenVMS remains a strategic product and we will continue thep- port of OpenVMS to Itanium-based hp servers."D  H "In addition, consistent with HP's overall strategy of converging on theL Itanium Processor Family, OpenVMS is being ported to Itanium, thus providingH a stable and long-term path for our customers. This port is already wellH underway, with a target availability for early developers in 2003, and aJ full production version in 2004. We are also working very closely with ourK ISV software partners and our goal is to have 100% of our existing partnersn port to Itanium."-  L "Q: How is the Itanium port going? A: This project is right on track, and weJ expect to have an initial boot at the end of 2002, an early developers kit7 in 1H 2003, with a full production version in 1H 2004."r  L HOW ON EARTH DO YOU GET THAT TO BE "HP doesn't really have any intentions to productize VMS on IA64??????"@   -- Peter WeaverL Opinions are my own, and do not reflect the opinions of my employer, nor theK company that it sub-contracts to, nor the company that it sub-contracts to.e   ------------------------------  % Date: Fri, 10 May 2002 16:21:32 -0500e1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>r# Subject: Re: Stallards smoking gun!l1 Message-ID: <abhdpb$krl$1@fizban.pprd.abbott.com>   K Thanks for the clear reasoning John.  And keep up the good work back in VMSe land.h  F At least TNN had sense enough to broadcast ST TNG.  TNN = The NationalJ Network in the US, for those wondering.  Hope I need not explain ST TNG to this group!  ;-)   -- Dave....  ) Adam and Eve had many advantages, but the-- principle one was that they escaped teething.r -----Mark Twainr  3 "John Reagan" <john.reagan@hp.com> wrote in messageT news:3CDC36E0.3000306@hp.com...  > JF Mezei wrote: B > > Just read the famous PDF containing the STallard damning text. > >-D > > What I found interesting is the wording used to specify that VMS development I > > will continue ON ALPHASERVERS until 2006. And very separately, almost ? > > deemphasized, it is stated that the port to IA64 continues.  > >cC > > If HP had long term intentions with VMS, they would have wordedd something such as:G > > "We plan to continue to provide new versions on ALPHA servers until  2006,c: > > after which new versions will appear only on Itanium". > >oK > > It sesms to me that HP doesn't really have any intentions to productizel VMS on IA64. > I > This is getting worse than watching the Conspiracy Zone on TNN.  Please E > don't take each statement and put it through the "paranoid filter"..3 > Next we'll be asking what the meaning of "is" is.a >MJ > If Compaq/HP didn't plan to productize OpenVMS on Itanium, they sure areI > paying me money for nothing then (as well as paying lots of other folks- > for nothing).M >A > Just my opinion. >F > --
 > John Reagan0) > Compaq Pascal/{A|I}MACRO Project Leaderf >c   ------------------------------  # Date: Fri, 10 May 2002 21:14:02 GMTs& From: John Reagan <john.reagan@hp.com># Subject: Re: Stallards smoking gun!a% Message-ID: <3CDC36E0.3000306@hp.com>    JF Mezei wrote:s@ > Just read the famous PDF containing the STallard damning text. > N > What I found interesting is the wording used to specify that VMS developmentG > will continue ON ALPHASERVERS until 2006. And very separately, almostt= > deemphasized, it is stated that the port to IA64 continues.  > T > If HP had long term intentions with VMS, they would have worded something such as:K > "We plan to continue to provide new versions on ALPHA servers until 2006,e8 > after which new versions will appear only on Itanium". > V > It sesms to me that HP doesn't really have any intentions to productize VMS on IA64.  H This is getting worse than watching the Conspiracy Zone on TNN.  Please D don't take each statement and put it through the "paranoid filter". 1 Next we'll be asking what the meaning of "is" is.l  I If Compaq/HP didn't plan to productize OpenVMS on Itanium, they sure are  H paying me money for nothing then (as well as paying lots of other folks 
 for nothing).f   Just my opinion.   --   John Reaganr' Compaq Pascal/{A|I}MACRO Project Leadern   ------------------------------  % Date: Fri, 10 May 2002 17:59:54 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>x# Subject: Re: Stallards smoking gun!f, Message-ID: <3CDC42D1.7403B67B@videotron.ca>   Peter Weaver wrote:/N > HOW ON EARTH DO YOU GET THAT TO BE "HP doesn't really have any intentions to > productize VMS on IA64??????"e  N Because when they mention VMS development, it is specific to alphaservers. AndN itanium is not mentioned wenever they discuss development/improvements on VMS.  L Again, remember that they had 8 months to wordsmith this and one MUST assume that every word counts.i  L I see no wording that says that they will continue to develop VMS on itanium' once development stops on alpha server.M  N The could have said "once the port to Itanium is complete in 2004, developmentH of VMS on both platforms will continue for at least 2 years, after whichL development will be focused on IA64 with only maintenance releases to ensure< interoperability on Alpha". That would have been very clear.  M Also, did I see the word VAX mentioned anywhere ?  Is VAX-VMS retired already: and nobody knows ?   ------------------------------  % Date: Fri, 10 May 2002 18:06:00 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>f# Subject: Re: Stallards smoking gun! , Message-ID: <3CDC443F.731AAE09@videotron.ca>   John Reagan wrote:I > This is getting worse than watching the Conspiracy Zone on TNN.  PleaseeE > don't take each statement and put it through the "paranoid filter".e3 > Next we'll be asking what the meaning of "is" is.n  G THIS IS TO BE SEEN AS OFFICIAL DOCUMENTS. HP TOOK THE TIME TO CAREFULLY2F WORDSMITH THIS. IT IS OUR DUTY TO ANALYSE EVERY WORD BECAUSE THERE ARE OPPOSING WORDING.   N How can you claim long term commitment to VMS wben some top guy says that they+ expect VMS customers to migrate to HP-UX ? a  M How can you claim long term commitment to VMS when the text specifically saystH that developpment will happen on Alphaservers and no mention of IA64 for
 development ?t  G If they didn't read through their texts during the 8 months they had tohL prepare them, then they truly are a bunch of incompetent twits. And I do notJ believe they are. They carefully worded the message that they wanted out.   J > If Compaq/HP didn't plan to productize OpenVMS on Itanium, they sure areI > paying me money for nothing then (as well as paying lots of other folks  > for nothing).    INTEL IS PAYING FOR THE PORT.e   ------------------------------  % Date: Fri, 10 May 2002 17:00:06 -0500i+ From: Christopher Smith <csmith@amdocs.com>A# Subject: RE: Stallards smoking gun!>J Message-ID: <7E008308CD77154485FEF878168D078E017845C8@CMIMAIL1.amdocs.com>   --=_IS_MIME_Boundary Content-Type: text/plain;w 	charset="iso-8859-1"T   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]  > > If they didn't read through their texts during the 8 months 
 > they had tor; > prepare them, then they truly are a bunch of incompetent e > twits. And I do not @ > believe they are. They carefully worded the message that they   = You don't?  They did get rid of their scientific instruments,o@ etc, didn't they?  Need I even mention that they believe windows2 is up to the task of running a computer system? ;)   Chrisr    ! Christopher Smith, Perl Developer  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-asciie Content-Transfer-Encoding: 7bitr Content-Disposition: inlinee  U -------------------------------------------------------------------------------------   C The information contained in this message is proprietary of Amdocs,_1 protected from disclosure, and may be privileged. N 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. _N 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 -------------------------------------------------------------------------------------i   --=_IS_MIME_Boundary--   ------------------------------  # Date: Fri, 10 May 2002 23:55:23 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>g# Subject: Re: Stallards smoking gun!o, Message-ID: <L5ZC8.20613$WR1.7321@sccrnsc01>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CDC2FD3.633AB951@videotron.ca...@ > Just read the famous PDF containing the STallard damning text. >cB > What I found interesting is the wording used to specify that VMS developmentgG > will continue ON ALPHASERVERS until 2006. And very separately, almostc= > deemphasized, it is stated that the port to IA64 continues.  >tK > If HP had long term intentions with VMS, they would have worded somethingr such as:K > "We plan to continue to provide new versions on ALPHA servers until 2006,i8 > after which new versions will appear only on Itanium".  G That would have been much better (and reassuring) wording, sans doubte!e >r  I > It sesms to me that HP doesn't really have any intentions to productize  VMS on IA64.  J If that was the case, why would they continue with the port (which is justJ about a done deal anyhow)? Once VMS is on IA64, at least the option exists to leverage the product.   ------------------------------  # Date: Fri, 10 May 2002 23:59:46 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>e# Subject: Re: Stallards smoking gun!a- Message-ID: <S9ZC8.19567$RR3.10960@sccrnsc02>i  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CDC42D1.7403B67B@videotron.ca... > Peter Weaver wrote:dB > > HOW ON EARTH DO YOU GET THAT TO BE "HP doesn't really have any
 intentions to ! > > productize VMS on IA64??????"o >iL > Because when they mention VMS development, it is specific to alphaservers. And K > itanium is not mentioned wenever they discuss development/improvements ond VMS.  J OK, another possible interpretation. Absent the port, which will require aK couple of dozen engineers, VMS is VMS. hence whatever is enhanced for AlphaaK should play on IPF. No V5.4 code-freeze as we had in the VAX to Alpha daysl.   > F > Again, remember that hey had 8 months to wordsmith this and one MUST assume > that every word counts.s  L But, can we assume that the statements were sanity-checked/message-tested byH an outsider? An outside perspective often makes all the difference (I'llJ betcha JF would have been real quick to pick up on the apparent omission.)   >qF > I see no wording that says that they will continue to develop VMS on itanium=) > once development stops on alpha server.- >-D > The could have said "once the port to Itanium is complete in 2004, development J > of VMS on both platforms will continue for at least 2 years, after whichG > development will be focused on IA64 with only maintenance releases toA ensure> > interoperability on Alpha". That would have been very clear. >lG > Also, did I see the word VAX mentioned anywhere ?  Is VAX-VMS retiredb alreadye > and nobody knows ?  K To all intents and purposes VAX is, well, pretty much retired. I am unawaree) of any plans for a VAX-to-IPF translator.    ------------------------------  # Date: Sat, 11 May 2002 00:01:36 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>s# Subject: Re: Stallards smoking gun! , Message-ID: <AbZC8.20671$WR1.8206@sccrnsc01>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CDC443F.731AAE09@videotron.ca... > John Reagan wrote:K > > This is getting worse than watching the Conspiracy Zone on TNN.  PleaseeG > > don't take each statement and put it through the "paranoid filter".r5 > > Next we'll be asking what the meaning of "is" is.l > I > THIS IS TO BE SEEN AS OFFICIAL DOCUMENTS. HP TOOK THE TIME TO CAREFULLYeH > WORDSMITH THIS. IT IS OUR DUTY TO ANALYSE EVERY WORD BECAUSE THERE ARE > OPPOSING WORDING.. >cK > How can you claim long term commitment to VMS wben some top guy says thatr they, > expect VMS customers to migrate to HP-UX ? >aJ > How can you claim long term commitment to VMS when the text specifically saysJ > that developpment will happen on Alphaservers and no mention of IA64 for > development ?r >cI > If they didn't read through their texts during the 8 months they had touJ > prepare them, then they truly are a bunch of incompetent twits. And I do notIK > believe they are. They carefully worded the message that they wanted out.t >s  K Indeed, the wording appears quite polished. But I daresay it was not vettedn by an outsider.c   ------------------------------  # Date: Sat, 11 May 2002 00:03:25 GMTo1 From: "Terry C. Shannon" <terryshannon@attbi.com>t# Subject: Re: Stallards smoking gun!T, Message-ID: <hdZC8.20683$WR1.8414@sccrnsc01>  8 "Christopher Smith" <csmith@amdocs.com> wrote in messageD news:7E008308CD77154485FEF878168D078E017845C8@CMIMAIL1.amdocs.com... > > -----Original Message-----8 > > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] >o? > > If they didn't read through their texts during the 8 monthsc > > they had too< > > prepare them, then they truly are a bunch of incompetent > > twits. And I do notyA > > believe they are. They carefully worded the message that theyb > ? > You don't?  They did get rid of their scientific instruments,aB > etc, didn't they?  Need I even mention that they believe windows4 > is up to the task of running a computer system? ;)  C Windoze issues aside (thank God!), it is true that HWP spun off its L medical/scientific instruments. Have you ever given any consideration to theJ possibility that one reason for the spinoff was limitation of exposure. AsG in Y2K-related issues? Just a thought, not an apology for the decision.d   ------------------------------  % Date: Fri, 10 May 2002 21:25:31 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>a# Subject: Re: Stallards smoking gun!r, Message-ID: <3CDC7309.3A4318F5@videotron.ca>   "Terry C. Shannon" wrote:nM > Indeed, the wording appears quite polished. But I daresay it was not vettedi > by an outsider.o  M If it had been vetted by an outsider, HP would have removed/changed the partswL which were a dead giveaway of its true intentions. In a way I much prefer HPN to be honest with customers and make it obvious enough without actually sayingS it, as opposed to giving customers lots of false hopes that will never materialise.r  H VMS , Alpha and Tru64 are in the Legacy department, won't be sold to new" customers. That is pretty obvious.  H Now, if HP were to provide from VMS-to-UNIX training to all of use whoseM skills have been made redundant, perhaps our appreciation for HP might not bes so negative.   ------------------------------  % Date: Fri, 10 May 2002 21:19:04 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> # Subject: Re: Stallards smoking gun!c, Message-ID: <3CDC7187.80625270@videotron.ca>   "Terry C. Shannon" wrote:nL > If that was the case, why would they continue with the port (which is justL > about a done deal anyhow)? Once VMS is on IA64, at least the option exists > to leverage the product.  I If the port is funded by Intel HP loses nothing by continuing it. If theysJ announce the port is cancelled, they won't save money, may have to lay offJ additional employees, and more importantly, customers would leave VMS much faster than anticipatedx  L Until HP-UX on IA64 is a commercial reality, HP has no choice but to pretendL that VMS continues since the desired migration can't happen until the target platform exists.  J HP does not want to be in a situation where it tells its customers "VMS is2 dead and we don't yet have a replacement product".   ------------------------------  # Date: Sat, 11 May 2002 01:39:25 GMTv1 From: "Terry C. Shannon" <terryshannon@attbi.com>p# Subject: Re: Stallards smoking gun!s- Message-ID: <hD_C8.20149$RR3.13788@sccrnsc02>n  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CDC7309.3A4318F5@videotron.ca... > "Terry C. Shannon" wrote: H > > Indeed, the wording appears quite polished. But I daresay it was not vetted > > by an outsider.t > I > If it had been vetted by an outsider, HP would have removed/changed theI parts K > which were a dead giveaway of its true intentions. In a way I much preferl HPI > to be honest with customers and make it obvious enough without actuallya sayingH > it, as opposed to giving customers lots of false hopes that will never materialise. >nJ > VMS , Alpha and Tru64 are in the Legacy department, won't be sold to new$ > customers. That is pretty obvious. >AJ > Now, if HP were to provide from VMS-to-UNIX training to all of use whoseL > skills have been made redundant, perhaps our appreciation for HP might not be > so negative.  K About a year ago I had a discussion with a CPQ UNIX person who shall remainoK nameless. Given that a significant number of VMS emigres go to non-CPQ UNIXdE platforms, I suggested a VMS-Tru64 UNIX Affinity and Interoperabilityu$ Program (none dare say "migration").  : The idea was turned down by some nameless folks in VMSland   ------------------------------  # Date: Sat, 11 May 2002 01:39:26 GMT@1 From: "Terry C. Shannon" <terryshannon@attbi.com> # Subject: Re: Stallards smoking gun!.- Message-ID: <iD_C8.20150$RR3.13436@sccrnsc02>J  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CDC7187.80625270@videotron.ca... > "Terry C. Shannon" wrote:wI > > If that was the case, why would they continue with the port (which iss justG > > about a done deal anyhow)? Once VMS is on IA64, at least the optionn exists > > to leverage the product. >rK > If the port is funded by Intel HP loses nothing by continuing it. If theyeL > announce the port is cancelled, they won't save money, may have to lay offL > additional employees, and more importantly, customers would leave VMS much > faster than anticipatedf >hF > Until HP-UX on IA64 is a commercial reality, HP has no choice but to pretendrG > that VMS continues since the desired migration can't happen until thei target > platform exists.  L Even when the platform exists, if customers don't want to migrate, why forceF 'em to? Especially if the end result is a migration to Solaris or AIX?   > L > HP does not want to be in a situation where it tells its customers "VMS is4 > dead and we don't yet have a replacement product".  L Some might argue that the only replacement product (in the HPQ portfolio) is NSK. Just a thought...   ------------------------------  # Date: Sat, 11 May 2002 01:42:03 GMT 1 From: LESLIE@JRLVAX.HOUSTON.RR.COM (Jerry Leslie)a# Subject: Re: Stallards smoking gun!r; Message-ID: <LF_C8.72071$9F5.3888661@typhoon.austin.rr.com>   . JF Mezei (jfmezei.spamnot@videotron.ca) wrote: : "Terry C. Shannon" wrote: N : > If that was the case, why would they continue with the port (which is justN : > about a done deal anyhow)? Once VMS is on IA64, at least the option exists : > to leverage the product. : K : If the port is funded by Intel HP loses nothing by continuing it. If they0L : announce the port is cancelled, they won't save money, may have to lay offL : additional employees, and more importantly, customers would leave VMS much : faster than anticipated  : N : Until HP-UX on IA64 is a commercial reality, HP has no choice but to pretendN : that VMS continues since the desired migration can't happen until the target : platform exists. : L : HP does not want to be in a situation where it tells its customers "VMS is4 : dead and we don't yet have a replacement product". : 5 AFAIK, HP will sell you a system based on IA64 today:t  :    http://www.hp.com/techservers/products/itanium/why.html:    hewlett-packard high performance technical computing / $    why the Itanium processor family?  <    http://www.hp.com/techservers/products/itanium/index.html:    hewlett-packard high performance technical computing / #    Itanium processor family serversS    H HP completed the port of HP-UX, and then laid off most of the conversion team.s  H --Jerry Leslie   leslie@clio.rice.edu  (my opinions are strictly my own)9   Note: leslie@jrlvax.houston.rr.com is invalid for email-   ------------------------------  # Date: Sat, 11 May 2002 02:37:32 GMT<1 From: "Terry C. Shannon" <terryshannon@attbi.com>r# Subject: Re: Stallards smoking gun!D- Message-ID: <Mt%C8.20557$RR3.14881@sccrnsc02>/  > "Jerry Leslie" <LESLIE@JRLVAX.HOUSTON.RR.COM> wrote in message5 news:LF_C8.72071$9F5.3888661@typhoon.austin.rr.com...a0 > JF Mezei (jfmezei.spamnot@videotron.ca) wrote: > : "Terry C. Shannon" wrote:uK > : > If that was the case, why would they continue with the port (which isg justI > : > about a done deal anyhow)? Once VMS is on IA64, at least the optione exists > : > to leverage the product. > :aH > : If the port is funded by Intel HP loses nothing by continuing it. If theyJ > : announce the port is cancelled, they won't save money, may have to lay off0I > : additional employees, and more importantly, customers would leave VMS, much > : faster than anticipatedo > : H > : Until HP-UX on IA64 is a commercial reality, HP has no choice but to pretendwI > : that VMS continues since the desired migration can't happen until ther target > : platform exists. > :nK > : HP does not want to be in a situation where it tells its customers "VMS1 is6 > : dead and we don't yet have a replacement product". > :u7 > AFAIK, HP will sell you a system based on IA64 today:.  H Indeed they will. Rumour has it that HP (now HPQ) has a bunch of ItaniumI II/McKinley systems all ready to ship, whenever Intel gives the word. ThenK old CPQ has 4-way, 8-way, and 32-way McKinley boxes waiting in the wings asnC well. Just waiting for the right weather conditions, e.g. Tornados,  Typhoons, and Cyclones.O   ------------------------------  % Date: Sat, 11 May 2002 00:09:26 -0400I- From: JF Mezei <jfmezei.spamnot@videotron.ca>m# Subject: Re: Stallards smoking gun!t, Message-ID: <3CDC9976.DA0D77D1@videotron.ca>   "Terry C. Shannon" wrote: N > Some might argue that the only replacement product (in the HPQ portfolio) is > NSK. Just a thought...  L I brought that up a long time ago. A certain percentage of VMS sites will beM forced to go to NSK because Unix won't have the reliability needed, while theu rest will go Unix.  F VMS didn't fill a gap between two product lines, it sat on their laps.  N From the "accountant" point of view, eliminating VMS makes sense. But from theN visionary point of view, eliminating a product with great profit potential andA great market differentiator and great quality doesn't make sense.    ------------------------------  # Date: Sat, 11 May 2002 03:42:05 GMT * From: "Bill Todd" <billtodd@metrocast.net># Subject: Re: Stallards smoking gun!>B Message-ID: <hq0D8.170104$Lj.13397238@bin4.nnrp.aus1.giganews.com>  3 "John Reagan" <john.reagan@hp.com> wrote in messagea news:3CDC36E0.3000306@hp.com...    ...i  J > If Compaq/HP didn't plan to productize OpenVMS on Itanium, they sure areI > paying me money for nothing then (as well as paying lots of other folkst > for nothing).m  D You mean, just like they paid the EV8 team for nothing from at leastL November, 2000 (the date Terry claims Alpha's fate was sealed) to June 25th, 2001?d   - bill   ------------------------------  # Date: Sat, 11 May 2002 03:46:01 GMTn* From: "Bill Todd" <billtodd@metrocast.net># Subject: Re: Stallards smoking gun! B Message-ID: <Yt0D8.137499$n7.12378615@bin8.nnrp.aus1.giganews.com>  > "Jerry Leslie" <LESLIE@JRLVAX.HOUSTON.RR.COM> wrote in message5 news:LF_C8.72071$9F5.3888661@typhoon.austin.rr.com... 0 > JF Mezei (jfmezei.spamnot@videotron.ca) wrote:   ...f  H > : Until HP-UX on IA64 is a commercial reality, HP has no choice but to pretend-I > : that VMS continues since the desired migration can't happen until thet target > : platform exists.   ...o  7 > AFAIK, HP will sell you a system based on IA64 today:d  K I considered raising that point but then decided that HP-UX on Merced, even(J if nominally available, doesn't fit the definition of 'commercial reality' in any significant sense.e   >t< >    http://www.hp.com/techservers/products/itanium/why.html; >    hewlett-packard high performance technical computing /y& >    why the Itanium processor family? >r> >    http://www.hp.com/techservers/products/itanium/index.html; >    hewlett-packard high performance technical computing /-% >    Itanium processor family servers- >- >-J > HP completed the port of HP-UX, and then laid off most of the conversion > team.   : Hey, with Carly to guide them, they don't need R&D, right?   - bill   ------------------------------   Date: 10 May 2002 21:58:29 GMT* From: bart@CTI01.COMVERSE.COM (Steve Bart)# Subject: Switching the console modet@ Message-ID: <3cdc4285$0$2920$724ebb72@reader2.ash.ops.us.uu.net>  A 	Can someone tell me how to switch the console mode from one modeuF to the other when you do not have access to the console in the currentG mode? In other words, if I have a system (in this case a DS10) with the K console set to graphics, but for whatever reason I cannot access the system B via that connection, how can I change it to serial? Thanks for any help in  advance.t 					Steve Bartv   ------------------------------  % Date: Fri, 10 May 2002 18:30:20 -0500wC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com> ' Subject: Re: Switching the console mode H Message-ID: <craig.berry-CB743B.18292610052002@news.directvinternet.com>  @ In article <3cdc4285$0$2920$724ebb72@reader2.ash.ops.us.uu.net>,,  bart@CTI01.COMVERSE.COM (Steve Bart) wrote:  C > 	Can someone tell me how to switch the console mode from one mode H > to the other when you do not have access to the console in the currentI > mode? In other words, if I have a system (in this case a DS10) with theSM > console set to graphics, but for whatever reason I cannot access the systemeD > via that connection, how can I change it to serial? Thanks for any > help in  advance.. > 					Steve Barto  B Hmm.  Cannot access in that something's busted with your graphics D widget or in that you can't physically get to the system?  I'm sure E someone will have a more elegant solution, but if you can get to the  @ system, try unplugging the keyboard and rebooting; some systems C automatically default to serial if there is no keyboard plugged in  7 (though I don't know for sure the DS10 is one of them).S   ------------------------------  # Date: Sat, 11 May 2002 02:19:49 GMT.1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ' Subject: Re: Switching the console moden' Message-ID: <3CDC82E2.CB96BB1B@fsi.net>e   "Craig A. Berry" wrote:s > B > In article <3cdc4285$0$2920$724ebb72@reader2.ash.ops.us.uu.net>,. >  bart@CTI01.COMVERSE.COM (Steve Bart) wrote: > J > >       Can someone tell me how to switch the console mode from one modeJ > > to the other when you do not have access to the console in the currentK > > mode? In other words, if I have a system (in this case a DS10) with the O > > console set to graphics, but for whatever reason I cannot access the system,F > > via that connection, how can I change it to serial? Thanks for any > > help in  advance.e4 > >                                       Steve Bart > C > Hmm.  Cannot access in that something's busted with your graphicsnE > widget or in that you can't physically get to the system?  I'm sureIF > someone will have a more elegant solution, but if you can get to theA > system, try unplugging the keyboard and rebooting; some systemspD > automatically default to serial if there is no keyboard plugged in9 > (though I don't know for sure the DS10 is one of them).n  F I think you're on the right track there, but just rebooting won't do -F AFAIK, ya gotta power-cycle the machine with no kb in order to default to the serial console.   --   David J. DachteraE dba DJE Systems. http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Sat, 11 May 2002 02:47:17 GMT # From: "B F Cole" <bfcole@ipass.net>n Subject: Tektronix 4207H? Message-ID: <VC%C8.61527$gd5.25289194@typhoon.southeast.rr.com>U  E Anybody know where I can find a Tek 4207 terminal (monitor, keyboard,EF cables) in good working order?  I have an old application running on aE VaxStation 3100 that requires this specific terminal.  I've tried theiL EMU-TEK emulation software, but have been unable to get the graphics displayD editor to run.  There are many text only emulations that run without problems, but I need graphics. Thanks for any suggestions.e Bill   ------------------------------  + Date: Fri, 10 May 2002 19:08:40 +0000 (UTC)n* From: bleau@umtof.umd.edu (Lawrence Bleau)* Subject: Re: Time for comp.sys.hp.vms? SSA0 Message-ID: <abh5rm$a59$2@grapevine.wam.umd.edu>  K Actually, how about a comp.os.vms.hp ?  Then all the HP merger stuff can gotI somewhere else, and leave the technical VMS discussion in this newsgroup.a   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edue   ------------------------------  % Date: Sat, 11 May 2002 00:11:50 -0000m From: sword7@speakeasy.org Subject: TS10/VAX with DHV11/ Message-ID: <udooe6rpb4qk04@corp.supernews.com>O  * In comp.os.vms sword7@speakeasy.org wrote:F > Does anyone have specs about modem controls like DCD, DSR, DTR, etc?F > I am figuring out how modem control works.  I tried telnet into TS10H > through DHV11, but OpenVMS did not response.  OpenVMS recognized DHV11D > and created TXA0 to TXA7 devices according to 'Show Device' on DCL > prompt on TS10/VAX emulator.  D Well, I decided to implement receive and transmit steam (characters)I to find out what happenings.  Now I was able to telnet into TS10 through )D DHV11 without any problems (regardless of modem controls).  I playedE many commands like monitor, editors, etc for stress tests execpt fileoA transfers.  It looks like that DHV11 is running stable now.  Yes,nC I know that file transfers crashed TS10 system due to overrun data.g% I still am working on this known bug.-  H When I close my telnet session without logout, I re-telnet back to TS10,I I found out that my login session still is in effect!   Hmmm. Does anyone-I know commands to enable modem controls like 'set terminal ...' for betterdJ security?  For example, I lost telnet session, OpenVMS would automatically log off my account for me.  D I studied tracings and learned that OpenVMS did not do anything withB modem controls but only accepts transmit/receive character stream.  
 Thank you!   -- Tim Stark   -- n, Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  + Date: Fri, 10 May 2002 18:49:04 +0000 (UTC)t* From: bleau@umtof.umd.edu (Lawrence Bleau)9 Subject: Re: What is good model for disk i/o w/shadowing?F0 Message-ID: <abh4n0$a59$1@grapevine.wam.umd.edu>  E This is a good thread so far; keep it up.  There were a few questions ? raised about my original post that I'd like to address, though.h  ( ----------------------------------------3 rdeininger@mindspring.com (Robert Deininger) wrote:a  D >It would be nice to upgrade to V7.3 or (soon) V7.3-1 if possible.    B You don't say why.  Does the shadowing model change?  If not, thenG upgrading only fixes bugs - which is a good thing - but does not reallyeK address my question.  Besides, upgrading is a different fight I must fight,n, let's not have me do both at once, okay? :-)   [snip] >How busy are your disks?p  I Not *that* busy.  I/O request queue length is <1 most of the time (except ' when the boss is looking, of course :-\a  C >If you shadow, you'll likely want to put the two shadow members onwJ >different controllers.  That will improve the overlap.  A single SCSI busH >can only handle 1 transfer at a time, but 2 busses can mostly overlap 2
 >transfers.  p  H This is a point I had not considered; thanks!  Such a rearrangement *is*E possible.  Is there a way to measure this, short of changing hardwaree8 config?  How about modelling; is there a model for this?  ( ----------------------------------------+ "Bill Todd" <billtodd@metrocast.net> wrote:e  K >Oh, dear - this may take time away from writing responses to idiots, but Id >guess duty takes many forms...   , I try only to post interesting questions :-)  K >> I thought this was going to be straightforward, but ran into a snag withb >theK >> boss as soon as I raised the idea.  He said: "What?  That would make allf >writesp? >> take twice as long."  I could tell he didn't like that idea.  >tI >Perhaps because he hasn't a clue what he's talking about (ahhh - back toi. >responding to idiots again, just indirectly).  O Actually, he's never heard of shadowing before, but from my cursory explanationrN (perhaps not done so well, but I had to fit it into 1 or 2 sentences), he drewF this not-unreasonable conclusion.  I was just at a loss to counter it.  K >Now, I may be being hasty (not knowing at this level of detail exactly howdM >VMS shadowing is implemented), but there is absolutely no reason that writestI >*have* to take twice as long, since the writes to both disks can execute-L >concurrently.  There is often a *slight* increase in time because operationF >completion must wait for both writes (i.e., the slower of the two) to. >complete, but nothing like twice the latency.  I Ah! Latency!  I'd forgotten that factor.  A subsequent poster pointed outDA that write i/o's to shadow set members are issued and can proceedfJ concurrently.  Of course, this only helps if the shadow set members are on different scsi buses.   J >> Q1: Does this seem like a reasonable model?  That is, are there factors >that.' >> I've omitted, is it not linear, etc.  >eK >Fragmentation effects will be significant for other than small files:  VMSwJ >is pretty good at keeping files fairly contiguous on disk, but can't work@ >magic if the disk just doesn't have contiguous space available.  E My disk has a good deal of free space, so that's not a consideration.   I >If you're copying the output files to the disk you're getting the sourcenJ >files from, this will slow things down a lot.  From your 3 MB/sec figure, >this seems likely.   M For the tests I did and results I posted, I was using a source disk differentsK from the target disk.  In fact, the target disk for the test is one that wesJ usually do not use at all; it's a spare.  I would be using it as the other shadow set member.  0 >> Q2: Do the values of A and B seem reasonable? >SF >They both suck.  B suggests that you might be creating the files in a) >*large* directory; A commented on above..  J In my test cases I created the directory anew, empty. so this can't be theJ reason.  Can you think of another reason for a large B (file create time)?  = >> For shadow sets with two members, the write has to be donet% >> twice, so we'd expect A to double.u >iG >No - at least I'd hope VMS doesn't work that way (it certainly doesn't  >*have* to).    G Hmmm; I think I see my own error.  To remind us, here's the model I had  proposed for writes:   	T = A*M + B*N  D T = time to complete a file copy (read and write, diff disks) (secs) M = amount of data copied (Mb)% N = number of files created (# files)m> A = transfer rate conversion factor (s/Mb) (smaller is better)+ B = file create overhead factor (secs/file)a  G Since A is a rate, it should stay constant.  The *amount* of data beingnE written doubles in a shadow set w/2 members, so M should double.  Thea+ product A*M would still double in any case.s  J Now, as pointed out elsewhere, though perhaps not as succinctly, the modelL I proposed assumes serial processing of i/o requests to shadow set members. K If the processing can be overlapped by placing the drives on different scsii8 buses, we'd have to subtract out another term A*O, where  3 O = amount of data transfer that is overlapped (Mb).   so the model would become    	T = A*M - A*O + B*N  B Is this a fair refinement of the model to take concurrant i/o intoF consideration?  And, if the i/o's are really serial and cannot execute  concurrently, then O = 0 (zero).  H Of course, this begs the question: How does one now determine O?  Ideas?  . Two related follow-up questions on this point:  H In the case of both shadow members being on the same scsi bus, would the4 original model be a fair one?  That is, no A*O term.  H In the case of both shadow members being on the same scsi bus, would theF data transfer time indeed double?  Or is there some other optimization going on that I'm not aware of?z    K Also, re mini-merges, I'm resigned to doing only full merges when putting afF disk back into operation, since in case of a failure we'll have done aK disk replacement and a reboot anyways, and the new disk that I'll re-add toe% the shadow set will basicly be empty..  ( ----------------------------------------) David Froble <davef@tsoft-inc.com> wrote:   Q >I don't think that's how shadowing works.  On reads, you will get the data from  L >the disk on which it's first available.  This is a potential speed-up, not 
 >slow-down.     I Yes, but on what order of magnitude?  If I'm measuring .3 secs for a fileoJ create and .2 secs to both read and write 1Mb, a speed-up of 10 msec won't be noticed.   ) >That's assuming that you're not writing n >100% of the time. >tK >In general, there will be more disk reads than writes.  Individual systemso >will vary.a  J True.  For our data disks (not to be shadowed) its almost 100% reads.  ForG our user disk, which also hosts web pages, I'd guess it's slightly more ( reads than writes, but not by that much.  K In my tests I was reading from one disk and writing to a different disk.  IwJ also did a read-only test.  The read-only test on 550Mb of data (31 files)H took 32 secs.  The read-write test took 173 secs.  Therefore, everything5 required to perform the write of 550Mb took 141 secs.2  ( ----------------------------------------) bob@instantwhip.com (Bob Ceculski) wrote:g  G >we run volume shadowing on vms 7.1-2, and I guarantee it does not takew >twice as long ... a  J Do you have any numbers?  Did you perform any tests?  Any idea what factor we're talking about here?h  0 >the volume shadowing manual specifically states >sC >"Overall, the performance of a shadow set in steady state compares @ >favorably with a nonshadowed disk.  Read and write I/O requestsE >processed by the shadow set utilize a very small amount of extra CPU D >processing time as  compared with a nonshadowed disk.  A shadow setG >can often process read requests more efficently then can a nonshadowed D >disk because it can use the additional heads to respond to multiple >read requests simultaneously."   K This citation gives a good case for reads, but it doesn't address the issuej4 of writes, so it doesn't really address my question.   Bob goes on to say:n  D >And during copy operations, if there are requests waiting, the copyB >manages those requests in between the copy operation so you don't >even notice it going on ... S  K That is a good thing to know, since in further discussions I'm sure my bossnE (who has a nack for asking perceptive questions) will ask about this.i  ) >the simple fact is, volume shadowing caneB >prevent loss of data, plus keep you running if one disk fails ...D >Your bosses assesment is wrong, and I suggest you obtain if not theC >manual from the internet if possible and turn to chapter 8 and let>E >him read it for himself.  Volume shadowing is very efficent and will3/ >keep your disk going, and going just like vms!i  A I'll read this myself, maybe it will answer other qeustions.  The9? performance info in chapter 9, btw, at least on the www manual.@  ( ----------------------------------------4 sy18889@rabbit.fmr.com (Bradford J. Hamilton) wrote:  L >We did an experiment in our lab, with a 6G RMS indexed file on a 9G, 10KRPMG >drive.  We backed the file up, disk-to-disk, to a "target" drive whichlJ >consisted of 2 9G drives, shadowed.  We then repeated the backup, using aN >target drive of one 9G drive, shadowed (single-member shadow-set).  The finalM >test was to repeat the experient with a 9G drive that was part of a 2-membert& >mirror set (controllers were HSJ80s).  J Hmm, this may not match my configuration.  We have no HSJ anythings; theseG are connected to a scsi bus.  Now, your findings still have merit.  TheeK question is what part of those findings can be applied to my configuration,aI and what part is dependent on the HSJ optimizing operations?  Or was onlytF the last test (mirror) done to an HSJ connected device?  If your otherH tests were done with host-based shadowing, not HSJ-based, then I can use the results.  F >The results of our experiments were that writing to the single-memberM >shadow-set and the mirror set took ~28% less wall-clock time than writing to4O >the two-member shadow-set (we repeated each test a number of times, to attemptt >to eliminate "noise").o  I So, to invert this, writing to a 2-member shadow set took 39% longer thaneG to either a 1-member shadow set or to a standalone disk.  The model I'dhJ used assumed a 100% increase.  Good work, these are the types of numbers I need!i  L >YMMV, of course, but our "results" seem to indicate that writes do not takeJ >twice as long, but there is *some* penalty when you write to a two-member >shadow-set.  C Okay, that's fine, I just wanted to measure these somehow.  My onlysD concern, mentioned above, is how much your HSJ assists the shadowingJ operation during a write.  Do you have any non-HSJ scsi disks that you can use to test?  ( ----------------------------------------( Now, in reply to the above test results,, young_r@encompasserve.org (Rob Young) wrote:  B >	You most likely did not have write-backed caching turned on thatG >	mirrorset.  As an example of just how big an effect this is, the time F >	for a write to complete to a modern disk is in the region of 4-5 ms.@ >	Using Polycenter, a write only mirrorset of mine measured 1 msC >	for writes to complete.  That was probably the minimum threshold,eC >	could have very well been rounded up to 1 ms :-).  Point is, withaD >	that kind of difference, I would argue writes are 300-500% faster.  J This is the type of factor I was wondering about.  However, Rob only makesJ the above point wrt mirror sets.  What about the other two tests that were done?e  I >	Also, the real-world test of course would be to load everything up withr@ >	plenty of read-traffic as most folks do something on the orderF >	of 80/20 read to write ratio (depending on global buffering and what >	not).m  F That is good for testing an average load, but won't address the narrowG issue I'm trying to resolve: the overhead involved in writing to shadow2 sets vs. standalone drives.h  @ >	If you don't have cache catching your writes when using volume+ >	shadowing, you will have big time issues.   H Can you elaborate on this?  You gave an example of a failed product, butF what about current VMS shadowing s/w?  What controls caching for disks$ connected to a processor's scsi bus?  ( ----------------------------------------: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote:  F >You mentioned no cluster.  I would recommend a cluster and mount the / >members of the shadow set on separate nodes.  a  G Not an option.  First, I'd have to buy another system.  Second, my bossnJ *hates* clusters and won't even let me say the word in his presence.  (AndI no, he won't tell me why, I just have to grind my teeh and live with it.)tJ So let's not spin wheels on clustering, as that's not an option.  Besides,G even if he liked clustering, it'd slow things down, since then all that G data would have to be pushed through a network adapter, which is slowerr than Ultrascsi.s   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edus   ------------------------------  % Date: Fri, 10 May 2002 21:09:28 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>y9 Subject: Re: What is good model for disk i/o w/shadowing? ' Message-ID: <3CDC1AE8.E8EDDA88@aaa.com>F  ! Regarding disk I/O and shadowing.T  > This how I'v leared that shadowning (host based !) takes place" (Using modern DMA SCSI controlers)  D In the non-shadowing case, the SCSI driver in VMS builds a I/O blockC in memory and sends an interrupt to the SCSI controler containing a 	 "pointer"eD to the I/O block. The SCSI controler then reads the data from memory, (DMA) and performes the I/O on the SCSI bus.  C In the shadowing case, the same I/O block is built in memory by theo? SCSI driver, then two (or three if there is three mebers in the A shadowset) interupts are sent the the rellevant SCSI controllers.:@ The controller(s) then use DMA to fetch the data and perform theA I/O on teh SCSI bus. Note that there still is only one data block@> in memory ! Both SCSI controlers read the same data using DMA.  D So the extra overhead in VMS is (more or less) the extra interupt(s) to the SCSI controllers.  ) Now lets take alook at the SCSI bus(ses).y  B If both disks in the shadow set is on the same SCSI bus, I'd thinkB that the I/O still can be performed more or less in parallell. The@ SCSI bus is probably much faster then a single write in the disk	 hardware.V  H If each disk are on a separate SCSI bus, the I/O's can be performed more or less at the same time.o  G On short, the VMS shadowing is very effective. Of course everything canfA be measured, but in practical use, you'd be hard to see any majorhA differense. Probably the better *read* performance will outweight1' the slightly worse *write* performance.r  ? Couple this with the ease-of-management of VMS-shadowing, therel- is realy no reason *not* to shadow your disk.t   Jan-Erik Sderholm       Lawrence Bleau wrote:  > G > This is a good thread so far; keep it up.  There were a few questionseA > raised about my original post that I'd like to address, though.r >e   ------------------------------  + Date: Fri, 10 May 2002 22:11:52 +0000 (UTC) * From: bleau@umtof.umd.edu (Lawrence Bleau)9 Subject: Re: What is good model for disk i/o w/shadowing?r0 Message-ID: <abhgj8$fej$1@grapevine.wam.umd.edu>  E Thanks, Jan-Erik, for a look "under the hood" of host-based shadowingoH operations.  I can see why it speeds things up for reads, and why writesF might not slow down as much as expected, even if on the same scsi bus.  H >On short, the VMS shadowing is very effective. Of course everything canB >be measured, but in practical use, you'd be hard to see any majorB >differense. Probably the better *read* performance will outweight( >the slightly worse *write* performance. > @ >Couple this with the ease-of-management of VMS-shadowing, there. >is realy no reason *not* to shadow your disk.  I Well, not from a technical point of view.  From management, however, it'soF still a battle, since it's a new concept to the one in charge, and hisH initial model is that of something that takes twice as long.  I'm in theK position of *disproving* that model, hopefully by presenting another model,aI and convincing my boss that the new model is the correct one.  Even if heiJ agrees it looks reasonable, he's the type that'll want evidence, either upG front or immediately after reconfiguration.  So I'm wondering how to goaI about testing this.  My initial tests give me results that look horrible,-. and do not help the case for shadowing at all.   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edu'   ------------------------------  % Date: Fri, 10 May 2002 13:40:07 -0400f2 From: Atlant Schmidt <atlantnospam@mindspring.com>& Subject: Re: [announce] FreeVMS 0.0.14. Message-ID: <3CDC05F7.C0CF88F9@mindspring.com>   "Keith A. Lewis" wrote:c  H > Current Apple products use Motorola PowerPC (PPC) processors, I think.   Absolutely true.  : They us Motorola G4 PowerPC processors right now, although8 they've used most of the various "computer" (as compared9 to "embedded") cores in the past. Motorola G5 is probablyi8 next in the lineup, although you never know when IBM and? Mot will settle their AltiVec (vector instructions) differencess6 and make the IBM cores highly elligible for use again.  :                                                     Atlant   ------------------------------  # Date: Sat, 11 May 2002 02:03:38 GMTt1 From: "David J. Dachtera" <djesys.nospam@fsi.net>-& Subject: Re: [announce] FreeVMS 0.0.14' Message-ID: <3CDC7F16.D6F2EDFF@fsi.net>m   Roar Throns wrote:w > < > Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote: > :> > C'est une blague? > :>L > :>      Non. C'est trs srieux. Je suis mme en train d'envisager un port > :>      sur ppc et sparc.> > H > : True, but if you look at the page, there are lots of areas---such asK > : RMS, clustering, editors---which are essential to VMS where nothing has  > : been done. > J > : Something like writing RMS from scratch seems like a pretty tall order
 > : to me. > C > Depends on whether it will be today's version, the 5.x version ormI > RMS as of 22-25 years ago (the available docs for the latter seems moret0 > detailed, so it will probably be tried first).> > (And on whether it will be a full or partial implementation) > 6 > But before that ODS-2 will have to be usable (soon).  F Yeah - I've noticed that a lot of folks have trouble determining where ODS ends and RMS begins.   -- c David J. Dachterae dba DJE Systemsi http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------  # Date: Sat, 11 May 2002 02:06:28 GMTt1 From: "David J. Dachtera" <djesys.nospam@fsi.net>c& Subject: Re: [announce] FreeVMS 0.0.14' Message-ID: <3CDC7FC0.F24F49E5@fsi.net>s   Roar Throns wrote:a > < > Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote:O > :> > Does anyone who a) is not working on this project and b) knows somethingsK > :> > about it seriously think it will get off the ground?  Something liketE > :> > writing RMS from scratch seems like a pretty tall order to me.i > :>H > :>      Do you agree to rewrite RMS from scratch (under GPL licence) ? > K > : No.  That's my point.  I don't think anyone else will, either.  I wouldu > " > It is not exactly a one-man job. > H > : like to see an estimate of the amount of work required.  That's just# > : RMS; then comes clustering etc.i > F > It is very difficult making such estimates, it all depends on who is@ > developing and how the debugging possibilities/facilities are. > J > If people should have been afraid of starting on a huge task very little > would have been accomplished.t  @ You have pretty well summed up the reason for the failure of the% abortive predecessor to your efforts.m  B I congratulate those working on this, and encourage your continuedE efforts. If I possessed the required skills, I would be very happy to* help.o   -- o David J. Dachtera  dba DJE Systemss http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/f   ------------------------------  # Date: Sat, 11 May 2002 02:11:53 GMTt1 From: "David J. Dachtera" <djesys.nospam@fsi.net>A& Subject: Re: [announce] FreeVMS 0.0.14' Message-ID: <3CDC8103.CE68B61E@fsi.net>    Phillip Helbig wrote:  > N > > > Does anyone who a) is not working on this project and b) knows somethingJ > > > about it seriously think it will get off the ground?  Something likeD > > > writing RMS from scratch seems like a pretty tall order to me. > >iH > >       Do you agree to rewrite RMS from scratch (under GPL licence) ? > I > No.  That's my point.  I don't think anyone else will, either.  I would,F > like to see an estimate of the amount of work required.  That's just! > RMS; then comes clustering etc.h  D Personally, I really hope that this effort gets off the ground as it seems to have and stays there.  E The previous effort never really got past the arguing stage. I'm sureiB former participants of that list still remember when Jon Powers ofC Sector7 fame came along and forged his mail headers so his messagese2 appeared to originate from "gib.senip@reknaw.com".  G My hat is off to these guys. No matter what it takes - how long, or how H much effort - I see a VMS clone running on IA32 as the best way to teachF those "old Proliants" a few "new" tricks (old ones, actually). WhetherD it actually gets to that point is, of course, not within my purview.   -- t David J. Dachterae dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/b   ------------------------------  , Date: Fri, 10 May 2002 02:00:20 +0200 (CEST)9 From: Richard Levitte - VMS Whacker <levitte@openssl.org> 2 Subject: [ANNOUNCE] OpenSSL 0.9.6d beta 1 released: Message-ID: <20020510.020020.85815556.levitte@openssl.org>  !   OpenSSL version 0.9.6d released-!   ===============================f  /   OpenSSL - The Open Source toolkit for SSL/TLSn   http://www.openssl.org/e  H   The OpenSSL project team is pleased to announce the release of versionJ   0.9.6d of our open source toolkit for SSL/TLS.  This new OpenSSL versionH   is mostly a bugfix release and incorporates at least 23 changes to theN   toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES).  #   The most significant changes are:i  '     o Various SSL/TLS library bugfixes. @     o Fix DH parameter generation for 'non-standard' generators.  H   We consider OpenSSL 0.9.6d to be the best version of OpenSSL availableC   and we strongly recommend that users of older versions upgrade as'F   soon as possible.  OpenSSL 0.9.6d is available for download via HTTPG   and FTP from the following master locations (you can find the variousr?   FTP mirrors under http://www.openssl.org/source/mirror.html):   $     o http://www.openssl.org/source/#     o ftp://ftp.openssl.org/source/d  ?   [1] OpenSSL comes in the form of two distributions this time.rK   The reasons for this is that we want to deploy the external crypto device J   support but don't want to have it part of the "normal" distribution justI   yet.  The distribution containing the external crypto device support is G   popularly called "engine", and is considered experimental.  It's been@J   fairly well tested on Unix and flavors thereof.  If run on a system withN   no external crypto device, it will work just like the "normal" distribution.  "   The distribution file names are:  &       o openssl-0.9.6d.tar.gz [normal]-       o openssl-engine-0.9.6d.tar.gz [engine]a     Yours,   The OpenSSL Project Team...     <     Mark J. Cox             Richard Levitte    Andy Polyakov:     Ralf S. Engelschall     Bodo Mller        Holger Reif;     Dr. Stephen Henson      Ulf Mller         Geoff Thorpes/     Ben Laurie              Lutz Jnicke           ------------------------------   End of INFO-VAX 2002.259 ************************