KRAIG@BIOSTR.BIOSTR.WASHINGTON.EDU ("Kraig Eno, UW BioStructure") (06/02/88)
Anyone know why BACKUP behaves this way? I have a command procedure (shown below) which stops just after the first BACKUP command...no error or anything, it just doesn't execute the following commands. If it's run batch, the job terminates at that point. This is under 4.7, but it did the same thing under 4.4. I've tried various things, but it doesn't even seem terribly consistent. $ set verify $ set process/name="FULL Backup" $ allocate MUA0: $ initialize MUA0: FULL $ mount/foreign MUA0: $ backup/image/record/ignore=interlock DUA0: MUA0:SYSTEM.BCK $ ! This is where it halts. $ backup/image/record/ignore=interlock DUA1: MUA0:USER1.BCK $ backup/image/record/ignore=interlock DUA2: MUA0:USER2.BCK $ dismount MUA0: $ deallocate MUA0:
helen@uhccux.uhcc.hawaii.edu (Helen Rapozo) (06/13/88)
In article <8806112307.AA20396@ucbvax.Berkeley.EDU> KRAIG@BIOSTR.BIOSTR.WASHINGTON.EDU ("Kraig Eno, UW BioStructure") writes: >Anyone know why BACKUP behaves this way? I have a command procedure (shown >below) which stops just after the first BACKUP command...no error or anything, >it just doesn't execute the following commands. If it's run batch, the job >terminates at that point. This is under 4.7, but it did the same thing under >4.4. I've tried various things, but it doesn't even seem terribly consistent. > >$ set verify >$ set process/name="FULL Backup" >$ allocate MUA0: >$ initialize MUA0: FULL >$ mount/foreign MUA0: >$ backup/image/record/ignore=interlock DUA0: MUA0:SYSTEM.BCK >$ ! This is where it halts. What kind of error messages are you getting? According to the VMS Manual (Version 4.4, page BACKUP-39), if you use /IMAGE you will need write access to the INDEXF.SYS and BITMAP.SYS for that volume. Also if you have TU81+ tape drives you will also need the PHY_IO privelege. I also understand you will need OPER and READALL priveleges to backup the entire drive. -- BITNET address: helen@uhccux UH Admin Network: HCCADA::CS_RAPOZO US Mail Address: 874 Dillingham Blvd., Honolulu, HI 96817, Ph# (808) 845-9202 PLATO address: helen rapozo/honcc/hawaii
MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (06/14/88)
> Date: Wednesday, June 1 at 12:47 pm pdt > From: Kraig Eno, UW BioStructure <KRAIG@BIOSTR.BIOSTR.WASHINGTON.EDU> > Subj: VMS BACKUP hiccups > > Anyone know why BACKUP behaves this way? I have a command procedure (shown > below) which stops just after the first BACKUP command...no error or anything, > it just doesn't execute the following commands. No errors at all? You're using /IGNORE=INTERLOCK for a reason; I imagine you get `file is open by another user' messages: as far as DCL is concerned, those are errors; depending upon the severity code set by BACKUP, they could be signalling DCL to terminate your procedure. If my guess is correct, then a SET NOON statement at the top of your code will cause DCL to bypass all error checking. Hope this helps! Ed
"Mike_F._England.ESCP8"@XEROX.COM (06/22/88)
I too have had a random problem with backup. In our application our VAX 11/750 backs up a set of files to a file service every evening at midnight. The VAX is running ORACLE in support of a software database, and there are no users on the system when the backup is run. What is suppose to happen is a set of VMS files are backed up to disk (into a single saveset) and then that saveset is shipped to the fileservice. Sometimes the backup does not complete correctly. When the log file is examined there are a series of BACKUP-S-COPIED messages followed by the accounting information. The statements in the DCL file following the backup command seem to be ignored. There are no error messages of any kind. It just seems like BACKUP "hiccups" and caused DCL to ignore the rest of the file. This happens about one time in 20 or 30. Ideas?? michael (213)333-6014