KRAIG@BIOSTR.BIOSTR.WASHINGTON.EDU ("Kraig Eno, UW BioStructure") (06/22/88)
I posted a message about my BACKUP procedure terminating prematurely, and I appreciate all the replies I got -- the upshot being that any procedure without a $ SET NOON at the beginning will stop when an image exits with Error or Fatal status. I'm embarassed, I should have seen that myself. Kraig Eno Univ. of Washington BS department KRAIG@biostr.biostr.washington.edu
"Mike_F._England.ESCP8"@XEROX.COM (06/29/88)
>the upshot being that anyprocedure without >a $ SET NOON at the beginning will stop when an >image exits with Error or Fatal status I still think that there is a backup hiccup, NOT related to the ON ERROR type of stuff. My backup procedure did not complete last night. The (edited) log file is as follows: ---------- $! AUTOBACK Daily backup command file $ $ SET DEF DUA0:[ORALOAD.SYS] $ $ show status Status on 27-JUN-1988 23:00:02.39 Elapsed CPU : 0 00:00:01.44<CR><LF> $ .... (stuff removed) $ backup/log - dua0:[epbu]/exclude=(*.DAT,*.DMP,*.BCK),- dua0:[customer]/exclude=(*.DAT,*.DMP,*.BCK),- dua0:[oraload.sys...]/exclude=(*.DAT,*.DMP,*.BCK) - dua0:[oraload.sys]backup.bck/save/block=2048 %BACKUP-S-COPIED, copied DUA0:[EPBU]1.SQL;7 .... (stuff removed) %BACKUP-S-COPIED, copied DUA0:[ORALOAD.SYS]UVSTARTUP.COM;1 %BACKUP-S-COPIED, copied DUA0:[ORALOAD.SYS]WELCOME.TXT;2 SYSTEM job terminated at 27-JUN-1988 23:43:04.06 <CR><LF> Accounting information: Buffered I/O count: 1268 Peak working set size: 512 Direct I/O count: 7384 Peak page file size: 2709 Page faults: 224919 Mounted volumes: 0 Charged CPU time: 0 00:38:13.43 Elapsed time: 0 00:43:04.00 ---------- The only places I have removed lines are denoted by ... . The .COM files has the lines: ---------- .... (stuff removed) $ backup/log - dua0:[epbu]/exclude=(*.DAT,*.DMP,*.BCK),- dua0:[customer]/exclude=(*.DAT,*.DMP,*.BCK),- dua0:[oraload.sys...]/exclude=(*.DAT,*.DMP,*.BCK) - dua0:[oraload.sys]backup.bck/save/block=2048 $ $ RENAME DUA0:[ORALOAD.SYS]backup.bck 'DAY'.BCK $ .... (more commands) ---------- As you can see, DCL ignored the lines following the backup command (starting with rename). There were NO error messages of any kind. //michael (213) 333-6014
hobbit@topaz.rutgers.edu (*Hobbit*) (07/24/88)
Uh, could you be more specific? Where doesn't it calculate the file size, on a /list equivalent? Does it incorrectly restore large files to the disk? I just grabbed it and played with it myself, and "restored" a couple of smallish example files onto the unix box in question and it seems to work fine [thank clod; having to dump them out and transfer them from the only remaining vms machine here is a pain]. What exactly broke? Since it comes with source, everyone should be able to fix whatever's wrong with it [and determine the format of a backup set from it too]. Perhaps your tape was written with a weird blocksize [I routinely use something around 60000] and that's what got it confused? _H*
hydrovax@nmtsun.nmt.edu (M. Warner Losh) (07/26/88)
In article <Jul.24.02.17.46.1988.27940@topaz.rutgers.edu> hobbit@topaz.rutgers.edu (*Hobbit*) writes: >Uh, could you be more specific? OK, I will. Sorry for the confusion. >Where doesn't it calculate the file size, >on a /list equivalent? Does it incorrectly restore large files to the disk? It fails to calculate the size of the files for LARGE files. It does this both with the -t option in addition to the size on the disk. The file I'm attempting to use is 103776 blocks long, 34000 blocks long. >I just grabbed it and played with it myself, and "restored" a couple of >smallish example files onto the unix box in question and it seems to work >fine [thank clod; having to dump them out and transfer them from the only >remaining vms machine here is a pain]. What exactly broke? The program appears to work with smallish backup save-sets, although it occasionally complains about a bad record type after it extracts the last file. The problem is with retrieving a file that is 103776 blocks long (according to BACKUP on a VMS machine). vmsbackup (the program I'm using on a UNIX box) says the file is about 19,000,000 bytes long (that number should be somewhere nearer to 50,000,000 bytes). The tape was written with a block size of 8192 with VMS backup version 4.4 on a VMS V4.4 system. The group size is 10. It also spans tape, but that is another problem.... >Since it comes with source, everyone should be able to fix whatever's >wrong with it [and determine the format of a backup set from it too]. In a way you can. I fixed it so that it will handle files between 32000 and 65000 blocks. However, I can't figure out where to go from here since I don't have the EXACT format of the file headers. The comments in this section of the program are not to be found. Since there was some confusion, I'll ask some more specific questions: 1) How does BACKUP deal with files that are longer than 65000 blocks? The source to the program is less than enlightening. A complete description of the headers that are found on each file would help a whole lot. As would a paper listing of BACKUP from the fische :-) 2) How does BACKUP deal with End of Volume? From some of the stuff I've seen, it looks as if it places an EOV label at the end of the volume. Does it place ant "Trailers" in the BACKUP saveset itself? Currently, vmsbackup does not begin to handle this case. >_H* I'll post a summary and the fixes to the program if there is enough interest in such things.... Warner-- M. Warner Losh My spelling and views are my own, my employer dosen't know I can speak, so how can I speak for them? bitnet: warner@hydrovax.nmt.csnet csnet:warner@hydrovax.nmt.edu arpa: warner%hydrovax.nmt@relay.cs.net uucp: uunet!nmtsun!warner%hydrovax