VERS_MAN: Tracking Code Version Releases

Warning: This Document is Out of Date

The version management system described below was never fully implemented and is now out of date. It is the intention of the Offline Software Group to write an improved, Unix-based version, but no such version is yet ready. For instructions on how to make code version releases in the meanwhile, see The Practical Guide to Version Management.

Brief Description:

This utility tracks the code versions on each of SLD's production code areas (three each on VM, VAX and Alpha). New versions are rippled through the disk areas and are archived to tape. The locations of all versions (disk and tape) are tracked in Oracle. VERS_MAN is executed on VM. All execs and com files live in DUCSUTIL.


VERS_MAN install_type production_area [production_area2] [(opt]
install_type = {Major, Minor, Copy}
production_area = {Prod, Prod1, Prod2}
opt = {Ripple}
VERS_MAN ? will give you help.


Major release: code modifications are made to the current PROD disk area, with the previous version of current PROD rippled into the other production areas. The new version is archived to tape. If the Ripple option is given, then a ripple is done.

Minor release: code modifications are made to any of the three production disk areas. The new version is archived to tape. No other action taken.

Copy: copy a production disk to another production disk. This can be done before the new production release is started.

production_area: there are five disk areas on each operating system storing versions of the production code. The code versions will occupy the PROD, PROD1, PROD2, FROZEN1 and FROZEN2 areas. The VGETVERS EXEC on VM or the GETVERS command on the VAX will connect a code version to a disk area.


VERS_MAN does not currently have any automated means of checking that the submitted batch jobs completed successfully.

VERS_MAN queries the console for verfification that DUCS has installed the file describing the code version, and to ask for a comment about it. If VERS_MAN is being run from a disconnected process, these responses will have to be stacked.

Reference Guide:

VERS_MAN EXEC is a VM Rexx exec making use of Pro*Rexx to interface to Oracle to track code versions on disk and tape. Batch jobs are submitted to each system (directly to VM and via RSHELL to VMS) to archive new versions and to restore archived versions to disk during a ripple.

As a temporary measure, while directories are still being set up on the Alpha, VERS_MAN will look for a disk name of NONE as a special keyword to tell it that that operating system isn't ready yet. The tables also contain entries as to whether the disk areas are locked, in case we want to freeze one.

A filelist of the VM files on the newly archived production area is sent to SLDPM for storage. A log of the VMS Backup is stored in $USR:[DUCS.LOG] directtory. These archival files both have their filename containing the code version.

Internal Utility Exec and Com files:

Oracle Table Definition:

Two tables are used to track the code versions on tape and disk, SLDPM.PROD_DISKS and SLDPM.PROD_ARCH; PROD_DISKS tracks the contents of the disk areas while PROD_ARCH tracks the tape archives.


Major_Version      Not Null       NUM(3)
Minor_Version      Not Null       NUM(3)
Prod_Area          Not Null       CHAR(16)
VM_Disk_Name       Not Null       CHAR(32)
VMS_Disk_Name      Not Null       CHAR(32)
Alpha_Disk_Name    Not Null       CHAR(32)
Release_Date       Not Null       DATE
VMWrite                           CHAR(1)
VMSWrite                          CHAR(1)
AlphaWrite                        CHAR(1)


Major_Version      Not Null       NUM(3)
Minor_Version      Not Null       NUM(3)
Release_Date       Not Null       DATE
Comments                          CHAR(150)
VMS_Volser         Not Null       CHAR(8)
VMS_tape_DSN       Not Null       CHAR(24)
VMS_file_num       Not Null       NUM(3)
VM_Volser          Not Null       CHAR(8)
VM_tape_DSN        Not Null       CHAR(24)
VM_file_num        Not Null       NUM(3)
Alpha_Volser       Not Null       CHAR(8)
Alpha_tape_DSN     Not Null       CHAR(24)
Alpha_file_num     Not Null       NUM(3)

Processing Flow:

Retrieve all production disk areas' information from PROD_DISKS and current PROD archive tape.

For Copy:

For Major release:

(*) Note: if a COPY has been done already such that the PROD version is already in two production areas, these steps are not performed.

For Minor release:

1993 or 4