At present, all of these disks are attached to SLDA6. Therefore, the submit statements in VERS_MAN EXEC N on VM contain the option "/char=SLDA6". If these disks are reshuffled, modify VERS_MAN EXEC N accordingly.
If a copy job fails due to lack of space, you then will need to edit VERS_MAN EXEC to create a special version that only launches those copy jobs that failed. It is easier to spend the time up front checking whether the required space is there.
Checking space on day is no guarentee that the space will still be there the next day. Run a final space check immediately before attempting to do the PROD copy.
To check the size of the current VMS DUCS:
SD $255$DUA0:[DUCS] DIR/SIZE/GRAND_TOTAL [...]*.* (for version 11.5, this measured 979K blocks) then subtract any code found in DIR/SIZE/GRAND_TOTAL [DUCS.UTIL.UVAXSRV.WORK...]*.* (for version 11.5, this measured 281K blocks) then also subtract 6K for some other miscellaneous code that is ommitted from the copy jobs. Last time, the result was that VMS DUCS required about 692K blocks.
To check the size of the current Alpha DUCS:
SD SLDA6$DKB300:[DUCS] DIR/SIZE/GRAND_TOTAL [...]*.* (for version 11.5, this measured 707K blocks) then subtract 6K for some other miscellaneous code that is ommitted from the copy jobs. Last time, the result was that Alpha DUCS required about 701K blocks.
To run the actual disk copy, from VM:
VERS_MAN COPY PROD prod_area where prod_area could be either PROD1, PROD2, FROZEN1, FROZEN2 or FROZEN3 and can be found on the Web in SLD Code Versions on Disk.
You may notice that trace is set to R in VCOPYPRD EXEC. Leave it this way. If trace is set off, this exec fails with RC -3. It's not worth trying to find out why.
It is rare that all three copies work correctly. If only one or two of them fail, edit VERS_MAN EXEC to skip the jobs that worked, then re-run it.
Update the VERSION INFO file in PROD to the next higher version number.
Update the version information in the Oracle SLDPM.PROD_DISKS table to show PROD as the next higher version number. Note that the new version will not show up in Disk Locations of Frozen Code Versions until the tape copy information has also been filled into Oracle (see below).
Use the special version of DSKDMP EXEC on PERL 191. It is a blend of the copies on RICHARD 191 and SLDPM 191, plus it allows for use of the new QK series tapes.
To run the actual tape copy, from VM:
VERS_MAN MINOR frozen_area where frozen_area could be either PROD1, PROD2, FROZEN1, FROZEN2 or FROZEN3.
If any of the copy jobs fail, do not simply repeat the above. That will cause yet another set of tapes to be reserved for the copy jobs, while the previous set will never be released for other uses. Instead, use some simpler execs to do the retry.
Two examples of such execs can be found on PERL 191.
VERS_MAN always fails to correctly update the PROD_ARCH table. Instead, use ORAARCH EXEC on PERL 191. Edit it by hand to contain the new information, then run it to insert that information into Oracle.