Talk:IBM CP-40

Plan

I am currently revising/creating a series of articles related to the early days of CP/CMS. This involves the various systems referenced by the family tree at the end of this article, plus entries on Cambridge Scientific Center, Lincoln Laboratory, Type-III product, etc. Kindly bear with me while I get the various pages in synch. (I was doing some of this work in a private sandbox, but thought it would be better to start putting out some text. I do intend to provide a good number of citations and references, plus do some systematic editing/wordsmithing, over the next few weeks. Obviously feel free to jump in and fix anything that needs attention. Trevor Hanson 21:52, 18 October 2006 (UTC)

Accurate Terminology

You know that I applaud your efforts, but it is frustrating to see the confusion caused by sloppy terminology. The naming of projects and products was very specific and, in many cases, illuminating. Let me put on my pedant's hat:

• CP-40 was the experimental hypervisor kernel developed for the IBM CSC System/360-40.
• Cambridge Monitor System or CMS was a single-user, standalone "shell" that could run directly on a System/360 or in a virtualized System/360.
• CP-67 was the second-generation hypervisor kernel developed for the IBM System/360 Model 67.
• CP-67/CMS was the packaged system including both CP-67 and CMS.
• Virtual Machine Facility/370 was the official IBM product name of the third-generation System Control Program (SCP) developed for the IBM System/370-Advanced Function (S/370-AF) processors; VM/370 was the abbreviated designation.
• VM-CP was the proper name for the hypervisor kernel component of VM/370; VM/370-CP was often used as an alternate designation.
• VM-CMS was the proper name for the Conversational Monitor System or (ambiguously) CMS component of VM/370. It was one of several subsystems distributed in the VM/370 package.
• Subsequent versions and options of the Virtual Machine Facility/370 package were developed and marketed for supporting specific IBM processor features and software capabilites:
  • VM/370-VMA - Virtual Machine Assist (microcode feature)
  • VM/370-BSEPP - Basic System Extension Program Product
  • VM/370-SEPP - System Extension Program Product (I think)
  • VM/HPO - High Performance Option
  • VM/XA - Extended Architecture
  • zVM - eServer zSeries (currently available)
• Over the years a widening collection of related subsystems were made available, as well:
  • CLMON
  • CPREMOTE
  • CP2780
  • VMREMOTE
  • VNET
  • RSCS
  • RACF

Melinda Varian's paper is likely to be the best source for the earlier variations, but IBM Product Marketing took over the naming game in 1972. If you mix up the names of components with the names of packaged collections, you fall into the naming trap epitomized by UNIX, Linux, OpenBSD, etc. Is it the kernel? Is it a package? Is it a project? Whose Linux? Which processor(s)? Dave Tuttle 03:20, 30 October 2006 (UTC)

Very, very helpful comments, much appreciated. I completely agree with your lament about inaccurate terminology, and regret my own additions to the confusion. Over the years, we have tended to abbreviate or misapply names, to the point where backtracing is difficult. This is precisely the kind of cleanup that I think is so badly needed -- to try to get a really good, accurate record of what happened, when, and what it was called. I will try to pull all this together shortly. Perhaps I jumped the gun – but by putting out some rough text, at least it elicited this nice summary from you. :) Trevor Hanson 08:03, 30 October 2006 (UTC)

What is this, "naming trap," of which you speak? UNIX has no problem, each UNIX is it's own operating system developed by a company, there is no issue telling AIX apart from A/UX, Solaris will never be mixed up with IRIX. Nor does OpenBSD, it is an operating system developed by a group of people, it's development is referred to as a project and it it makes and distributes OpenSSH, nothing getting, "trapped," as far as I can see. The only potential, "trap," is the issue regarding the Linux naming controversy, where the Linux kernel and it's GNU/BSD/public domain UNIX/X Windows/random other people userland are sometimes called Linux, or GNU/Linux as a set of codebases. Each Linux-based distribution desides if it's going to call itself a Linux or not. Fedora Core, or Ubuntu, Debian GNU/Linux, they're all pretty much the same operating system with minor variance. There is a minor issue of confusion because of stupid people bumping egos, but I see no, "trap," with it. Care to explain what you're going on about? Janizary 23:35, 30 October 2006 (UTC)

