1 INFO-VAX	Wed, 09 Jul 2003	Volume 2003 : Issue 376       Contents:5 Re: "Advanced server" and Samba Domain Authentication 5 Re: "Advanced server" and Samba Domain Authentication ; 2 networkcards in an alpha800 server using multinet Problem ? Re: 2 networkcards in an alpha800 server using multinet Problem  Re: APC UPS control for VMS  Compiled Applications  Re: Compiled Applications  Re: Compiled Applications  Re: Compiled Applications  RE: Compiled Applications  Re: Compiled Applications  Re: Compiled Applications  RE: Compiled Applications  Re: Compiled Applications  Re: Cpu panic randomN Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful Performance Re: DHCP startup problems  Re: Ethernet Cluster Password G Re: five modes (Was: vms security model - does it still exist on IA64?) % Re: Gartner HP vendor rating upgraded % Re: Gartner HP vendor rating upgraded % Re: Gartner HP vendor rating upgraded % Re: Gartner HP vendor rating upgraded + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense  Re: KVM switches Re: OpenVMS I64, a proposal  Re: OpenVMS I64, a proposal  Re: OpenVMS I64, a proposal P OpenVMS Pearl - Press release from one of our partners- PROCESS SOFTWARE INTRODU@ Re: OpenVMS Technical Update Day in Chicago - Only 10 days away!@ Re: OpenVMS Technical Update Day in Chicago - Only 10 days away!0 Opinions please: EVA and database journal policy PDP-11 OS Release Dates & Re: problem with MONITOR CLUSTER (VPM)& Re: problem with MONITOR CLUSTER (VPM)& Re: problem with MONITOR CLUSTER (VPM)& Re: problem with MONITOR CLUSTER (VPM)& Re: problem with MONITOR CLUSTER (VPM) Re: Rethinking V.M.S Thanks VMS rolling roadmap * Re: [Mozilla 1.4] bug in pref-advanced.xul# [spam] Looking for a DLT 7000 drive ' Re: [spam] Looking for a DLT 7000 drive ' Re: [spam] Looking for a DLT 7000 drive   F ----------------------------------------------------------------------   Date: 9 Jul 2003 10:46:57 GMT 1 From: JONESD@er6.eng.ohio-state.edu (David Jones) > Subject: Re: "Advanced server" and Samba Domain Authentication: Message-ID: <begrr1$bsl$1@charm.magnus.acs.ohio-state.edu>  D In message <tomnews-D09CC4.21404608072003@news.comcast.giganews.com>'   Tom Rymes <tomnews@rymes.net> writes: D >OK, I'm asking a question to which the answer is either "Yeah! I am! >doing that here!" or "YOU FOOL!"   . There is a broader range of answers than that.  H >However, I would like to make it possible to keep the OpenVMS passwords+ >in sync with the Samba server's passwords.   C >Would it be possible to do this using a Samba server as a PDC? Has  >anyone done it?  N I don't think so.  The best you could do is write a ACM client (or use the oldH LGI callout mechanism) that has designated accounts authenticate againstE the domain.  You don't have to be a PDC, just a member of the domain.       < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet: L 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  1 Disclaimer: I'm looking for marbles all day long.    ------------------------------  # Date: Wed, 09 Jul 2003 17:13:19 GMT - From: "John E. Malmberg" <wb8tyw@qsl.network> > Subject: Re: "Advanced server" and Samba Domain Authentication: Message-ID: <P2YOa.739$5o5.556655@news1.news.adelphia.net>   Tom Rymes wrote:F > OK, I'm asking a question to which the answer is either "Yeah! I am " > doing that here!" or "YOU FOOL!" >  > Either way, here goes: > G > We are planning to replace our MicroVAX tomorrow with an AlphaServer  G > DS20. That should be a welcome change, assuming all goes as planned.  E > Now, I also run a RedHat linux file server that handles all of our  H > fileserving and e-mail chores. Since the Alpha is going to be running J > our "mission-critical" software, I'm not planning on using it as a file 5 > server via OpenVMS advanced server. (nee Pathworks)  > J > However, I would like to make it possible to keep the OpenVMS passwords - > in sync with the Samba server's passwords.  I > http://h71000.www7.hp.com/pathworks/advancedserver.html states in part:  <snip>E > Would it be possible to do this using a Samba server as a PDC? Has  K > anyone done it? The main idea being that if I make it easy for people to  D > change their passwords, I can make it that much easier to enforce  > password controls. > ! > The DS-20 will be running 7.3.1 + > The RedHat Box runs RH8.0 and Samba 2.2.7   = This is something that is not officially supported of course.   I How well it will work depends on how closely the SAMBA server emulates a  > Microsoft PDC for the functions that External Authentications.  D You can install Advanced Server, and test it out, enabling External ' Authentication for a few test accounts.   H > Any help would be great. Even if it is only "RUN! Don't even think of  > it!"  D I really do not know if it will work or not.  If you do get this to 4 work, then please document it for other Samba users.  * I am not aware of anyone else trying this.   -John  wb8tyw@qsl.network Personal Opinion Only    ------------------------------  $ Date: Wed, 9 Jul 2003 14:45:42 +02002 From: "AWN_VSIS" <anty_SPAM_email_adres@email.com>D Subject: 2 networkcards in an alpha800 server using multinet Problem6 Message-ID: <3f0c0e81$0$49104$e4fe514c@news.xs4all.nl>  	 Hi There,   F I try to use two networkcard's in one alpha800 server running OPEN VMS 7.1-1h2 and Multinet. J After I put in the second networkcard the name is EWB0 (the first is EWA0)  J When I configure EWA0 to se0 and EWB0 to se1, then I have an error on EWB0 after restarting.  The error message i get is ;  B %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1( -SYSTEM-F-INVADDR, invalid media address5 %MULTINET-I-TRYAGAIN, trying again with 3 LAN buffers B %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1( -SYSTEM-F-INVADDR, invalid media address5 %MULTINET-I-TRYAGAIN, trying again with 2 LAN buffers B %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1( -SYSTEM-F-INVADDR, invalid media address5 %MULTINET-I-TRYAGAIN, trying again with 1 LAN buffers B %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1( -SYSTEM-F-INVADDR, invalid media address< %MULTINET-F-CANTSTART, unable to start LAN device, giving up  J When I configure EWA0 to se1 and EWB0 to se0, tehn I have an error on EWA0 after restarting.  See message below ;   B %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1( -SYSTEM-F-INVADDR, invalid media address5 %MULTINET-I-TRYAGAIN, trying again with 3 LAN buffers B %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1( -SYSTEM-F-INVADDR, invalid media address5 %MULTINET-I-TRYAGAIN, trying again with 2 LAN buffers B %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1( -SYSTEM-F-INVADDR, invalid media address5 %MULTINET-I-TRYAGAIN, trying again with 1 LAN buffers B %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1( -SYSTEM-F-INVADDR, invalid media address< %MULTINET-F-CANTSTART, unable to start LAN device, giving up    
 QUESTION : What is the 'MEDIA adrres' ???/ Where can I change this in the right address ??    Please help ................  $ Please reply to arjanmarkt@xs4all.nl   THANKS.    ------------------------------  % Date: Wed, 09 Jul 2003 08:39:57 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> H Subject: Re: 2 networkcards in an alpha800 server using multinet Problem' Message-ID: <3F0C1B2D.AB57B169@fsi.net>    AWN_VSIS wrote:  >  > Hi There,  > H > I try to use two networkcard's in one alpha800 server running OPEN VMS > 7.1-1h2 and Multinet. L > After I put in the second networkcard the name is EWB0 (the first is EWA0) > L > When I configure EWA0 to se0 and EWB0 to se1, then I have an error on EWB0 > after restarting.  > The error message i get is ; > D > %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1* > -SYSTEM-F-INVADDR, invalid media address7 > %MULTINET-I-TRYAGAIN, trying again with 3 LAN buffers D > %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1* > -SYSTEM-F-INVADDR, invalid media address7 > %MULTINET-I-TRYAGAIN, trying again with 2 LAN buffers D > %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1* > -SYSTEM-F-INVADDR, invalid media address7 > %MULTINET-I-TRYAGAIN, trying again with 1 LAN buffers D > %MULTINET-W-STARTUPERR, error starting LAN device for EWB0 for se1* > -SYSTEM-F-INVADDR, invalid media address> > %MULTINET-F-CANTSTART, unable to start LAN device, giving up > L > When I configure EWA0 to se1 and EWB0 to se0, tehn I have an error on EWA0 > after restarting.  > See message below ;  > D > %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1* > -SYSTEM-F-INVADDR, invalid media address7 > %MULTINET-I-TRYAGAIN, trying again with 3 LAN buffers D > %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1* > -SYSTEM-F-INVADDR, invalid media address7 > %MULTINET-I-TRYAGAIN, trying again with 2 LAN buffers D > %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1* > -SYSTEM-F-INVADDR, invalid media address7 > %MULTINET-I-TRYAGAIN, trying again with 1 LAN buffers D > %MULTINET-W-STARTUPERR, error starting LAN device for EWA0 for se1* > -SYSTEM-F-INVADDR, invalid media address> > %MULTINET-F-CANTSTART, unable to start LAN device, giving up >  > QUESTION :  > What is the 'MEDIA adrres' ???1 > Where can I change this in the right address ??   H Oohhh... It looks to me like you may have DECnet lines/circuits on thoseC cards and the MAC address has already been adjusted by DECnet to be  identical on both cards.  8 If possible, try not running DECnet on one or the other.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Wed, 9 Jul 2003 10:13:33 +0300; From: "Oleksii Krykun" <krikun@do.not.spam.academy.kiev.ua> $ Subject: Re: APC UPS control for VMSQ Message-ID: <1037270357C4D411A1C900A0C9D4BFCBD0F7B3@hqnts40div01.academy.kiev.ua>   , <VAXman- @SendSpamHere.ORG> wrote in message* news: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. 1 > >Can you describe your problem more in detail ?  > >/Lars > J > What's so "cute" about it?  Last time that I *explored* this product, itK > only handled simple signalling from the UPS.  For US$400.00, I could very K > easily implement my own single $QIO call to monitor the status of the pin / > that the UPS toggles when it goes on battery.   J I found that APC protocol using more simpler than direct monitoring of pin; status. Though I use VAX with LAT ports on terminal server.    ------------------------------  $ Date: Wed, 9 Jul 2003 10:42:43 -0230, From: "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> Subject: Compiled Applications- Message-ID: <pyUOa.2235$Fy1.101678@localhost>   J Should an application compiled on VMS 5.5 run natively on OpenVMS 6.2-1H3?L I'm not sure what language the original surce was compiled in, or even if it makes a difference.   + Any pointers would be appreciated.  Thanks.    ------------------------------  $ Date: Wed, 9 Jul 2003 10:58:06 -0230, From: "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca>" Subject: Re: Compiled Applications- Message-ID: <PMUOa.2237$Fy1.101619@localhost>   K Further to the following, the system running VMS 5.5 is a MicroVAX; whereas $ the OpenVMS server is an Alpha 2100.  7 "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> wrote in message ' news:pyUOa.2235$Fy1.101678@localhost... L > Should an application compiled on VMS 5.5 run natively on OpenVMS 6.2-1H3?K > I'm not sure what language the original surce was compiled in, or even if  it > makes a difference.  > - > Any pointers would be appreciated.  Thanks.  >  >  >  >    ------------------------------  + Date: Wed, 09 Jul 2003 15:52:43 +0200 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> " Subject: Re: Compiled Applications; Message-ID: <01KY26LAFGPGAM7Y4A@sysdev.deutsche-boerse.com>   C > Should an application compiled on VMS 5.5 run natively on OpenVMS  > 6.2-1H3?     Normally, yes...  E > Further to the following, the system running VMS 5.5 is a MicroVAX; / > whereas the OpenVMS server is an Alpha 2100.    F ..but VAX is 32-bit CISC and ALPHA is 64-bit RISC, so no.  There is a A tool, call VEST, which can translate binary executables to ALPHA  $ executables, but I've never used it.   ------------------------------  $ Date: Wed, 9 Jul 2003 14:56:24 +0100* From: "John Travell" <john@travell.uk.net>" Subject: Re: Compiled Applications5 Message-ID: <beh760$4t9tr$1@ID-120847.news.dfncis.de>   7 "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> wrote in message ' news:pyUOa.2235$Fy1.101678@localhost... L > Should an application compiled on VMS 5.5 run natively on OpenVMS 6.2-1H3?K > I'm not sure what language the original surce was compiled in, or even if  it > makes a difference.  > - > Any pointers would be appreciated.  Thanks.  > # No. V5.5 is VAX, V6.2-1H3 is Alpha.  They are binary incompatible. L You *might* be able to to 'Vest' the image and achieve workable results, but YM*WILL*V...  L If you have the sources you may be able to simply re-compile, if not, and if* Vest does not help, you may well be stuck.     -- John Travell  VMS crashdump expertise for hire john@jomatech.com  +44-(0)23-92552229 http://www.jomatech.com/       --- & 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/2003    ------------------------------  $ Date: Wed, 9 Jul 2003 06:57:40 -0700# From: "Tom Linden" <tom@kednos.com> " Subject: RE: Compiled Applications9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOEPAHIAA.tom@kednos.com>   B Better to bite the bullet now.  Assuming you can find the sources,. recompile.  If they are in C, expect problems.  6 It is good practice to regularly rebuild applications.     >-----Original Message----- 2 >From: Jeff Barnes [mailto:barnesjw@dfo-mpo.gc.ca]' >Sent: Wednesday, July 09, 2003 6:28 AM  >To: Info-VAX@Mvb.Saic.Com# >Subject: Re: Compiled Applications  >  > L >Further to the following, the system running VMS 5.5 is a MicroVAX; whereas% >the OpenVMS server is an Alpha 2100.  > 8 >"Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> wrote in message( >news:pyUOa.2235$Fy1.101678@localhost...< >> Should an application compiled on VMS 5.5 run natively on >OpenVMS 6.2-1H3? L >> I'm not sure what language the original surce was compiled in, or even if >it  >> makes a difference. >>. >> Any pointers would be appreciated.  Thanks. >> >> >> >> >  >  >---' >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: 9 Jul 2003 14:35:37 GMT * From: Terry Aardema <taardema@nrcan.gc.ca>" Subject: Re: Compiled Applications< Message-ID: <Xns93B3576B1C669taardemanrcangcca@132.156.36.9>  / "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> wrote in & news:PMUOa.2237$Fy1.101619@localhost:   E > Further to the following, the system running VMS 5.5 is a MicroVAX; . > whereas the OpenVMS server is an Alpha 2100. > 9 > "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> wrote in message ) > news:pyUOa.2235$Fy1.101678@localhost... D >> Should an application compiled on VMS 5.5 run natively on OpenVMSF >> 6.2-1H3? I'm not sure what language the original surce was compiled >> in, or even if  > it >> makes a difference. >>. >> Any pointers would be appreciated.  Thanks.  J (To the question "Should an executable from previous VMS version X run on G newer version Y?") Yes, although programs that need to access specific  = VMS structures will need to be re-linked on each new version.   J (To the question "Should an executable from VMS for VAX run under VMS for J Alpha?") Nope. That'd be like trying to run a Macintosh application under < Windows; they are completely different CPU instruction sets.  D You do have some options, however. By far the best is to locate the H original sources, and rebuild on the Alpha. This will give you the best G performance, and most VAX -> Alpha migrations require no, or very few,  J modifications to the code. If the sources are NOT available, then you can E use VEST (aka DECmigrate) to perform a binary translation on the VAX  F executable. There are some restrictions on which VAX/VMS versions are E supported, but 5.5 is definately one that is. VESTed images will run  F signifigantly slower than a native rebuild, but will still run *MUCH* G faster on the Alpha than the native VAX executable. I VESTed a library  F (as in "dead trees") database application, and saw a 10-20 fold speed I increase. Note that VEST is not able to translate all applications, even  J those built under supported versions of VAX/VMS; if the application needs J intimate knowledge of the locations of OS structures (humm, the same apps F that need to be relinked for new versions...), VEST probably won't be  able to deal with it.   I If you decide to try the VEST route, get the latest and greatest version  C of "OpenVMS Migration Software for VAX to Alpha" (or "The software  # formerly known as DECmigrate") from   ; http://h71000.www7.hp.com/openvms/products/omsva/omsva.html   
 Terry Aardema D Computer Systems and Network Manager	Administrateur d'ensembles     , 	    	    	    	    	    	    	Informatiques> Natural Resources Canada			Ressources naturelles Canada       6 Canadian Forest Service				Service canadien des forets7 Northern Forestry Centre			Centre de foresterie du Nord " 5320-122 Street					5320, 122e rueF Edmonton, Alberta, Canada T6H 3S5		Edmonton (Alberta), Canada T6H     " 	    	    	    	    	    	    	3S52 Telephone: 780-435-7262				Tlphone: 780-435-72624 Facsimile: 780-435-7359				Tlcopieur: 780-435-7359, taardema@NRCan.gc.ca				taardema@RNCan.gc.ca      ------------------------------  % Date: Wed, 09 Jul 2003 11:15:10 -0400 * From: "Stanley F. Quayle" <stan@stanq.com>" Subject: Re: Compiled Applications- Message-ID: <3F0BF93E.14003.A6618D@localhost>   + On 9 Jul 2003 at 14:56, John Travell wrote: 9 > "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> wrote in message ) > news:pyUOa.2235$Fy1.101678@localhost... N > > Should an application compiled on VMS 5.5 run natively on OpenVMS 6.2-1H3? > N > If you have the sources you may be able to simply re-compile, if not, and if, > Vest does not help, you may well be stuck.  E You could always run CHARON-VAX on your Alpha, which would certainly  E run your application.  Check out http://www.stanq.com/charon-vax.html 8 [another Shameless Plug(tm) from a CHARON-VAX reseller.]
 --Stan Quayle  Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671 1 8572 North Spring Ct. NW, Pickerington, OH  43147 = Preferred address:  stan@stanq.com       http://www.stanq.com    ------------------------------   Date: 9 Jul 2003 12:00:25 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) " Subject: RE: Compiled Applications3 Message-ID: <pzXY3xJyJrxz@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIOEPAHIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: D > Better to bite the bullet now.  Assuming you can find the sources,0 > recompile.  If they are in C, expect problems.  + If they are in Macro, also expect problems.    ------------------------------  * Date: Wed, 9 Jul 2003 17:07:03 +0000 (UTC)+ From: david20@alpha2.mdx.ac.uk (David Webb) " Subject: Re: Compiled Applications+ Message-ID: <behi3n$3ma$1@aquila.mdx.ac.uk>   \ In article <PMUOa.2237$Fy1.101619@localhost>, "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> writes:L >Further to the following, the system running VMS 5.5 is a MicroVAX; whereas% >the OpenVMS server is an Alpha 2100.  > 8 >"Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> wrote in message( >news:pyUOa.2235$Fy1.101678@localhost...M >> Should an application compiled on VMS 5.5 run natively on OpenVMS 6.2-1H3? L >> I'm not sure what language the original surce was compiled in, or even if >it  >> makes a difference. >>. >> Any pointers would be appreciated.  Thanks. >>  G Whilst all VAX VMS user applications compiled on VMS 5.5 (or VMS 4.x or D VMS 3.x etc) should run fine on later versions of VAX VMS no VAX VMS+ executables will run natively on Alpha. (*)     M To get a VAX/VMS application to run on Alpha it either needs to be recompiled O and linked on Alpha or it needs to be translated using the VEST Migration tool.   < If you don't have the source then you will need to use VEST.     M (*) The ability to run VAX executables on later versions of VAX VMS and Alpha P executables on later versions of Alpha VMS is not guaranteed for any code which N directly accesses memory structures or does other nasty things in Kernel mode.     
 David Webb VMS and unix team leader CCSS Middlesex University   ------------------------------  $ Date: Wed, 9 Jul 2003 08:42:09 -0400& From: "Island" <dbturner@islandco.com> Subject: Re: Cpu panic random / Message-ID: <vgo3hqn2m8id50@news.supernews.com>   ; We have some 667Mhz CPU boards if it turns out you need one K We also have the 500Mhz (need to match the Pass# which is based on the part  no on the CPU board) Call me if you need some help    David    --   David B Turner Island Computers US Corporation  2700 Gregory St., Suite 180  Savannah GA 31404  Tel: 912 447 6622  Fax: 912 201 0402  Email: dbturner@hpaq.net http://www.hpaq.net    ------------------------------  $ Date: Wed, 9 Jul 2003 02:05:46 -0400* From: "Bill Todd" <billtodd@metrocast.net>W Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful Performance 2 Message-ID: <whycne6PUYJZLZaiXTWJkw@metrocast.net>  . "rob kas" <rob@paychoice.com> wrote in message2 news:BqHOa.537$lq7.52902976@news.netcarrier.net... >  > 
 >    Keith > I >  Don't you feel a bit odd posting this after posting  after posting the  > Omega Article? > ! >   "Far better to go the Itanium J > route (and perhaps eat some crow with a side dish of humble pie) than toH > relentlessly rely on an aging microprocessor such as PA-RISC or Alpha"  J You have to realize that HP, like Compaq before it, refuses to acknowledgeK any shame.  The closest they come is some nominal sop, such as this one, to F those who persist in complaining about their perfidy and incompetence.  K The article cited appears, of course, under the alphaserver portion of HP's G Web site, so they can be sure that no one will see it save for existing I customers.  Other people who might be interested (or critical) won't have J their minds troubled by the inconsistencies between this paper and Terry's, far more wide-spread propaganda in HP World.  E In my critique of Terry's paper, while I took time to expose his more ? blatant lies I didn't dwell upon Alpha's continuing performance J competitiveness - despite its continuing reliance on a 1998 core - perhapsL as much as I should have.  The D.H. Brown paper helped rectify that omissionC by noting how clearly EV7 out-performed Itanic2 in the same process D generation, but to *really* appreciate EV7 you need to compare it toD Madison, with its full-process-generation lead and 4-year-newer core technology.   K Since cHumPaq has made it more difficult to assess EV7's merits by refusing I to submit a TPC-C result for it, we need to rely instead upon things like F the Oracle Applications Standard Benchmark.  There, an 8-processor EV7K system more than doubled the performance of the 4-processor McKinley system L noted in the D.H. Brown article, and while a later 4-processor McKinley testL managed to exceed half the EV7 system's performance by less then 9% that wasL at the cost of 51% slower average response time than EV7's.  The 8-processor; EV7 system even out-performed a 4-processor Madison by 20%.   G That last point may not seem very competitive until you realize that if K SuperDome's current rather pathetic TPC-C scaling is anything to go by it's K not clear that an 8-processor Madison will do all that much better than the J aging Alpha, once again emphasizing EV7's superior scalability.  But sinceI Alpha is a dying breed it's no longer what Madison has to worry about:  a K 16-processor POWER4+ system generated a score well over three times that of D the 4-processor Madison, so Madison will have to scale very close toL linearly in the transition from the fast, 4-processor zx1 environment to theH apparently significantly more sluggish SuperDome environment to have any chance at all of keeping up.  H The SAP SD 2-tier benchmark showed EV7's performance to be well over 50%J ahead of the NEC 32-processor McKinley submission (which barely managed toK beat out a 3-year-old GS320 score), so Madison may have difficulty catching J EV7 there as well (Madison's 4-processor result on HP's supposedly hot zx1H box was less than 20% of the EV7's 32-processor result, and there's thatK scaling issue again...).  POWER4+ also seems well-positioned to out-perform C Madison here:  too bad Alpha is no longer in the long-term running.   G I already noted (as D.H. Brown did) that there's no competition for EV7 J anywhere on the visible horizon in STREAMS performance, regardless of whatL process generation the competition may be in.  But it's worth noting as wellC that even in the areas where Itanic2 supposedly enjoys its greatest I advantages EV7 hangs right in there in large systems despite being a full I process generation (and 4 years in core design) behind:  at 32 processors H EV7's SPECint_rate scores of 285/313 are only about 20% behind Madison'sG (385/385 on the similarly-superbly-scaling SGI platform) and even EV7's G SPECfp_rate scores of 405/536 don't look all that bad compared to SGI's L Madison scores 644/647 when you consider that feedback-directed optimizationJ was not used for EV7's base score and was for Itanic2's (so comparing peakL score is a better measure of relative performance, and once again EV7's peak) score is less than 20% behind Madison's).   L It's really sad to consider how sick EV8 would have made Itanic look even ifL EV8 *had* trailed by a full process generation as EV7 now does (though sinceK IBM actually introduced its 130 nm process for POWER4+ well *before* Itanic K hit 130 nm there's no reason for this to have been the case).  Not only was H EV8 in a given process generation a significantly faster single-threadedE core than EV6/EV7, but simulations had clearly indicated that in OLTP G environments its SMT provided an *additional* 3x improvement in overall J throughput (average improvement across all multi-threaded environments was more like 2x).  H That means that even if it had been a full process generation behind EV8I would have somewhat out-performed Itanic in single-threaded operation and I offered well over 2x Itanic's throughput in average multi-threaded server E use and close to 4x in OLTP server environments.  In the same process K generation, it would have beat Itanic by factors of close to 2x, 4x, and 6x G in those categories.  Ave atque vale, EV8.  Rot in hell, cHumPaq liars.    - bill   ------------------------------  $ Date: Wed, 9 Jul 2003 02:41:21 -0400  From: John Santos <JOHN@egh.com>" Subject: Re: DHCP startup problems4 Message-ID: <1030709023145.636B-100000@Ives.egh.com>  ) On Wed, 9 Jul 2003, Michael Austin wrote:    > Steve Young wrote: > >  > >   Hello all, > > M > >   I'm having a weird problem with DHCP on my VMS 7.3-1 box running Compaq K > > TCP/IP.  The problem is that when TCP/IP starts during boot time, it is O > > unable to get a DHCP lease and starts the machine up without an IP address. I > > However, if I log in immediately afterwards and deassign SE0 and then > > > re-create the interface with /DHCP/PRIMARY, it works fine. > > G > >   Can anyone suggest a solution or possible cause for this problem?  > > 
 > >   Thanks,  > >   Steve. > E > IMHO, DHCP is for toy computers.  And since I have servers that are F > dependent upon knowing the IP address to be able to connect to theseH > services... I find it much simpler to just set it and be done with it.  C It might be useful to use DHCP with static addresses in some cases. A (DHCP can be told to always serve up a particular IP address to a A particular MAC address.)  The advantages are that the DHCP server B can provide DNS server addresses, gateway addresses, and so forth,D so you don't have to change a zillion places if these change.  Also,B if you need to move a bunch of systems from one subnet to another,D you can make all your changes on the DHCP server (i.e. in one place)0 and just reboot everything else when convenient.  = I haven't actually done this, but did look at it at one time, C long ago when VMS TCP/IP stacks didn't support being a DHCP client.   = I don't remember if the DHCP server becomes a single point of C failure or if there is a way to have multiple DHCP servers.  (Maybe B a VMS cluster with a lock to control which system is currently theB server and the DHCP config file in a common directory on a shared,A shadowed disk would do the trick if the DHCP protocol intrinsicly / dislikes having multiple servers on one LAN :-)    > --  
 > Regards, > 8 > Michael Austin            OpenVMS User since June 19849 > First DBA Source, Inc.    Registered Linux User #261163  >  >    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 9 Jul 2003 07:34:17 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) & Subject: Re: Ethernet Cluster Password3 Message-ID: <GO8JwIwwaVBH@eisner.encompasserve.org>   c In article <YGWFfIlb2d2J@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > H > Which is _not_ the same as saying it is secure.  The security level ofC > the cluster password is approximately good enough to prevent most D > independent clusters from colliding on the same wire.  It is _NOT_C > good enough to prevent an attacker on the wire from breaking into G > a cluster without having prior access to any of the existing members.  >   E    It's also good enough to fill up your system disk via errorlog.sys <    if someone tries the same group and a different password.   ------------------------------  $ Date: Wed, 9 Jul 2003 03:33:52 -0400  From: John Santos <JOHN@egh.com>P Subject: Re: five modes (Was: vms security model - does it still exist on IA64?)4 Message-ID: <1030709032127.636C-100000@Ives.egh.com>  ' On Tue, 8 Jul 2003, Dan O'Reilly wrote:   , > At 02:17 PM 7/8/2003, Chris Scheers wrote: > >Hoff Hoffman wrote: > > >  > > > K > > >   Extra credit question: which VAX implementation had five modes. :-)  > >  > > D > >That would be the 700 series VAXen with PDP11 compatibility mode: > > K > >780, 782, 785, 750, 751, 730, 725, and 8600 (aka 790)  [Did I miss any?]  > I > I thought the 8600 dropped compatibility mode finally, or am I thinking  > of the 8650?  H Nope.  8600 and 8650 both had compatibility mode, but it was implemented differently (and slower.)   ? I think the 86x0's implemented it in microcode with no hardware > assists, unlike the 11/7xx's.  The 8600 was only about 1/2 the> speed of an 11/785, despite being over twice as fast in native? mode (~3 VUP vs. 1.3 VUP).  IIRC, the 8650 was about 50% faster E than the 8600, but still a lot slower than an 11/785 in compatibility F mode (and a little slower than the 11/780, somewhere between the 11/84 and the 11/70.)   = I think the 1st systems without any compatibility mode at all @ were the 8700/8800 and 8200/8300, which were introduced at about? the same time.  Might have been the MVI, but I think that was a 
 little later.    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Wed, 09 Jul 2003 13:26:01 GMT # From: "John Smith" <a@nonymous.com> . Subject: Re: Gartner HP vendor rating upgradedH Message-ID: <JJUOa.88399$a51.54333@news02.bloor.is.net.cable.rogers.com>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3F0B85F5.6EDB6A73@fsi.net...t > Dave Gudewicz wrote: > > F > > Noticed VMS went from Strong Negative to something higher.  Didn't say what > > higher.c >sC > Well, at least that's progress. Guess we'll have to keep whipping  thatE > one until we get "their" "opinion" back into an acceptable range...p    B The question everyone ought to be asking is why place any stock inC what Gartner has to say at all? They've been so full of b.s. for sol< long about VMS and Alpha.....why the sudden change of heart?   ------------------------------  % Date: Wed, 09 Jul 2003 10:53:51 -0400n( From: David Froble <davef@tsoft-inc.com>. Subject: Re: Gartner HP vendor rating upgraded, Message-ID: <3F0C2C7F.6050906@tsoft-inc.com>   John Smith wrote:t  > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3F0B85F5.6EDB6A73@fsi.net...  >  >>Dave Gudewicz wrote: >>E >>>Noticed VMS went from Strong Negative to something higher.  Didn'tP >>>d
 > say what > 
 >>>higher. >>> C >>Well, at least that's progress. Guess we'll have to keep whipping' >> > that > E >>one until we get "their" "opinion" back into an acceptable range...l >> >  > D > The question everyone ought to be asking is why place any stock inE > what Gartner has to say at all? They've been so full of b.s. for sos> > long about VMS and Alpha.....why the sudden change of heart? >  >  >    Gartner is owned by Intel ???n   -- a4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Wed, 09 Jul 2003 12:11:27 -0500R1 From: "David J. Dachtera" <djesys.nospam@fsi.net> . Subject: Re: Gartner HP vendor rating upgraded' Message-ID: <3F0C4CBF.259C9C65@fsi.net>l   John Smith wrote:a > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3F0B85F5.6EDB6A73@fsi.net...- > > Dave Gudewicz wrote: > > >-H > > > Noticed VMS went from Strong Negative to something higher.  Didn't
 > say what
 > > > higher.. > >DE > > Well, at least that's progress. Guess we'll have to keep whippinga > thatG > > one until we get "their" "opinion" back into an acceptable range...o > D > The question everyone ought to be asking is why place any stock inE > what Gartner has to say at all? They've been so full of b.s. for soi> > long about VMS and Alpha.....why the sudden change of heart?  H Well, not a change really, just an acknowledgement that those who shouldE know better (i.e., the "decision makers") *DO* put stock in Gartner'sv3 BS. So, the less BS and the more truth, the better.u   -- S David J. DachteraC dba DJE Systemso http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   Date: 9 Jul 2003 17:16:57 GMTo( From: bill@cs.uofs.edu (Bill Gunshannon). Subject: Re: Gartner HP vendor rating upgraded5 Message-ID: <behim8$5frui$1@ID-135708.news.dfncis.de>U  ' In article <3F0C4CBF.259C9C65@fsi.net>,14 	"David J. Dachtera" <djesys.nospam@fsi.net> writes: > John Smith wrote:b >> H? >> "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message $ >> news:3F0B85F5.6EDB6A73@fsi.net... >> > Dave Gudewicz wrote:- >> > >I >> > > Noticed VMS went from Strong Negative to something higher.  Didn'tt >> say whatc >> > > higher. >> >F >> > Well, at least that's progress. Guess we'll have to keep whipping >> thataH >> > one until we get "their" "opinion" back into an acceptable range... >> eE >> The question everyone ought to be asking is why place any stock inhF >> what Gartner has to say at all? They've been so full of b.s. for so? >> long about VMS and Alpha.....why the sudden change of heart?, > J > Well, not a change really, just an acknowledgement that those who shouldG > know better (i.e., the "decision makers") *DO* put stock in Gartner'sa5 > BS. So, the less BS and the more truth, the better.w >   F But it will always be BS.  Just because at some small number of pointsE the BS coincides with reality doesn't change the overall value of the  the service they provide.d   bill   -- iJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   a   ------------------------------   Date: 8 Jul 2003 23:26:43 -0700h# From: dooleys@snowy.net.au (dooley)d4 Subject: Re: HP World: Why Alpha's Omega Makes Sense< Message-ID: <1ca82fc6.0307082226.1e4f079@posting.google.com>  ] Greg Cagle <gregc@gregcagle.com> wrote in message news:<vgkk92p9keq708@corp.supernews.com>...e > Dirk Munk wrote: > M > > If someone would be so kind to publish an extract of this article here ? n; > > Not everyone is a member of the US part of Interex ....u >  > Here you go: >  > ---------------- >  > Why Alpha's Omega Makes Senses3 > Farewell to the "Fastest Processor on the Planet"d > by Terry Shannon > K > In my last HP World Magazine article ("Dj vu All Over Again," April HP aJ > World Magazine, page 33), I discussed in detail prior migrations on DEC H > and Compaq platforms. A close read of the article rendered it evident J > that I was a bona-fide Alpha adherent, which in fact was the case. Less I > than two months before the decision to terminate the Alpha program was oH > made public on June 25, 2001, I was on the road in the United States, : > Europe and the Pacific Rim touting the virtues of Alpha. > J > But there are two sides to every coin, and such is the case with Alpha. J > Since its introduction in November 2002, the "architecture for the next C                             ^^^^^^^^^^^^^ ????? surely some mistakeeK > 25 years" has begun to lose some of its initially compelling performance 0 > differentiation.   ------------------------------  # Date: Wed, 09 Jul 2003 13:26:04 GMT # From: "John Smith" <a@nonymous.com> 4 Subject: Re: HP World: Why Alpha's Omega Makes SenseH Message-ID: <MJUOa.88400$a51.40211@news02.bloor.is.net.cable.rogers.com>  0 "dooley" <dooleys@snowy.net.au> wrote in message6 news:1ca82fc6.0307082226.1e4f079@posting.google.com...3 > Greg Cagle <gregc@gregcagle.com> wrote in messaget+ news:<vgkk92p9keq708@corp.supernews.com>...o > > Dirk Munk wrote: > >W? > > > If someone would be so kind to publish an extract of this- article here ?= > > > Not everyone is a member of the US part of Interex ....1 > >E > > Here you go: > >  > > ---------------- > >t! > > Why Alpha's Omega Makes SenseM5 > > Farewell to the "Fastest Processor on the Planet"0 > > by Terry Shannon > >,C > > In my last HP World Magazine article ("Dj vu All Over Again,"  April HPD > > World Magazine, page 33), I discussed in detail prior migrations on DECA > > and Compaq platforms. A close read of the article rendered itw evident F > > that I was a bona-fide Alpha adherent, which in fact was the case. LessF > > than two months before the decision to terminate the Alpha program waswA > > made public on June 25, 2001, I was on the road in the Unitedc States,0< > > Europe and the Pacific Rim touting the virtues of Alpha. > >TD > > But there are two sides to every coin, and such is the case with Alpha.F > > Since its introduction in November 2002, the "architecture for the nextE >                             ^^^^^^^^^^^^^ ????? surely some mistake @ > > 25 years" has begun to lose some of its initially compelling performancem > > differentiation.     1992.p  C Since the posting here was, I'm sure, a cut/paste job, the originaluD error probably was in Terry's original typographic efforts......just+ like all the other mistakes in the article.t   ------------------------------   Date: 9 Jul 2003 08:40:44 -0500n+ From: young_r@encompasserve.org (Rob Young)w4 Subject: Re: HP World: Why Alpha's Omega Makes Sense3 Message-ID: <pgC2myMEsybs@eisner.encompasserve.org>v  b In article <1ca82fc6.0307082226.1e4f079@posting.google.com>, dooleys@snowy.net.au (dooley) writes:_ > Greg Cagle <gregc@gregcagle.com> wrote in message news:<vgkk92p9keq708@corp.supernews.com>...I   >> RK >> But there are two sides to every coin, and such is the case with Alpha. rK >> Since its introduction in November 2002, the "architecture for the next  E >                             ^^^^^^^^^^^^^ ????? surely some mistake-  0 	Yes.  That is easy to remember.  November 1992.   				RobE   ------------------------------  % Date: Wed, 09 Jul 2003 07:19:48 -0700t& From: Greg Cagle <gregc@gregcagle.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense/ Message-ID: <vgo947d2kd5d64@corp.supernews.com>-   John Smith wrote:o   > 1992.d > E > Since the posting here was, I'm sure, a cut/paste job, the originalIF > error probably was in Terry's original typographic efforts......just- > like all the other mistakes in the article.d  E Yup, and the error also appears in the printed version of the articleL in HPW magazine.   - Greg -- t
 Greg Cagle gregc at gregcagle dot com   ------------------------------  % Date: Wed, 09 Jul 2003 18:42:06 +0200d From: Dirk Munk <munk@home.nl>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense2 Message-ID: <behgld$2lb$1@news3.tilbu1.nb.home.nl>  C >Since its introduction in November 2002, the "architecture for theN > B >                          ^^^^^^^^^^^^^ ????? surely some mistake >gB >next 25 years" has begun to lose some of its initially compelling >  >performance differentiation.l >  >  >  > 1992., > E > Since the posting here was, I'm sure, a cut/paste job, the original F > error probably was in Terry's original typographic efforts......just- > like all the other mistakes in the article.d > M Or Terry made a Freudian mistake, and he was thinking of the Itanium when he  1 wrote this. Then the date would be about correct.e   ------------------------------  $ Date: Wed, 9 Jul 2003 09:34:09 +0100* From: "John Travell" <john@travell.uk.net> Subject: Re: KVM switchesy5 Message-ID: <begk64$4st21$1@ID-120847.news.dfncis.de>a  9 "Ken Fairfield" <My.Full.Name@intel.com> wrote in messager" news:3F0B2766.EAF25B0@intel.com... > "Stanley F. Quayle" wrote: > >S0 > > On 7 Jul 2003 at 16:28, Ken Fairfield wrote:F > > > I haven't been able to get a technical person to tell me whether
 either theH > > > Rose or the Raritan can manage the switch between a live VMS/Alpha > > > and a live PC. > >mG > > I have a Raritan switch working between Windows 2000, Red Hat Linux.E > > 7.3 on Intel, OpenVMS 7.3-1 Alpha, and OpenVMS 7.3 VAX.  It works I > > perfectly.  There are no problems with the keyboard, unlike other KVMp > > switches I've tried. >m: > Thanks for that input, it gives more confidence is goingE > the Raritan route.  Which series is it (MasterConsole, CompuSwitch, 	 > other)?t >e9 > Also, in the other followup form the OP, it sounds likepA > Adder understands the requirements and has a solution.  I thinkh@ > I'll look around and see if they are available on this side of
 > the pond...- >   8 Adder do have a US office, according to their website at http://www.addertec.com/     -- John Travell  VMS crashdump expertise for hire john@jomatech.comt +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/2003s   ------------------------------   Date: 9 Jul 2003 07:31:52 -05006; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler):$ Subject: Re: OpenVMS I64, a proposal3 Message-ID: <FH2C+yQCIDd4@eisner.encompasserve.org>e  _ In article <Uvqr3E2E8Tq9@cuebid.zko.dec.com>, brooks@cuebid.zko.dec.nospam (Rob Brooks) writes:.? > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:s2 >> Kilgallen@SpamCop.net (Larry Kilgallen) writes: > C >>> I hate to consider all that freeware floating around built with A >>> still-buggy compilers.  Presumably once IA64 VMS is released, A >>> anything that built on Alpha VMS should easily build, or else.F >>> depends on IA64 VMS internals that _do_ require listing kits, etc. >>  6 >>    I assume TECO will be native (and not freeware)? > J > Unlikely; TECO on OpenVMS Alpha is brought to you courtesy of DECmigrate3 > (if "be native", you meant "compiled by IMACRO").   D    I knew TECO was a serious challenge to VEST, but I thought it was;    later ported natively.  Somehow I must have got mislead.g   > D > I have seen nothing to indicate that TECO will be omitted from any0 > OpenVMS distribution on any hardware platform.  H    So does this mean that VEST from Alpha to IA64 can handle images that+    were VEST from VAX to Alpha?  Very good.e   ------------------------------   Date: 9 Jul 2003 06:42:05 -0700 ( From: bob@instantwhip.com (Bob Ceculski)$ Subject: Re: OpenVMS I64, a proposal< Message-ID: <d7791aa1.0307090542.c46f470@posting.google.com>  q Doc.Cypher <Use-Author-Address-Header@[127.1]> wrote in message news:<20030708214330.7939.qmail@nym.alias.net>...l? > On Tue, 08 Jul 2003, Elliott Roper <elliott@yrl.co.uk> wrote:yF > >In article <5XzHgOLm8I6L@eisner.encompasserve.org>, Larry Kilgallen! > ><Kilgallen@SpamCop.net> wrote:a > > 8 > >> In article <FW8PQBYcNJBA@eisner.encompasserve.org>,B > >> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > >> bL > >> >    THEREFOR I propose that HP provide a small two node Alpha and IA64I > >> >       cluster, unsupported, undocumented, on the internet, to the cQ > >> >       OpenVMS hobbyist community at large for the sole purpose of porting a/ > >> >       said free software to OpenVMS I64.t > >>  D > >> I hate to consider all that freeware floating around built withB > >> still-buggy compilers.  Presumably once IA64 VMS is released,B > >> anything that built on Alpha VMS should easily build, or elseG > >> depends on IA64 VMS internals that _do_ require listing kits, etc.l > > I > >Nevertheless. Bob's idea is a good'un. If it is that easy, then it's a 0 > >good way of showing the world how easy it is. > >.G > >Since they are so little and cheap, another way would be to lend the 5 > >freeware authors a box each for a month or so. ;-)l > P > What about all those boxes Dave Turner was talking about?  I know, Alphas, but? > they'd be ideal for seeding the .edu space with VMS machines.S >  >  > Doc.  - don't worry, I'll put them to good use ... :)m   ------------------------------   Date: 9 Jul 2003 11:58:43 -0500w- From: Kilgallen@SpamCop.net (Larry Kilgallen)w$ Subject: Re: OpenVMS I64, a proposal3 Message-ID: <NxsT1px0pwDg@eisner.encompasserve.org>   q In article <FH2C+yQCIDd4@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: a > In article <Uvqr3E2E8Tq9@cuebid.zko.dec.com>, brooks@cuebid.zko.dec.nospam (Rob Brooks) writes:f@ >> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:3 >>> Kilgallen@SpamCop.net (Larry Kilgallen) writes:m >> aD >>>> I hate to consider all that freeware floating around built withB >>>> still-buggy compilers.  Presumably once IA64 VMS is released,B >>>> anything that built on Alpha VMS should easily build, or elseG >>>> depends on IA64 VMS internals that _do_ require listing kits, etc.0 >>> 7 >>>    I assume TECO will be native (and not freeware)?- >> -K >> Unlikely; TECO on OpenVMS Alpha is brought to you courtesy of DECmigrated4 >> (if "be native", you meant "compiled by IMACRO"). > F >    I knew TECO was a serious challenge to VEST, but I thought it was= >    later ported natively.  Somehow I must have got mislead.9  I What happened after the initial try was that TECO was used to postprocessiH it's own VAX listing files creating a VEST hints file used for effectiveJ VESTing.  TECO was not so much a challenge to VEST as it was to the AMACROI compiler, where the source code in TECO defeated the efforts of AMACRO ton& "behave on Alpha as if this were VAX".  E >> I have seen nothing to indicate that TECO will be omitted from anyk1 >> OpenVMS distribution on any hardware platform.e > J >    So does this mean that VEST from Alpha to IA64 can handle images that- >    were VEST from VAX to Alpha?  Very good.h  C I thought that was a stated direction for image translation to IA64e& (rather than going directly from VAX).   ------------------------------   Date: 9 Jul 2003 10:29:12 -0700 1 From: susan_skonetski@hotmail.com (Sue Skonetski)iY Subject: OpenVMS Pearl - Press release from one of our partners- PROCESS SOFTWARE INTRODUo= Message-ID: <857e9e41.0307090929.1584c152@posting.google.com>h   Folks,  E If you need a word copy of this press release please let me know.  OKr for external distribution.  
 Warm Regards,r Sue F ______________________________________________________________________B PROCESS SOFTWARE INTRODUCES SECURITY ENHANCEMENTS TO PRODUCT SUITE  C SSH for OpenVMS, MultiNet and TCPware products supports secure fileh transfer protocolr  A         FRAMINGHAM, Mass. (July 8, 2003) - Process Software todayrF announced security enhancements to its Secure Shell for OpenVMS client8 and server software, MultiNet and TCPware TCP/IP stacks.E The SSH feature was enhanced in all three products to include supportwA for SFTP server and client and single sign-on. SSH enables remotel? systems administrators, telecommuters and other users to accesssD corporate networks without revealing passwords and data to potentialC eavesdroppers. Telnet, e-mail, database connections, file transfersdE and other third party applications are protected. SSH provides a high D level of security using several authentication and strong encryption2 options, including industry standard RSA and 3DES.? SSH for OpenVMS is a complete SSH client and server application F running on Alpha and VAX systems using HP TCP/IP Services for OpenVMS.E With this enhancement, Process Software has released Version 2 of SSH D for OpenVMS. SSH for OpenVMS now supports HP TCP/IP Services version
 4.0 or later.rA MultiNet and TCPware are similar products that provide a completenA TCP/IP solution for OpenVMS software with a reliable backbone foruF running mission-critical applications on HP VAX and Alpha Systems. TheC security enhancement is a plug-in to the existing releases MultiNet	F v4.4 and TCPware v5.6, which can be accessed from the Process Software	 FTP site.5D The new SSH security enhancements include an SFTP server and client.E It provides a secure mechanism for copying, deleting and transferring1@ data over a network. SFTP is based on SSH file transfer protocolD Version 4, which improves the file transfer interoperability between disparate operating systems.F Also, included in this security enhancement is single sign-on support,< which allows customers to use their existing Kerberos or PKIF certificates for SSH authentication. This simplifies the management of* an organization's security infrastructure.F "We added these enhancements to provide our customers with the abilityB to support secure file transfer protocol and single sign-on," saidC Brian P. McDonald, president and chief executive officer of ProcesstA Software. "In addition, they provide better interoperability with-@ operating systems other than OpenVMS. With the enhancements, ourA customers can rest assured that they have a secure and functional1
 solution."? Process Software was founded in 1984 and serves more than 5,000 D customers, including many Global 2000 and Fortune 1000 companies. It( was acquired by Platinum Equity in 2000. Process Software; Process Software (www.process.com) is a premier supplier oft$ infrastructure software solutions toD mission-critical environments. The company delivers customer-centric and innovative IP-based<D technologies to customers worldwide, and provides them with superior? customer support and service. Process Software's leading TCP/IPpC products for OpenVMS include SSH for OpenVMS, TCPware and MultiNet,-A and PMDF messaging products for OpenVMS, Tru64 UNIX, Solaris, and 6 Windows. Process Software is owned by Platinum Equity.   Platinum Equityt: Platinum Equity (www.peh.com) is a global acquisition firmE specializing in the strategic operation of mission-critical companies.@ according to a unique M&A&OSM model of value creation. Since itsA founding in 1995, Platinum has completed over 40 privately funded D transactions, leveraging a multi-billion dollar revenue base derived? from the continued growth of its portfolio. With an establishede@ infrastructure in North America, Europe, Asia and South America,E Platinum employs a workforce of more than 15,000 serving over 600,000k customer sites worldwide.y     # # #o  	 Contact:	i  / Process Software                Platinum Equityc% Lauren Maschio          Jodie Dauberto; Director of Marketing           Public Relations Consultant . (508) 626-7525                  (717) 703-67200 maschio@process.com             jdaubert@peh.com   ------------------------------  $ Date: Wed, 9 Jul 2003 09:42:11 +0100* From: "John Travell" <john@travell.uk.net>I Subject: Re: OpenVMS Technical Update Day in Chicago - Only 10 days away! 5 Message-ID: <begkh6$4rat4$1@ID-120847.news.dfncis.de>o  7 "Dave Gudewicz" <k9jdk@NOSPAMarrl.net> wrote in messageA) news:vgmtv6tko0pe88@corp.supernews.com...cF > Outside it might be windy, rainy, hot and humid, just like summer in > Chicagoland. >aH > Inside the Double Tree it probably won't be. :)  Don't let the weather stop  > you from attending the update. >2	 > Dave...9 >4  & Huh!. I wish it were only the weather!K I am sure there are a lot of us euro-types who would love to attend if onlyc, someone else were paying the air-fare... :-)     -- John Travell  VMS crashdump expertise for hire john@jomatech.comi +44-(0)23-92552229 http://www.jomatech.com/       ---f& 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/20032   ------------------------------  % Date: Wed, 09 Jul 2003 08:18:03 -0500-1 From: "David J. Dachtera" <djesys.nospam@fsi.net>-I Subject: Re: OpenVMS Technical Update Day in Chicago - Only 10 days away!E' Message-ID: <3F0C160B.41E49B97@fsi.net>P   Dave Gudewicz wrote: > F > Outside it might be windy, rainy, hot and humid, just like summer in > Chicagoland. > M > Inside the Double Tree it probably won't be. :)  Don't let the weather stop   > you from attending the update.  B Agreed! In fact, I'll bring a sweater - hotel conference rooms are, usually something akin to a walk-in 'fridge!   -- t David J. Dachterai dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Wed, 09 Jul 2003 14:17:18 GMT./ From: "Jeff Goodwin" <jgoodwin@maine.rrr-r.com> 9 Subject: Opinions please: EVA and database journal policye7 Message-ID: <OtVOa.78034$8B.21586@twister.nyroc.rr.com>,  G We're installing EVA storage in some of our facilities.  We've had someeK discussion on how to handle database journal files (like .AIJ for DBMS/RDB)o= and I'd like to find out what others are doing in this space.u  K Currently, our practice is to store journal files on a separate device fromdL any devices the database is stored on.  If any database device is completelyK lost, the database can be restored from tape and bought up to date with thefH still available journal files.  We've never had to do this to production data, but we like to be ready.  H Storage allocation on the EVA makes this practice less clear.  I guess II want to know if people are allocating separate storage pools for databaselG and journals or if one storage pool is sufficient.  If I'm missing somee( other option, I'd like to hear that too.   -Jeffy   ------------------------------   Date: 9 Jul 2003 16:37:15 GMTt2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>  Subject: PDP-11 OS Release Dates+ Message-ID: <behgbr047t@enews4.newsguy.com>a  L For a start, I'd like to appologize for the cross-posting, but I'm trying toL reach people that might have info but don't normally read the PDP-11 groups.  K I'm looking for release dates for the various PDP-11 OS's.  For example forc RT-11:    RT-11 V4 was February 21st, 1980 RT-11 V5 was March 12th, 1983  RT-11 V5.6 was 1992o" RT-11 V5.7 was October, 29th, 1998  5 Please note I'm interested in the other OS's as well.o   		Zane   ------------------------------  $ Date: Wed, 9 Jul 2003 08:48:54 +0200< From: "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de>/ Subject: Re: problem with MONITOR CLUSTER (VPM)r4 Message-ID: <begdst$4mvnr$1@ID-56200.news.dfncis.de>   Michael Austin wrote:tA > do pipe sh sys/proc=*vpm_server* |sear sys$input vpm_server | -o< >  (read sys$pipe rec ; x = f$ele(0," ",rec) ; stop/id=&x );  A Wouldn't SHOW SYSTEM /NOHEADING and removing the SEARCH yield thei same result?   cu,    Martin -- rF   OpenVMS:                | Martin Vorlaender  |  VMS & WNT programmer3    The operating system   | work: mv@pdv-systeme.derF    God runs the           |   http://www.pdv-systeme.de/users/martinv/:    earth simulation on.   | home: martin@radiogaga.harz.de   ------------------------------  + Date: Wed, 09 Jul 2003 10:09:24 +0200 (MET)39 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>h/ Subject: Re: problem with MONITOR CLUSTER (VPM)s; Message-ID: <01KY1UM73VL0AM7Y4A@sysdev.deutsche-boerse.com>E  J > I have seen this a few times.. just stop the VPM Server processes on all. > nodes and try your Monitor command again...   - Presumably after restarting VPM on all nodes?-  H > I have not seen a difinitive answer on how to keep from scrambling the) > VPM Server's brains or what causes it. i  D So if I used DECnet for monitor communication, the problem wouldn't  occur?   ------------------------------  $ Date: Wed, 9 Jul 2003 09:50:11 +0100* From: "John Travell" <john@travell.uk.net>/ Subject: Re: problem with MONITOR CLUSTER (VPM)s5 Message-ID: <beglmm$4ou49$1@ID-120847.news.dfncis.de>   G "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de> wrote in message5. news:begdst$4mvnr$1@ID-56200.news.dfncis.de... > Michael Austin wrote:bC > > do pipe sh sys/proc=*vpm_server* |sear sys$input vpm_server | -3> > >  (read sys$pipe rec ; x = f$ele(0," ",rec) ; stop/id=&x ); >7C > Wouldn't SHOW SYSTEM /NOHEADING and removing the SEARCH yield thef > same result? >   0 Yes - if you want to do a manual eyeball search.E No - if you want the procedure to find *and extract* the PID's of therH vpm_server processes, and kill them without any user intervention beyond* invoking the procedure in the first place.  G I like it, I will save that code snippet for a day when it might becomen
 useful to me.y     -- John Travell  VMS crashdump expertise for hire john@jomatech.comm +44-(0)23-92552229 http://www.jomatech.com/       ---o& 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/2003s   ------------------------------  $ Date: Wed, 9 Jul 2003 11:41:01 +0200< From: "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de>/ Subject: Re: problem with MONITOR CLUSTER (VPM)d4 Message-ID: <begnvl$4s2fa$1@ID-56200.news.dfncis.de>   John Travell wrote: A > "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de> wrote ini8 > message news:begdst$4mvnr$1@ID-56200.news.dfncis.de... >> Michael Austin wrote:C >>> do pipe sh sys/proc=*vpm_server* |sear sys$input vpm_server | -I> >>>  (read sys$pipe rec ; x = f$ele(0," ",rec) ; stop/id=&x ); >> vD >> Wouldn't SHOW SYSTEM /NOHEADING and removing the SEARCH yield the >> same result?- > 2 > Yes - if you want to do a manual eyeball search.G > No - if you want the procedure to find *and extract* the PID's of the1C > vpm_server processes, and kill them without any user intervention 3 > beyond invoking the procedure in the first place.e  = It also should work for the automated case. The only lines inV! SHOW SYSTEM /PROCESS=*vpm_server*C9 that don't sho vpm_server processes are heading lines, soi, SHOW SYSTEM /PROCESS=*vpm_server* /NOHEADING yields the same asD PIPE SHOW SYSTEM /PROCESS=*vpm_server* | SEARCH SYS$INPUT vpm_server  dB > I like it, I will save that code snippet for a day when it might > become useful to me.   Yup, me too.   cu,e   Martin -- tF   OpenVMS:                | Martin Vorlaender  |  VMS & WNT programmer3    The operating system   | work: mv@pdv-systeme.decF    God runs the           |   http://www.pdv-systeme.de/users/martinv/:    earth simulation on.   | home: martin@radiogaga.harz.de   ------------------------------  % Date: Wed, 09 Jul 2003 08:31:00 -0500w1 From: "David J. Dachtera" <djesys.nospam@fsi.net>t/ Subject: Re: problem with MONITOR CLUSTER (VPM) ' Message-ID: <3F0C1914.7B3B50E5@fsi.net>g   Martin Vorlaender wrote: >  > Michael Austin wrote:eC > > do pipe sh sys/proc=*vpm_server* |sear sys$input vpm_server | - > > >  (read sys$pipe rec ; x = f$ele(0," ",rec) ; stop/id=&x ); > C > Wouldn't SHOW SYSTEM /NOHEADING and removing the SEARCH yield the  > same result?   By Gadfrey, he's right!   0 DJAS01::DDACHTERA$ sh sys/nohead/proc=*dachtera*A 00000085 DDACHTERA       CUR      4     1735   0 00:00:02.44     o 1334    112   9 DJAS01::DDACHTERA$ pipe sh sys/nohead/proc=*dachtera* | -eG (read sys$pipe rec ; x = f$ele(0," ",rec) ; say f$getjpi( x, "logintim"s ))  8-JUL-2003 22:16:56.69s   Well, shut my mouth WIDE open!   -- c David J. Dachteras dba DJE Systemsy http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  $ Date: Wed, 9 Jul 2003 01:55:34 -0400  From: John Santos <JOHN@egh.com> Subject: Re: Rethinking V.M.S 4 Message-ID: <1030709012829.636A-100000@Ives.egh.com>  $ On Mon, 7 Jul 2003, Don Sykes wrote:   >  >  > Bob Koehler wrote: > > Y > > In article <3F03225E.AC8837D3@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:  > > >:I > > > In spite of what others have said this deserves some consideration. E > > > While it's true it would not be practical in all situations, inrN > > > environments where there are not a lot of processes running, this may beK > > > possible. As you stated, paging, swapping, related to disk I/O delay,sI > > > could be eliminated, but so could all the cycles related to addressr- > > > translation, working sets and the like.e > > K > >   If you have enough RAM, there isn't any paging or swapping except foreG > >   initially paging in the program when it starts.  So you don't getgF > >   any advantage by taking out the capability (you still have to do/ > >   I/O somehow to get the program into RAM).y > > J > >   There aren't really cycles used up for address translation.  AddressL > >   translation happens in the pipeline parallel to instruction execution.K > >   And you still have to track working sets and the like unless you wantlJ > >   my process to clobber data in your process' space.  Like MS-DOS.  No
 > >   thanks.3 > >  > E > I don't know enough about cpu design to argue that. I was under theoC > impression that EVERY virtual address had to be de-referenced andXI > checked against page tables to see if the subject address's page was insJ > memory or not. Then page it in to the appropriate location. If the AlphaJ > 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 But 99.9999% of the time (number of 9's is just a guess), it is *NOT*dG doing all that.  The CPU always has to do the 1st sentence (dereferenceoF the virtual address and check the page table), but it only has to page1 it in (2nd sentence) if it isn't currently valid.v  C Because the page tables are cached and can't change unless there iswH some kind of interrupt, the 1st sentence usually only takes nanoseconds,F and if the hardware is pipelined, as most if not all modern CPU's are,( it happens in parallel most of the time.   > I > As far as working sets and system page tables, IIRC they are maintainedaE > to track the physical pages in memory assigned to a process. If alleG > pages were already physical, you might still need to track which pageoG > belonged to which process, but not which pages are physical (no one's-. > suggesting a return to an MS DOS style OS!).  C The assumption is invalid memory references are rare (and cause theeB process to crash if not specially trapped.)  All you have to do isA add a few extra instructions to the "invalid memory" trap handleri< in the O/S to decide it is a real access violation or just aC non-resident page fault.  If it's non-resident, you page it back in B (often requiring disk I/O, thus vastly more expensive then the fewF CPU cycles needed to see if it's a page fault or an access violation.)@ Once the page has been made resident and the page table has been& fixed up, you restart the instruction.  @ (Designing the architecture so all instructions a restartable is? probably a performance hit, but I don't think it is serious.  IyC think it is cheaper on RISC than on CISC, since there is less statee@ to fix up.  E.G. look at the VAX string instructions...  I don't know abour EPIC.):  B So if you are going to have memory protection and logical/physical@ address translation (i.e. so a program doesn't always need to be? loaded at the same physical address and in physically contigousi? pages), full virtual memory support (with processes larger thanmC physical memory, or temporarily paged out while other process run),  is almost free.    --   John Santos' Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  $ Date: Wed, 9 Jul 2003 10:28:09 -0230, From: "Jeff Barnes" <barnesjw@dfo-mpo.gc.ca> Subject: Thanksg- Message-ID: <KkUOa.2234$Fy1.101757@localhost>t  K Thanks for your help, and sorry for being rude.  My supporting VMS, OpenVMS.H and Tru64 began with the sentence: "By the way, can you do us a favour?"   To solve I did the following:    Server1# backupl _From: dsk1:[dir...]*.*;* > _To: server2"account password"::dsk2:[dir]saveset.bck/SAVE_SET Total of 1 file.   On server 2:  = $ backup/log saveset.bck/save xxx0:[000000.dir1.dir2...]*.*;*    ------------------------------  $ Date: Wed, 9 Jul 2003 03:54:21 -0400* From: "Bill Todd" <billtodd@metrocast.net> Subject: VMS rolling roadmap2 Message-ID: <_x6cnV8ZKIKlV5aiXTWJjQ@metrocast.net>  H I just had occasion in another context to glance at the infamous rollingH (and presumably therefore up-to-date) VMS roadmap.  And the road *still*# seems pretty much to end next year.i  G The only obvious declarations of features appearing after 2004 involved K minor enhancements to TPC/IP, RTR, and ACMS.  A few notes about (explicitly G *un*committed) 'investigations' of possible future work (in 2005 on theaD slides, but if the *investigations* are only just starting one mightL question that resulting products would actually ship that soon) had appearedJ since the last time I looked, but even they weren't particularly inspiringC (and, of course, conspicuously omitted any mention of that new fileh system...).d   Forewarned is forearmed...   - bill   ------------------------------  # Date: Wed, 09 Jul 2003 10:08:21 GMT ' From: Colin Blake <colin@theblakes.com> 3 Subject: Re: [Mozilla 1.4] bug in pref-advanced.xull: Message-ID: <pQROa.575$5o5.440869@news1.news.adelphia.net>    Peter 'EPLAN' LANGSTOEGER wrote:  G >But strange thing is, that JUNKing did work in MOZILLA 1.3 (on OpenVMSoH >and Win32). And I'm afraid, I already wrote this here (some weeks ago). >$G It was there, but supposedly it wasn't meant to be. Evidently the spam  G filtering techniques which are done for mail don't apply for news. The bI filter controls were there, but the code behind them didn't do anything. >G As explained in http://bugzilla.mozilla.org/show_bug.cgi?id=169638#c149>  5   Although the Junk Mail controls for Newsgroups werei<   supposed to be disabled, they are only partially disabled,@   currently a user can set them up (select checkboxes, whatnot),;   but none of the junkmail controls actually work. They canc5   also mark messages as Junk/Not Junk in newsgroups. t   ------------------------------  $ Date: Wed, 9 Jul 2003 12:09:48 +02008 From: "Tomasz Dryjanski" <tdryjanski.nospam@hotmail.com>, Subject: [spam] Looking for a DLT 7000 drive/ Message-ID: <begplu$l5k$1@atlantis.news.tpi.pl>d  H We need a DLT 7000 (IV) external tape drive. Unfortunately it is already unavailable on the market.K We are ready to take a risk of buying an used drive for a reasonable price.aB Please contact me at tdryjanski@hotmail.com if you are interested.   Sorry for spamming T. D.n   ------------------------------   Date: 9 Jul 2003 05:13:36 -0500-- From: Kilgallen@SpamCop.net (Larry Kilgallen)i0 Subject: Re: [spam] Looking for a DLT 7000 drive3 Message-ID: <OqlxX73s8d$q@eisner.encompasserve.org>n  j In article <begplu$l5k$1@atlantis.news.tpi.pl>, "Tomasz Dryjanski" <tdryjanski.nospam@hotmail.com> writes:J > We need a DLT 7000 (IV) external tape drive. Unfortunately it is already > unavailable on the market.M > We are ready to take a risk of buying an used drive for a reasonable price.9D > Please contact me at tdryjanski@hotmail.com if you are interested. >  > Sorry for spamming  . My inclination would not be to call that spam. But thank you for your concern.p   ------------------------------  $ Date: Wed, 9 Jul 2003 08:23:49 -0400, From: "Island" <dbturner@nospamislandco.com>0 Subject: Re: [spam] Looking for a DLT 7000 drive/ Message-ID: <vgo2fepdo5eh68@news.supernews.com>e   Tomasz  E We have one in stock - in excellent condition with 12 months warrantye   Price is $1795  $ In stock - tested and can ship today+ Comes with a free 5 pack of DLT1V New tapeso   Regards      -- p David B Turner Island Computers US Corporationd 2700 Gregory St., Suite 180b Savannah GA 31404r Tel: 912 447 6622w Fax: 912 201 0402  Email: dbturner@hpaq.net http://www.hpaq.neta   ------------------------------   End of INFO-VAX 2003.376 ************************