ALTMERGE - merge sets of GMAP alters.

This program performs a handy function (in a somewhat crude fashion). During the development of a program, it is desirable to apply alters only to the most recent version of the program. This approach eliminates the difficulty in determining the correct alter number in the base version, reshuffling the alter deck applying to it, and the difficulty involved in undoing previous alters.

This approach presents its own problems. Storage (somewhere) must be provided for the intermediate versions and careful track must be kept of them. In situations where a log of the changes must be kept, the programmer must then reconcile all the intermediate versions.

The ALTMERGE program takes care of that final reconciliation. In the process, it eliminates the need for storing intermediate program versions and provides an easy way to "back-up" to a previous version.

ALTMERGE reads a file consisting of alter-sets used to produce successive generations of the same program. Each alter-set produces the next version of the program from the current one. ALTMERGE resolves the conflicts between them and produces as output a single alter-set which will generate the most recent program version from the base. This means that one need never keep around intermediate program versions.

Consider the following example: suppose we have a program called "prog00" which we would like to update. We determine the changes necessary to do this and store them in a file called "alter00". Applying "alter00" to "prog00" gives another program; call it "prog01". If "alter00" was not quite sufficient to give the desired result, we might consider creating a new file of changes, "alter01". Applying it to "prog01" gives a new program, "prog02". We may iterate through this cycle until we have our desired result. However, we need never save source versions of "prog01", "prog02", "prog03", and so on; to create a new source version, we take the concatenation of "alter00", "alter01", "alter02", etc., and place our latest set of alters at the end. By running this file through ALTMERGE, we obtain an alter file that can be applied to the base. The listing we obtain is that of the new current version. Successive changes are written against this listing and concatenated on the end of the alter file.

"Backing-up" to a previous version is accomplished by deleting all the alter-sets from a specific location in the concatenated file on to the end.

Options:

Three options may be selected by setting of different bits in the program switch word.

bit 6: Turning this bit on causes the generated alter card set to be placed in file code "cp". If this bit is not set, the checking and merging will be done but no final merged file will be written.
bit 7: When this bit is set, the contents of "in" as well as the actions taken to generate the resulting alter file will be listed on file "lp". This feature is used in debugging and is not normally set by the average user.
bit 8: Normally, having an alter-set in which the $alter cards are not in ascending order is an error. When this bit is set, the error which would ordinarily appear is suppressed and the alter cards within each set are arranged into proper order. This is done by invoking GCOS sort/merge. In this case, file codes "s1" and "s2" must be specified. If this option is set but no alter-set is out of sequence, sort/merge will not be invoked.
bit 9: This bit is turned off at the beginning of the program. It will be turned on if any error conditions are detected during the running of the program. The status of this bit can then be used to determine future action of the job.

Files Used:

in: is the input file code. It contains all the sets of alters to be merged. Each alter set begins with a $update card and continues to the next $update card or the end-of-file. To be consistent with $update usage in the system, columns 73-80 of the $update card replace columns 73-80 of each card in a given set unless they are blank or zero. There must be at least one alter set.
f1, f2, f3: These file codes are temporary files used during the merge. Each file must be of sufficient size to contain the number of cards affected by all the $alter cards contained in "in".
lp: This is the line-printer file. It contains debugging trace information (if this was selected) and any error messages produced by the program. Normally, this file can be assigned to SYSOUT.
cp: This file is the resulting set of alters. If assigned to SYSOUT, the file will go to the card-punch. Output from this file may subsequently be given to a compiler in a following activity for use as a*.
s1, s2: These files are random files. They are used to sort the alter cards within each set (all at the same time) into ascending order by alter number. Normal cards following each $alter card are moved with the $alter. Sorting will only be done if necessary and if the sort option has been selected. If the sort option has not been selected and the alters in any set are not in ascending order, an error message will be printed. "s1" and "s2" should each be as large as "f1".

Example:

The following deck set-up is intended to give an idea of how to use ALTMERGE in connection with a subsequent assembly.

$   lowload
$   option  cobol
$   select  userid/obj  alter-merge object deck
$   execute dump
$   limits  25,13k,,20000
$   set     6   generate new alter set
$   set     8   sort sets into proper order
$   data    in,,copy

 <successive alter sets go here>

$   endcopy
$   file    f1,a1r,5l
$   file    f2,a2r,5l
$   file    f3,a3r,5l
$   sysout  lp
$   file    cp,a4s,5l
$   file    s1,a5r,5r
$   file    s2,a6r,5r
$   gmap    other options
$   prmfl   g*,r,s,userid/base-src
$   set     9   let gmap know about a*
$   file    a*,a4r,5l