Status of Software Reuse 577

for some topic drift ... cp67-cms had an update command, it basically was used to merge an "update" deck with base software source and produce a temporary file that was then buttembled-compiled.

it was oriented towards 80 column "card" records and sequence numbers in cols. 73-80. The cp67-cms buttembler source had convention of ISEQ buttembler statement ... to indicate that the sequences in the sequence number field should be checked (from physical card deck days when decks could be dropped and shuffled).

the control commands were of the form

.i nnnnnn (insert new source after record nnnnn

it started out essentially being a single change file application

as an undergraduate ... i was making enormous amount of source code changes to cp67 and cms ... and the default process required you to manually type-in the sequence number field (cols. 73-80) for all new source records.

I got tired of this and created an update preprocessor that supported "$" for replace & insert commands

where it would generate a temporary update file (for feeding into the update command) that had the sequence number field automatically generated. It could default to choosing number & increment based on previous-following cards ... or you could specify a starting number and any increments.

i believe it was the virtual 370 project that really kicked off the multi-level update effort. The "H" modifications to cp67 running on real 360-67 that supported virtual 370 machines ... which had some number of new-different control operations and instructions. The "I" modifications were applied after the "H" modificationa and product a cp67 kernel that ran on (real) 370 architecture (rather than real 360-67 hardware).

this was a set of execs (command processor file) that used a "cntl" file to select updates and their sequence for applying incrementally a hierarchical set of update files. This would iteratively processe "$" update files ... generating temporary update file and applying the temporary update file to the source file ... creating a temporary source file. The first iteration involved updated the base source file ... additional iterations wuould update the previously generated temporary update file.

I had replicated archived a H-I system (all the source and all the processes and files needed to generate running systems) on multiple tapes. Unfornately the datacenter i was using in the mid-80s had an internal operational problem ... where they had a rash of operators mouting valid tapes for scratch tapes and destorying data. The H-I archives tapes were wiped out in this period.

As a small reprieve ... not too long earlier ... Melinda

was looking for early examples of the multi-level source update process. i managed to pull a comple package (execs, control files, executables, etc) from the h-i archive tapes (prior to their getting wiped).

In the early time-frame, an MIT student (that has since become quite well known for work he has since done on the internet) was giving task for an application that would attempt to merge multiple independent update hiererachies. This is sort of software re-use ... in the sense that the same common source was used possibly by different organizations for developing different target solutions.

As the use of the multi-level update feature became wider used ... the "$' preprocessing support and the iterative application was merged into the base update command. Now rather than creating multiple iterative temporary files ... it would manage everything in memory, applying things as it went along ... and not producing a temporary source file until after the last update had been applied.

misc. past posts about the cp67 h-i operating system work

a fiew past posts on cms source update

--