The Practical Guide to Version Management

This document describes how to perform production code releases until such time as a more automated system becomes available. It supersedes information in the older document, VERS_MAN: Tracking Code Version Releases.

If the Disks are Moved to Different Hosts

The copy jobs require less network traffic and therefore run faster if they are performed on the hosts that are directly attached to the relevant disks. In fact, if they are performed on inappropriate hosts, they will probably consume so much extra time that the jobs will time out.

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.

Copying the Current PROD to a Frozen Disk

Before actually trying to do the copy, check that there is sufficient space for it. DUCS grows with each release, and no copy job has succeeded in years without first going through a struggle to reclaim some disk space.

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.

Do Not Forget the Remaining Three Steps

Re-enable DUCS (it was automatically disabled by VERS_MAN)

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).

Copying the Frozen Disk to Tape

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.

You will need to modify them to use the appropriate tape names, version numbers and frozen areas.

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.


Joseph Perl
4 October 1995