I'll let Dave answer with specificity but I presume he's talking about the unclear naming lines between kernels, distros, packages, sets of packages, etc. When you say "Linux" do you just mean the kernel, or the ecosystem of code installed on a particular Linux machine? Again, he said: "Is it the kernel? Is it a package? Is it a project? Whose Linux? Which processor(s)?" The answer can range from "One of the above" to "All of the above." This led to a lot of confusion in the SCO litigation. To say that there is no confusion about the UNIX name with OpenBSD is to miss the point, I think. The fact that there may be a strict legal/trademark definition ignores the reality of how the name UNIX is used and misused. Trevor Hanson 03:30, 31 October 2006 (UTC)

How an idiot misuses the term irony does not change the meaning of the word itself, it still means, "the use of words to express something other tham their literal intention." It doesn't matter what Alanis Morissette says or does, coincidence and bad luck will never be ironic. X is X, it is not Linux, GNU is a bunch of poorly made userland tools, it is not Linux, the Linux kernel, the centre of a whole bunch of operating systems referred to as Linux distributions, is Linux, though mob rule attempts to dictate otherwise and call those operating systems which contain Linux simply Linux. Packages have no problem, somerandomprogramme-1.3.7p.rpm is the 1.3.7p release of somerandomprogramme in binary form. Each and every operating system which uses the Linux kernel has it's own name, I cannot fathom any issue with their nomenclature, Ubuntu is Ubuntu, it is not Yellow Dog Linux, nor is it openSUSE. Processors have nothing to do with the naming confusion caused by mass stupidiy, there has never been a Linux processor, it's just a bunch of people who refuse to speak clearly, as with many people referring to their computers and their operating systems as the same thing, your Dell Latitude is not Windows no matter how many times someone asks to see your Windows. How one may illegally use a trademark is not going to change the meaning of the word, UNIX is not a generic term, it is a specific licensed term controlled by a company. If Dave was simply saying, "let's not all be stupid," he could simply have said that rather than go on about Linux. Janizary 05:10, 31 October 2006 (UTC)

Although this issue seems so clear to you, I don't believe everyone shares your view. There is no "official" definition of the term 'irony' – like all other words in the language, its meaning is determined by usage, and may undergo semantic change over time. Thus, although today 'irony' indeed does not mean coincidence or bad luck, who knows what it will mean in 50 years? You assert that "UNIX is not a generic term, it is a specific licensed term controlled by a company." However many observers disagree. It is indeed a licensed term controlled by a company, but as seen with 'Xerox' and 'Coke,' tradenames are difficult to protect. Many people use the term UNIX is a generic way; see Unix-like. You and OSF argue that they are wrong, and are violating a trademark; but others disagree and are pursuing the matter in court. Bottom line: I understood immediately what Dave Tuttle (who speaks from the perspective of a long and distinguished career) meant when he referred to a naming trap involving UNIX, Linux, and related technologies. Anyway, this discussion has drifted off topic, and probably belongs on a blog or forum somewhere. It has nothing to do with CP-40. It certainly did not merit what are close to ad hominem comments about the contributors. Trevor Hanson 20:30, 31 October 2006 (UTC)

Notes on the Family Tree

While I'm here, I might as well chime in on the family tree chart.

• CTSS, the Compatible Time Sharing System, was the supervisor and terminal monitor for the MIT Computation Center mainframe, a modified IBM 7094.
• IBSYS, the Integrated Batch System, was the underlying standard IBM 70x0 operating system that processed the majority of the MIT-CC computation workload.
• OS/360 was initially available in three "flavors":
  • OS/360-PCP - Primary Control Program - single thread, single task
  • OS/360-MFT - Multiprogrammed, Fixed Tasks - static resource allocation
  • OS/360-MVT - Multiprogrammed, Variable Tasks - dynamic resource allocation

• OS/360-PCP gave birth to ONLINE/OS in the Cambridge Scientific Center, but essentially died off with the S/360 line.
• OS/360-MFT gave birth to OS/VS1.
• OS/360-MVT gave birth to OS/VS2-SVS (Single Virtual Space).
• OS/VS2-MVS (Multiple Virtual Spaces) was a new development project, parallel to OS/VS2-SVS rather than a direct descendant (1.6 Mil LOC in 18 months, entirely dependent on VM/370 as the work environment).
• TSS/360 was a unique development project aimed at producing a monolithic multiuser timesharing system, similar to the goals of MULTICS. It was not a derivative of any of the batch O/S or earlier timesharing efforts.
• OS/VS2-TSO (Time Sharing Option) was a general-purpose extension of OS/VS2-MVS for interactive computing. It was an independently developed alternative to TSS/360. VS2 plus TSO was architecturally related to the original CTSS plus IBSYS combination.
• OS/VS1 and DOS/VS provided "hosting" for interactive facilties such as CICS/VS (Customer Information Control System) and its wide range of industry-specific applications.

