1 INFO-VAX	Tue, 15 Apr 2003	Volume 2003 : Issue 208       Contents:7 Re: Alpha emulator - 21172 vs. 21174 logic core chipset @ Communication Problem between process and subprocess via mailboxD Re: Communication Problem between process and subprocess via mailboxD Re: Communication Problem between process and subprocess via mailboxD Re: Communication Problem between process and subprocess via mailboxD Re: Communication Problem between process and subprocess via mailboxD Re: Communication Problem between process and subprocess via mailbox Re: DECnet hacker? Re: DECnet hacker? Re: DECnet hacker?% Re: Excellent new OpenVMS Testimonial 8 Re: Excellent new OpenVMS Testimonial (baggage handling) Re: Fiber channel question Re: Fiber channel question' Re: Need to buy 8 x VAX 4000 or similar ' Re: Need to buy 8 x VAX 4000 or similar P Re: OpenVMS.org: Marvel article and HP's press release for Marveland Alpha RetaiP Re: OpenVMS.org: Marvel article and HP's press release for Marveland Alpha RetaiP OT: Re: starting batch job on windows machine when process on vms alpha complete Re: Process Quota Tuning Re: Process Quota Tuning RE: Process Quota Tuning/ Re: So much for Opteron 32bit compatibility ... / Re: So much for Opteron 32bit compatibility ... / Re: So much for Opteron 32bit compatibility ... @ Re: Spam from HP (was: Email to Geoff.Graves@hp.com is rejected) TOY-battery VAX4000/105A Re: TOY-battery VAX4000/105A VAX C++ 5.6 install question1 Re: VMS Advertising & Marketing - a status report 1 Re: VMS Advertising & Marketing - a status report  Re: What is a VMS Cluster  RE: What is a VMS Cluster  Re: XDM problems (TCPIP 5.3)  F ----------------------------------------------------------------------  + Date: Tue, 15 Apr 2003 11:35:49 +0000 (UTC) 5 From: "John Wallace" <johnwallace4@yahoo.dotco.dotuk> @ Subject: Re: Alpha emulator - 21172 vs. 21174 logic core chipset/ Message-ID: <b7gqqk$rac$1@titan.btinternet.com>   = "Timothy Stark" <sword7nospam@speakeasy.org> wrote in message , news:ufKcnSXzm8eLgQujXTWcqA@speakeasy.net...< > "Dave Weatherall" <djweath@attglobal.net> wrote in message1 > news:DTiotGxQ0bj6-pn2-KIvQbsTlW7So@localhost... I > > Best of luck with the project Tim. Just had an evil thought. An Alpha C > > emulator running in a 64-bit Opteron running VMS faster than on 1 > > Itanium, which is where the evil comes in :-)  > J > Hmmm.  But my Alpha emulator is running slowly.  :-)  I implemented manyJ > emulated instructions on it and ran SRM console successfully.  According toJ > my debug log file, SRM console moved itself to loc 40.0000 from anywhere and H > decompressed itself (like compressed Linux kernel) then finally jumped intoI > loc C000... It took a few seconds to complete decompression.   I now am F > working on logic core emulation for accessing I/O devices right now. > F > Well I have more two questons for you here.  I read my AlphaPC 164LXJ > technical manual and noticed that core logic chipset is 21174 but I haveI > 21171 and 21172 tech docs.  I was looking for 21174 docs but can't find  it. J > What are difference between 21174 and 21172 core logics?  I noticed that not 3 > much difference between their space address maps.  > ! <graphics/serial console snipped>  > Thank you! > Tim Stark  >  >   G Still looking? Given a bit of historical knowledge of these things as a  starter, here's what I found...   K Iirc, the 21172 chipset was developed by Digital Semiconductor folks as the J system/memory interface chipset for 21164. The 21174 was a low-cost singleK chip alternative developed for (by?) the PWS folks and also used on PC164LX K etc. 21174 was often referred to as Pyxis (Google finds lots of Linux/Alpha C references to Pyxis). The manuals below should tell you a lot more.   H Googling for "21172 21174 alpha" and ignoring the initial junk led me toK http://www.cse.unsw.edu.au/~danielp/cs1/l4alpha/alpha_docs.html where there H seems to be an interesting collection of Alpha docs, including 21172 andD 21174 Core Logic Chipset technical manuals. I haven't looked at them (limited net access now).   = Also available at that site, the Alpha Architecture Handbook.   K Google also finds http://www.0xfi.com/oslib/topx.html where there's another J fine collection of "weird stuff", not all correct (e.g. 21164 and 21164 PCE aren't the same chip). But it does have a copy of a Digital Technical E Journal article titled "The Design of the 21174 Memory Controller for I DIGITAL Personal Workstations", and various other bits on Alpha and other  architectures.  . Corrections and clarifications always welcome.  	 good luck  john   ------------------------------    Date: 15 Apr 2003 01:20:22 -07001 From: patrice.patron@euriware.Fr (Patrice PATRON) I Subject: Communication Problem between process and subprocess via mailbox = Message-ID: <ee236176.0304150020.615a5027@posting.google.com>    Hi,   < I try to spawn a command like "run sys$system:authorize" andF communicate with this subprocess using two mailboxes. The first one isF used to send command to the subprocess. The second one is used to read the output of the subprocess.   @ I find an exemple called DISKMOUNT.c and based my program on it.  E Evething goes well as long as use a delayof 0.5 second before reading A the output mailbox. Without this delay, the father process hangs.   C To read the output mailbox I first use a READVBLK code and then use , READVBLK and M_NOW till I receive ENDOFFILE.  F Does any body experience this problem or should I post the C program ?   Thanks   Patrice.   ------------------------------  % Date: Tue, 15 Apr 2003 11:21:21 +0200 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>M Subject: Re: Communication Problem between process and subprocess via mailbox ) Message-ID: <3E9BCF11.1030603@vajhoej.dk>    Patrice PATRON wrote: > > I try to spawn a command like "run sys$system:authorize" andH > communicate with this subprocess using two mailboxes. The first one isH > used to send command to the subprocess. The second one is used to read > the output of the subprocess.  > B > I find an exemple called DISKMOUNT.c and based my program on it. > G > Evething goes well as long as use a delayof 0.5 second before reading C > the output mailbox. Without this delay, the father process hangs.  > E > To read the output mailbox I first use a READVBLK code and then use . > READVBLK and M_NOW till I receive ENDOFFILE.  2 I have code both in C and Macro-32 that does this.   Want me to post it ?   Arne  @ PS: Sometimes a process created with a pseudo-terminal is better&      that a subprocess with mailboxes.   ------------------------------  % Date: Tue, 15 Apr 2003 14:37:34 +0200 3 From: "Patrice Patron" <patrice.patron@euriware.fr> M Subject: Re: Communication Problem between process and subprocess via mailbox & Message-ID: <3e9bfb76$1@news.euriware>   Hi   Yes, thanks if you can post it.    Patrice.  @ "Arne Vajhj" <arne@vajhoej.dk> a crit dans le message de news: 3E9BCF11.1030603@vajhoej.dk... > Patrice PATRON wrote: @ > > I try to spawn a command like "run sys$system:authorize" andJ > > communicate with this subprocess using two mailboxes. The first one isJ > > used to send command to the subprocess. The second one is used to read! > > the output of the subprocess.  > > D > > I find an exemple called DISKMOUNT.c and based my program on it. > > I > > Evething goes well as long as use a delayof 0.5 second before reading E > > the output mailbox. Without this delay, the father process hangs.  > > G > > To read the output mailbox I first use a READVBLK code and then use 0 > > READVBLK and M_NOW till I receive ENDOFFILE. > 4 > I have code both in C and Macro-32 that does this. >  > Want me to post it ? >  > Arne > B > PS: Sometimes a process created with a pseudo-terminal is better( >      that a subprocess with mailboxes. >    ------------------------------  % Date: Tue, 15 Apr 2003 14:38:47 +0200 3 From: "Patrice Patron" <patrice.patron@euriware.fr> M Subject: Re: Communication Problem between process and subprocess via mailbox & Message-ID: <3e9bfbbf$1@news.euriware>   Hi  ! I prefer the C version ... Thanks    Patrice.  @ "Arne Vajhj" <arne@vajhoej.dk> a crit dans le message de news: 3E9BCF11.1030603@vajhoej.dk... > Patrice PATRON wrote: @ > > I try to spawn a command like "run sys$system:authorize" andJ > > communicate with this subprocess using two mailboxes. The first one isJ > > used to send command to the subprocess. The second one is used to read! > > the output of the subprocess.  > > D > > I find an exemple called DISKMOUNT.c and based my program on it. > > I > > Evething goes well as long as use a delayof 0.5 second before reading E > > the output mailbox. Without this delay, the father process hangs.  > > G > > To read the output mailbox I first use a READVBLK code and then use 0 > > READVBLK and M_NOW till I receive ENDOFFILE. > 4 > I have code both in C and Macro-32 that does this. >  > Want me to post it ? >  > Arne > B > PS: Sometimes a process created with a pseudo-terminal is better( >      that a subprocess with mailboxes. >    ------------------------------  % Date: Tue, 15 Apr 2003 15:16:17 +0200 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>M Subject: Re: Communication Problem between process and subprocess via mailbox ) Message-ID: <3E9C0621.7040903@vajhoej.dk>   	 SUBPROC.H 	 ---------    void sub_init(); void sub_put(char *line);  void sub_wait(int n);   int sub_get(char *line,long nb); void sub_end();   	 SUBPROC.C 	 ---------    #include <stdlib.h>  #include <string.h>  #include <descrip.h> #include <clidef.h>  #include <ssdef.h> #include <iodef.h>   short chani,chano; #define maxlinlen 256  char *bigbuf[10000]; int wptr = -1; int rptr = -1;   long sys$crembx(); long lib$spawn();  long sys$qiow(); long lib$wait(float *t);  $ int sub_help_get(char *line,long nb) { )     short read = IO$_READVBLK | IO$M_NOW;      short iosb[4];F     if (sys$qiow(0,chano,read,iosb,0,0,line,nb,0,0,0,0)==SS$_NORMAL) {!        if (iosb[0]==SS$_NORMAL) {            line[iosb[1]] = '\0';            return 1;         } else {            return 0;         }     } else {        return 0;     }  }    void sub_set_ast();    void sub_ast() {      do {        wptr++;*        bigbuf[wptr] = malloc(maxlinlen+1);3     } while (sub_help_get(bigbuf[wptr],maxlinlen));      wptr--;      sub_set_ast();     return;  }    void sub_set_ast() { .     short setatt = IO$_SETMODE | IO$M_WRTATTN;5     sys$qiow(0,chano,setatt,0,0,0,sub_ast,0,0,0,0,0);      return;  }    void sub_init()  {      long messiz = 256;     long bufsiz = 4096;      long flags = CLI$M_NOWAIT;(     $DESCRIPTOR(inpdes,"SUB_INPUT_MBX");*     $DESCRIPTOR(outpdes,"SUB_OUTPUT_MBX");3     sys$crembx(0,&chani,messiz,bufsiz,0,0,&inpdes); 4     sys$crembx(0,&chano,messiz,bufsiz,0,0,&outpdes);     sub_set_ast();=     lib$spawn(0,&inpdes,&outpdes,&flags,0,0,0,0,0,0,0,0,0,0);      return;  }    void sub_put(char *line) { +     short write = IO$_WRITEVBLK | IO$M_NOW; <     sys$qiow(0,chani,write,0,0,0,line,strlen(line),0,0,0,0);     return;  }    void sub_wait(int n) {      float t;
     t = n;     lib$wait(&t);      return;  }    int sub_get(char *line,long nb)  {      if (rptr<wptr) {        rptr++;'        strncpy(line,bigbuf[rptr],nb-1);         line[nb-1] = '\0';         return 1;     } else {        return 0;     }  }    void sub_end() {      long fnd,bool;     char line[81];     sub_put("LOGOUT/BRIEF");     bool=1;      while(bool) {         sub_wait(1); *        fnd = sub_get(line,sizeof(line)-1);        if (!fnd) bool=0;     }      return;  }    ------------------------------  % Date: Tue, 15 Apr 2003 15:19:57 +0200 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>M Subject: Re: Communication Problem between process and subprocess via mailbox ' Message-ID: <3E9C06FD.60404@vajhoej.dk>    Macro-32 version:   7 http://www.vajhoej.dk/anonymous/spawn_mbx/spawn_mbx.zip    Pseudo terminal:  + http://www.vajhoej.dk/anonymous/ptd/ptd.zip    Arne   ------------------------------    Date: 15 Apr 2003 09:12:14 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]> Subject: Re: DECnet hacker? 6 Message-ID: <20030415091214.12127.qmail@gacracker.org>  > On Mon, 14 Apr 2003, "Mark E. Levy" <mlevy70@attbi.com> wrote:3 >"Dean Woodward" <deanw@rdrop.com> wrote in message # >news:3E9AE8B4.1080302@rdrop.com... ! >> Eberhard Heuser-Hofmann wrote: B >> > I've noticed more tries of hacking passwords of vms-machines.C >> > Usually stupid attempts to login as user decnet. There must be % >> > a script that many bad guys use.  >>G >> Hmmm- Not that I've tried to set it up, but I do know that there's a # >> DECnet implementation for Linux.  > M >Maybe so, but what everyone seems to be forgetting is that the Internet will K >not pass DECnet traffic (unless it's encapsulated in TCP packets, but that K >requires that both ends cooperate to set it up - not a likely method for a  >hacker)   <nit> I There's a *lot* of misuse of the terms hacker and hacking in this thread.   I If someone is trying to gain unauthorized access I'd call them a cracker.  </nit>     Doc. --  : Time and money, the psychotropics of the business world...K ~ VAXman                                             https://vmsbox.cjb.net    ------------------------------  + Date: Tue, 15 Apr 2003 13:40:45 +0000 (UTC) + From: david20@alpha2.mdx.ac.uk (David Webb)  Subject: Re: DECnet hacker? * Message-ID: <b7h24t$n4$1@aquila.mdx.ac.uk>  Y In article <1030414114609.18347B-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes: % >On Mon, 14 Apr 2003, JF Mezei wrote:  >  >> David Froble wrote:N >> > Think about that idea.  One thing about VMS, it never shows passwords, toU >> > anyone.  You're asking to see a password.  Yeah fine idea if it's someone trying S >> > to break into the system.  But what if it's a valid user who just mistyped the  >> > username or password. >>  P >> We are talking about displaying passwords for FTP "anonymous" only. Since oneP >> wants to know if a somewhat valid email address is being supplied, or if theyQ >> truly send junk (or perhas the same "ramdom" password for attempts coming from  >> different IP adresses). > D >BTW, Dave - it is a common convention for anonymous FTP, but for noD >other protocol I've ever encountered, to send your email address asD >the password, which isn't otherwise used.  I think the FTP protocolD >doesn't treat "anonymous" any differently than any other user name,E >so you have to send *something* for the password, but the FTP server ; >ignores it if it allows anonymous logins.  I don't know if @ >the common VMS FTP servers record the passwords for "anonymous"@ >anywhere (so you can tell who has been using your system.)  And$ >of course, the bad guys always lie! > P DEC TCPIP services records the password/ident string you supply when logging in $ to the anonymous ftp account in the   0 SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG   file   eg  5 TAIL SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG   O 15-APR-2003 14:37:01.34 User:anonymous logged in ident:mytestident@testing from  Host:alpha2 K 15-APR-2003 14:37:08.16 User:anonymous ident:mytestident@testing logged out     
 David webb VMS and Unix team leader CCSS Middlesex University    @ >I think it is pretty unlikely that anyone would have a username> >sufficiently close to "anonymous" that they could generate it@ >by accident, but someone could get distracted while logging in,A >and type anonymous for the username, but then type their regular 2 >(secret) password instead of their email address. > C >However, I think it is the job of the FTP server, not the security B >audit server, to record email addresses for anonymous logins.  It@ >is very much a special case, and you (the system manager of the: >FTP server) are probably just as interested in successful? >anonymous logins as in failures.  (Why would there be failures = >if you have enabled anonymous FTP?)  I'm pretty sure the VMS < >security audit server doesn't record passwords on sucessful >logins, anyway. >  >--  >John Santos >Evans Griffiths & Hart, Inc.  >781-861-0670 ext 539  >    ------------------------------  % Date: Tue, 15 Apr 2003 10:29:12 -0400 ( From: David Froble <davef@tsoft-inc.com> Subject: Re: DECnet hacker? , Message-ID: <3E9C1738.8060909@tsoft-inc.com>   David J. Dachtera wrote:   > David Froble wrote:  >  >>David J. Dachtera wrote: >> >> >>>JF Mezei wrote: >>>  >>> / >>>>>>Process name:             TCPIP$FTPC00017 ) >>>>>>Username:                 anonymous 0 >>>>>>Remote nodename:          f16v-1-57.d1.clu2 >>>>>>Remote node id:           3569600569 (50.57), >>>>>>Remote username:          FTP_D4C3C839 >>>>>> >>>>>>R >>>>I think that this opcom message really needs to be spruced up. I'd like to seeO >>>>real dotted decimal TCPIP node names instead of a single integer we have to / >>>>break up to find out what the real address.  >>>> >>>>
 >>>Agreed. >>>  >>>  >>> Z >>>>Also, it would be interesting to see the "password" in the case of anonymous attempts. >>>> >>>> >>>Whole-heartedly agreed! >>> K >>Think about that idea.  One thing about VMS, it never shows passwords, to 
 >>anyone.  >> > = > 1. LOGFAILs as logged to OPCOM include the failed password.  > % > 2. NCP under certain circumstances.     P Ok, got me there.  I'm a software person, not operations, and I just don't look  at such.  J However, I could still present an argument that even such as you describe P shouldn't happen.  SYSUAF.DAT is secured, but still passwords are not readable. J   Why should even failed passwords be available anywhere?  Just a concept.   Dave   --  4 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: Tue, 15 Apr 2003 18:23:43 +0200 $ From: Michael Unger <unger@decus.de>. Subject: Re: Excellent new OpenVMS Testimonial* Message-ID: <00A1E704.9BCB1344.8@decus.de>   "Sue Skonetski" wrote:   > Dear Newsgroup,  > C > Warren has put up a new customer testimonial on the web site. The C > customer is  Fraport (Frankfurt, Germany airport).  Please take a G > moment to look at this.  I think it is excellent. Marc Courchesne and 8 > Guenter Krieble are the HP folks responsible for this.   Quoting from page 3:  
 <start quote>    future visions   Over the next decade [...]  G Tomorrow, as today, OpenVMS AlphaServer systems will be on board, [...]    <end quote>   C AlphaServers over the next decade -- that's at least misleading :-)   8 I don't think Fraport wants to rely on "legacy systems".   Michael    ------------------------------    Date: 15 Apr 2003 07:11:26 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) A Subject: Re: Excellent new OpenVMS Testimonial (baggage handling) 3 Message-ID: <6ZB6nSZjPdbv@eisner.encompasserve.org>   p In article <857e9e41.0304141436.382fdd0@posting.google.com>, susan_skonetski@hotmail.com (Sue Skonetski) writes: > Dear Newsgroup,  > C > Warren has put up a new customer testimonial on the web site. The C > customer is  Fraport (Frankfurt, Germany airport).  Please take a G > moment to look at this.  I think it is excellent. Marc Courchesne and 8 > Guenter Krieble are the HP folks responsible for this.   Newsgroup, the URL is:  5 	http://h71000.www7.hp.com/openvms/brochures/fraport/    Sue:  = 	This baggage handling application appears to be custom-built < 	for the Frankfurt airport.  Please ask them to market it to 	North American airports.    Larry Kilgallen F got my box of food back in Boston 12 days after the sailboat for which< it was destined had left the dock in Baja California Sur :-(   ------------------------------  % Date: Mon, 14 Apr 2003 23:33:15 +0100 * From: "John Travell" <john@travell.uk.net># Subject: Re: Fiber channel question 4 Message-ID: <b7gaio$kfgk$1@ID-120847.news.dfncis.de>  & <brandon@dalsemi.com> wrote in message+ news:03041417033478@dscis6-0.dalsemi.com... . > > Bart Zorn [B.Zorn@xs4all.nospam.nl] wrote:K > > Th SRM console of an Alphaserver has limited resources and can normally I > > only hold the information of up to four FC disks. Those disks must be  > E > Is it four or is it one?  I thought it was one.  Correct me if I am 	 wrong - I K > am not about to crash my server to find out! ;-)  Is it a new Firmware or  is; > it the GS140?  It has been awhile since I WWID.  Curious.  > H > With a properly configured SAN you have four access paths to the disk." > Two adapters in your VMS server: >     Adapter # 1 to hub # 1.  >     Adapter # 2 to hub # 2.  > Two SAN hubs: 6 >     Hub # 1 Path # 1 to controller # 1 primary port.6 >     Hub # 1 Path # 2 to controller # 2 primary port.8 >     Hub # 2 Path # 1 to controller # 1 secondary port.8 >     Hub # 2 Path # 2 to controller # 2 secondary port.4 > Two controllers (HSG80 redundant/multi-path pair):< >     Each controller has a primary port and secondary port.# >     Four ports, four connections.  > - > That is where you get the four connections.  > D Yes, but the fun comes when your system disk is a shadow set, with aG potential 3 members, and 4 paths to each member, you have a total of 12  paths.@ Now consider what happens when it is time to write a bugcheck...L The console (SRM) writes the dump to the first active path that it finds. ItG has no way of knowing whether the disk that path goes to is the current G master member of the shadow set, or even a current member at all!. This F leaves you with the interesting situation that dumpfile writes fail at random. I Either they get written to a slave member, then the merge copy overwrites E the dump with the previous content, or none of the paths known to the " console is a currently valid path.! This leaves you with two choices. 6 1. dump to a non-shadowed device (DOSD or system disk)/ 2. accept random dumpfile write failures... :-(   6 Engineering know about this, I made certain of that...L I suggested a possible solution, but it is one that can only work IF VMS can' write to the console variable DUMP_DEV.    -- John Travell  VMS crashdump expertise for hire john@travell.uk.net  http://www.travell.uk.net/       --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003    ------------------------------  % Date: Tue, 15 Apr 2003 07:15:43 -0500  From: brandon@dalsemi.com # Subject: Re: Fiber channel question 1 Message-ID: <03041507154305@dscis6-0.dalsemi.com>   F > Yes, but the fun comes when your system disk is a shadow set, with aI > potential 3 members, and 4 paths to each member, you have a total of 12  > paths.  L Double Damn.  I think I will stay with hardware based RAID.  - Not to strike" up more threads on this issue...    B > Now consider what happens when it is time to write a bugcheck...N > The console (SRM) writes the dump to the first active path that it finds. ItI > has no way of knowing whether the disk that path goes to is the current I > master member of the shadow set, or even a current member at all!. This H > leaves you with the interesting situation that dumpfile writes fail at	 > random.   O So what you are telling me here - The SRM will write the dump file to the first M path and since SW volume shadowing no longer exists (due to the bugcheck) the L dump will be written to only one volume - not its mirror set.  Therefore youN have two split volumes.  On subsequent boot is SW volume shadowing intelligent enough to merge this properly?  K > Either they get written to a slave member, then the merge copy overwrites G > the dump with the previous content, or none of the paths known to the $ > console is a currently valid path.# > This leaves you with two choices. 8 > 1. dump to a non-shadowed device (DOSD or system disk)1 > 2. accept random dumpfile write failures... :-(   ( Sort of answers my question with a "No".  8 > Engineering know about this, I made certain of that...N > I suggested a possible solution, but it is one that can only work IF VMS can) > write to the console variable DUMP_DEV.   5 I think I will stick with a hardware RAID solution.       Thanks for the INFO!  gasp-argh!   John Brandon VMS Systems Administrator  Dallas Semiconductor john.brandon@dalsemi.com 972.371.4172 wk  972.371.4003 fx    ------------------------------  % Date: Tue, 15 Apr 2003 10:11:58 -0400 < From: "Peter Weaver" <WeaverConsultingServices@sympatico.ca>0 Subject: Re: Need to buy 8 x VAX 4000 or similar4 Message-ID: <b7h3vh$rsor$1@ID-141708.news.dfncis.de>   David J. Dachtera wrote: > Peter Weaver wrote:  >> >...; > From SRI. Stan Q. may have mentioned some numbers at some  point, also.; > It ain't cheap, certainly not cheaper thanthe Intel boxes  some > versions run on.  ; Does "From SRI" mean that you have an actual quote with the 9 price, or is this "I think I remember seeing some numbers ; someplace?" The numbers I looked at yesterday came directly > from SRI about 2 years ago, I do not know if they have changed much since then.   >> When we looked at. >> Charon-VAX the pricing was very reasonable. > 9 > Compared to what? The original price of a VAX-9000? The 
 price of a > GS160? ...GS1280?   2 Compared to a few months of maintenance on a MVII.   >> Existing licenses. >> could be moved for a low transfer fee also. > ; > ...but you still need two of them when Charon-VAX runs on 4 > OpenVMS-Alpha: the Alpha base license plus the VAX license(s).    Someone else posted > http://h71000.www7.hp.com/openvms/sri-charon-vax-emulator.html> , it shows that you can transfer the VAX licenses to the Alpha0 based Charon-VAX with HP's approval and support.   -- Peter Weaver Weaver Consulting Services Inc. ) Serving Southern Ontario/Western New York    ------------------------------  % Date: Tue, 15 Apr 2003 12:26:43 -0400 . From: "Rob Lyons" <rob.lyons@resilientsys.com>0 Subject: Re: Need to buy 8 x VAX 4000 or similar+ Message-ID: <b7hbtq$1qp$1@bob.news.rcn.net>   \ David J. Dachtera <djesys.nospam@fsi.net> wrote in message news:3E9B6994.22A13A0A@fsi.net...   > > Existing licenses / > > could be moved for a low transfer fee also.  > J > ...but you still need two of them when Charon-VAX runs on OpenVMS-Alpha:1 > the Alpha base license plus the VAX license(s).   B That is the nature of the beast.  Charon emulator technology gives: you the opportunity to "transplant" your VAX programs to a; contemporary host system.  That host system needs operating < software (Win2K, XP, VMS, Linux) but the operating system isD totally separate and only needs to be bare bones.  Also, it's betterC if the host system has limited other software so you aren't tempted ! into using it for other purposes.   : You can't expect HP to give away the Alpha OS on the host,6 just because there may be a VAX version of VMS running= at an upper layer. Actually, one economy available is to have ; the host Alpha perform backup of the VAX disks or container 2 files, which directly uses that copy of Alpha-VMS.  	 Rob Lyons  Resilient System, Inc.   ------------------------------  % Date: Tue, 15 Apr 2003 12:40:24 +0100 ' From: Andrew Harrison SUNUK Consultancy Y Subject: Re: OpenVMS.org: Marvel article and HP's press release for Marveland Alpha Retai . Message-ID: <3E9BEFA8.1000108@nospamn.sun.com>   jlsue wrote:G > On Mon, 07 Apr 2003 17:50:14 +0100, Andrew Harrison SUNUK Consultancy 0 > <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >  >  >> >>jlsue wrote: >  >     6 A whole load of BS going over the same ground snipped.  ? >>While you are at it, what was the performance improvement for ; >>the hardware alone ??? Surely if you can apparently be so < >>sure what the perfromance bump for the 7.3 upgrade was you: >>can also publish what the 8400->160 upgrade did for them >>if it isn't 28%. >  > G > Not necessary to support my argument.  This is yet another attempt to F > deflect the discussion somewhere else.  Too bad it won't work.  ThisA > is a happy GS160 customer, whether you like to admit it or not.  >   ? Entirely necessary to support your argument. Because without it = you simply don't have a case. If as you claim the 7.3 upgrade < was the gold plating on the lily then what was the impact of' moving from 8400->GS160, you must know.   E Had you considered why they ran with a pre release version of OpenVMS + on a mission critical production system ???   C I would guess that the GS160 upgrade didn't deliver the performance B they were expecting and that they had to go to 7.3 to get improved
 NUMA support.   B Now in the total absence on your part of any supporting data aboutC the total performance improvement of moving to GS160's which should B based on numbers of CPU's and CPU performance improvements be over( 200% this is a perfectly sensible guess.  D If you cannot provide the numbers then you simply don't have a case.   >  >>I >>>One other thing you seem to miss in the GS vs Turbolaser discussion is F >>>the scalability of the GS.  Sure, it has a slower QBB-to-QBB memoryA >>>transfer rate, but the scalability is much better - especially H >>>compared to the Turbolaser.  The 8400's really didn't scale well whenF >>>you got into the higher cpu counts.  The additional cpus would giveI >>>you some added benefit, but the benefit decreases significantly, while E >>>the GS decreases less significantly.  So while there is additional G >>>latency, it can still provide greater growth potential due to better  >>>scalability of the CPU. >>>  >>; >>Ahh now you have got quite close to the real issue. Shall  >>I help you out.  >>* >>Firstly we need to clarify a few points. >>8 >>1. QBB -> QBB memory bandwidth is higher than the 84006 >>   interconnect bandwidth. Minimum QBB -> QBB memory< >>   latency is higher than the 8400 minimum memory latency. >>9 >>2. QBB onboard memory bandwidth is also higher than the 6 >>   total interconnect bandwidth on 8400. However QBB6 >>   minimum onboard memory latency is longer than the! >>   8400 minimum memory latency.  >  > B > Yes, I understand that, but the overall throughput that the 8400E > actually gets, with 12 processors, is still possibly much less than  > the GS160. >    Sure it is but:   8 1   The break even point is much higher than people were7      expecting. In fact they were led to believe that a >      GS160/320 with an equal number of CPU's would out perform5      an equal CPU'd 8400/GS140. This wasn't the case.   A 2   People have had to do much more work to get better throughput A      protracted waits for NUMA optimised versions of OpenVMS, OPS ?      in a box, 1 GHz CPU's with larger caches etc. Bank Austria @      deploying a pre-release version of OpenVMS 7.3 on a mission?      critical core system and then having to upgrade to the FCS %      release being a perfect example.    >  >>Now a bit of background. >>? >>Your own performance white papers indicate that for something 9 >>like a DBMS over 50% of the wall clock time is actually 5 >>spent with the CPU stalled waiting for main memory.  >>D >>http://research.compaq.com/wrl/DECarchives/DTJ/DTJO01/DTJO01HM.HTM >  > < > This URL brings up the 4100s performance characterization. >  >   2 Sure but if you had read it you would have noticed1 that it tells you what the CPI, D-Cache miss rate 3 etc is for TPC-C and SPEC. This should be very very 5 helpfull in getting you to a point where you actually 3 figure out what the problem with GS320's is and why 4 this isn't a specific localised problem but an issue4 that will effect the majority of apps running on the	 platform.        > B >>Your comments about 8400 scalability will also come as a suprise? >>to people who were on the receiving end of the 8400 marketing  >>campaign.  >> >  > A > Ho hum... as if you/Sun are (or have been) lilly white in their H > marketing claims over the years.  Everyone sells their products in the? > best way they can, and that includes Sun.  When I worked as a H > customer, I was on the receiving end of lots of Sun bullshit, so don'tB > cry foul when you see something you don't like from anyone else.  > Look you claimed that the GS320 was the worlds fastest server.  9 Fact, you were unable to support this claim.  Crying foul 6 in this situation isn't unsuprising because your claim was demonstrably untrue.  8 Now if this had been an isolated instance then you couldA be forgiven, perhaps a rush of blood to a marketing persons head.n  = But these claims were also made for the GS140 and before that 5 the 8400, neither justified by any tests and like thea5 GS320 claim so far from the truth as to be laughable.   8 Put your claims for the 8400 in perspective, you claimed: world leading performance, in reality the 8400 was roughly8 equivalent in performance to a Sun E4500 which was a mid range Sun server.   > I challenge you to trawl back through all the public benchmark> results for the 8400-GS140-GS320, compare them with Sun/HP/IBM< results for those tests at the same time, you will find that? except for period between the introduction of the 8400 and whenl9 Sun introduced the E4500-E10K there is no time when the 3n4 servers held a performance lead over Sun/HP and IBM.  < There is a history around Alpha servers of hugely optimistic9 performance claims which have never been supported by anyM collateral.    regards  Andrew Harrisone   ------------------------------  # Date: Tue, 15 Apr 2003 18:26:14 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>Y Subject: Re: OpenVMS.org: Marvel article and HP's press release for Marveland Alpha Retaip8 Message-ID: <aafo9vo78r3fjv7ab7vg6f7uv65s986d6i@4ax.com>  E On Mon, 14 Apr 2003 17:50:15 +0100, Andrew Harrison SUNUK Consultancy . <Andrew_No.Harrison_No@nospamn.sun.com> wrote:   >s >j
 >jlsue wrote:t   >> 4G >> Bullshit it doesn't.  I don't care *how many* times you tell me.  It F >> says specifically, in an EXACT QUOTE, that the vms upgrade gave theH >> 28% performance increase.  I have provided proof, within the article,I >> to support my claim.  Your position is only one of conjecture based on-" >> your own self-serving opinions. >> aI >> You can keep repeating your lies, but you can't support it with actualc% >> data/info/quotes from the article.p >> u >oD >So tell us what was the impact of moving from Turbolaser to GS160 !  B I don't have to find or present that information because it is notA germane to my side of this discussion:  They are happy customers.vF The 28% improvement from the VMS upgrade is just a side issue that you@ bring out because you can't counter it with anything meaningful.   >iA >You claim that the customer reference is for the VMS upgrade and4@ >you claim that the result of this upgrade was a 28% performance= >improvement. That means that the customer has measured theiri= >performance in which case they must have the results for thei >TurboLaser upgrade. >s9 >If you cannot find these numbers then I suggest that youc >stop BSing and give it a rest.0  D You give it a rest.  There is nothing in my argument that depends onD these numbers, so it's not necessary for me to show them.  There are> some possible answers to your inquiry, including these two for example:  E 1.  The GS160 upgrade gave them zero improvement, but after upgrading $ to VMS 7.3 they got 28% improvement.   	ORa  F 2.  The GS160 upgrade gave them great performance improvement, but the( VMS upgrade gave them an additional 28%.  C Both of us are only guessing which it may be, but the difference is 2 that my argument doesn't depend on either outcome.  C In any case, they are HAPPY.  Do you have anything to counter that?e     >>  G >> There's no reason to provide exact numbers, I only make claims abouttF >> *happy customers existing* - why do you keep harping about specificG >> performance numbers?  YOU are the only one here that keeps insistingaF >> specific performance problems, that is why you are stuck looking atD >> numbers.  I have provided two examples of happy customers, and myI >> argument is that the performance "numbers" that you keep harping about ! >> does not tell the whole story.  >> ) >h3 >Oh come on how much of an idiot do you need to be.i >f2 >[snip useless issues that we have already hashed,  > but which you refuse to admit] >u5 >And you have the idiocity to claim that there are nom5 >performance problems, without yourself being able toi4 >provide on concrete example that stands scrutiny to >support your conjecture.m  B You would have a point if you didn't lie about my claims.  I claimC that, in the real world, the benchmarks don't tell the whole story,iF and that there are happy customers.   But YOU claim that there can notE be ANY happy customers based on generic information.  I did NOT claimoA that there are no performance problems.  And I gave TWO "concrete D examples" to support my claim.  And you have nothing to counter them/ except bland, experimental, generic benchmarks.   E The thing is, my position is much easier to prove, and your is easierlD to disprove.  I only have to find ONE counter argument to support myA logical argument and disprove yours.  That's why your claim is soj	 hopeless.i  E Why do you spend so much time on this?  You haven't provided anythingeA to prove that my real claim is wrong.  If you have something thatoB shows these two articles are no longer valid - e.g., the customersB have switched to something else because they were unhappy with theE GS160 - then show it.  If not, then you have nothing to counter with.t   >h6 >And then to cap it all you accuse me of being a lying9 >bullshitter. You really need to get in front of a mirror  >more often.  F Yeah, whatever.  I support my claim with exact quotes, and you counterC with wishful thinking.  If what you believe is correct, why haven'tVB you been able to provide any concrete proof of that?   Could it be1 that you are incapable of supporting YOUR claims?    >> t6 >> They are still happy GS customers.  Like it or not. >> - >-: >How the heck do you know, they are all references written >before they got the boxes.e  E Not true.  Re-read them.  One even standardized on the systems.  TheyrA have them, that's what these win references are all about - happya
 customers.   >e6 >Incedentally how many Sequent boxes are sold today ??  * Andrew Harrison, king of the non sequitur.   ------------------------------  + Date: Tue, 15 Apr 2003 14:35:59 +0000 (UTC) , From: lewis@PROBE.mitre.org (Keith A. Lewis)Y Subject: OT: Re: starting batch job on windows machine when process on vms alpha complete . Message-ID: <b7h5cf$84o$1@newslocal.mitre.org>  u riplips <riplips_member@newsguy.com> writes in article <b7el820579@drn.newsguy.com> dated 14 Apr 2003 08:48:18 -0700:pQ >Does windoz have a rshd (rsh deamon)? I've never been able to find one. It wouldeL >be nice to just send an rsh command to windoz that kicks off the .bat file.   Here's one.?   http://www.csa.ru/~il/rsh/  + --Keith Lewis              klewis$mitre.org > The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Tue, 15 Apr 2003 06:36:09 GMT"2 From: Mike Rechtman <michael.rechtman@digital.com>! Subject: Re: Process Quota Tunings+ Message-ID: <3E9BD1FA.3589AAE7@digital.com>$   Jeff Cameron wrote:  > G > On 4/14/03 5:01 PM, in article 7qycnaQisrap0QajXTWcpg@brightview.com,.6 > "Jefferson Humber" <matrix01@globalnet.co.uk> wrote: > O > > Does anybody have any good DCL scripts for monitoring quota usage levels ofs > > running processes. > >nP > > I have one DCL command procedure in which you pass the PID of the process toO > > be monitored.  It monitors a few quota levels retrievable through F$GETJPI, G > > and records the highest noted usage of each quota since the command  > > procedure has been running.g > > . ...<DCL command-file & other stuff snipped>...     ..Or the following C code - 8 undocumented, unsupported, take it and make it your own.7 Possibly a trifle more efficient than DCL. Let me know d9 what you find wrong (I'm not quite sure of the percentage. calculation)   ...<start code>... # include <stdio.h>. # include <stdlib.h> # include <string.h> # include <signal.h> # include <ssdef.h>p # include <stsdef.h> # include <jpidef.h> # include <fscndef.h>  # include <descrip.h>- # include <ctype.h>  # include <starlet.h>4  J /*************************************************************************E         This program is not warranted in any manner, shape or form togB         perform any useful task. It is guaranteed to contain bugs.D         Its use and the interpretation of any results is left solely6         to the discretion and imagination of the user.5         No claims are made or implied by its release. G         Any distribution of this program MUST include the above notice,g1         and the following copyright information :c  '                 (c) Mike Rechtman 1995   8                 M O D I F I C A T I O N    H I S T O R Y    &         VER/ED  EDIT DATE       REASON  5         01.00   Oct.,1995       First implementation g  ;                                         Mike Rechtman, 1995i  J *************************************************************************/    7 /* Define item for system services list: 3 longwords */E  B typedef struct  {       short buflen,   /* output buffer length */                          itmcode;<                         void *buffer;   /* buffer address */H                         void *retlen;   /* address of returned length */                 } ITEM3 ;-     char    imagename[80],         username[16],1         procname[16],?         nodename[8],         user[16],j         uic_str[32],         contr_str[4] = "!%I",e         bold[5] = "\033[1m",         unbold[5] = "\033[0m",!         clear_EOS[5] = "\033[0J",-         terminal[10],          access_port[80],%         s_tick[3],s_sec[3],s_min[3] ;h   char    *temp ;    char    *pretty( char[] ) ;  void    curpos( int,int ) ;b void    wipescreen( ) ;  void    wipeline( int ) ;c   int     pid,         job_type,>         ast_cnt,         byio_lim,h         byio_cnt,n         byte_lim,b         byte_cnt,r         enq_lim,         enq_cnt,         fil_cnt,         free_cnt,s         pgfl_quota,i         pgfl_cnt,          ws_ext,          ws_size,         ws_peak,         cpu_time,M         dirio,         dirio_cnt,         dirio_lim,         prior,         base_prior,A         uic,         tick,sec,min,hour,         l1, l2, l3, l4,          l5, l6, l7, l8,1         l9, l10, l11, l12,         l13, l14, l15, l16,          l17, l18, l19, l20,          l21, l22 ;   float   temp_f ;  ! $DESCRIPTOR(user_desc, username);+! $DESCRIPTOR(proc_desc, procname);x" $DESCRIPTOR(imag_desc, imagename);! $DESCRIPTOR(node_desc, nodename);p! $DESCRIPTOR(term_desc, terminal);u% $DESCRIPTOR(acces_desc, access_port); # $DESCRIPTOR(contr_desc, contr_str);A $DESCRIPTOR(uic_desc, uic_str);,   ITEM3   item_list[29] = { H                 {12, JPI$_USERNAME, username,  &user_desc.dsc$w_length},H                 {15, JPI$_PRCNAM  , procname,  &proc_desc.dsc$w_length},H                 {70, JPI$_IMAGNAME, imagename, &imag_desc.dsc$w_length},H                 {8,  JPI$_NODENAME, nodename,  &node_desc.dsc$w_length},H                 {8,  JPI$_TERMINAL, terminal,  &term_desc.dsc$w_length},5                 {80, JPI$_TT_ACCPORNAM, access_port, s &acces_desc.dsc$w_length},8                 {4, JPI$_ASTCNT     , &ast_cnt,   &l1 },8                 {4, JPI$_BIOLM      , &byio_lim,  &l2 },8                 {4, JPI$_BIOCNT     , &byio_cnt,  &l3 },8                 {4, JPI$_BYTLM      , &byte_lim,  &l4 },8                 {4, JPI$_BYTCNT     , &byte_cnt,  &l5 },8                 {4, JPI$_ENQLM      , &enq_lim,   &l6 },8                 {4, JPI$_ENQCNT     , &enq_cnt,   &l7 },8                 {4, JPI$_FILCNT     , &fil_cnt,   &l8 },8                 {4, JPI$_FREPTECNT  , &free_cnt,  &l9 },8                 {4, JPI$_PGFLQUOTA  , &pgfl_quota,&l10},8                 {4, JPI$_PAGFILCNT  , &pgfl_cnt,  &l11},8                 {4, JPI$_JOBTYPE    , &job_type,  &l12},8                 {4, JPI$_WSSIZE     , &ws_size,   &l13},8                 {4, JPI$_WSPEAK     , &ws_peak,   &l14},8                 {4, JPI$_WSEXTENT   , &ws_ext,    &l15},8                 {4, JPI$_CPUTIM     , &cpu_time,  &l16},8                 {4, JPI$_DIOCNT     , &dirio_cnt, &l17},8                 {4, JPI$_DIOLM      , &dirio_lim, &l18},8                 {4, JPI$_PRI        , &prior,     &l19},8                 {4, JPI$_PRIB       , &base_prior,&l20},8                 {4, JPI$_UIC        , &uic       ,&l21},8                 {4, JPI$_DIRIO      , &dirio,     &l22},                 {0, 0, 0, 0}                 } ;        main( argc, argv ) int     argc ; char    *argv[] ;>	         {e                 int x,                 sleep_time = 2,                  status = 1 ;         char    a;           if ( argc == 3 )                 {UE                 if ( ( argv[2][0] <= '9' ) && ( argv[2][0] > '0' ) &&s<                                 ( strlen( argv[2] ) <= 2 ) )6                         sleep_time = atoi( argv[2] ) ;                 else                         {wH                         printf( "Illegal sleep time %s \n\n",argv[2] ) ;.                         return SS$_BADPARAM  ;                         }e                 }o         else                 {y                  if ( argc != 2 )                         { @                         printf( "Illegal parameter count.\n" ) ;C                         printf( "Usage is: \n$ MONP*ROC :== $%s\n", 3                                 pretty(argv[0]) ) ;tG                         printf( "$ MONPROC <Hex-pid> [sleep_time] \n" )  ;t;                         printf( "[sleep-time] defaults to 2e seconds.\n\n" );?                         if ( argc != 1 ) return SS$_BADPARAM  ;b+                         return SS$_NORMAL ;                          }u                 }0  .         if ( sleep_time < 1 ) sleep_time = 1 ;0         if ( sleep_time > 60 ) sleep_time = 60 ;           temp = argv[1] ;B         if ( ( temp[1] == '%' ) && ( toupper( temp[2] ) == 'X' ) )!                 temp = temp + 2 ;a  1         if ( sscanf( argv[1], "%x", &pid ) != 1 )d                 {t;                 printf( "Illegal hex PID %s\n", argv[1] ) ;l&                 return SS$_BADPARAM  ;                 }            wipescreen() ;           while ( 1 == 1 )                 {l  $                 /* prime the pump */                 x = 0 ;i  !                 while  ( x <= 5 )y                         {aG                         status = sys$getjpiw( 0, &pid, 0, item_list, 0,. 0, 0 ) ;  ?                         if ( ( status & STS$M_SUCCESS ) == 0 &&oD                                 ( status != SS$_SUSPENDED ) ) return status ;  6                         if ( status == SS$_SUSPENDED )!                                 {e0                                 curpos( 22,1 ) ;G                                 printf( "Process currently suspended" )  ;o0                                 curpos( 23,1 ) ;5                                 sleep( sleep_time ) ; %                                 x++ ; C                                 if ( x > 5 ) return SS$_SUSPENDED ;E!                                 }r(                         else    x = 99 ;                         }u  9                 username[user_desc.dsc$w_length] = '\0' ;G9                 procname[proc_desc.dsc$w_length] = '\0' ;N:                 imagename[imag_desc.dsc$w_length] = '\0' ;9                 nodename[node_desc.dsc$w_length] = '\0' ;29                 terminal[term_desc.dsc$w_length] = '\0' ;g=                 access_port[acces_desc.dsc$w_length] = '\0' ;e             /*      Output: */                   wipeline( 2 ) ;d"         /*      curpos( 2,1 ) ; */  6                 printf( "Username: %s%s%s              ",bold,username,unbold );t                 curpos (2,25) ;p8                 printf( "Process name: %s ", procname );                   curpos (2,48) ;i#                 switch ( job_type )n                 {t%                 case JPI$K_DETACHED :t                         {d/                         printf( " Detached" ) ;                          break ;                          })$                 case JPI$K_NETWORK :                         { .                         printf( " Network" ) ;                         break ;P                         } "                 case JPI$K_BATCH :                         { ,                         printf( " Batch" ) ;                         break ;8                         }-"                 case JPI$K_LOCAL :                         {0,                         printf( " Local" ) ;                         break ;e                         }@#                 case JPI$K_DIALUP :r                         {e-                         printf( " Dialup" ) ;J                         break ;>                         }C#                 case JPI$K_REMOTE :                          {>-                         printf( " Remote" ) ;>                         break ;0                         }u                 default :8                         break ;h                 }g  F                 status = sys$fao( &contr_desc,&x,&uic_desc,uic,uic ) ;#                 uic_str[x] = '\0' ;i                    curpos( 2,58 ) ;.                 printf( "UIC:%s  ", uic_str );                     wipeline( 3 ) ;                   curpos( 3,25 ) ;8                 printf( "PID %8X on %s",pid,nodename ) ;                  curpos( 3,49 ) ;)                 printf( "%s",terminal ) ;                    curpos (3,58) ; <                 printf( (acces_desc.dsc$w_length==0) ? " " :-                         "(%s)",access_port );n                   wipeline( 5 ) ;e2                 temp_f = ( byio_lim == 0 ) ? 0 : ( 100.*byio_cnt/byio_lim ) ;*         /*      curpos( 5,1 ) ;         */<                 printf( "Buffer. IO limit: %d ",byio_lim ) ;                  curpos( 5,33 ) ;;                 printf( "Buffered IO free: %d ",byio_cnt );a                  curpos( 5,62 ) ;7                 if ( (temp_f > 0.0) && (temp_f < 5.0) )- printf("%s",bold) ; ;                 printf( "Free: %3.1f%%%s",temp_f,unbold ) ;c                   wipeline( 6 ) ;i0                 temp_f = ( byte_lim == 0 ) ? 0 :C                         100.-( 100.*(byte_lim-byte_cnt)/byte_lim) ;0                 curpos( 6,7 );5                 printf( "Byte limit: %d ",byte_lim );e                 curpos( 6,39 );A6                 printf( "Byte. free: %d ",byte_cnt ) ;                  curpos( 6,62 ) ;7                 if ( (temp_f > 0.0) && (temp_f < 5.0) )  printf("%s",bold) ;o;                 printf( "Free: %3.1f%%%s",temp_f,unbold ) ;                    wipeline( 7 ) ;e3                 temp_f = ( dirio_lim == 0 ) ? 0 : (P 100.*dirio_cnt/dirio_lim) ; "         /*      curpos( 7,1 );  */<                 printf( "Direct I/O limit: %d ",dirio_lim );                 curpos( 7,34 ); ;                 printf( "Direct I/O free: %d ",dirio_cnt );e                  curpos( 7,62 ) ;7                 if ( (temp_f > 0.0) && (temp_f < 5.0) )o printf("%s",bold) ;e;                 printf( "Free: %3.1f%%%s",temp_f,unbold ) ;5                   wipeline( 8 ) ;g4                 temp_f = ( pgfl_quota == 0 ) ? 0 : ( 100.*pgfl_cnt/pgfl_quota ) ;(                 curpos( 8,3 );<                 printf( "Pagefile_Quota: %d ",pgfl_quota ) ;                  curpos( 8,36 ) ;8                 printf( "Pagefile_Free: %d ",pgfl_cnt) ;                  curpos( 8,62 ) ;7                 if ( (temp_f > 0.0) && (temp_f < 5.0) )  printf("%s",bold) ;F;                 printf( "Free: %3.1f%%%s",temp_f,unbold ) ;t                   wipeline( 9 ) ;c                 curpos( 9,8 );3                 printf( "Enq_Quota: %d ",enq_lim );.                 curpos( 9,36 );t7                 printf( "Enq_Remaining: %d ",enq_cnt );:                    wipeline( 10 ) ;                 curpos( 10,4 );f8                 printf( "AST_Remaining: %d ", ast_cnt );                  curpos( 10,34 );9                 printf( "Files_Remaining: %d ",fil_cnt );f                    wipeline( 11 ) ;"         /*      curpos( 11,1 ); */>                 printf( "Virtual Memory pages free: %d        
 ",free_cnt );:                  curpos( 11,46 );A                 printf( "Direct I/O count: %d          ",dirio );g                    wipeline( 12 ) ;                 curpos( 12,2 );mH                 printf( "Allowed working set size: %d          ",ws_size );                 curpos( 12,41);:F                 printf( "Peak working set size: %d        ",ws_peak );  A         /*      printf( "Working set extent: %d    ",ws_ext ); */i&                 /* display CPU-Time */&                 sec = cpu_time / 100 ;-                 tick = cpu_time - sec * 100 ;y#                 hour = sec / 3600 ; )                 sec = sec - hour * 3600 ;e                  min = sec / 60 ;&                 sec = sec - min * 60 ;=                 ( tick > 9 ) ? sprintf( s_tick,"%2d",tick ) :V7                         sprintf( s_tick,"0%1d",tick ) ; :                 ( sec > 9 ) ? sprintf( s_sec,"%2d",sec ) :5                         sprintf( s_sec,"0%1d",sec ) ;t:                 ( min > 9 ) ? sprintf( s_min,"%2d",min ) :5                         sprintf( s_min,"0%1d",min ) ;                       wipeline( 13 ) ;!                 curpos( 13,18 ) ;p2                 printf( "CPU time: %d:%2s:%2s.%2s  ",hour,s_min,s_sec,s_tick ) ;r  !                 curpos( 13,54 ) ;tA                 printf( "Priority: %2d/%2d  ",prior,base_prior) ;s  *         /*      wipeline( 15 ) ;        */                  curpos( 15,1 ) ;B                 printf( "%s",clear_EOS ) ;      /* Erase to end of	 screen */n2                 if ( imag_desc.dsc$w_length != 0 )C                         printf( "Running: %s",pretty(imagename) ) ;w                 else4                         printf( "Running: <DCL>" ) ;                  curpos( 23,1 ) ;  %                 sleep( sleep_time ) ;w                 } 	         }h  ! void    curpos( int ln, int col ) 	         { (         printf( "\033[%d;%dH",ln,col ) ;	         }e   void    wipescreen()	         {s         printf( "\033[2J" ) ;k	         }    void    wipeline( int ln )	         {s         curpos( ln,1 ) ;         printf( "\033[2K" ) ; 	         }D   char    *pretty( char lin_x[] )d	         {t         int i,j ;   -         for ( i=0 ; i < strlen(lin_x) ; i++ )t                 { C                 if ( ( lin_x[i] == ']' ) && ( lin_x[i+1] == '[' ) )t                         {U=                         for ( j=i ; j < strlen(lin_x) ; j++ ) 7                                 lin_x[j] = lin_x[j+2] ;-                         }i                 }c-         for ( i=0 ; i < strlen(lin_x) ; i++ )t0                 lin_x[i] = toupper( lin_x[i] ) ;           return lin_x ;	         }-    - ...<end code>... --  E ---------------------------------------------------------------------RE Usual disclaimer: All opinions are mine alone, perhaps not even that.i? Mike Rechtman                            *rechtman@tzora.co.il*dF Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------.   ------------------------------  # Date: Tue, 15 Apr 2003 09:36:09 GMT.0 From: "labadie" <en_trajectant_a_mort@127.0.0.1>! Subject: Re: Process Quota Tuninga/ Message-ID: <doQma.842$Ic2.20@news.cpqcorp.net>e  > "Jefferson Humber" <matrix01@globalnet.co.uk> wrote in message- news:7qycnaQisrap0QajXTWcpg@brightview.com...tJ > Does anybody have any good DCL scripts for monitoring quota usage levels of > running processes. Hello    Try pquota, available at5 http://h71000.www7.hp.com/freeware/freeware40/pquota/o  . or better install Amds or Availability Manager= http://h71000.www7.hp.com/openvms/products/availman/news.htmly   Regardso   Grard   ------------------------------  % Date: Tue, 15 Apr 2003 13:05:27 -0400g' From: "Main, Kerry" <Kerry.Main@hp.com>t! Subject: RE: Process Quota TuninggT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF403FB5C72@kaoexc01.americas.cpqcorp.net>   Jeff,   G Another good option is to use the new Availability Manager (AM) that is H free with OpenVMS and can be downloaded from the HP OpenVMS web site at:    > http://h71000.www7.hp.com/openvms/products/availman/index.html  H You can also dynamically and interactively increase quota's on a running5 process which is not something DCL procedures can do.y  G If interested, I can send you some sample screen shots from a large VAXiD to Alpha project that I just completed last weekend. For performance' monitoring, we used AM a great deal.=20i   Regards   
 Kerry Main Senior Consultantn Hewlett-Packard (Canada) Co.! Consulting & Integration Services- Voice: 613-592-4660a Fax   : 613-591-4477 Email: kerryDOTmain@hpDOTcom-     (remove the DOT's and replace with "."'s)  OpenVMS DCL - the original .COM4   -----Original Message-----; From: Jefferson Humber [mailto:matrix01@globalnet.co.uk]=20r Sent: April 14, 2003 8:02 PM To: Info-VAX@Mvb.Saic.ComQ Subject: Process Quota Tuningr    H Does anybody have any good DCL scripts for monitoring quota usage levels of running processes.o  A I have one DCL command procedure in which you pass the PID of the D process to be monitored.  It monitors a few quota levels retrievableC through F$GETJPI, and records the highest noted usage of each quotao- since the command procedure has been running.g  H From using this little tool we have found that some of our processes areF running at 100% utilisation of their FILLM quota levels, so we will beH tuning the detached process initialisation command files to increase theC value.... currently taking the default PQL_DFILLM value, since none 
 specified.  E I was wondering whether anybody else had any other tools for checkingsD whether your bespoke processes are running happy with the designated
 quota levels.l  D Or does anybody have any techniques for configuring quota levels for processes ?s   Many Thanks,   Jeff   ------------------------------  % Date: Tue, 15 Apr 2003 13:11:16 +0100r' From: Andrew Harrison SUNUK Consultancy 8 Subject: Re: So much for Opteron 32bit compatibility .... Message-ID: <3E9BF6E4.4050501@nospamn.sun.com>   Bill Todd wrote:M > "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>b; > wrote in message news:3E9AB095.7050809@nospamn.sun.com...s >  > ...  >  > D >>1.  Sun's SPECfp and SPECint performance improvements are entirelyD >>     legitimate. The optimisations have been extensively discussedA >>     and they are not SPEC specific and are usefull outside thenD >>     narrow boundaries of the SPECint and SPECfp benchmarkd. FredsG >>     allegation that they are a new way of "breaking" SPEC benchmarkshA >>     is an old one that has been totally trashed on a number of E >>     occasions. It is hugely regretable that he seems to think thatt? >>     if he repeats the slur often enough it will be beleived.  >  > M > Well, you're on kind of thin ground there, I'm afraid.  When discussing themG > relative performance of *hardware* (as is the case when talking aboutsF > processors rather than, say, systems) variances introduced purely byN > *software* tweaks can legitimately be criticized - especially if they're notJ > particularly applicable to most of the software people are interested in
 > running. >   D RISC processors Alpha, Power, SPARC, HP-PA have always derived their? performance from a combination of processor design and compiler 1 design. That plus a balanced system architecture.i  = There is no such thing as processor performance because it isa< so intrinsically linked to the performance of the compilers.  < The facts about Sun's SPEC performance improvements are that9 we have made very significant investments in our compiler > teams, we have aquired some very good compiler developers from the fallout of HP and Compaq.h  < Historically Sun's compilers have been safe and accurate but< not particularly fast, this is changing. When the major bump< in SPEC performance came through in the Forte/Sun ONE Studio? 7 compilers, there was extensive discussion about the merits ofo; the optimisations Sun introduced and the concensus was that'; they are usefull outside SPEC which is after all the point.   M > SPECint/fp are system benchmarks rather than processor benchmarks, but whenwI > being used to characterized the relative performance of processors such G > observations are legitimate - and the fact that SPEC tends to move tooJ > obviate such anomalies each time it updates its suite suggests that theyD > would like their benchmarks to be as software-neutral as possible. >   @ SPECint and SPECfp are not system benchmarks, they do hardly any< I/O, virtually no interupts, virtually no VM etc, no contextH switching, no threads. They are CPU, Cache, Memory, Compiler benchmarks.? On UNIX systems they are often run with the machines running int1 single user mode, hardly typical of most systems.a  M > Of course, these observations also apply, in spades, to Itanic's SPECint/fpnI > performance:  if typical use will not be by applications that have beenfL > heavily feedback-optimized, then allowing this (especially in base scores)N > seems ridiculous.  Unfortunately, that battle appears to have been lost some7 > time ago, unless they decide to reconsider the issue.i >   6 The inclusion of feedback directed optimisation in the7 BASE scores was much discussed at the time but it won'tlB be re-considered for CPU2000. CPU2004 is currently being developed6 and that would be the time to change the run rules for@ BASE or PEAK to exclude the use of Freedback based optimisation.     > A >>2.  Sun outperforms the PA8700+ on SPECrate_int and SPECrate_fp = >>     it also outperforms the P690 on SPECrate_fp by a handy>D >>     margin while only being slightly slower than the P690 on int.D >>     Sun also outperforms the best that you can get from large SMP( >>     Itanium boxes on both int and fp. >  > J > Er, that would be incorrect - grossly so, in fact.  The figures you listN > below for SGI are for R14K systems, not Itanic2 systems.  SGI's Itanic2 peak? > (and base) SPECfp_rate performance scores are 227/443/862 foraN > 16/32/64-processor systems, and while they don't list SPECint_rate scores itM > is not unreasonable to suspect that they would significantly exceed SPARC'se
 > as well. >  > E >>                      Sun F12/15 HP Dome IBM P690 SGI  GS1280 IA-64tB >>16 CPU SPECrate_int  119        N/A     131      91.6 162    117B >>32 CPU SPECrate_int  232        N/A     249      183  N/A    N/AB >>64 CPU SPECrate_int  436        413     N/A      362  N/A    N/AB >>Max SPECrate_int     478        413     249     1402  162    N/A >>B >>16 CPU SPECrate_fp   174        N/A     145      83.2 274    159B >>32 CPU SPECrate_fp   338        N/A     260     166   N/A    303B >>64 CPU SPECrate_fp   645        288     N/A     327   N/A    N/AB >>Max SPECrate_fp      717        288     260    1215   274    303 >>@ >>Couple of things to note. Itanium systems scalability even for; >>something relatively simple like SPECrate_fp is terrible.e >  > L > Not on SGI's platforms:  it's at least comparable in linearity to SPARC's. >   8 You are right, however SGI isn't exactly a player in the9 commercial server market. They havn't bothered publishingr/ SPECrate_int numbers for the Altix for example.  > ; >>The NEC 32 way system does 303 SPECrate_fp while a singlea< >>1 GHZ Itanium 2 does 16.6 so the NEC is getting 57% of the >>peak.U >  > I > Since there is no single-processor SPECfp_rate score listed for the NEC N > platform, no such comparison is possible:  NEC's supporting chipset could beL > a real slug at single-processor operation as well.  It does scale close to/ > linearly from 16 to 32 processors, after all.a >   7 Well its bound to be different however it should not beo> that different. The fact is that all the large SMP IA-64 boxes6 with the exception of the SGI on fp squander a per CPU< performance advantage for single CPU SPECfp/int when running7 with larger numbers of CPU's, while other platforms get 8 slower but not nearly so dramatically. This doesn't bode3 very well for large IA-64 based commercial servers.s  5 >  Incedentally even the 4 way HP Itanium boxes start  > 9 >>tanking early. A 4 way box does 49 SPECrate_fp only 74% 
 >>of peak. >>B >>The Dome is the worst performer of all on SPECrate_fp suggesting@ >>that its backplane is the issue, SPECfp has a larger footprint? >>than int showing up bandwidth and latency issues earlier than  >>int does.l >>> >>The GS1280 does well on a per CPU basis but you can only get< >>16 way machines, when the larger systems come out both IBM? >>and Sun will have faster modules available for their servers.p >  > L > But I wouldn't hold my breath waiting for them to equal the performance ofN > the larger GS boxes if I were you.  While they aren't yet at spec.web, AlphaM > documents indicate that the 32-processor GS1280 results continue the linearaA > scaling of the smaller configurations, including the absolutelyaK > unprecedented STREAMS benchmark results (right up to 64 processors IIRC).0 >   @ We will have to wait and see. This group is littered with people> who nearly asphyxiated while waiting for Compaq to deliver the< next system that was going to blow all the competition away.   Regards  Andrew Harrisont   ------------------------------    Date: 15 Apr 2003 07:48:35 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)v8 Subject: Re: So much for Opteron 32bit compatibility ...3 Message-ID: <qRVgI33bxZCR@eisner.encompasserve.org>c  X In article <3E9BF6E4.4050501@nospamn.sun.com>, Andrew Harrison SUNUK Consultancy writes:  > > Historically Sun's compilers have been safe and accurate but* > not particularly fast, this is changing.  =    So now they'll be dangerous and erroneous as well as slow?'  A    (You really shouldn't leave us a gaping wide crack like that.)j   ------------------------------  % Date: Tue, 15 Apr 2003 14:33:09 +0100w' From: Andrew Harrison SUNUK ConsultancyH8 Subject: Re: So much for Opteron 32bit compatibility .... Message-ID: <3E9C0A15.6000808@nospamn.sun.com>   Bob Koehler wrote:Z > In article <3E9BF6E4.4050501@nospamn.sun.com>, Andrew Harrison SUNUK Consultancy writes: >  > > >>Historically Sun's compilers have been safe and accurate but* >>not particularly fast, this is changing. >  > ? >    So now they'll be dangerous and erroneous as well as slow?> > C >    (You really shouldn't leave us a gaping wide crack like that.)  >   1 The size of crack is directly proportional to howl infantile you are.   No crack adult Huge wide crack infant  	 You chosee   Regards  Andrew Harrisonr   ------------------------------  % Date: Tue, 15 Apr 2003 09:08:59 -0400h0 From: "Brian Tillman" <Tillman@sparkingwire.com>I Subject: Re: Spam from HP (was: Email to Geoff.Graves@hp.com is rejected) $ Message-ID: <3e9c0468$1@news.si.com>  I >For providing email addresses to those whose trustworthiness is unknown,t
 >I recommend:o >h >http://sneakemail.com/o    And http://www.sparkingwire.com/ --  I Brian Tillman         Internet: Brian.Tillman at smiths-aerospace dot com 5 Smiths Aerospace  Addresses modified to prevent SPAM.n@ 3290 Patterson Ave. SE, MS Replace "at" with "@", "dot" with "." Grand Rapids, MI 49512-1991 8        This opinion doesn't represent that of my company   ------------------------------  % Date: Tue, 15 Apr 2003 14:32:50 +0200p! From: "ulfo" <ulfo@memo.ikea.com>c! Subject: TOY-battery VAX4000/105A., Message-ID: <b7gubo$vvg$1@mailgate.ikea.com>   Hi !  A Could someone please tell me the LOCATION of the TOY-battery on ah VAX4000/105A ?K As far as I can see there aren't any battery in teh machine now, makes it adK bit annoying to have to key in date & time each time the machine is poweredn up and booted.. The battery - according to the IPB - should be( p/n 12-19245-01 3.75 V NiCd rechargable.   Thanks in advance.   Ulf Ohlsson>   ------------------------------    Date: 15 Apr 2003 07:58:53 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)u% Subject: Re: TOY-battery VAX4000/105AU3 Message-ID: <dfH$lKlRKhF9@eisner.encompasserve.org>i  P In article <b7gubo$vvg$1@mailgate.ikea.com>, "ulfo" <ulfo@memo.ikea.com> writes: > Hi ! > C > Could someone please tell me the LOCATION of the TOY-battery on aa > VAX4000/105A ?M > As far as I can see there aren't any battery in teh machine now, makes it aeM > bit annoying to have to key in date & time each time the machine is powered  > up and booted.0 > The battery - according to the IPB - should be* > p/n 12-19245-01 3.75 V NiCd rechargable.  ?    On mine it's under the lower drive shelf, at the edge of theeF    motherboard far from the power supply, near the middle of the edge.      A pack of three small cells.i   ------------------------------    Date: 15 Apr 2003 09:59:58 -0700+ From: hobbesnet@hotmail.com (Scott Squires)t% Subject: VAX C++ 5.6 install questioni= Message-ID: <ff921edf.0304150859.677fe62c@posting.google.com>n  E I tried installing C++ about a year ago but had trouble and gave up. dE I decided to give it another try.  The installation doesn't really gotB anywhere before it stops because of missing logical names.  Anyone> know how I can find out which logical names it is looking for?   Thanks,l
 Scott Squires   G -----------------------------------------------------------------------d  A $ @sys$update:vmsinstal cxx056 disk$user:[programs.cxx] options ly    @         OpenVMS VAX Software Product Installation Procedure V7.2     It is 15-APR-2003 at 12:46.I  / Enter a question mark (?) at any time for help.s  > %VMSINSTAL-W-ACTIVE, The following processes are still active:
         Scotts* * Do you want to continue anyway [NO]? yes> * Are you satisfied with the backup of your system disk [YES]?    ) The following products will be processed:a  
   CXX V5.6    3         Beginning installation of CXX V5.6 at 12:46r  7 %CREATE-I-CREATED, $3$DKA0:[SYS0.SYSUPD.CXX056] createdq6 %VMSINSTAL-I-RESTORE, Restoring product save set A ...C %COPY-S-COPIED, $3$DKA0:[SYS0.SYSUPD.CXX056]CXX056.RELEASE_NOTES;16n copied to VM4 I$COMMON:[SYSHLP]CXX056.RELEASE_NOTES;2 (305 blocks)C %PURGE-I-FILPURG, VMI$COMMON:[SYSHLP]CXX056.RELEASE_NOTES;1 deletedk (306 blocks)A %VMSINSTAL-I-RELMOVED, Product's release notes have been moved ton	 SYS$HELP.h? %COPY-S-COPIED, SYS$COMMON:[SYSMGR]SYSTARTUP_V5.COM;1 copied toi $3$DKA0:[SYS0.SY, SUPD.CXX056]VMI$SYSTARTUP_V5.TMP;1 (1 block)  3     Compaq C++ Version V5.6 for OpenVMS VAX Systemsd  E   Copyright (c) Digital Equipment Corporation 1993, 1999.  All rights 	 reserved.s  @   Restricted Rights: Use, duplication, or disclosure by the U.S.D   Government is subject to restrictions as set forth in subparagraphD   (c) (1) (ii) of DFARS 252.227-7013, or in FAR 52.227-19, or in FAR$   52.227-14 Alt. III, as applicable.  ?   This software is proprietary to and embodies the confidentialoB   technology of Digital Equipment Corporation. Possession, use, orE   copying of this software and media is authorized only pursuant to anB   valid written license from Digital or an authorized sublicensor.  ) %SYSTEM-F-NOLOGNAM, no logical name matche) %SYSTEM-F-NOLOGNAM, no logical name match-) %SYSTEM-F-NOLOGNAM, no logical name match > %VMSINSTAL-E-INSFAIL, The installation of CXX V5.6 has failed.E %DELETE-I-FILDEL, SYS$SYSROOT:[SYSUPD]VMIMARKER20209320.DAT;1 deleted"
 (9 blocks)    )         VMSINSTAL procedure done at 12:47c   ------------------------------    Date: 15 Apr 2003 13:57:43 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>: Subject: Re: VMS Advertising & Marketing - a status report5 Message-ID: <20030415135743.7569.qmail@nym.alias.net>   9 On Mon, 14 Apr 2003, "John Smith" <a@nonymous.com> wrote: C >"Doc.Cypher" <Use-Author-Supplied-Address-Header@[127.1]> wrote inm  , >> >What's a good address to contact you at? >> >> Hidden in my headers... >>C >> Author-Supplied-Address: doc_cypher <AT> redneck <DOT> gacrackero
 ><DOT> org >  >Have sent you a message.i  F I should've checked that Redneck was getting incoming mail through. It isn't.  E I've just confirmed that doc_cypher <AT> nym <DOT> alias <DOT> net isn working.  D You probably won't get a bounce to your earlier mail. It'll just getK dropped in the bit bucket somewhere between being accepted and forwarded on  to me.   Sorry about that!e     Doc. --  : Time and money, the psychotropics of the business world...K ~ VAXman                                             https://vmsbox.cjb.nete   ------------------------------  # Date: Tue, 15 Apr 2003 14:26:44 GMT # From: "John Smith" <a@nonymous.com>*: Subject: Re: VMS Advertising & Marketing - a status reportH Message-ID: <EEUma.36564$BQi.26879@news04.bloor.is.net.cable.rogers.com>  A "Doc.Cypher" <Use-Author-Address-Header@[127.1]> wrote in message./ news:20030415135743.7569.qmail@nym.alias.net...e; > On Mon, 14 Apr 2003, "John Smith" <a@nonymous.com> wrote:oE > >"Doc.Cypher" <Use-Author-Supplied-Address-Header@[127.1]> wrote in  > . > >> >What's a good address to contact you at? > >> > >> Hidden in my headers... > >>E > >> Author-Supplied-Address: doc_cypher <AT> redneck <DOT> gacracker9 > ><DOT> org > >  > >Have sent you a message.H >SE > I should've checked that Redneck was getting incoming mail through.  It > isn't. >iD > I've just confirmed that doc_cypher <AT> nym <DOT> alias <DOT> net is
 > working. >*F > You probably won't get a bounce to your earlier mail. It'll just get@ > dropped in the bit bucket somewhere between being accepted and forwarded on > to me. >r > Sorry about that!   - No problem.. have resent to you this morning.;   ------------------------------    Date: 15 Apr 2003 07:03:50 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) " Subject: Re: What is a VMS Cluster3 Message-ID: <4V4OIdiHCK4A@eisner.encompasserve.org>a  f In article <3E9B5ED6.D0BE498C@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:  H > I have actually used this analogy that the SAN in *SOME* respects is a > smart Star-coupler  E If one views abandoning the reliability of a passive device as smart.    ------------------------------  % Date: Tue, 15 Apr 2003 12:49:31 -0400t' From: "Main, Kerry" <Kerry.Main@hp.com> " Subject: RE: What is a VMS ClusterT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4040ECFA2@kaoexc01.americas.cpqcorp.net>   John,   , The following article may be of interest.=20  G It discusses shared everything vs shared nothing cluster architectures.r@ OpenVMS and MVS (now z/OS) are examples of shared everything (orG sometimes called shared disk) cluster architectures while UNIX, Windows,< and NSK are considered shared nothing cluster architectures.  H http://archive.infoworld.com/articles/fe/xml/01/12/17/011217feclustertca xml4   Regards   
 Kerry Main Senior Consultant, Hewlett-Packard (Canada) Co.! Consulting & Integration Servicesl Voice: 613-592-46602 Fax   : 613-591-4477 Email: kerryDOTmain@hpDOTcom-     (remove the DOT's and replace with "."'s)D OpenVMS DCL - the original .COM      -----Original Message-----+ From: John N. [mailto:JNixon@cfl.rr.com]=20R Sent: April 13, 2003 8:55 PM To: Info-VAX@Mvb.Saic.Com  Subject: What is a VMS Cluster    F Of course, I know what a VMS Cluster is.  I have been working with VMSF since 1981 and with Clusters since 1986.  I guess my problem is that IF understand them so well that it is difficult for me to explain to PHMsB what they are, and what their advantage are over other "so-called"	 clusters.A  C Can you guys help me come up with a simple definition of what a VMSM4 Cluster is, and why it is better than the imposters?   ------------------------------  % Date: Tue, 15 Apr 2003 05:06:02 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>% Subject: Re: XDM problems (TCPIP 5.3) / Message-ID: <3E9BCB62.46515EF5@vl.videotron.ca>B   David Michaels wrote:l: > I think it looks like this could be a MIT-COOKIE problem  0 Damned you for telling me about this :-) :-) :-)  J The MI/X server on the mac, upon receiving a "willing" offer from the vax,8 makes an official request, and in that request there is:       0 connection adressesf     0 authentication name      0 authentication data -     1 authorization name "MIT-MAGIC-COOKIE-1"F     1 display name  "MIX",  D The XDM documentation talks only about XDM-AUTHENTIFICATION-1 in the^ xdm-keys.txt file. However, the TCPIP$XDM.EXE file does contain the string MIT-MAGIC-COOKIE-1.  J Before I continue any further on this, is it a lost cause with the VMS XDM' server refusing the MIT_COOKIE stuff ? 5   (VAX VMS 7.2,  TCPIP 5.3 eco 2)     N Oh, and I had a hell of a time using TCPTRACE. For a long time, it just didn'tD display any information, but eventually, I must have typed a correctG incantation and after that, I was able to see the XDM packets. Strange.I   ------------------------------   End of INFO-VAX 2003.208 ************************              {4, JPI$_DIRIO      , &dirio,     &l22},                 {0, 0, 0, 0}                 } ;        main( argc, argv ) int     argc ; char    *argv[] ;>	         {e                 int x,                 sleep_time = 2,                  status = 1 ;         char    a;           if ( argc == 3 )                 {UE                 if ( ( argv[2][0] <= '9' ) && ( argv[2][0] > '0' ) &&s<                                 ( strlen( argv[2] ) <= 2 ) )6                         r<n*3Z><wA>B_|ѕMTp4]1J&I3R_492> ^kv!;B&zY>o. GhOSڅUxkfƕM~,hH3	-{i4
0t\.umܸjsXgY`Q	cbcX<ouW <Cg 7}<x4i;xeC.In<t槕zd}2F-)~hvb_5]o->Xdgx2j$\̋-,nK0 LNo&CvQU;	i*\jB[WtU'*࡫Yr[t,'EHY+^%+*ϽQbvaد_R=A`k3 o`nX i?} ~ t1Os\U%ujz{Y teQq}ehco`o94;@4?n9m52 ]Y5'ګXLi,A_6lg=]&ɮdroς|Q$5(3+뫡>ّyv߀-oeaǍ?!㵵za n4{(#_8+nΘI@~ԮiS:6?,'3rK?6Z{wq5A#CÎ>1W6XƀMG-Y~lj5/sȍv7v`|:,]3)>_:N!.#.WNۜXD[ze1_z9t]D6XZg2,eHA̷Ԓ뎵Ҟ[<|
782hx0L~;V0lϢBoƮ=ō_N	ʥ$;"i5F6Liy~M0<po~1._7~zrխ3J^\Ni'tc_E᏶N' Ӹ7\O񎂦raSJr
5J(<lY_BQ$Q!;g.(6Xxf+0.Mm}!ducH#B4s}yqcMX22烰cںuvÇ߷Lڸi
cWō]q`~o^/ ==8Nsw:Z=|WyN~
Hk4ƿY@ʛg~0sm? Mrz& #q|.?tjxTs7nS7ZJ{Y޴Q4̯uFߏqs0n6tkppF|%vNr>[鳽Lh5iٸoU&54f 4; M~}`}fc}tmo8Kv7k3kڔiB Jkdf=h-˪q:3\ӤXonYxZR)tsJ^߾8N[wuZ7Lx4j>1Wd}a/bSwMiIlFuiM
#*m_wFqD=.m2FN {Λ$nZ>okDy.(̹>YTFȷ0*њbq8{ ;xoC?9ctP֍ t{rIw\Dg
`ݚKmnayu-h-W:p0Mㇾ]|5
_"<͍47zߎCmƣtY|(>A75:x@E~=&ƀ
.p-{ݝؽ`čL!Cb~d$Y7ڦ!>Ӹ?u ʘ~Sy$/'sݽſgܻ >#V8cF!?4j=ǜRAinε?Gƛ;1ЎL=Oa!si/f9bO}{r9*@.[CeԠJC*i/%$Ug8S=8Z,Ngn:@gQ}dXg ϑ؋]ރv+DrJ?G>GR]?oXnf%1lL"5yw"
euK:[ōfbqCL[:+n5"nC áj覭+
Ę~nKD/wtJRƍ'ErR{zc̑GdL؆o91WV3XEf?
@Ѳ԰hqƤ0ǍkHYy]S\{Q
9f*om'XSV>rKvEeT5|4.lӝ
sX_-KUs{[i4u;	jp&-KUҢ_h>J׃|դA}U?1,ŕ~At ru0(3	v!]YViei߽O_I9
HWWsiZ}=iJ?<~,73Vlv"Dztε!׃oCN@Zka߱Wǀ<惴o)r?/kl:En_a:mvy^΅e&ntvt;3=[(ϭazslD	.i}?Lƃ5c]hW.~63"Ȭ6kYYgkmvo?S*7}g sh뙒WnZEKgS/A;''ng!w4Q1g	uۺǜxnOuKwN.@{_8c!
vvړԎӌ08g6n&F(fOݹ9!3v#YT.
Nߴ~ԯMۖ1}SnM`woZ_K66CߴJ7şxQgx蛎93_7?ӹM9}'d|u
 yآ*qq rFi֑3sȡv	4AX>I@#psF`"w,fgsselqGùo	w]Fw-UdZs!}uĎ8®kj)&[+=slP~@!.95"dmFqټuum(ehېӾg`X[ϛErE*D^V?hIoxim_7 6=x[~DfΏ-6K|<zŤ|	Kuqurn:62.xo]L\t9s)'7TJ69wwQU&ڨ0P\?bA|Tt