Misplaced Pages

Talk:IBM CP-40

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by Janizary (talk | contribs) at 05:10, 31 October 2006 (→Accurate Terminology). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 05:10, 31 October 2006 by Janizary (talk | contribs) (→Accurate Terminology)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

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)

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:

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?
  • 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)