1 INFO-VAX	Tue, 08 Jul 2003	Volume 2003 : Issue 374       Contents: Any news on Exabyte? Re: Any news on Exabyte? Re: Any news on Exabyte? Re: APC UPS control for VMS  Re: APC UPS control for VMS  Re: Basics of attaching a PC Re: Basics of attaching a PC Re: Basics of attaching a PC Re: Cannot see disk drives* Converting VMS Formats to IEEE equivalents. Re: Converting VMS Formats to IEEE equivalents. RE: Converting VMS Formats to IEEE equivalents Re: DHCP startup problems  Re: DHCP startup problems  EMC buys Legato  Re: Good code profilers on VMS?  Re: Good code profilers on VMS? + Re: HP World: Why Alpha's Omega Makes Sense  Re: KVM switches Re: KVM switches Re: KVM switches Re: KVM switches Re: KVM switches Re: KVM switches$ Re: LTO-2 Ultrium tape drive and VMS$ Re: LTO-2 Ultrium tape drive and VMS$ RE: LTO-2 Ultrium tape drive and VMS$ Re: LTO-2 Ultrium tape drive and VMS$ RE: LTO-2 Ultrium tape drive and VMS" Re: OpenVMS 7.3.1 Install problem." Re: OpenVMS 7.3.1 Install problem. OpenVMS I64, a proposal  Re: OpenVMS I64, a proposal   Re: Porting VAX Object Libraries Re: RDB V7.  Re: RDB V7.  Re: RDB V7.  Re: RDB V7.  Re: RDB V7.  Re: RDB V7. * Re: Recursive copy between nodes using LAT* Re: Recursive copy between nodes using LAT Re: Rethinking  V.M.S  Re: Rethinking  V.M.S  Re: Running VMS off CD Re: Running VMS off CD Re: Running VMS off CD( swapping system disks (was: RE: RDB V7.), Re: swapping system disks (was: RE: RDB V7.)0 Re: Sybase Migrations External Website available+ Re: SYS$SPECIFIC and SYS$COMMON not enough? + Re: SYS$SPECIFIC and SYS$COMMON not enough? + Re: SYS$SPECIFIC and SYS$COMMON not enough? + Re: SYS$SPECIFIC and SYS$COMMON not enough? 8 Re: VAX Vup Listing not available on HP - where is it ??8 Re: VAX Vup Listing not available on HP - where is it ??5 Re: vms security model - does it still exist on IA64? 5 Re: vms security model - does it still exist on IA64? 5 Re: vms security model - does it still exist on IA64? 5 Re: vms security model - does it still exist on IA64? 5 Re: vms security model - does it still exist on IA64? 5 Re: vms security model - does it still exist on IA64? 5 Re: vms security model - does it still exist on IA64? 5 Re: vms security model - does it still exist on IA64? & [Mozilla 1.4] bug in pref-advanced.xul* Re: [Mozilla 1.4] bug in pref-advanced.xul* Re: [Mozilla 1.4] bug in pref-advanced.xul  F ----------------------------------------------------------------------  % Date: Tue, 08 Jul 2003 08:20:40 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com>  Subject: Any news on Exabyte? ' Message-ID: <3F0AE148.2050109@MMaz.com>   L Exabyte's web site has been off-line prior to the 4th, did the company tank?   Barry    --    @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------  % Date: Tue, 08 Jul 2003 08:56:08 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com> ! Subject: Re: Any news on Exabyte? ' Message-ID: <3F0AE998.4090904@MMaz.com>   $ Webb, William W - Raleigh, NC wrote:  D >Probably a disk crash and they've been unable to restore from tape. >    > H Now that is a funny!  Never the less, it doesn't explain why their main  800 number has been busy...    Barry    --    @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------  % Date: Tue, 08 Jul 2003 12:34:50 -0400 8 From: Jim Agnew - VCU/MCV Neurosurgery <jpagnew@vcu.edu>! Subject: Re: Any news on Exabyte? ' Message-ID: <3F0AF2AA.F12C8CE3@vcu.edu>   G There was something about a hacker todo or something that was to happen  on the 7th..  did they get hit?    "Barry Treahy, Jr." wrote: > & > Webb, William W - Raleigh, NC wrote: > F > >Probably a disk crash and they've been unable to restore from tape. > >  > > I > Now that is a funny!  Never the less, it doesn't explain why their main  > 800 number has been busy...  >  > Barry  >  > -- > A > Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO  > C > E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    --  F "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"  F "I try not to be right any more than necessary". -- Larry Wall, author of the Perl Language   ------------------------------  # Date: Tue, 08 Jul 2003 13:17:42 GMT " From:   VAXman-  @SendSpamHere.ORG$ Subject: Re: APC UPS control for VMS0 Message-ID: <00A228BA.429A118F@SendSpamHere.ORG>  ] In article <3f09ccaa$1@news.wineasy.se>, "Lars Holmstrm" <lars.holmstrom@flysta.net> writes: - >We use the Powercute for VMS. Works perfect. / >Can you describe your problem more in detail ?  >/Lars  H What's so "cute" about it?  Last time that I *explored* this product, itI only handled simple signalling from the UPS.  For US$400.00, I could very I easily implement my own single $QIO call to monitor the status of the pin - that the UPS toggles when it goes on battery.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  # Date: Tue, 08 Jul 2003 13:19:42 GMT " From:   VAXman-  @SendSpamHere.ORG$ Subject: Re: APC UPS control for VMS0 Message-ID: <00A228BA.8A2973DA@SendSpamHere.ORG>  ] In article <UF2dnT6fFN-os5eiXTWc-g@speakeasy.net>, Rich Jordan <duodec@speakeasy.net> writes:  >http://www.tmesis.com/upshot  > J >This is Brian's product for SmartUPS systems and OpenVMS.  We have it in G >use at one customer site; its a lot more versatile than the APC code,  G >which I believe only uses the 'dumb' relay mode, not the smart serial  I >mode.  UPShot also provides a web interface that you can use to monitor  : >and partly manage the UPS remotely (with authentication). > G >I had planned on getting it for home, but I just couldn't justify the  I >cost of a SmartUPS in the range I needed when Sams Club put BackUPS Pro   >1100s on sale recently....  > F >Good product, and Brian worked with us to get it going under TCPware E >(which at that time, ~2 years ago, he hadn't been able to test with  # >much) so the support is there too.   F Did I need to change any code?  IIRC, it was merely a matter of having% no version of TCPware to test UPShot.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Tue, 08 Jul 2003 13:52:35 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> % Subject: Re: Basics of attaching a PC ' Message-ID: <3F0AB083.A80CE1AB@aaa.com>    They will work pretty well. ; Those things that are in V6, will be more or less the same. A Those things that was new in V7.x, well you'll just not find them  in your system.   H And details about any command/feature are always in the on-line $HELP...  	 Jan-Erik.    Rodney Carter wrote: >  > Am I wasting time reading 7.3  > manuals for a 6.2 OS?    ------------------------------   Date: 8 Jul 2003 07:59:21 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: Re: Basics of attaching a PC 3 Message-ID: <MrDMybAbdae6@eisner.encompasserve.org>   W In article <3F0A01F4.A11A0CAF@yahoo.com>, Rodney Carter <rtcarter401@yahoo.com> writes: [ > Thank you for pointing me to the web for docs. I found them and will be reading all nite. Z > Now, the ones I found at the DEC/HP site are for version 7.2/7.3. In my Microsoft world,[ > exact identical functions are given different names as they change versions each year--it [ > is crazy because you have to learn the same thing 5 different ways. Is this going to be a V > consideration in that I am using open VMS version 6.2? Am I wasting time reading 7.3 > manuals for a 6.2 OS?   A    No, you are not wasting time.  You can peruse the new features F    manuals to figure out what the new OS version does that the old oneD    won't, but it's quite rare in VMS for the way something's done to    have changed.   ------------------------------  % Date: Tue, 08 Jul 2003 12:29:30 -0400 8 From: Jim Agnew - VCU/MCV Neurosurgery <jpagnew@vcu.edu>% Subject: Re: Basics of attaching a PC ' Message-ID: <3F0AF16A.8BF9C663@vcu.edu>   D Your system should be no problem.  7.3 docco's still help out people running 5.5-2 systems...  F Your best friend is the HELP command.  It's thinking is different fromE the Unix man command, the man docs are uh, er, ok, they are reference G manuals, meant to be read and reread..  That why you have to dig at 'em 	 a little.   E the VMS Help commmand is oriented more towards user manuals, that is, E they answer the questions of "how do I code this command to get it to % work more or less the way I want it."   F and then, the docs on html  or bookreader are the "man pages" that youF read to understand what you just did to your system disk!!!!  (chuckle meant here.)   to quote a person somewhere,    H "to enter a command as root(SYSTEM), should be a zen moment, a pause for! reflection before hitting return"    Jim    Rodney Carter wrote: > [ > Thank you for pointing me to the web for docs. I found them and will be reading all nite. Z > Now, the ones I found at the DEC/HP site are for version 7.2/7.3. In my Microsoft world,[ > exact identical functions are given different names as they change versions each year--it [ > is crazy because you have to learn the same thing 5 different ways. Is this going to be a V > consideration in that I am using open VMS version 6.2? Am I wasting time reading 7.3 > manuals for a 6.2 OS?  > Y > Sorry about the RTFM remark but I had seen several answers to questions in a forum with ] > knowledgeable people being arrogant I'm tired and stressed and just don't need that type of X > response. I need  help (from gracious people such as I have found here) and not people] > pointing out the fact that I don't know what I'm doing. If I can find the answers myself, I , > will but if I ask a question, I need help. >  > Hoff Hoffman wrote:  > [ > > In article <3F09A059.F83B6750@yahoo.com>, Rodney Carter <rtcarter401@yahoo.com> writes: J > > :I am a lowly Microsoft/Novell admin who has been thrown into the deepK > > :end. I don't mind doing my homework but I need some basic help. Please : > > :don't say RTFM because I can find no FM in this shop. > > F > >   Um, RTFM?  :-)  Seriously.  :-)  You do have access to a websiteD > >   with HTML-format manuals for OpenVMS and DECwindows.  You haveC > >   access to most of (all of?) the Fine Manuals, in other words.  > > F > >   You will want to acquire at least CD copies of the manuals, too.J > >   It's difficult to run most any non-trivial software platform withoutG > >   having local copies of the relevent documentation and/or manuals.  > >   And you waste more time. > > 6 > > :..The openVMS version is 6.2 and the transport isH > > :TCP/IP and use Humingbird Exceed.... We have bought upgrade PCs andG > > :I have tried to mirror the setups of the old systems. There are no J > > :new user accounts--just the old ones. Logging on with an old account, > > :I get the following error:  > > : 0 > > :%DECW-E-CANT_OPEN_DISPL, Can't open display3 > > :INTERnet ACP AUXS failure Status=%DECW-E-NOMSG  > > B > >   SHOW DISPLAY will display the target display for DECwindows.> > >   This should be the X Windows Server; the Exceed IP host. > > I > > :I can telnet to the server and login OK with an existing account but D > > :when the application tries to access a drawing I get the error: > > : - > > :Error while initializing graphics device  > > G > >   Use ICO (RUN DECW$EXAMPLES:ICO.EXE) for troubleshooting X Windows F > >   displays, as ICO provides some fairly reasonable X Windows error > >   messages.  > > H > > :From my research, I understand that I need to define the new PCs in7 > > :Security. But I haven't figured out just how, yet.  > > E > >   The setting is usually one in the X Windows server (Exceed), as E > >   the security is set up in the X Windows server.  Look around in E > >   the session manager menus, or whatever Exceed calls this stuff.  > > K > > :Can someone layout the basic steps I need to take to install a PC node P > > :into the VAX system? Just general--I'll work hard at finding the specifics. > > :Something like:* > > :1. Define the PC in the VMS security. > > : > >   Nope.  Configure at the X Windows server; in Exceed. > > ) > > :2. Define the VMS servers in Exceed.  > > F > >   Nope.  Usually SET DISPLAY on OpenVMS, either directly or in theG > >   LOGIN.COM or SYLOGIN.COM command procedure, or in a site-specific 0 > >   or application-specific command procedure. > > F > >   X Windows applications are clients of the server, and the serverF > >   (usually) runs on the appliance or host controlling and local to# > >   the X Windows display itself.  > > & > > :3. Assign new PC to user account. > > J > >   Eh?  Usually, the reverse is what you need and want -- the X WindowsJ > >   Server (Exceed) needs to map to the remote hosts and username(s) andG > >   transport(s) that will be establishing incoming X Windows display  > >   sessions.  > > H > >   Sometimes the most difficult part of this can be matching the caseF > >   or username syntax, and the X Windows server log files can be anD > >   invaluable resource for troubleshooting failed connections andG > >   security errors.  And again, these are in the Exceed environment.  > > * > > :4. Whatever the next step would be... > > J > >   The DECwindows manuals are on the documentation website.  Start withI > >   the OpenVMS FAQ (qv: sig) and the documentation -- particularly the I > >   DECwindows documentation, and then the system management and user's J > >   guides within the OpenVMS manual set -- at the OpenVMS documentation > >   website. > > J > > :I want to learn and I want this project so I've got to get some solidM > > :steps to show my boss progress. Can anyone help me or am I really out of  > > :my league with this?  > > R > >  ---------------------------- #include <rtfaq.h> -----------------------------O > >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq R > >  --------------------------- pure personal opinion ---------------------------I > >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    --  F "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"  F "I try not to be right any more than necessary". -- Larry Wall, author of the Perl Language   ------------------------------  % Date: Tue, 08 Jul 2003 11:31:41 -0400 - From: Jonathan Boswell <jsb@ost.cdrh.fda.gov> # Subject: Re: Cannot see disk drives 0 Message-ID: <3F0AE3DD.10D24E5C@ost.cdrh.fda.gov>   Alan Boyles wrote:; >The BA35X-MG is the single bus shelf, and right now I have < >the cable going to the left 50 ping connector and the right: >connector is empty.  Do you need termination on the right >connector?   K It is supposed to auto-terminate in this configuration. (My cable is in the / UPPER connector, since my shelf is horizontal.)    ------------------------------  " Date: Tue, 8 Jul 2003 13:27:17 GMT6 From: "Dale Pennington" <Dale.K.Pennington@boeing.com>3 Subject: Converting VMS Formats to IEEE equivalents ( Message-ID: <HHpK1H.4E6@news.boeing.com>   Folks,  K I am working a project on an IBM AIX system that is getting data from a VMS L system. The VMS system is providing the data in the F & G Float formats, andD expects info back in the same format. We have no say in this matter.  I What we need are conversions from the F & G Float formats to IEEE formats I and vice-versa. We have been hunting around for them with little success.   J So does anyone know where I could find code for such a conversion library, preferably open source ?   Thanks for your time   Dale Pennington    ------------------------------   Date: 8 Jul 2003 10:00:52 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) 7 Subject: Re: Converting VMS Formats to IEEE equivalents 3 Message-ID: <R5h7wjuAEbXF@eisner.encompasserve.org>   a In article <HHpK1H.4E6@news.boeing.com>, "Dale Pennington" <Dale.K.Pennington@boeing.com> writes:   M > I am working a project on an IBM AIX system that is getting data from a VMS N > system. The VMS system is providing the data in the F & G Float formats, andF > expects info back in the same format. We have no say in this matter. > K > What we need are conversions from the F & G Float formats to IEEE formats K > and vice-versa. We have been hunting around for them with little success.  > L > So does anyone know where I could find code for such a conversion library, > preferably open source ?  E You don't say whether that is a VAX or Alpha VMS system, but on Alpha - there are system calls to do that conversion.   ? If it is a VAX system, you could run the data through an Alpha.    ------------------------------  $ Date: Tue, 8 Jul 2003 08:30:17 -0700# From: "Tom Linden" <tom@kednos.com> 7 Subject: RE: Converting VMS Formats to IEEE equivalents 9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEMPHIAA.tom@kednos.com>   H You will take more time looking than it takes to write the program.  YouK will also need to covert little=>big=>little endian.  Probably best done on < VMS.  You need 4 small procedures, F->S, S->F, G->T and T->G  5 F2S: proc(in) returns(bit(32));  /* PL/I procedure */  	dcl (in,out) bit(32);5 	substr(out,32,1) = substr(in,1,1);			/* move sign */ I 	substr(out,31,8) = reverse(substr(in,2,8));	/* move and swap exponent */ K 	substr(out,23,23) = reverse(substr(in,9,23));	/* move and swap mantissa */ 
 	return(out); 	 	end F2S;   L The other three should be trivial modifications of the above.  However, when	 doing the L double precision you should add an ON-CONDITION to recover from overflows on both the exponent and mantissa.  / If you need the other three, just send check:-)    >-----Original Message----- H >From: Boeing NNTP News Access [mailto:nntp@news.boeing.com]On Behalf Of >Dale Pennington% >Sent: Tuesday, July 08, 2003 6:27 AM  >To: Info-VAX@Mvb.Saic.Com4 >Subject: Converting VMS Formats to IEEE equivalents >  >  >Folks,  > L >I am working a project on an IBM AIX system that is getting data from a VMS@ >system. The VMS system is providing the data in the F & G Float
 >formats, and E >expects info back in the same format. We have no say in this matter.  > J >What we need are conversions from the F & G Float formats to IEEE formatsJ >and vice-versa. We have been hunting around for them with little success. > K >So does anyone know where I could find code for such a conversion library,  >preferably open source ?  >  >Thanks for your time  >  >Dale Pennington >  >  >  >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). @ >Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003 >  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003    ------------------------------  + Date: Tue, 08 Jul 2003 12:03:32 +0200 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> " Subject: Re: DHCP startup problems; Message-ID: <01KY0KBU0BSIAPKEWT@sysdev.deutsche-boerse.com>   D > I "solved" it, by starting TCPIP in SYSMAN (CONFIG phase) _before_F > DECnet gets started. I have so far no explaination why you can get a/ > lease at your 2nd try. It never worked here.    / Doesn't DECnet have to be started before TCPIP?    ------------------------------  % Date: Tue, 08 Jul 2003 08:19:30 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com> " Subject: Re: DHCP startup problems' Message-ID: <3F0AE102.7090205@MMaz.com>    Phillip Helbig wrote:   D >>I "solved" it, by starting TCPIP in SYSMAN (CONFIG phase) _before_F >>DECnet gets started. I have so far no explaination why you can get a/ >>lease at your 2nd try. It never worked here.   >>     >> > 0 >Doesn't DECnet have to be started before TCPIP? >    > I Unless something has changed, yes because DECnet alters the MAC based on  F the configured area and node which, if TCPIP is started first, should  create a problem...    Barry    --    @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------   Date: 8 Jul 2003 07:41:54 -0500 + From: young_r@encompasserve.org (Rob Young)  Subject: EMC buys Legato3 Message-ID: <7hH0WSUmCjl+@eisner.encompasserve.org>   5 http://biz.yahoo.com/rb/030708/tech_legato_emc_3.html    Reuters " EMC to Buy Legato for $1.3 Billion Tuesday July 8, 8:27 am ET   By Kenneth Li     L NEW YORK (Reuters) - EMC Corp. (NYSE:EMC - News), which makes computers thatM store data, said on Tuesday it would buy Legato Systems Inc. (NasdaqNM:LGTO - H News) for $1.3 billion in stock in a deal that EMC said would expand its portfolio of storage software.   N EMC dominated sales of data storage machines during the 1990s technology boom,K but has since been hurt by overcapacity and falling hardware prices. It has I said it was in the market for software companies to diversity its revenue  sources.  M "The deal allows them to widen their software platform, which has been a goal N for EMC," said Friedman Billings Ramsey analyst Nitsan Hargil. "Unfortunately,H they are buying software which is not considered to be industry leading.8 Veritas Software (NasdaqNM:VRTS - News) has that title."  O Hargil said he expects EMC will have to invest substantial amounts of money and < time to make Legato products into industry-leading software.  L EMC rivals IBM, Hewlett-Packard and others in the market for large corporateM computer servers. Legato makes software used to manage those computer systems  and keep them up and running.   M The stock exchange deal values Legato at about $10.57 a share, based on EMC's M closing share price on Monday. The price represents a 16 percent premium over 5 Legato's closing price of $9.10 on Monday on Nasdaq..   M In pre-market trading on Instinet, Legato shares rose 12.6 percent to $10.25. N EMC shares fell 4.5 percent to $11.20 from Monday's close at $11.74 on the New& York Stock Exchange (News - Websites).  I Under the offer, Legato shareholders would receive 0.9 EMC share for each  Legato share held.  I Hopkinton, Massachusetts-based EMC said it will take a charge for some of M Legato's costs when the deal closes, but expected the transaction to slightly - boost its diluted earnings per share in 2004.   D EMC also said its second-quarter earnings will meet or beat targets.  M It expects earnings of 3 cents to 4 cents per share for the quarter. Analysts M polled by Thomson First Call (News - Websites) expected, on average, that EMC J would earn 3 cents per share. It reported a break-even second quarter last year.   O EMC said it sees consolidated revenue for the second quarter in at the high end H of the $1.425 billion to $1.475 billion range it had stated earlier. The7 company posted revenue of $1.39 billion a year earlier.   K Earlier this year, Legato hired Morgan Stanley to seek potential buyers. In N February, sources told Reuters that Legato was an acquisition target for EMC..  J EMC's acquisition of Legato, if approved, will add to consolidation in theL software sector, amid PeopleSoft's (NasdaqNM:PSFT - News) bid for rival J.D.N Edwards and Oracle's (NasdaqNM:ORCL - News) hostile counterbid for PeopleSoft.  O EMC said it expected the deal to be completed in the fourth quarter of the 2003  calendar year.     				Rob    ------------------------------   Date: 8 Jul 2003 07:47:56 -0700 ) From: ejohnson@factset.com (Eric Johnson) ( Subject: Re: Good code profilers on VMS?= Message-ID: <ef79676b.0307080647.3d1cae4b@posting.google.com>   h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<SzHfe$6jtGBN@eisner.encompasserve.org>...  E > When measuring performance I create a slightly different version of / > my program that does not use dynamic linking.    Ugh!  What a pain!   3 > I have not seen the problem with dynamic linking.   E Its particularly challenging in an environment with over 700+ images.    A > I _have_ seen the problem that PCA cannot deal with DECthreads.   F This seems to be a common theme with VMS tools.  Properly dealing with/ DECthreads always seems to be an after thought.    G > Certainly HP needs to put a _lot_ more emphasis on bringing PCA up to  > date.   F Given the priority of the Itanium, it seems like that won't happen for/ many years to come.  Which is very frustrating.    -Eric    ------------------------------   Date: 8 Jul 2003 10:02:33 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) ( Subject: Re: Good code profilers on VMS?3 Message-ID: <PlgoFTrSs3pz@eisner.encompasserve.org>   i In article <ef79676b.0307080647.3d1cae4b@posting.google.com>, ejohnson@factset.com (Eric Johnson) writes: j > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<SzHfe$6jtGBN@eisner.encompasserve.org>... > F >> When measuring performance I create a slightly different version of0 >> my program that does not use dynamic linking. >  > Ugh!  What a pain!  A There are some profilers on other operating systems that actually . require a separate compilation for profiling !   ------------------------------  $ Date: Tue, 8 Jul 2003 05:16:16 -0400* From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense2 Message-ID: <II-dncxx59R3FpeiXTWJlg@metrocast.net>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0307070816.6ae79f06@posting.google.com... E > There was an interesting article in the July 2003 issue of HP World A > Magazine, page 34. The article is available online via the link 5 > http://hpworldnews.c.tclk.net/maabedKaaY0bda4e8YPe/  > E > (Note: The online copy of the article is accessible only by Interex = > members, but a free level of membership is available -- see  > http://www.interex.org.)  I Well, no surprises here:  yet another Shannon the Shill attempt to defend I the indefensible - and just as disgusting as all those that have preceded H it.  Why anyone with even half a clue might consider it 'interesting' is difficult to understand.  K Let's dissect this piece of garbage so that any newcomers to the discussion  won't be suckered in by it:   L 1.  'DEC CEO Bob Palmer's "we're twice as fast as any competitive processor", lost credence relatively early in the game.'  C How, exactly, Terry?  Are you suggesting that the Pentium Pro was a I 'competive' processor to Alpha?  If so, please document the percentage of 5 Alpha revenue with which it was directly 'competing'.   J Furthermore, bringing up GQ Bob as the champion of Alpha seems a bit much,L given how little interest he showed in promoting anything but Windows on it.I That's why anyone who cared breathed a tremendous sigh of relief when DEC H was purchased by Compaq:  while seeing the DEC name disappear was hardlyI pleasant, seeing what DEC had *become* disappear was the chance for a new ) owner to 'do the right thing' once again.   H And Eckhard Pfeiffer started trying to do exactly that.  Alpha marketingI picked up, even including VMS-specific aspects.  Pfeiffer declared openly G (both to the press and in internal memos) that Alpha was years ahead of H Itanic and would compete vigorously with it (this was at a time when theK first Itanic was scheduled to ship in Y2K and be a formidable contender; of I course, the reality was that it shipped in 2001 and was a complete flop).   L 2.  "The third-generation EV6 processor-thought by some to be Alpha's chance1 to regain supremacy-was at least 18 months late."    My! 18 *months* late!   G Intel and HP first projected Itanic's debut as late 1997.  That quickly K changed to 1998 - then 1999 - then 2000.  It actually appeared in 2001, but K was so slow that Intel decided to try to save face before the launch rather H than be subject to extensive ridicule after it and warned that it reallyE wasn't anything but a trial system for people to become familar with.   G So Itanic was either nearly 4 *years* late, if you count its unlamented K first appearance, or nearly 5 *years* late, if you measure to the time when " the first useful product appeared.  J 3.  "Senior DEC processor architects who previously disregarded Intel as aL competitor had a sudden change of opinion and concluded that Intel's processH technology was emerging as a daunting-if not insurmountable-challenge to Alpha's long-term future."  H Funny - this fear and trembling is alleged to have developed in the yearI after EV6 appeared, i.e., certainly by Fall, 1999.  I guess these 'senior G DEC processor architects' didn't bother to reveal their concerns to the L senior corporate VPs they reported to - Bill Heil and Jesse Lipcon - becauseJ in September, 1999 those same VPs wrote a passionate commitment to Alpha'sH long-term future (through EV10, with specific feature commitment through9 EV8) and posted it prominently on the Alpha Web site (see L http://www.tru64.org/pages.php?page=Valued_Customers ).  On October 11, 1999L senior Alpha technical contributors released a detailed, 32-page white paperD detailing exactly why Itanic's architecture could not equal Alpha's,- regardless of process technology issues - see G http://www.cs.trinity.edu/~mlewis/CSCI3294-F01/Papers/alpha_ia64.pdf or F http://www.raytheon-computers.com/ref_docs/alpha_ia64.pdf .  And JesseJ Lipcon retained this viewpoint right up to the day he retired in December,J 2000 (see "Jesse Lipcon:  Interview with a pioneer", though I can't find a freely-available copy on line).   K In other words, Terry simply lied.  At a *later* date, some Compaq *server* J (not processor) architects who had a different vision of the future of theK server line than that which EV7/EV8 were designed to support helped provide K a fig-leaf for management's decision to kill Alpha, but that was hardly the J kind of technical consideration that Terry attempted to convey.  And sinceE these server people were the same ones who had turned Wildfire into a H mediocre rather than a leadership product, the quality of their 'vision' should be assessed accordingly.   K 4.  "Intel disclosed an extended five-year-plus road map that convinced the J Alpha team that Itanium would surpass Alpha in every metric before EV8 saw the light of day."  J Supposedly in Fall, 2000.  Fortunately, we no longer need to guess at whatI that roadmap might be, because Intel has now publicly disclosed its plans H through the end of 2005 - and they make the suggestion that Itanic wouldF have permanently eclipsed Alpha in anything of commercial significance
 laughable.  E In products using the same process generation, Itanic's *one* current D noticeable lead is in single-processor floating-point (and similarlyE regular) processing, which is characteristic of some high-performance C scientific and workstation applications but not of most software of I commercial importance.  And even here, Alpha remains competitive (not far J behind - especially in peak scores), and the partnership entered into withF IBM to produce Alphas ensured that if Alpha process generations lagged& Itanic at all it would not be by much.  G When the game changes to multi-processor scaling EV7's peak SPECfp_rate D score passes HP's Itanic peak score (in the same process generation)H starting with 2-processor systems, and its base score passes HP's ItanicK base score starting with 4-processor systems (i.e., EV7 scales far better). J EV7's peak scores even significantly surpass SGI's superbly-scaling ItanicK systems in the same generation, though EV's base scores are slightly lower.   K And EV7 accomplishes this with a processor core that debuted in 1998, using E a design 4 years older than Itanic2's (e.g., not benefiting from FMAC L instructions that give Itanic a nominal 2:1 advantage in FLOPS, and having aJ slower L2 cache than could have been employed if the core had been updatedJ to be able to accept data from it faster), without using feedback-directedK optimization for its base scores (unlike Itanic), and using compilers being G developed far less vigorously than Itanic's are (one of the interesting I observations in that alpha_ia64.pdf paper cited above is that most of the F compiler optimizations applicable to Itanic are applicable to Alpha as well).  I Now, Terry's statement above was very carefully crafted.  It said nothinguL about EV8's ability to beat the pants off Itanic, but instead suggested thatL *before EV8 appeared* Itanic would grab a (temporary) lead.  By late in Y2K,E after Pfeiffer's enthusiasm for Alpha got replaced in April, 1999, by H Capellas' meat-cleaver approach to funding (pressure on staffing levels,J temporary diversion of staff to other endeavors, management shuffles - allL of which hardly encourage smooth project progress), it had started to becomeG likely that Itanic would enter its 130 nm process generation before thenJ appearance of EV8 (which had first been scheduled for December, 2001, thenH slipped to a 2002 date in late 1999 after the sea-change in support thatG arrived with Capellas had become obvious).  This meant that there wouldeI likely be a period during which EV7 with its 1998 core and 180 nm processeL would be competing with Itanic2 with its 2002 core and 130 nm process (as itJ is at this very moment), and during that period Itanic would indeed grab aI significant lead (though hardly everywhere:  there's nothing on the Intel K roadmap to suggest that Itanic will catch up with the system bandwidth that C EV7 offers today, as measured by the STREAMS benchmarks, before thee. yet-undisclosed 2006 or later Itanic appears).  L So while Terry's statement is technically correct (given the lack of supportH that the Alpha team was already experiencing as of late Y2K), the strongL implication that this represented some kind of *permanent* change in Alpha'sL competitiveness rather than a temporary glitch is rubbish.  Even at the dateI of the Alphacide nearly a year later Alpha's processor architects had *nohK doubt whatsoever* that EV8 would regain a significant performance lead overiK Itanic if they were allowed to continue - even with their cut-back support. K Again, it was the disgruntled *server* contingent who were inclined to castuL doubt on Alpha's ability to compete - because it didn't fit what they wantedF to do:  characterizing this group as 'Alpha advocates' is analogous to6 characterizing Brutus as a supporter of Julius Caesar.  L Another relevant observation is that Intel had only a 5-year roadmap becauseH it had no clue where the road might go after that - in fact, in terms ofH *evolution* Intel's map stopped in less than 2 years, because everythingG after that was simply process-shrinks and the cache-size increases (and L eventual multi-core dice) that they made possible.  By contrast, Alpha had aL clear evolutionary path through EV7 (on-chip supporting features that aren'tE yet on Itanic's roadmap at all) and EV8 (8-wide issue, SMT, and otherzF goodies), at that time scheduled to ship in early 2002 and early 2003,F respectively - though further cut-backs would push both dates out moreL before EV8 got cut off altogether.  Plus a clear vision for EV9 and at least tentative plans for EV10.-  B When Intel obtained the EV8 development team from Compaq after theI Alphacide, they immediately put them in charge of defining and developingyD the next new Itanic processor core (which is slated to appear at theJ earliest in 2006).  So clearly, if Intel had anyone working on a follow-upI core before that, they hadn't produced anything that Intel felt was worthpK pursuing.  This both highlights the value of the EV8 work that the team had L been doing on Alpha, and indicates that Itanic's future would have been evenI more questionable than it already is had they *continued* working to keep- Alpha in the lead.  E 5.  "The Alpha team drafted a white paper articulating the respectivep futures of Alpha and Itanium."  J Now, if you read the paragraph in which this appears in the context of theI preceding paragraphs, you might infer that this analysis appeared shortlyiB after the 'team' was supposedly so impressed by Intel's Fall, 2000B presentation.  In fact, it appeared a full year later (*after* theL Alphacide, in yet another lame attempt to justify it) in October, 2001.  AndK the 'team' that authored it was, once again, *not* the Alpha processor team E (much of which was already at Intel by then) but the High Performancec *Servers* Business Unit.  L 6.  "Contrary to the claims of some, the research and the resulting decisionG were arrived at by the best and the brightest on the Alpha team, not bye/ Compaq's senior management team or financiers."c  H Pure, unadulterated bullshit.  The Big Lie at its best:  repeat it often3 enough, and at least *some* people will believe it.r  J 7.  "Compaq was losing more or less $800 on every Alpha chip it produced."  H Now we enter the 'creative accounting' portion of the spin.  Even if oneJ accepts that by some isolated measure (based on internal transfer pricing)K the above statement is correct, the fact remains that VMS and Tru64 systemsdL produced, even after slumping somewhat in early 2001, close to $1 billion inG *profit* annually for Compaq.  Later Terry indicates that average Alpha0E production was about 100,000 processors per year over the 1992 - 2002hG decade.  Even if one allows for the fact that the early years saw lower-L production numbers (so production at the time of the Alphacide may have beenI slightly above 100,000 annually), at $800 a pop that's at most about $100 L million annually in 'losses', offset by close to $1 billion in Alpha-related@ profit that took a *major* hit once the Alphacide was announced.  G Of course, one can also question the base assertion:  according to RickfG Marcello at the time of the Alphacide, Alpha chip development cost $150 I million annually (covering two parallel tracks:  EV7 and EV8).  So unless H Compaq was selling Alphas for less than it was paying IBM to build them,F that figure pretty much caps the possible annual nominal 'loss' - and,I again, should be compared with the hit that the near $1 billion in annualiJ system profit took (VMS annual system revenue after the Alphacide was halfL what it was when it was generating $800 million in annual profit, indicatingI that the reduction in VMS annual system profits alone would have paid for + continued EV8 development many times over).l  : 8.  "Hindsight reveals that Compaq made the right choice."  D More bullshit.  And it's not as if Terry struggled in coming to thisK conclusion:  his near-miraculous conversion occurred instantly, on June 25,hF 2001 - clearly indicating that he knew on which side his own bread was	 buttered.s  ! 9.  "The economics were obvious."   I Yes, they were:  as noted above, by killing Alpha Compaq lost far more in L profit than the amount it would have cost to continue its development - evenD if Compaq had *still* refused to try to grow its markets.  Given howJ tenacious Alpha's sales were despite the abject neglect of its owner, withK any real support it's entirely probable that Alpha profits could have grown 
 many-fold.  K If the decision to kill Alpha was indeed based on economics, it was clearlyn made by utter incompetents.i  H 10.  "Of equal importance, the Itanium adoption simplified the merger of Compaq and Hewlett-Packard."  K Equal???  Even the current Administration would likely have gagged over theuL acquisition had Alpha still been competing.  Killing Alpha didn't 'simplify'% the merger, it was *required* for it..  G And the merger was likely the only thing that would save Capellas' job,eK given his dismal performance as CEO for the previous 2+ years.  Carly's job1 as well, for the same reason.   I So while Capellas had been slowly throttling Alpha since 1999, the mergerdI certainly finalized the decision (and perhaps explains the 'economics' oft it).  H 11.  "The good news is that HP-like most other vendors-is betting on the
 right horse."   I If the Itanic horse wins, it will because sharpshooters took out at leastuI two superior entries - both of them currently owned by HP.  And Itanic is H *so* late getting started that the dark horse Hammer may 'eviscerate itsH soft underbelly' from below while POWERx retains the commercial high-end crown.  L But Terry's feel-good spin won't be telling any such tales:  rationalization is his specialty.e  H 12.  "The Alpha design team devoted nearly one-third of an estimated $10G billion budget to Alpha research, development and implementation cost."1  C Terry has clearly been smoking something considerably stronger than>$ tumbleweed down there in New Mexico.  I 13.  "The senior developers of the much-vaunted Alpha EV8 microprocessor,l: originally due in 2004, began investigating alternatives."   Back to out-right lies again.E  I a)  The original target date for EV8 (at least the first one I'm familiaroL with) was 2001:  see Pete Bannon's October, 1998 MPF presentation (I've seenJ a couple more references from late 1998/early 1999 that specifically stateJ December, 2001, with EV7 scheduled exactly one year earlier).  Those datesI were unquestionably aggressive, but they were official at that time.  AndiH even if EV8 had slipped by the full 18 months that Terry noted with suchF amazement for EV6, it would have appeared last month - just in time to6 out-match the launch of the 130 nm Itanic ('Madison').  L (EV7 *did* slip a full 25 months beyond its December, 2000 initial schedule.H Some of that slip was doubtless really justified by unexpected technicalI obstacles.  Another equally significant portion was likely due to lack oflI support.  But even given that neglect, after tape-out in May, 2001, first3I silicon a month later, and first VMS boot a month after that, by January,aL 2002, things appeared to be going well and Compaq was projecting shipment inK Q3 - a slip of only 19 - 21 months.  The final 4 - 6 month slip to January,nG 2003 after HP took over the reins was AFAIK never explained, but lookedaG suspiciously like an attempt to keep EV7 from stealing whatever thunderv Itanic2 might have.)  E The other part of the lie is once again that senior Alpha *processor* I developers were involved in this intrigue.  One might hazard a guess thatgL the participants in the little Intel party that Terry describes included oneE server architect whose identity might not be excessively difficult to  imagine.  @ 14.  "It was further discovered that the addition of symmetricalK multi-threading to EV8 would reduce the processor's target clock speed by 1y GHz."m  C Another 'fact' that the actual Alpha chip team would find extremelynG surprising:  Terry's just full of them (or at least full of something).b  H 15.  "Incremental resources were not available to address this and other issues."  H That part was true:  Capellas had already proved that he wasn't about to fund Alpha adequately.  K 16.  "Based on the road map, Itanium would surpass Alpha in virtually every  dimension before 2005..."s  D Well, I can't comment on the truth of that, because I don't know howF fanciful that roadmap may have been (and given Intel's previous ItanicH roadmaps, it could well have been very fanciful indeed - you might thinkK that any competent investigators would have taken that into account if theynL were truly in search of the truth rather than of the conclusion they alreadyD wished to reach).  But, as explained above, the only way that such aK prediction had any way of becoming *reality* was first by continued neglecti@ of EV7 and then by ensuring that EV8 never saw the light of day.  , Aren't self-fulfilling prophecies wonderful?  F 17.  "...and prior to the introduction of a next-generation enterpriseE server designed to run multiple processor architectures and operatings	 systems."e  H Here we return once again to the crux of the matter - because the serverJ group *really* wanted to scrap EV7/EV8 and design a box that didn't dependJ on their unique strengths (i.e., one that could run any old processor, andL was limited by that generality).  And they indeed found a receptive audienceH in management that clearly preferred to join the 'industry-standard' mobL rather than use Alpha to compete with it, however effective that competition could have been.    L So it's just the same old crap from Terry, repackaged a bit.  'Interesting'?B Not by my standards - just disgusting.  If anyone wants additionalF background on Compaq's lies and broken commitments that surrounded the  Alphacide, there's an article at9 http://www.tru64.org/stories.php?story=01/09/06/4674257 .n   - bill   ------------------------------  % Date: Tue, 08 Jul 2003 09:17:25 +0100A* From: Nic Clews <sendspamhere@[127.0.0.1]> Subject: Re: KVM switchesS' Message-ID: <beduse$6jp$1@lore.csc.com>t   Tim ffrench-Lynch wrote: > H > Does anyone know of any affordable KVM switches that will work with anJ > AlphaStation 255? It's the old business of the Alpha using scanset 3 and > the PC something else.  H To add to the discussion, I'm using a Belkin KVM. Using earlier graphicsG cards, e.g. the EISA Compaq Qvision, the signalling can make the switch G think the system has gone to sleep, although it does appear to pass theu. signalling correctly (the port select blinks).  E For one of the PC's I'm using quite a high resolution, and I find theoH screen smears a little at high resolution and scan rate. A manual switchH (that this one replaced) did the same. It claims to support 1900 by 1200 though. Just call me Mr. Fussy.r   -- (? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencese nclews at csc dot como   ------------------------------  % Date: Tue, 08 Jul 2003 10:32:35 +0100u/ From: Tim ffrench-Lynch <nospam@baesystems.com>s Subject: Re: KVM switchese. Message-ID: <3F0A8FB3.A09DAA87@baesystems.com>   Mike Bartman wrote:r@ > I've got an AlphaStation 200 using a Belkin F1D074.  Handles 4G > computers, and worked fine with a couple of NT boxes when I was usingsG > it to handle all three inputs (I've since found a proper keyboard for:G > the Alpha, so that part isn't on the Belkin anymore...I like the feelnB > of a proper keyboard better, and the keys are where the softwareE > expects them.  I still use the Belkin to switch the mouse and videot
 > though.) ...wE > I don't know if a 200 and a 255 differ enough to matter, but that's . > what I've got here, and it's working for me.  E On looking at my machine, it's a 200 as well, the 255 was a machine I-G had on my desk a few years ago. DEC make equipment so reliable that you  can forget what model it is :-)t  A The Belkin switch is no longer available and has been replaced by- switches of unknown capability.-  C It looks as though Adder in the UK may be worth investigating. TheyEG specifically mention DEC Alpha and one switch (their cheapest) mentions E keyboard modes 1,2,3. They have two and four way switches at 80-110gG excluding VAT. I've emailed them to ask a few questions, I'll follow up  here if I get any luck.-   Tim    ------------------------------  % Date: Tue, 08 Jul 2003 10:55:49 +0100d/ From: Tim ffrench-Lynch <nospam@baesystems.com>  Subject: Re: KVM switches2. Message-ID: <3F0A9525.3EB4C616@baesystems.com>   Mike Bartman wrote:l@ > I've got an AlphaStation 200 using a Belkin F1D074.  Handles 4G > computers, and worked fine with a couple of NT boxes when I was usingtG > it to handle all three inputs (I've since found a proper keyboard forsG > the Alpha, so that part isn't on the Belkin anymore...I like the feelhB > of a proper keyboard better, and the keys are where the softwareE > expects them.  I still use the Belkin to switch the mouse and video>
 > though.) ...tE > I don't know if a 200 and a 255 differ enough to matter, but that'sn. > what I've got here, and it's working for me.  E On looking at my machine, it's a 200 as well, the 255 was a machine IiG had on my desk a few years ago. DEC make equipment so reliable that youn can forget what model it is.  A The Belkin switch is no longer available and has been replaced bya" switches of unknown capability :-(  H Adder in the UK look worth trying. On the web, they specifically mention; DEC Alpha but not VMS. I emailed them and got this reply :-i  C . The DEC Alpha running VMS requires keyboard mode 3 that the OmegagB . supports fully. It is also happy running mixed keyboard modes on= . different ports (most PCs use mode 2). It also supports the:C . undocumented PS/2 codes that are used by DECs and DEC keyboards. uE . The Omega or GEM are ideal switches for what you are looking to do.c  7 The Omega is 80+VAT, supports two computers and sound.sC The GEM is a more normal design, 95+VAT (2 computers), 110+VAT (4a% computers) but doesn't support sound.m  B I'll probably order order one and follow up here with the results.   Timn   ------------------------------  % Date: Tue, 08 Jul 2003 07:36:30 -0500n( From: Michael Rice <marice@whiteice.com> Subject: Re: KVM switchesr/ Message-ID: <vglemhe7to2994@corp.supernews.com>t  . On 7/7/2003 11:17 PM, Stanley F. Quayle wrote:  . > On 7 Jul 2003 at 16:28, Ken Fairfield wrote: > M >>I haven't been able to get a technical person to tell me whether either thebE >>Rose or the Raritan can manage the switch between a live VMS/Alpha s >>and a live PC. >  > F > I have a Raritan switch working between Windows 2000, Red Hat Linux D > 7.3 on Intel, OpenVMS 7.3-1 Alpha, and OpenVMS 7.3 VAX.  It works H > perfectly.  There are no problems with the keyboard, unlike other KVM  > switches I've tried. > F > And, as I said in an earlier posting, I was able to get a Raritan 4- > port for about $100 on eBay. >   F Assuming the KVM has PS/2 connections for mouse and keyboard, how did 3 you connect it to the VAX, or is that a Charon VAX?    ------------------------------  % Date: Tue, 08 Jul 2003 10:30:28 -04002* From: "Stanley F. Quayle" <stan@stanq.com> Subject: Re: KVM switches,/ Message-ID: <3F0A9D44.28127.1435F3CD@localhost>   * On 8 Jul 2003 at 7:36, Michael Rice wrote:H > Assuming the KVM has PS/2 connections for mouse and keyboard, how did 5 > you connect it to the VAX, or is that a Charon VAX?e  B I have the video hooked to the KVM.  I'm "experimenting" with VAX  4000 to PS/2 conversion.  + I'm sure CHARON-VAX would work fine, too...s  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671o1 8572 North Spring Ct. NW, Pickerington, OH  43147n= Preferred address:  stan@stanq.com       http://www.stanq.comc   ------------------------------  % Date: Tue, 08 Jul 2003 12:30:22 -0400 8 From: Jim Agnew - VCU/MCV Neurosurgery <jpagnew@vcu.edu> Subject: Re: KVM switchess' Message-ID: <3F0AF19E.AC17F4B9@vcu.edu>t  G Try the Black Box catalog.  however, they tend to be pricey, but if you.$ cought it up, it tends to work well.   jime   Tim ffrench-Lynch wrote: > H > Does anyone know of any affordable KVM switches that will work with anJ > AlphaStation 255? It's the old business of the Alpha using scanset 3 and > the PC something else. > F > It looks like what is needed is a KVM with a keyboard controller forG > each computer connection which then talks to the keyboard in whateverrI > way it prefers. It looks like a Raritran switch would work, but they'ren. > a bit pricey for a 92 AlphaStation at home. >  > Tim    --  F "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"  F "I try not to be right any more than necessary". -- Larry Wall, author of the Perl Language   ------------------------------  # Date: Tue, 08 Jul 2003 11:08:59 GMTh) From: Patrick Young <P.Young@unsw.EDU.AU>e- Subject: Re: LTO-2 Ultrium tape drive and VMSs; Message-ID: <fDxOa.443$TX6.6213@news-server.bigpond.net.au>    Bart Zorn wrote: > Interesting! > F > I understood that the problem with LTO drives until now is that theyB > do not support small blocks and thus cannot support ANSI labels.  >2 > Did you try to use BACKUP to write to the drive?  > Yes, works a treat. See below. You could write ANSI label size? blocks all day long, however like a DLT you don't. Small blocksj9 will put you at TK50 performance level really quickly :-)0  2 Consider the following mods to my previous post...  7      declare integer constant block_count = 1048544%, &>0                               block_size = 2048%  5          (block_size) + "/media_format=nocompaction")k   $ r test+ %MOUNT-I-MOUNTED,  mounted on _TEST$MKA100:a Data to write (MB) : 2047  Time taken         :00:03:44.14e MB per second      : 9.13268  4           (block_size) + "/media_format=compaction")   $ r test+ %MOUNT-I-MOUNTED,  mounted on _TEST$MKA100:r Data to write (MB) : 2047  Time taken         :00:03:37.81  MB per second      : 9.3981r  9 I'm keeping this Dell kit, and it's going into production-8 on Sunday to replace the TL891 (Our Novell administrator can go buy his own :-)  ; Things to watch for: Unit must be placed on a level surface-9 for the robot to work properly to the in/out port. I alsoy= don't like the fact the the default start up mode is "Wizard"B; which puts the robot into MRU "ATTENTION" status, as does aK= half completed front panel move operation. I would prefer MRU) to override this.t  	 Backup...r  > $ back dkb200:[vms$common...] mk100:test/save/list/ign=lab/rew Listing of save set(s)  H %BACKUP-I-LBLOVRWRITE, volume label NON-ANSI     overwritten, new label  is TESTw  / %MOUNT-I-MOUNTED, TEST mounted on _TEST$MKA100:n Save set:          TEST. Written by:        SYSTEMe" UIC:               [000001,000004]* Date:               8-JUL-2003 17:53:37.12/ Command:           BACK DKB200:[VMS$COMMON...] e  MK100:TEST/SAVE/LIST/IGN=LAB/REW- Operating system:  OpenVMS Alpha version V7.3  BACKUP version:    AXP73-1 CPU ID register:   80000000   Written on:        _TEST$MKA100: Block size:        8192t Group size:        10d Buffer count:      110   ------------------------------  # Date: Tue, 08 Jul 2003 11:52:53 GMTs) From: Patrick Young <P.Young@unsw.EDU.AU>t- Subject: Re: LTO-2 Ultrium tape drive and VMSt; Message-ID: <pgyOa.501$TX6.6937@news-server.bigpond.net.au>    Dan Allen wrote: > F > 	First I've heard that. Previous posts here have identified odd byteF > 	transfers as the problem - supposedly supported by LTO-2. I have anI > 	LTO-2 library on a Dell Windows server here and using Veritas it's PDFd' > 	(about 70MB/sec without any tuning).. >  > 	Dan  A I'm putting my Dell unit into production for OpenVMS next Sunday.   , 70MB/sec... two drives in your library unit?   ------------------------------  $ Date: Tue, 8 Jul 2003 08:15:46 -0400# From: "Dan Allen" <dallen@nist.gov>l- Subject: RE: LTO-2 Ultrium tape drive and VMSN: Message-ID: <JFEPKAPBPMDFDBOIANGDOELMDJAA.dallen@nist.gov>   > -----Original Message-----2 > From: Patrick Young [mailto:P.Young@unsw.EDU.AU]& > Sent: Tuesday, July 08, 2003 7:53 AM > To: Info-VAX@Mvb.Saic.Com / > Subject: Re: LTO-2 Ultrium tape drive and VMSs >  >  > Dan Allen wrote: > > H > > 	First I've heard that. Previous posts here have identified odd byteH > > 	transfers as the problem - supposedly supported by LTO-2. I have anK > > 	LTO-2 library on a Dell Windows server here and using Veritas it's PDFe) > > 	(about 70MB/sec without any tuning).3 > >  > > 	Dan > C > I'm putting my Dell unit into production for OpenVMS next Sunday.s > . > 70MB/sec... two drives in your library unit? >h  R 	Just one - something amiss about that number? I believe that's the number VeritasU 	BackupExec logs but I'll double check (W2K/NTFS). Just out of curiosity who providese" 	the VMS drivers for the Dell kit?   	Dan   ------------------------------  # Date: Tue, 08 Jul 2003 13:30:19 GMTf) From: Patrick Young <P.Young@unsw.EDU.AU> - Subject: Re: LTO-2 Ultrium tape drive and VMSt; Message-ID: <LHzOa.624$TX6.8296@news-server.bigpond.net.au>    Dan Allen wrote: >  >>-----Original Message-----2 >>From: Patrick Young [mailto:P.Young@unsw.EDU.AU]& >>Sent: Tuesday, July 08, 2003 7:53 AM  . >>70MB/sec... two drives in your library unit? >>T > 	Just one - something amiss about that number? I believe that's the number VeritasW > 	BackupExec logs but I'll double check (W2K/NTFS). Just out of curiosity who providese$ > 	the VMS drivers for the Dell kit?  A This is using the as shipped standard OpenVMS device drivers. Fore& the robot, the Compaq/HP MRU software.  ? 70MB/sec just seems a bit optimal for a single drive. What sorte9 of capacity per tape do you get?, and the blocksize used?i   Many thanks.   ------------------------------  $ Date: Tue, 8 Jul 2003 09:56:59 -0400# From: "Dan Allen" <dallen@nist.gov>r- Subject: RE: LTO-2 Ultrium tape drive and VMSs: Message-ID: <JFEPKAPBPMDFDBOIANGDEEMDDJAA.dallen@nist.gov>   > -----Original Message-----2 > From: Patrick Young [mailto:P.Young@unsw.EDU.AU]& > Sent: Tuesday, July 08, 2003 9:30 AM > To: Info-VAX@Mvb.Saic.Com / > Subject: Re: LTO-2 Ultrium tape drive and VMSe >  >  > Dan Allen wrote: > >  > >>-----Original Message-----4 > >>From: Patrick Young [mailto:P.Young@unsw.EDU.AU]( > >>Sent: Tuesday, July 08, 2003 7:53 AM > 0 > >>70MB/sec... two drives in your library unit? > >>V > > 	Just one - something amiss about that number? I believe that's the number VeritasY > > 	BackupExec logs but I'll double check (W2K/NTFS). Just out of curiosity who providesg& > > 	the VMS drivers for the Dell kit? > C > This is using the as shipped standard OpenVMS device drivers. Fors( > the robot, the Compaq/HP MRU software. > A > 70MB/sec just seems a bit optimal for a single drive. What sortr; > of capacity per tape do you get?, and the blocksize used?n >   L 	This is Windows not VMS - I don't choose the blocksize, BackupExec does ;-)N 	Actually I'll check and see if I can find the answer to that question. As forJ 	capacity I don't know - have yet to fill a tape! I'm still evaluating theJ 	BackupExec software - must say I like it - very intuitive easy to use GUIO 	and the operation is not too different conceptually from VMSBACKUP. I've neverrS 	had a VMS system with a library so I'm totally clueless wrt the MRU functionality.g   > Many thanks. >   O 	Why certainly - I was a little surprised when I learned a month or so ago thatTR 	VMS didn't/couldn't support LTO tape. Obviously that's going to change real quickT 	now that LTO-2 is on the street. As you have said this is real good performance andS 	price. My ADIC Scalar 100 with 60 slots (24TB compressed) and 1 drive was $20K andi 	change.   	Dan   	Dan   ------------------------------  $ Date: Mon, 7 Jul 2003 23:35:26 -0700$ From: "Eric Bruno" <eric@ebruno.org>+ Subject: Re: OpenVMS 7.3.1 Install problem. 0 Message-ID: <fgSdnWDowsH6-5eiXTWJjg@comcast.com>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3F0A16C4.76FA5D93@fsi.net...e > > Eric Bruno wrote:s > >e > > David J. Dachtera wrote: > >l > > > Eric Bruno wrote:t > > >  > > >t
 > > >> [snip] G > > >> Someone was generous enough to put an iso image of  7.2-1 up for  > > >> me to > > >> download.F > > >> I downloaded the image, burnt the CD installed 7.2-1 with out a > > >> problem.l > > >> > > >>J > > > Interesting that it worked at all. AFAIK, VMS's loaders can't handle@ > > > ISO-9660 media. I suspect it was an ODS image, not an ISO. > > >e > > >oE > > It was ISO as far as the buring software was concerned  (the filed' > > extension) it was image of  the CD.a >uD > My guess is you're using a piece of software that burns the image,G > regardless of its content. AFAIK, Gear and Nero will do this, as will  > others (cdrecord?).t Hotburn by ASIM. > 8 > > The actual format I'll have to take your word on it. >aJ > Don't take my word for it - ask OpenVMS Engineering if VMS can be booted! > from an ISO-9660 format medium.i  E The point is good image, good CD, 7.2-1 booted installed no problems.e  K For what ever reason at this point it's moot. The machine I am using is NOT  on the supportedG list and as far as I am concerned I am not going to get a free lunch on2 7.3-1 working on the machine.   K I'll get a machine on the offical 7.3.1 supported list and then try  7.3.x.  again.  H I had the same type of problem with Solaris 2.7 x86 and Solaris 2.8 x86.K Got a machine worked great on 2.7, get 2.8 Sun happened to drop support for I 2 pieces of hardware I was using the NIC and SCSI card.  Bit of a problemo sinceh the system was all SCSI :-).     >b > -- h > David J. Dachteran > dba DJE Systemsn > http://www.djesys.com/ >r* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/i   ------------------------------  # Date: Tue, 08 Jul 2003 13:54:58 GMTs3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond)a+ Subject: Re: OpenVMS 7.3.1 Install problem.s1 Message-ID: <S2AOa.4109$ww.1734@news.cpqcorp.net>s   Somebody wrote:p .i4 >}>  $DIRECTORY/DATE/SIZE SYS$COMMON:[000000]*.PCSI* >}> " >}>  This showed these four files: >}> 7 >}>     DEC-AXPVMS-OPENVMS-V0703-1-5.PCSI$DESCRIPTION;1o/ >}>     DEC-AXPVMS-OPENVMS-V0703-1-5.PCSI$TLB;1 3 >}>     DEC-AXPVMS-VMS-V0703-1-2.PCSI$DESCRIPTION;1d+ >}>     DEC-AXPVMS-VMS-V0703-1-2.PCSI$TLB;1. >} t >}Try: >} ,9 >}$ RENAME SYS$COMMON:[000000]*.PCSI* SYS$COMMON:[SYSEXE]i  H This is a bad idea.  These files are the Product Description and Product' Text files. They are where they belong.c  H The PCSI database is a number of file with the extentsion .PCSI$DATABASEI located in SYS$COMMON:[SYSEXE].  They are not present because the OpenVMSuG installation did not complete.  (They are the last thing written by thew PRODUCT INSTALL command.)a  G If this system is not supported for OpenVMS V7.3-1, then the failure of J the installation is likely due to that fact -- i.e., there is something inK the hardware which OpenVMS V7.3-1 doesn't work with.  You may or may not be @ able to find a way around this.   Sorry I can't be more helpful.   -- fJ       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------   Date: 8 Jul 2003 08:47:48 -0500y; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)s  Subject: OpenVMS I64, a proposal3 Message-ID: <FW8PQBYcNJBA@eisner.encompasserve.org>h      A proposal:  G    WHEREAS there is lot of software on the Freeware CD that needs to be +       ported from Alpha and/or VAX to IA64,   C    AND OpenVMS I64 8.0 requires cross compilers hosted on an Alpha,s  /    AND OpenVMS Alpha is fully internet capable,i  H    AND OpenVMS I64 clusters with OpenVMS Alpha, providing disk and other       services,u  1    AND we're all itching to get our hands on one,a  C    AND nobody is going to get paid to port all that free softeware,   ?    AND the OpenVMS hobbyist community includes some of the mosth:       VMS knowledgeable people outside of VMS engineering,  E    THEREFOR I propose that HP provide a small two node Alpha and IA64wB       cluster, unsupported, undocumented, on the internet, to the J       OpenVMS hobbyist community at large for the sole purpose of porting (       said free software to OpenVMS I64.  F    I'll volunteer to remote admin the thing.  Local admin, too, if you+    can put in in HP's facility on Ivy Lane.o  F    No support from VMS engineering expected, they've got too much work    to do already.a  F    And, oh yes, later we should allow porting of other free software, J    provided that it end up on the Freeware CD or is made freely available (    by other means such as GNU web sites.   ------------------------------   Date: 8 Jul 2003 09:57:51 -0500t- From: Kilgallen@SpamCop.net (Larry Kilgallen) $ Subject: Re: OpenVMS I64, a proposal3 Message-ID: <5XzHgOLm8I6L@eisner.encompasserve.org>   q In article <FW8PQBYcNJBA@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:,  G >    THEREFOR I propose that HP provide a small two node Alpha and IA64rD >       cluster, unsupported, undocumented, on the internet, to the L >       OpenVMS hobbyist community at large for the sole purpose of porting * >       said free software to OpenVMS I64.  ? I hate to consider all that freeware floating around built withi= still-buggy compilers.  Presumably once IA64 VMS is released,t= anything that built on Alpha VMS should easily build, or else B depends on IA64 VMS internals that _do_ require listing kits, etc.   ------------------------------   Date: 8 Jul 2003 08:15:46 -0500t; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)i) Subject: Re: Porting VAX Object Libraries 3 Message-ID: <cG8RJGROnAz6@eisner.encompasserve.org>   S In article <becnbo$lro$1@titan.btinternet.com>, "Code Monkey" <me@here.com> writes:iB > Have an application that I would like to port to Alpha from VAX. > J > Whilst I have the C code for the application it has to link against some5 > object libraries which I don't have the source for.b >   C    If you're using object libraries, this is unimportant as the VAX (    .EXE will have all the objects in it.  K    If you're using shared image libraries (also .OLB), then you'll need to pH    see if you can VEST the shared images and build an Alpha shared image>    library from those (I don't know VEST, is this supported?).  4    $lib/list will tell you what your .OLB really is.   ------------------------------  + Date: Tue, 08 Jul 2003 11:58:20 +0200 (MET)i9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>  Subject: Re: RDB V7.; Message-ID: <01KY0K5BEHCMAPKEWT@sysdev.deutsche-boerse.com>   F > Anyone know where I can download a copy of RDB 7.1 for Vax? I have a8 > legitimate license but I've lost the distribution kit.  I No, you don't.  7.1 is ALPHA only.  And if you have a legitimate license m* you probably know where to download stuff.   ------------------------------  $ Date: Tue, 8 Jul 2003 12:00:07 +0100" From: "Rolona" <nospam@nospam.com> Subject: Re: RDB V7.> Message-ID: <LwxOa.10585$pd.7381@news-binary.blueyonder.co.uk>   Your right, sorry, RDB 6.0-04y> I've looked all around Oracle's site and cant find a download.L My licenses are about 8 - 10 years old. and I need the distribution kit just to change to a different Vax.e  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KY0K5BEHCMAPKEWT@sysdev.deutsche-boerse.com...oH > > Anyone know where I can download a copy of RDB 7.1 for Vax? I have a: > > legitimate license but I've lost the distribution kit. >hJ > No, you don't.  7.1 is ALPHA only.  And if you have a legitimate license, > you probably know where to download stuff. >    ------------------------------  + Date: Tue, 08 Jul 2003 13:24:42 +0200 (MET)n9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>e Subject: Re: RDB V7.; Message-ID: <01KY0N2KM12EAM7Y4A@sysdev.deutsche-boerse.com>t  J > > > Anyone know where I can download a copy of RDB 7.1 for Vax? I have a< > > > legitimate license but I've lost the distribution kit. > >pL > > No, you don't.  7.1 is ALPHA only.  And if you have a legitimate license. > > you probably know where to download stuff. >   > Your right, sorry, RDB 6.0-04  > C > I've looked all around Oracle's site and cant find a download. MyaF > licenses are about 8 - 10 years old. and I need the distribution kit% > just to change to a different Vax. i  I If you're changing to a different VAX, rather than wanting to run Rdb on t5 an additional VAX, why not just move the system disk?   C As far as I know, Rdb kits are not downloadable from any public web F page.  If you have support, you can log in with username and password 8 and download stuff.  Contact your Oracle representative.   ------------------------------  $ Date: Tue, 8 Jul 2003 12:35:48 +0100" From: "Rolona" <nospam@nospam.com> Subject: Re: RDB V7.? Message-ID: <c2yOa.11331$pd.11227@news-binary.blueyonder.co.uk>d  F The new VAX is a different Model and I need to get it running before I= transfer it. Are system disks interchangeable between models?   F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KY0N2KM12EAM7Y4A@sysdev.deutsche-boerse.com...IL > > > > Anyone know where I can download a copy of RDB 7.1 for Vax? I have a> > > > > legitimate license but I've lost the distribution kit. > > >fF > > > No, you don't.  7.1 is ALPHA only.  And if you have a legitimate licenseu0 > > > you probably know where to download stuff. > >p! > > Your right, sorry, RDB 6.0-04u > >gE > > I've looked all around Oracle's site and cant find a download. MyeH > > licenses are about 8 - 10 years old. and I need the distribution kit& > > just to change to a different Vax. >aJ > If you're changing to a different VAX, rather than wanting to run Rdb on7 > an additional VAX, why not just move the system disk?e >*E > As far as I know, Rdb kits are not downloadable from any public webtG > page.  If you have support, you can log in with username and passwordA: > and download stuff.  Contact your Oracle representative.   ------------------------------  # Date: Tue, 08 Jul 2003 12:19:27 GMTr% From: "bayden cline" <bayden@isys.ca>n Subject: Re: RDB V7.H Message-ID: <jFyOa.83084$x4o.21727@news04.bloor.is.net.cable.rogers.com>   here try this link  9 http://otn.oracle.com/software/products/rdb7/content.htmlt   bayden  - "Rolona" <nospam@nospam.com> wrote in messaget8 news:LwxOa.10585$pd.7381@news-binary.blueyonder.co.uk... > Your right, sorry, RDB 6.0-04 @ > I've looked all around Oracle's site and cant find a download.I > My licenses are about 8 - 10 years old. and I need the distribution kitb just > to change to a different Vax.  >vH > "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message7 > news:01KY0K5BEHCMAPKEWT@sysdev.deutsche-boerse.com...oJ > > > Anyone know where I can download a copy of RDB 7.1 for Vax? I have a< > > > legitimate license but I've lost the distribution kit. > > L > > No, you don't.  7.1 is ALPHA only.  And if you have a legitimate license. > > you probably know where to download stuff. > >e >m >f   ------------------------------  % Date: Tue, 08 Jul 2003 10:34:03 -0400o* From: "Stanley F. Quayle" <stan@stanq.com> Subject: Re: RDB V7./ Message-ID: <3F0A9E1B.21679.14393BEA@localhost>t  % On 8 Jul 2003 at 12:35, Rolona wrote: H > The new VAX is a different Model and I need to get it running before I? > transfer it. Are system disks interchangeable between models?i  @ Depends on the two models of VAXen.  If you're going from a VAX " 11/780 to a VAX 4000, I'd say not.  D If both computers are SCSI, and your system disk is SCSI, you could  give it a try.  
 --Stan Quaylep Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671n1 8572 North Spring Ct. NW, Pickerington, OH  43147 = Preferred address:  stan@stanq.com       http://www.stanq.comg   ------------------------------   Date: 8 Jul 2003 08:07:48 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)V3 Subject: Re: Recursive copy between nodes using LATv3 Message-ID: <Kcfc+bpKeyOm@eisner.encompasserve.org>s  [ In article <CaiOa.1942$Fy1.91859@localhost>, "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> writes:nL > OK, OK both are running DECnet (I can set host from one to the other).  MyM > problem is still the same and your solution, unlike most on this newsgroup,u< > is not very helpful.  Why do you bother responding at all?  C    AH!  You see, that's an entirely different question.  You didn'tiD    provide enough correct information in the original post to make aE    better answer correct.  We can't help you with what you don't tellj    us.  -    Now that we know you have DECnet, you can:i  D    1) create a backup save set, use DECnet to copy that, and restore
       from itl  E    2) create the backup save set, or restore it, using DECnet withoutoD       bothering to copy it (BACKUP will only access save sets across
       DECnet)f  F    3) use tar, zip, ..., instead of backup, but that's unecessary pain  
 I'd do 2):         On the 1st system:O    $backup dev1:[dir1...] node2"user passwd"::dev2:[dir2]saveset/save_set/nocrcg         On the 2nd system:5    $backup dev2:[dir2]saveset/save_set dev3:[dir3...]l  F Or, if you have more disk space on the 1st system then the 2nd system:         On the 1st system:;    $backup dev1:[dir1...] dev2:[dir2]saveset/save_set/nocrcs         On the 2nd system:I    $backup node1"user passwd"::dev2:[dir2]saveset/save_set dev3:[dir3...]t    c   ------------------------------   Date: 8 Jul 2003 08:37:52 -0500v From: briggs@encompasserve.org3 Subject: Re: Recursive copy between nodes using LAT 3 Message-ID: <qhjR4U2WZScc@eisner.encompasserve.org>s  q In article <Kcfc+bpKeyOm@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:s] > In article <CaiOa.1942$Fy1.91859@localhost>, "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> writes: M >> OK, OK both are running DECnet (I can set host from one to the other).  MysN >> problem is still the same and your solution, unlike most on this newsgroup,= >> is not very helpful.  Why do you bother responding at all?  > E >    AH!  You see, that's an entirely different question.  You didn'taF >    provide enough correct information in the original post to make aG >    better answer correct.  We can't help you with what you don't telly >    us. > / >    Now that we know you have DECnet, you can:- > F >    1) create a backup save set, use DECnet to copy that, and restore >       from ita > G >    2) create the backup save set, or restore it, using DECnet withouteF >       bothering to copy it (BACKUP will only access save sets across >       DECnet)  > H >    3) use tar, zip, ..., instead of backup, but that's unecessary pain >  > I'd do 2): >  >       On the 1st system:Q >    $backup dev1:[dir1...] node2"user passwd"::dev2:[dir2]saveset/save_set/nocrcu >  >       On the 2nd system:7 >    $backup dev2:[dir2]saveset/save_set dev3:[dir3...]   A You missed one gotcha with this syntax.  Your restored files will  wind up in [dir3.dir1...]   E What you need to do on the restore command is use a /SELECT=[DIR1...]bD clause to "anchor" the source for the restore at the proper point in	 the tree.y   	John Briggs   ------------------------------  + Date: Tue, 08 Jul 2003 11:55:53 +0200 (MET)i9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>y Subject: Re: Rethinking  V.M.S; Message-ID: <01KY0JYK5S0YAPKEWT@sysdev.deutsche-boerse.com>-  H > > It's amazing how often the "Dave Cutler secretly implemented a fullyJ > > functional version of VMS within NT and this is what makes NT so good"< > > myth, which is wrong in several ways, keeps coming back. > >vJ > > Think of what features really set VMS apart from the competition, likeD > > clusters and volume shadowing.  Then look up what version of VMSL > > introduced these features.  Then put the fact that Cutler left after VMS" > > 1.0 in your pipe and smoke it. > >eJ > > Microsoft's marketing department probably put the initial "VMS inside"J > > spin by exaggerating Cutler's contribution to VMS, and apparently some > > people still believe it. > 2 > Sigh.  Just as you underplay his contribution.    G Obviously a rhetorical statement to counteract opposite sentiment.  :-)s   > In terms of raw kernel OS M > design, Dave is pretty much up there as one of a handful of people who havesF > designed core logic for multiple _new_ commercially viable operatingG > systems.  Yes, you can see the evolution, and the similarities in thet9 > systems that he worked on - from RSX all the way to NT.  > L > Did he invent Clusters?  No.  He didn't invent Windows either.  ClusteringM > has become a large part of VMS, but that doesn't take away from the rest ofi) > the system and people who worked on it.e > L > I've contributed to an OS.  I know people who have contributed to multipleM > ones.  There are people out there who's entire fame rests on implementing atL > single variation of UNIX.  Yeah, Dave's reputation *is* deserved - even if5 > people sometime give him too much (or sole) credit.e  E I've never said his reputation per se is not deserved, just that the rD often-repeated statement "NT is essentially VMS inside" is far from  correct.   ------------------------------   Date: 8 Jul 2003 07:55:16 -0500o; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)t Subject: Re: Rethinking  V.M.S3 Message-ID: <fuKOVVLN7skR@eisner.encompasserve.org>t  U In article <3F09DCB7.AC23377E@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:d  E > I don't know enough about cpu design to argue that. I was under therC > impression that EVERY virtual address had to be de-referenced and I > checked against page tables to see if the subject address's page was inu > memory or not.  G    While it is possible to design a CPU that took extra CPU cycles justiF    to do the virtual/physical translation, I don't think it would sellA    to well in competition to the many designs that pipeline it asn"    part of instruction/data fetch.  ; > Then page it in to the appropriate location. If the AlphatJ > is doing all that in a parallel stream in hardware, I guess that part ofE > the advantage would be minimized. Is the IA64 also doing all that? e  G    Generally the page mapping is in CPU tranlation buffer (cache) so it1G    doesn't have to get pulled in, just used, and generally the page is  6    in physical memory so it doesn't have to get paged.  E    You pay performance hits every time you reference an address who'ssB    mapping is not already covered by the translation buffer, and a.    bigger hit if you actually have to page in.  I > As far as working sets and system page tables, IIRC they are maintainedeE > to track the physical pages in memory assigned to a process. If alllG > pages were already physical, you might still need to track which page G > belonged to which process, but not which pages are physical (no one'sf. > suggesting a return to an MS DOS style OS!).  I    If you're using a virtual memory system, all that data is in the same  D    map; it map's the current process's virtual addresses to physicalD    addresses.  If you don't map virtual to physical then you have toF    have a similar map or some other mechanism to determine which pagesC    are yours.  There's still an overhead you need to handle and yousF    still need to optimize your hardware design to do it for you duringD    instruction execution.  Let me know if you think you can come up I    with a design that provides lower overhead for this than you get with o    virtual to physical mapping.t  C    I know of other designs for tracking which pages belong to which F    process, but I know of no inherint performance advantage that would'    be meaningfull to most applications.y  E    OBTW, some CPU's, like MIPS, simply don't map some addresses.  ForcG    those addresses the virtual address must be the same as the physical5E    address.  This simplifies some OS kernel issues, but I don't thinkw(    it provides a real performance boost.   ------------------------------  % Date: Tue, 08 Jul 2003 12:16:58 +0200a$ From: Michael Unger <unger@decus.de> Subject: Re: Running VMS off CDi5 Message-ID: <beea0b$47b6g$1@ID-152801.news.dfncis.de>h  ' On 08-Jul-2003 05:53, John Smith wrote:a  > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3F0A1579.6C922670@fsi.net...n >> John Smith wrote: >> > [snip]eD >> > Or watchdog process could monitor the <listener> and restart it > should >> > it die. >>/ >> What happens when the watchdog process dies?I >  > / > Damn...it's always the details, isn't it? ;-)-  H Normally a watchdog "process" is implemented in hardware *and* software:E - a hardware timer firing a non-maskable interrupt in fixed intervalseH - that hardware timer is reset be a process regularly so it doesn't fire' the interrupt under "normal" conditions   F If the watchdog process dies the entire system is reset and restarted.   Michael    --    @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system.e= And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)r   ------------------------------   Date: 8 Jul 2003 14:57:06 GMTh( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Running VMS off CDf5 Message-ID: <beem41$4crh3$1@ID-135708.news.dfncis.de>   H In article <nfrOa.94401$2ay.26712@news01.bloor.is.net.cable.rogers.com>,& 	"John Smith" <a@nonymous.com> writes: > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3F0A1579.6C922670@fsi.net...c >> John Smith wrote: >> > [snip]eD >> > Or watchdog process could monitor the <listener> and restart it > should >> > it die. >>/ >> What happens when the watchdog process dies?M >  > / > Damn...it's always the details, isn't it? ;-)h >  >   B Hmmmm....  The watchdog process watchdog process restarts it?  :-)   bill   -- nJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 8 Jul 2003 15:12:47 -0000r4 From: Doc.Cypher <Use-Author-Address-Header@[127.1]> Subject: Re: Running VMS off CDu6 Message-ID: <20030708151247.26462.qmail@nym.alias.net>  8 On 8 Jul 2003, bill@cs.uofs.edu (Bill Gunshannon) wrote:I >In article <nfrOa.94401$2ay.26712@news01.bloor.is.net.cable.rogers.com>,e' >	"John Smith" <a@nonymous.com> writes:s >> D? >> "David J. Dachtera" <djesys.nospam@fsi.net> wrote in messaget$ >> news:3F0A1579.6C922670@fsi.net... >>> John Smith wrote:i >>> > [snip]E >>> > Or watchdog process could monitor the <listener> and restart itt	 >> should>
 >>> > it die.i >>>a0 >>> What happens when the watchdog process dies? >>   >> P0 >> Damn...it's always the details, isn't it? ;-) >> i >>   >0C >Hmmmm....  The watchdog process watchdog process restarts it?  :-)3  # Sed quis custodiet ipsos Custodes?"r    aka... Who watches the watchmen?   :-)e     Doc. -- hK OpenVMS.         Eight out of ten hackers prefer *other* operating systems.    ------------------------------  + Date: Tue, 08 Jul 2003 14:38:36 +0200 (MET)n9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> 1 Subject: swapping system disks (was: RE: RDB V7.)-; Message-ID: <01KY0PJUM7GCAM7Y4A@sysdev.deutsche-boerse.com>r  H > The new VAX is a different Model and I need to get it running before I@ > transfer it. Are system disks interchangeable between models?   C As long as the disk itself will work with both systems (controller,sF maximum disk size etc), one can swap the system disk (or a copy of it)G from system to system.  In some sense, the identity of the system is on D the system disk, not in the CPU, the system box etc.  If just one isG being used at a time, then one needs to keep just a few things in mind: F system parameters might need to be set differently (i.e. run AUTOGEN),D one might need to reconfigure TCPIP if the Ethernet controller has aH different name etc.  If one plans to run both at once and there is some A sort of communication between them (cluster, TCPIP etc), then in rB addition things like the node name and related parameters must be  changed.   ------------------------------  % Date: Tue, 08 Jul 2003 14:50:38 +0100p+ From: John Laird <john@laird-towers.org.uk> 5 Subject: Re: swapping system disks (was: RE: RDB V7.)o8 Message-ID: <spilgvk0f3asi1gr71peiikheq5c0fu5pt@4ax.com>  8 On Tue, 08 Jul 2003 14:38:36 +0200 (MET), Phillip Helbig+ <HELBPHI@sysdev.deutsche-boerse.com> wrote:g  I >> The new VAX is a different Model and I need to get it running before IrA >> transfer it. Are system disks interchangeable between models? n >aD >As long as the disk itself will work with both systems (controller,G >maximum disk size etc), one can swap the system disk (or a copy of it) H >from system to system.  In some sense, the identity of the system is onE >the system disk, not in the CPU, the system box etc.  If just one is-H >being used at a time, then one needs to keep just a few things in mind:G >system parameters might need to be set differently (i.e. run AUTOGEN),uE >one might need to reconfigure TCPIP if the Ethernet controller has aDI >different name etc.  If one plans to run both at once and there is some nB >sort of communication between them (cluster, TCPIP etc), then in C >addition things like the node name and related parameters must be p	 >changed.b  K Licences may not load if the new processor requires more units than the oldeI one.  And any Ethernet device name changes will affect Decnet too.  OtherrE than that, and assuming the installed version of VMS supports the newlI processor and related hardware, VMS should boot.  It might be sensible to.K clone the system disk onto a different drive before starting this exercise.    --     John   ------------------------------   Date: 8 Jul 2003 08:27:13 -0500t; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)09 Subject: Re: Sybase Migrations External Website available43 Message-ID: <gvlIlslpP+So@eisner.encompasserve.org>k   In article <00A22836.AE98E244@SSRL.SLAC.STANFORD.EDU>, winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") writes:   M > No arguments about your actual point here, but "mano-a-mano" actually meansdP > "hand-to-hand" as in "hand-to-hand combat", not "man-to-man" so you might just2 > mean "face to face", or stick with "CEO to CEO".  F    You mean they aren't communicating via sign over a video-only link?   ------------------------------  + Date: Tue, 08 Jul 2003 11:30:28 +0200 (MET)"9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> 4 Subject: Re: SYS$SPECIFIC and SYS$COMMON not enough?; Message-ID: <01KY0IST97CIAPKEWT@sysdev.deutsche-boerse.com>a  C >   You need to answer this question yourself, and specifically fors >   your local environment.  R  @ I know what type of things are in my local environment (hobbyistF cluster), such as ALPHA-only queues for running Fortran95 code.  (OK, E this is architecture-dependent and not boot-disk dependent, but a) I eC don't do cross-architecture boots and b) I don't (yet) have enough 0E ALPHAs in the cluster that I have more than one system disk.)  I was  D looking for OTHER examples to put in the back of my mind so I don't ! forget them if I run across them.   ) >   One example would be SYSUAF.DAT quotauB >   settings for various hosts, if running parallel SYSUAF files. D >   (You need to be VERY careful here, as you must keep all UICs andE >   all usernames and all identifiers involved scrupulously matched.)   7 Right, or any differences in such files.  However, on a E share-as-much-as-possible cluster, there would be just one such file  % (and in my case off the system disk).a  L > :Is there any chance of extending definitions like SYS$SYSROOT to include 6 > :SYS$CLUSTER while retaining backward compatibility? > E >   We have something similar here in OpenVMS Engineering, and we do n8 >   create and use a CLU$COMMON root within SYS$SYSROOT: >  > $ sho log sys$sysrootu6 >    "SYS$SYSROOT" = "ddcu:[root.]" (LNM$SYSTEM_TABLE) >         = "SYS$COMMON:"m? > 1  "SYS$COMMON" = "ddcu:[root.SYSCOMMON.]" (LNM$SYSTEM_TABLE)  >         = "CLU$COMMON:" : > 2  "CLU$COMMON" = "ddcuother:[root.]" (LNM$SYSTEM_TABLE)   Wow!  H >   though we do know that various of the LP installation procedures canH >   and regularly do become somewhat confused with this structure.  SomeJ >   of the engineers have informally discussed implementing and supportingH >   this configuration, and (obviously) fixing and extending the variousK >   OpenVMS installation procedures and tools -- but another and far largerlE >   project has, um, intruded on this particular OpenVMS enhancement.(  > I suspect that everyone has their own, non-portable, probably H non-documented, bag of tricks to implement this functionality.  I think 2 official support and documentation would be great.  I >   We walk the current list of SYS$SYSROOT translations within some DCL  H >   within SYLOGICALS.COM, and we append the CLU$COMMON translation onto >   the searchlist.S  = This sounds like an interesting candidate for SYS$EXAMPLES.  -  H Obviously, code which uses the search list as a search list should work D with no modifications, but there is probably some code around which G assumes that there are only two translations (and what they look like).   ? I currently have SYS$SPECIFIC:[SYSMGR]SYSTARTUP_VMS.COM do somenI node-dependent stuff then execute SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM.   G Of course, normal behaviour of @SYS$MANAGER:SYSTARTUP_VMS.COM would be tH to execute ONLY the first file found.  A qualifier to "@" would be nice G which would allow one to specify how many files in the search list are d0 to be executed (default, of course, would be 1).   ------------------------------  + Date: Tue, 08 Jul 2003 11:51:54 +0200 (MET)r9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> 4 Subject: Re: SYS$SPECIFIC and SYS$COMMON not enough?; Message-ID: <01KY0J7Y1MZSAPKEWT@sysdev.deutsche-boerse.com>-  K > >What are some real-world examples of stuff which is common to all nodes vJ > >which boot from a common system disk, but not common to all nodes in a 8 > >cluster, even in a share-as-much-as-possible cluster? > M > One use of a cluster is testing new system SW.  You can make a copy of your K > main system disk and upgrade the software there (say, a VMS patch).  ThentM > boot one system using that disk and see how it works, while the rest of the-N > cluster does your production work using the old system without the upgrade. K > In that case, any files affected by the upgrade would/should be different  > for the test node.    G Right.  I should have explicitly excluded multiple versions of VMS and c multiple architectures.b  : > The audit journal file is another example.  It's in eachG > SYS$COMMON:[SYSMGR].  Why does it need to be on the system disk?  TheaH > system might need to access it at any time, and the system disk is the< > only disk which is (or needs to be) guaranteed available.   0 Those are the kinds of examples I'm looking for.  G > You can rig all kinds of stuff.  I'm sure there have been discussions B > here about having SYS$COMMON and SYS$SPECIFIC point to differentI > devices.  The "VMSCluster Systems for OpenVMS" manual has a list of ~10eJ > data files which it recommends be migrated off the system disk if you're/ > using multiple system disks in your cluster. t  A In newer versions of VMS, it's in SYLOGICALS.TEMPLATE, see below.e   Note first two mistakes:   (The file locationslL $! shown below use search list logical names such as SYS$SYSTEM: for clarityN $! -- be aware that the files actually reside in the system disk system-commonM $! root, and not in the system-specific root.  eg: the common files reside inaN $! SYS$SYSROOT:[SYSEXE], in the case of any files accessable via SYS$SYSTEM:.)  F First, SYS$SYSROOT:[SYSEXE] should obviously be SYS$COMMON:[SYSEXE].  A Second, I believe "accessible" is more correct than "accessable".-  F (In any case, I would not use SYS$SYSROOT, since it is not clear what G is meant: SYS$SYSROOT as a search list of SYS$SPECIFIC and SYS$COMMON, wF or SYS$SYSROOT as the label for SYS$SPECIFIC in a DIRECTORY command?  ? (Add to this the confusion that the second, but not the first, BD translation of SYS$SYSROOT is concealed; it would be SO NICE to see ( SYS$SPECIFIC in the directory listing!))  G $! Define the Logical Names Associated With OpenVMS Cluster Operations:  $! $!E $! This section should include any site specific VMScluster core filetH $! definitions.  (These logical name definitions were previously defined, $! in the site-specific file SYENVIRON.COM.) $!G $! Site-specific VMScluster core file definitions are required whenever.M $! there is more than one system disk present in the VMScluster, and whenevertJ $! the standard file naming and/or file location conventions are not used. $!M $! The user should include definitions for the devices, directories, and fileKN $! names for the various core VMScluster and DECnet files, typically includingL $! all of the logical names and file names shown below.  (The file locationsL $! shown below use search list logical names such as SYS$SYSTEM: for clarityN $! -- be aware that the files actually reside in the system disk system-commonM $! root, and not in the system-specific root.  eg: the common files reside in N $! SYS$SYSROOT:[SYSEXE], in the case of any files accessable via SYS$SYSTEM:.) $!L $! DEFINE/SYSTEM/EXECUTIVE SYSUAF                      SYS$SYSTEM:SYSUAF.DATO $! DEFINE/SYSTEM/EXECUTIVE SYSUAFALT                   SYS$SYSTEM:SYSUAFALT.DATaL $! DEFINE/SYSTEM/EXECUTIVE SYSALF                      SYS$SYSTEM:SYSALF.DATP $! DEFINE/SYSTEM/EXECUTIVE RIGHTSLIST                  SYS$SYSTEM:RIGHTSLIST.DATN $! DEFINE/SYSTEM/EXECUTIVE NETPROXY                    SYS$SYSTEM:NETPROXY.DATO $! DEFINE/SYSTEM/EXECUTIVE NET$PROXY                   SYS$SYSTEM:NET$PROXY.DATwO $! DEFINE/SYSTEM/EXECUTIVE NETOBJECT                   SYS$SYSTEM:NETOBJECT.DATyT $! DEFINE/SYSTEM/EXECUTIVE NETNODE_REMOTE              SYS$SYSTEM:NETNODE_REMOTE.DATQ $! DEFINE/SYSTEM/EXECUTIVE LMF$LICENSE                 SYS$SYSTEM:LMF$LICENSE.LDB3V $! DEFINE/SYSTEM/EXECUTIVE VMSMAIL_PROFILE             SYS$SYSTEM:VMSMAIL_PROFILE.DATAQ $! DEFINE/SYSTEM/EXECUTIVE VMS$OBJECTS                 SYS$SYSTEM:VMS$OBJECTS.DATwW $! DEFINE/SYSTEM/EXECUTIVE VMS$AUDIT_SERVER            SYS$MANAGER:VMS$AUDIT_SERVER.DAT [ $! DEFINE/SYSTEM/EXECUTIVE VMS$PASSWORD_HISTORY        SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATAO_ $! DEFINE/SYSTEM/EXECUTIVE VMS$PASSWORD_DICTIONARY     SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA0U $! DEFINE/SYSTEM/EXECUTIVE NETNODE_UPDATE              SYS$MANAGER:NETNODE_UPDATE.COMsZ $! DEFINE/SYSTEM/EXECUTIVE VMS$PASSWORD_POLICY         SYS$LIBRARY:VMS$PASSWORD_POLICY.EXEW $! DEFINE/SYSTEM/EXECUTIVE LAN$NODE_DATABASE           SYS$SYSTEM:LAN$NODE_DATABASE.DAT   B The comments say "typically including".  Who can add to this list?   ------------------------------  # Date: Tue, 08 Jul 2003 12:28:52 GMTi) From: Patrick Young <P.Young@unsw.EDU.AU>14 Subject: Re: SYS$SPECIFIC and SYS$COMMON not enough?; Message-ID: <8OyOa.577$TX6.7651@news-server.bigpond.net.au>i   Hoff Hoffman wrote:'y > In article <01KXZKP04MZUAM7Y4A@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:iK > :What are some real-world examples of stuff which is common to all nodes mJ > :which boot from a common system disk, but not common to all nodes in a 8 > :cluster, even in a share-as-much-as-possible cluster? > C >   You need to answer this question yourself, and specifically formB >   your local environment.  One example would be SYSUAF.DAT quotaB >   settings for various hosts, if running parallel SYSUAF files. D >   (You need to be VERY careful here, as you must keep all UICs andE >   all usernames and all identifiers involved scrupulously matched.)  > C >   I am aware of nothing here, however, that can't also be handledpC >   "directly" with per-file logical name redirections.  SYSUAF cane' >   certainly be redirected, of course.v > L > :Is there any chance of extending definitions like SYS$SYSROOT to include 6 > :SYS$CLUSTER while retaining backward compatibility? > E >   We have something similar here in OpenVMS Engineering, and we do s8 >   create and use a CLU$COMMON root within SYS$SYSROOT: >  > $ sho log sys$sysrootE6 >    "SYS$SYSROOT" = "ddcu:[root.]" (LNM$SYSTEM_TABLE) >         = "SYS$COMMON:"s? > 1  "SYS$COMMON" = "ddcu:[root.SYSCOMMON.]" (LNM$SYSTEM_TABLE)o >         = "CLU$COMMON:"o: > 2  "CLU$COMMON" = "ddcuother:[root.]" (LNM$SYSTEM_TABLE) > H >   though we do know that various of the LP installation procedures canH >   and regularly do become somewhat confused with this structure.  SomeJ >   of the engineers have informally discussed implementing and supportingH >   this configuration, and (obviously) fixing and extending the various  C How weird - we did this as a different excercise to do upgrades offlF line on the read only stuff, and swap it back in quickly. We also haveC a third party product root to keep our own/third party stuff out ofe; SYS$SYSDEVICE:[VMS$COMMON...] tree, like a "/usr/local...".e   H sh lo sys$sysroot@8     "SYS$SYSROOT" = "$9$DKA0:[SYS0.]" (LNM$SYSTEM_TABLE)          = "SYS$COMMON:"2 1  "SYS$COMMON" = "CLU$COMMON:" (LNM$SYSTEM_TABLE)          = "VMS$COMMON:"          = "OUR$COMMON:"@ 2  "CLU$COMMON" = "$9$DKA0:[SYS0.CLUCOMMON.]" (LNM$SYSTEM_TABLE)@ 2  "VMS$COMMON" = "$9$DKA0:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)@ 2  "OUR$COMMON" = "$9$DKA0:[SYS0.OURCOMMON.]" (LNM$SYSTEM_TABLE)    <   $!      R.P. Young                             26-Jun-1991   $!<   $!     Added cluster support to our environment by  making<   $!     SYS$COMMON a search list, by including a CLU$COMMON;   $!     and moving OUR$COMMON from SYS$SYSROOT search listt9   $!     to the SYS$COMMON search list. The CLU$COMMON is-:   $!     required for non buildable cluster specific files   $!     such As SYSUAF.DAT.    @ It does confuse PCSI - you generally end up with directories and@ associated files created in SYS$SYSDEVICE:[SYSLIB], etc. This is' good for on the go Mozilla upgrades :-)   I >   We walk the current list of SYS$SYSROOT translations within some DCL pH >   within SYLOGICALS.COM, and we append the CLU$COMMON translation onto >   the searchlist.    We used SYCONFIG.h   ------------------------------  + Date: Tue, 08 Jul 2003 14:55:24 +0200 (MET)s9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> 4 Subject: Re: SYS$SPECIFIC and SYS$COMMON not enough?; Message-ID: <01KY0PUMQ2IQAM7Y4A@sysdev.deutsche-boerse.com>s  E > How weird - we did this as a different excercise to do upgrades offnH > line on the read only stuff, and swap it back in quickly. We also haveE > a third party product root to keep our own/third party stuff out of = > SYS$SYSDEVICE:[VMS$COMMON...] tree, like a "/usr/local...".v >  > H sh lo sys$sysrootj: >     "SYS$SYSROOT" = "$9$DKA0:[SYS0.]" (LNM$SYSTEM_TABLE) >          = "SYS$COMMON:"4 > 1  "SYS$COMMON" = "CLU$COMMON:" (LNM$SYSTEM_TABLE) >          = "VMS$COMMON:" >          = "OUR$COMMON:"B > 2  "CLU$COMMON" = "$9$DKA0:[SYS0.CLUCOMMON.]" (LNM$SYSTEM_TABLE)B > 2  "VMS$COMMON" = "$9$DKA0:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)B > 2  "OUR$COMMON" = "$9$DKA0:[SYS0.OURCOMMON.]" (LNM$SYSTEM_TABLE) >  > > >   $!      R.P. Young                             26-Jun-1991 >   $!> >   $!     Added cluster support to our environment by  making> >   $!     SYS$COMMON a search list, by including a CLU$COMMON= >   $!     and moving OUR$COMMON from SYS$SYSROOT search list ; >   $!     to the SYS$COMMON search list. The CLU$COMMON ise< >   $!     required for non buildable cluster specific files >   $!     such As SYSUAF.DAT.  E Some questions:  Why CLU$COMMON before VMS$COMMON in the search list?dH Logically, I would think one should first search in SYS$SPECIFIC (as youF do), then in VMS$COMMON, then CLU$COMMON.  Wouldn't it be more logical> to have CLU$COMMON located on a non-system disk?  What was theF motivation for moving CLU$COMMON from the SYS$SYSROOT search list to aC VMS$COMMON search list?  Wouldn't it also be better to do away withs@ OUR$COMMON altogether and put third-party stuff on a completely : different disk?  (This is more clearly a matter of taste.)   ------------------------------  $ Date: Tue, 8 Jul 2003 09:20:44 +0100* From: "John Travell" <john@travell.uk.net>A Subject: Re: VAX Vup Listing not available on HP - where is it ??i5 Message-ID: <bedv0l$42l8m$1@ID-120847.news.dfncis.de>t  4 "Carl Perkins" <carl@gerg.tamu.edu> wrote in message& news:7JUL200316100684@gerg.tamu.edu...: > kuhrt@nospammy.encompasserve.org (Marty Kuhrt) writes...F > }In article <01KXV0FW92HUAPKEWT@sysdev.deutsche-boerse.com>, Phillip3 Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:nE > }>> As a BTW, I've got a file CALCULATE_VUPS.COM which gave me verye accurateI > }>> answers on a variety of VAX machines that I once had.  And seems toe giveK > }>> a good "VUPS" for our Alpha machines where we have measured CPU timesu in > }>> our applications.e > }>>v > } C > }That's the CALCULATE_VUPS.COM that comes with Diskeeper, written0> > }by Rick Cadruvi (IIRC).   If you have DK you can find it in >- > E > The most interesting part to me is that the thing drives the systemaE > at around 27 - 28 percent kernel mode and 10 - 12 percent executivee+ > mode (the rest going to supervisor mode).  >   > It would, The DCL command interpreter runs in supervisor mode.? The only user mode stuff you would see would be invoked images. H Things like f$getsyi call sys$getsyi and do much of their work in Kernel mode.      -- John Travell  VMS crashdump expertise for hire john@jomatech.como +44-(0)23-92552229 http://www.jomatech.com/       ---e& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.493 / Virus Database: 292 - Release Date: 25/06/2003d   ------------------------------  $ Date: Tue, 8 Jul 2003 07:11:26 -0700. From: "David D Miller" <ddmiller@raytheon.com>A Subject: Re: VAX Vup Listing not available on HP - where is it ??iF Message-ID: <OFA8424CAD.A2F2B76D-ON07256D5D.004D8170@rsc.raytheon.com>   Folks:  H I thought the VUP information would be a nice addition to Baldwin's 2nd=  H edition  (which I've been working on.)  So I contacted Paul Hardy about=  it.H The following is his latest effort.  Sorry about the format.   The usua= l- disclaimers apply.  3 If you'd like an HTML version, contact me off-line..   dave.j    % VMS CPU Model Summary (12th May 1998)xH The following table tries to summarises the whole publicly known Digita= l/H VAX and Alpha model range by CPU type, divided into processor families,=  and  H then by subtype, giving approximate chronological order. The informatio= ne	 given is: C =B7       The top byte of the SID in hex (containing the CPU type),i. =B7       Processor subtype (XCPU or SYSTYPE).! =B7       Processor ID for VAXes.t& =B7       Clock speed in MHz for AXPs.> =B7       Approximate speed, relative to a nominal VAX-11/780:% =B7       in VUPS for early machines,e7 =B7       in SPECmark89 (S) for later VAX workstations, 0 =B7       in SPECint92 & SPECfp92 for most AXPs,@ =B7       scaled up SPECint95*38 & SPECfp95*42 for later Alphas,H =B7       scaled up SPECint_rate_base*5.2 & SPECfp_rate_base*5.0 for ev= en
 later Alphas.lH =B7       Main I/O bus type (U=3DUNIBUS, M=3DMASSBUS, C=3DCI, Q=3DQBUS,=  B=3DBI, D=3DDSSI,  H X=3DXMI, T=3DTurbochannel, F=3DFuturebus+, S=3DSCSI, E=3DEISA, P=3DPCI)= .s =B7       Model names. =B7       Nickname.-H Information is from publicly available sources such as DEC brochures an= doF press releases, together with the description of SYS$GETSYI in the VMSH documentation, and from $PRDEF, $VAXDEF, and $ALPHADEF in the system ma= croe@ library. This is supplemented with information from USENET groupF comp.os.vms. Models thought to be current are marked by a leading `*'.H This list is not an official publication of Laser-Scan - ask DEC if you=  H want confirmed figures! In the fast changing world of computer hardware= ,xH its probably out of date when written. However, please let me know of a= ny inaccuracies or omissions. --- H Paul Hardy (PGH), Product Manager (former Chief Programmer), Laser-Scan=   Ltd,5 Science Park, Milton Rd, CAMBRIDGE, CB4 4FY, England.r> Tel: (+44) (0)1223 420414; Fax: 420044, Email: PAUL@LSL.CO.UK.   Author: Paul Hardy Go UP to Laser-Scan Home Pagee   VAX CPUs& SID X Id Speed Bus Model Name Nickname 700 series (1977)a" 01 - 780 1.0 U,M,C VAX-11/780 Star# 01 - 780 1.8 U,M,C VAX-11/782 Atlase' 01 - 780 3.5 U,M,C VAX-11/784 (VAXimus)b' 01 - 780 1.5 U,M,C VAX-11/785 Superstaru( 02 - 750 0.6 U,M,C VAX-11/750, 751 Comet* 03 - 730 0.3 U VAX-11/730, 725 Nebula, LCN" 04 - 790 4.0 U,M,C VAX 8600, Venus' 04 - 790 7.0 U,M,C VAX 8650 Morningstari 8000 series (1986)5 05 - 8SS 0.9-2 B,C VAX 8200, 8300, 8250, 8350 Scorpiob' 05 - 8SS 0.9-2 B,C VAXstation 8000 Lynxw  06 - 8NN 3 B,C VAX 8500 Flounder( 06 - 8NN 4/6 B,C VAX 8530, 8550 Skipjack) 06 - 8NN 6/12 B,C VAX 8700, 8800 Nautiluss# MicroVAX I (1984) SID =3D 117440512 0 07 - UV1 0.3 Q MicroVAX I, VAXstation I Seahorse+ MicroVAX II series (1985) SID =3D 134217728o2 08 1 UV2 0.9 Q MicroVAX II,VAXstation II Mayflower( 08 1 UV2 0.9 Q VAXstation II/GPX Caylith( 08 4 410 0.9 none MicroVAX 2000 TeamMate) 08 4 410 0.9 none VAXstation 2000 VAXstare) 08 ? UV2 0.9-28 ?? MicroVAX M31 Andromedae) CVAX chip series (1987) SID =3D 167772160/* 0A 1 650 2.8 Q MicroVAX 3500, 3600 Mayfair0 0A 1 65D 2.8 Q VAXstation 3200, 3500 Mayfair/GPX/ 0A 1 640 2.4 Q,D MicroVAX 3300, 3400 Mayfair II . 0A 1 655 3.8 Q MicroVAX 3800, 3900 Mayfair III1 0A 2 9CC 2.8 X,B,C VAX 6000 model 210 Calypso/XCP_1 0A 2 9CC 3.8 X,B,C VAX 6000 model 310 Calypso/XCPn, 0A 3 60 3-10 Q VAXstation 3520, 3540 Firefox1 0A 4 420 2.8 S VAXstation 3100 models 30, 40 PVAX-6 0A 4 420 2.4 S MicroVAX 3100 models 10, 20 Teammate II8 0A 4 420 3.5 S MicroVAX 3100 models 10e, 20e Teammate II7 0A 4 420 3.8 S VAXstation 3100 models 38, 48 PVAX rev#7r' * 0A 7 510 2.4 D VAXft model 110 Cirruse% 0A 7 520 3.8 D VAXft model 310 Cirruss* Rigel chip series (1990) SID =3D 184549376( 0B 1 670 8.0 Q,D VAX 4000 model 300 Pele6 0B 2 9RR 7-36 X,B,C VAX 6000 model 410-460 Calypso/XRP/ 0B 4 43 7.6 S VAXstation 3100 model 76 RigelMAX ' 0B 4 43? 7? S MicroVAX 3100 model 40 ??i( Aquarius series (1990) SID =3D 2348810249 0E - 9AR 40-157 X,B,C VAX 9000 models 210, 410-440 Ariduso4 0E - 9AQ 40-157 X,B VAX 9000 models 400-800 Aquarius) Polarstar series (1988) SID =3D 285212672d, 11 - 8PS 6-22 B,C VAX 8810 to 8840 Polarstar+ Mariah chip series (1991) SID =3D 301989888 7 12 2 1202 13-58 XBCD VAX 6000 model 510-560 Calypso/XMPl/ 12 4 46 12 T,S VAXstation 4000 model 60 PMariahD. 12 4 46 12 S MicroVAX 3100 model 80 Waverley/M5 * 12 4 46 16 S MicroVAX 3100 model 85, 88 Waverley/M+r) NVAX chip series (1991) SID =3D 318767104s( 13 1 690 16 Q,D VAX 4000 model 400 Omega0 13 1 69D 24 Q,D VAX 4000 model 500, 500A Omega/N, 13 1 69D 32 Q,D VAX 4000 model 505A Omega/N+3 13 1 1303 24 Q,D VAX 4000 model 100, 100A Cheetah-Qs/ 13 1 1303 32 Q,D VAX 4000 model 105A Cheetah-Q+n1 13 1 1303 ??? Q,D VAX 4000 model 106A Cheetah-Q++"1 * 13 1 1303 38 Q,D VAX 4000 model 108 Cheetah-Q++ 1 13 1 700 32 Q,D VAX 4000 model 600, 600A Omega/N+r* 13 1 700 40 Q,D VAX 4000 model 700A Legacy- * 13 1 700 45 Q,D VAX 4000 model 705A Legacy+d5 13 2 1302 32-150 XBDC VAX 6000 models 610-660 Neptunee2 13 4 49 32.8 S T,S VAXstation 4000 model 90 Cougar4 13 4 49 38.5 S T,S VAXstation 4000 model 90A Cougar+5 * 13 4 49 46 S? T,S VAXstation 4000 model 96 Cougar++-+ 13 4 49 24 S MicroVAX 3100 model 90 Cheetah , 13 4 49 32 S MicroVAX 3100 model 95 Cheetah+3 * 13 4 49 38 S MicroVAX 3100 model 96, 98 Cheetah++:) * 13 7 600 30 D VAXft model 810 JetstreamY( SOC chip series (1991) SID =3D 335544320, 14 1 660 5.0 Q,D VAX 4000 model 200 Spitfire9 14 4 440 6.2 S S VAXstation 4000 VLC (model 30) PVAX2/VLC 5 14 4 440 5.0 S MicroVAX 3100 models 30, 40 Waverley/S - 14 7 550 6.0 D VAXft model 410, 610 Cirrus IIc* NVAX+ chip series (1991) SID =3D 3858759689 17 3 1701 35-120 X,C,D VAX 7000 models 610-640 Laser/Neonv6 17 3 1701 35-120 X,C,D VAX 10000 models 610-640 Blazer* NVAX5 chip series (1994) SID =3D ?????????< 17 3 1701 50-250 X,C,D VAX 7000 models 710-760 Laser/Krypton? * 17 3 1701 60-300 X,C,D VAX 7000 models 810-860 Laser/Krypton+n  
 Alpha CPUs* SID S Clock SPEC92 Bus Model Name Nickname2 EV4 (21064) chip series (1992) SID =3D -2147483648. 80 2 160 95/138 F,D,S DEC 4000 model 610 Cobra0 * 80 2 190 122/185 F,D,S DEC 4000 model 710 Fang4 80 3 180 103/176 X,C,D DEC 7000 model 610 Laser/Ruby5 80 3 200 133/200 X,C,D DEC 7000 model 610 Laser/Ruby+c6 80 3 200 107/200 X,C,D DEC 10000 model 610 Blazer/Ruby5 80 4 150 84/128 T,S DEC 3000 model 500W or S Flamingoe9 80 4 200 130/184 T,S DEC 3000 model 800W or S Flamingo II 6 80 4 133 75/112 T,S DEC 3000 model 400W or S Sandpiper8 80 4 175 114/162 T,S DEC 3000 model 600W or S Sandpiper+1 80 4 200 111/164 T,S DEC 3000 model 500X Hot Pinkg. 80 4 150 81/110 T,S DEC 3000 model 300 Pelican+ 80 4 100 46/63 S DEC 3000 model 300L Pelicam- 80 4 125 68/77 S DEC 3000 model 300LX Pelica+r0 80 4 175 90/102 T,S DEC 3000 model 300X Pelican+6 80 6 150 81/110 S,E DEC 2000 model 300 (pc/150) Jensen2 80 9 200 124/160 P,S,E DEC 2100 model A500MP Sable8 80 9 200 127/161 P,S,E AlphaServer 2000 4/200 Demi-Sable4 80 ? 200 136/177 P,S,E AlphaServer 1000 4/200 Mikasa5 80 ? 166 116/135 P,S,E AlphaStation 200 4/166 Mustangt. 80 ? 100 75/95 P,S,E AlphaStation 200 4/100 ??6 80 ? 166 117/140 P,S,E AlphaServer 400 4/166 Mustang S4 EV45 (21064A) chip series (1994) SID =3D -21474836484 80 4 225 163/231 T,S DEC 3000 model 700W Sandpiper459 80 4 275 189/264 T,S DEC 3000 model 900W or S Flamingo 45 6 80 3 275 201/293 X,C,D DEC 7000 model 710 Laser/Ruby455 80 ? 233 158/184 P,S,E AlphaStation 200 4/233 Mustanga4 80 ? 233 158/184 P,S,E AlphaStation 400 4/233 Mikasa: 80 9 275 181/260 P,S,E AlphaServer 2000 4/275 Demi-Sable455 80 9 275 158/184 P,S,E AlphaServer 2100 4/233 Sable45 5 80 9 275 200/292 P,S,E AlphaServer 2100 4/275 Sable45c4 80 ? 233 165/223 P,S,E AlphaServer 1000 4/233 Mikasa4 80 ? 266 199/263 P,S,E AlphaServer 1000 4/266 Mikasa1 * 80 ? 266 199/263 P,S,E AlphaServer 300 4/266 ??o0 80 ? 266 199/263 P,S,E AlphaStation 250 4/266 ??. 80 ? 233 180/230 P,S,E AlphaStation 255/233 ??. 80 ? 300 215/295 P,S,E AlphaStation 255/300 ??2 EV5 (21164) chip series (1995) SID =3D -21474836481 80 3 300 336/507 XPFCSE AlphaServer 8400 5/300 ??a1 80 3 350 432/602 XPFCSE AlphaServer 8400 5/300 ??m0 80 3 300 336/507 P,S,E AlphaServer 8200 5/300 ??9 80 3 250 277/410 P,S,E AlphaServer 2000 5/250 Demi-Sable5c7 80 3 250 277/410 P,S,E AlphaServer 2100 5/250 Sable EV5a1 * 80 ? 400 *12/17 P,S,E AlphaServer 4100 5/400 ??o1 * 80 ? 466 *14/19 P,S,E AlphaServer 4100 5/466 ??m1 * 80 ? 533 *17/22 P,S,E AlphaServer 4100 5/533 ??s1 * 80 ? 400 *12/17 P,S,E AlphaServer 1200 5/400 ??i1 * 80 ? 533 *17/22 P,S,E AlphaServer 1200 5/533 ??e0 * 80 3 333 *10/13 P,S,E AlphaServer 800 5/333 ??0 * 80 3 400 *10/13 P,S,E AlphaServer 800 5/400 ??0 * 80 3 500 *10/13 P,S,E AlphaServer 800 5/500 ??0 80 ? 266 288/428 P,S,E AlphaStation 600 5/266 ??0 80 ? 333 362/554 P,S,E AlphaStation 600 5/333 ??. 80 ? 266 280/400 P,S,E AlphaStation 500/266 ??. 80 ? 333 350/500 P,S,E AlphaStation 500/333 ??4 EV56 (21164A) chip series (1996) SID =3D -2147483648/ 80 3 440 *14/17 P,S,E AlphaServer 8200 5/440 ??m/ 80 3 625 *18/21 P,S,E AlphaServer 8200 5/625 ??h0 80 3 440 *14/17 XPFCSE AlphaServer 8400 5/440 ??0 80 3 625 *18/21 XPFCSE AlphaServer 8400 5/440 ??1 80 ? 400 420/600 P,S,E AlphaStation 500/400 Brett 1 80 ? 500 570/840 P,S,E AlphaStation 500/500 Bretth+ 80 ? 433 523/790 P,S,E Personal WS 433au ??r+ 80 ? 500 590/842 P,S,E Personal WS 500au ??i+ 80 ? 600 691/930 P,S,E Personal WS 600au ??n   Last modified: 12th May 1998       =    ------------------------------  % Date: Tue, 08 Jul 2003 09:21:12 +0100l* From: Nic Clews <sendspamhere@[127.0.0.1]>> Subject: Re: vms security model - does it still exist on IA64?' Message-ID: <bedv3g$6jp$2@lore.csc.com>w   Hoff Hoffman wrote:  >    > G >   Extra credit question: which VAX implementation had five modes. :-)r  E I've not personally used it, but we have people that live and breathet it.y   VAXeln ?   --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot coma   ------------------------------  # Date: Tue, 08 Jul 2003 09:44:50 GMT:) From: bob smith <sfmc68@bellatlantic.net>c> Subject: Re: vms security model - does it still exist on IA64?8 Message-ID: <mowOa.63373$n%5.61267@nwrddc02.gnilink.net>   Hoff Hoffman wrote:   H >   Extra credit question: which VAX implementation had five modes. :-)  >  > P >  ---------------------------- #include <rtfaq.h> -----------------------------M >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqpP >  --------------------------- pure personal opinion ---------------------------G >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com* > & I believe it is something called SEVMS boba   ------------------------------  % Date: Tue, 08 Jul 2003 12:48:02 +0200r$ From: Michael Unger <unger@decus.de>> Subject: Re: vms security model - does it still exist on IA64?5 Message-ID: <beea0c$47b6g$2@ID-152801.news.dfncis.de>h  ) On 08-Jul-2003 05:05, Hoff Hoffman wrote:y  \ > In article <3F0A2485.A129490@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: > :bob smith wrote:o >  > [...]p > L > :> The IA64 does seem to have some hardware capabilities but the area I amF > :> interested in is what was changed with ref to the security model. > :RC > :If you mean does it still use the four modes: kernel, executive,.J > :supervisor and user; and the four classes: System, Owner, Group, World;C > :and the ACLs and rights identifiers; and intrusion detection anda% > :evasion, then I would expect so...a >  > [...]0 > I >   Will all code port across transparently?  Probably not -- most of thegI >   "fun" I am finding involves code that explicitly tests for VAX or for.K >   Alpha as part of selecting something -- and particularly then with the  D >   path selected when the code finds neither platform matches.  :-)  F Which is *very* similar to a lot of websites' code which tests for the@ browser type used and, if it isn't "Netscape", then it *must* be@ "Internet Exploder" (and completely ignoring other browsers like Mozilla) ...   > H >   Extra credit question: which VAX implementation had five modes. :-)     VAXft? (Just a guess of course!)   >  > [...]0   Michael    --    @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system.a= And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)t   ------------------------------   Date: 8 Jul 2003 06:19:10 -0500r- From: Kilgallen@SpamCop.net (Larry Kilgallen)s> Subject: Re: vms security model - does it still exist on IA64?3 Message-ID: <ufa0AGTFq3h+@eisner.encompasserve.org>   d In article <mowOa.63373$n%5.61267@nwrddc02.gnilink.net>, bob smith <sfmc68@bellatlantic.net> writes: >  >  > Hoff Hoffman wrote:> > I >>   Extra credit question: which VAX implementation had five modes. :-) s >> y >>  Q >>  ---------------------------- #include <rtfaq.h> -----------------------------rN >>     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqQ >>  --------------------------- pure personal opinion ---------------------------kH >>         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com >> e( > I believe it is something called SEVMS  L More likely the SVS modification to certain microcode allowing A1 operation.K That was dropped just after it reached field test because of a lack of realhK market interest.  The US government department that thought it was great tonK have such a thing turned out to have an entirely different opinion than the J US government departments that actually bought computers.  In fact, it wasL finer than that, as even the department pushing A1 has a parent organization- that prefers "system high" for their own use.t  J SEVMS is a special version of VMS, and thus is not a "VAX implementation".   ------------------------------   Date: 8 Jul 2003 08:16:46 -0500n; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)t> Subject: Re: vms security model - does it still exist on IA64?3 Message-ID: <NjthRpBR92gQ@eisner.encompasserve.org>   [ In article <3F09F67F.1070002@bellatlantic.net>, bob smith <sfmc68@bellatlantic.net> writes:T( > Subject says it all, any info on this? > bobd      VMS is VMS is VMS ...   ------------------------------   Date: 8 Jul 2003 08:19:14 -05000; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)r> Subject: Re: vms security model - does it still exist on IA64?3 Message-ID: <fmgiL8Cs$Pas@eisner.encompasserve.org>a  T In article <bedv3g$6jp$2@lore.csc.com>, Nic Clews <sendspamhere@[127.0.0.1]> writes: > Hoff Hoffman wrote:g >> > >  >> VH >>   Extra credit question: which VAX implementation had five modes. :-) > G > I've not personally used it, but we have people that live and breathe  > it.s > 
 > VAXeln ?  F    VAXeln is an OS, not a VAX.  It only required 2 modes and IIRC some8    stripped down VAX chips were made that provided that.   ------------------------------   Date: 8 Jul 2003 08:24:22 -0500n; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)t> Subject: Re: vms security model - does it still exist on IA64?3 Message-ID: <mAgoBT6CFwlj@eisner.encompasserve.org>   W In article <byqOa.4070$Ub.2394@news.cpqcorp.net>, hoff@hp.nospam (Hoff Hoffman) writes:f > H >   Extra credit question: which VAX implementation had five modes. :-)   D    You want to count compatability mode on 11/780?  IIRC the AME was    only place CHMU was needed.  C    The biggest problem I had with the AME was it was expecting .EXEn<    files and the RSX task builder knew they were .TSK files.  4    Or are you looking for console mode on an 11/750?   ------------------------------   Date: 8 Jul 2003 08:25:20 -0500h; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)m> Subject: Re: vms security model - does it still exist on IA64?3 Message-ID: <b7aTdEKsmS1V@eisner.encompasserve.org>   d In article <mowOa.63373$n%5.61267@nwrddc02.gnilink.net>, bob smith <sfmc68@bellatlantic.net> writes: >  >  > Hoff Hoffman wrote:c > I >>   Extra credit question: which VAX implementation had five modes. :-) @  ( > I believe it is something called SEVMS  B    Hoff sure looks to be asking about hardware, SEVMS is software.   ------------------------------   Date: 8 Jul 2003 09:36:10 +0100aK From: pmoreau@ath.cena.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.68.40)n/ Subject: [Mozilla 1.4] bug in pref-advanced.xuls! Message-ID: <7X9JtSokaT9v@sinead>a   Hi,   A I've found a small bug in Mozilla 1.4  VMS distribution. The main 8 screen of Preferences - Advanced is broken and displays:  #  XML Parsing Error: not well-formed ?  Location: chrome://communicator/content/pref/pref-advanced.xule  Line Number 161, Column 3:I    PK   --^  O The problems seems to be into SYS$COMMON:[MOZILLA.CHROME]COMM.JAR;1 file, where J is pref-advanced.xul (and is broken). May be a problem when making the VMS distribution ?  O The main Preferences - Advanced sceer is used to specify whether or not Java is)M used and to specify the anonymous ftp login username (generally user@domain).cO You can set manually these preferences into your PREFS.JS file in your _MOZILLAr
 directory.  ( Otherwise, 1.4 works well (on VMS 7.2-1)   Patrickh --O ===============================================================================tN pmoreau@ath.cena.fr  (CENA)      ______      ___   _          (Patrick MOREAU)4 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================n   ------------------------------  $ Date: Tue, 8 Jul 2003 09:40:17 +0100* From: "Richard Brodie" <R.Brodie@rl.ac.uk>3 Subject: Re: [Mozilla 1.4] bug in pref-advanced.xulo, Message-ID: <bee01i$1130@newton.cc.rl.ac.uk>  X "Patrick MOREAU, CENA Athis, Tel: 01.69.57.68.40" <pmoreau@ath.cena.fr> wrote in message news:7X9JtSokaT9v@sinead...M  C > I've found a small bug in Mozilla 1.4  VMS distribution. The main : > screen of Preferences - Advanced is broken and displays:   Tracking information:L2 http://bugzilla.mozilla.org/show_bug.cgi?id=211757   ------------------------------  # Date: Tue, 08 Jul 2003 14:57:06 GMTc' From: Colin Blake <colin@theblakes.com>f3 Subject: Re: [Mozilla 1.4] bug in pref-advanced.xul : Message-ID: <6ZAOa.114$5o5.157479@news1.news.adelphia.net>  6 Patrick MOREAU, CENA Athis, Tel: 01.69.57.68.40 wrote:   >Hi, > B >I've found a small bug in Mozilla 1.4  VMS distribution. The main9 >screen of Preferences - Advanced is broken and displays:e >y$ > XML Parsing Error: not well-formed@ > Location: chrome://communicator/content/pref/pref-advanced.xul > Line Number 161, Column 3: >dH Broken zip file. A new kit has just been posted to mozilla.org. The kit G and updated release notes should be on the OpenVMS server tonight. The eK only change is an unbroken zip file and a change to the build ident string.a   ------------------------------   End of INFO-VAX 2003.374 ************************