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.
Usage:
VERS_MAN install_type production_area [production_area2] [(opt]
- where
- install_type = {Major, Minor, Copy}
- production_area = {Prod, Prod1, Prod2}
- opt = {Ripple}
VERS_MAN ? will give you help.
Definitions:
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.
Notes:
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.
The current usage for major releases involves the user performing two steps:
- perform the major release. By default, no ripple is done.
- copy the now current prod release to the frozen disk of your choice.
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:
- VGetDisk Exec: Stacks requested information from the PROD_DISKS
table in the order specified on the call for a given
production area.
- VGetVers Exec Stacks requested information from the PROD_DISKS
table in the order specified on the call for a given (Major,
Minor) version.
- VComArch Exec: Inserts a given comment into the DB
- VGetArch Exec: Stacks requested information from the PROD_ARCH
table in the order specified on the call for a given (Major,
Minor) version.
- VModDisk Exec: Update the PROD_DISKS table with new version
information for a specified area.
- VNewArch Exec: Create a new entry in the PROD_ARCH table for a
new code version.
- VArchPrd Exec: Submitted to batch. Copy a production area to a
specified tape using DSKDMP utility. Will wait (using
WAKEUP utility) for VERSION INFO file to arrive in
production area before copy is initiated.
- VCopyPrd Exec: Submitted to batch. Retrieve an archived production
version from tape and copy it to a selected production
disk area using DSKLOAD utility, or copy from disk to
disk directly if the 'tape' name actually refers to a disk.
- VArchPrd.Com: Submitted to VMS batch via RSHELL. Uses VMS
Backup to archive production area to tape. Will wait
(using WAIT utility) until VERSION.INFO file arrives in
the production area before the copy is initiated. The
tape is relabelled as a VAX tape.
- VRipPrd.Com: Submitted to VMS batch via RSHELL. Restore an
archive tape to disk production area or copy disk to
disk directly.
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.
SLDPM.PROD_DISKS:
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)
SLDPM.PROD_ARCH:
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:
- disable DUCS
- copy the PROD area to the specified production area directly (disk to
disk)
- update PROD_DISKS table for the newly overwritten area.
For Major release:
- increment major release for new PROD. Write new PROD
information to a flat file and TODUCS it to PROD area.
- disable DUCS
- For each O/S set of production areas:
- get a tape
- use NEWCOM to tag the tape's use
- copy the PROD disk area to tape(*)
- retrieve the previous PROD archive and copy it to
- if the Ripple option was given, copy an archived version
of the PROD area to the PROD2 area(*)
- if Ripple, swap the PROD1 and PROD2 names in PROD_DISKS(*).
- create a new entry in PROD_ARCH for the new PROD version
- modify the PROD_DISKS entries to reflect the new PROD version
and rippling of the old version(*).
(*) 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:
- increment minor release for selected production area. Write new
production information to a flat file and TODUCS it to production
area.
- disable DUCS
- For each set of production areas:
- get a tape
- use NEWCOM to tag the tape's use
- copy the production disk area to tape
- create a new entry in PROD_ARCH for the new production
version
- modify the PROD_DISKS entry to reflect the new production
version.
R.Dubois
1993 or 4