1 INFO-VAX	Sat, 25 Aug 2001	Volume 2001 : Issue 471       Contents: Re: Alpha - Complete for USD599 ' Re: Alpha ECU - Does it work from a CD?  Comp.os.VMS session at CETS  Re: Comp.os.VMS session at CETS  Re: Compaq Mark Twain Mailing  RE: Compaq Mark Twain Mailing ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update  Re: DCL challenge  Re: DCL challenge $ Re: DECnet-Plus on an alternate disk$ Re: DECnet-Plus on an alternate disk Digital LG06 Re: Digital LG06 Re: Digital LG06 Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  RE: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium Re: Freeware Dskmon Utility   Re: Help! Boot Block Information' Re: Hex dump-and-lookatit-in-themorning 1 Re: How do you search for blank lines in TPU/EVE? 1 Re: How do you search for blank lines in TPU/EVE? - Re: IA-64 Emulation (was: Re: Nits in Slides) - Re: IA-64 Emulation (was: Re: Nits in Slides) - Re: IA-64 Emulation (was: Re: Nits in Slides) A Re: Incautious Privileged Users (was: Re: Queue/Entry management)  Re: Intersystems and Alpha% J2EE, RMI, Java Connectivity Question ( Re: LPR from VMS 7.2-1 to Win2000 Server Re: MLU and VMS 7.3 ) Modifying User Accounts - newbie question - Re: Modifying User Accounts - newbie question K Re: Mount Points (was: Re: Wailing at Eunuchs (was: Wailing and Moaning...) P Re: Mount Points (was: Re: Wailing at Eunuchs (was: Wailing and Moaning...) Moan Re: Nits in Slides Re: Nits in Slides Re: Nits in Slides9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) 9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) 5 Re: Nuts-n-bolts in News (was: Re: Nits in Slides...) 5 Re: Nuts-n-bolts in News (was: Re: Nits in Slides...) 5 Re: Nuts-n-bolts in News (was: Re: Nits in Slides...) 5 Re: Nuts-n-bolts in News (was: Re: Nits in Slides...) " Re: ODS-5 and parse_style question# Re: OT: TOPS-20 and TOPS-10 live on  Re: Queue/Entry management Re: Queue/Entry management Re: Queue/Entry management Re: Queue/Entry management Re: Queue/Entry management7 Re: RWMBX - What to do, What to do! Help me if you can. , Re: VMS high reliability needed by Air Force4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)4 Re: Wailing at Eunuchs (was: Wailing and Moaning...): Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?  F ----------------------------------------------------------------------  % Date: Fri, 24 Aug 2001 21:28:12 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ( Subject: Re: Alpha - Complete for USD599' Message-ID: <3B870D3C.3ADA3184@fsi.net>    "www.islandco.com" wrote:  > C > Yep - September is here and we are shipping these little puppies.  >  > Configured as follows: > ! > 433Mhz CPU 21164 EV56 at 433Mhz ( > 128MB Memory 10/100 Ethernet On Board, > S3Trio64 2MB > 1.44Mb Floppy +  > 4x SCSI CDROM 5 > Unix/Linux SCSI Ctr PCI 2GB  7200rpm Disk SCSI Wide ! > Keyboard Generic 3 Button Mouse  > F > VMS compatible system requires different (QLogic) controller add $51 >  > 23 in stock and ready to go !   E I HAD to congratulate you on this price breakthrough. That's the best $ deal on a "new" Alpha I've seen yet.  ? Keep up the good work. Hope you sell 'em all before 15-Sep-2001 % (arbitrary day - no special meaning).    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Fri, 24 Aug 2001 23:45:39 +0100 1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk> 0 Subject: Re: Alpha ECU - Does it work from a CD?6 Message-ID: <3B86E723.3C3B2C27@ipl.demon.co.nospam.uk>   You mean like :   C - "It wasn't only the CD that was coasting as Nic booted the GS140"  orF - "With the power of a floppy-drive-less GS140, you'll be coasting all the way to the Ecu".  A or even (for those with an interest in European exchange rates) : G - "Hey guys.  How many ECUs would we need to pay EDS to make this thing  work??"    :-(      Nic Clews wrote: <trim> > F > If we have a coaster, I'll sent to to the person that posts the best > joke. ' > (We need a little humour around here)  >  <trim> --  G "A shadow fell over her face; clear, as if the composure were rent like E a veil.  And her lips parted, but only with a short intake of breath. A Then she said, 'Well, then you are right.  Indeed, we are even.'" % 		Louis, "Interview with the Vampire"    ------------------------------  % Date: Fri, 24 Aug 2001 17:32:11 -0400 2 From: "Sue Skonetski" <susan.skonetski@compaq.com>$ Subject: Comp.os.VMS session at CETS2 Message-ID: <9Jzh7.772$bB1.32697@news.cpqcorp.net>   Folks,  H  Hoff will be having a Denizens of comp.os.vms session at CETS.  Session number 1133   7 Wednesday 4:15 in the La Jolla conference room (Hilton)   $ looking forward to seeing you there.   Sue    ------------------------------  # Date: Fri, 24 Aug 2001 22:39:27 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) ( Subject: Re: Comp.os.VMS session at CETS0 Message-ID: <00A01054.917CE6BD@SendSpamHere.ORG>  g In article <9Jzh7.772$bB1.32697@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:  >Folks,  > I > Hoff will be having a Denizens of comp.os.vms session at CETS.  Session  >number 1133 > 8 >Wednesday 4:15 in the La Jolla conference room (Hilton) > % >looking forward to seeing you there.  >  >Sue >  >   J Oh goodie... and this trip I'm bringing the camera so I can snap a shot of0 all the ugly mugs of this forum that attend.  :)   See you all there. --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  % Date: Fri, 24 Aug 2001 17:04:59 -0400 - From: "John Eisenschmidt" <jeisensc@aaas.org> & Subject: Re: Compaq Mark Twain Mailing+ Message-ID: <sb868949.034@AAASMTA.aaas.org>   J WTF? If Twain were to be reincarnated he'd come back as OpenVMS? (Yes, I = know I'm paraphrasing)  L It then says: "Compaq OpenVMS on AlphaServer systems and beyond - classic, =I unstoppable computing." Yeah, OpenVMS AXP - it runs until we give it to =  Intel.  0 Mark Gorham - what are you smoking? I want some.  K Mark Twain coming back as OpenVMS??? Did you consider spending this money = J on a TV commercial? Or marketing to people who don't have or use the OS? =) An ad in InfoWorld? A daily newspaper?=20   9 Thank you for the cheap newsprint...er book, but come on.     B Unless the Voices are Mistaken, <William_Bochnik@acml.com>, wrote:  # From: <William_Bochnik@acml.com>=20 " Subject: Compaq Mark Twain mailing    . when you get it in the mail, you'll understand  ? page 55 - Put all your eggs in one basket and WATCH THAT BASKET    ROTFL    ------------------------------  % Date: Fri, 24 Aug 2001 16:12:08 -0500 + From: Christopher Smith <csmith@amdocs.com> & Subject: RE: Compaq Mark Twain MailingL Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DB7E@cmiexch1.cmi.itds.com>   > -----Original Message-----4 > From: John Eisenschmidt [mailto:jeisensc@aaas.org]  8 > Mark Twain coming back as OpenVMS??? Did you consider : > spending this money on a TV commercial? Or marketing to   K I agree -- put that statement on a TV commercial, and people will just have  to know what VMS is. :)    Chris     ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");  '       ------------------------------  % Date: Fri, 24 Aug 2001 14:20:27 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9m65sl$cri$1@pyrite.mv.net>  L Yup - as I suspected, *lots* of good cheer from Compaq about the transition.K I especially liked Rich Marcello's "You Can Bet Your Business on Compaq and J Itanium" session, which one might guess will be modeled on the Heil/Lipcon7 'you can bet your business on Compaq and Alpha' letter.    - bill  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 2 news:0hwh7.1151$YN4.805979@typhoon2.gnilink.net...G > This message is a detailed update for the Compaq Enterprise Technical ( > Symposium 2001. This message includes: > ' >     1) Registration Discount Extended ! >     2) Symposium Program Update % >     3) Meet the Experts Night (New)  >     4) Itanium Sessions (New) > >     5) Compaq Listens Panel Update (Open for Questions Now!)3 >     6) Compaq Engineering Technical Center Update A >     7) Encompass Exposition Update (Complementary - No Reg Fee) # >     8) Encompass Campground (New) ? >     9) Technical Seminars Update (Symposium Reg Not Required)    ...    ------------------------------    Date: 24 Aug 2001 13:20:55 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) 2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <qAOtNDf690$y@malvm5.mala.bc.ca>  ) In article <9m65sl$cri$1@pyrite.mv.net>,  ,    "Bill Todd" <billtodd@foo.mv.com> writes:  N > Yup - as I suspected, *lots* of good cheer from Compaq about the transition.M > I especially liked Rich Marcello's "You Can Bet Your Business on Compaq and  > Itanium" session,   :    Why not, they're betting their business on Itanium. :-)  >    It's not my business anymore anyway, I sold my Compaq stockB about a year and a half ago. I thought I was doing poorly to break? even on it after holding it for a couple of years, given todays % prices I'm glad I got out when I did.    ------------------------------  # Date: Fri, 24 Aug 2001 22:25:31 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update6 Message-ID: <vvAh7.253$A83.90944@typhoon1.gnilink.net>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9m65sl$cri$1@pyrite.mv.net...B > Yup - as I suspected, *lots* of good cheer from Compaq about the transition. I > I especially liked Rich Marcello's "You Can Bet Your Business on Compaq  and L > Itanium" session, which one might guess will be modeled on the Heil/Lipcon9 > 'you can bet your business on Compaq and Alpha' letter.  >  > - bill  H Nope - it was specifically requested by Encompass leadership to answer aH series of business issue questions.  Encompass had a great deal of input& into the design of Monday's program...  7     Capellas leads off with the Compaq overall strategy    Next you can either choose...   /     NSD Strategy (AKA Tandem) with Howard Elias      orH     Industry Standard Servers Strategy (AKA ProLiant) with Mary McDowell   Next you can either choose...   6     HPS Strategy (AKA Tru64/OpenVMS) with Howard Elias     orH     Access Strategy (AKA everything below the serves) with John Stautner  K Then after we break for lunch Encompass requested the following session (we  wrote the abstract)...  8     1673 You Can Bet Your Business on Compaq and Itanium  K     Abstract: This session addresses fundamental business issues related to I     Compaq's AlphaT to Itanium strategy. These issues include: Preserving  yourB     already existing investment in your Tru64T UNIX or OpenVMST ITE     infrastructure; Why the investment you make today in new projects  deployedH     on Tru64 UNIX  or OpenVMS, both in terms of hardware and applicationL     development costs, will be preserved in the future; What Compaq is doing toE      insure the long term  viability of OpenVMS and Tru64 UNIX in the  marketplace K     as technology leading enterprise class servers. These issues and others  are K     covered, and this session provides the answers to why Compaq's Alpha to  Itanium -     strategy is a safe bet for your business.   F ...we requested session because as we learned more about the technicalH aspects of porting from Alpha to VMS many of us realized that it was NOTK going to be mission impossible.  Anyone with open mind who has been reading L 'Hoff' Hoffman's postings in comp.os.vms knows that there has already been aD lot of thought put into this and this not some wild ass dream of theL beancounters Houston - there is significant engineering insight behind this.D However, even if you are a believer that the technical issues can beF addressed we kept hearing back over and over again that folks were notF believers about the all the business issue aspects.  We asked for thisK session up front and we were very clear that a ra ra "gloss over the issues L with a thin coating of happy dust" would NOT work.  Frankly I thought CompaqF was going to duck the session, especially given the expectation that aH superficial session wouldn't work, and we were pleasantly surprised thatJ they took the session right away even after we explained our perception ofI the situation.  You have to give them credit for being willing to lead to   what may be the hardest session.  6 This will be followed by normal track kickoff sessions  E Then at the end of the regular session day there is another Encompass  requested session...  A     1674  Compaq Directions for Integrating Alpha Chip Technology F               with the Intel Itanium Processor Family: Executive Panel  H     Abstract:  Join us for this panel discussion with Compaq engineering
 executivesJ     as we discuss the plans for integrating Alpha chip technology into the
 Intel Itanium K     Processor Family (IPF). We'll address your interests and concerns about  future     server and OS roadmaps.   D ...this will be the Q&A session with the architectural heavy weights  I So at this point if you are and Encompass member and pick the sessions we   recommend you will have heard...       Overall Strategy (Capellas) >     ProLiant Strategy (McDowell) (ProLiant does not = Windows)3     OpenVMS/Tru64 Strategy (Elias (second session))      Business issues (Marcello)$     Normal Platform Opening Sessions*     High Powered IPF Q&A (Executive Panel)  E ...which leads into the last session on Monday - Compaq Listens Panel   F ...Then we start you off on Tuesday with Storage Strategy (Mark Lewis)H followed by a bunch of nitty gritty technical sessions.  There is a realJ plan to this and it was driven by the issues being raised by the Encompass
 membership...    ------------------------------  % Date: Fri, 24 Aug 2001 21:45:20 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update' Message-ID: <3B871140.7A29551F@fsi.net>    Jeff Killeen wrote:  > 4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9m65sl$cri$1@pyrite.mv.net...D > > Yup - as I suspected, *lots* of good cheer from Compaq about the
 > transition. K > > I especially liked Rich Marcello's "You Can Bet Your Business on Compaq  > and N > > Itanium" session, which one might guess will be modeled on the Heil/Lipcon; > > 'you can bet your business on Compaq and Alpha' letter.g > >	
 > > - bill > J > Nope - it was specifically requested by Encompass leadership to answer aJ > series of business issue questions.  Encompass had a great deal of input( > into the design of Monday's program... > 9 >     Capellas leads off with the Compaq overall strategye >  > Next you can either choose...2 > 1 >     NSD Strategy (AKA Tandem) with Howard Eliasd >     orJ >     Industry Standard Servers Strategy (AKA ProLiant) with Mary McDowell >  > Next you can either choose...  > 8 >     HPS Strategy (AKA Tru64/OpenVMS) with Howard Elias >     orJ >     Access Strategy (AKA everything below the serves) with John Stautner > M > Then after we break for lunch Encompass requested the following session (wer > wrote the abstract)... > : >     1673 You Can Bet Your Business on Compaq and Itanium > M >     Abstract: This session addresses fundamental business issues related tooK >     Compaq's AlphaT to Itanium strategy. These issues include: Preservingm > yourD >     already existing investment in your Tru64T UNIX or OpenVMST ITG >     infrastructure; Why the investment you make today in new projectse
 > deployedJ >     on Tru64 UNIX  or OpenVMS, both in terms of hardware and applicationN >     development costs, will be preserved in the future; What Compaq is doing > toG >      insure the long term  viability of OpenVMS and Tru64 UNIX in thea
 > marketplaceuM >     as technology leading enterprise class servers. These issues and othersE > are M >     covered, and this session provides the answers to why Compaq's Alpha toi	 > Itaniums/ >     strategy is a safe bet for your business.  > H > ...we requested session because as we learned more about the technicalJ > aspects of porting from Alpha to VMS many of us realized that it was NOTM > going to be mission impossible.  Anyone with open mind who has been readingLN > 'Hoff' Hoffman's postings in comp.os.vms knows that there has already been aF > lot of thought put into this and this not some wild ass dream of theN > beancounters Houston - there is significant engineering insight behind this.F > However, even if you are a believer that the technical issues can beH > addressed we kept hearing back over and over again that folks were notH > believers about the all the business issue aspects.  We asked for thisM > session up front and we were very clear that a ra ra "gloss over the issuesaN > with a thin coating of happy dust" would NOT work.  Frankly I thought CompaqH > was going to duck the session, especially given the expectation that aJ > superficial session wouldn't work, and we were pleasantly surprised thatL > they took the session right away even after we explained our perception ofK > the situation.  You have to give them credit for being willing to lead to " > what may be the hardest session.  B Indeed. I wrote to Richard suggesting that he may want to considerH changing the name of the session. I've not heard back from him; so, I'll repeat my entreat again:  E __P_L_E_A_S_E__ !!!! Don't embarass Richard, even if they are foolishi@ enough to not change the name of the presentation. Hear him out, courteously and respectfully.g  D The LAST thing we need would be to have him be laughed right off the stage...   -- w David J. Dachterae dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  # Date: Sat, 25 Aug 2001 03:14:00 GMTu& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update7 Message-ID: <YJEh7.697$A83.219023@typhoon1.gnilink.net>    [SNIP]  K > > Then after we break for lunch Encompass requested the following sessionu (wei > > wrote the abstract)... > >P< > >     1673 You Can Bet Your Business on Compaq and Itanium   [SNIP]  D > Indeed. I wrote to Richard suggesting that he may want to consider# > changing the name of the session.y  E When Encompass submitted the session we submitted it with that title. D Compaq took the session and title from us and did not modified it...   ------------------------------  # Date: Sat, 25 Aug 2001 03:13:15 GMTf& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update7 Message-ID: <fJEh7.696$A83.218143@typhoon1.gnilink.net>D   [SNIP]  K > > Then after we break for lunch Encompass requested the following session  (we  > > wrote the abstract)... > >u< > >     1673 You Can Bet Your Business on Compaq and Itanium   [SNIP]  D > Indeed. I wrote to Richard suggesting that he may want to consider# > changing the name of the session.e  E When Encompass submitted the session we submitted it with that title.2D Compaq took the session and title from us and did not modified it...   ------------------------------  % Date: Fri, 24 Aug 2001 20:38:42 +0200M> From: "Jean-Francois Marchal" <jean-francois.marchal@x9000.fr> Subject: Re: DCL challenge. Message-ID: <9m66lt$ovi$1@reader1.imaginet.fr>  F "Didier Morandi" <Didier.Morandi@gmx.ch> a crit dans le message news: 3B869396.FD905B31@gmx.ch...E > Jean-Francois Marchal wrote: >> > ../..eK > > could any DCL guru rewrite the code to get z in one line without a pipe1 ?  >r$ > You should make a choice here, JF: >sL > Either you please yourself with the most ununderstandable line(s) of code,  / a me plairait particulirement dans ce cas ...yI juste pour le fun ... je suis de toute faon le seul  maintenir ce code, < qui aurait plutt du tre crit en cobol, en fortran ou en C (c'est une appli de "gestion")   > orG > you consider that one day someone else than you will have to maintaini > this code. >oI > I have definitely choosen the second option and each time I arrive on aAE > Customer's site, I split complicated DCL code to different lines tos+ > improve readability and ease maintenance.r >v9 > Think about the poor consultants who come behind... :-)- >- > D.   ------------------------------  % Date: Fri, 24 Aug 2001 20:42:25 +0200 > From: "Jean-Francois Marchal" <jean-francois.marchal@x9000.fr> Subject: Re: DCL challenge. Message-ID: <9m66ss$p0v$1@reader1.imaginet.fr>  F "Didier Morandi" <Didier.Morandi@gmx.ch> a crit dans le message news: 3B869396.FD905B31@gmx.ch...  > Jean-Francois Marchal wrote: >  > ../.. K > > could any DCL guru rewrite the code to get z in one line without a pipee ?r >2$ > You should make a choice here, JF: >nL > Either you please yourself with the most ununderstandable line(s) of code,  ? that's exactly what I would like to do for this special line ofaI a really modular procedure written for my own usage (the code is intendedt to quote service contracts)l   > orG > you consider that one day someone else than you will have to maintaino > this code. > I > I have definitely choosen the second option and each time I arrive on afE > Customer's site, I split complicated DCL code to different lines to + > improve readability and ease maintenance.s > 9 > Think about the poor consultants who come behind... :-)  >  > D.   ------------------------------  % Date: Fri, 24 Aug 2001 21:14:32 +0100T+ From: "antonio.carlini" <arcarlini@iee.org>e- Subject: Re: DECnet-Plus on an alternate disko' Message-ID: <3B86B5A8.C57050A9@iee.org>n   Phil Mendelsohn wrote:K > I'm learning some ropes of VMS system management.  I have a VAXserver31001K > with a small (RZ23) system disk, but a 2.0GB disk also.  I got Polycenter:  0 Nothing like diving in at the deep end is there!4 Getting OpenVMS up and running on a 120MB drive must have been a bit of a squeeze!M  I > to install DECnet Plus on the big drive (DISK$POOL) but want to know ifaJ > there are logical names that need to be defined to make sure things find > it.   & Speaking as an ex-DECnet devo, I don't recall anyone trying this! o Let us all know if it works!  L > Is it as easy as adding VMS$COMMON=DISK$POOL:[VMS$COMMON.] to the existing > VMS$COMMON logical?t  2 You may well be better off extending SYS$SYSROOT -' I started doing that back in V4.5 or soo# and it's never got in the way yet. b  / > I am *not* trying to avoid manual reading -- W   This won't be in the manual!   AntonioW   -- B   --------------- - Antonio Carlini             arcarlini@iee.orgy   ------------------------------  % Date: Fri, 24 Aug 2001 23:37:52 +0100o4 From: John Laird <john@laird-towers.freeserve.co.uk>- Subject: Re: DECnet-Plus on an alternate disk18 Message-ID: <1cldotseggo0rbsg398nbeqfoocbehra37@4ax.com>  5 On Fri, 24 Aug 2001 21:14:32 +0100, "antonio.carlini"  <arcarlini@iee.org> wrote:   >Phil Mendelsohn wrote:iL >> I'm learning some ropes of VMS system management.  I have a VAXserver3100L >> with a small (RZ23) system disk, but a 2.0GB disk also.  I got Polycenter >p1 >Nothing like diving in at the deep end is there!t5 >Getting OpenVMS up and running on a 120MB drive must  >have been a bit of a squeeze!  D It was just about possible to get 6.2, Motif 1.2-3, and a modicum ofH page file and applications, but to my mind it is a largely wasted effortC when you consider just how slow an RZ23 is.  Check the specs - it's-D something like 3 times slower than the average 3.5" 1Gb drive, whichH would be my definite recommendation for a system disk in such a machine.  J >> to install DECnet Plus on the big drive (DISK$POOL) but want to know ifK >> there are logical names that need to be defined to make sure things findo >> it. > ' >Speaking as an ex-DECnet devo, I don't" >recall anyone trying this!  >Let us all know if it works!i >nM >> Is it as easy as adding VMS$COMMON=DISK$POOL:[VMS$COMMON.] to the existingi >> VMS$COMMON logical? >o3 >You may well be better off extending SYS$SYSROOT -n( >I started doing that back in V4.5 or so$ >and it's never got in the way yet.  >a0 >> I am *not* trying to avoid manual reading --  >  >This won't be in the manual!n  E As you are off in the realms of the unsupported and undocumented, why F not consider ditching the RZ23 altogether and employing an alternativeH trick of initialising the the 2Gb drive with /INDEX=BEGIN and creating aF container file occupying the high end of the drive and then installingC VMS in the rest (thus guaranteeing not to place any vital boot-timemG files beyond the 1Gb watershed).  The container file can then be served-G up by LD as DISK$POOL.  This keeps the system and the (presumably) usere1 data apart and can simplify backups and the like.C  # Makes for more fun restoring, too !q     	John    ------------------------------   Date: 24 Aug 2001 23:08:52 GMT. From: destefan@juniata.edu (Anthony DeStefano) Subject: Digital LG06l6 Message-ID: <slrn9odni0.gpr.destefan@mars.juniata.edu>  @ We have a Digital LG06 here and everyone has seemed to misplacedC the manual.  What we need to know is how to "unlock" it.  EverytimeuD I try to change a setting on it's control panel it returns "locked".  E I've searched everywhere on the net that I know of and the only thingoE I've found so far is that you can order the "Operator Manual" for $20t2 and the "Maintance Manual" for $120 from Compaq :/   Thanks for any help, Tony   ------------------------------  # Date: Fri, 24 Aug 2001 23:47:49 GMT.2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Digital LG0632 Message-ID: <FIBh7.783$bB1.32631@news.cpqcorp.net>  g In article <slrn9odni0.gpr.destefan@mars.juniata.edu>, destefan@juniata.edu (Anthony DeStefano) writes:oA :We have a Digital LG06 here and everyone has seemed to misplacedRD :the manual.  What we need to know is how to "unlock" it.  EverytimeE :I try to change a setting on it's control panel it returns "locked".y  &   Usually, press UP and DOWN together.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 24 Aug 2001 21:49:45 -0400e' From: Howard S Shubs <howard@shubs.net>c Subject: Re: Digital LG06e< Message-ID: <howard-44B0F4.21494524082001@enews.newsguy.com>  2 In article <FIBh7.783$bB1.32631@news.cpqcorp.net>,4  hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote:  F > :the manual.  What we need to know is how to "unlock" it.  EverytimeG > :I try to change a setting on it's control panel it returns "locked".  > ( >   Usually, press UP and DOWN together.  ) Sounds like a relabled Printronix device.s -- a Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Fri, 24 Aug 2001 11:30:21 -0700n! From: Don Sykes <don@alphase.com>e% Subject: Feeling Better about Itaniump+ Message-ID: <3B869D3D.6932C271@alphase.com>i  " This may be old news for some, butH As one who was concerned (not quite panicked) about moving from Alpha, IB was relieved by the talk given by Cathy Stockwell yesterday at the? Diamond Forum in Cupertino,CA. The most important points being:rE A) the Intel 64 bit of today or even tomorrow, will NOT be the one topE support VMS. The EV8 design team that has been assigned to Intel will G make a significant impact on the design that will eventually be our VMSl	 platform.fG B) The EV6 & EV7 teams are still at Compaq and will continue to deliverbB improvements for the next few (~3) years. So even if the new IntelH design doesn't deliver, they could extend the Alpha line until the Intel
 does deliver.gE C) New Alphas will continue to be built and sold for a few years evenH  after the Intel's are available.  D Although no one can guarantee Compaq's word, Cathy did a good job in, dispelling the concerns of this old VMS'er.  Donn   ------------------------------  % Date: Fri, 24 Aug 2001 15:20:05 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>s) Subject: Re: Feeling Better about Itaniumr, Message-ID: <3B86A8D8.565D04D2@videotron.ca>   Don Sykes wrote:G > support VMS. The EV8 design team that has been assigned to Intel willeI > make a significant impact on the design that will eventually be our VMSa > platform.e  F Do you seriously beleive that ? The IA64 architecture has already beenM designed. While the Digits may help improve that architecture and improve itsgE performance, they aren't going to be able to dramatically change thatf@ architecture because that architecture has now be cast in stone.  J Remember that IA64 is a chip built of compromises and various requirementsF (such as support for pA-RISC) which may make it extremely difficult toE streamline that architecture to permit all the fancy techniques AlphabC engineers were going to use to make Alpha reach the speed of light.x  M Compaq realises that it needs to spin this bad technological decision. CompaqtK knows that Alpha was better, but its had no choice because killing Alpha inaN exchange for a wad of money was part of its strategic plan. So it tries to put a good face to this.  N And if the Digital engineers were truly needed to make IA64 a viable platform,K that says a lot about the current crop of Intel engineers, and it says eveneG more about Compaq jumping into an architecture it knows was designed bydJ engineers that were so "incompetant" that Compaq had to donate its Digital? engineers and wait a few years before that chip becomes usable.w  M And it says a lot about a company committin to a platform that is so bad that-1 Compaq has to donate its own engineers to fix it.o  N Compaq should have just outright admitted that it was not in the chip businessI and wanted the most money for its Alpha copyrights and engineers and that J while IA64 was an inferior platform, Compaq could be more profitable usingJ Intel's junk instead of the high quality Alpha. Decision may not have beenJ popular, but at least Compaq would have been honest with its customers and would have retained some trust.5   ------------------------------  % Date: Fri, 24 Aug 2001 15:25:38 -0400m' From: "Bill Todd" <billtodd@foo.mv.com>y) Subject: Re: Feeling Better about Itaniuml( Message-ID: <9m69ms$fqe$1@pyrite.mv.net>  . "Don Sykes" <don@alphase.com> wrote in message% news:3B869D3D.6932C271@alphase.com...a$ > This may be old news for some, butJ > As one who was concerned (not quite panicked) about moving from Alpha, ID > was relieved by the talk given by Cathy Stockwell yesterday at theA > Diamond Forum in Cupertino,CA. The most important points being: G > A) the Intel 64 bit of today or even tomorrow, will NOT be the one totG > support VMS. The EV8 design team that has been assigned to Intel willwI > make a significant impact on the design that will eventually be our VMS  > platform.a  F Sorry to disappoint you, but either Cathy is still spouting the CompaqD bullshit that accompanied the announcement or you misunderstood her.  J If VMS becomes available on IA64 in 3 years, as projected, the platform itL will run on won't have any measurable contribution from Alpha, since it willL either be McKinley (already in silicon) or its follow-on (Madison?) which isK already pretty well-defined.  The earliest you could expect even peripheraliL features (such as the on-chip glue for RAMBUS and SMP) is some time in 2005,K and the earliest you could expect fundamental architectural impact (such asT SMT) is some time in 2006.  E I guess those qualify as 'eventually', but my impression was that youeH thought their introduction would accompany VMS's on IA64, and that's notJ projected to be the case (and from their posts the VMS engineers certainly9 don't appear to expect any hardware help for their port).e  I > B) The EV6 & EV7 teams are still at Compaq and will continue to delivervD > improvements for the next few (~3) years. So even if the new IntelJ > design doesn't deliver, they could extend the Alpha line until the Intel > does deliver.a  K They even could develop EV8.  I see no reason to advise you to count on it, A however:  there's not even any guarantee that EV7 will ever ship.   G > C) New Alphas will continue to be built and sold for a few years eveng" > after the Intel's are available.  K If you feel you can trust Compaq's 'commitments' in this area more than youo/ were able to trust its commitments in the past.n   >.F > Although no one can guarantee Compaq's word, Cathy did a good job in- > dispelling the concerns of this old VMS'er.e  K It's by no means clear why, however.  If there's something you haven't toldoJ us, I strongly suspect that a lot of people would be interested in hearingL it (there keep being these allegations of information imparted to privileged2 parties but not made available to the hoi polloi).   - bill   > Don    ------------------------------    Date: 24 Aug 2001 14:27:27 -0500+ From: young_r@encompasserve.org (Rob Young)T) Subject: Re: Feeling Better about Itaniumn3 Message-ID: <b4m2T$l7u3P8@eisner.encompasserve.org>o  \ In article <3B86A8D8.565D04D2@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Don Sykes wrote:H >> support VMS. The EV8 design team that has been assigned to Intel willJ >> make a significant impact on the design that will eventually be our VMS >> platform. > H > Do you seriously beleive that ? The IA64 architecture has already beenO > designed. While the Digits may help improve that architecture and improve its G > performance, they aren't going to be able to dramatically change thatoB > architecture because that architecture has now be cast in stone. >   = 	Yes.  Pentium Pro was/is essiantilly a VLIW engine that tookb@ 	IA32 and pipelined the instructions gaining a grand improvement 	versus Pentium performance.  F 	Intel is masterful at hiding bad designs through clever architecturalB 	enhancements.  They didn't hire Alpha designers because they feltA 	sorry for them.  And yes, we know from comp.arch posts there are.+ 	"former" Alpha designers working at Intel.i  > 	Intel wanted/wants the Alpha designers to design a future IPFA 	processor.  They aren't paying them a paycheck because they feele 	sorry for them.   	JF, what part don't you "get?"t   				Rob    ------------------------------  % Date: Fri, 24 Aug 2001 16:06:52 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>t) Subject: Re: Feeling Better about Itaniumm( Message-ID: <9m6c4b$hv4$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:b4m2T$l7u3P8@eisner.encompasserve.org...o7 > In article <3B86A8D8.565D04D2@videotron.ca>, JF Mezeia& <jfmezei.spamnot@videotron.ca> writes: > > Don Sykes wrote:J > >> support VMS. The EV8 design team that has been assigned to Intel willL > >> make a significant impact on the design that will eventually be our VMS > >> platform. > >eJ > > Do you seriously beleive that ? The IA64 architecture has already beenE > > designed. While the Digits may help improve that architecture and  improve itstI > > performance, they aren't going to be able to dramatically change thatfD > > architecture because that architecture has now be cast in stone. > >  >t> > Yes.  Pentium Pro was/is essiantilly a VLIW engine that tookA > IA32 and pipelined the instructions gaining a grand improvementu > versus Pentium performance.J  F And its IA32 descendants have continued that improvement though use ofJ technologies, primarily OOO execution, that are not only conspicuously but> *intentionally* (at the highest design levels) absent in IA64.  J IA64 was designed explicitly to *avoid* use of OOO execution.  That choiceL is starting to appear to be a major and fundamental error for performance inI most real-world use, and one that will be extremely expensive to correct,hJ since the features that EPIC depends upon (and that its instruction set isL explicitly designed to leverage, although not to all that great effect) makeK adding OOO and SMT much more difficult (read:  the redesign will take a lot I of time and effort) and chip-real-estate-expensive than the same features 
 are in Alpha.i   >vG > Intel is masterful at hiding bad designs through clever architecturalo > enhancements.m  I They have proved this *once* (and admittedly very well) in IA32.  But, astL noted above, the approaches they took to enhance IA32 are far more difficult to apply to enhancing IA64.e  J By contrast, Alpha engineering has proved consistently for nearly a decadeJ its ability to keep a *good* design at the forefront of the industry - butL the degree to which this experience can readily be transferred to rescuing aD fundamentally *bad* design remains to be seen, and under the best ofH circumstances will take a long time (placing the future IA64 performance: road map 2 - 3 years behind what Alpha's would have been).   ...n    > JF, what part don't you "get?"  H I'd say that JF 'got' it pretty well, but may have left out some detailsH which I've filled in above.  Just what part of it now don't *you* 'get', Rob?   - bill   >a > Robo >    ------------------------------  % Date: Fri, 24 Aug 2001 16:16:16 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>s) Subject: Re: Feeling Better about Itaniuml, Message-ID: <3B86B60F.F52C6EF6@videotron.ca>   Rob Young wrote:F >         Yes.  Pentium Pro was/is essiantilly a VLIW engine that tookI >         IA32 and pipelined the instructions gaining a grand improvementa% >         versus Pentium performance.   J The problem is that if IA64 starts off with a bad architecture, it will beJ hindered by that baggage for the rest iof its life, just like Pentiums areC hindered by the 8086.  The fact that Intel is now developping a neweN architecture is a good indication that Intel saw the limit approaching for the 8086 architecture.  I So yes, IA64 will be improved and its speed will be improved, but it will,2 retain its basic architecture and instruction set.  G >         Intel wanted/wants the Alpha designers to design a future IPFoJ >         processor.  They aren't paying them a paycheck because they feel >         sorry for them.$  I Well, a "future IPF processor". Do you mean an improved IA64, or some new H architecture ? As far as I know, Compaq committed to IA64. So if DigitalM engineers are tasked to develop some new architecture, VMS won't benefit from 5 it. "IPF" as far as I am concerned is a generic term.s   ------------------------------    Date: 24 Aug 2001 15:50:31 -0500+ From: young_r@encompasserve.org (Rob Young).) Subject: Re: Feeling Better about Itanium.3 Message-ID: <REN5T3qngjdh@eisner.encompasserve.org>W  R In article <9m6c4b$hv4$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:   >  >  > ...r > ! >> JF, what part don't you "get?"- > J > I'd say that JF 'got' it pretty well, but may have left out some detailsJ > which I've filled in above.  Just what part of it now don't *you* 'get', > Rob? >   A 	The part I don't "get" is why would you trim portions to make it1B 	appear is if the question is dangling in mid-air?  The part aboutC 	Alpha designers.  The missing context of which leaves the questionmC 	dangling in mid-air.  That is now the part I don't get.  Actually, D 	I do get it.  It is again another thin attempt to twist and turn.  G 	Someone posts (see subject line) a more positive outlook for them now,mH 	and it is quickly twisted.  Sorry, the Compaq folks are doing a fairly H 	good job with the people that count most.  The ones invited to Diamond  	Forums.  8 	Meanwhile, those on the fringes are still wailing away.   				RobC    N "To be sober means to have a calm, clear head, to judge things after the rule N of right, and not according to mob rule.  Don't be influenced by those who cry8 the loudest, or by those who beat the biggest drum"        		-- C.H. Spurgeon   ------------------------------  % Date: Fri, 24 Aug 2001 17:23:29 -0400n2 From: "Sue Skonetski" <susan.skonetski@compaq.com>) Subject: Re: Feeling Better about Itanium 2 Message-ID: <%Azh7.768$bB1.32693@news.cpqcorp.net>  E You know folks the fact that Don feels better and Compaq is trying toiG communicate is a good thing.  People should be allowed to express theirdH opinions even if they are good.  I think that the newsgroup has to allowF folks to state their opinions with out being hammered.  If someone hasE something to positive to say and they want to share it they should beo allowed to.   J And from personal experience I can tell you,  if you get hammered as beingI unaware, or swallowing Compaq Bull or you are blind or uneducated it sureiH does not make you want to communicate and we need more communication notJ less.  And then all we will be left with is negative baggage that everyone= can complain about in the newsgroup and nothing constructive.b  J And I know Cathy Stockwell and in the entire time I have known her she hasI never said a lie and has communicated as openly and honestly as possible, K she is an OpenVMS Ambassador and has been with the company for more than 200 years and is a good person.a  H We don't do everything correct but you know we don't do everything wrongK either.  And while I am on the soap box, you can only say you are sorry fors4 selling products to different companies for so long.   suew      2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9m69ms$fqe$1@pyrite.mv.net... >.0 > "Don Sykes" <don@alphase.com> wrote in message' > news:3B869D3D.6932C271@alphase.com...a& > > This may be old news for some, butL > > As one who was concerned (not quite panicked) about moving from Alpha, IF > > was relieved by the talk given by Cathy Stockwell yesterday at theC > > Diamond Forum in Cupertino,CA. The most important points being:aI > > A) the Intel 64 bit of today or even tomorrow, will NOT be the one torI > > support VMS. The EV8 design team that has been assigned to Intel willuK > > make a significant impact on the design that will eventually be our VMSy
 > > platform.t >iH > Sorry to disappoint you, but either Cathy is still spouting the CompaqF > bullshit that accompanied the announcement or you misunderstood her. >yL > If VMS becomes available on IA64 in 3 years, as projected, the platform itI > will run on won't have any measurable contribution from Alpha, since ite willK > either be McKinley (already in silicon) or its follow-on (Madison?) whichr isB > already pretty well-defined.  The earliest you could expect even
 peripheralH > features (such as the on-chip glue for RAMBUS and SMP) is some time in 2005,eJ > and the earliest you could expect fundamental architectural impact (such as > SMT) is some time in 2006. >-G > I guess those qualify as 'eventually', but my impression was that you.J > thought their introduction would accompany VMS's on IA64, and that's notL > projected to be the case (and from their posts the VMS engineers certainly; > don't appear to expect any hardware help for their port).  >uK > > B) The EV6 & EV7 teams are still at Compaq and will continue to deliver F > > improvements for the next few (~3) years. So even if the new IntelL > > design doesn't deliver, they could extend the Alpha line until the Intel > > does deliver.2 >uI > They even could develop EV8.  I see no reason to advise you to count ong it,eC > however:  there's not even any guarantee that EV7 will ever ship.s >yI > > C) New Alphas will continue to be built and sold for a few years evenb$ > > after the Intel's are available. > I > If you feel you can trust Compaq's 'commitments' in this area more thani you.1 > were able to trust its commitments in the past.  >  > >dH > > Although no one can guarantee Compaq's word, Cathy did a good job in/ > > dispelling the concerns of this old VMS'er.a >gH > It's by no means clear why, however.  If there's something you haven't toldL > us, I strongly suspect that a lot of people would be interested in hearingC > it (there keep being these allegations of information imparted toe
 privileged4 > parties but not made available to the hoi polloi). >d > - bill >N > > Don  >l >n   ------------------------------  % Date: Fri, 24 Aug 2001 16:52:35 -0500i+ From: Christopher Smith <csmith@amdocs.com>q) Subject: RE: Feeling Better about ItaniumgL Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DB7F@cmiexch1.cmi.itds.com>   > -----Original Message-----9 > From: Sue Skonetski [mailto:susan.skonetski@compaq.com]j  G > You know folks the fact that Don feels better and Compaq is trying too< > communicate is a good thing.  People should be allowed to  > express theira> > opinions even if they are good.  I think that the newsgroup  > has to allowH > folks to state their opinions with out being hammered.  If someone hasG > something to positive to say and they want to share it they should ber
 > allowed to.e  8 I wanted to follow this up in agreement with you, Sue.    A I also wanted to say that Bill's post probably wasn't intentionalcL "hammering."  His tone comes from the fact that he's upset with Compaq aboutF the IA63 decision, but most of the content of the message was factual.K (Regarding which revisions of the chip would likely acquire Alpha features,eG etc, etc.)  Of course at the end he starts verbally lashing Compaq (not K Don), but I think there's less of that than actual information in the post.l  A Basically he said something perfectly relevant, in the wrong way.   H On the other hand, there seems to be a complete lack of civility here of( late, and I hope that it will soon stop.   Regards,   Chrisn  ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");e 'e  o   ------------------------------  % Date: Fri, 24 Aug 2001 22:09:19 -0000i- From: wspencer@ap.nospam.org (Warren Spencer)d) Subject: Re: Feeling Better about Itaniuma7 Message-ID: <9107BFB55warrenspencer1977@207.126.101.97>y  3 susan.skonetski@compaq.com (Sue Skonetski) wrote in ( <%Azh7.768$bB1.32693@news.cpqcorp.net>:   F >You know folks the fact that Don feels better and Compaq is trying toH >communicate is a good thing.  People should be allowed to express theirI >opinions even if they are good.  I think that the newsgroup has to allowaG >folks to state their opinions with out being hammered.  If someone hasyF >something to positive to say and they want to share it they should be >allowed to. >iE >And from personal experience I can tell you,  if you get hammered as-* >being unaware, or swallowing Compaq Bull    -- snip remainder --  3 Glad to see "Compaq Bull" is now a proper name <g>.B  E I've put out a memo to my colleagues here that essentially says that kK OpenVMS's move to Intel is likely a good thing for us over the *long*term*.a  A However, Bill's repeated thumping on the desk regarding Compaq's oL questionable statement that  "Alpha can't keep up with IA-64", while mildly K annoying, serves a purpose whole-heartedly I agree with:  Make Compaq come s clean on this statement.  F The trust has been fractured, and cannot be restored with more weasel F words.  Real facts are required, and Compaq's ongoing silence in this 4 matter worsens its credibility, from my perspective.   ws   -- b   Warren Spencer( Senior Software Engineer (not a writer!) The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  % Date: Fri, 24 Aug 2001 18:11:32 -0400r' From: "Bill Todd" <billtodd@foo.mv.com>l) Subject: Re: Feeling Better about Itaniumi( Message-ID: <9m6jdu$np1$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:REN5T3qngjdh@eisner.encompasserve.org...aL > In article <9m6c4b$hv4$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:h   ...e  # > >> JF, what part don't you "get?"c > > L > > I'd say that JF 'got' it pretty well, but may have left out some detailsL > > which I've filled in above.  Just what part of it now don't *you* 'get', > > Rob? > >  >4B > The part I don't "get" is why would you trim portions to make it3 > appear is if the question is dangling in mid-air?h  % I guess that means you didn't get it.e     The part about > Alpha designers.  I You mean the part where you imply that they will wave their hands and note= only work miracles but do so in some comparable time-frame to I previously-planned Alpha development?  That's what I responded to, rather ; adequately, I think.  Try re-reading for content next time.:   ...'  J > "To be sober means to have a calm, clear head, to judge things after the ruleL > of right, and not according to mob rule.  Don't be influenced by those who cryf5 > the loudest, or by those who beat the biggest drum"a  C Which would be Compaq and its apologists.  We're just providing the I appropriate (and clear-and-sober, at least in my own case) counter-point.    - bill   ------------------------------  % Date: Fri, 24 Aug 2001 18:29:39 -0400.- From: JF Mezei <jfmezei.spamnot@videotron.ca> ) Subject: Re: Feeling Better about Itanium , Message-ID: <3B86D551.5308A18F@videotron.ca>   Sue Skonetski wrote:I > communicate is a good thing.  People should be allowed to express their " > opinions even if they are good.   D Yep, but people should also be allowed to point out that some of theM propaganda spewed by Compaq goes against actual actions (or the way they werenL taken). It is one thing for Compaq to state that the move to IA64 is a greatI thing for VMS, but it should be put into a context where VMS was given no L choice, and where VMS engineers learned of that decision at the same time asD customers, that Compaq lied about the future performance of Alpha as) justification for killing it etc etc etc.y  H Compaq has not been honest about the real reasons for killing Alpha. The, reasons given have little to no credibility.  J Someone who has not monitored the various aspects of Compaq would not haveJ enough information to see through the propaganda that Compaq employees areN forced to spew out. But when you combine how financial presentatiosn are made,L statements from Compaq power VPs such as Winkler, the way and context of theL alpha murder announcement, you realise Compaq's true intentions do not matchH Compaq's propaganda. And becomes very interesting when Compaq's "public"G propaganda which is all wintel focused is at odds with Compaq's focusedr propaganda to VMS customers.  B Compaq pretends to be an enterprise IT corporation. But it clearlyN underestimates its enterprise customer's ability to read between the lines andN see through propaganda. And this should not be news to Compaq since the Palmer> era has clearly sensitized customers to this type of activity.   ------------------------------  % Date: Fri, 24 Aug 2001 18:35:12 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>@) Subject: Re: Feeling Better about Itaniumm( Message-ID: <9m6kq9$ohc$1@pyrite.mv.net>  = "Sue Skonetski" <susan.skonetski@compaq.com> wrote in message0, news:%Azh7.768$bB1.32693@news.cpqcorp.net...G > You know folks the fact that Don feels better and Compaq is trying toe > communicate is a good thing.  J Don's feeling better is a good thing only if the feeling does not lead himJ astray in the decisions he makes (e.g., give him faith in a future that isK not likely to occur, and thus cause him to make decisions he may have cause  to regret).a  H Compaq's attempt to communicate is a good thing only if it's telling theH truth.  In this case, either it wasn't or its message was misunderstood.  +   People should be allowed to express theire! > opinions even if they are good.   G I suggest that your reading of my post was strongly colored by your ownrK opinions rather than objective.  In no way did I suggest that Don's opiniont was not welcome.  )   I think that the newsgroup has to allowO8 > folks to state their opinions with out being hammered.  D While I was straight-forward in what I wrote and did not hesitate toE indicate where I felt his perceptions were in error, in no way did itnH constitute 'hammering' (when I hammer someone, there's very little doubt
 about it).     If someone hasG > something to positive to say and they want to share it they should bes
 > allowed to.   A He was.  That doesn't mean it shouldn't be responded to, however.    >lL > And from personal experience I can tell you,  if you get hammered as being
 > unaware,  J There appear to have been issues of which he was unaware, but that doesn't. constitute 'hammering' but simply 'informing'.   > or swallowing Compaq Bullr  H Again, I didn't criticize him for believing it, just pointed out that he$ either misunderstood or was mislead.    > or you are blind or uneducated  2 And exactly where did you get *that* from my post?    it sureJ > does not make you want to communicate and we need more communication not > less.   L Yes - but the source from which we need it the most (Compaq) isn't providingI much information.  It seems to be reserving it for a forum (CETS) that iti feels better able to control.n  E   And then all we will be left with is negative baggage that everyoneg? > can complain about in the newsgroup and nothing constructive.b >nL > And I know Cathy Stockwell and in the entire time I have known her she hasK > never said a lie and has communicated as openly and honestly as possible,hJ > she is an OpenVMS Ambassador and has been with the company for more than 20 > years and is a good person.-  K That leaves two possibilities:  she was either misinformed herself (as manyMJ people were by Compaq's statements at and shortly after the announcement), or Don misunderstood her..   >EJ > We don't do everything correct but you know we don't do everything wrong	 > either.V  L The VMS group does very little wrong.  Unfortunately, the VMS group also has' very little control over VMS's destiny.m  D   And while I am on the soap box, you can only say you are sorry for6 > selling products to different companies for so long.  K Though as I just said above the VMS group is largely above reproach, CompaqIF has a great deal to say it's sorry for:  lies, broken commitments, andK abject (and completely unnecessary) non-performance in its custodianship oflJ valuable products that are important to its customers, to start with.  (ItF should apologize to its stockholders for at least the last of these as well.)   - bill   ------------------------------  # Date: Fri, 24 Aug 2001 23:58:00 GMTc& From: "Jeff Killeen" <Jeff@IDM-IO.com>) Subject: Re: Feeling Better about Itanium"7 Message-ID: <cSBh7.444$A83.133613@typhoon1.gnilink.net>e  5 > Glad to see "Compaq Bull" is now a proper name <g>.t  - Did Compaq buy a French computer company? ;-)i   ------------------------------  # Date: Sat, 25 Aug 2001 00:13:50 GMT . From: Burnie M <burniem.NOSPAM@ozemail.com.au>) Subject: Re: Feeling Better about Itanium 8 Message-ID: <15rdotg39cncji73c359ncqfnplbg88u5v@4ax.com>  3 On Fri, 24 Aug 2001 17:23:29 -0400, "Sue Skonetski"n# <susan.skonetski@compaq.com> wrote:<   <snip>  K >And I know Cathy Stockwell and in the entire time I have known her she has J >never said a lie and has communicated as openly and honestly as possible,L >she is an OpenVMS Ambassador and has been with the company for more than 20 >years and is a good person.   <snip>   >sue    F I do not believe that anybody stated that she was lying but there is aD big difference between (truthfully) presenting part of the situation and telling us the full story.A ...but then we have commented on this so many times and Compaq isn still stonewalling us.  E We (the customer Systems Groups) have been selling a really excellentdE product for Compaq for so many years now (because your sales force is  not). F I am getting tired of it and more, I am getting very fed up with being treated like a mushroom.   Burnie M   ------------------------------  % Date: Fri, 24 Aug 2001 17:07:19 -0700t< From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>) Subject: Re: Feeling Better about Itaniumg) Message-ID: <3B86EC37.83554844@intel.com>    Sue Skonetski wrote:  G > You know folks the fact that Don feels better and Compaq is trying to I > communicate is a good thing.  People should be allowed to express their J > opinions even if they are good.  I think that the newsgroup has to allowH > folks to state their opinions with out being hammered.  If someone hasG > something to positive to say and they want to share it they should ben
 > allowed to.n >oL > And from personal experience I can tell you,  if you get hammered as beingK > unaware, or swallowing Compaq Bull or you are blind or uneducated it sureaJ > does not make you want to communicate and we need more communication notL > less.  And then all we will be left with is negative baggage that everyone? > can complain about in the newsgroup and nothing constructive.f  J Indeed, there is precedent, in this very news group, for what happens whenK one (or more) participants take on a role of criticizing nearly every post,oH or every post that doesn't take their particular point of few (RIP CJL).M By my count, and IMHO, there are about 2 1/2 such in the current environment,cG one particularly abrasive one, and a "few" others that, while not beingh@ abrasive or rude (two Brownie points for each! :-), are tiringly- repetitive and make threads run way too long.d  F In the past case, it was patently clear that CJL's style and frequency@ drove out other posters, including highly technical, experiencedF professionals (e.g., Steve Lionel) and newbies and lurkers were simplyG afraid to post.  When CJL passed, c.o.v became a much more civil place,nH many more people started participating, the level of discussion improvedH immensely, and and the long, tedious, abusive flame-wars dies out almostE over night (even though many were very much saddened by his passing).l  I Ladies and gentlemen, NONE of us benefit from the monopolization of ideas I expressed here when those with ideas different from the "majority" (i.e., J Larry Kilgallen's "Jonny One Notes") posts, choose not to post them eitherF out of a desire not to be abused publicly by Jonny One Note, or out ofE disgust for the unprofessional level to which these "discussions", org better, "arguments", have sunk.g  F Even an old geezer like me who's not afraid to argue a point publicly,G and be shown to be wrong(!), has a gut reaction when each sentence I'veh@ typed in a post gets a snide, denigrating or sarcastic response.A Pot shots, thinks I.  Not an honest exchange of ideas.  Closer toa ad hominem attacks.f  F So here's sympathy for anyone who feels put off by Jonny One Note, and> an invitation to please post your ideas, assessments, personalE professional experience, and to ignore the "abuse" heaped on by thoseaE who want to dominate the discussion and drown out other voices.  JustiD ignore them.  They won't go away, but don't feel you need to respond to them either...u       -Ken --6 I don't speak for Intel, Intel doesn't speak for me...   ------------------------------  % Date: Fri, 24 Aug 2001 18:23:05 -0700.! From: Don Sykes <don@alphase.com>d) Subject: Re: Feeling Better about Itanium + Message-ID: <3B86FDF9.F204CA18@alphase.com>s  G Fortunately, or unfortunately, I'm not sure yet, I have other things torG do besides monitoring this newsgroup. So I just saw all these replies. l   First to Bill:@ Far be it from me to "feel better" about anything these days w/oE suffering the ire of someone. And yes, I have misunderstood things ineC the past, but it seemed clear that McKinley and Madison (and here IV= don't pretend to know the details of either's organization or:A implementation) are NOT the chips on which VMS will run. What was D conveyed to us was that the Alpha group (EV8 folks) will be, and areG already, impacting the chip that will come AFTER Madison and to me thatoH sounds pretty good. It means that the people who built the Alpha will beH incorporating that knowledge onto the whatever comes AFTER Madison. TrueG Compaq could be lying or grossly exaggerating, but I don't see why theyiG would. They make a lot of $$ with VMS (more this year than last I hear)mH and there are a lot of folks around (espec in the EU) that wouldn't wantF anything else and would look elsewhere if they couldn't get it. To sayG nothing of very binding commitments they have made to the DOD & NASA 20tF years out. It sounds like you're saying that Compaq just wants to dumpH VMS at any cost ? But how would that help them ? What would their motive? be for deploying a profitable OS on an unworkable, or at least,  seriously flawed chip ?      To JF:G You talk about the Intel engineers as if they're a bunch of morons. AregD you a chip designer ? I was at DEC when the 1st Alpha chip was beingE developed and I heard it was a mighty BIG process. If Intel is havingoC trouble, I'm not surprised, but that doesn't mean they're all dumb.r@ Mature people ask for help if they need it. That's not a sign of	 weakness.      To all: H I want to see VMS progress into the future as much as anyone and I can'tH think of a better (i.e. more practical) way to do that than gain a widerF acceptance by making it available on a cheaper, more widely used chip.     'till Mon then...s Dona         Bill Todd wrote: > 0 > "Don Sykes" <don@alphase.com> wrote in message' > news:3B869D3D.6932C271@alphase.com... & > > This may be old news for some, butL > > As one who was concerned (not quite panicked) about moving from Alpha, IF > > was relieved by the talk given by Cathy Stockwell yesterday at theC > > Diamond Forum in Cupertino,CA. The most important points being:hI > > A) the Intel 64 bit of today or even tomorrow, will NOT be the one tofI > > support VMS. The EV8 design team that has been assigned to Intel willaK > > make a significant impact on the design that will eventually be our VMS 
 > > platform.h > H > Sorry to disappoint you, but either Cathy is still spouting the CompaqF > bullshit that accompanied the announcement or you misunderstood her. > L > If VMS becomes available on IA64 in 3 years, as projected, the platform itN > will run on won't have any measurable contribution from Alpha, since it willN > either be McKinley (already in silicon) or its follow-on (Madison?) which isM > already pretty well-defined.  The earliest you could expect even peripheral.N > features (such as the on-chip glue for RAMBUS and SMP) is some time in 2005,M > and the earliest you could expect fundamental architectural impact (such ase > SMT) is some time in 2006. > G > I guess those qualify as 'eventually', but my impression was that youoJ > thought their introduction would accompany VMS's on IA64, and that's notL > projected to be the case (and from their posts the VMS engineers certainly; > don't appear to expect any hardware help for their port).u > K > > B) The EV6 & EV7 teams are still at Compaq and will continue to deliver F > > improvements for the next few (~3) years. So even if the new IntelL > > design doesn't deliver, they could extend the Alpha line until the Intel > > does deliver.e > M > They even could develop EV8.  I see no reason to advise you to count on it,oC > however:  there's not even any guarantee that EV7 will ever ship.e > I > > C) New Alphas will continue to be built and sold for a few years even $ > > after the Intel's are available. > M > If you feel you can trust Compaq's 'commitments' in this area more than youf1 > were able to trust its commitments in the past.t >  > >tH > > Although no one can guarantee Compaq's word, Cathy did a good job in/ > > dispelling the concerns of this old VMS'er.  > M > It's by no means clear why, however.  If there's something you haven't toldsL > us, I strongly suspect that a lot of people would be interested in hearingN > it (there keep being these allegations of information imparted to privileged4 > parties but not made available to the hoi polloi). >  > - bill >  > > Don    ------------------------------  % Date: Fri, 24 Aug 2001 23:47:51 -0400m- From: JF Mezei <jfmezei.spamnot@videotron.ca>r) Subject: Re: Feeling Better about Itaniumo, Message-ID: <3B871FDC.BB0D1A87@videotron.ca>   Don Sykes wrote: > To JF:E > You talk about the Intel engineers as if they're a bunch of morons.   N No, I am saying that Compaq's rethoric makes it look like Compaq beleives thatE Intel designers are a bunch of morons, and it isn't until the DigitaloE engineers get to "fix" IA64 that IA64 will be good enough to run VMS,s@ according to what/how Compaq is presenting its propaganda to us.  M But in reality, the VMS engineers were asked to port VMS on existing IA64s sooL VMS *should* be available on IA64 machines well before Compaq's predictions.L But Compaq thinks that delaying VMS on IA64 until after EV7 would be better,= so it will concuct whatever excuse is necessary to save face.T  W In other words, Compaq's rethoric, instead of helping, is hurting Compaq's credibility.n  M Compaq has relinquished its patents, engineers and compiler experts to Intel.sM There is no telling how many of these will actually stay with Intel. Compaq'slJ managers won't have any say over what former Digital employees do as IntelR employees. So Compaq has no business making any promises about the future of IA64.  L Compaq has become dependant on Intel for not only chip/architecture but alsoN compilers. Compilers that will also be used by Compaq's competitors. So CompaqM won't be able to claim any edge over its competitors since they will have thesM same products and same compilers as Compaq (except for Sun, IBM and Apple whobI retain some control over their technology). So any speed improvement madesK available by Intel on its IA64 won't give Compaq any edge since Dell and HPt; will also benefit from those improvements at the same time.g  M Consider also that VMS will no longer run on a chip faster than competitor's, K so its additional overhwad due to it being a robust system will become much H more visible compared to its competitors that will run on the same chip.    L Consider that HP and Microsoft have far more control over the future of IA64K than any individual box maker such as Compaq. If Microsoft wants some fancy.M graphic instruction, it can petition Intel to include it. But Compaq, without L chip or compiler designers will be a simple box maker without much weight inJ IA64 architecture decisions. Furthermore, the bulk of Compaq's use of IA64L will be for wintel servers whose features are dictated by Microsoft. The lowK volume systems for Tandem,VMS and Tru64 won't have much clout when the timehM comes to ask Intel for new features (especially since Compaq is not likely top push these systems much).f  M Compaq chose to exit the chip business and focus on its core wintel business.pL That is its right and there isn't anything we can do about it.  But in doingM so, Compaq relinquishes the right to make any predictions over products it nog longer controls.   ------------------------------  % Date: Sat, 25 Aug 2001 01:35:41 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>-) Subject: Re: Feeling Better about Itanium ( Message-ID: <9m7deo$gqo$1@pyrite.mv.net>  G "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com> wrote in messageD# news:3B86EC37.83554844@intel.com...e   ...s  H > So here's sympathy for anyone who feels put off by Jonny One Note, and@ > an invitation to please post your ideas, assessments, personalG > professional experience, and to ignore the "abuse" heaped on by thoselG > who want to dominate the discussion and drown out other voices.  JustiF > ignore them.  They won't go away, but don't feel you need to respond > to them either...t  H You know, what you think about participants and posts in this discussionJ depends very strongly on where you yourself stand (Sue's recent experienceD being a particularly good example).  And I suspect that an objectiveH observer would find similar amounts of repetitiveness (and abuse) coming from both sides.  L Don't confuse an inclination to respond to extremely dubious assertions withH a desire to dominate:  they're nothing like the same thing.  The closestH things I've seen to a desire to control (rather than participate in) theD discussion are the pointed invitations for some people to take theirG observations elsewhere, but I agree with your sentiment above that such % invitations should simply be ignored.i  I People who are tired of these topics should similarly simply ignore them..H People who aren't tired should recognize that there are likely people of' opposing views who aren't tired either.e  I Compaq changed the rules significantly on June 25th, and reaction to that J change seems unlikely to disappear until they change them yet again (i.e.,H don't expect it just to 'blow over', next month or next year) - or untilG major new information surfaces (I don't expect it to, but neither is itwL impossible to imagine).  Possible sufficiently significant changes include aK change in corporate ownership (people should be willing to give a new owner D a chance, just as they did Compaq), a change in corporate leadershipL combined with a major change in approach to VMS (read:  an aggressive growthK strategy with major new development and marketing funding), or that kind of)I major change in approach combined with a truly convincing "Mea culpa:  wemJ really screwed up this operation and are doing the best we can to recover.J Please help us understand what else we can do to compensate for the damageK we've done" from current leadership.  Again, I'm not holding my breath, but ) don't wholly discount such possibilities.   K Lacking that, expect every statement supporting Compaq's version of realityhC that contravenes fact or common sense - or even some that just seemnF questionable - to be met with an analysis of why it's unbelievable andK accompanied by a reminder that Compaq is completely untrustworthy (and why,nG if relevant):  that's important information that should be available to H people reading this forum, especially newcomers.  If you don't like suchL reactions, don't make such statements.  But if you find logical flaws in theK criticism offered, by all means engage in discussing them:  no one here has H a monopoly on insights, and given the relative paucity of hard facts (asL distinguished form peripheral facts that *seem* to indicate what's going on)0 insights are the bulk of what we must rely upon.   - bill   >t
 >     -Ken > --8 > I don't speak for Intel, Intel doesn't speak for me... >y   ------------------------------  % Date: Fri, 24 Aug 2001 21:41:04 +0200r, From: "Bart Zorn" <B.Zorn@TrueBit.nospam.nl>$ Subject: Re: Freeware Dskmon Utility9 Message-ID: <3b86af17$0$230$e4fe514c@newszilla.xs4all.nl>-  9 "Didier Morandi" <Didier.Morandi@gmx.ch> wrote in messagec  news:3B86923E.FD230DAA@gmx.ch... > Nic Clews wrote: > ../..B > > A simple SETD > > DISPLAY/CREATE/NODE=node[/TRANSPORT=transport] will fix it, also> > > assuming the security allows the creation of said display. >a > A few details: >a4 > the real command in your login.com (or elsewhere): >29 > $ set display/create/node='target_node'/transport=tcpipe >lI > where 'target-node' is either the name or fully qualified name or TCPIP9H > address of the system where you wish to have the display ... displayed >eC > For the security param, if you use DEcwindows, click the SECURITYII > function and add *:*, whish means all IP addresses ad all users allowedv* > to display something on your X terminal. >dI > Of course, you should then change this to avoid an erroneous command to C > display something on your terminal, then an eventual resetof  thesH > originator X server, will causes your terminal to poofff and force youF > to reopen the 12 windows you had opened and carefully sized for yourJ > development session. The reset command sent to a server is actually alsoB > sent to the X terminal where it runs and resets the thing... :-(  L If you are concerned about security, you should use DECNET as transport, not TCPIPyG TCPIP lacks information about the user of the originator (the client int X-windows). With DECNETeL you can restrict access to your display to specific nodename/username pairs, as where you can only  specify nodename/* for TCPIP.t  	 Bart Zorne   ------------------------------  % Date: Fri, 24 Aug 2001 21:06:13 +0100e+ From: "antonio.carlini" <arcarlini@iee.org>8) Subject: Re: Help! Boot Block Information ' Message-ID: <3B86B3B5.F4912D70@iee.org>t  " "Gotfryd Smolik, VMS lists" wrote:  A >  Fortunatelly (och, someone must somethink drink in High Sierra : > for the reason ;)) the formats are uses differrent areas< > for "data description" and *is* possible get a CD-ROM with > both format on it...  + You can, in fact, build a CD-ROM with filest+ visible in both the ISO9660 structure *and*o. the ODS-2 structure but having the data stored. only once ... (obviously this only makes sense, for some formats, but all I need is text and binary - PDF).  . It should be possible to build a CD that would2 *boot* Linux in a PC (using El-Torito) and OpenVMS! on a VAX (and Alpha too I think).e   Antonioo   -- a   --------------- - Antonio Carlini             arcarlini@iee.orge   ------------------------------  % Date: Fri, 24 Aug 2001 21:09:36 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>g0 Subject: Re: Hex dump-and-lookatit-in-themorning' Message-ID: <3B8708E0.BAD649A5@fsi.net>L   Thys de Wet wrote: > ! > Reminds me of my operator days:c > K > Program chrashes at 03:00 right in the middle of the night production runlH > (No OS, no terminals, no disks in those days: Old ICT Orion transistorI > 'puter, Papertape, punch cards, flexowriter, I-line paper, drum memory)t > K > Phone up the standby programmer and lo and behold: "do a hex dump and Illu > look at it in the morning"...dK > He didn't get far.  He had to go and "look at it" in the manager's officea > "in the morning.  F Hhmmm... Maybe just a cultural thing. In American slang, "take a dump" is a euphemism for "defecate".   --   David J. Dachtera, dba DJE Systems, http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Fri, 24 Aug 2001 20:15:16 +0200i  From: Paul Sture <paul@sture.ch>: Subject: Re: How do you search for blank lines in TPU/EVE?+ Message-ID: <VA.0000042a.004477be@sture.ch>h  D In article <23AUG01.18155297@thuria.waisman.wisc.edu>, Carl Karcher  wrote:3 > How would you search for a blank line in TPU/EVE?l > I > I had need to remove blank lines from a text file and could not come upn? > with a way of searching for them in EVE. I used SORT instead., >n7 While the wildcard method is better for this example...e  G You can also use CTRL-V in the REPLACE command (and other commands) to s- insert the next character typed as a literal:e  H E.g. <FIND>^V<RETURN> will search for the next occurrence of a carriage  return.l  H So, if you know that the blank lines are zero length, you could replace % two <CR> characters by a single <CR>.r ___,
 Paul Sture Switzerland"   ------------------------------  % Date: Fri, 24 Aug 2001 14:51:27 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>w: Subject: Re: How do you search for blank lines in TPU/EVE?, Message-ID: <3B86A225.ED1C0E6A@videotron.ca>   Paul Sture wrote:.I > So, if you know that the blank lines are zero length, you could replace0' > two <CR> characters by a single <CR>.u  N This does not work in TPU. (but it works perfectly well in WPSPLUS because WPSI does put a "CR" character at the end of paragraphs/hard lines. So you cansE replace two consecutive CRs with a single one to remove blank lines.)l   ------------------------------  % Date: Fri, 24 Aug 2001 18:47:30 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com>6 Subject: Re: IA-64 Emulation (was: Re: Nits in Slides)* Message-ID: <3B869332.696F2219@uk.sun.com>   Duane Sand wrote:  >  > andrew harrison wrote' > >a > > Hoff Hoffman wrote:i > > >   ...hJ > > >   As for the applicability of notifications or the need for these or > other8K > > >   special assists within IA-64, that remains to be determined.  Givend > thedN > > >   IA-64 features that are already available in support of the HP Ares PAJ > > >   emulator, it certainly appears quite feasible to have emulation on > IA-64. > >uI > > Of course it is but HP developed the IA64 ISA and they made damn sure D > > that they provided the instructions in IA64 to map onto from PA. > > = > > This is a totally different situation to the one you findt9 > > youselves in and a totally different situation to the ) > > one that you were in with VAX->Alpha.  > >h= > > It also depends on how you define feasible, x86 emulatione= > > is known to be slow and there are benchmarks to prove it,o: > > I don't think that HP have published any benchmarks to> > > IA64 running PA binaries so the jury is still out on that. >  > SeeiE > http://www.hp.com/products1/itanium/infolibrary/whitepapers/dct.pdfnK > for an initial HP report on Aries' performance.  It is working quite wellpJ > enough to support HP's customer migration goals.  It doesn't have to runI > fast enough to win benchmarketing wars. It's there to make whole-systemrG > migrations practical while doing native recompiles of major apps at ae > convenient pace. >   ; Actually that isn't the conclusion you would draw from the c white paper refer to.   4 The 4 benchmark results they refer to where Itanium 1 emulating PA-RISC is close to the performance of e0 PA-RISC native are all I/O intensive apps which . spend most of their time in the kernel. Since 1 the kernel is natively compiled for Itanium this 2/ does not really help you determine what the hitr is for emulated vs native.  1 HP then recommend that any compute intensive appsl2 are re-compiled and don't use emulation. They also) don't publish any comparative benchmarks.u  1 The whole white paper is spoiled by the fact that . HP don't actually bother to mention what they 0 actually benchmarked what Itanium, what PA-RISC.   regardse Andrew Harrisona Enterprise IT Architect    ------------------------------  # Date: Fri, 24 Aug 2001 18:15:08 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)6 Subject: Re: IA-64 Emulation (was: Re: Nits in Slides)2 Message-ID: <MQwh7.752$bB1.32402@news.cpqcorp.net>  m In article <3rvh7.8901$sa.3907766@news1.rdc1.sfba.home.com>, "Duane Sand" <duane.sand@mindspring.com> writes:eF :The slow x86 emulation Andrew apparently refers to is the x86 decoder :on the initial Itanium chip.  f  G   So we're talking about the performance of the IA-64 hardware stuff?  yF   Sheesh.  That's quite a different approach than what I'm discussing    with VEST.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Sat, 25 Aug 2001 05:20:21 GMTt. From: "Duane Sand" <duane.sand@mindspring.com>6 Subject: Re: IA-64 Emulation (was: Re: Nits in Slides)= Message-ID: <pAGh7.10803$sa.5032126@news1.rdc1.sfba.home.com>o  5 hmm.  That HP white paper about Aries was vague aboutc performance of cpu-bound stuff.t Here's something more specific: -       http://www.theinquirer.net/21050101.htm = which was apparently said by HP at an Intels Developer Forum.y6 News article says "With compute bound applications, it) [binary PA-RISC code translated by Aries]a7 operates at 40-70 per cent native [recompiled for IA64] 
 performance."   > 40% would be about what I would expect.  70% would be amazing.  1 IBM Research and HP have both published papers on ; dynamic binary translators that can actually improve on they8 static optimizations of best-in-class compilers.  At run9 time, a smart system can spot patterns and overheads thatt5 aren't found by compilers even with profile feedback.s  ; And 40%-of-native speed (within the applications' own code)(A is certainly good enough for migration of typical commercial appslJ that do indeed spend most of their cycles in database native code and I/O.6 On Compaq NonStop (Tandem)  systems, most applications9 today are still running via binary translator rather thanm@ by native recompilation, 10 years after the migration onto Mips.8 Because the overall performance is good enough that way.     "andrew harrison wrote > Duane Sand wrote:eG > > http://www.hp.com/products1/itanium/infolibrary/whitepapers/dct.pdfhH > > for an initial HP report on Aries' performance.  It is working quite wellL > > enough to support HP's customer migration goals.  It doesn't have to runK > > fast enough to win benchmarketing wars. It's there to make whole-systemsI > > migrations practical while doing native recompiles of major apps at aV > > convenient pace. > < > Actually that isn't the conclusion you would draw from the > white paper refer to.q >i5 > The 4 benchmark results they refer to where Itaniumb2 > emulating PA-RISC is close to the performance of1 > PA-RISC native are all I/O intensive apps whicho/ > spend most of their time in the kernel. Sincei2 > the kernel is natively compiled for Itanium this1 > does not really help you determine what the hit  > is for emulated vs native. >t3 > HP then recommend that any compute intensive apps 4 > are re-compiled and don't use emulation. They also+ > don't publish any comparative benchmarks.  > 3 > The whole white paper is spoiled by the fact thatm/ > HP don't actually bother to mention what theyr2 > actually benchmarked what Itanium, what PA-RISC.   ------------------------------  # Date: Fri, 24 Aug 2001 20:16:48 GMTv2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)J Subject: Re: Incautious Privileged Users (was: Re: Queue/Entry management)2 Message-ID: <QCyh7.765$bB1.32662@news.cpqcorp.net>  _ In article <OFF456B08A.483CA20E-ON85256AB2.0060C38A@acml.com>, William_Bochnik@acml.com writes: 7 :Do you know a way to avoid deleting entries in a queuee0 :using a "way" to protect the entries from being# :deleted  by a priviliged account ?o :The problem is: :w0 :The development people have privilges to delete2 :entries and sometimes, a "sleepy" cobol developer* :deletes an important entry in the queues.  G   Um, no, you are wrong.  The problem here is the sleepy developer withdG   privileges.  The privilege and protection mechanisms are designed to  F   prevent exactly this situation from happening.  Sleepy or incautiousG   privileged users are extremely hazardous to correct system operation.   6 :We would like to create a way to protect entries from :being deleted, just this.  )   You will want to remove the privileges.t  G   If the privileges exist solely to permit access to the queues -- thiseD   is extremely unlikely -- you will want to use the protection masksH   and potentially associate access control lists (ACLs) with the queues.  G   Since you will undoubtedly be unable to remove the privileges (or youhH   would have done so before asking) you will want to enable auditing forG   use-of-privileges and such.  While a privileged user can disable the  E   audits, a truely sleepy privileged user will probably leave enough ,F   evidence around for you to find the (privileged) culprit.   You willE   also want to encourage the users to leave their privileges disabledyH   whenever possible, and you will want to provide alternative mechanismsE   and configurations and procedures that can avoid the need to assignr
   privileges.r     N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Fri, 24 Aug 2001 22:06:16 GMTi$ From: Scott Vieth <svieth@wi.rr.com># Subject: Re: Intersystems and Alphas) Message-ID: <3B86D0A0.EF73767E@wi.rr.com>   E Yeah?  What's your point?  I heard the same thing in person from someu Intersystems repsu5 at the IDX National Users Conference a few weeks ago.e  A Did you think that they *weren't* going to support a move to IPF?s   -Scott ????    Fabio Cardoso wrote:   > Clickg >k. > http://www.intersystems.com/cache/alpha.html >  > It is dated from Aug/8 >h	 > Regardsa >i
 > Fbio C. >i4 > __________________________________________________ > Do You Yahoo!?J > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/e   ------------------------------  % Date: Sat, 25 Aug 2001 20:51:07 -0400e! From: "Airnews" <Kuff@Tessco.Com>i. Subject: J2EE, RMI, Java Connectivity QuestionO Message-ID: <5DC43D73C2468850.1A3DADEF37796A25.96A81314382FB371@lp.airnews.net>t  E     We would like a remote java application to instantiate an OpenVMShG process and run an image passing up to 4096 bytes to the image ... thattH program will open some files and access a database, then send back up to
 4096 bytes...t  K     There's BEA, Attunity, Connx, something called Concerto from Xology....i> Anyone doing this with these tools or others in the field now?     ---Hal   ------------------------------  % Date: Fri, 24 Aug 2001 15:04:56 -0600r4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>1 Subject: Re: LPR from VMS 7.2-1 to Win2000 Servere2 Message-ID: <_jzh7.873$dJ6.240755@news.uswest.net>  I Thanks to all who replied.  I got it working.  The print jobs now go frommG the VMS system to a Windows 2000 Server and then to a Windows 98 laptopeG running a LPD deamon as well.  I couldn't go directly to the laptop fora? security reasons, thus the passthrough the Windows 2000 Server.g --
 Mike Ober.  6 "Jan-Erik Sderholm" <noone@home.com> wrote in message" news:3B85F24F.3193C062@home.com... > OK.q8 > Using the TELNET print symbiont is something completly# > different from using the LPR/LPD.u3 > You have first to descide what print protocoll ton6 > use, then set it up at both ends in the correct way.9 > Personlay, I'd prefer to use LPR/LPD instead of TELNET.  >o > Jan-Erik Sderholm.s >l > "Michael D. Ober" wrote: > >g > > Thanks,e > >aJ > > The ports aren't relevent, except that TELNETSYM requires port numbers to7 > > print to IP printers and I had never used LPRSETUP.b > > -- > > Mike Ober.   ------------------------------  # Date: Sat, 25 Aug 2001 02:26:22 GMTe- From: "Richard L. Dyson" <rickdyson@home.com>  Subject: Re: MLU and VMS 7.3( Message-ID: <3B870CCB.11E6F469@home.com>   Thomas Schildknecht wrote: > I > I was using the 'mlu' utility to select tapes from a TZ857 minilibrary.dG > This worked fine until I moved from VMS AXP V7.1 to VMS AXP V7.1! The, > problem is the following:  > G > The robotic device is accessed via a pseudo-device on SCSI sub-lun 1.i/ > The device is created (e.g. for MKA100) with:l > > >    mcr sysman io connect mka101 /noadapt/driver=sys$gkdriver > C > BUT: V7.3 does not anymore allow this because 'there is already a 3 > different driver defined for the device type MK'!P > I > Does anybody know a workaround? Any other utility to command the robot?   I 	As someone else pointed out, you should not be using the MK device name.cH It is definitely not new with v7.1.  It has been around fo ra long time!  H 	The convention that is used with library robots is to use the GK driver, (as you do) but call the device GK...  I.e.,  < mcr sysman io connect gka101 /driver=sys$gkdriver /noadapter  K and then the tape drive will probably be mka100.  (For a SCSI device on thes first ) SCSI controller with a unit number of 1).o   rick   ------------------------------  % Date: Fri, 24 Aug 2001 20:58:24 +0100s, From: "Mat Riain" <matei@no.spam.eircom.net>2 Subject: Modifying User Accounts - newbie question0 Message-ID: <Aoyh7.4407$s5.55519@news.indigo.ie>   Hello!  L Today I was trying to create a new user account and I forgot to specify someD of the user's information.  Can someone tell me how I can modify theI existing account?  I am fairly new to this, so excuse the newbie questionh please!(   Thanks!a   ------------------------------  % Date: Fri, 24 Aug 2001 22:29:30 +0200y, From: Didier Morandi <Didier.Morandi@gmx.ch>6 Subject: Re: Modifying User Accounts - newbie question& Message-ID: <3B86B92A.B1AE0134@gmx.ch>   Mat Riain wrote: >  > Hello! > N > Today I was trying to create a new user account and I forgot to specify someF > of the user's information.  Can someone tell me how I can modify theK > existing account?  I am fairly new to this, so excuse the newbie questiont	 > please!g > 	 > Thanks!.  M www.openvms.compaq.com:8000/73final/6017/6017pro_022.html#modify_user_account    D.   ------------------------------  % Date: Fri, 24 Aug 2001 18:03:09 -0400e' From: "Bill Todd" <billtodd@foo.mv.com>iT Subject: Re: Mount Points (was: Re: Wailing at Eunuchs (was: Wailing and Moaning...)( Message-ID: <9m6iu7$n3v$1@pyrite.mv.net>  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messagee, news:zvdh7.692$bB1.31613@news.cpqcorp.net...L > In article <9m3kbq$6r4$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:l >e@ > : long discussion of the benefits of mount points over volumes >rI >   We have added mount point support into OpenVMS as part of the DII COE H >   work, permitting at least some of the same benefits (and, of course,D >   the same problems) that are available with the UNIX environment.  J Good.  As I said, it took me quite a while to appreciate them, and in someJ ways I still feel they're a kludge.  But they've been an effective way forK over a decade to get around the limitations of most single-volume directory3H structures, and until we have file system virtualization at a level thatB even storage virtualization hasn't yet achieved they'll be useful.   - bill   >r( >  ---------------------------- #include' <rtfaq.h> ----------------------------- L >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com, >  --------------------------- pure personal# opinion --------------------------- 1 >    Hoff (Stephen) Hoffman   OpenVMS Engineeringg hoffman#xdelta.zko.dec.com >m   ------------------------------  % Date: Fri, 24 Aug 2001 21:14:44 -0500t1 From: "David J. Dachtera" <djesys.nospam@fsi.net>lY Subject: Re: Mount Points (was: Re: Wailing at Eunuchs (was: Wailing and Moaning...) Moan ' Message-ID: <3B870A14.F3F85295@fsi.net>r   Hoff Hoffman wrote:u > T > In article <9m3kbq$6r4$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > @ > : long discussion of the benefits of mount points over volumes > I >   We have added mount point support into OpenVMS as part of the DII COEUH >   work, permitting at least some of the same benefits (and, of course,D >   the same problems) that are available with the UNIX environment.  E I tried to concoct a bawdy come-back for that subject change, but wit 8 failed me. I'm sure that comes as no surprise to some...   -- s David J. Dachteran dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------  % Date: Fri, 24 Aug 2001 11:27:23 -0700 < From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com> Subject: Re: Nits in Slides-) Message-ID: <3B869C8B.6255BA7B@intel.com>:   Hoff Hoffman wrote:M  _ > In article <3B863910.DE584C1E@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:e3 > :But back to your point. Byte alligned access wasu0 > :added to Alpha after the first implimentation- > :because of performance issues when running>: > :VAX and other apps on Alpha. While this probably wasn't: > :added to specifically improve VESTED performance it was4 > :also added to improve the performance of FX!32 as: > :well as if my memory is correct Cobol and it would have' > :had an impact on VESTED performance.- >-E >   Most code out there that I am aware of does not use the byte-wordhM >   instructions.  OpenVMS, for instance, is built without byte-word enabled. G >   (The latest C compilers do use amask-protected sequences containingeG >   byte-word instructions within the tight loops, but you have to have ( >   rebuilt with very recent compilers.) >iI >   Folks that do have performance-critical code -- and particularly codenE >   with byte- or word-aligned data access -- are using the byte-wordeI >   instructions.  But I would be quite surprised to learn these are samel4 >   applications that are also using FX!32 nor VEST. >oG >   Byte-word is only available (in hardware) on EV56 and later.  As annF >   interestingly tangental discussion, the byte-word instructions are. >   emulated on earlier Alpha implementations. >iI >   Having just been looking at the VEST code for reasons other than thiseK >   discussion, it is sufficiently old that it has no clue of the existence < >   of the byte-word instructions in the Alpha Architecture.  E "Dang!  Those bloody FACTS keep getting in the way of my FUD!"  -A.H.        -Ken   ------------------------------  % Date: Fri, 24 Aug 2001 19:08:55 +0100y0 From: andrew harrison <andrew.nospam@uk.sun.com> Subject: Re: Nits in Slidesi* Message-ID: <3B869837.F2E6E436@uk.sun.com>   Fred Kleinsorge wrote: > D > andrew harrison wrote in message <3B863910.DE584C1E@uk.sun.com>... > >  > >.3 > >But back to your point. Byte alligned access wasa0 > >added to Alpha after the first implimentation- > >because of performance issues when runningl: > >VAX and other apps on Alpha. While this probably wasn't: > >added to specifically improve VESTED performance it was4 > >also added to improve the performance of FX!32 as: > >well as if my memory is correct Cobol and it would have' > >had an impact on VESTED performance.n > >a > ' > As my Uncle used to say, horse pucky.e > M > Partial word access was added explicitly because of NT, and the use of bytee* > access both to memory *and* to IO space.  - Since you forgot Cobol you rather ruined youru point. i  1 Or had you forgotten the Cobol performance issuese4 that were also helped by adding byte access. I guess1 memory isn't what it used to be, shame about the  
 name calling.l   Regards  Andrew Harrison  Enterprise IT Architecta   ------------------------------  % Date: Fri, 24 Aug 2001 16:42:50 -0400t* From: John Reagan <john.reagan@compaq.com> Subject: Re: Nits in Slides ) Message-ID: <3B86BC4A.4010207@compaq.com>H   andrew harrison wrote: > 3 > Or had you forgotten the Cobol performance issuesM6 > that were also helped by adding byte access. I guess3 > memory isn't what it used to be, shame about the a > name calling.i >   H Well, I'm just the Pascal compiler, but I talk to the COBOL folks alot. I   I don't remember COBOL performance being a reason for adding byte/word tB access.  I seem to remember it being added for NT and for Windows B programs that used lots of byte data and assumed byte granularity , (especially drivers writing into I/O space).  ? In the long run, I think the byte/word stuff helped out Pascal eI programmers more than COBOL programmers since the Pascal compiler on the -F VAX used byte for Boolean and enumerated datatypes (we now default to D longword on the Alpha but provide an /ENUMERATION_SIZE=BYTE for VAX E migration).  However, I can certainly promise that byte/word was not a0 added on behalf of any Pascal performance issue.   John Reagann Compaq Pascal Project Leader   ------------------------------  % Date: Fri, 24 Aug 2001 18:55:15 +0100H0 From: andrew harrison <andrew.nospam@uk.sun.com>B Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)* Message-ID: <3B869503.6556E3E4@uk.sun.com>   jlsue wrote: > D > Er, Bill, I didn't make that statement.  Something happened in the > cut-n-paste I think    Errn  C "The initial IA64 may be slower than EV7 on translated code, but itv won't stay that way forever."r  4 Was definitely posted by you, where you got it from # is anyones guess but you posted it.d   Regardst Andrew HarrisonsG > On Fri, 24 Aug 2001 04:12:17 -0400, "Bill Todd" <billtodd@foo.mv.com>c > wrote: >  > >e0 > >"jlsue" <jlsuexxxz@home.com> wrote in message5 > >news:h99bot8vcq0lv2godv2etr6qtmf1h55ocs@4ax.com...b > >p > >... > >tG > >> The initial IA64 may be slower than EV7 on translated code, but it ! > >> won't stay that way forever.h > >mN > >Er, the initial IA64 (Merced) is already out, and is slower than *EV6* whenK > >both are running *native* code (with the possible exception of unusuallypN > >regular floating-point-intensive code).  That Merced's successor (McKinley,M > >due in the EV7 time frame) will be similarly slower than EV7 when both areeO > >running native code seems likely (if only due to EV7's on-chip glue for botheM > >memory and SMP), so there's no chance in hell that McKinley will *emulate* K > >EV7 at anything like native speed.  And the same situation (or worse for J > >IA64, with the addition of SMT to the mix) would likely have applied in? > >EV8's era, had EV8 not been traded for a bag of magic beans.w > >sL > >In other words, Alpha's native performance would have remained noticeablyO > >superior to IA64's native performance for the foreseeable future, had CompaqaO > >chosen to continue developing Alpha.  And IA64 performance *emulating* Alpha O > >code likely won't catch up to EV7's until well after Compaq stops giving EV7i > >process upgrades. > >p	 > >- bill  > >  > >o   ------------------------------  % Date: Fri, 24 Aug 2001 19:21:16 +0100t0 From: andrew harrison <andrew.nospam@uk.sun.com>B Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)* Message-ID: <3B869B1C.D520C45C@uk.sun.com>   Fred Kleinsorge wrote: > - > andrew harrison pontificated like a baboon:e > >r* > >Are you sure you are an engineer ?????? > >h > N > Well I sure as heck am not a self-styled "Enterprise Architect".  I've still > to see *your* credentials.  1 Since you didn't even get the title right I guessu3 you are displaying more post the 25th inexactitude.s   Regardso Andrew HarrisonR Enterprise IT ArchitectU   ------------------------------  # Date: Fri, 24 Aug 2001 18:05:22 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)> Subject: Re: Nuts-n-bolts in News (was: Re: Nits in Slides...)2 Message-ID: <CHwh7.751$bB1.32396@news.cpqcorp.net>  ] In article <3B865D2A.8DD0CC65@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:T   :Hoff Hoffman wrote: :> :p9 :> :It is also not possible to draw parallels between thes7 :> :experience when moving from VAX to Alpha since care 6 :> :was taken in the Alpha architecture to allow this. :> i@ :>   Alpha was not particularly designed with emulation in mind. :> o :e@ :This is as you should know now incorrect, RC and RS were added B :to the architecture specifically to support VESTED applications.   F   Clearly we have differing opinions concerning the addition of these J   two instructions.   Personally, I think that the timing of the addition H   of these instructions -- comparatively late in the design process for '   the architecture -- bolsters my case.l  G   That said, I suspect we will have to agree to disagree.  Unlike you, iI   I do not believe that the Alpha architecture was particularly designed t<   with the run-time emulation of VAX code as a central goal.    < :Byte alligned access was added later to improve among other :things FX!32 performance.    A   Yes, the addition of byte-word instructions can certainly help v>   emulation.  I am not familiar with the innards of FX!32, but?   -- as stated before -- VEST was built before the availabilitye   of byte-word instructions.  A   Byte-word can also greatly help native code execution, and thisr   is the normal case.n    ; :As you should also know microprocessor designers are very  9 :carefull about adding instructions to an implimentation -< :so the decision to add this support was not something that  :would have been made lightly.  G   The ability to provide for current and future improvements in native eI   code performance are more common microprocessor design considerations. n  F   Why do I feel like I'm in a Monty Python skit?  (The Argument skit, (   for those unfamiliar with the series.)  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 24 Aug 2001 19:14:41 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com>> Subject: Re: Nuts-n-bolts in News (was: Re: Nits in Slides...)* Message-ID: <3B869991.108C0BC9@uk.sun.com>   Hoff Hoffman wrote:Y > _ > In article <3B865D2A.8DD0CC65@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:d >  > :Hoff Hoffman wrote: > :> > :-; > :> :It is also not possible to draw parallels between thee9 > :> :experience when moving from VAX to Alpha since caret8 > :> :was taken in the Alpha architecture to allow this. > :>B > :>   Alpha was not particularly designed with emulation in mind. > :> > :iA > :This is as you should know now incorrect, RC and RS were added C > :to the architecture specifically to support VESTED applications.  > G >   Clearly we have differing opinions concerning the addition of these,K >   two instructions.   Personally, I think that the timing of the additioneI >   of these instructions -- comparatively late in the design process for-) >   the architecture -- bolsters my case.0 >   A Why you stated that Alpha had no specific support for emulation, LC but your collegue stated that RC and RS were added specifically for56 VESTED apps and are not used by any Compaq compilers.   H >   That said, I suspect we will have to agree to disagree.  Unlike you,J >   I do not believe that the Alpha architecture was particularly designed> >   with the run-time emulation of VAX code as a central goal. > > > :Byte alligned access was added later to improve among other > :things FX!32 performance. > B >   Yes, the addition of byte-word instructions can certainly help@ >   emulation.  I am not familiar with the innards of FX!32, butA >   -- as stated before -- VEST was built before the availabilityt >   of byte-word instructions. > C >   Byte-word can also greatly help native code execution, and thisd >   is the normal case.r >   5 Like for example Cobol, better tell poor old Fred he n  is confused and needs your help.   Regardsc Andrew HarrisonM Enterprise IT Architecto   ------------------------------  % Date: Fri, 24 Aug 2001 14:59:45 -0400e' From: "Bill Todd" <billtodd@foo.mv.com> > Subject: Re: Nuts-n-bolts in News (was: Re: Nits in Slides...)( Message-ID: <9m686a$emk$1@pyrite.mv.net>  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messagel, news:CHwh7.751$bB1.32396@news.cpqcorp.net...   ...o  G >   Why do I feel like I'm in a Monty Python skit?  (The Argument skit,f* >   for those unfamiliar with the series.)   At least it's not Abuse.   - bill   ------------------------------  % Date: Fri, 24 Aug 2001 21:17:25 -0000i- From: wspencer@ap.nospam.org (Warren Spencer) > Subject: Re: Nuts-n-bolts in News (was: Re: Nits in Slides...)7 Message-ID: <9107A55D2warrenspencer1977@207.126.101.97>   F billtodd@foo.mv.com (Bill Todd) wrote in <9m686a$emk$1@pyrite.mv.net>:   >y@ >"Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message- >news:CHwh7.751$bB1.32396@news.cpqcorp.net...b >s >... >KH >>   Why do I feel like I'm in a Monty Python skit?  (The Argument skit,+ >>   for those unfamiliar with the series.)d >t >At least it's not Abuse.t >G >- bill   ) That might be a matter of perspective ;-)    ws   -- i   Warren Spencer  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------    Date: 24 Aug 2001 14:15:10 -0700* From: polato@igi.pd.cnr.it (Sandro Polato)+ Subject: Re: ODS-5 and parse_style question0= Message-ID: <2af2b3d8.0108241315.643b7eae@posting.google.com>f  H > Maybe I'm missing something but can't you just specify the filename inO > uppercase when you create it ? If the name is supplied to the running programg8 > by the user then you need to uppercase the user input. > M > So long as a lowercase/mixedcase version of the file does not already exists > then this should surely work.  > H > If a lowercase/mixedcase version already exists then this case will beP > preserved for all later versions. Hence you will need to get rid of such filesD > if you want to make sure it is created with an uppercase filename.K > (Note. In this context 'later versions' means versions created later not eM > necessarily with higher version numbers. If a mixed case filename exists asnP > version number 2 without a version 1 of the file existing. Then it's case willC > be used if you try to explicitly create a version 1 of the file.).    C I have to admit: the question was too general and seems a nonsense. C I try to explain better my problem . In my organization there are a0D lot of programmers (students and researchers) that use indifferentlyD lowercase and uppercase in the file name to create it. To read theirD output files they use some application (ghostview for examples) thatA can't show file names in lower or mix case and I would dislike tocE obligate the users to edit all their programs and change in uppercasel the file names. E But it seems there are not alternatives to uppercasing the file namesvC because we can't upgrade all that limited applications and the "SETt8 PROC/PARSE=TRADITIONAL" command works only at DCL level. Thanks anyway.  
 Sandro Polato  Consorzio RFX - Padova - Italy   ------------------------------  % Date: Fri, 24 Aug 2001 21:44:46 -0400a' From: Howard S Shubs <howard@shubs.net>a, Subject: Re: OT: TOPS-20 and TOPS-10 live on< Message-ID: <howard-64A1BD.21444624082001@enews.newsguy.com>  A In article <OF0207E2FE.C302BC2C-ON85256AB2.005CD546@cca-int.com>,h  Tym_Stegner@cca-int.com wrote:   E > Unfortunately, I can't tell you specifically who/where they are, asuF > somebody else handled that project...  I think there was one site in@ > Cambridge, MA/USA, and another is the Danish Railway system...  I I suspect that one is Teradyne, in Boston.  I know they were running one -M around 1995 when I interviewed there.  Had a system disk crash while we were a all standing around. -- o Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Fri, 24 Aug 2001 14:36:37 -0400j- From: JF Mezei <jfmezei.spamnot@videotron.ca>c# Subject: Re: Queue/Entry management , Message-ID: <3B869EAB.C23C1F91@videotron.ca>   Fabio Cardoso wrote:1 > The development people have privilges to deleteT3 > entries and sometimes, a "sleepy" cobol developeru+ > deletes an important entry in the queues.l  N Create a "test" queue whose protection allows the programmers to play with theM entries in that queue. You can have that queue be a generaic queue that flows I into a real execution queue to which the programmers don't have access toe (unless it is their own job).f  @ This way, you don't need to give the programmers any privileges.   ------------------------------  + Date: Fri, 24 Aug 2001 11:33:03 -0700 (PDT)d. From: Fabio Cardoso <fabiopenvms@yahoo.com.br># Subject: Re: Queue/Entry managemento@ Message-ID: <20010824183303.88511.qmail@web20210.mail.yahoo.com>   William   3 The queues they manage are the "production" queues.e  There is not a real "culture" of3 development/production servers here, so they submitf6 jobs for test in the production systems. And sometimes they delete the wrong jobs...w1 I cant put restricions in the queues because theyo* are responsible for the jobs running them.   Regards    FC=20       # --- William_Bochnik@acml.com wrote:s >=202 > read up on settin priv's on queues and only give > them priv's to% > delete jobs from their own queue's.S >=20 > help init/que/prot >=20  > give them each their own queue >=20 >=20 >=20 >=208 >                                                    =203 >                                               =20h8 >                     Fabio Cardoso                  =203 >                                               =20b7 >                     <fabiopenvms@yah              =20a4 > To:  Info-VAX@Mvb.Saic.Com                     =207 >                     oo.com.br>                    =20 4 > cc:                                            =206 >                                             Subject:3 >     Queue/Entry management                    =20-8 >                     08/24/2001 01:30               =203 >                                               =20l8 >                     PM                             =203 >                                               =20e8 >                                                    =203 >                                               =20h8 >                                                    =203 >                                               =20i >=20 >=20 >=20 > People >=20 >=202 > Do you know a way to avoid deleting entries in a > queuen1 > using a "way" to protect the entries from beingC$ > deleted  by a priviliged account ? > The problem is:n >=201 > The development people have privilges to delete03 > entries and sometimes, a "sleepy" cobol developerp+ > deletes an important entry in the queues.  >=202 > We would like to create a way to protect entries > from > being deleted, just this.t >=20	 > Regards6 >=20 >=20 >=20     =3D=3D=3D=3D=3D.L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D  F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazila fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Ds  2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/m   ------------------------------    Date: 24 Aug 2001 15:58:23 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)e# Subject: Re: Queue/Entry management 3 Message-ID: <OZVCuROhLycr@eisner.encompasserve.org>u  q In article <20010824183303.88511.qmail@web20210.mail.yahoo.com>, Fabio Cardoso <fabiopenvms@yahoo.com.br> writes:e	 > Williami > 5 > The queues they manage are the "production" queues. " > There is not a real "culture" of& > development/production servers here,  1 That is the root problem that needs to be solved.t   ------------------------------  % Date: Fri, 24 Aug 2001 21:48:48 -0400 ' From: Howard S Shubs <howard@shubs.net>H# Subject: Re: Queue/Entry managementh< Message-ID: <howard-DBE61B.21484824082001@enews.newsguy.com>  , In article <3B869EAB.C23C1F91@videotron.ca>,/  JF Mezei <jfmezei.spamnot@videotron.ca> wrote:   B > This way, you don't need to give the programmers any privileges.  H The fun part comes if the programmers have privs for other tasks, as is . usually the case, so you can't take them away.  I To fix that situation, I suspect that making it known publically why the  O important job disappeared would suffice.  Let management take care of the rest.  -- t Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Fri, 24 Aug 2001 21:36:51 -0500a1 From: "David J. Dachtera" <djesys.nospam@fsi.net>g# Subject: Re: Queue/Entry managementM' Message-ID: <3B870F43.C25B551B@fsi.net>H   Fabio Cardoso wrote: > 	 > Williamt > 5 > The queues they manage are the "production" queues. " > There is not a real "culture" of5 > development/production servers here, so they submita8 > jobs for test in the production systems. And sometimes > they delete the wrong jobs...j3 > I cant put restricions in the queues because they , > are responsible for the jobs running them.  G Sounds like the answer might be to put ACLs on the production queues att3 startup time (do queue ACLs survive across boots?).   F I think permitting ACLs on queue entries via a DEFAULT ACE, similar toG the way it is done for files in directories, would be very useful here,oF also. Then, you could lock down the production queues, but the hackersH could have free reign on anything that ACLs on the queues alone wouldn't cover.   Dunno...   --   David J. Dachterax dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/i   ------------------------------  % Date: Fri, 24 Aug 2001 18:34:07 +0100 4 From: John Laird <john@laird-towers.freeserve.co.uk>@ Subject: Re: RWMBX - What to do, What to do! Help me if you can.8 Message-ID: <tg3dotcmjshg868uo9lcprli7rj1303rif@4ax.com>  > On 24 Aug 2001 08:12:50 -0500, briggs@encompasserve.org wrote:  ] >In article <3B8545A8.B18F3009@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:eM >> If, however, the process hangs and stays in RWMBX forever, the trick is totM >> ANA/SYSTEM, SET PROCESS <name of process in RWMBX), show proc/CHANNELS ande. >> that will tell you the mailbox name/number. >> m7 >> Then, you can write a simple DCL procedure tsuch as:  >> o >> $OPEN/READ temp MBAxxx: >> $loop >> $READ/end=finish temp testn
 >> $goto loopa >> $finish:a >> $exit >  >Ort >  >$ COPY /LOG MBAxxx NL:f >aE >Saves you a dangling open file named "temp" that will screw you overm4 >the next time you try to use it for something else.  $ You forgot (after the COPY command): <Ctrl/C>  D else you get a dangling DCL session (unless the writing app cares to write an EOF).  G A rather more couth approach would be to take MBOX from the freeware CD-F or Hunter Goatley's site and modify it to (intake of breath here) bumpB up the mailbox byte quota.  (We've done this but never updated the available source).     	Johnl   ------------------------------  % Date: Fri, 24 Aug 2001 21:11:04 -0500g1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 5 Subject: Re: VMS high reliability needed by Air Force?' Message-ID: <3B870938.8716F324@fsi.net>t   Alan Greig wrote:p > F > On 24 Aug 2001 01:08:50 GMT, Joe Heimann <heimann@nog.ecs.umass.edu> > wrote: > 6 > >Michael D. Ober <mdo.@.wakeassoc.com.nospam> wrote:K > >> My favorite was when our Honeywell systems crashed, the first four hex 8 > >> characters in the crashdump were frequently "DEAD". > >> --  > >> Mike Ober.a > >lJ > >A department here used to have a Wang VS45 system that crashed during aH > >thunderstorm.  When it came back up, its LED status display also read > >a
 > >        DEA
 > >        ADn > C > I recall a VAX with an add in processor card running some libraryaF > software. The second processor/OS crashed with the error "Full power > to the shields Mr. Sulu"  > She canna' take much more o'this, Cap'n - she's goin' to BLOW!   -- r David J. Dachtera> dba DJE Systemss http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/c   ------------------------------  % Date: Fri, 24 Aug 2001 14:03:20 -0400E5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>s= Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...)n2 Message-ID: <hFwh7.750$bB1.32352@news.cpqcorp.net>  A Hamlyn Mootoo wrote in message <3B856D15.155D5F60@bigfoot.com>...   0 >> Remind me not to work on any of your systems.B >After I get done inheriting the crap that other people leave, theA >systems are secure.  But it's possible you've never been outsidenG >DEC/Compaq ( don't worry, a lot of ex DEC people have the same problemBD >when they get out into the real world).  In the real world, a large+ >percentage of systems run with huge holes.b >-    A While I have been at DEC/Compaq for 22 years now, I didn't go the K college-to-VMS-engineering route.  I worked as a IBM 360 operator, and as aeH programmer writing store-and-forward message switching for a specializedI custom OS.  The first 5 years or so of my career at DEC was as a SoftwareAC Specialist, working at customer sites doing PL90, remedial support, @ installation, etc.  Nor have I retired to a closet since joining engineering.  E Of course, the shops I worked with and for back in NY, generally wereb! insanely paranoid about security.t   >Except for the standaloneF >> systems that I self manage, I neither have privledges, or have them turnedL >> on if I do, unless I need them.  I would venture to say that outside of aJ >> development environment, most production VMS shops give the minimal set of? >> required privledges to users other than the system managers.s >>J >> Installing random images written by sloppy programmers sounds dangerous on
 >> any OS.E >I don't know what kind of coding you've done, but this is a standardnF >tactic to allow users to perform specific privilege tasks - maybe youF >should read your own manuals.  For instance let's say a user needs toH >only delte some lta ports.  A program written only to do this installed+ >with appropriate privs would do just fine.. >.    G Yes, but *you* implied that people blithely install "bad" software with,K privs, or worse - allow end users to have excessive privs because they needtL to use poorly written software that needs privs.   Why on earth would you do* that?  Are people to lazy or too ignorant?  J Is this just some admission that in the real world, bad practices are justJ too appealing?  And good ones just too hard?  It's not like we've made the  hoops that hard to jump through.   ------------------------------  % Date: Fri, 24 Aug 2001 14:36:32 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> = Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...)h( Message-ID: <9m66qp$dp0$1@pyrite.mv.net>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:hFwh7.750$bB1.32352@news.cpqcorp.net...   ...   L > Is this just some admission that in the real world, bad practices are justL > too appealing?  And good ones just too hard?  It's not like we've made the" > hoops that hard to jump through.  K I suspect you've hit on an unfortunate but common truth.  Unless you designlH software that can't be misused (and in consequence is often ridiculouslyB hard to use at all), the average person (even one in a position ofL responsibility) will be sloppy in using it.  VMS certainly strikes as good aG compromise in this area as anything else (and better than most), but ittB still happens a lot, especially when compounded with use by peopleJ accustomed to less fine-grained controls in other more common environments7 (who thus may overlook what VMS provides in this area).t  H In other words, it's not a feature problem, but a social problem - and aJ problem not just for VMS, nor even just for the industry, but for the U.S.J as a whole given that people in other countries are hungrier and thus moreK willing to expend the energy to act responsibly if doing so will get them a-G piece of prosperity.  Established U.S. corporations need to watch theiroK backs a hell of a lot better than they're doing now if we don't want to seeeI a great deal of our own prosperity gobbled up by others (and that doesn'toD just mean moving operations elsewhere:  the U.S. management will getD replaced too if it keeps screwing up):  start-ups do a decent job of1 competing, but they can't stem the drain forever.    - bill   ------------------------------    Date: 24 Aug 2001 14:51:40 -0400+ From: randall.burlew@srs.gov (Randy Burlew)i= Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...)N, Message-ID: <2001Aug24.145140.13102@srs.gov>   Hamlyn Mootoo says...2 >r >> >> >...And since mostM >> >> >programmers on VMS don't take the time to make sure their applications M >> >> >can be installed with privs so that non-priv'ed users can just do whatHN >> >> >they're supposed to, an incredibly LARGE percentage of user accounts onL >> >> >VMS systems are running around with near full privs, or at least onesH >> >> >that will allow their accounts to get the rest with minimal work. >> >> >t   <snip>  , > ...My point is that in both systems, abuseE >is possible.  I would even further argue here, that at least in UnixdC >systems, you know who has root (only one password) whereas in VMS,:G >regular users may be holding incredibly destructive privilges that youaD >might not catch because in some cases third party app installs will) >create accounts with elevated privilege.o >h >  >HMa  = I agree that abuse is possible in both systems. However, your ? experience, even if wide, is still a very small sampling of alle3 VMS installations. There is no basis for you to sayo  B "...an incredibly LARGE percentage of user accounts on VMS systems( are running around with near full privs"  A I would have no beef with "In my experiences, an incredibly LARGEl percentage..."    B You do not and cannot speak for the majority of VMS sites. We takeC great care in creating user accounts so that everyone has the privs B they require but no more than they require. I went round and roundD with a CA tech. support person because they wanted us to run our DBA8 accounts with BYPASS to get around a checkpoint problem.  D The vast majority of people I know who run VMS are also very carefulD about privs. Doesn't prove anything, but in my experience I find the above quote hard to believe.  C We also know exactly what our third party app installs do. It's not ( that hard to keep track of these things.   Randya   ------------------------------  % Date: Fri, 24 Aug 2001 15:39:09 -0400 ( From: Hamlyn Mootoo <univms@bigfoot.com>= Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...)w+ Message-ID: <3B86AD5D.81361889@bigfoot.com>d   Fred Kleinsorge wrote: > C > Hamlyn Mootoo wrote in message <3B856D15.155D5F60@bigfoot.com>...  > 2 > >> Remind me not to work on any of your systems.D > >After I get done inheriting the crap that other people leave, theC > >systems are secure.  But it's possible you've never been outsideeI > >DEC/Compaq ( don't worry, a lot of ex DEC people have the same problem-F > >when they get out into the real world).  In the real world, a large- > >percentage of systems run with huge holes.c > >: > C > While I have been at DEC/Compaq for 22 years now, I didn't go the0M > college-to-VMS-engineering route.  I worked as a IBM 360 operator, and as a-J > programmer writing store-and-forward message switching for a specializedK > custom OS.  The first 5 years or so of my career at DEC was as a SoftwareeE > Specialist, working at customer sites doing PL90, remedial support,iB > installation, etc.  Nor have I retired to a closet since joining > engineering. > G > Of course, the shops I worked with and for back in NY, generally were # > insanely paranoid about security.i >  > >Except for the standaloneH > >> systems that I self manage, I neither have privledges, or have them > turnedN > >> on if I do, unless I need them.  I would venture to say that outside of aL > >> development environment, most production VMS shops give the minimal set > ofA > >> required privledges to users other than the system managers.m > >>L > >> Installing random images written by sloppy programmers sounds dangerous > on > >> any OS.G > >I don't know what kind of coding you've done, but this is a standardnH > >tactic to allow users to perform specific privilege tasks - maybe youH > >should read your own manuals.  For instance let's say a user needs toJ > >only delte some lta ports.  A program written only to do this installed- > >with appropriate privs would do just fine.o > >e > I > Yes, but *you* implied that people blithely install "bad" software with1M > privs, or worse - allow end users to have excessive privs because they needR2 > to use poorly written software that needs privs.  ( I indicated the latter not the former.        Why on earth would you do, > that?  Are people to lazy or too ignorant? > H I believe it's a lack of education. It is understandable from people who? have recently moved or coded from other platforms.  Actually, a H programmer has to know a little bit about systems management in order toH avail himself (gender neutral himself here) of this method.  Quite a fewG system managers on the other hand, are not programmers.  In the "early"uG days, a lot of VMS system managers came "up through the ranks" and wereSH little more than glorified tape jockeys.  I still remember in some shopsF that their was this notrious "glass wall" behind which the programmersD could not go, even to get their printouts.  The operators and system> managers had full access, but generally didn't know much aboutH programming.  This created a bit of rivalry between the "systems" peopleE and the application programmers which didn't help the finger pointing=G when something didn't work.  I remember doing a VMS upgrade (circa 5.0) G after which an in-house application developer swore up and down that it C broke his code somehow.  Knowing that what I did had very little if G anything to do with what he was coding, I asked him to show me the code H ( it was COBOL, ugh).  After his initial confused look, he let me take aC look.  I compiled and linked it with Debug and nonchalantly stepped H through his code and in about 4 minutes pointed out the problem.  He hadH made his changes around the same time that the upgrade had been done, soG naturally he thought it was that.  I could tell though, that he was not @ familiar with the symbolic debugger so I gave him a few pointersA afterwards.  This went a long way in establishing and keeping the $ credibility of the operations staff.  L > Is this just some admission that in the real world, bad practices are justL > too appealing?  And good ones just too hard?  It's not like we've made the" > hoops that hard to jump through.   ------------------------------  % Date: Fri, 24 Aug 2001 16:38:28 -0400s( From: Hamlyn Mootoo <univms@bigfoot.com>= Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...)3+ Message-ID: <3B86BB44.6DD5295E@bigfoot.com>D   Randy Burlew wrote:  >  > Hamlyn Mootoo says...o > >p > >> >> >...And since mostO > >> >> >programmers on VMS don't take the time to make sure their applicationsDO > >> >> >can be installed with privs so that non-priv'ed users can just do what_P > >> >> >they're supposed to, an incredibly LARGE percentage of user accounts onN > >> >> >VMS systems are running around with near full privs, or at least onesJ > >> >> >that will allow their accounts to get the rest with minimal work.	 > >> >> >a >  > <snip> > . > > ...My point is that in both systems, abuseG > >is possible.  I would even further argue here, that at least in UnixlE > >systems, you know who has root (only one password) whereas in VMS,tI > >regular users may be holding incredibly destructive privilges that you F > >might not catch because in some cases third party app installs will+ > >create accounts with elevated privilege.o > >o > >t > >HM- > ? > I agree that abuse is possible in both systems. However, your A > experience, even if wide, is still a very small sampling of allm5 > VMS installations. There is no basis for you to sayn > D > "...an incredibly LARGE percentage of user accounts on VMS systems* > are running around with near full privs" > C > I would have no beef with "In my experiences, an incredibly LARGE  > percentage..." > D > You do not and cannot speak for the majority of VMS sites. We takeE > great care in creating user accounts so that everyone has the privsgD > they require but no more than they require. I went round and roundF > with a CA tech. support person because they wanted us to run our DBA: > accounts with BYPASS to get around a checkpoint problem.  F Thanks for adding for evidence supporting my point.  CA is not a smallF software company.  In fact, I believe at one time they were consideredF the largest on the planet.  If their tech support made that suggestion? with a "straight face" then guess how many people got that sameeG suggestion too?  And that suggestion belies their tendency toward usingmH that solution to fix a host of other tech support problem.  IncidentallyD I challenge you to show me your equations and data to represent whatE sample is statistically significant given an few hundred thousand VMSh8 installation worldwide (probably a lot less now though).   > F > The vast majority of people I know who run VMS are also very carefulF > about privs. Doesn't prove anything, but in my experience I find the > above quote hard to believe. > E > We also know exactly what our third party app installs do. It's not * > that hard to keep track of these things. >  > Randyo   ------------------------------  % Date: Fri, 24 Aug 2001 21:20:26 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net> = Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...)M' Message-ID: <3B870B6A.10F4700F@fsi.net>o   Nigel Arnot wrote: > [snip]C > As for the "do you really want to do this?" approach, it's almostoP > useless. You woudn't have typed INIT if you didn't want to. The disaster is ifJ > you enter the wrong device as target - but you think at that moment thatG > it's the right one, so almost certainly you answer "YES", even if yourJ > haven't habituated yourself into doing so mechanically without thinking.  C Dunno. The message displayed by some DCL commands using /CONFIRM atvD least reflects the identity of the object upon which you're about toF operate. Seeing that reflection has stopped me - more than once - from clobbering the wrong file.   -- e David J. Dachterad dba DJE Systems> http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  % Date: Fri, 24 Aug 2001 10:56:37 -0700n< From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?O) Message-ID: <3B869555.B0294A92@intel.com>n   Didier Morandi wrote:    > "Kenneth H. Fairfield" wrote:E	 > > ../..aJ > >     Does anyone have a suggestion of how to either (a) force BACKUP toF > > use the labels I want it to without pre-labeling the tapes, or (b)L > > provide a (robust, reliable?) method to determine how many tapes a givenN > > BACKUP job as used (without scanning the log file, which will be held open > > during this processing)? >e: > IMHO, as usual, the best answer may be the "normal" one.  D And which one is the "normal" one?  I'm afraid I don't follow you...    I >                                                           I'll leave tocI > the mathematicians the number of different tapes you can name with four = > digits containing letters A to Z and numbers 0 to 9 (that's,@ > 36*36*36*36?). Change the four first characters of your tapes.  G Doesn't solve my problem, namely, that (A) I need to know the labels onoJ all the tapes and _tell_ BACKUP what they are, otherwise BACKUP overwritesH the label, (B) it would take extra manual intervention to have the tapesH labeled by the coommand procedure since the stacker ejects the cartridgeI after the last tape is dismounted, and (C) it's not feasible to pre-labelpH all the tapes because there's no (reliable) way to coordinate the actualE tapes (and their labels) between the operator (person) and the backup  command procedure.  J Unfortunately, the TZ877 is strictly a _stacker_, not a library.  I cannotG mount tape from an arbitrary slot in the cartridge and neither does the0) stacker "know" what tape is in what slot.t       Thanks, Kenu --6 I don't speak for Intel, Intel doesn't speak for me...   ------------------------------  % Date: Fri, 24 Aug 2001 19:55:30 +0200   From: Paul Sture <paul@sture.ch>C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?t+ Message-ID: <VA.00000429.00326141@sture.ch>p  E In article <3B858933.FA4E23A8@intel.com>, Kenneth H. Fairfield wrote:eB > I've been studying BACKUP's /LABEL=(<label-list>), /EXACT_ORDER,F > and /IGNORE=(LABEL_PROCESSING) qualifiers (yes, there is some mutual> > exclusion present), in order to solve the following problem. > D >     We have a number of clusters, each with one or more TZ877 tapeG > loaders.  The operators load the 7-tape cartridges with enough tapes, G > typically 4 or 5, to do one clusters backups for the night, then loadzJ > the cartridge in the TZ877.  These tapes are mostly recycled, previously > D > labeled, but the labels are unknown (not tracked).  Therefore, the> > 4 or 5 tapes' labels are essentially arbitrary from BACKUP's > perspective. > F >     Our procedures INITIALIZE the first tape with the desired label,D > MOUNT it, then fire off a series of BACKUP commands, all /NOREWINDE > /IGNORE=(INTERLOCK,LABEL_PROCESSING).  For the first saveset on thedI > first tape, the journal file "knows" the label on the tape and displaysfB > it if you do a BACKUP/JOURNAL=journal-file/LIST.  For subsequent > savesets,fH > created by subsequent BACKUP commands (but writing to the same journal% > file), the volume label is unknown.o > B >     When BACKUP reaches the end of a given tape, mid-saveset, it > dismountsoH > the tape, issues various OPCOM messages, the TZ877 loads the next tape > inJ > the cartridge, BACKUP mounts the tape, doesn't like the label, dismounts > G > it and labels it with the first four characters of the _saveset_ nameo > withI > "02" appended, remounts the tape and forges ahead.  If the same saveset*C > causes BACKUP to reach the end of the 2nd tape, the 3rd tape gets,	 > labeled J > with "03" in place of "02".  When BACKUP has mounted and labeled a tape, > @ > the journal file reflects that label.  All this is documented. >pG You can use the /LABEL qualifier to disable the 2 byte sequence in the   continuation labels.   E.g.   $ label = "ABCDE"  ! 5 bytes
 $ BACKUP -   .?   .s   .l?         /LABEL=('label'1,'label'2,'label'3,'label'4,'label'5) --   .-   .-   .-  J >     The problem we encounter is that several of the "continuation" tapes > J > wind up with the same label.  For example "DPA202" is generated when the > F > saveset DPA234.SAV spans to another tape, but the same label is used > whenG > DPA256.SAV written to the same tape spans to 3rd tape.  This makes it  > hardJ > for the operators to _find_ the particular tape that has a given saveset > G > on it even when they use all the tools that BACKUP/JOURNAL/LIST giveso > them.hJ > BTW, a log file from SET HOST/LOG is produced when the operators run the > G > BACKUP procedure, but these don't stay around very long and searchingi	 > throughi? > them for this information is a bit tedious and trouble prone.p > G >     I've made an attempt to keep track of the tape sequence number ass > eachH > saveset is started using F$GETJPI("","VOLUMES").  However, I've had toD > kludge around the fact that if BACKUP (has to) label the tape, the > volumeC > count increases by two.  That happens most of the time, but if itw
 > doesn't,J > I probably make an error (i.e., if volume count increases by 1, I accept > J > that; if it increases by 2 or 4, I increment by 1 or 2, respectively; if > F > it increases by 3, I increment by 3 which is probably a mistake...). >oH Experience has taught me that you cannot always trust label information K returned by F$GETDVI for tapes mounted /FOREIGN - it's possible in certain .% circumstances for it to get confused.k  I >     The (semi-)obvious solution would be to tell BACKUP the tape labelsrE > to use via /LABEL=(list)/EXACT_ORDER.  That won't work in this case 	 > becauseoF > the tapes must be pre-labeled or BACKUP won't use them.  It would be  J Sorry, I've forgotten how /EXACT_ORDER works (and my VMS systems are down F at the moment). I know I don't currently use it, although did so in a K previous existence in conjunction with /LABEL=(n1,n2...) - I'm pretty sure l< that I didn't use LABEL_PROCESSING in the /IGNORE qualifier.   > easyB > enough to run a procedure to INITIALIZE all the tapes in a given > cartridge.J > once it was loaded, but once that's done, the operators would have to go > G > back to the TZ877 and reload the cartridge, something that would slowu > themJ > down and could easily be forgotten in the midst of other possibly urgent > G > things going on.  Thus we'd be at probably risk of frequently missings= > a nightly backup job.  Finally, one might "hope" that usingt > /LABEL=(list)nG > along with /IGNORE=(LABEL_PROCESSING) _might_ direct BACKUP to ignoreaG > the label on the tapes and relabel them from the given list.  DWIM, Ii > know,e > and wishful thinking...o >  >     So...  > H >     Does anyone have a suggestion of how to either (a) force BACKUP toD > use the labels I want it to without pre-labeling the tapes, or (b)	 > providelI > a (robust, reliable?) method to determine how many tapes a given BACKUPaE > job as used (without scanning the log file, which will be held openi > during > this processing)?i > K I use the ROBOT utility for labelling a set of tapes on HSJ controllers. I iA honestly don't know if this utility is still available/supported.r  J I recall some problem with BACKUP journal files (in the 7.1 or 7.2 era?), I but assuming that is fixed, they contain a record of the individual tape  K mounts. As long as you choose individual journal files per backup command, eG these will be closed when the current backup command completes. You'll tK need to do a listing of the journal file to get the volume information, as n+ it's a binary file, then SEARCH after that.a   ___o
 Paul Sture Switzerlandm   ------------------------------  % Date: Fri, 24 Aug 2001 11:04:19 -0700e< From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? ) Message-ID: <3B869723.8F0EC164@intel.com>r   John Santos wrote:  2 > On Thu, 23 Aug 2001, Kenneth H. Fairfield wrote: >2H > >     I've been studying BACKUP's /LABEL=(<label-list>), /EXACT_ORDER,H > > and /IGNORE=(LABEL_PROCESSING) qualifiers (yes, there is some mutual@ > > exclusion present), in order to solve the following problem. >n8 > [snip a lot of stuff I might regret snipping later...] > 
 > >     So...  > >tJ > >     Does anyone have a suggestion of how to either (a) force BACKUP toF > > use the labels I want it to without pre-labeling the tapes, or (b) > > provideeK > > a (robust, reliable?) method to determine how many tapes a given BACKUP G > > job as used (without scanning the log file, which will be held opena
 > > during > > this processing)?n > >  > >     Thanks, Ken  > 3 > A couple of things you might want to investigate.i >tG > 1) The MRU (Media Robot Utility, but Compaq may have changed the nameaG > recently) allows you direct control of the loader.  You could write afG > command procedure to load each tape in turn and label it (with INIT),EI > then unload it.  When done, reload the 1st tape and run backup with thee > label=() [*] and exact_order.   E I'd love to do that.  In fact the init/unload/repeat would be trivial E to do from the backup command procedure.  The problem is the TZ877 is C NOT a library, it is strictly a stacker.  MRU can't access it.  AndeC the operational problem is that the stacker ejects the whole 7-tape @ cartridge after the last tape is unloaded, which requires manualC intervention to reload the cartridge.  I can't ask the operators touA do that: it would burden them with _waiting_ for some message andsE responding to it, while they're busy getting a dozens of other backupmG procedures running on other clusters/systems.  They don't have the time.C stand around and wait for the 7 tapes to be initialized, and they'ddE likely miss one or more of these messages telling them to go back andy reload the cartridge.y    C > 2) TAPESYS (I think that's the name, the tape management & backupoF > product from Software Partners) may do all this.  If you have enoughE > systems and tapes, this may prove very worthwhile, just for keepingt > track of things.  D I'd love to try this out, or SLS, but I'd guess our current stackersD have insufficient functionality to support either product.  Although= they might do a better job of trcking the tapes themselves...        Thanks, Keno --6 I don't speak for Intel, Intel doesn't speak for me...   ------------------------------   Date: 24 AUG 2001 16:12:22 GMT4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? 6 Message-ID: <24AUG01.16122216@thuria.waisman.wisc.edu>  N In a previous article, "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>  wrote:  H -> ...Does anyone have a suggestion of how to either (a) force BACKUP toE -> use the labels I want it to without pre-labeling the tapes, or (b)lD -> provide a (robust, reliable?) method to determine how many tapes ; -> a given BACKUP has used (without scanning the log file, r3 -> which will be held open during this processing)?    Something I do here is:t  E 1. Preload the label list E.g. LABEL_LIST = "BFAA01,BFAA02,BFAA03..."   * 2. Mount the first pre-initialized volume.  = 3. Save the currently mounted volume name and issue a backup  2    command using /EXACT_ORDER/LABEL=('LABEL_LIST')  D 4. After each backup command, detect when a save set is continued on>    a second volume by comparing the current volume label (from<    F$GETDVI) with the label saved before the backup command.  ? 5. If the labels are different, delete the first label from theeA    label list E.g. LABEL_LIST = "BFAA02,BFAA03...". Go to step 3.g   ------------------------------    Date: 24 Aug 2001 14:02:07 -0500 From: briggs@encompasserve.orgC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? 3 Message-ID: <V0bn7Qn46Sei@eisner.encompasserve.org>h  h In article <3B869723.8F0EC164@intel.com>, "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com> writes: > John Santos wrote:D >> 2) TAPESYS (I think that's the name, the tape management & backupG >> product from Software Partners) may do all this.  If you have enoughtF >> systems and tapes, this may prove very worthwhile, just for keeping >> track of things.h > F > I'd love to try this out, or SLS, but I'd guess our current stackersF > have insufficient functionality to support either product.  Although? > they might do a better job of trcking the tapes themselves...D  @ We use TAPESYS with TZ877 stackers.  Works fine.  It isn't smart enough to get into trouble.   B The scheme that you use with TAPESYS is to prelabel all your tapes? with names or numbers or whatever.  We used a simple sequentialiA scheme.  And we stuck all the tapes in the racks according to the'A number.  We pre-initialized them before racking them.  You can do G without pre-initialization if you're willing to deal with the resulting C OPCOM nasty-grams and provide the requisite confirmation responses.n  A You then let TAPESYS allocate unused tapes (for a save) or locatebA the appropriate used tapes (for a restore) and prompt you to loadeB them.  By default, TAPESYS is not smart enough to know that you'reA dealing with a stacker and to prompt for the whole stack at once,dA but I wrote a command procedure to examine the allocated reel set + and let the operator know what is required.c  E You never modify the tape label.  No matter what saveset you write oneB the tape, the originally allocated volume label is left alone.  IfA you let TAPESYS generate your backup commands for you, that's nottJ a problem.  TAPESYS has hooks into the volume change process and currently@ uses callable BACKUP.  In much older versions, it used a patched! (and renamed) copy of BACKUP.EXE.   C If you roll your own backup commands, you've just got to be carefule> to always specify a label list and watch for volume changes in' multi-volume, multi-saveset operations.u   	John Briggs   ------------------------------  % Date: Fri, 24 Aug 2001 12:08:30 -0700 < From: "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?d) Message-ID: <3B86A62E.5C3C7541@intel.com>    Carl Karcher wrote:   O > In a previous article, "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com>y > wrote: >rJ > -> ...Does anyone have a suggestion of how to either (a) force BACKUP toG > -> use the labels I want it to without pre-labeling the tapes, or (b)iE > -> provide a (robust, reliable?) method to determine how many tapess< > -> a given BACKUP has used (without scanning the log file,5 > -> which will be held open during this processing)?a >  > Something I do here is:t >sG > 1. Preload the label list E.g. LABEL_LIST = "BFAA01,BFAA02,BFAA03..."d >e, > 2. Mount the first pre-initialized volume. >a> > 3. Save the currently mounted volume name and issue a backup4 >    command using /EXACT_ORDER/LABEL=('LABEL_LIST') >cF > 4. After each backup command, detect when a save set is continued on@ >    a second volume by comparing the current volume label (from> >    F$GETDVI) with the label saved before the backup command. >-A > 5. If the labels are different, delete the first label from theaC >    label list E.g. LABEL_LIST = "BFAA02,BFAA03...". Go to step 3.s  E Thanks, Carl, that's exactly what I'd thought to do.  The "gotcha" isiD that I can't make two passes through the tapes in a cartridge on theE TZ877 stacker.  After the first pass (to initialize/label the tapes),oD the cartridge gets ejected.  If the operators had nothing else to do) but stand around waiting for the eject...        Thanks, Kene --6 I don't speak for Intel, Intel doesn't speak for me...   ------------------------------   Date: 24 Aug 2001 15:18:25 CDT= From: wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell)NC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? . Message-ID: <uy9$+Z2W3M$5@tachxxsoftxxconsult>  h In article <3B869723.8F0EC164@intel.com>, "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com> writes: > John Santos wrote: >  > D >> 2) TAPESYS (I think that's the name, the tape management & backupG >> product from Software Partners) may do all this.  If you have enough0F >> systems and tapes, this may prove very worthwhile, just for keeping >> track of things.t > F > I'd love to try this out, or SLS, but I'd guess our current stackers> > have insufficient functionality to support either product.    M tapesys works fine with stackers.  All you have to do is turn off the AUTOSELrN (auto select) parameter in the backup parameter file.  In this case, it simplyK mounts whatever it finds (assuming the label is in the tapesys database andg flagged as available for use).  	 >Althoughg? > they might do a better job of trcking the tapes themselves...g      H And also the files on them.  The history database is one of the greatestL features of tapesys.   It can keep track of every file on every tape and youL can do a lookup in seconds.  If a user comes to you and says "I accidentallyH deleted my login com and I want it back", you don't have to wade throughG listings or anything else to determine what tape it is on.  You can do:   2 $ tape report/system laurel_disk2:[wayne]login.com  O Run date 24-AUG-2001 15:07:19.45                                         Page 1t3                                System Backup Reports5 Set LAUREL -- File *::LAUREL_DISK2:[WAYNE]LOGIN.COM;*n   P Filename-------------------------------------------------------------------OwnerP ----------Date_of_backup------Reel---------Saveset------------------------------  l  hP *::LAUREL_DISK2:[WAYNE]LOGIN.COM;2                                   [WAYNE_VAX]H           19-AUG-2001 22:41  DLT034       LAUREL_DISK2.IMG (pos 3, ODS2)H           12-AUG-2001 22:41  DLT022       LAUREL_DISK2.IMG (pos 3, ODS2)H            5-AUG-2001 22:42  DLT021       LAUREL_DISK2.IMG (pos 3, ODS2)H           29-JUL-2001 11:09  DLT016       LAUREL_DISK2.IMG (pos 3, ODS2)H           22-JUL-2001 08:33  DLT013       LAUREL_DISK2.IMG (pos 3, ODS2)H           16-JUL-2001 07:55  DLT047       LAUREL_DISK2.IMG (pos 3, ODS2)H            8-JUL-2001 22:51  DLT011       LAUREL_DISK2.IMG (pos 3, ODS2)H            3-JUL-2001 07:51  DLT020       LAUREL_DISK2.IMG (pos 3, ODS2)H           25-JUN-2001 07:33  DLT048       LAUREL_DISK2.IMG (pos 3, ODS2)H           17-JUN-2001 22:47  DLT018       LAUREL_DISK2.IMG (pos 3, ODS2)H           11-JUN-2001 07:25  DLT046       LAUREL_DISK2.IMG (pos 3, ODS2)          K In fact, if you use the "individual file restore" menu option, you can evenh2 have tapesys automatically do the restore as well.     -- tO ===============================================================================bM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxe: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)iO =============================================================================== H Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------    Date: 24 Aug 2001 16:03:04 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)aC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? 3 Message-ID: <YBBKTGNGOdO4@eisner.encompasserve.org>   n In article <uy9$+Z2W3M$5@tachxxsoftxxconsult>, wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell) writes:  J > And also the files on them.  The history database is one of the greatestN > features of tapesys.   It can keep track of every file on every tape and youN > can do a lookup in seconds.  If a user comes to you and says "I accidentallyJ > deleted my login com and I want it back", you don't have to wade through< > listings or anything else to determine what tape it is on.  H While that is a good feature, I don't understand why that implementation; is any better than the journal files made by Backup itself.t   But I am ready to be taught.   ------------------------------    Date: 24 Aug 2001 14:25:49 -0700) From: google@mccready.com (Gary McCready) C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?A= Message-ID: <6e64ea70.0108241325.6b43684a@posting.google.com>(  m "Kenneth H. Fairfield" <Kenneth.H.Fairfield@intel.com> wrote in message news:<3B858933.FA4E23A8@intel.com>...rB > I've been studying BACKUP's /LABEL=(<label-list>), /EXACT_ORDER,F > and /IGNORE=(LABEL_PROCESSING) qualifiers (yes, there is some mutual> > exclusion present), in order to solve the following problem. > D >     We have a number of clusters, each with one or more TZ877 tapeG > loaders.  The operators load the 7-tape cartridges with enough tapes,tG > typically 4 or 5, to do one clusters backups for the night, then loadiJ > the cartridge in the TZ877.  These tapes are mostly recycled, previously > D > labeled, but the labels are unknown (not tracked).  Therefore, the> > 4 or 5 tapes' labels are essentially arbitrary from BACKUP's > perspective.   <snip..............>   >     So...n > H >     Does anyone have a suggestion of how to either (a) force BACKUP toD > use the labels I want it to without pre-labeling the tapes, or (b)	 > provideaI > a (robust, reliable?) method to determine how many tapes a given BACKUP E > job as used (without scanning the log file, which will be held openb > during > this processing)?l >  >     Thanks, Ken1    B Well, what I would recommend (keep in mind, you'll probably eitherD have to get more software, and/or force the operators to do a little bit more work):k  6 1) label the exterior of each tape with a unique labelF 2) input into a command procedure (I'd suggest editing it) the labels,> and have the command procedure init the tapes and then, eitherF manually or with the MRU (ROBOT) software, re-load the tape in slot 0,E and then submit the backup procedure with the same list of labels. AskC an alternative , you may simply wish to mount and read the label on D each tape and then re-init the tape with that label; however, if theB interior label does not match the one on the exterior, then you of course, will have problems.i@ 3) Have the backup command procedure reference the labels in the /label qualifier;eD 4) if you use /journal, and are in a version of vms that has the bugE with /journal, you might have to dismount, and remount the tape priornE to each disk backup to correctly reflect the tape label used for thatrE disk in the journal file. If the tape label mounted changed, and doesoC not match the first label in the list, I "subtract" the first labelnE from my list of labels, also for an accurate backup journal (seems to' be needed).bC 5) to show what labels are in use, in-between disk backups, you may @ take the current list of labels (after subtracting as above) and* define that as a system wide logical name.F 6) additional concise logs can be kept by intelligently searching yourB log file for things like "backup/","2001", "mount-i-mounted", etc.E Listing files will also indicate the correct tape to find the saveset % on if the subtraction method is used.u  A Don't want to do all *that* - then I'd suggest buying some backup 5 management software and live within its requirements.o  ? There are lots of ways to do the above - feel free to reply for  additional input.o   --Gary McCreadys2 ---My opinions have nothing to do with my employer   ------------------------------  % Date: Sat, 25 Aug 2001 07:18:23 +0200e, From: Didier Morandi <Didier.Morandi@gmx.ch>C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?x& Message-ID: <3B87351F.60BEAC3A@gmx.ch>   Larry Kilgallen wrote: > J > While that is a good feature, I don't understand why that implementation= > is any better than the journal files made by Backup itself.t  N Maybe because all the history is in only one file instead of thousand of .LOG?   D.  P ================================================================================F "I should have listened what my mother used to told me so often when I	 was young"  What did she tell you?e   I do not know, I didn't listen"  : (Douglas Adams in "The Hitch Hiker's Guide to the Galaxy")   ------------------------------   End of INFO-VAX 2001.471 ************************