topic Re: BACKUP /PROGRESS in Operating System - OpenVMS

BACKUP /PROGRESS

Sean OBanion — Thu, 25 Aug 2011 14:23:44 GMT

First time I've used the /PROGRESS qualifier, OpenVMS Alpha 8.3, unknown patch level.

And first post in the new community...

I'm performing a copy operation on a single large file, about 20MBlocks. I was hoping that /PROGRESS would say how much IO had been moved, and a rough guess about the % completed, but I'm not getting anything useful though the copy is completed. The documentation gives the example:

"%BACKUP-I-PROGRESS, progress report generated at 18-JAN-2006 18:07:55.08
Restoring file: DKA100:[KITS.CDSA]HP-I64VMS-CDSA-T0202-134-1.PCSI$COMPRESSED;1
Saveset volume:1, saveset block:1705 (32256 byte blocks)
52.44MB restored out of 1.23GB, 4% completed
Restore rate: 895KB/sec, estimated completion time: 18:30:59.10 "

With /PROGRESS=30, I do get some output:

"%BACKUP-I-PROGRESS, progress report generated at 24-AUG-2011 16:02:36.55 Last file scanned: DISK:[DATA]PRICES.DAT;1

Saveset volume:0, saveset block:0 (33040 byte blocks) 0KB saved, save rate: 0KB/sec

%BACKUP-I-PROGRESS, progress report generated at 24-AUG-2011 16:06:46.57 Last file scanned: DISK:[DATA]PRICES.DAT;1

Saveset volume:0, saveset block:0 (33040 byte blocks) 0KB saved, save rate: 0KB/sec"

Is the expectation a backup or restore, so copy doesn't do anything, or is it that there is only one file involved?

Sean

Re: BACKUP /PROGRESS

Steven Schweda — Thu, 25 Aug 2011 20:13:12 GMT

Re: BACKUP /PROGRESS

John Gillings — Fri, 26 Aug 2011 00:21:28 GMT

Sean,

I'm not sure why you're not seeing numbers. I get stuff like this, even for a single file (OpenVMS/Alpha V8.4), as pasted below. I haven't tried a restore, but since the example in the Utilities Reference Manual is a restore, I'd expect it to work.

$ backup/progress=5 SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP/IGNORE=NOBACKUP nl:x.sav/save
%BACKUP-I-PROGRESS, progress report generated at 26-AUG-2011 10:01:36.34
 Last file scanned: $1$DGA7130:[SYS0.][SYSEXE]SYSDUMP.DMP;1
 Saveset volume:1, saveset block:6047 (32256 byte blocks)
 186.01MB saved, save rate: 37.17MB/sec
%BACKUP-I-PROGRESS, progress report generated at 26-AUG-2011 10:01:41.34
 Last file scanned: $1$DGA7130:[SYS0.][SYSEXE]SYSDUMP.DMP;1
 Saveset volume:1, saveset block:12085 (32256 byte blocks)
 371.75MB saved, save rate: 37.13MB/sec
...
%BACKUP-I-PROGRESS, progress report generated at 26-AUG-2011 10:03:06.90
 Input file scan inactive.
 Output: Saveset volume: 1, saveset block 37209 (32256 byte blocks)
 1.11GB saved, save rate: 31.07MB/sec

> rough guess about the % completed

Seems reasonable, BUT, for a save operation, in order to work that out BACKUP has to first figure out the total space to be copied. That is potentially an expensive thing to do. At best it would require a pause at the beginning of the operation to scan all the files and add up the blocks. I know I don't like Windows spending lots of time "preparing to copy" if I drag and drop a large number of files (basically wasting time collecting the sizes so it can give me an inaccurate estimate of how long it will take, when I'd rather it just got on and did the copy).

Of course, you could use DIRECTORY/GRAND/SIZE=(ALL,UNITS=BYTE) on the same filespec as the BACKUP command to determine it yourself, then compare with the "saved" number.

For a RESTORE, the total size is known in advance, so the percentage and estimated completion times can be calculated. According to the example in the manual, they are:

$ BACKUP SAVESET.BCK/SAVESET DKA100:/IMAGE/PROGRESS_REPORT=60
  
%BACKUP-I-PROGRESS, progress report generated at 18-JAN-2006 18:07:55.08 
Restoring file: DKA100:[KITS.CDSA]HP-I64VMS-CDSA-T0202-134-1.PCSI$COMPRESSED;1 
Saveset volume:1, saveset block:1705 (32256 byte blocks) 
52.44MB restored out of 1.23GB, 4% completed 
Restore rate: 895KB/sec, estimated completion time: 18:30:59.10 
 
%BACKUP-I-PROGRESS, progress report generated at 18-JAN-2006 18:08:55.08 
Restoring file: DKA100:[KITS.DWMOTIF]HP-I64VMS-DWMOTIF-L0106--1.PCSI$COMPRESSED;1 
Saveset volume:1, saveset block:3547 (32256 byte blocks) 
109.11MB restored out of 1.23GB, 8% completed 
Restore rate: 967KB/sec, estimated completion time: 18:29:16.05

If the command is not behaving as documented, please document what you're doing, what you're seeing and what you expect then log a case with your local Customer Support Centre.

Re: BACKUP /PROGRESS

Sean OBanion — Fri, 16 Sep 2011 20:01:57 GMT

Looks like with just a sigle file copy operation, PROGRESS doesn't do much but give time stamps...

Thanks.

Re: BACKUP /PROGRESS

GuentherF — Sat, 17 Sep 2011 02:31:13 GMT

I doubt that the PROGRESS code in BACKUP was implemented to cover file copies as well. But...

A BACKUP file copy is a save operation from the input file to an in memory save set buffer and the the standard restore is called to write the file to the target. Nice design!

But in this case neither side is a save set and I assume that is what the progress code doesn't handle as expected.

/Guenther