• Of the various Digital Equipment Corp. systems listed, it is not likely that any of the '-11' systems are related to any of '-10/20' systems. The DEC operating system development groups in the 1970's were diverse and competitive. The DECsystem-10 and DECsystem-20 machines were 36-bit; the PDP-11 machines were 16-bit; PDP-8 and PDP-12 machines were 12-bit; the PDP-15 was something else. Systems that I knew of and/or worked with (1976-1978) included:
  • RSX-11M
  • RSX-11D
  • RSTS
  • MUMPS-15
  • MUMPS-11
  • RT-11
  • VAX/VMS

At the time there were 11 different operating systems in production. Portions of VMS are likely to be related to VM/370, by the way, since a substantial portion of the IBM Burlington team ended up working on VMS in the 1976-1979 era. Dave Tuttle 04:16, 30 October 2006 (UTC)

I know that the family tree needs surgery. My goal was to have SOME kind of graph structure, showing links to all the major time-sharing systems – something with more structure than just an alphabetical or chronological list of system names. The tree's current incarnation shows all relationships in the same way – from direct derivation to loose influence (I tried a variety of other approaches). Some of the relationships are indeed tenuous, e.g. those shown for for TSS, which really were intended to show precedence in the sense of 'prior art,' rather than actual derivation of code or architecture. I'll try to come up with something less likely to raise eyebrows. I still think some kind of tree is the right approach.

• Regarding TSS: I understand that it was not directly derivative of any other operating system; but surely it was influenced by earlier work, particularly at MIT?

• Regarding SVS and MVS: My recollection was that these were released as OS/VS2 2.3 (SVS) and OS/VS2 2.4 (MVS). (I might have the release numbers wrong, but I remember a distinct migration path.) I can't find any of my old SVS manuals; does this sound right?

• • SVS was OS/VS2 version 1; it was basically MVT with virtual memory. MVS was originally released as OS/VS2 version 2, but it was supposedly such a dog that it had to be substantially reworked, and released as OS/VS2 version 3. It didn't really work well until version 3.7; 3.8 was the last non-program product version. -- Jay Maynard 03:53, 3 December 2006 (UTC)

• Regarding the DEC operating systems: Again, as with TSS, surely RSX and RSTS drew user interface ideas from the major timesharing systems in use at the time, viz. TOPS and MULTICS? The PDP-11 OSes weren't consed-up in a vacuum.

Thanks again for much helpful input. At the end of the process, I'd like to see a set of factual articles that don't suffer from any of the problems you've identified. There's till some wood to chop before we get there, though. Trevor Hanson 08:47, 30 October 2006 (UTC)

See the revised family tree, which should be a less dubious framework. It still needs work of course. The temptation will be to add every system we can think of; but to be useful, it should probably just have the major systems that really influenced the industry, or introduced major new interface concepts. (My intent here is to focus on the interface side of things – the timesharing-ness of the systems – rather than on other operating system concepts which were evolving at the time. Similar family trees addressing such concepts as file systems, virtual memory, dispatching, etc. might be helpful. Unfortunately we don't have a really good tool for building such linkage graphs. Perhaps the template language is robust enough to build something like that...?) Trevor Hanson 19:51, 30 October 2006 (UTC)

Whither the term "CAT box" ?

Where did this term come from? The original relocation design for the S/360 series was called a "Blaauw box", for its designer, Gerrit Blaauw. Dave Tuttle 22:38, 18 November 2006 (UTC)

Varian's paper includes this paragraph (p. 11) (my stress added; remember that we're talking about CP-40 rather than CP-67 here):

This system could have been implemented on a 360/67, had there been one available, but the Blaauw Box wasn’t really a measurement tool. Even before the design for CP-40 was hit upon, Les Comeau had been thinking about a design for an address translator that would give them the information they needed for the sort of research they were planning. He was intrigued by what he had read about the associative memories that had been built by Rex Seeber and Bruce Lindquist in Poughkeepsie, so he went to see Seeber with his design for the “Cambridge Address Translator” (the “CAT Box”), which was based on the use of associative memory and had “lots of bits” for recording various states of the paging system.

