1 INFO-VAX	Sun, 12 Oct 2003	Volume 2003 : Issue 565       Contents:$ RE: anyone running 7.3-1 with 64 MB?C RE: Forget the OSU job ... they are going to AIX ... sad, isn't it? / Re: HGFTP - how to troubleshoot data connection / Re: HGFTP - how to troubleshoot data connection H Re: How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set? Re: MD5 source code ? = Re: The VAX/VMS to Itanium Migration Letter, Vol. 1 Number 1.  VMS article at "the Inquirer" ! Re: VMS article at "the Inquirer" $ Re: What does MSCP_SERVE_ALL=4 mean?$ Re: What does MSCP_SERVE_ALL=4 mean?$ Re: What does MSCP_SERVE_ALL=4 mean?$ Re: What does MSCP_SERVE_ALL=4 mean?  F ----------------------------------------------------------------------  % Date: Sat, 11 Oct 2003 22:13:22 -0400 ' From: "Main, Kerry" <kerry.main@hp.com> - Subject: RE: anyone running 7.3-1 with 64 MB? R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB17BB0B@tayexc19.americas.cpqcorp.net>   > -----Original Message-----3 > From: Phillip Helbig---remove CLOTHES to reply=20 - > [mailto:helbig@astro.multiCLOTHESvax.de]=20   > Sent: October 11, 2003 8:41 AM > To: Info-VAX@Mvb.Saic.Com  >=20@ > I have an ALPHAstation 255/233 with 64 MB at 7.2-1.  I plan=20@ > to upgrade to 7.3-1 soon, possibly this weekend.  Is anyone=20? > actually running 7.3-1 with just 64 MB?  Is it even possible?  >=207 > Note that I am not just running core VMS, but also=20 = > DECwindows.  In addition, the machine is running the OSU=20 ? > server, has 7 SCSI devices attached, some of them shadowed=20 ? > (with devices on the same controller (there is only one on=20 G > the machine) or with other disks in the cluster) and is in a cluster.  >=20@ > Performance now is acceptable, though it could be better of=20> > course.  (I haven't analysed things to see where the real=20 > bottlenecks are.)  >=20@ > I understand that 7.3-1 has many performance improvements. =20> > So, things might actually get better.  On the other hand,=20 > perhaps I need more than) > 64 MB to actually take advantage of it.  >=20@ > A related question---is there ever any reason at all not to=20A > put as much memory into the machine as possible?  (I think I=20 % > can put 8 128-MB SIMMs in the 255.)  >=20 >=20    	 Phillip -   E Fwiw - I have OpenVMS V7.3-1 (+ latest patches) on one of my home VMS D systems - an AlphaStation 400 4/233 with 64MB memory, Motif V1.3 andH while I do not run any large app's on this, I have had no issues at all.     Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  Email: kerryDOTmainAThpDOTcom . (remove the DOT's and AT for email address)=20   ------------------------------  % Date: Sat, 11 Oct 2003 22:30:24 -0400 ' From: "Main, Kerry" <kerry.main@hp.com> L Subject: RE: Forget the OSU job ... they are going to AIX ... sad, isn't it?R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB17BB0C@tayexc19.americas.cpqcorp.net>   >=20 > -----Original Message-----4 > From: Bob Ceculski [mailto:bob@instantwhip.com]=20! > Sent: October 11, 2003 12:26 AM  > To: Info-VAX@Mvb.Saic.Com  >=20@ > this is a response I got from OSU when asking them on their=20A > plans for VMS ... sad when you replace the best with a mess ...  >=20 > > Robert,  > > H > > Thank you for your interest in this position and I apologize for not> > having gotten back to you sooner as I have been out ill a=20B > good portion of this week.  With respect to the future of VMS=20D > in our environment, long term, we will likely migrate to other plaH > > tforms, with AIX being the most likely.  We have actually already=20	 > > moved F > one system (Kronos - our timekeeping system) from VMS to the iSeries@ > (AS/400) platform.  As I am sure you are aware, the reality=207 > is that with DEC having changed hands twice in recent G > > years, support is not up to the standard it once was.  Perhaps this 8 > contributed to the bigger issue, which is that many=20< > application vendors are moving away from offering their=20< > products on VMS - this was the issue we faced with Kronos. > > ? > > Hopefully, this answers your question.  I do foresee VMS=20  > continuing as=20 > > an; > integral part in our environment for at least the next=20 A > several years, and I will agree that, if nothing else, it is=20 B > the most resilient OS we have.  If you remain interested in thisC > > position, please reply back with a copy of your current resume.  > >  > > Regards, > > 	 > > Scott  > >  > >  > > Scott Rubin I > > The Ohio State University Medical Center Department of Information=20 4 > > Systems Sr. Systems Manager, Midrange Systems=20! > > Rubin-1@MedCtr.Ohio-State.edu  >=20 >=20   Bob,  ! Re: moving from OpenVMS to AIX ..   H So given what IBM has publically stated about AIX futures, I guess these1 folks don't mind doing two migrations I guess?=20   H Senior VP of IBM Software division has stated publically that the likely future for AIX is Linux.  
 Reference:< http://news.com.com/2100-1001-982512.html?tag=3Dfd_lede2_hed  F "NEW YORK--The day is approaching when Linux will likely replace IBM's> version of Unix, the company's top software executive said, anG indication that the upstart operating system's stature is rising within 	 Big Blue.   E While IBM doesn't expect Linux to replace its own AIX version of Unix A any time soon, Big Blue is pushing the open-source OS in the that F direction, Steve Mills, senior vice president of IBM's Software Group,; told CNET News.com at last week's LinuxWorld trade show.=20   E Asked whether IBM's eventual goal is to replace AIX with Linux, Mills D responded, "It's fairly obvious we're fine with that idea...It's the logical successor."        Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  Email: kerryDOTmainAThpDOTcom . (remove the DOT's and AT for email address)=20   ------------------------------  + Date: Sun, 12 Oct 2003 01:17:24 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk8 Subject: Re: HGFTP - how to troubleshoot data connection) Message-ID: <bmaa34$hhp$1@news.mdx.ac.uk>   U In article <UiXhb.5613$Pe5.1495@edtnps84>, Alder <PGDEHMKOKIMD@spammotel.com> writes: ! >david20@alpha1.mdx.ac.uk wrote::  > L >>>I found that clients CAN connect to my HGFTP server, but only if they're J >>>using Active mode and don't have a firewall on their end.  I'd like to K >>>support Passive mode connections, but I don't see anything in the HGFTP  I >>>docs that would suggest it supports Passive mode.  I also checked the  I >>>docs for the FTP server in TCPIP Services for OpenVMS and didn't find   >>>anything in there either. >>> I >>>Does anyone know if either of these servers DOES support Passive mode  % >>>connections, and how to enable it?  >>>  >>   >>  I >> Don't need to do anything special to the DEC TPIP services ftp server. 1 >> The client just needs to request passive mode.  >  >David,  > A >I definitely cannot get a passive-mode data connection from the  2 >non-firewalled client I'm using to test all this. > G >The way I understand this is that my server receives the PASV command  I >from the client and should then - if it supports passive mode - respond  F >with an ephemeral port number it is willing to listen for and accept G >data connections on.  The client should then make its data connection  H >attempt on this ephemeral port.  But, because I don't know which ports B >the HGFTP or TCPIP Services FTP server will want to use, I can't C >configure the gateway to open the proper range.  Hence the client  D >"hangs" when it asks for a directory listing.  Are the two servers & >simply using any old port above 1024? >    Where is the firewall ? 8 Is it in front of the client or in front of the server ?O If the firewall is in front of the clients and is allowing outgoing connections  then PASV should work.  A As far as I am aware it will just pick a random high port number.  For details see :   ) http://www.phoneboy.com/docs/pasvftp.html    and   % http://www.faqs.org/rfcs/rfc1579.html       
 David Webb VMS and Unix team leader CCSS Middlesex University       >Any suggestions folks?  >  >Cheers, >  >Alder >    ------------------------------  # Date: Sun, 12 Oct 2003 03:53:11 GMT ( From: Alder <PGDEHMKOKIMD@spammotel.com>8 Subject: Re: HGFTP - how to troubleshoot data connection7 Message-ID: <He4ib.4138$KX.83991@news1.telusplanet.net>     david20@alpha2.mdx.ac.uk wrote::W > In article <UiXhb.5613$Pe5.1495@edtnps84>, Alder <PGDEHMKOKIMD@spammotel.com> writes:  > " >>david20@alpha1.mdx.ac.uk wrote:: >  > Where is the firewall ?   F Definitely one on my server side.  I just want to support connections ( from clients behind their own firewalls.  : > Is it in front of the client or in front of the server ?Q > If the firewall is in front of the clients and is allowing outgoing connections  > then PASV should work.  H Yes, so long as there is no firewall on the server side trying to block - "unsolicited" connections on ephemeral ports.    > C > As far as I am aware it will just pick a random high port number.   F If by "it" you mean the server, then yes.  If the client sends it the G PASV command, the server will "pick" an ephermeral port, then tell the  @ client which one it picked.  The client then initiates the data D connection on this "random" port.  My issue is with configuring the G server-side firewall to recognize these data connections for what they   are and allow them in.  G This is where my understanding of the server configuration runs rather  F thin.  If they could be configured to confine themselves to a certain G narrow range of ephemeral ports, I could then configure my server-side  H firewall to allow connection requests through within that range, rather # than open the barn door above 1024.    Hunter?  Are you there?    Regards,   Alder    ------------------------------  + Date: Sat, 11 Oct 2003 20:49:22 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set? ( Message-ID: <bm9qci$si5$1@pcls4.std.com>  * "H Vlems" <hvlems.nieuw@zonnet.nl> writes:    J >> > But perhaps you could elaborate on what you consider "side effects" ? >>D >> I'm mainly concerned with cloning system disks.  That is, after aK >> successful upgrade when I have a valid shadow set, remove one member and K >> use it for the system disk on another machine, replacing it with a fresh H >> disk (which will be the target of a shadow copy).  There are a lot ofJ >> open files on a system disk, but presumably most of these are just open@ >> for reading.  I'm sure they don't change on disk under normalH >> circumstances; the question is if they can become corrupted when I doH >> the dismount.  (There are also log files open, but I don't care aboutH >> these since they are of no interest on the other machine.  SYSUAF etc& >> are not on the system disk at all.)  J >On a quiescent system only OPERATOR.LOG and the event log are written to.J >Part of the data may remain in cache and thus missing on the disk. If you6 >want to create clones then that shouldn't bother you.  G SHADOWING will wait until writes in progress are complete and stall new C writes before removing the member, but as mentioned, open files may H not have their cache flushed, etc.  So doing so is cleaner than shutting8 down by yanking the power cord and probably cleaner thanF $ BACKUP/IGNORE=INTERLOCK (since it is a snapshot at a moment in time)E Doing this procedure while under a minimum boot has fewer files open.    >>E >> This leads to another question: can I have one of the members of a I >> SYSTEM-DISK shadow set be directly connected to another machine in the I >> cluster (even one with different architecture) and only MSCP served to K >> the system using it as a system disk, as long as I add this member after I >> all machines in the cluster are up and running (or at least if I don't H >> boot from it)?  If I can do this, the extra reboot would be worth the1 >> trouble of avoiding an additional shadow copy.   G Yes you can do this but there can be strangeness if the serving node is C not available.  Well usually not so strange, the system will "hang" G for SHADOW_SYS_WAIT (I think that's right) waiting for the disk to come # back online before giving up on it.   G >AFAIK host based shadowsets cannot be MSCP served. The DSA devices are M >listed without an ALLOCLASS prefix. If you use a shadowset member all by its K >own then VMS will mount that volume read-only. No idea how VMS would react < >when it encounters such an isolated member as a systemdisk.  E Irrelevant.  Each system creates its own DSAx: device but coordinates H everything with other nodes (via the lock manager).  The members must be, visible on all nodes mounting the shadowset. --   -Mike    ------------------------------  + Date: Sun, 12 Oct 2003 00:08:36 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set? $ Message-ID: <bma623$nsh$3@online.de>  C In article <bm9fuf$kk3f1$1@ID-143435.news.uni-berlin.de>, "H Vlems" ! <hvlems.nieuw@zonnet.nl> writes:    I > >   $ MOUNT/SYSTEM DSA133:/SHADOW=($33$DKA100:,$33$DKA600:,$44$DKA100:)  > > K > > but only on the machine with ALLOCLASS=33 (GLADIA in the example below, . > > which is an ALPHA---the others are VAXes). > > K > > It seems to me that $44$DKA100: should be added to the shadow set.  But * > > I'd like to be sure before I try this! > H > Not sure I understand your concern here. $44$DKA100: is a datadisk forJ > GLADIA which does not (have to) know that the other two members use thatM > disk as a systemdisk. I did this on a three node VAXcluster where the third M > (quorum) node mounted a similar shadowset. That way the quorum system could A > when necessary be used to boot the other VAXes across ethernet.   C What I want to do is add a third member to an existing system-disk  H shadow set, but have this third member have a direct connection only to E another node, and only be visible via MSCP to the node which has the  = direct connection to the two other members of the shadow set.   ) Note: I don't have any dual-ported disks.   I I've always had the system disk locally connected to the node it is used  F on.  This has to be the case, so that the system can boot from it.  I G now want to add a third disk to this shadow set, but on another node.   F Not to actually use it as the system disk, but rather to make a clone.E (The idea is, after an upgrade when I turn shadowing back on, I will  I shadow-copy the upgraded disk to TWO other disks.  I can then shut down,  I remove one of the three members, and reboot, using the removed member as  H a starting point for an upgraded disk on another system.  With just the F OS, this is probably more trouble than it's worth, but it is worth it / after upgrading a lot of layered products etc.)   N > OK, I see what you're driving at and I did not catch up on this point beforeK > so my comments may have been completely off up to now. AFAIK only locally H > attached shadowset members of a system disk get mounted automatically.   OK.    > Another I.Asimov fan :-)  E Indeed.  There seem to be many characters in his books with 6-letter   names.  :-)    > BTW what is a DPA0: ?    It's a template RAID device:  H Disk DPA0: (GLADIA), device type RAID5, is online, file-oriented device,K     shareable, served to cluster via MSCP Server, error logging is enabled.   C I installed the RAID software with the intent of experimenting with G this, but haven't actually gotten around to it.  (Similarly, DAD0: is a D template device for virtual InfoServer disks, which I used to have. @ Now, I have enough real disks and the InfoServer has also died.)   ------------------------------  + Date: Sun, 12 Oct 2003 00:10:45 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set? $ Message-ID: <bma665$nsh$4@online.de>  H In article <bm9qci$si5$1@pcls4.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:   G > >> This leads to another question: can I have one of the members of a K > >> SYSTEM-DISK shadow set be directly connected to another machine in the K > >> cluster (even one with different architecture) and only MSCP served to M > >> the system using it as a system disk, as long as I add this member after K > >> all machines in the cluster are up and running (or at least if I don't J > >> boot from it)?  If I can do this, the extra reboot would be worth the3 > >> trouble of avoiding an additional shadow copy.  > I > Yes you can do this but there can be strangeness if the serving node is E > not available.  Well usually not so strange, the system will "hang" I > for SHADOW_SYS_WAIT (I think that's right) waiting for the disk to come % > back online before giving up on it.   I Good point; a reason not to leave this set up for longer than necessary,  7 since the loss of one node could cause another to hang.    ------------------------------  # Date: Sun, 12 Oct 2003 03:26:23 GMT  From: fdasfa <jfkfa@fdsajf.com> Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set? ) Message-ID: <3F88BD4E.454F587@fdsajf.com>   / Phillip Helbig---remove CLOTHES to reply wrote:  > E > In article <bm8nnk$kkpv0$1@ID-143435.news.uni-berlin.de>, "H Vlems" " > <hvlems.nieuw@zonnet.nl> writes: > P > > Interesting question. My initial reaction to the question was that you'd endN > > up with the same situation as running BACKUP/IMAGE/IGNORE=INTERLOCK on theN > > disk. The only difference being that backup takes time to complete and theA > > actual on-disk state of an open file is never known for sure.  > C > Right, it's faster.  (Well, when I replace the disk I remove with E > another one, a shadow copy will happen, but I don't care about that % > since I don't have to wait for it.)  >  > > AFAIK it is O > > the reason why an image backup of a database disk won't work when restored.  > ; > This definitely wouldn't be possible with database files.  >   F I disagree -- with regards to Oracle RDBMS in "hot backup" mode (alterH tablespace begin backup) for all tablespaces on the volume and make sure? you keep all the Archive log files. Our clients use this method  extensively.  A 1) alter tablespace ... begin backup for each tablespace/datafile  2) dismount shadow member 9 3) spool dismounted member to tape (image or incremental)  4) re-mount shadow member.& 5) copy all archive log files to tape.  H .. and never use this method with Rdb.  you will end up with corruption.  G Now as far as making a clone... that all depends.  I have a system that D it's sole purpose is to stay up to date (OS, Patches, etc...) and to@ clone this system drive for new system builds.  With this systemB connected to all of our 36+ HSG80's on the SAN, we can build a new8 system in a couple of hours.  Cabling, copying the driveG (ignore=inter,nobackup), changing the SCSSYSTEMID and nodename and some  other configuration stuff..   D I have 16 new DS25's and 8 ES47's along with another 8 DS20s that we+ will be building over the next month or so.   F That makes ~ 156 VMS nodes and with the new MSA1000's we are at ~160TBH of storage with another 80 146GB drives on order ~11TB raw, ~9TB usable.C Next comes another EVA - with expansion cabinet and using the 309GB E drives = ~76TB raw storage.  all of this before we even start putting G equipment in our (under construction) expansion data center -- which is . almost 2x the size of the current data center.   --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.com  816-373-0270 (Office)  816-728-3080 (Mobile)    ------------------------------  % Date: Sun, 12 Oct 2003 03:11:53 +0930 / From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>  Subject: Re: MD5 source code ?, Message-ID: <3f8840d4_3@news.chariot.net.au>   Doc.Cypher wrote: G > On Sat, 11 Oct 2003, Mark Daniel <Mark.Daniel@wasd.vsm.com.au> wrote:  >  >>Doc.Cypher wrote:  >>O >>>On Mon, 06 Oct 2003, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) wrote:  >>>  >>> N >>>>Does anyone have a source code ready which does a MD5 checksum of an input5 >>>>file and puts the hash/checksum in a DCL symbol ?  >>>>Q >>>>I know I could do it myself but I'm lazy^Wshort of time and ask here first...  >>>  >>> P >>>There's a md5 routine in WASD.  Doesn't put the hash in a symbol, but all the >>>hard work is done.  >>> K >>>You can find md5.c and md5.h in http://vmsbox.cjb.net/ht_root/src/httpd/  >>>  >>>HTH >>>  >>>  >>>Doc.  >>3 >>It can Doc.  From the prologue of that module ...  >  > , > Oh well, learn something new every day. :)  " If you're not very careful ... ;^)   >  >  > Doc.  F +--------------------------------------------------------------------+E   Mark Daniel                         http://wasd.vsm.com.au/adelaide F   mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au)F +--------------------------------------------------------------------+   ------------------------------  % Date: Sat, 11 Oct 2003 20:48:59 +0200 $ From: Michael Unger <unger@decus.de>F Subject: Re: The VAX/VMS to Itanium Migration Letter, Vol. 1 Number 1.9 Message-ID: <bm9jf3$ke8fp$1@ID-152801.news.uni-berlin.de>   , On 2003-10-11 02:46, "Didier Morandi" wrote:  8 > http://www.didiermorandi.com/vaxvms2itanium_200310.pdf > (English, 8 pages) >  > Feedback welcome: [...] 
 > Danke schn  > Thank you  > Merci.   Minor nitpicks:   D - an invalid hyperlink (page 6) resulting in an "unable to open file; '.\nntp:\comp.os.vms\'" message (Acrobat Reader 5.0 on W2k)   F  - the 5-columns layout on pages 6 and 7 (the columns are of different width)  6 I didn't read the entire document by now of course ...   Michael    --  ; Real names enhance the probability of getting real answers. @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system. = And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)    ------------------------------  % Date: Sat, 11 Oct 2003 19:17:50 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> & Subject: VMS article at "the Inquirer": Message-ID: <Bc0ib.14267$fP6.467633@news20.bellglobal.com>  K Interesting OpenVMS article at "the Inquirer" regarding Defense Information M Infrastructure Common Operating Environment (DII COE) and UNIX compatibility. 5 Like the author said, HP probably won't mention this.   ) http://www.theinquirer.net/?article=12033   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  % Date: Sun, 12 Oct 2003 12:27:02 +1000  From: bah@bit.bucket (BAH)* Subject: Re: VMS article at "the Inquirer"0 Message-ID: <slrnbohevm.60.bah@plague.bogus.com>  M On Sat, 11 Oct 2003 19:17:50 -0400, Neil Rieck <n.rieck@sympatico.ca> Wrote : L >Interesting OpenVMS article at "the Inquirer" regarding Defense InformationN >Infrastructure Common Operating Environment (DII COE) and UNIX compatibility.6 >Like the author said, HP probably won't mention this.  > Nothing much has changed. The people responsible for marketing; OpenVMS couldn't market free food in a famine. Never could.    > * >http://www.theinquirer.net/?article=12033 >  >Neil Rieck  >Kitchener/Waterloo/Cambridge, >Ontario, Canada. " >http://www3.sympatico.ca/n.rieck/ >  >      --    
 BAH Humbug   ------------------------------  + Date: Sat, 11 Oct 2003 21:12:09 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) - Subject: Re: What does MSCP_SERVE_ALL=4 mean? ( Message-ID: <bm9rn9$si5$2@pcls4.std.com>  B MSCP_SERVE_ALL=4 means only serve the system disk.  MSCP_SERVE_ALL? is now a bitmask so you can also do MSCP_SERVE_ALL=6 (serve all & local disks and the system disk, 4+2).  D Since MSCP_SERVE_ALL=1 means what it always does, the system disk isB served anyway, so this complaining is unnecesary.  You may wish to file an SPR.  D If you are running unpatched V7.1 or earlier, look at MSCP_SERVE_ALLE bit 3 (8).  Nodes running an old version of DUDRIVER can get confused  by newer MSCP Servers.     --   -Mike    ------------------------------  + Date: Sat, 11 Oct 2003 23:55:35 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)- Subject: Re: What does MSCP_SERVE_ALL=4 mean? $ Message-ID: <bma59n$nsh$1@online.de>  C In article <bm9e1n$k5ral$1@ID-143435.news.uni-berlin.de>, "H Vlems" ! <hvlems.nieuw@zonnet.nl> writes:    ' > $ mc sysgen help sys_param mscp_serve E > produced a lot of output on an AXP/VMS V7.3 system, but a fragment:  > E > Bit 2           Serve the system disk. This is the default setting. C >      (4)        This setting is important when other nodes in the G >                   cluster rely on this system being able to serve its I >                   system disk. This setting prevents obscure contention E >                   problems that can occur when a system attempts to I >                   complete I/O to a remote system disk whose system has  >                   failed.   H Thanks.  I use the BOOKREADER docs so much I sometimes forget that HELP 
 gets updated.   H I want each node to serve all available disks.  From the HELP it is not 1 clear if 1 is sufficient or if 5 would be better.   B Also, there seems to be a contradiction in the HELP (I seem to be # noticing a lot of these recently):    D        Bit 3      Restrict the serving specified by bit 0. All disksG        (8)        except those with allocation classes that differ from E                   the system's allocation class (set by the ALLOCLASS (                   parameter) are served.  C                   This is pre-Version 7.2 behavior. If your cluster D                   includes systems running OpenVMS 7.1-x or earlier,E                   and you want to serve all available disks, you must F                   specify 9, the result of setting this bit and bit 0.  F Presumably, the only way to interpret this is that before 7.2, a valueD of 1 didn't serve ALL disks, but only those with the same allocationE class as the node.  Still, setting the value to 9 should "restore pre F 7.2 behaviour" and not "serve all disks".  In the first paragraph, it G says that setting bit 3 restricts the serving.  In the next paragraph,  F it says that if I want to serve everything, set this bit.  They can't  both be correct!   ------------------------------  + Date: Sat, 11 Oct 2003 23:58:33 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)- Subject: Re: What does MSCP_SERVE_ALL=4 mean? $ Message-ID: <bma5f9$nsh$2@online.de>  G In article <bm9elb$k8s5j$1@ID-152801.news.uni-berlin.de>, Michael Unger  <unger@decus.de> writes:    H > The current (7.3 as well as 7.3-1) documentation is available from the, > HP web site. I prefer using the PDF files.  B Right.  However, I haven't been able to find a substitute for the B "Search Book(s)" function.  I also like the separate windows with E library, table of contents, search window, search results, and pages.    ------------------------------  + Date: Sun, 12 Oct 2003 00:37:48 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) - Subject: Re: What does MSCP_SERVE_ALL=4 mean? ( Message-ID: <bma7os$5da$1@pcls4.std.com>  R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  C >Also, there seems to be a contradiction in the HELP (I seem to be  $ >noticing a lot of these recently):   E >       Bit 3      Restrict the serving specified by bit 0. All disks H >       (8)        except those with allocation classes that differ fromF >                  the system's allocation class (set by the ALLOCLASS) >                  parameter) are served.   D >                  This is pre-Version 7.2 behavior. If your clusterE >                  includes systems running OpenVMS 7.1-x or earlier, F >                  and you want to serve all available disks, you mustG >                  specify 9, the result of setting this bit and bit 0.   G >Presumably, the only way to interpret this is that before 7.2, a value E >of 1 didn't serve ALL disks, but only those with the same allocation F >class as the node.  Still, setting the value to 9 should "restore preG >7.2 behaviour" and not "serve all disks".  In the first paragraph, it  H >says that setting bit 3 restricts the serving.  In the next paragraph, G >it says that if I want to serve everything, set this bit.  They can't   >both be correct!   E Bit 3 restricts the other bits.  MSCP_SERVE_ALL=1 serves *all* disks. E MSCP_SERVE_ALL=9 serves all disks except those whose allocation class 5 don't match the server's.  (this is pre-7.2 behavior)   ; The text isn't clear.  Enter a documentation SPR to fix it.  --   -Mike    ------------------------------   End of INFO-VAX 2003.565 ************************                                                                                                                                                        EOYHUhD4L B0AQAAg2EOsHMRDhBzEQ4wd5DZMEog2YBMANsgTXDdYE7A3lBPEN8gQADgEFFw4YBRAORAX+DUkFL 7g1BBd8NKgXADQYFrg3oBKQNyQSNDa8Egw2iBHkNmAR5DZMEQw7OBEMO1gRDDt0EQA7iBEAO6gRAL DvIEQA73BEMOAQVFDgkFUg4LBVIOGAVxDiUFmg4tBacOLwWxDgkFwA7/BNUO4gTNDr8EzQ6yBNIOL mwTDDo4Etg55BKcOiQSnDpAEpA6YBJ8OoASaDqgElQ6vBI0OtASIDrkEgA6/BHsOwQRzDsEEbA7EL BGQOxgRfDskEVw7JBFAOywRIDssEQw7RBD4O1gQ7Dt0EOw7lBDsO7wQ+DvcEPg4BBT4OCQVDDs4EL 9g8bBdwPJQXSDyoFxQ8gBb4PFgW2DwYFpA8BBZAPBgWaDxgFpA8bBZ8PIAWkDzQFpA8/Ba4PNAXDL DzwF1Q9EBd8PTAXnD1EF7g9YBfYPYAX7D2oFABByBQgQfAUNEIcFQxCYBT4QgQVFEHwFZxCRBXkQL ngWAEKgFiBC3BbMQxAWVEIkFgxB3BZUQdwWNEGAFdhBRBVwQPwUuECMFFxAbBfsPFgXiDyUF0g8tL BcUPHQXADxgFtg//BPYPGwUXDmAFIg5OBTsOUQVFDlYFXA5OBXsOaAWNDnUFiA56BXYOcgVkDnIFL VQ5qBUAObwUsDmgFEg5bBRcOYAX5EEcIHxFNCEoRIQhXERwIWhEXCFwRDwhcEQoIXxEFCF8R/QdfL EfgHXxHwB18R6QdIEfUHMxEHCCcRIQgSESYIABFKCPkQRwh2EbMHgBHAB2wR1wdiEcwHWhHCB2wRL sAdxEaEHexGmB3YRswe2CqgF0ArbBb4K4AWxCvoFuQoRBrMKIwauCjcGpwpEBp8KWQaiCmsGlwp6L BpAKoAZ+CqgGbAqrBloKngZcCo8GUgp3BlcKYAZkClQGdgo9BnEKIwZuCg4Gbgr1BYMK6gWVCuAFL rArTBa4KwQW5CrUFvgqoBbYKqAVID5UCbA+LAn4PiwKaD4YCpA+AAqQPdAKiD2kCog9fApwPVQKaL D0sClQ9DApAPOQKIDzECgA8nAnYPKQJ2D0MCeQ9QAnYPWgJpD1oCYg9XAmQPbAJpD34CVQ9+AkUPL hgJQD5ICSA+VApAMSQSfDE4EsQxlBKwMfAScDH4EjQxnBJIMWwSaDEsEkAxJBHECMABcAjMAXAJAL AGkCRQBpAk8AUgJUAFwCZABxAmkAeQJmAIgCXgCfAmQAtgJkAL4CVwC2AkcArgJHAKQCOACXAkUAL iAI9AIACOABzAjsAcwIzAFwCNQBxAjAA3wq7AuIK7ALpCgYD9goaAwULDQMNCy8DMwsvAzsLGANFL Cw0DRQsiA18LQwNuC00DbAtlA1oLhgNSC44DSguTA0MLmAM7C58DNgulAy4LrAMnC7EDHwu3AxALL vAMAC8ED7grJA98K0wPNCt0DvgrnA6wK7wOfCvkDkgrsA4oK2gODCsYDewq0A3EKnwNpCo4DYgp5L A1oKZQNSClMDUgovA00KJANIChgDRQoNA0AKAQM+CvYCOwrsAjYK3wIzCtUCMQq+AiQK1QISCr4CL AwrDAgUKlwIcCpICJwqNAiwKgAI7CmkCSgpLAkgKRQI+CkgCNgpIAi4KSAIpCkgCIgpIAhoKSAISL CkUCCgpDAvEJUALfCSkC5AkfAukJAwLfCfkBwwn2Ab4JDQKzCRACrgkpAq4JPgKiCUsCkglDApAJL MQKaCSkCkgkiApAJDQKKCQAChQnpAXsJzQFuCcUBZAm+AVIJuAFNCcUBVwncAWcJ6QFzCfYBfgkDL An4JDQJzCQgCbgkIAmkJDQJsCRwCXwknAloJKQJaCRwCVwkKAk0J8wE+CeQBLAnVAR8JyAEVCc0BL CgnSAf4I1wH2CNoB7AjaAeII3AHXCN8BzQjkAcMI6QGpCPEBnAj5AZUIAAKICA0CgwgVAnsIHAJzL CCQCaQgpAlUIMQJACDYCNgg2AiwINgIkCDMCHAguAhcIJwISCB8CEAgVAhAICAInCPEBMQjXATsIL 0AFNCMoBVwjKAV8IzQFpCM0BcQjNAXkIzQGACM0BigjNAZUIygGnCLEBqQikAaIIlwGcCIgBpAiDL AbMIhQHACIgBwAh2Ac0IdgHXCHMB5AhxAfEIbgEACWkBDQlkARoJXAEkCVQBLglNATMJTwFICUUBL Xwk9AYUJQAGkCUABuQk9AdIJPQHXCUgB5Ak9Ae4JLgH2CSsBCAoUAQAKAAHpCQUB0gkNAbsJIQGzL CSkBmgkuAZoJGgGkCQUBqQn4AJcJAAF+CQUBcwkAAYMJ6wCNCeQAlQncAJwJ1wCnCc8ArgnKALkJL xQDDCcAAzQm9AOIJtgD2Ca4ACgqmABwKnAAxCpIARQqHAFcKgABpCnUAgApuAJ8KaQCsCm4AuQpzL AMUKeADQCn0A3AqCAOkKhwDzCo0AAAuSAAgLpADnCq4A0gqmAMUKoQDQCrYA1wrCAOwKwgAKC7MAL GgurAB8LqQAnC40AMQuKACwLqQBDC5cAfguUAI0LkgCnC4cA0AuSAPMLZADzC3MAAwycAPELqQD7L C7MAGgykADMMpgBDDK4AMwyXABUMjQASDHUAHAxuACIMewAzDHUAJwxmAD4MZABaDGYAUAxcAIgML UgC7DD0A8wxAAPMMZAANDVcAJw1mAFANawBcDXgAfg11AIgNewCfDXAAtg17APENeADsDWsABQ5rL ADEOaQBDDn0AUg59AF8OgABuDoIAew6FAIgOhwCVDo0ApA6SALEOlwC7DpwA6Q6kACwPpAAnD5wAL SA+eAFoPpgBxD64ApA+2ANAPwgDpD8AA8Q/FAAoQ0gAiEOEANhDpACkQ7gD+D+QA3A/XAOcP5gD7L D/MAABAAAewPDwHxDxcB1w8cAbYPHwGzDykByg9FAdcPSgHiD2QB9g9uAfYPgwEAEJoB7g+SAdoPL iAHKD3YBxQ9xAcAPbAG7