Anne & Lynn Wheeler
2006-07-31 15:40:44 UTC
How do the various source maintenance packages for other platforms
such as Unix handle the problem. I'm thinking of CVS and the various
Itegrated Development Environments. There are differential upgrades
and other techniques. I am not familiar with them but realize that I
am not familiar with most of the tools in the non-MVS environment.
rcs, cvs, etc ... tend to be "down-dates" ... you have the completesuch as Unix handle the problem. I'm thinking of CVS and the various
Itegrated Development Environments. There are differential upgrades
and other techniques. I am not familiar with them but realize that I
am not familiar with most of the tools in the non-MVS environment.
source for the current version ... with control information how to
regress to earlier versions.
cms had "update" command from mid-60s ... which applied an update
control file to source, resulting in "temporary" file to be updated
recent refs:
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
this provides a short description of the evoluation of the CMS
update command into multi-level source maintenance updates
http://www.garlic.com/~lynn/2006n.html#45 sorting
one of the things that fell by the wayside was an application
that attempting to merge potentially parallel update activity.
during the early days at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
evolving the cms multi-level source maintenance process ... there was
an application written that attempted to merge and resolve parallel
update/maint. operations.
the infrastructure evolved out of a joint project between cambridge
and endicott to add 370 virtual machine support to cp67. cp67 provide
virtual 360 and virtual 360/67 (i.e. virtual memory) virtual machines
... but 370 was going to announce virtual memory (it was something
like two years away). 370 virtual memory definition had various
differences from 360/67. the idea was quickly implement 370 virtual
machines (with 370 defined virtual memory hardware tables) under cp67
(running on 360/67).
the multi-level initially consisted of
1) normal set of updates and enhancements built on base cp67 source,
("cp67l" system)
2) set of updates applied to normal cp67 that added support for 370
virtual machine option ("cp67h" system)
3) set of updates that modified cp67 kernel to run on 370 hardware
(rather than 360/67 hardware; "cp67i" system)
part of the issue was that the cambridge cp67 system hosted some
number of students (mit, bu, harvard, etc) and other non-employees in
the boston area. since 370 virtual memory hadn't been announced yet,
it was being treated as super sensitive corporate information and
there was no desire for it to leak to non-employees.
as a result only #1 kernel typically ran on the real hardware. #2
kernel would run in a 360/67 virtual machine, isolated from prying
eyes of the students and other non-employees. for testing of #2, #3
would then run in a 370 virtual machine (under #2 kernel, running in
360/67 virtual machine under #1 kernel, which ran on real machine).
so potential problem was that there might be new updates introduced at
the "#1 level" (earlier in the update sequence) which might impact the
updates applied later in the update sequence (i.e. updates to the base
system that was going on independently supporting changes for 370
virtual machines).
as an aside, "cp67i" was up and running as normal operation a year
before the first engineering 370 machine with virtual memory support was
operational. then as 370 real machines with virtual memory support
became available internally (still well before customer first customer
ship), the "cp67i" was standard operating system running on those (real)
machines ... at least until the vm370 morph became available (and some
of the other operating system development got far enuf along to move
from testing in virtual machine to real machine operation).