1 INFO-VAX	Mon, 15 Aug 2005	Volume 2005 : Issue 453       Contents:% Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set A Re: HP0-436 OpenVMS V7 Network Administration Exam / Study Guides  Re: Image restore fails  Re: LD  (WAS: SAMBA for VMS) Re: Moving System Disk
 my 2 cents Re: my 2 cents Re: SAMBA for VMS  Re: SAMBA for VMS  Re: SAMBA for VMS  Re: SAMBA for VMS  Re: SAMBA for VMS  Re: SAMBA for VMS   F ----------------------------------------------------------------------  % Date: Sun, 14 Aug 2005 14:13:44 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A48462.D7E2D8CC.1@tachysoft.com>   3 >NNTP-Posting-Date: Sat, 13 Aug 2005 22:51:21 -0500 . >Message-ID: <42FEBFDA.1A8C10D9=40comcast.net>& >Date: Sat, 13 Aug 2005 22:51:55 -05005 >From: David J Dachtera <djesys.nospam=40comcast.net> ( >Reply-To: djesysno=40spam.earthlink.net >Organization: DJE Systems >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set      >  >Wayne Sewell wrote: >> =206 >> >NNTP-Posting-Date: Fri, 12 Aug 2005 21:58:51 -05001 >> >Message-ID: <42FD620F.E7F791D7=40comcast.net> ) >> >Date: Fri, 12 Aug 2005 21:59:27 -0500 8 >> >From: David J Dachtera <djesys.nospam=40comcast.net>+ >> >Reply-To: djesysno=40spam.earthlink.net  >> >Organization: DJE Systems  >> >X-Newsgroups: comp.os.vms 2 >> >Subject: Re: Help Needed: Tape Backup Save Set >> =20 >> >Z wrote: >> >>  >> >> David J Dachtera wrote:  >> >> >>>You can" >> >> >>>BACKUP/LIST tape_device:* >> >> F >> >> >>If you're going to use BACKUP, let VMS mount the tape for you. >> >> : >> >> > Ooohhh... Careful there=21 Not always a good idea. >> >>   >> >> When isn't it a good idea? >> >' >> >See the other posts in this thread,  >> =20L >> Some of which were irrelevant for most of us, referring to ancient versi= ons ofC >> vms and unreliable tape drives that hardly anyone uses any more.  >> =20( >> >or just consider circumstances whereJ >> >you may want to start/resume BACKUP operations from the tape's currentJ >> >position, or any other circumstance where knowing the current state ofC >> >the tape is important, as opposed to assuming what it MIGHT be.  >> > >> =20L >> There's no doubt what it will be if backup does the mount: at the beginn= ing ofL >> the tape.  If you say /rewind on the backup it will stay there.  If you = don't,L >> backup will go to the end of the tape to write the saveset.  Doesn't tha= t count , >> as knowing the current state of the tape? >> >> =5Bsnippage=5D  > H >Yes and no. In a predictable series of events (no automation failures), >this could be true. > > >When WRITING, BACKUP will start at BOT when first MOUNTed =20  # not true without /rewind, see below    >or if you use: >/REWIND, at the current tape position without /REWIND =20    L In the above, =22current tape position=22 is ambiguous.  Do you mean =22the=	  position L of the tape at the conclusion of the last backup=22 AKA end of tape, or do = you L mean =22the position of the tape at this point of time=22?  They are not th= e sameL if you have performed manual tape operations since the backup.  For instanc= e,L if you did ten consecutive backups and then skipped backward five savesets,=  the; current position and the end of tape would not be the same.     K If =22current position=22 meant anything, I could do a dozen backups, use =  =22setL magtape/skip=3Dfile=3D-6=22 to back up two savesets, and overwrite the last=  twoL savesets with the next backup, thus wiping them out.  I actually attempt to=  do  this in the test below.      >(check the H >HELP/doc. to see what the relevant default is for /REWIND - it varies). >   L Unless =22current tape position=22 always equals =22end-of-tape=22, you nee= d to reread K it yourself, because the latter is what it actually says.  The help text is I reproduced in the log file below.  In the part about writing, there is no L mention of =22current tape position=22.  Instead it says =22Otherwise, the = magneticG tape begins (or resumes)  processing from the logical end-of-tape (EOT) 
 marker.=22    L For write, the help says that the saveset will be written at EOT if you don= 't' use /rewind or you are not at BOT.  =20   I And in fact, even that is not true.  The help is wrong about the behavior J during writes.  You always have to use /rewind if you want to write at theB beginning of the tape, even if you are already sitting there.  =20  L Before anyone goes ballistic, hear me out.  More importantly, look at the l= ogL from an actual test below.  Better yet, try the procedure yourself on a scr= atch tape.   L It's really pretty simple.  If you say /rewind, the saveset is written at t= heL beginning of the tape.  If you say /norewind (the default), it is written atL the end of the tape.  Period.  The actual position of the tape at the time = you L issue the backup command (BOT, EOT, somewhere in the middle) does not matte= r. =20L True, if you are writing savesets sequentially, you are probably already at=  EOTK when starting the next saveset.  But if you manually reposition the tape in A between backups, the next saveset will *still* be written at EOT.   L The fact that backup by default always writes at the end of the tape bites = myL ass all the time.  Since I often do interactive backups to support developm= ent L of tapesys, I often forget to init the tape manually or use /rewind when =20L running what is supposed to be a quick test.  Then I have to sit there for aL while while backup scans for EOT.  Which might be a long while if the tape = has  a lot on it.  L The *only* way you can write a saveset to the middle of a tape is to manual= lyL position there with skip and then manually write a EOT marker by doing =22s= etL mag/end=22 three times.  And even that doesn't not invalidate my statement = above.L Without /rewind, backup will *still* not write anywhere but the EOT marker.=  =20/ It's just not the same place it was before. =20   . For proof of my assertions, see the log below.  G >Likewise, when READING, BACKUP will start at BOT when first MOUNTed or B >if you use /REWIND, at the current tape position without /REWIND.  L This is true.  The term =22current tape position=22 has meaning only for re= ad operations.       L Here is the log from the test I did.  This was performed on a Digital Perso= nal L WorkStation 600au running 7.3-2.  The tape drive is a =22DEC DLT2000 15/30 = GB=22 ! served from another cluster node.   K Note that the saveset is *always* written to the end of the tape, no matter L *what* the position of the tape on the drive, except for the two backups wh= ich I specified /rewind.  Only in these backups is the tape initialized and the - saveset written at the beginning of the tape.     L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =24 set ver  =24 help backup/rewind   BACKUP  	   /REWIND            /REWIND          /NOREWIND (default)   '      Input or Output Save-Set Qualifier   E      As an input save-set qualifier, causes the input tape reel to be F      rewound (/REWIND) or not rewound (/NOREWIND) to beginning-of-tapeD      (BOT) before BACKUP searches for the save-set name specified in      the input specifier.   ?      As an output save-set qualifier, specifies that the output >      magnetic tape is to be rewound and initialized before the@      save operation begins (/REWIND) or that the tape is neitherC      to be rewound nor initialized before the save operation begins F      (/NOREWIND). Initializing the tape removes access to any existing      data on the tape.  E      If you want to start processing at BOT, and the magnetic tape is C      already positioned beyond BOT, specify /REWIND. Otherwise, the B      magnetic tape begins (or resumes) processing from the logical      end-of-tape (EOT) marker.  H      Use the /=5BNO=5DREWIND qualifier for magnetic tape save sets only.    =20     =24 alloc ZEPPO=24MKB200: tape( %DCL-I-ALLOC, _ZEPPO=24MKB200: allocated; =24 backup/rewind/lab=3Ddltest home:login.com tape:save.one 4 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200:5 =24 backup/lab=3Ddltest  home:login.com tape:save.two 7 =24 backup/lab=3Ddltest  home:login.com tape:save.three  =24=21L =24=21 just for laffs, go back to the beginning of the tape in the middle o= f the L =24=21 test; this will show that saveset writes go to the end of the tape n= o matterL =24=21 what the current position; we will find that save.four will still be=  after7 =24=21 save.three and not at the beginning of the tape.  =24=21 =24 set magtape/rew tape, =24 sho dev/ful tape	=21 is the tape at BOT?  L Magtape ZEPPO=24MKB200:, device type DEC DLT2000 15/30 GB, is online, alloc= ated, L     mounted foreign, record-oriented device, file-oriented device, availabl= e toE     cluster, error logging is enabled, controller supports compaction      (compaction  disabled).   L     Error count                    0    Operations completed               = 4021L     Owner process        =22BATCH_349=22    Owner UIC                      =  =5BWAYNE=5DL     Owner process ID        20E00460    Dev Prot            S:RWPL,O:RWPL,G= :R,WL     Reference count                2    Default buffer size                = 8192  L     Volume label            =22DLTEST=22    Relative volume no.            =        0L     Record size                    0    Transaction count                  =    1L     Mount status             Process    Mount count                        =    1(     ACP process name              =22=22L     Density                     TK87    Format                        Norma= l-11L     Host name                =22ZEPPO=22    Host type, avail DIGITAL Server=  3000 Model 3300 6400A, yes   0   Volume status:  beginning-of-tape, odd parity.  6 =24 backup/lab=3Ddltest  home:login.com tape:save.four6 =24 backup/lab=3Ddltest  home:login.com tape:save.five =24=21L =24=21 For more farting around with position, back up the tape two savesets= , to theL =24=21 beginning of saveset four.  If this mattered, saveset six would over= write ) =24=21 four; four and five would be lost.  =24=21? =24 set magtape/skip=3Dfile=3D-6 tape  =21 go back two savesets 5 =24 backup/lab=3Ddltest  home:login.com tape:save.six  =24 dismount/nounload tape =24 mount tape dltest 4 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200:
 =24 dir tape:     Directory _ZEPPO=24MKB200:=5B=5D  L SAVE.ONE;1          SAVE.TWO;1          SAVE.THREE;1        SAVE.FOUR;1    =     =20 + SAVE.FIVE;1         SAVE.SIX;1          =20    Total of 6 files.  =24=21L =24=21 As we can see here, all six savesets are present.  Despite current p= osition L =24=21 of the tape drive, all savesets were written to the current end of t= he tape. =24=21 =24 dismount/nounload tape =24=21L =24=21 The help implies that if the tape is at BOT, the saveset will be wri= ttenL =24=21 there, even without /rewind.  This next backup will show this not to=  be the L =24=21 case.  The saveset will go to the end, after one thru six, just like=  always. =24=218 =24 backup/lab=3Ddltest   home:login.com tape:save.seven4 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200: =24 dismount/nounload tape =24=21 =24=21 =24 mount tape dltest 4 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200:
 =24 dir tape:     Directory _ZEPPO=24MKB200:=5B=5D  L SAVE.ONE;1          SAVE.TWO;1          SAVE.THREE;1        SAVE.FOUR;1    =     =20 ? SAVE.FIVE;1         SAVE.SIX;1          SAVE.SEVEN;1        =20    Total of 7 files.  =24=21L =24=21 once again, all savesets are present, and in the order of the backup= s. =24=21 =24 dismount/nounload tape =24=21L =24=21 Let's do it again, this time explictly mounting the tape.  This allo= ws us 5 =24=21 to *check* for BOT before starting the backup.  =24=21 =24 mount/for tape =204 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200:, =24 sho dev/ful tape	=21 is the tape at BOT?  L Magtape ZEPPO=24MKB200:, device type DEC DLT2000 15/30 GB, is online, alloc= ated, L     mounted foreign, record-oriented device, file-oriented device, availabl= e toE     cluster, error logging is enabled, controller supports compaction      (compaction  disabled).   L     Error count                    0    Operations completed               = 4337L     Owner process        =22BATCH_349=22    Owner UIC                      =  =5BWAYNE=5DL     Owner process ID        20E00460    Dev Prot            S:RWPL,O:RWPL,G= :R,WL     Reference count                2    Default buffer size                =  512  L     Volume label            =22DLTEST=22    Relative volume no.            =        0L     Record size                    0    Transaction count                  =    1L     Mount status             Process    Mount count                        =    1(     ACP process name              =22=22L     Density                  default    Format                        Norma= l-11L     Host name                =22ZEPPO=22    Host type, avail DIGITAL Server=  3000 Model 3300 6400A, yes   0   Volume status:  beginning-of-tape, odd parity.  8 =24 backup/lab=3Ddltest   home:login.com tape:save.eight =24 dismount/nounload tape =24=21 =24=21 =24 mount tape dltest 4 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200:
 =24 dir tape:     Directory _ZEPPO=24MKB200:=5B=5D  L SAVE.ONE;1          SAVE.TWO;1          SAVE.THREE;1        SAVE.FOUR;1    =     =20 L SAVE.FIVE;1         SAVE.SIX;1          SAVE.SEVEN;1        SAVE.EIGHT;1   =     =20    Total of 8 files.  =24=21L =24=21 once again, all savesets are present, and in the order of the backup= s. =24=21 =24 dismount/nounload tape =24=21L =24=21 Now we will do another /rewind.  Only now will the prior savesets be=  =20L =24=21 overwritten, because only now are we writing to the beginning of the=  tape. =24=21> =24 backup/lab=3Ddltest/rewind   home:login.com tape:save.nine4 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200: =24 dismount/nounload tape =24=21 =24=21 =24 mount tape dltest 4 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO=24MKB200:
 =24 dir tape:     Directory _ZEPPO=24MKB200:=5B=5D   SAVE.NINE;1         =20    Total of 1 file. =24=21L =24=21 Now there is only saveset nine, because the tape has been reinitiali= zed. =24=21 =24 dismount/nounload tape =24=21 =24 dealloc tape8   WAYNE        job terminated at 14-AUG-2005 13:12:05.28 =0D=0A  Accounting information: L   Buffered I/O count:               1138      Peak working set size:       = 3968L   Direct I/O count:                  402      Peak virtual size:         17= 4464L   Page faults:                      4507      Mounted volumes:             =    8L   Charged CPU time:        0 00:00:01.28      Elapsed time:       0 00:03:4= 7.97L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3DL Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne=40tachysof= t.com > http://www.tachysoft.com/www/tachyon.html and wayne.html   =20L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3DL Jake Blues:=22You traded the Caddy for a microphone? ...... Okay, I can buy=	  that.=22    ------------------------------  % Date: Sun, 14 Aug 2005 15:52:19 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A48470.9D45D710.3@tachysoft.com>    >From: Z <Z@no.spam> >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set  >  >David J Dachtera wrote:
 >>>>>>You can * >>>>>>MOUNT/FOREIGN tape_device tape_label >>>>>>BACKUP/LIST tape_device:*  > L >>>>>If you're going to use BACKUP, let VMS [BACKUP] mount the tape for you. > 4 >>>>Ooohhh... Careful there! Not always a good idea. >  >>>When isn't it a good idea?  > K >> See the other posts in this thread, or just consider circumstances where I >> you may want to start/resume BACKUP operations from the tape's current I >> position, or any other circumstance where knowing the current state of B >> the tape is important, as opposed to assuming what it MIGHT be. > J >Well, of course; but that's not what I thought you were saying, nor what @ >I was asking. Is it ever a bad idea when taking a tape listing?  K The only reason I can think of is if you have 500 savesets on the same tape J with the same name, which unfortunately, is possible to do, if you used anO output parameter of tape:my_ambiguous.saveset on 500 backups to the same tape.  K If you want a listing of ambiguous saveset number 60, you could do a manual N mount, then "set mag /skip=file=180" and then when you did the backup/list you would get the right one.  2 If you do *not* have ambiguous saveset names, then   mount/for tape backup/list tape:unambig.save    is logically identical to just   backup/list tape:unambig.save   " if the tape is not already mounted         Whether unambiguous or not,   	 mount/for  backup/list tape:    is identical to    backup/list tape:   M when the tape is not mounted (assuming you don't do any tape movement between 0 the mount and the backup/list in the first case) > F >I've had customers $MOUNT without /FOREIGN and, if they do that, the D >$BACKUP/LIST completes with no errors but the list is empty (IIRC).  I Backup simply doesn't work with ansi mounted tapes, which is what you get N without foreign.  Only foreign mounted.  It's not clear from the above whetherO the non-foreign mount was on the backup or the list or both, but in any case it  shouldn't be used with either.   Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Sun, 14 Aug 2005 16:16:38 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A48474.0348E2DE.1@tachysoft.com>   & >Date: Sun, 14 Aug 2005 00:13:22 -0400. >From: JF Mezei <jfmezei.spamnot@teksavvy.com> >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set    >David J Dachtera wrote:J >> When WRITING, BACKUP will start at BOT when first MOUNTed or if you useC >> /REWIND, at the current tape position without /REWIND (check the J >> HELP/doc. to see what the relevant default is for /REWIND - it varies).  I Not only is the actual help text for wrong for writes, but this is not an O accurate rendition of it anyway, unless you substitute "end-of-tape marker" for M "current tape position".  See my other post on this, complete with log file.    J When writing, backup will always write to the current end-of-tape (not theM current position of the tape) unless /rewind is specified.  It doesn't matter G what the current position of the tape is, including BOT.  If /rewind is M specified, it will initialize the tape and write the saveset at the beginning M of the tape.  Period.  Again, see my other post and the log file for proof of  this.   O By the way, I apoligize in advance for the unreadability of my other post.  For N some reason, the billyshit reformatting kicked in, replacing dollar signs withL "=24" and other stupid horseshit such as arbitrary line breaks.  Needless to4 say, this makes the DCL extremely difficult to read.   > % >Something I was never quite sure of:  >  >If you have >  >$! ) >$BACKUP/IMAGE $DISK1 mua0:disk1.sav/save  >$some commands ) >$BACKUP/IMAGE $DISK2 mua0:disk2.sav/save  >$!  >  > D >What is needed in the above to ensure that the second backup writes! >disk2.sav AFTER disk1.sav ??????   M Nothing.  This is the default.  The current position of the tape on the drive M doesn't matter.  Without /rewind, backup will scan for the end-of-tape marker J before writing anything.  This would be immediately after the last saveset written.   > H >Or let me rephrase the question: how does the first backup command knowI >it shouldn't dismount the tape when it is done so that subsequent backup I >commands will have the tape already mounted and already at end of tape ?   N First, backup does not dismount the tape at all unless told to do by /release.L (We will forget about reaching the physical end of tape for the moment).  It* assumes you may want to do another backup.  8 Second, by default it writes to the current end of tape.   >-- P >===============================================================================N >Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx; >http://www.tachysoft.xxx/www/tachyon.html and wayne.html   L >change .xxx to .com in addresses above, assuming you are not a spambot  :-)P >===============================================================================Q >Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."  --  O =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Sun, 14 Aug 2005 18:54:24 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A4848A.0D681111.1@tachysoft.com>   % >From: "AEF" <spamsink2001@yahoo.com>  >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set ! >Date: 12 Aug 2005 15:58:34 -0700    >  >Chris Allen wrote: @ >> Well everything worked fine this time around.  I must of beenF >> mounting it wrong before.  Here's a copy of my backup .com file andH >> some terminal output.  It really baffles me that "BACKUP/LIST" workedG >> this time around, because I'm almost positive I tried it before with H >> and without /FOR for mount.  But I MUST have not since it worked now.I >> This time around I also tried DIR and BACKUP/LIST with and without the J >> /MEDIA=COMPACT and it made no difference.  If I restore and forget this >  > E >/MEDIA=COMPACT only applies when writing to tape. If you use it with ? >BACKUP, it only applies to tapes that BACKUP actually mounts.    3 And on top of that, if you use /rewind.  See below.    >If you G >MOUNT a tape without /MEDIA=COMPACT, then run BACKUP ... /MED=COMPACT,  >you will not get compaction.  >     K This does not appear to be true on my system.  Check out the following log:       	 $ set ver  $ alloc ZEPPO$MKB200: tape& %DCL-I-ALLOC, _ZEPPO$MKB200: allocated $ sho dev/ful tape  N Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated,M     record-oriented device, file-oriented device, available to cluster, error N     logging is enabled, controller supports compaction (compaction  disabled).  O     Error count                    0    Operations completed               4659 O     Owner process        "BATCH_359"    Owner UIC                      [SYSTEM] O     Owner process ID        20E00467    Dev Prot            S:RWPL,O:RWPL,G:R,W O     Reference count                1    Default buffer size                 512 O     Density                     TK87    Format                        Normal-11 b     Host name                "ZEPPO"    Host type, avail DIGITAL Server 3000 Model 3300 6400A, yes  G   Volume status:  no-unload on dismount, beginning-of-tape, odd parity.    $ mount/for tape  2 %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO$MKB200: $ sho dev/ful tape  N Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated,O     mounted foreign, record-oriented device, file-oriented device, available to E     cluster, error logging is enabled, controller supports compaction      (compaction  disabled).  ---> ^^^^^^^^^^^^^^^^^^^^     O     Error count                    0    Operations completed               4674 O     Owner process        "BATCH_359"    Owner UIC                       [WAYNE] O     Owner process ID        20E00467    Dev Prot            S:RWPL,O:RWPL,G:R,W O     Reference count                2    Default buffer size                 512   O     Volume label            "DLTEST"    Relative volume no.                   0 O     Record size                    0    Transaction count                     1 O     Mount status             Process    Mount count                           1 $     ACP process name              ""O     Density                  default    Format                        Normal-11 b     Host name                "ZEPPO"    Host type, avail DIGITAL Server 3000 Model 3300 6400A, yes  0   Volume status:  beginning-of-tape, odd parity.  E $ backup/rewind/lab=dltest/media=compact home:login.com tape:save.one  $ sho dev/ful tape  N Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated,O     mounted foreign, record-oriented device, file-oriented device, available to E     cluster, error logging is enabled, controller supports compaction      (compaction enabled).  ---> ^^^^^^^^^^^^^^^^^^^^   O     Error count                    0    Operations completed               4707 O     Owner process        "BATCH_359"    Owner UIC                       [WAYNE] O     Owner process ID        20E00467    Dev Prot            S:RWPL,O:RWPL,G:R,W O     Reference count                2    Default buffer size                 512   O     Volume label            "DLTEST"    Relative volume no.                   0 O     Record size                    0    Transaction count                     1 O     Mount status             Process    Mount count                           1 $     ACP process name              ""O     Density                     TK87    Format                        Normal-11 b     Host name                "ZEPPO"    Host type, avail DIGITAL Server 3000 Model 3300 6400A, yes     Volume status:  odd parity.    $! $ dismount/nounload tape $! $ dealloc tape    K After the mount, but before the backup, compaction was disabled.  After the M backup compaction was enabled.  And the tape was still mounted.  Ergo, backup , turned on compaction despite what mount did.  M When you do a /rewind, backup has to write a new label to the tape.  Since it O is starting at the very beginning, including the headers, there is no reason it M can't turn compaction on or off according to its own media qualifier, even if  the mount didn't specify it.  1 Backup with /norewind is a whole different story.   O If you do /norewind, you are appending to the end of an existing tape.  If data L is already on the tape (EOT is not the same position as BOT), you can't makeO any changes to compaction, on or off, with most current tape drives.  They will I not let you make compaction/density changes in the middle of the tape.  I L believe some very old tape drives could do this, but whether any of them are still running is unknown.   L You can see this in help mount/media: "Note that for compacting tape drives,N once data compaction or noncompaction has been selected for a given tape, thatH status applies to the entire tape."  There is similar text for /density.  M So specifying compaction, either via mount or backup/norewind, on an existing N nonempty uncompacted tape will not do anything.  And vice versa.  And /density6 won't do anything at all on an existing nonempty tape.   Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------    Date: 14 Aug 2005 20:04:22 -0700$ From: "AEF" <spamsink2001@yahoo.com>. Subject: Re: Help Needed: Tape Backup Save SetC Message-ID: <1124075062.733972.316260@g43g2000cwa.googlegroups.com>    Wayne Sewell wrote: ' > >From: "AEF" <spamsink2001@yahoo.com>  > >X-Newsgroups: comp.os.vms1 > >Subject: Re: Help Needed: Tape Backup Save Set # > >Date: 12 Aug 2005 15:58:34 -0700  >  > >  > >Chris Allen wrote: B > >> Well everything worked fine this time around.  I must of beenH > >> mounting it wrong before.  Here's a copy of my backup .com file andJ > >> some terminal output.  It really baffles me that "BACKUP/LIST" workedI > >> this time around, because I'm almost positive I tried it before with J > >> and without /FOR for mount.  But I MUST have not since it worked now.K > >> This time around I also tried DIR and BACKUP/LIST with and without the L > >> /MEDIA=COMPACT and it made no difference.  If I restore and forget this > >  > > G > >/MEDIA=COMPACT only applies when writing to tape. If you use it with @ > >BACKUP, it only applies to tapes that BACKUP actually mounts. > 5 > And on top of that, if you use /rewind.  See below.     ? If you use rewind, then it re-inits the tape, re-mounts it, and E compaction is therefore enabled as I said in the post you're quoting.     	 > >If you I > >MOUNT a tape without /MEDIA=COMPACT, then run BACKUP ... /MED=COMPACT,  > >you will not get compaction.  > >  >  > M > This does not appear to be true on my system.  Check out the following log:  >  > $ set ver  > $ alloc ZEPPO$MKB200: tape( > %DCL-I-ALLOC, _ZEPPO$MKB200: allocated > $ sho dev/ful tape > P > Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated,O >     record-oriented device, file-oriented device, available to cluster, error P >     logging is enabled, controller supports compaction (compaction  disabled). > Q >     Error count                    0    Operations completed               4659 Q >     Owner process        "BATCH_359"    Owner UIC                      [SYSTEM] Q >     Owner process ID        20E00467    Dev Prot            S:RWPL,O:RWPL,G:R,W Q >     Reference count                1    Default buffer size                 512 Q >     Density                     TK87    Format                        Normal-11 d >     Host name                "ZEPPO"    Host type, avail DIGITAL Server 3000 Model 3300 6400A, yes > I >   Volume status:  no-unload on dismount, beginning-of-tape, odd parity.  >  > $ mount/for tape4 > %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO$MKB200: > $ sho dev/ful tape > P > Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated,Q >     mounted foreign, record-oriented device, file-oriented device, available to G >     cluster, error logging is enabled, controller supports compaction  >     (compaction  disabled).  > ---> ^^^^^^^^^^^^^^^^^^^^    Noted.   [...]  > G > $ backup/rewind/lab=dltest/media=compact home:login.com tape:save.one  > $ sho dev/ful tape  D There was no message about mounting and tape labels after the BACKUPE command? I'll check it tomorrow when I'm back at work what my systems G do. I can't check it now. Even so, you can't INIT a MOUNTed tape. So if ? BACKUP is initing the tape when /rewind is specified, it has to B dismount it first. Then of course it has to "re-mount" it after itG inits it. If you look at it this way -- and I do -- what I wrote before F is right. Besides, you can change the label with BACKUP ... /REWIND so( doesn't a new label require a new MOUNT?   > P > Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated,Q >     mounted foreign, record-oriented device, file-oriented device, available to G >     cluster, error logging is enabled, controller supports compaction  >     (compaction enabled).  > ---> ^^^^^^^^^^^^^^^^^^^^   1 Noted. But same comment as I opened with applies.    [...]  > O > When you do a /rewind, backup has to write a new label to the tape.  Since it Q > is starting at the very beginning, including the headers, there is no reason it O > can't turn compaction on or off according to its own media qualifier, even if  > the mount didn't specify it.  6 IIRC, this involves a "re-mount". I'll check tomorrow.   > 3 > Backup with /norewind is a whole different story.  > Q > If you do /norewind, you are appending to the end of an existing tape.  If data N > is already on the tape (EOT is not the same position as BOT), you can't makeQ > any changes to compaction, on or off, with most current tape drives.  They will K > not let you make compaction/density changes in the middle of the tape.  I N > believe some very old tape drives could do this, but whether any of them are > still running is unknown.     G Hmmm. Mine seem to do that. That is, if I take a tape, write a save set > on it without /media=compaction, dismount it, re-mount it withF /med=compact, then append a second save set, it compacts! I'll have toC do a more careful test when time allows by actually timing the save B operation on a quiet system to see if the drive is lying about its compaction state.     N > You can see this in help mount/media: "Note that for compacting tape drives,P > once data compaction or noncompaction has been selected for a given tape, thatJ > status applies to the entire tape."  There is similar text for /density.    D This is wrong unless the system is lying about whether compaction is: enabled. Again, I'll recheck tomorrow or when time allows.    O > So specifying compaction, either via mount or backup/norewind, on an existing P > nonempty uncompacted tape will not do anything.  And vice versa.  And /density8 > won't do anything at all on an existing nonempty tape.  F I've use /density only rarely and in the distant past and don't recall* anything about it so I can't comment here.   >  > Wayne Q > =============================================================================== P > Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com: > http://www.tachysoft.com/www/tachyon.html and wayne.htmlQ > =============================================================================== R > Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   AEF    ------------------------------    Date: 14 Aug 2005 21:22:41 -0700$ From: "AEF" <spamsink2001@yahoo.com>. Subject: Re: Help Needed: Tape Backup Save SetC Message-ID: <1124079761.745778.186980@z14g2000cwz.googlegroups.com>    Wayne Sewell wrote: ' > >From: "AEF" <spamsink2001@yahoo.com>  > >X-Newsgroups: comp.os.vms1 > >Subject: Re: Help Needed: Tape Backup Save Set # > >Date: 13 Aug 2005 10:56:34 -0700  >  > > J > >I am just curious what could cause such a problem. I cannot imagine howI > >it could happen. How could BACKUP "get so upset" so as to not function H > >correctly and additionally corrupt the memory registers that hold the > >tape label? > >  > P > There are several categories of bug that can cause memory corruption.  Once itO > happens, everything goes crazy.  Strings contain garbage, flags switch to the J > opposite state, enumerated types go out of range, integers contain bogusQ > values.  Often strings are overwritten with integers at some offset within them 4 > and integers contain one or more ascii characters. [...] M > Anyway, there are a number of things that could cause results like what you  > saw.  G That's all fine. But that's the part after the big mystery. Here're the 
 scenarios:   A:)  0. Drive is not in use.  1. Load 2ND tape volume  2. MOUNT/FOR drive:  3. BACKUP/LIST drive: B    a. BACKUP sees the tape is already mounted and notes its label.C    b. BACKUP reads the tape and warns about not being first volume, 0 lists the contents of the tape, and all is fine.   B:)  0. Drive is not in use.  1. Load 2ND tape volume  2. Twiddle thumbs. 3. BACKUP/LIST drive: -    a. BACKUP mounts the tape noting its label A    b. BACKUP reads the tape and should warn about not being first E volume but instead goes bonkers, requires a ^Y abort, and trashes the ( system registers that contain the label.  G But if the tape were the first volume, B3b would read and list the tape G normally. So something wacky happens at the moment BACKUP discovers the G tape is not the first volume. This means the mount by BACKUP is somehow G different than the mount by MOUNT, but is only fatal if the tape is not F the first volume. So the BACKUP mount trashes some part of memory that6 is only used if the tape is not the first volume? Huh?   ------------------------------    Date: 14 Aug 2005 21:25:55 -0700$ From: "AEF" <spamsink2001@yahoo.com>. Subject: Re: Help Needed: Tape Backup Save SetB Message-ID: <1124079955.460882.25290@g14g2000cwa.googlegroups.com>   JF Mezei wrote:  > David J Dachtera wrote: K > > When WRITING, BACKUP will start at BOT when first MOUNTed or if you use D > > /REWIND, at the current tape position without /REWIND (check theK > > HELP/doc. to see what the relevant default is for /REWIND - it varies).  > & > Something I was never quite sure of: > 
 > If you have  >  > $!* > $BACKUP/IMAGE $DISK1 mua0:disk1.sav/save > $some commands* > $BACKUP/IMAGE $DISK2 mua0:disk2.sav/save > $! >  > E > What is needed in the above to ensure that the second backup writes " > disk2.sav AFTER disk1.sav ??????    + Is there some reason you can't just try it?     I > Or let me rephrase the question: how does the first backup command know J > it shouldn't dismount the tape when it is done so that subsequent backupJ > commands will have the tape already mounted and already at end of tape ?    E Now just why in the world would the first backup command dismount the D tape? And why wouldn't it be at the end of the tape when it is done?  & Have you ever used the BACKUP command?   ------------------------------  % Date: Mon, 15 Aug 2005 00:05:18 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A484B5.7BF5FA14.1@tachysoft.com>   % >From: "AEF" <spamsink2001@yahoo.com>  >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set    >Wayne Sewell wrote:( >> >From: "AEF" <spamsink2001@yahoo.com> >> >X-Newsgroups: comp.os.vms 2 >> >Subject: Re: Help Needed: Tape Backup Save Set$ >> >Date: 12 Aug 2005 15:58:34 -0700 >> >> > >> >Chris Allen wrote:C >> >> Well everything worked fine this time around.  I must of been I >> >> mounting it wrong before.  Here's a copy of my backup .com file and K >> >> some terminal output.  It really baffles me that "BACKUP/LIST" worked J >> >> this time around, because I'm almost positive I tried it before withK >> >> and without /FOR for mount.  But I MUST have not since it worked now. L >> >> This time around I also tried DIR and BACKUP/LIST with and without theM >> >> /MEDIA=COMPACT and it made no difference.  If I restore and forget this  >> > >> >H >> >/MEDIA=COMPACT only applies when writing to tape. If you use it withA >> >BACKUP, it only applies to tapes that BACKUP actually mounts.  >>6 >> And on top of that, if you use /rewind.  See below. >  > @ >If you use rewind, then it re-inits the tape, re-mounts it, andF >compaction is therefore enabled as I said in the post you're quoting.  F But using /rewind *without* backup mounting the tape will also turn onO compaction.  That's in direct opposition to your statement.  You obviously mean 4 an implied mount that is part of /rewind processing.  N You are assuming backup actually does a formal dismount/init/remount sequence,N using the standard system services, if you use /rewind and the tape is alreadyM mounted foreign.  I would have to look at the backup source to be sure, but I G am not sure that backup actually does this.  It is not required.  It is G possible to initialize a tape without it as long as the tape is mounted O foreign.   You can do a rewind qio to the drive, which takes it to the absolute L beginning of the tape, even ahead of the label (not possible with a standardN ansi mount).  Then issue write qios to write the header records (three of themM IIRC), including the VOL1 record containing the label, followed by three tape C marks to create the end-of-tape marker.  At this point, the tape is N indistinguishable from one that an init was just performed on, so backup couldN simply go on with its usual gag of writing the saveset at EOT no matter what. N And the tape was *not* dismounted/remounted.  I do this inside tapesys to makeN absolutely sure the tape is initialized before vms backup is even executed.  IO haven't looked at this part of the backup source code lately, but they could do N it that way if they wanted.  No need to call sys$mount or sys$init_vol, and itH would be a hell of a lot faster.  Again, would need to check the source.     > 
 >> >If youJ >> >MOUNT a tape without /MEDIA=COMPACT, then run BACKUP ... /MED=COMPACT,  >> >you will not get compaction. >> > >> >>N >> This does not appear to be true on my system.  Check out the following log: >> >> $ set ver >> $ alloc ZEPPO$MKB200: tape ) >> %DCL-I-ALLOC, _ZEPPO$MKB200: allocated  >> $ sho dev/ful tape  >>Q >> Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated, P >>     record-oriented device, file-oriented device, available to cluster, errorQ >>     logging is enabled, controller supports compaction (compaction  disabled).  >> >> >> $ mount/for tape 5 >> %MOUNT-I-MOUNTED, DLTEST mounted on _ZEPPO$MKB200:  >> $ sho dev/ful tape  >>Q >> Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated, R >>     mounted foreign, record-oriented device, file-oriented device, available toH >>     cluster, error logging is enabled, controller supports compaction >>     (compaction  disabled). >> ---> ^^^^^^^^^^^^^^^^^^^^ >  >Noted.  >  >[...] >>H >> $ backup/rewind/lab=dltest/media=compact home:login.com tape:save.one >> $ sho dev/ful tape  > E >There was no message about mounting and tape labels after the BACKUP 
 >command?   L No, because the tape was already mounted.  As mentioned above, I don't thinkN backup does a formal dismount/init/remount with /rewind and an already mounted tape.   = >I'll check it tomorrow when I'm back at work what my systems C >do. I can't check it now. Even so, you can't INIT a MOUNTed tape.    I Not with sys$init_vol, but you can do it manually with low-level QIOs, as  described above.   >So if@ >BACKUP is initing the tape when /rewind is specified, it has toC >dismount it first. Then of course it has to "re-mount" it after it  >inits it.    * No and no, it doesn't have to.  See above.  > >If you look at it this way -- and I do -- what I wrote beforeG >is right. Besides, you can change the label with BACKUP ... /REWIND so ) >doesn't a new label require a new MOUNT?   I See description of manual low-level initialization of tapes above.  After O manually initializing the tape, one only has to set the position to BOT and the J tape is mounted.  Well, I suppose you need to move the label name into theO volume control block so that it shows up in sho dev, but that's no big deal for   a low level utility like backup.   >  >>Q >> Magtape ZEPPO$MKB200:, device type DEC DLT2000 15/30 GB, is online, allocated, R >>     mounted foreign, record-oriented device, file-oriented device, available toH >>     cluster, error logging is enabled, controller supports compaction >>     (compaction enabled). >> ---> ^^^^^^^^^^^^^^^^^^^^ > 2 >Noted. But same comment as I opened with applies. >  >[...] >>P >> When you do a /rewind, backup has to write a new label to the tape.  Since itR >> is starting at the very beginning, including the headers, there is no reason itP >> can't turn compaction on or off according to its own media qualifier, even if >> the mount didn't specify it.  > 7 >IIRC, this involves a "re-mount". I'll check tomorrow.  >  >>4 >> Backup with /norewind is a whole different story. >>R >> If you do /norewind, you are appending to the end of an existing tape.  If dataO >> is already on the tape (EOT is not the same position as BOT), you can't make R >> any changes to compaction, on or off, with most current tape drives.  They willL >> not let you make compaction/density changes in the middle of the tape.  IO >> believe some very old tape drives could do this, but whether any of them are  >> still running is unknown. >  > H >Hmmm. Mine seem to do that. That is, if I take a tape, write a save set" >on it without /media=compaction,   P A better test would be an explicit /media=nocompact if you want to turn it off. H I have seen that compaction status is sometimes "sticky".  If you didn'tN explictly turn it off, it may have been already been compacted from an earlier job.   >dismount it, re-mount it withG >/med=compact, then append a second save set, it compacts! I'll have to D >do a more careful test when time allows by actually timing the saveC >operation on a quiet system to see if the drive is lying about its  >compaction state.  N I would also check the compaction light on the drive, if it has one.  Mine wasI lit, indicating that the drive itself agreed with the status in show dev.    >  > O >> You can see this in help mount/media: "Note that for compacting tape drives, Q >> once data compaction or noncompaction has been selected for a given tape, that K >> status applies to the entire tape."  There is similar text for /density.  >  > E >This is wrong unless the system is lying about whether compaction is ; >enabled. Again, I'll recheck tomorrow or when time allows.  >   N I reran my test with a second backup that was /norewind/nocompact.  Compaction remained enabled. O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------    Date: 14 Aug 2005 11:26:45 -07005 From: "robert_kersey@bat.com" <robert_kersey@bat.com> J Subject: Re: HP0-436 OpenVMS V7 Network Administration Exam / Study GuidesC Message-ID: <1124044005.213587.195960@g44g2000cwa.googlegroups.com>    Did,  F TFT. I wouldn't really call this a "Student Guide" though more a "User Guide".   A Yes for sure this would give a good grounding into the how to Use C TCP/IP services but would be expecting something with a little more ' 'meat on the bone' for a student guide.   F I have gone through the EPG that is available for the HP0-436 exam andD downloaded all the manuals that HP recommend for this exam. I am nowG working through them making notes on all the relevant chapters that the  EPG specifies.  F I was hoping someone out there may have a copy of the student guide asF this would make my revision process a lot simpler(no need to re-invent the wheel).    TIA.   Rob    ------------------------------  % Date: Mon, 15 Aug 2005 01:15:23 -0400 0 From: Peter Sjoberg <peters38@techwiz.spamno.ca>  Subject: Re: Image restore fails> Message-ID: <pan.2005.08.15.05.15.21.348418@techwiz.spamno.ca>  ; On Fri, 12 Aug 2005 22:25:14 -0500, David J Dachtera wrote:    > Peter Sjoberg wrote:	 >> [snip] M >> The system I'm trying to restore is VMS 6.x while the lab system I'm doing G >> it on is 7.3-1. I dn't have a VMS 6 cd anywhere here but on the real + >> system it was used with the same result.  >  > AH! That explains a lot! > J > There is a significant change in BACKUP between V6.2 and V7.x that gives > rise to this issue.  > H > If you have a V6.2 CD, boot it up and try the restore again. Should do	 > better.  I seen that,B http://www3.sympatico.ca/n.rieck/docs/openvms_72_backup_bug.htm is3 basically what I see but in my case it's all Alpha. I The hw that has the problem is an AlphaServer 1000A which require 6.2-1H3 I or later. We could not find a cd with that version and booted up on a 7.2 C cd (Tried a 6.2 but it failed) and done some of the tests from 7.2.   D In my lab I have a DS20 that I started to test on and that of courseJ requires something higher then 6.x to boot but I was thinking that I could! at least restore the system here.   H What I seen after reading multimeg logfiles from backup/list/full etc is: that some importent stuff is missing. It lists things likeJ [sys0.syscommon]systest.dir but no where does it list [sys0]syscommon.dir.I It lists []vms$common.dir with a fid of (15,1,0) bit later when I look on H the disk it's gone. Many fo the FID for files inder [sys0.syscommon] areJ the same as the onces listed under [vms$common] (as it should) but without? a syscommon.dir or vms$common.dir they have no where to belong.   < I done restores with both /Alias and /NoAlias with no change  < After a ana/disk/rep a pile of files in [SYSLOST] comes from [sys0.syscommon].   G I did rename syslost.dir to vms$common.dir, fixed up the alias, another G ana/disk/rep to fix some broken backlinks and think I got a system that I may be able to boot (can't test it in the lab, 6.2 won't boot on a DS20). 3 At least I have lots of files like sysuaf.dat etc.  I I don't have any onsite support until Wednesday but then it's time to try 	 it again.    ------------------------------  % Date: Sun, 14 Aug 2005 16:42:16 -0400 - From: "John E. Malmberg" <wb8tyw@qsl.network> % Subject: Re: LD  (WAS: SAMBA for VMS) F Message-ID: <bZGdnZ2dnZ2PXn-KnZ2dnTExYt-dnZ2dRVn-0p2dnZ0@adelphia.com>   David J Dachtera wrote:  > F > As John M. goes on to say, later versions of the freeware LD supportJ > large container files (>4GB). LD V6.x is probably still usable with that > limitation in mind.    This John M. did not say that.  C Please upgrade to the current version of LD if you are making dual  A format devices, or copying the container file to other locations.   H The older versions do not mark the container file to be non-cached, and H that can result in data corruption if the container file is manipulated 2 by other than the LD command or as a mounted disk.  . This is documented in the 7.3-2 release notes.   -John  wb8tyw@qsl.net Personal Opinion Only    ------------------------------  % Date: Mon, 15 Aug 2005 03:53:04 +0800  From: prep@prep.synonet.com  Subject: Re: Moving System Disk - Message-ID: <87ll34b8in.fsf@prep.synonet.com>   " njklostermann@cbegroup.com writes:  B > We are moving from an ES40 with a local system disk and many SAND > attached disks to a GS80 with a local system disk that will attachA > to the same SAN disks the ES40 currently attaches to, after the @ > migration.  Both are running VMS 7.3-2.  What is the preferredB > method of migrating the system disk to the new server?  Should IF > create an image of the ES40 system disk and simply restore it to theF > GS80 disk?  What is the best method of doing this considering I have > intermediate VMS skills?  * My thoughts, having read the follow-ups...  @ Create a SAN volume and mirror it with the current systems disk.A Create another root for the GS80 to play in, yes, we are going to F cluster them for the change over. Get a cluster PAK and the like.  Pop> you new SAN copy out of the shadow set, and BACK/IM to another' drive. Lets clean up while we are here.   D Write lock your first copy, and boot off the new copy, watch autogenE do its thing. Go over everything on the new system, while the ES40 is F still running your production stuff. When ready switch to the GS80 for> `real work' and then re-boot the ES40 from the new disk on theE SAN. BTW, no changes on the ES40 system disk once you clone it unless ! they can be moved to the new one!   C If you find a problem, you have the ES40 untouched just a boot away D with the old disk as an out, the original clone you made for backup.  @ Use your change over time to make sure you have licence PAKS etc that you need.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 14 Aug 2005 18:01:49 -0700! From: susan_skonetski@hotmail.com  Subject: my 2 cents C Message-ID: <1124067709.769056.148780@f14g2000cwb.googlegroups.com>   C I am not replying directly to Keith but to this note in general.  I G normally do not respond to notes regarding senior management because of ; flames I normally get, but I feel compelled to respond now.   C I have had some small dealings with Mark Hurd, very small, I do not A know him personally, so everything I am saying is from electronic  knowledge only.    My feelings only  < He cares more about customers than Hollywood and I like thatC He reads his mail, I know I sent mail and he answered it and I like  thatC We have had Internal briefings and I read the note, and I have been C impressed when he refused to give a response saying he needed to do ; more research rather than give a BS answer and I like that.  He says thank you.  G I am more concerned that people that are not customers may have tainted E the water where VMS is concerned.  For example if folks have sent him E mail ranting about VMS, why has he not done this or that just to find F out that they are not even purchasing customers.  He is a numbers guy,/ you need to be willing to include your numbers.   F Let me give you a real example. (Before you read this example rememberE this is not Call Center type with software or hardware that needed to F be fixed that is a different issues.)  Someone sends Carly a letter, aE very "enthusiastic" VMS letter.  This letter has several well written ? points in it, unfortunately these good points are surrounded by G paragraphs of rants of how VMS has been mistreated as an orphaned child ? for the last decade.  And that essentially the companies senior F management is imbeciles / morons, with the IQ of ice cubes and a wasteF of skin (I can't remember exactly so I am making the wording up).   WeF meaning me eventually get the letter asking to find out who the personC is so we can respond.  It is my sincere hope that this letter never & made it to Carly, for several reasons.= 1. The note saying "we get these all the time" attached to it G 2. The fact that it came from a person that was not a customer, and not F a business partner, so they were hurting VMS and the fact was they did not own VMS G 3. I did not know them (not that I know all our customers, but I know a  lot of the hobbyist as well). G 4. They made us all sound like a bunch of whiners because they used the  words us, and we  B Not being a senior manager myself, I tried to think how they think1 about the VMS community.  What is our reputation?   E You tell me, as a VMS community and as a newsgroup what do you think? > When a VMS person goes to stand up in front of a microphone atF Encompass/TECH Forum is the speaker happy to get the question? All theE speakers I know don't mind hard questions, in fact they like them. As C long as they are in their scope of responsibility they are happy to D answer them. However, they do mind questions where the person askingF the question is trying to show off, self promote or embarrass them, orB they can't figure out what the question actually is.  Or you ask a Marketing guy about the XFC.  E Ok I think I have given this newsgroup enough to chat about for a few 	 days now.    ------------------------------    Date: 14 Aug 2005 20:15:46 -0700$ From: "AEF" <spamsink2001@yahoo.com> Subject: Re: my 2 cents B Message-ID: <1124075746.204136.19630@z14g2000cwz.googlegroups.com>  " susan_skonetski@hotmail.com wrote: [...]  > I > I am more concerned that people that are not customers may have tainted G > the water where VMS is concerned.  For example if folks have sent him G > mail ranting about VMS, why has he not done this or that just to find H > out that they are not even purchasing customers.  He is a numbers guy,1 > you need to be willing to include your numbers.  > H > Let me give you a real example. (Before you read this example rememberG > this is not Call Center type with software or hardware that needed to H > be fixed that is a different issues.)  Someone sends Carly a letter, aG > very "enthusiastic" VMS letter.  This letter has several well written A > points in it, unfortunately these good points are surrounded by I > paragraphs of rants of how VMS has been mistreated as an orphaned child A > for the last decade.  And that essentially the companies senior H > management is imbeciles / morons, with the IQ of ice cubes and a wasteH > of skin (I can't remember exactly so I am making the wording up).   WeH > meaning me eventually get the letter asking to find out who the personE > is so we can respond.  It is my sincere hope that this letter never ( > made it to Carly, for several reasons.? > 1. The note saying "we get these all the time" attached to it I > 2. The fact that it came from a person that was not a customer, and not H > a business partner, so they were hurting VMS and the fact was they did
 > not own VMS I > 3. I did not know them (not that I know all our customers, but I know a  > lot of the hobbyist as well). I > 4. They made us all sound like a bunch of whiners because they used the  > words us, and we > D > Not being a senior manager myself, I tried to think how they think3 > about the VMS community.  What is our reputation?  > G > You tell me, as a VMS community and as a newsgroup what do you think?     D Sue, I think you are right on target. I myself tried to make similarF points about writing HP/Compaq. A whining, insulting letter will neverE do any good. It must be to-the-point, polite, and respectful. One can @ say we are disappointed about the lack of attention given to VMS4 without whining and insulting and similar bad karma.  C I'd like to add that it is good to explain how HP will benefit from & giving more positive attention to VMS.  , Thank you for this post! I am with you 100%!  @ > When a VMS person goes to stand up in front of a microphone atH > Encompass/TECH Forum is the speaker happy to get the question? All theG > speakers I know don't mind hard questions, in fact they like them. As E > long as they are in their scope of responsibility they are happy to F > answer them. However, they do mind questions where the person askingH > the question is trying to show off, self promote or embarrass them, orD > they can't figure out what the question actually is.  Or you ask a > Marketing guy about the XFC.   Good point.    > G > Ok I think I have given this newsgroup enough to chat about for a few  > days now.    How true. Thank you Sue!   ------------------------------    Date: 14 Aug 2005 20:28:05 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: SAMBA for VMS, Message-ID: <42ffa955$1@news.langstoeger.at>  a In article <EbSdnUkGy-w70mLfRVn-3w@adelphia.com>, "John E. Malmberg" <wb8tyw@qsl.network> writes: ! >Peter 'EPLAN' LANGSTOEGER wrote: Q >> in article <opsvga4qq7zgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:  >>   >> Please, don't. D >> Don't install such an old package on a modern version of OpenVMS. > I >For 7.3-2 and earlier you will want to use LD 7.1 from the Freeware 7.0  H >CD-ROM.  See the OpenVMS 7.3-2 release notes for a work around that is I >needed if for some types of operations using the logical disk container   >file.  C Strange, as Freeware V6 already contained a LD 7.31 (for VMS 7.3-1)   K >> OTOH, I don't understand why I still need to install (but only once - an M >> VMS upgrade doesn't kill the DCLTABLES) the LD freeware package to get the + >> rest of the LD functionality (like HELP)  > ( >That issue is being corrected post 8.2.  ' Which we expected for V7.3-2 already...    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 14 Aug 2005 20:29:55 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: SAMBA for VMS, Message-ID: <42ffa9c3$1@news.langstoeger.at>  c In article <S$w4BegPtECc@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: N >> Look for VMS freeware LD V8 to get the .ZIP file with the .HLB and the .CLD > H >So even given the freeware, it is not sufficient to install the command% >file, you also need to install ZIP ?   ) No, my fault. LD V8 is already a PCSI kit    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sun, 14 Aug 2005 15:25:43 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com> Subject: Re: SAMBA for VMS. Message-ID: <42FF6277.23976.490E24C@localhost>  0 On 13 Aug 2005 at 23:17, David J Dachtera wrote:E > Having been unsupported freeware for some years now, LD is about to  > become supported!   D Before it becomes supported, can the device type be changed so that C the virtual disks come up as "D" something?  To see the disks on a  @ system, I do a "SHOW DEVICE D", and this command will miss them  all...  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------- Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363 3 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com) "OpenVMS, when downtime is not an option"    ------------------------------  % Date: Sun, 14 Aug 2005 20:53:17 +0100 6 From: "Alex Daniels" <AlexNoSpamDaniels@themail.co.uk> Subject: Re: SAMBA for VMS6 Message-ID: <42ffa12e$0$17950$db0fefd9@news.zen.co.uk>  > "Stanley F. Quayle" <squayle@insight.rr.com> wrote in message ( news:42FF6277.23976.490E24C@localhost...E > Before it becomes supported, can the device type be changed so that D > the virtual disks come up as "D" something?  To see the disks on aA > system, I do a "SHOW DEVICE D", and this command will miss them  > all... >   I You already will miss some disks, not all current "disks" start with 'D'.   G Specifically DECram (which is in V8.2 and above is a System Integrated   Product) disks.    $ sh dev md   M Device                  Device           Error    Volume         Free  Trans   Mnt M  Name                   Status           Count     Label        Blocks Count   Cnt H $1$MDA1:       (XXXXXX)  Mounted              0  RAM              45992  1   1    Alex     ------------------------------    Date: 14 Aug 2005 21:53:50 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: SAMBA for VMS, Message-ID: <42ffbd6e$1@news.langstoeger.at>  c In article <42FF6277.23976.490E24C@localhost>, "Stanley F. Quayle" <squayle@insight.rr.com> writes: 1 >On 13 Aug 2005 at 23:17, David J Dachtera wrote: F >> Having been unsupported freeware for some years now, LD is about to >> become supported!   > E >Before it becomes supported, can the device type be changed so that  D >the virtual disks come up as "D" something?  To see the disks on a A >system, I do a "SHOW DEVICE D", and this command will miss them   >all...   I Many months ago I requested (at Guy P.) a SHOW DEVICE/CLASS=DISK (and for M consistency also a SHOW DEVICE/TYPE=mumble) to solve exactly this problem ;-)    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  + Date: Sun, 14 Aug 2005 22:30:19 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda) Subject: Re: SAMBA for VMS2 Message-ID: <05081422301926_20200296@antinode.org>  - From: Kilgallen@SpamCop.net (Larry Kilgallen)   I > So even given the freeware, it is not sufficient to install the command & > file, you also need to install ZIP ? >  > ============ > G > People should understand that not everybody is allow to use Freeware.   *    I understand it, but it's not my fault.  E    In the case of [Un]Zip, if anyone would like to cross my palm with F silver for a non-free copy of the Info-ZIP software (with no liabilityH attaching to me), please get in touch.  Of course, it'll look remarkablyD like the free version, except for the price.  For enough silver, I'dF even put it onto a CD-R to avoid the hazards of downloading (non-)free	 software.   H    Those with suspicious minds may wish to check the restrictions in the: LICENSE file which is included in the (free) product kits.  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------   End of INFO-VAX 2005.453 ************************