Regarding the availability of CP/CMS in source form: I see you changed the text to say that most IBM OS software was not shipped in source form at this time. Is that true? As I recall, OS also came with source, and I thought you posted an earlier comment to this effect; though perhaps source only came on fiche. At any rate, my text was wrong here anyway since the first CP/CMS was before unbundling, and thus should not really be compared with SCP software. But are you saying that, after unbundling, SCP software was binary-only? Trevor Hanson 23:31, 18 November 2006 (UTC)

[added 11/18/2006 15:45 PST]: I've reread your comments on Talk:Hypervisor and realize that I had misremembered what you said about source distribution of OS software; I somehow read this as saying that most IBM OS software at the time was delivered this way. Obviously not. The following comment you made is so clear that I propose moving most of it into the new CP/CMS material:

Note that before the June 23, 1969 "unbundling", all IBM software was freely available to IBM customers - distributed and supported primarily in binary form. All of the major elements of CP-67/CMS and the first 'N' releases of VM/370 were distributed in full source form, along with the tools to (re)build the kernels and many of the command-line programs. Language processors and some other user-mode programs were distributed in binary form, since they were "borrowed" from the OS/360 software. Updates were provided as source patches, to be applied or not at the cutomer's choice. Problem reports (APAR's - Authorized Program Analysis Report) were often received with the fix provided, in source form; one variety of APAR was an Enhancement Request. A large number of fixes and extensions were originated "in the field" and in other parts of IBM, then verified and redistributed on a subsequent PLC (Program Level Change) tape. If that does not qualify as "Open Source", I don't know what would. It predated the GPL by several decades.

According to the terms of the 1969 unbundling, System Control Program (SCP) software was available without additional charge to any IBM customer. System Product Program (SPP) software was extra-cost, ordered separately, and supported for a fee. The source restrictions and charging for operating system software came about much later.

Thanks for watching over this effort. Sorry it's taking longer than expected (but you know how that goes). Trevor Hanson 23:50, 18 November 2006 (UTC)

OS distribution in source form

The comment about distribution in source vs. binary form needs to go away entirely, since it's inaccurate. OS/360 and DOS/360 (contemporary to CP-40 and CP-67) were distibuted in source form; indeed, building the system that sites actually ran was done by assembling the supplied source code under an IBM-supplied "starter system", which was then discarded. OS/360 source is available even today, and I've got a page that describes how to build a running MVT system under Hercules. Jay Maynard 03:57, 3 December 2006 (UTC)

Hokey smokes. You know, I had thought that what you say was true, but I wound up getting persuaded it was not. OK, I will fix this. If you can find any citations about OS distribution methods at the time, that would be very helpful. (I am still trying to find any definitive material about the content of the Type-III library – at any period.) I wish I still had some of my old manuals, but few are left. (I do have a TSS manual though.) Trevor Hanson 06:54, 3 December 2006 (UTC)

I have removed the text in question, which was destined for the CP/CMS article anyway. See what you think of its new home in the CP/CMS article and whether it is an accurate description of the sequence of events. Again, any citeable sources will make this easier, since there seem to be different views about how much binary distribution occurred on the S/360 and S/370 platforms. I hope that Dave Tuttle has a look at this and can provide his slant. Trevor Hanson 07:19, 3 December 2006 (UTC)

I don't know where to find citations about the distribution method; it's one of those things that's so basic that nobody felt the need to comment on it. Maybe some text form the introduction to sysgen manual...I'll look around on bitsavers.

The stuff in the CP/CMS article looks okay, for the most part, though source code was available for the non-Program Product OSes the whole time. IBM didn't start distributing things in object code only (OCO) until the early 80s. It was quite controversial at the time, and some folks attribute the decline of IBM in academic settings in part to that policy. Jay Maynard 15:24, 3 December 2006 (UTC)

Yeah, that and the fact that, by 1980, you couldn't find a computer science program that wasn't steeped in UNIX, LISP, Smalltalk, Cedar, etc. People learned from K&R and the dragon book, not from IBM manuals. Losing Project MAC and Bell Labs look like the key milestones to me. But OCO certainly didn't help. Even in the 70s, source code access was restricted at most sites. At Sears, I remember that it was closely guarded by the systems programming priesthood, as were all the interesting manuals. One had to sneak into storerooms and filch the PLMs etc. IBM was aggressive about maintaining a strict hierarchy of knowledge, and source code was very high in the pyramid. At least that was my experience. Trevor Hanson 06:25, 4 December 2006 (UTC)

