Looking for some help-VMS Severs running Openvms V8.3-1H1

[Joseph Huber_1]

Ah sorry , for backup it is of course best to use /since=backup:

$ backup/record [...]/since=backup SYSTEMB::tmp.sav/save

In the backup case the result are backup save sets; You may want to have the savesets extracted to the target directory.
This can be done by another commnd-file, wich is submitted by the backup job:

$ submit/remote SYSTEMB::expand_backup.com

[Joseph Huber_1]

and finally, instead of SUBMIT/REMOTE, You can synchroneously execute the backup expansion job from inside the backup job by executing a DECnet task like:

$type/nopage SYSTEMB"user"::"0=expand_backup"

This methode requires to have the DECnet TASK object installed and enabled, or have expand_backup.com defined as a network object: ask Your system manager if this is possible/allowed.

[Joseph Huber_1]

and finally 2: since You said having no experience with DCL, and probably no system system manger to do it for YOU:
setting up DECnet access requires proper setup of FAL and TASK objects, and establishing proxies;
it might be easier to us TCPIP ssh,scp,sftp tools with public key authorization.

[The Gunners]

Joseph , all of your suggestions are a tremendous help. Thank you indeed. I will have a good think about this over the weekend and put something together for testing next week. I will update.

[Robert Gezelter]

The Gunners,

Caution is indeed recommended, it is easy to make a small error and incur spectacular consequences.

Some information about the size and makeup of files would be helpful.

In most cases, I would personally avoid doing a direct COPY over the network. Instead, I would use BACKUP to create a save set, then use ZIP to compress the same set, COPY/file transfer the resulting ZIP archive to the remote system, and then reverse the process.

A side effect of this process is the log (and contents) of what was propagated when, which is useful collateral when something goes awry, as it inevitably does.

This might not be the best beginners DCL/system management project, there are many ways things can go "off the rails". You may want experienced assistance/counsel [Disclosure: We provide services in this area, as do several other regular contributors to this forum.]

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

I would not recommend using zip on a BACKUP as the basis for a file transfer operation.

This particular sequence defeats some of the efficacy of zip compression, and it also doesn't particularly improve the outcome of the whole operation, and it means you can't get at the files from a box that doesn't have BACKUP, and you have an extra step. (It also means that search engines such as Google can't index the zip archive contents, which is helpful if you're planning on posting zipped copies of open source somewhere, too.)

Just use zip (with the "-V" switch) the files directly, and you'll have the same (or better) results, and without the extra step of the BACKUP command.

The basic zip command is:

zip "-V" ziparchive files

Yes, the "-V" is quoted. Really.

And yes, the quoting of that -V switch is not necessary when RMS extended parsing is enabled, but if you know what ODS-5 with extended parsing means, then you probably recognize the quoting and you thus won't need to read this particular quoting advice.

And if you're going to be using zip (at all, even if you are wrapping a BACKUP saveset, as Bob suggests), then use at least the zip 3.0 and unzop 6.0 tool versions, as these versions deal correctly with multi-gigabyte files. The zip and unzip versions available from the HP site are old, and, well, they won't.

There's an introduction to zip and unzip on VMS here:

http://labs.hoffmanlabs.com/node/575

There are current versions of zip and unzip available at the VMS Resource Center link available at the Process Software site, among other places (other than HP, that is) around the Internet. http://www.process.com

[Hoff]

ps: zip "-V" is goodness if you NEED to toss around a BACKUP saveset. That step avoids getting the saveset RMS attributes corrupted. But I would not start out with that model and that extra step, particularly if you're controlling the full sequence.

[Joseph Huber_1]

A note to the copy or backup selection /SINCE= qualifier:
while a fixed /SINCE="''f$time()'-4" for "since the last 4 hours"
is not precise or may fail to select the correct files,
because the job scheduling is delayed,
but
BACKUP/RECORD *.*/SINCE=BACKUP may conflict with a regular
incremental backup of the same files, overriding the incremental backup time,
the following method I use for daily disk to disk backup between weekly backups:

Have a marker file, say SNAPSHOT.DAT.
use the revision date of this file for defining the update period.
At the beginning of the snapshot copy do

last = f$file("SNAPSHOT.DAT","RDT")
set file/protection=W:R SNAPSHOT.DAT !update to current time
backup [...]*.*/since="''last'" ... !no /RECORD !

This way the backup covers all files since the last run.