1 INFO-VAX	Sun, 27 Mar 2005	Volume 2005 : Issue 172       Contents: Re: /include/nocopy  Re: /include/nocopy  Re: /include/nocopy  Re: /include/nocopy  Re: /include/nocopy  Re: /include/nocopy : A blast from the past - PDP history, and a bit of TECO tooG Re: about .Note section of ELF; was: CLD symbol table object on Itanium  Best Practie shadow minicopy Re: History of the VMS shark reading RS232 port  F ----------------------------------------------------------------------  % Date: Sun, 27 Mar 2005 10:38:09 +0200 & From: Paul Sture <paul.sture@decus.ch> Subject: Re: /include/nocopy, Message-ID: <3an9m9F69es1jU1@individual.net>   Ken Fairfield wrote:  1 > Phillip Helbig---remove CLOTHES to reply wrote:  > I >> In article <opsn83tczvzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> 
 >> writes: >>4 >>> $ ! From: Ken Fairfield <My.Full.Name@intel.com> >>> $ ! Newsgroups: comp.os.vms 5 >>> $ ! Subject: Re: Creating a wide area VMS Cluster - >>> $ ! Date: Thu, 18 Sep 2003 12:00:24 -0700 ' >>> $ ! Organization: Intel Corporation 1 >>> $ ! Message-ID: <3F6A00C8.7E0EEAF7@intel.com>  >>> $ ! ? >>> $ !         I've said this before in the newsgroup and I'll < >>> $ ! say it again: the ONLY SAFE WAY to mount shadow setsB >>> $ ! (unassisted during startup) is with /INCLUDE/NOCOPY.  ThisF >>> $ ! will assure that you don't overwrite a good member of a shadowH >>> $ ! set with a out-of-date one that, for any of a number of reasons,G >>> $ ! might otherwise be used as the shadow master during a copy (not " >>> $ ! merge) initiated on mount. >> >> >>H >> I remember reading this, thinking about it, then not implementing it,G >> partially because I didn't understand it thorougly.  Let me see if I F >> have it right.  Let's assume a "normal" MOUNT/SHADOW command in theC >> startup.  Everything is up and running.  Member A fails due to a J >> transient power failure.  The node shuts down.  Member A comes back up.J >> Member B fails due to a transient power failure.  The node boots, can'tI >> find B so uses A as the master.  Member B comes back up and becomes a  H >> copy target.  This will lose any data written to B after the failure F >> of A before the node shut down.  However, I suppose this is only a D >> problem if the shadow set is mounted again after B comes back up. >>5 >> What are some more of the "any number of reasons"?  >>E >> The above scenario looks possible but a bit unlikely.  Has anyone   >> every experienced it? >>I >> The weakness I see is the following.  Either I specify all the members I >> on the /SHADOW qualifier, or I don't.  If I specify them all, then the I >> MOUNT will fail if they are not all available (if I specify /INCLUDE), G >> correct?  This means that if I lose a disk, I can't do an unassisted J >> reboot.  That's not very robust.  On the other hand, if I don't specifyG >> all the members, and only (a) non-specified member(s) is there, then  >> again the MOUNT will fail.  >  > C >    So to avoid the problem in your last paragraph, you need a way B > to supply both (all?) potential shadow set members, but use only) > one at a time when you issue the mount.  > F >    What we did (when was at SLAC) was to have an internal subroutineE > in the disk mount procedure.  The subroutine was passed the list of C > all potential shadow set members, but it looped through the list, C > checking each individually to see if it existed and was available D > before trying the mount.  If either check failed, it would try theE > next member in the list.  Of course, the /Include would pick up all  > valid available members. > ? >    I admit to not having a clear scenario for the "bad thing" B > happening, but here's a contrived example:  A and B have locallyF > attached members of DSA0.  A crashes, then at a later time B crashes? > before A has rebooted and shadow copied its member into DSA0. D > Therefore B's local member is more up to date than A's.  A rebootsC > before B and mounts DSA0 with its local member of DSA0, B's being  > unavailable. > D >    NOW COMES THE PROBLEM: B boots and mounts DSA0.  If it _allows_> > its local member to be copied into DSA0, the more up-to-dateC > version will be overwritten.  It will have mounted an out-of-date @ > DSA0 (as did A), but the up-to-date data on B's member will be? > preserved until the system manager can decide how to procede.  > C >    As a variation, imagine the nodes crash as described, with B's @ > member is the "good" one.  Now you boot both A and B together.B > How do you know which member will be the shadow master?  I don't@ > _think_ you do.  There is at least a timing issue if A gets toB > the mount before B.  Or it could depend on the order the membersA > are listed in the /Shadow.  The point is, I'm not convinced you @ > are in control of which member becomes the master, nor whether1 > the shadow server will make the "right" choice.  >   G A couple of points here, which I don't recall having been mentioned in   this thread.  C 1. If you drop shadow set members in order to do some testing, for  ? example, a software upgrade (could be VMS, layered products or  G applications), intending to revert to the dropped members once testing  F is complete, then as far as shadowing sees it, the latest members are  the ones you want overwritten.  E 2. In the case of a system disk, if you boot from say $1$DKA0 (and I  H mean doing a manual console boot to a specific disk rather than letting I the system decide for itself),  then that will always become the master,  8 irrespective of the status of other system disk members.   ------------------------------  + Date: Sun, 27 Mar 2005 09:02:55 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: /include/nocopy$ Message-ID: <d25srv$ala$1@online.de>  9 In article <d2575s$828$1@news01.intel.com>, Ken Fairfield ! <my.full.name@intel.com> writes:    J > > The weakness I see is the following.  Either I specify all the membersJ > > on the /SHADOW qualifier, or I don't.  If I specify them all, then theJ > > MOUNT will fail if they are not all available (if I specify /INCLUDE),H > > correct?  This means that if I lose a disk, I can't do an unassistedK > > reboot.  That's not very robust.  On the other hand, if I don't specify H > > all the members, and only (a) non-specified member(s) is there, then > > again the MOUNT will fail.   > D >     So to avoid the problem in your last paragraph, you need a wayB > to supply both (all?) potential shadow set members, but use only) > one at a time when you issue the mount.  > G >     What we did (when was at SLAC) was to have an internal subroutine E > in the disk mount procedure.  The subroutine was passed the list of C > all potential shadow set members, but it looped through the list, C > checking each individually to see if it existed and was available D > before trying the mount.  If either check failed, it would try theE > next member in the list.  Of course, the /Include would pick up all  > valid available members.  G OK, instead of having a fixed MOUNT command, I construct it on the fly  C and only include those members which are actually available in the  I /SHADOW qualifier.  Of course, I still have to live with the possibility   of the MOUNT command failing.    ------------------------------    Date: 27 Mar 2005 07:46:37 -0800$ From: "AEF" <spamsink2001@yahoo.com> Subject: Re: /include/nocopyC Message-ID: <1111938397.233669.305170@l41g2000cwc.googlegroups.com>   / Phillip Helbig---remove CLOTHES to reply wrote: 7 > In article <opsn83tczvzgicya@hyrrokkin>, "Tom Linden"  <tom@kednos.com>	 > writes:  > 4 > > $ ! From: Ken Fairfield <My.Full.Name@intel.com> > > $ ! Newsgroups: comp.os.vms 5 > > $ ! Subject: Re: Creating a wide area VMS Cluster - > > $ ! Date: Thu, 18 Sep 2003 12:00:24 -0700 ' > > $ ! Organization: Intel Corporation 1 > > $ ! Message-ID: <3F6A00C8.7E0EEAF7@intel.com>  > > $ ! ? > > $ !         I've said this before in the newsgroup and I'll < > > $ ! say it again: the ONLY SAFE WAY to mount shadow setsB > > $ ! (unassisted during startup) is with /INCLUDE/NOCOPY.  ThisF > > $ ! will assure that you don't overwrite a good member of a shadow? > > $ ! set with a out-of-date one that, for any of a number of  reasons,G > > $ ! might otherwise be used as the shadow master during a copy (not " > > $ ! merge) initiated on mount. >  [...] @ > The weakness I see is the following.  Either I specify all the members D > on the /SHADOW qualifier, or I don't.  If I specify them all, then the = > MOUNT will fail if they are not all available (if I specify 
 /INCLUDE),F > correct?  This means that if I lose a disk, I can't do an unassistedA > reboot.  That's not very robust.  On the other hand, if I don't  specify F > all the members, and only (a) non-specified member(s) is there, then > again the MOUNT will fail.    ? Isn't this what /NOASSIST is for? With /NOASSIST, if any of the E mentioned memebers are not present, the MOUNT mounts the members that  are present.     [...]    ------------------------------    Date: 27 Mar 2005 08:08:54 -0800$ From: "AEF" <spamsink2001@yahoo.com> Subject: Re: /include/nocopyB Message-ID: <1111939734.495771.26280@o13g2000cwo.googlegroups.com>   Ken Fairfield wrote:1 > Phillip Helbig---remove CLOTHES to reply wrote: 9 > > In article <opsn83tczvzgicya@hyrrokkin>, "Tom Linden"  <tom@kednos.com> > > writes:  > > 4 > >>$ ! From: Ken Fairfield <My.Full.Name@intel.com> > >>$ ! Newsgroups: comp.os.vms 5 > >>$ ! Subject: Re: Creating a wide area VMS Cluster - > >>$ ! Date: Thu, 18 Sep 2003 12:00:24 -0700 ' > >>$ ! Organization: Intel Corporation 1 > >>$ ! Message-ID: <3F6A00C8.7E0EEAF7@intel.com>  > >>$ ! ? > >>$ !         I've said this before in the newsgroup and I'll < > >>$ ! say it again: the ONLY SAFE WAY to mount shadow setsB > >>$ ! (unassisted during startup) is with /INCLUDE/NOCOPY.  This [...] B > > The weakness I see is the following.  Either I specify all the members F > > on the /SHADOW qualifier, or I don't.  If I specify them all, then the ? > > MOUNT will fail if they are not all available (if I specify 
 /INCLUDE),= > > correct?  This means that if I lose a disk, I can't do an 
 unassistedC > > reboot.  That's not very robust.  On the other hand, if I don't  specify C > > all the members, and only (a) non-specified member(s) is there,  then > > again the MOUNT will fail. > D >     So to avoid the problem in your last paragraph, you need a wayB > to supply both (all?) potential shadow set members, but use only) > one at a time when you issue the mount.     = Why not just use /NOASSIST with all members lised in /shadow?     G >     What we did (when was at SLAC) was to have an internal subroutine E > in the disk mount procedure.  The subroutine was passed the list of C > all potential shadow set members, but it looped through the list, C > checking each individually to see if it existed and was available D > before trying the mount.  If either check failed, it would try theE > next member in the list.  Of course, the /Include would pick up all  > valid available members.     Then why the subroutine?    @ >     I admit to not having a clear scenario for the "bad thing"B > happening, but here's a contrived example:  A and B have locallyF > attached members of DSA0.  A crashes, then at a later time B crashes? > before A has rebooted and shadow copied its member into DSA0. D > Therefore B's local member is more up to date than A's.  A rebootsC > before B and mounts DSA0 with its local member of DSA0, B's being  > unavailable. > E >     NOW COMES THE PROBLEM: B boots and mounts DSA0.  If it _allows_ > > its local member to be copied into DSA0, the more up-to-dateC > version will be overwritten.  It will have mounted an out-of-date @ > DSA0 (as did A), but the up-to-date data on B's member will be? > preserved until the system manager can decide how to procede.     ) But isn't /NOCOPY enough to prevent this?    Why use /INCLUDE?     D >     As a variation, imagine the nodes crash as described, with B's@ > member is the "good" one.  Now you boot both A and B together.B > How do you know which member will be the shadow master?  I don't@ > _think_ you do.  There is at least a timing issue if A gets toB > the mount before B.  Or it could depend on the order the membersA > are listed in the /Shadow.  The point is, I'm not convinced you @ > are in control of which member becomes the master, nor whether1 > the shadow server will make the "right" choice.     G Well, it seems to me that if you need to come up ASAP, you have to work E with what you have, and if you use /NOCOPY in all your system startup F command procedures, you won't lose any data, and if you use /NOASSIST,F you can specify all members of a shadow set and the MOUNT command will@ fail only if all members are not usable. And it seems to me thatD /INCLUDE only takes effect for the creation of the shadow set, i.e.,E when a MOUNT command is issued for said shadow set but the shadow set G isn't mounted on any system yet (not the "first creation" of the shadow  set).    JMHO   ------------------------------  % Date: Sun, 27 Mar 2005 08:58:28 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: /include/nocopy( Message-ID: <opsoa2rqaazgicya@hyrrokkin>  K On Sat, 26 Mar 2005 22:06:40 +0000 (UTC), Phillip Helbig---remove CLOTHES   1 to reply <helbig@astro.multiCLOTHESvax.de> wrote:   G > In article <1111873649.4c64bd5ca0b3925d22f828067e7016ce@teranews>, JF . > Mezei <jfmezei.spamnot@teksavvy.com> writes: > 2 >> Phillip Helbig---remove CLOTHES to reply wrote:E >> > startup.  Everything is up and running.  Member A fails due to a J >> > transient power failure.  The node shuts down.  Member A comes back   >> up.H >> > Member B fails due to a transient power failure.  The node boots,   >> can'tJ >> > find B so uses A as the master.  Member B comes back up and becomes aK >> > copy target.  This will lose any data written to B after the failure    >> of F >> > A before the node shut down.  However, I suppose this is only a  
 >> problem> >> > if the shadow set is mounted again after B comes back up. >>G >> If member A comes back up before B goes down, that A's disks will be / >> marked as copy targets and this invalidated.  > J > Note that between A failing and A coming back up, the node is shut down.G > I should have mentioned that one should consider the shadow set to be J > mounted only on one node.  The point is, while the node is down, nothingJ > can mark A as a copy target.  Then when the node comes back up, A is the4 > only member available, and becomes the new master. > E >> Where this fails is if A comes down , B continues to run for a few G >> minutes and then goes down. Later on, A is brought back up first, at K >> which point, A,s disks are cosnidered valid and become the most uptodate ? >> valid drives and when B comes up, its disks are overwritten.  > J > Right.  Instead of having B going down in the example above, I shut downH > the node.  The point is, as you say, that A comes back up first before. > it has had a chance to become a copy target. > G >> This si why a good DR plan has WRITTEN procedures on how to boot the K >> machines based on a grid of which machines went down in what order. If B E >> was the last member to go down and thus has valid drives, you must % >> ensure that B comes back up first.  > J > This example is actually much more relevant to my case.  All my physicalI > disks have a direct connection to only one node, and all are members of J > shadow sets.  Except for system and page/swap disks, all shadow sets areH > distributed across multiple nodes.  So if node A and member 1 go down,I > then node B and member 2 go down, as you say I really need to make sure C > that node B and member 2 come back up before node A and member 1. J > Normally, I take down 1 node at a time and wait for all shadow copies to> > complete after rebooting it until I take the next node down.  J In my case I want to introduce minicopy, so it sounds like I would have toI dismount the shadow sets from all nodes except the one I am going reboot, H and then repeat the process, exempting nodes that had been rebooted.  Is
 that correct?     I > Occasionally, I do a cluster reboot (for example if I change allocation F > classes, or to save time by avoiding shadow copies if I have to takeJ > down all nodes anyway).  In the event of a power failure, all nodes willH > come up at the same time (I have some code in the startup so that theyG > wait for each other to allow for different lengths of time needed for E > the boot; no point in mounting just one member of a shadow set then C > doing a copy when the other member comes in a few seconds later.)  > G > Thus, I don't see this happening in my case, either during planned or @ > unexpected downtime, but it is something worth thinking about. >    ------------------------------  % Date: Sun, 27 Mar 2005 09:01:11 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: /include/nocopy( Message-ID: <opsoa2v9wezgicya@hyrrokkin>  L On Sat, 26 Mar 2005 18:52:44 -0800, Ken Fairfield <my.full.name@intel.com>   wrote:  1 > Phillip Helbig---remove CLOTHES to reply wrote: I >> In article <opsn83tczvzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> 
 >> writes:4 >>> $ ! From: Ken Fairfield <My.Full.Name@intel.com> >>> $ ! Newsgroups: comp.os.vms 5 >>> $ ! Subject: Re: Creating a wide area VMS Cluster - >>> $ ! Date: Thu, 18 Sep 2003 12:00:24 -0700 ' >>> $ ! Organization: Intel Corporation 1 >>> $ ! Message-ID: <3F6A00C8.7E0EEAF7@intel.com>  >>> $ ! ? >>> $ !         I've said this before in the newsgroup and I'll < >>> $ ! say it again: the ONLY SAFE WAY to mount shadow setsB >>> $ ! (unassisted during startup) is with /INCLUDE/NOCOPY.  ThisF >>> $ ! will assure that you don't overwrite a good member of a shadowH >>> $ ! set with a out-of-date one that, for any of a number of reasons,G >>> $ ! might otherwise be used as the shadow master during a copy (not " >>> $ ! merge) initiated on mount.J >>   I remember reading this, thinking about it, then not implementing it,G >> partially because I didn't understand it thorougly.  Let me see if I F >> have it right.  Let's assume a "normal" MOUNT/SHADOW command in theC >> startup.  Everything is up and running.  Member A fails due to a J >> transient power failure.  The node shuts down.  Member A comes back up.J >> Member B fails due to a transient power failure.  The node boots, can'tJ >> find B so uses A as the master.  Member B comes back up and becomes a  L >> copy target.  This will lose any data written to B after the failure of  L >> A before the node shut down.  However, I suppose this is only a problem  < >> if the shadow set is mounted again after B comes back up.6 >>  What are some more of the "any number of reasons"?G >>  The above scenario looks possible but a bit unlikely.  Has anyone    >> every experienced it?J >>  The weakness I see is the following.  Either I specify all the membersI >> on the /SHADOW qualifier, or I don't.  If I specify them all, then the I >> MOUNT will fail if they are not all available (if I specify /INCLUDE), G >> correct?  This means that if I lose a disk, I can't do an unassisted J >> reboot.  That's not very robust.  On the other hand, if I don't specifyG >> all the members, and only (a) non-specified member(s) is there, then  >> again the MOUNT will fail.  > D >     So to avoid the problem in your last paragraph, you need a wayB > to supply both (all?) potential shadow set members, but use only) > one at a time when you issue the mount.  > G >     What we did (when was at SLAC) was to have an internal subroutine E > in the disk mount procedure.  The subroutine was passed the list of C > all potential shadow set members, but it looped through the list, C > checking each individually to see if it existed and was available D > before trying the mount.  If either check failed, it would try theE > next member in the list.  Of course, the /Include would pick up all  > valid available members.  6 I don't see the difference between the two approaches.   > @ >     I admit to not having a clear scenario for the "bad thing"B > happening, but here's a contrived example:  A and B have locallyF > attached members of DSA0.  A crashes, then at a later time B crashes? > before A has rebooted and shadow copied its member into DSA0. D > Therefore B's local member is more up to date than A's.  A rebootsC > before B and mounts DSA0 with its local member of DSA0, B's being  > unavailable. > E >     NOW COMES THE PROBLEM: B boots and mounts DSA0.  If it _allows_ > > its local member to be copied into DSA0, the more up-to-dateC > version will be overwritten.  It will have mounted an out-of-date @ > DSA0 (as did A), but the up-to-date data on B's member will be? > preserved until the system manager can decide how to procede.  > D >     As a variation, imagine the nodes crash as described, with B's@ > member is the "good" one.  Now you boot both A and B together.B > How do you know which member will be the shadow master?  I don't@ > _think_ you do.  There is at least a timing issue if A gets toB > the mount before B.  Or it could depend on the order the membersA > are listed in the /Shadow.  The point is, I'm not convinced you @ > are in control of which member becomes the master, nor whether1 > the shadow server will make the "right" choice.  >  >      -Ken    ------------------------------  % Date: Sun, 27 Mar 2005 19:46:28 +0200 & From: Paul Sture <paul.sture@decus.ch>C Subject: A blast from the past - PDP history, and a bit of TECO too , Message-ID: <3ao9qbF6buhs5U1@individual.net>  ! http://tenex.opost.com/hbook.html   ? Also: TECO available on Windows, and maybe shortly on Mac OS X.    http://almy.us/teco.html   ------------------------------  # Date: Sun, 27 Mar 2005 13:08:23 GMT " From:   VAXman-  @SendSpamHere.ORGP Subject: Re: about .Note section of ELF; was: CLD symbol table object on Itanium0 Message-ID: <00A4162C.9BE56664@SendSpamHere.ORG>  S In article <00A414EB.33E2FF98@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes: [ >In article <K901e.2313$Eq2.662@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes: " >>VAXman- @SendSpamHere.ORG wrote: >> >>> N >>> I've had my head in ELF image layouts all day too trying to understand howN >>> to get at the image ident info in the .note section.  Finally happened up-L >>> on NHDR$ defs in $ELFDEF which was hiding in STARLET and not in LIB likeO >>> all of the VAX and Alpha image def files.  Sheesh, so much for consistency.  >>>  >>C >>Can't say what that happened other than a tip-o-the-hat to ELF's  - >>standardization (whatever that is worth)???  >>K >>By now, you know that fishing the image ident out of an ELF image is not  K >>for the faint of heart.  For the rest of the readers, the image ident is  K >>located at a somewhat fixed offset in the image header on Alpha and VAX.  I >>  On ELF, there is no such concept.  What ELF does provide is a "note"  I >>section that essentially allows any system to encode any sort of data.  K >>We use them in object files to hold the compiler name which compiled the  I >>module, the compilation date/time, etc.  Getting at them from inside a  B >>program involves opening the file, finding the note section and K >>processing all the notes.  We are looking at adding some callable API in  ) >>a future release to make it all easier.  > F >It appears from the images that I've examined that the .Note section F >falls on a block boundary.  Is this just a figment of the images that9 >I have empirically examined or is this always the case?    G HAPPY EASTER!  It does appear to be that the .Note section always falls G on a block boundary.  I've successfully coded my little project and can G now extract the image idents from all of the images activated to run my . image (ie. the list off of IAC$GL_IMAGE_LIST).  G Break out the Guinness ice cream and the hard boiled eggs; it's time to 9 celebrate.  This Itanium stuff isn't so bad... just ugly.  --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Sun, 27 Mar 2005 09:02:35 -0800 # From: "Tom Linden" <tom@kednos.com> % Subject: Best Practie shadow minicopy ( Message-ID: <opsoa2yldbzgicya@hyrrokkin>  H Such a document would be very useful.  I still don't have clarity on theD issues I raised following the responses so far.  Certainly differentB topologies will dictate different strategies, but I think we couldE start from a reference model.  Suppose you have P shadow sets mounted C on M + N nodes where the P shadow sets are directly attached to the B M nodes.  How do you migrate to use of mincopy?  How do you modify shutdown and startup?    > > > Have three shadow sets in a cluster containing nodes runningA > 7.3, 7.3-1, 7.3-2 and 8.2 on alpha and VAX.  Had to replace the A > CD drives in one 7.3 AXP and one 7.3-1.  The shadow sets are on > > a shared scsi bus with those two and yet a third 7.3-2 node.F > The shadow sets are each 74GB.  A merge operation was thus initiatedD > One of the sets hosts hosts WASD, MX HGFTP and QUEUE Manager. ThisJ > one took 7 days to merge!  (the sets are in a BA356 so only 40MB/sec Tx)G > the others completed in two days.  So I thought I would implement the  > minicopy.  > 1 > Upon startup, the sets are currently mounted as  > $     MOUNT   L > DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)   > COMMONK > and at shutdown a command procedure is called to dismount the disks which K > tests for and skips system disk this is called from syshutdwn.com which   	 > exempts  > shadow masters, i.e. > 2 > $       if f$getdvi(device,"shdw_master") then - >          goto loop > G > So in the the dismount procedure after determining this_disk we issue  > $	dismount 'this_disk' >  > J > So here is the question, to implement minicopy is the following correct? > G > $     MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/POLICY=MINICOPY=OPTIONAL - - > 	/SHADOW=($42$DKA1200:,$42$DKA1300:) COMMON  >  > and for dismount > - > $       If f$getdvi(this_disk,"shdw_member)  > $       then? > $               dismount/policy=minicopy=optional 'this_disk'  > $       else& > $               dismount 'this_disk' > $       endif  > L > I ask because I note a posting by Ken Fairfield, (reproduced in the .com   > file)  > " 2 > $ ! From: Ken Fairfield <My.Full.Name@intel.com> > $ ! Newsgroups: comp.os.vms 3 > $ ! Subject: Re: Creating a wide area VMS Cluster + > $ ! Date: Thu, 18 Sep 2003 12:00:24 -0700 % > $ ! Organization: Intel Corporation / > $ ! Message-ID: <3F6A00C8.7E0EEAF7@intel.com>  > $ ! = > $ !         I've said this before in the newsgroup and I'll : > $ ! say it again: the ONLY SAFE WAY to mount shadow sets@ > $ ! (unassisted during startup) is with /INCLUDE/NOCOPY.  ThisD > $ ! will assure that you don't overwrite a good member of a shadowF > $ ! set with a out-of-date one that, for any of a number of reasons,E > $ ! might otherwise be used as the shadow master during a copy (not   > $ ! merge) initiated on mount. > "  > I > which may predate the appearance of minicopy.  I couldn't find in the    > docs, = > but isn't /NOCOPY exclusive with /POLICY=MINICOPY=OPTIONAL?  > K > Finally, since these sets are mounted on all the nodes, I guess they have H > to be dismounted first from all and then mount with minicopy to create0 > the bit maps, one at a time.  Is that correct? >  > TIA  > Tom    ------------------------------  % Date: Sun, 27 Mar 2005 13:26:47 +0200 3 From: Michael Unger <spam.to.unger@spamgourmet.com> % Subject: Re: History of the VMS shark , Message-ID: <3anjumF6duol1U1@individual.net>  & On 2005-03-26 19:46, "JF Mezei" wrote:   > [...]  > L > Does anyone knwo where I could find a 3d DXF format of the linux penguin ?  ( That's where I found the "Original Tux":6 <http://www.linux.org/info/images/officialpenguin.gif>   > [...]   F There are many links on that site but I don't remember if a 3D version
 is mentioned.    Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------    Date: 27 Mar 2005 01:23:42 -0800& From: patrick.ronsmans@skynet.be (Pat) Subject: reading RS232 port = Message-ID: <54f4941c.0503270123.2c49a85d@posting.google.com>   F I'm using a microVax 4000 under VMS and I'm trying to read the data on* a RS232 port (TX) using a Fortran program.F I already can write data on tis port using the SYS$QIOW system service but I can't read the port . D I've tried to replace the WRITEVBLK by the READVBLK  in the SYS$QIOW# command but it don't seems to work. / Can somebody give me the correct way to do this    Thanks   Pat    ------------------------------   End of INFO-VAX 2005.172 ************************                                                                      cket< Mar 21 13:22:08: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:08: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 13:22:09: IPSEC(crypto_engine_post_encrypt_cef_les): & CEF-les switched tunnel encaped packet< Mar 21 1