sorting 3902
cp67-cms had a source *update* appliatiion called *update* that used sequence numbers on card images (default field in cols 73-80)
it would take a combination of the original source and an *update* file and produce a temporary working file (for actual compilation-buttembly).
an update file statement was of the form:
input new set after card with particular sequence number: .I 828000
replace a card with one or more new cards .R 242000
replace starting card until ending card with one or more new cards .R 242000 245000
delete a card .D 242000
On Thu, 20 Jul 2006 11:42:51 -0600 in alt.folklore.computers, Anne & Using XEDIT and UPDATE with control files was almost as...
delete from start until end .D 242000 245000
it was dependent on all the card images in the input file have increasing sequence numbers in the sequence number field. originally it also required that new-replacement card images have the new sequence field numbers manually created.
when i was undergraduate, i was doing so many changes to cp67 kernel source that i got tired of manually producing the sequence numbers for the new-replacement statements ... so i wrote a utility that preprocessed update files and produced temporary output files for the cms *update* program.
my source update files had optional fields of the form:
No, it wasn't. The job was to keypunch the code the programmer needed yesterday. Are you really trying to tell somebody, who...
.I 828000 $ 828500 100
.R 242000 $ 2420500 100
where the preprocessing utility would take the "dollar" field and used that for generating sequence numbers on the new-replacement card images, as well as removing the dollar fields before pbutting the file to the standard update program.
later, at the science center
during the joint effort w-endicott to add 370 virtual machine support to cp67. a multi-level update procedure was created ... where a "control" file was defined that defined a search order for a series of possible update names to look for to be applied serially (before the buttembly). after the first update was applied and the temporary file was produced, successive updates would be applied to the previous output workfile (generating a new temporary output workfile which would be renamed to the standard output workfile name for subsequent processing).
inserted Now try to imagine proofreading all of those numbers. I'm beginning to think you've never looked at a listing of data cards either. When a keypunch job involves entering 72 numbers-card...
later the cms *update* command was enhanced to both directly handle the $-dollar processing convention as well as internally provide the sequential processing for multi-level update application (instead of having it done externally by an command scripting *EXEC* file ... which eliminating the production of a lot of temporary work files).
CMS editors were also enhanced to take all edit changes and produce *update* files ... as opposed to producing a new copy of the original file with all changes applied. simple example:
.R 01001000 $ 1001000 300 10-09-80 21:40:21
the editor produced a new *update* file of source changes with the "$" field convention ... and also added date-time of the change out in comment field of the ".-" control statement. when you went to edit a source file ... it would also optionally apply all previously generated incremental update files.
a few urls from around the web discussing cms update command
description of current cms update command
discussion of the cms multi-level update process
misc. past posts mentioning cms update command
misc. past posts mentioning joint cambridge-endicott effort to add 370 virtual machine support to cp67
Alt Folklore Computers from Newsgroups