This varied from site to site. The sites I worked at were much more relaxed: since proper security setups prevented accessing things you shouldn't, there was no particular reason to lock down the source, much less the manuals. Most restrictions of that type were designed not to protect the system, but to keep the systems programmers from getting bugged by folks wanting them to do things that were technically possible but against site policy for one reason or another. It was often easier to say "the system can't do that' rather than "we won't set it up that way": the latter was much more subject to argument. Jay Maynard 13:14, 4 December 2006 (UTC)

Yes, I worked with sites like that too, but they seemed to be in the minority. (You're right about the self-protection rationale behind such policies, of course.) By the 80s, though, I think the "big shop" mentality/hierarchy was widespread, with lots of focus on standards, security, and need-to-know attitudes – leading to a lot of end-user dissatisfaction, and the rise of the Information Center concept and the time-sharing industry as ways to gain freedom from traditional MIS. I think IBM helped foster much of this insularity, in what I suppose we might call its second generation of FUD (the first being in the era of the Seven Dwarves and the BUNCH). I remember some very opinionated SEs who had definite ideas about limiting access to technical information. IBM's decline in academic settings traces a long arc from 60s through the 80s – a mirror image of its ascendance in corporate computing. Trevor Hanson 20:46, 4 December 2006 (UTC)

Let me chime in, again, with what I remember from OS/360-PCP Rel.4/5 days at the MIT-CC. The OS/360 Starter System was typically distributed as a set of tapes. Step 1 was to IPL from the first tape, then restore the rest of the tape data onto a disk volume or two (2311s, at that time [1967]). Then you could IPL the starter system from disk, I think. The only thing you got in source form was a set of macro libraries and procedures. You had to create the SYSGEN file, which was a S/360 Assembler file that used a standard set of macros to describe the hardware and the system options that you wanted. Step 2 was to use the SYSGEN macro library to compile the system description, and it generated the rest of the data and procedures needed. The vast majority of the actual O/S code was distributed as binary files in the disk image(s) of the starter system, such as SVCLIB, and copied from the starter system disk(s) onto the target disks of the resulting system. The time-consuming part of the install was formatting the target disks and copying the selected binary data into place. If you could show me the Assembler source for the OS/360 first-level interrupt handlers, just as an example, I would be fascinated. I worked at MIT for 2 years and at IBM for over 8, and I don't think I ever saw that code. Dave Tuttle 22:18, 4 December 2006 (UTC)

I cannot tell you two how eager I am to see the result of this discussion. After each of your comments on the topic, I've thought "Oh yes, that's right." Trevor Hanson 03:07, 5 December 2006 (UTC)

When I started as a working sysprog in the late 1970s, the OS (MVT 21.8E in our case) SYSGEN process was very little source and mostly binary. The "STAGE1" and "STAGE2" SYSGENs were as Dave Tuttle says they were. The STAGE1 job was an assembly of a bunch of special-purpose macros, and was run against a maclib to generate another set of jobs that did the work. These STAGE2 jobs were a mix of assemblies (mostly site-specific tables of data) and link-edits of shipped-in-binary code. We did, of course, have lots and lots of code in micro-fiche form, but it wasn't the source - it was the assembly listings, 121-column fan-fold output on fiche. As both he and Jay Maynard say, you needed a starter system to run those stage 1 and stage 2 jobs, and they ran for quite a while, even on our 370/168-III. By contrast, our first VM system, VM/370 Release 5, came with both a starter system and full source for CP, CMS, and a few other components. Most VM sites in those days did a full build from source - I'm not even sure there was a production-qualified binary-buildable system until you ran those first assemblies. We had fiche for VM as well, although we had enough 3270s (real and emulated) that we didn't use it much. On yet another hand, I believe Jay has done an MVT sysgen a lot more recently than I have. RossPatterson 04:45, 5 December 2006 (UTC)

FWIW, this was basically my experience, although I spent less time in this environment than you guys. I definitely only remember source on fiche, though; in fact I can remember 'fiche' being synonymous for 'source' at at least three sites. It is sounding to me like perhaps today's treatment of those systems as published public domain source (by IBM et al.) may be a different issue from how they were treated in the day. I look forward to hearing Jay's perspective. I was very surprised by the idea that OS (especially MVS) was distributed in source form, although the details he's been citing sound very convincing. Perhaps it is a question of source distribution occurring at x% of the sites – enough to make a precedent, even though not the normal experience at many shops? I'd like to get the descriptions correct. Dave has said that the distribution of CP/CMS (as Type-III) and early VM (as SCP) in source form was unique, and that was what I had believed – until hearing about the status of systems from the Hercules angle. Trevor Hanson 06:39, 5 December 2006 (UTC)

While we were developing the first and early subsequent releases of VM/370, specifically late 1971 through spring 1973, the majority of IBM SDD code was written in PL/S (Programming Language/Systems) with, in many cases, embedded FL/1 (Flowcharting Language/1). Both PL/S and FL/1 were proprietary tools that, to the best of my knowledge, were handled as IBM Trade Secret and never made available outside of the company. I suspect it would have been difficult to get them outside of SDD, let alone at a customer site. One of the hurdles we had to jump was the justification to not use PL/S. We did go through the FL/1 exercise at least once, but I don't think the FL/1 statements were included in the released source code. Dave Tuttle 19:41, 5 December 2006 (UTC)

D'oh! <hits head> I knew that. PL/S had a lot of buzz in those days, and I remember efforts being made to get access to a compiler. I do remember being shown examples on paper and fiche – e.g. TSO source. The Wikipedia PL/S article has some interesting detail; I do remember hearing about the RAND effort to offer a compiler through SHARE. This concluding sentence is interesting: "IBM recanted and has offered the current versions of PL/S to selected customers (ISVs through the Developer Partner program.)" PL/S is still apparently not public domain or open source. This makes it unlikely that components using PL/S could have been distributed in source. Jay, any further thoughts? Trevor Hanson 21:14, 5 December 2006 (UTC)

Based on what's just been said, and pending more input from Jay, I have restated the CP/CMS material about source code distribution. I didn't want to leave a disputed statement in place. Regardless of whether OS, DOS, etc. sources were actually distributed in machine-readable form, I think we can agree: a) that only CP/CMS had a large community of source code users; b) that IBM did provide sources for these other systems in some forms, at least fiche; c) that those portions of systems written in PL/S couldn't have been compiled by customers no matter what, though they could have assembled the generated assembler (that's how PL/S worked, right, not direct-to-object?), and d) that the putative availability of sources TODAY doesn't necessarily mean they were available "back in the day". I'll keep looking for primary sources dealing with this issue, and will watch for further comments here by you folks with more knowledge than I. Trevor Hanson 06:03, 6 December 2006 (UTC)

