Source maintenance was Re: SEQUENCE NUMBERS
(too old to reply)
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 complete
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

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).
Anne & Lynn Wheeler
2006-07-31 19:48:38 UTC
I'm not sure when it came along, but by VM/SE there was a somewhat
more sophisticated UPDATE facility[1] with aux files, control files
and update files. I'd love to see a similar facility integrated with
[1] Not only could the XEDIT editor process them, but it could
generate update files to reproduce the effects of an edit
session. That's one of the CMS facilities I miss the most.
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re:

the aux files, control files, update files scheme was what was created
for the effort for building 370 virtual machine support into a cp67
kernel (running on 360/67). however, it was implemented all in EXEC with
EXEC processing figuring out the control & aux files and making
interative calls to UPDATE command.

this was picked up as part of the original vm370 release and update
command was enhanced to directly process control, aux, and update files
(in one pass) and spitting out the (temporary, working) source file for

a little later, editors were enhanced to directly support the control,
aux, and update files as part of loading a source file for editing ...
with option that all changes made in the edit session resulted in an
"update" file (as opposed to a new complete source).

this recent posting, in a different thread, has more detailed
description of some of the operations ... as well as URLs to current CMS
documentation (including an example "update" from an internal editor
that predated xedit).
http://www.garlic.com/~lynn/2006n.html#45 sorting

a few other recent postings that happen to also mention xedit:
http://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe:
Little Iron
http://www.garlic.com/~lynn/2006n.html#43 MTS, Emacs, and... WYLBUR?
http://www.garlic.com/~lynn/2006n.html#55 The very first text editor
Peter Flass
2006-07-31 21:18:17 UTC
Anne & Lynn Wheeler wrote:

I guess most unix people use cvs, rcs, etc. nowadays, as someone posted.
There used to be lots of use of diff and patch. Lacking sequence
numbers, they worked either by line nunber or by using one or more lines
of context to identify the line to be changed.
Brian Inglis
2006-08-02 05:36:57 UTC
On Mon, 31 Jul 2006 21:18:17 GMT in alt.folklore.computers, Peter
Post by Peter Flass
I guess most unix people use cvs, rcs, etc. nowadays, as someone posted.
There used to be lots of use of diff and patch. Lacking sequence
numbers, they worked either by line nunber or by using one or more lines
of context to identify the line to be changed.
There still is: cvs diff to generate the patches for distribution, and
patch to apply them to your local copy, before the change is committed
to cvs; no other option if you don't have remote access to the cvs
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

***@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Anne & Lynn Wheeler
2006-08-12 14:37:05 UTC
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re:
http://www.garlic.com/~lynn/2006o.html#21 Source maintenance was Re:

for some additional drift, old history about requiring source for
application distribution on the internal network

***** Extract from VM Newsletter 5 *****

V M Newsletter Issue 5 ... May 1977

Welcome to the fifth issue of the newsletter.


I recently received a contribution for the newsletter which, in
addition to the usual description, mentioned that no source code for
the item described would be made available. I have withheld its
publication for the time being. I feel that, in the absence of a very
good reason to the contrary, contributors should always make the
source for their programs available to the requesters. Aside from
the fact that in many cases it may be essential for the proper
installation of a program to have the source, it seems to me a matter
of courtesy that it should be provided. I would like to establish a
policy for the newsletter regarding this question, but I solicit your
opinion to help me do so.

***** Extract from VM Newsletter 6 *****

V M Newsletter Issue 6 ... June 1977

Welcome to the sixth issue of the newsletter.

The response to the first editorial in the last issue is quite
satisfying. Most of you feel that source should, in general, be made
available. But a number of readers pointed out some other
considerations, most of which seem to me to be valid. Among them:

* Sometimes the source is really not available; it seems
unreasonable to lose what might be an otherwise valuable contribution
and of use to someone in spite of the lack of source.

* Sometimes the source is really part of, or related to, some
product being developed and the source can't be made available until
the corresponding product is announced or shipped. This was the
situation with the contribution which prompted the editorial.

* When the program is under continuing development, it is a
considerable burden to the developer to provide a complete set of
source. In this situation, some people felt, at least idle requests
for the source code should be discouraged. Furthermore, there appears
to be a conflict between letting many early versions of the program
propagate widely, and getting a number of early "guinea-pig" users.

* When the contribution is the installation of some OS-based
processor on CMS, it is inappropriate to distribute the source of the
entire processor. In these cases, however, the source for any
interface and installation programs should be provided.

* There are a few unusual cases in which the integrity of a
lot of data depends on the integrity of programs which access or
maintain it. A specific example of this is a file system which was
developed at Yorktown. In such cases, a small bug could be introduced
by someone casually changing the program, and not have its effects
realized until long afterwards. In cases like this, perhaps the
burden is on the requester to demonstrate that providing the source
will not lead to a bad situation.

The policy I have decided to implement for the newsletter is to
publish any contribution, but to require that the contributor state
explicitly that the source is not available, and that he explain why
this is the case.