Well, let's see. A quick search for FLIH in my copy of the OS/360 source turns up a macro, IECINT, from SYS1.MODGEN with the following comment at the beginning:

*              THE IOS INTERRUPT SUPERVISOR IS THAT PART OF THE
*              INPUT OUTPUT SUPERVISOR WHICH HANDLES THE INPUT OUTPUT
*              INTERRUPTS.
*              THE FOLLOWING IS A GENERAL OUTLINE OF THE OPERATION
*              OF THIS PROGRAM.

There was an extensive collection of OS/360 user mods, all distributed as source code changes by SHARE and GUIDE. There are other FLIHs; I didn't go searching for them. Yes, the sysgen did a lot of copies, but it did more assemblies, and large chunks of the system are copied and then re-assembled from scratch in a full gen. (Presumably, this allows for partial gens, in case the user only wants to change some parts.) Note that this was only true of OS/360. MVS, at least, was indeed largely rewritten in PL/S; even then, however, the source code was provided in microfiche and optional machine-readable materials. (I haven't gone looking, but I believe they're included in Volker Bandke's Turnkey MVS system; I have a copy of them, in my copy of the complete MVS 3.8 distribution on 30-something 3480 tape cartridges.) Most sites didn't bother loading them to disk, since nobody outside IBM could compile PL/S, and so making mods became a lot more problematical to manage. This was a stated goal of IBM, as it made it much easier for them to do problem determination. The culture of users making source code mods to the OS died out a lot earlier in the MVS world than it did in the VM world, but I'll firmly stand by my contention that it was not unique to CP/CMS (or VM). Jay Maynard 11:59, 7 December 2006 (UTC)

A little more digging found the actual external, SVC, program, machine, and I/O FLIHs in SYS1.MODGEN macro IEAAIH. You can see that at [1]. Jay Maynard 14:20, 7 December 2006 (UTC)