Talk:History of IBM mainframe operating systems

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Discussion leading to creation of the article[edit]

See Talk:MVS for a verbose discussion leading to the creation of this article and to restructuring most IBM mainframe OS articles. --Kubanczyk 14:35, 23 October 2007 (UTC)[reply]

To avoid inconvenience to other users I'm moving to this page all discussion relating to History of IBM mainframe operating systems an dposting a note about this on Talk:MVS.Philcha 12:07, 24 October 2007 (UTC)[reply]

Need to restructure IBM operating system articles?[edit]

I've done a fairly large edit on the MVS article ("Evolution ..." and "File management"). Now that I've had time to look at related articles (e.g. MFT, MVT, IBM System/360 Model 67) I think the MVS article contains too much that's common to these other OSs and that we need to restructure the set of articles about IBM mainframe operating systems. I suggest:

  • Generic article about IBM operating systems from System/360 onwards, including BOS, TOS and other ancient history. Good place for war stories and links to Fred Brooks and Gene Amdahl.
  • OS family
    • From OS/MFT to MVS. Stopping at the point where MVS became the only surviving OS variant and referring to the MVS article for more recent developments.
    • Evolution of memory management in the OS family. Refer to 360/67 and CP-67. Include brief description of V=R mode (where the virtual memory facilities were disabled so that a logical address was also a physical address).
    • File management, including references to ISAM and VSAM articles.
    • JCL (OS) briefly, and refer to JCL (OS) article.
    • Utilities (OS) briefly, and refer to Utilities (OS) article.
  • Shorter individual articles on each of MFT, MVT, VS1, SVS, MVS, all referring back to the comprehensive article on the OS family.
  • DOS family.
    • Overview of the entire family and describe common features.
    • File management, including references to ISAM and VSAM articles.
    • JCL (DOS) briefly, and refer to JCL (DOS) article if anybody wants to write one (not me as almost all my IBM experience was with the OS family).
    • Utilities (DOS) briefly, and refer to Utilities (DOS) article if anybody wants to write one (not me).
  • Possibly individual articles on DOS, DOS/VS, DOS/VSE. Or it might be better to make these redirect to a single article on the DOS family, as there's less variation in the DOS family.
  • VM family, including ref to CP-67.
  • Unix-based IBM operating systems. I can't suggest how to structure this topic as I don't know Unix-based operating systems at all.Philcha 06:14, 19 October 2007 (UTC)[reply]

Hi. First of all, great work. My view on restructuring - yes the current structure is bad. Every OS article explains the whole story.

My reply, with a LOT of links collected, but only considering the 1st stage below.

(current version of plan moved to subsection below)

I need comments on article names, do they stick to WP:COMMONNAME? For example is it more common to call CP/CMS+VM+z/VM a VM line or CP/CMS line? Or maybe family instead of line? It would be great if you could copy just update the whole tree to your reply, and apply corrections, so the whole hierarchy would be still visible. --Kubanczyk 16:48, 19 October 2007 (UTC) Updated Kubanczyk 19:38, 19 October 2007 (UTC)[reply]

Yes, the reorganization makes sense to me.
IBM mainframe also refers to pre-S/360 mainframes, so the "IBM mainframe operating systems" should have a section for them, linking to pages such as the IBSYS page. Guy Harris 18:26, 19 October 2007 (UTC)[reply]
I was thinking perhaps we should have one set of articles "IBM operating systems System/360 onwards" and another "IBM operating systems before System/360". I expect most readers will go for the "System/360 onwards" pages as they would describe a set of software that is more coherent and with more obvious similarities to what's in use now. But "before System/360" will still have some interesting content, esspecialy in the light of the "family tree" shown in CP-67. And the root "before System/360" article will have to explain quite carefully the humble, fragmented beginnings of the operating system concept.Philcha 21:20, 19 October 2007 (UTC)[reply]
Presumably the reorg would handle the issue I mentioned above, where I asked whether features mentioned on this page should be moved to the OS/390 page if they first appeared in OS/390 or to the z/OS page if they first appeared in z/OS? Guy Harris 18:29, 19 October 2007 (UTC)[reply]
By "features mentioned on this page" do you mean this Talk page or the MVS article? The content I added to MVS mainly applies to the late 1970s and early 1980s, except for the comments about what drove the moves to larger address spaces.Philcha 21:20, 19 October 2007 (UTC)[reply]
Yes, exactly. I think it is pointless to focus on "what was introduced in this-or-that OS" and scattering the "evolution story" among multiple pages. I find the "how this-or-that feature (like virtual memory or I/O) evolved over the years" approach much more interesting. This is also favored by most other contributors. Introducing "... line" articles will help everyone.
Btw, I take back what I said about copying the whole tree. Just update the original tree, wiki saves historical versions. --Kubanczyk 19:38, 19 October 2007 (UTC)[reply]
Oops, I copied and annotated it then got and edit conflict while trying to save, and didn't notice your latest suggestion until after the save.
At least the edit conflict made me aware of Guy Harris's interest in the subject. Welcome aboard, Guy. The entire subject is so big and hard to structure that it needs all the input it can get.Philcha 21:20, 19 October 2007 (UTC)[reply]

Hi, Kubanczyk, it's nice to know that you agree and have the enthusiam and knowledge. As you suggested, here's your structure with my comments.

Also needs to summarise pre-360 operating systems - show where IBM started from and how the 360 operating systems were a big leap forward from a less structured collection of device drivers, utilities and system services (e.g. timer). I think in this context it would be appropriate to include war stories and quotes, e.g. "We bet the company" (on System/360; a frequent quote around IBM, I think reproduced in Father, Son, and Co.: My Life at IBM and Beyond, the autobiography of Thomas J. Watson, Jr.), although IBM was usually regarded as conservative.
We face a big decision here. I think it's important to show how each family of operating system evolved, e.g.: DOS had only 1 partition initially, then 3, and DOS/VS had 5; no spooling at first, but IBM added POWER in response to the 3rd-party spooler GRASP (IBM System 360, Model 30); pre-VS DOS had no relocating loader, so users had to linkedit each program at least once per partition in which they might want to run it. This family could (eventually) run most IBM software (compilers, sorts, apps, CICS, VTAM, IMS DB aka DL/I) but not [TSO] or IMS DC - and DB2 added much later but available with VSE/ESA (z/Journal). Unlike the OS family it did not allow multi-tasking within a partition (job), at least in the members I had contact with. I don't know how up-to-date your knowledge is but I'd have to research later members of the family from DOS/VSE to zVSE to see how far they evolved.
We also need to research features which distinguish all DOS-family operating systems from all OS-family systems. AFAIK (up to DOS/VS around 1979) DOS lacked: within a partition (job); device independence in both JCL and program code (file declarations for DOS had to specify device type); file catalog, at least until VSAM came along; relocating loader until DOS/VSE.
If we went with the evolutionary approach the title should be something like "DOS family of IBM operating systems". It would also imply that article sin specific DOS-family members would be shorter.
At present we have an article Job Control Language which mostly emphasises the common features of DOS and OS JCL basic syntax, and then summarises OS JCL. Given the commonalities perhaps we should keep JCL as 1 article and add sections on the distinctive features of DOS and OS JCL: DOS JCL hard to read and write because all parameters positional rather than keyword; no device independece in DOS.
I remember reading decades ago that the USA's General Accouting Office thought the unfriendly design of JCL cost the US economy billions of $ a year - but Google got no hits on "IBM JCL GAO General Accounting Office billion dollar".
Good sources: IBM's Introduction to the New Mainframe: z/VSE Basics; z/VSE Products and components.
        • Exists
    • OS/360 line a summary introducing those subordinate articles:
We face the same big decision here as for the DOS family. I think it's important to show how each family of operating system evolved, and I think the case is stronger for OS... than for DOS... because OS immediately split into 2 sub-families, the MFT-VS1 group and the MVT-SVS-MVS-...-z/OS group - and we need to explain once(!) what the split was about.
I'm not sure about this - there's a 3-way split between the DOS, MFT / VS1 and MVT / SVS / MVS / etc. families, and DOS and MFT / VS1 (OS!) resemble each other more in memory management than either resembles MVT / SVS / MVS / etc. Hence I think there's a good case for covering it in the top-level article.
Access methods bothers me because its content is too IBM-specific but many operating systems have the concept, many use the suffix ...AM in the names and there are a lot of ISAMs besides IBM's.
My current feeling is that Access methods should be more generic and that we should have: IBM Mainframe File Management covering record-orientation, OS filename structure, IBM access methods, OS catalog and (briefly) VSAM catalogs (and shorten the corresponding stuff in MVS); VSAM catalogs (available for DOS family from DOS/VS onwards?; add material on master and user catalogs, see [1])
See comments above.
Agree, IBM mainframe utility programs is OS-specific.
Retitle "IBM operating systems - MVT to MVS" in the light of its scope.
But becomes shorter as a lot of the material will be in the articles about IBM mainframe operating systems and / or about the OS family.
I prefer "VM family", see below.
OK, I included this mainly to raise the question "Are there any?"

I need comments on article names, do they stick to WP:COMMONNAME? For example is it more common to call CP/CMS+VM+z/VM a VM line or CP/CMS line? Or maybe family instead of line?

In my experience "VM" was normal - CP-67 was history when VM was launched. But my IBM experience was mainly with big organsations that used MVT / SVS / MVS and who therefore had TSO; so their main interst was in the "guest operating system" aspect as a tool for testing new releases of SVS / MVS. Someone whose background is in "smaller" organisations (including some leading UK insurance companies!) might see CMS as the more significant component since to was the only time-sharing facility for users of the DOS and MFT / VS1 families. After all this rambling I still prefer "VM" because the current memeber of the family is z/VM.
We probably need to think hard about how to handle this family, as it had 2 sets of ancestors: CP-40 introduced the "hypervisor plus guest operating system" architecture, CP-67 was IBM's first virtual memory system AFAIK; but both were the "kernel" CP components of the CP/CMS operating systems, whose main deliverable was time-sharing. The hypervisor concept apparently started with IBM M44/44X on a modified IBM 7044 (pre-360!) - but this incuded time-sharing (An Experimental System for Time-shared, On-line Data Acquisition ). And the time-sharing front-end apparently got going with MIT's CTSS (non-IBM!), based on John McCarthy (computer scientist)'s work with a modified IBM 704 in 1957(!). Just to complicate matters, CP/CMS also spawned VP/CSS, which was turned into a bureau service by a group of technicians who defected from the CP/CMS project.

Help, I'm more confused than ever!Philcha 21:05, 19 October 2007 (UTC)[reply]

Hey, first of all, you are mistaken about me having any knowledge about mainframe world. I don't even know z/OS :) I reintegrated what you suggested to the hierarchy; then moved the the plan to always stay on the bottom - as it is the most current version at any time. Please reply here and paralelly improve bottom hierarchy to keep the clear picture. About naming personally I find "family" not specific enough. For example VM and MVS are a family too (brotherhood). The "line" is better because it immediately suggest the article is about father-son relationships. Maybe you will find "evolution of ..." a better convention?

The more I read, the more I prefer "family", because we have to deakl with multiple ancestor and descendant lineages. For example OS was split from the start into MFT and MVT (multiple descendants); and all the .../VS operating systems inherited the virtual memory components from the CP/CMS group (so DOS/VS has 2 ancestors, DOS/360 and CP/CMS).
BTW while checking out CP/CMS I found one of its ancestors, IBM 44/44M, on an non-360 machine around 1960! This raises the question of whether we should try to wrap up all IBM mainframe operating systems. I prefer to focus on Sys/360 and successors: the job's pretty large and complex already; in both hardware and software Sys/360 and successors show a clear evolutionary continuity; pre-360 "operating systems" were more heterogeneous and rudimentary (except for the CP/CMS group, but they were special-purpose). Philcha 11:36, 21 October 2007 (UTC)[reply]
  • DOS

We cannot use "DOS" itself, it is to ambiguous (MS DOS). I think the wholle discussion about structuring of this line should be started at DOS talk pages, and is not main interest here. For a whole line I think "DOS/VSE line" is the best; it was not the first system chronologically, but it is most obvious choice to be understood today.

I agree about avoiding ambiguity - I only use "DOS" as shorthand in this Talk page. Bbut I prefer "DOS/360" as our "official" term: DOS/VSE is no longer supported, therefore will become a decreasingly obvious choice to be understood by general readers; z/VSE is about 10 years old, and it's about time for IBM to give its successor a new name; DOS/360 is an immutable starting point and emphasises evolutionary continuity, which I think is important for both of us. Philcha 11:36, 21 October 2007 (UTC)[reply]
DOS/VSE Release 1 was a major change probably greater than the addition of virtual storage. The supervisor was completely (every line) re-written. BPS (the basis of TOS and BOS) survived only as part of the IPL routines. The task manager was completely changed allowing additional partitions (tasks) and subtasks. So the story of VSE ought to begin with DOS/VSE. I saw a comment that z/VSE would be separate. I am not sure that I follow the reasoning. Ccalvin 17:38, 29 October 2007 (UTC)[reply]
  • OS

"Access methods bothers me because its content is too IBM-specific but many operating systems have the concept, many use the suffix ...AM in the names and there are a lot of ISAMs besides IBM's." This does not matter per WP:COMMONNAME. Today if you say AM you always think about IBM mainframes. Hence, other articles should be titled Access method (my favorite OS).

I'm still unhappy about the Access method article. In addition to the reasons above, I've learne dto be wary of artificially restricting the scope of an article title. For example while writing Evolution of mammals I found (via crurotarsal) that Suture covers only the surgical meaning of the term (stitches) but there are 3 other meanings (hard-parts anatomy, in skulls as well as ankles, and also in molluscs and arthropods; geological; and another that I've forgotten). The only good solution is to copy the content of Suture to and new article "Suture (surgical)" and make Suture a disambiguation page - which means current wikilinks to Suture should be updated. Restructuring the IBM operating systems articles will be a large, complex job anyway. I'd hate to leave open a risk that a further restructure might be needed if we artifically restrict the scope of "access method" - especially if we had to do the 2nd restructure!
I think the material I added to MVS covers IBM access methods in enough detail for the general reader. The next level of detail is much larger and involves quite technical stuff like why VSAM's distributed free space and control interval splits are superior to IBM ISAM's overflow areas, and why VSAM's index update mechanism is more secure than IBM ISAM's (the 2 topics would amount to an article in their own right). Philcha 11:36, 21 October 2007 (UTC)[reply]
See also my comments on File Management.

"IBM Mainframe File Management covering record-orientation, OS filename structure, IBM access methods, OS catalog and (briefly) VSAM catalogs". I strongly disagree. How does AM depend on filenames+cataloging? This is a parallel, distinct topic.

VSAM is both an access method and a catalog system - and master catalogs from MVS onwards have to be VSAM catalogs. Philcha 11:36, 21 October 2007 (UTC)[reply]

By the way do not forget Unit Control Block, it is a nice article and another parallel topic.

I think it would be a big mistake to go to that level of detail, because then we'd have to consider articles on over 30 types of OS/360 etc. control block plus a slightly smaller number for DOS/360 etc. plus various other internals such as PSW, System Mask, reltive priorities if first-level interrupt handlers, etc. (and no, I was never an operating system specialist). I can only suppose that someone added Unit Control Block to support a use of the term in 1 article. Philcha 11:36, 21 October 2007 (UTC)[reply]
  • VM

OK, let's move the structuring discussion on VM's talk page.

I've posted on all relevant Talk pages that I could find a request for comments and contributions to be routed through Talk: MVS.
While doing this I found another family we need to include - PARS, ACP, TPF and z/TPF. I don't know whether SABRE (developed by IBM starting 1957!) contributed any technology, but the others are an evolutionary succession. They have / had relatively few customers, but big enough for IBM to be supporting this family to-day. Philcha 11:36, 21 October 2007 (UTC)[reply]

--Kubanczyk 13:07, 20 October 2007 (UTC)[reply]

Philcha's notes on the plan 21 Oct 2007[edit]

As I said above, I think we should focus on Sys/360 operating systems and successors: it's big enough job; except for the CP/CMS group pre-360 operating systems were rudimentary and heterogenous. IBSYS is worth a mention as an example of how rudimentary they were. We probably should go back as far as M44/44X in the CP/CMS lineage, beccuase that group is an evolutionary succession and technologically important as the "virtual" component of the ../VS systems.

This suggestion (considering IBM M44/44X as part of the CP/CMS lineage) is troubling to me, and it illustrates one of the problems I see with this whole effort. Although I applaud the idea of restructuring these many related articles, there seems to be an element of reinventing history in order to place material in nice timelines. The M44/44X project, for example, definitely WAS an important source of input to the CP/CMS effort; but CP/CMS was definitely NOT a successor system in the sense that CP/67 was a successor to CP/40, or that VM/370 was a successor to CP/CMS. The projects were independent. The same goes for CTSS and the other systems that influenced the various CP projects. We might as well say that MULTICS and UNIX belong in the same family (and in a sense they do). We need to keep in mind that these articles a) must not create a new meta-perspective on operating system relationships that is not reflected in existing sources (violating NOR), and b) must provide appropriate levels of detail for the reader. Somebody interested in the history of CP/40 or M44/44X is probably not just interested in their role in the overall arc of IBM operating system development. I agree that a hierarchy of main/subordinate articles is important and helpful, as is the development of templates showing family relationships. I do NOT think we need to consolidate all of this material, some of which has interesting low-level detail quoted from printed sources, to create a mammoth narrative covering every system at the same level of detail. (I don't suggest that anybody is proposing this, but this is often the result of the "lumper" approach to taxonomy.) Trevor Hanson 22:19, 22 October 2007 (UTC)[reply]
We're not proposing massive lumping - the outline structure is a "logical" / "virtual" one which will be split over about as many articles as there are at present. And some articles will apply to more than one specf IBM op sys, e.g. Job Control Language. M44/44X, CP/40 and CP-67 are important because they provided the technology that made IBM's VM and ..VS.. operating systmes successful. They also show that in IBM's view (rightly or wrongly), there was a close connection between timesharing and vm technology. And the subordinate articles will contain "interesting low-level detail quoted from printed sources".
Please contribute or comment on the new content as it appears. Philcha 10:48, 23 October 2007 (UTC)[reply]

"Pre-360 operating systems were rudimentary" can be backed up by the existing operating system article, which is thorough enough for our present purposes.

Suggested title for the top article "IBM mainframe operating systems: System/360 and successors" - unless anyone can think of one that's shorter and equally clear.

I'd prefer to do memory management as part of an overview article - it's the main distinguisher between the DOS, MFT and MVT lineages. But I don't think it needs much more space than it takes in the current MVS article. So I think memory management should be part of "IBM mainframe operating systems: System/360 and successors".

Highest-level on the DOS series to be titled "DOS/360 and successors" for reasons presented above.

Notes for DOS/360 (system, not family):

  • "Core image library's full" halted development for hours at a time.
  • No relocating loader.
  • Initially no multi-programming.

We need an article on DOS/VS (1970s), to explain one of the biggest changes in the DOS series - VS, relocating loader, POWER spooler.

"Dataset" is just IBM-speak for file, not worth an article. Data set (IBM mainframe) is poorly scoped and structured - e.g. explains PDSs and the DSORG sub-parameter of the DCB parameter of the DD statement in OS JCL, but nothing about access methods.

I have begun this but have not had time to add detail. Ccalvin 17:38, 29 October 2007 (UTC)[reply]

We need an article "File management" (access methods, file names hierachical but not a true directory structure, catalogs including VSAM catalog) - one topic since VSAM pulls them together. At present I think one article will be enough for DOS and OS groups. I don't know enough about CMS (within VM). So at present I'd place it at the 2nd level (below IBM mainframe operating systems: System/360 and successors"), but CMS might force a change.

I'm not sure about articles on individual IBM access methods, as: I think the current version of MVS says enough for the general reader about file access methods; likewise I think IBM Systems Network Architecture says almost enough for the general readr about VTAM. I suggest 2 articles: IBM file access methods (SAM, ISAM, VSAM and PDS); IBM communication access methods (BTAM, QTAM, TCAM, VTAM).

I'd prefer to cover JES2 and JES3 as part of MVS, since they were only parts of MVS and successors. The content needs an upgrade, since it misses the most important apsect of JES3, "single system image" (one operator could manage a roomful of loosely-coupled CPUs, each with its own copy of MVS). Philcha 12:37, 21 October 2007 (UTC)[reply]

I think we need an article on the OS family (MFT, VS1, MVT, MVS, ...z/OS), as they presented the same interface (JCL, utilities, Assembler macros) to the programmer.

Perhaps one article on MFT and VS1 together would be enough, as VS1 was just MFT with paging and was relatively short-lived. If so, main title "OS/MFT and OS/VS1", redirects from "OS/MFT" and "OS/VS1". But that only works if we also have an overview article on the whole OS family (MFT, VS1, MVT, MVS, ...z/OS).Philcha 12:55, 21 October 2007 (UTC)[reply]

I agree with "Some harsh merging needed for overlapping History of CP/CMS, CP-67, CP/CMS, VM (operating system)". We'll have be careful as ther's some very good contnet. The highest-level article in this group should also mention IBM M44/44X. Philcha 13:12, 21 October 2007 (UTC)[reply]

The TPF section probably requires more than 1 article as it had predecessors: PARS and ACP. We should also check whether SABRE made any technical contribution. Philcha 16:23, 21 October 2007 (UTC)[reply]

Again, I would like this discussion focused right now on: proper article names, moves, merges. For me it is not logical to introduce new content, when the structure is broken.
I agree about names / moves / merges being essential, but we need to document what content goes where - including new content where one of us has seen gaps.
To proceed with renaming, we really need a neat naming convention for "line" articles, alternatives are: "XXX and YYY and ...", "XXX and successors", "History of XXX", "Evolution of XXX", "XXX line", "XXX family". You seem to like "XXX and successors" so, let's agree on it and start with the rename propositions.
IBM mainframe operating systems: System/360 and successors - a bad name for an article. We are not developing SQL query here. As this is not a "line" article (it's a "set of lines"), we should stick to the simple History of IBM mainframe operating systems. If somebody will add a pre-S/360 subsection - that's even better.
"We are not developing SQL query here" had me ROFL. Nice way to make a point! OK, "History of IBM mainframe operating systems" is the top level. As well as being more user-friendly, it allows for the fact that IBM's time-sharing experiments started on the 700 series. We may have to split out the "360 and later" section if it gets too long, but we'll worry about that IFF it happens.
"Dataset is just IBM-speak for file, not worth an article. Data set (IBM mainframe) is poorly scoped and structured" - hmmm, but look - the article exists in Wikipedia, looks like it was needed, wasn't it? And I think it is pretty useful now. Also, in Wikipedia you have to stay sourced, you cannot pursue the term "file" or "file management" if majority of the sources (esp. IBM's) uses "data set".
OK, I see the point re Data set (IBM mainframe) - it's implicitly contrasted with e.g. Unix's "bag of bytes" view, and I think Data set (IBM mainframe) should make that explicit, when we get to it.
I've just remembered: IBM DOS/... manuals talk about "files", not "datasets", which means "dataset" was just some OS developers trying to sound scientific. So I prefer "file" as the more widely-understood term. Philcha 10:38, 23 October 2007 (UTC)[reply]
I agree on merging JES2/3 to MVS. --Kubanczyk

21:19, 21 October 2007 (UTC)

I think we've agreed enough to start writing, and should start before anybody else creates an article titled "History of IBM mainframe operating systems". We'll have to do it in strictly top-down fashion, so we can see and resolve as early as possible any other structure issues that pop up. When we're happy with a coherent chunk, we can turn into redirects any articles whose structure ot title doesn't fit (e.g. the existing articles about time-sharing OSs).
I suggest the top-level article has an under construction tag for a while as we still have to agree a detailed structure for IBM's early time-sharing systems and for the PARS-ACP-TPF group. We could temporarily link to CP-67, which has a family-tree of the early time-sharing systems, and to Programmable Airline Reservation System for the PARS-ACP-TPF group.
In fact I've just created a skeleton version of History of IBM mainframe operating systems to reserve the name for our little project.
BTW we should also insert into History of IBM 1 or more links to History of IBM mainframe operating systems. Philcha 13:35, 22 October 2007 (UTC)[reply]
Glad to read that, I'll start tomorrow. --Kubanczyk 17:22, 22 October 2007 (UTC)[reply]

The plan[edit]

An important point is: there is Wikipedia:Summary style guideline, which I find to be the best in such cases. It builds a hierarchy of articles: Summary->Subordinates. Second important point: articles should be long and interesting per WP:NOT#DICT (presently there are too many short ones). Now, in the first stage let's focus exclusively on moves, merges, splits, and having precise article names. Second phase is writing any new text, creating new stubs or redirects.

Anyone, please feel free to improve this hierarchy in place, Wiki saves historical versions of page. Please discuss your improvements above, not here, to keep the picture clear.

Again, discussion for the plan is in the section above.

The living version of the articles' hierarchy plan is now in the Template:History of IBM mainframe operating systems. --Kubanczyk (talk) 10:44, 25 November 2007 (UTC)[reply]

Refs for use when appropriate[edit]

  • Mealy, G.H., et al. The functional structure of OS/360. IBMSJ, Vol. 5, No. 1, 1966
  • [http://www.research.ibm.com/journal/rd43-56.html
  • Pugh, Emerson (1991). IBM's 360 and Early 370 Systems. Cambridge MA: MIT Press. pp. 362–265, 596. ISBN 0-262-16123-0. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Session O441 - The History of HASP and JES2 part of collection of SHARE (IBM user group) papers.

Philcha 15:09, 24 October 2007 (UTC)[reply]

Structure of History of IBM mainframe operating systems[edit]

Hi, would you mind if I edit History of IBM mainframe operating systems? I don't like the current structure at all. On the other hand if you already have a larger plan in your head for the article, I don't want to disrupt it. Please reply here. --Kubanczyk 10:32, 24 October 2007 (UTC)[reply]

Sorry to hear you don't like the way the structure of History of IBM mainframe operating systems is developing - and we (naively?) thought we had agreed it.
Of course you're free to edit - any one is, and especially you're part of this "project".
Perhaps I should explain why I've (part-)written it as I have:
  • I suspect the big issue is whether the structure should be chronological or thematic (e.g. DOS/360 and successors, OS/MFT and successors, etc.). I've gone for chronological because:
    • There's no real theme for pre-360 OSs, such as they were.
    • IBM was running on 2 tracks in the mid-1960s, experimental timesharing / virtual machine systems and OS/360. These merged when IBM announced the ../VS.. systems in the early 1970s, but in a rather mixed-up order which makes a thematic approach harder to follow: DOS/VS, OS/VS1, OS/VS2 (SVS), VM/370, MVS.
    • But it might be best to go for a thematic approach to the successors of DOS/VS, MVS and VM/370, especially as they were less tied to new hardware announcements. Switching at this point will be easy enough to folow and we can make it explicit by pointing out that by this stage (mid-1970s onwards) IBM had all the pieces in place. —Preceding unsigned comment added by Philcha (talk • contribs) 12:49, 24 October 2007 (UTC)[reply]
  • However hard we try to summarise, History of IBM mainframe operating systems will be large, because it has to pull a lot of material together - and we haven't even started on pre-360.
  • I placed "early timesharing and virtual machine systems" before any System/360 content because: chronologically it started earlier, and on non-360 hardware; it's interesting that IBM was moving on 2 parallel tracks in the mid-1960s; IBM offered CP-67 to large customers while OS/MVT was still rather immature and AFAIK did not yet include TSO.
  • The reasons for IBM's commiting to System/360 need to be explained, especially considering how traumatic the 360 project turned out to be (and I haven't mentioned hoew stressful the hardware aspects were, but that's in some of the docs cited).
  • Why they were much more complex thna perious IBM OSs helps to explain why there was so much trauma, and why IBM released stop-gaps.
  • The bit about TP monitors is really a footnote whose final position I would expect to change. Bbut it illustrates the point about how batch-oriented 360 was.
  • The part about DOS/360 is longer than I'd lke it to be, and I expect to move some of it as we get into the more detailed articles. But I'd like to keep the limitations of DOS/360 here because it helps to explain why successors had the enhancements they had (and incidentally stimulated the growth of 3rd-party systems software products - GRASP, at least 5 independent TP monitors - which were important from the late 1960s onwards).

I currently plan to add:

  • Overview of the common aspects between OS/MFT and OS/MVT - API, JCL, utilities, etc.
  • OS/MFT-specific stuff - not much, mainly fixed memory partitions. Have move to this point the comment about "not less than 256K". Since the "256K" note has a citation, please don't delete it.
  • OS/MVT: variable-sized "regions", TSO.
  • Early airlines-specific systems. I expect later ones as well, but don't yet know the chronology.
  • 360/20 is a separate sub-section because 360/20 was not program-compatible with the other 360 CPUs, so had a different OS. It has no further chronology becuase 360/20 was succeeded by the System/3 business-oriented minicomputer.Philcha 12:40, 24 October 2007 (UTC)[reply]
To repeat myself, I don't want to disrupt your train of thoughts. As this seems to be the case - please proceed as you intended. As soon as you remove {{undercontruction}}, or stop editing for about a week (?), I will know that I can proceed in a normal Wiki way. --Kubanczyk 12:56, 24 October 2007 (UTC)[reply]

Where do we go from here?[edit]

I've added as much as I think this article should contain. It now covers: pre-360; timesharing OSs, including the "independents" (VP/CSS, MUSIC, MTS); "mainstream" System/360 and System/370 OSs; ACP and descendants; the System/360 "oddballs" (360/20 and 360/44). IMO once we get to DOS/VS, OS/VS1, MVS and VM/370 we have groups of IBM OSs that continue to today, and the rest is just enhancements. I suggest the details should be presented in other articles:

  • DOS/360 and successors, up to z/VSE;
  • OS/360 and successors, up to z/OS. I'd inlude both the MFT-VS1 and MVT-SVS-MVS lineages in this, as the main differences between these lineages are memory management and TSO - APIs, JCL and datamanagement are almost identical;
  • VM/370 and successors, up to z/VM;
  • ACP and successors, up to z/TPF;

possibly with separate articles on the latest versions (z/VSE, z/OS, z/VM, z/TPF).

We also need to tidy up the set of articles on CTSS, CP-49, CP67, etc. - as noted above, some ruthless merging is needed.

Then we should think about how to fit in more detailed articles about specific subjects such as SNA and VSAM.Philcha (talk) 17:26, 19 November 2007 (UTC)[reply]

I agree on the "other articles" part. I'd like to remind, that the initial idea was to transform what already exists, so for example rename OS/360 to summary-styled OS/360 and successors, instead of writing from scratch. In fact, I see some detailed stuff on this page that could quite happily land in OS/360 and successors or DOS/360 and successors, too.
Another thing—when adding new articles please use and update the (terribly long) navigational template as needed. --Kubanczyk (talk) 20:43, 19 November 2007 (UTC)[reply]
I agree re "some detailed stuff on this page that could quite happily land in OS/360 and successors or DOS/360 and successors". In fact I think that the existing articles on MFT, OS/VS1, MVT, SVS, MVS etc. should be changed to redirect to OS/360 and successors because they are all so similar except in: memory management; TSO in MVT and successors; VSAM master catalog in MVS and successors. The significant difference not covered in that list of exceptions is system configuration and management (multiprocessors, sysplexes, etc.) I'm not sure how deeply we should go into that for the obsolete OSs, but we probably should for z/OS, and I think that probably leads to a separate article for z/OS. Similarly for DOS/360 etc. and VM/370 etc. - and also with separate articles for the current members of the other lineages. Then we can tweak the amount of content in History of IBM mainframe operating systems until there's just enough to explain the differences between the DOS/360, OS/360 and VM/370 lineages, and the major differences between members of each lineage. After that we can see how much we need to re-factor material about e.g. IBM access methods.
And yes I'll update the nav template (which might become shorter as a result of what I've just proposed).
I've just realised that what I've proposed implies an article "IBM's virtual machine operating systems", which would start with one of CTSS, 44X/44M or CP-40 and include CP-67, VM/370, VM/... and z/VM; plus a separate article on z/VM. What do you think? Philcha (talk) 20:18, 20 November 2007 (UTC)[reply]

Remove first para?[edit]

The current first paragraph is vey questionable:

One could argue that other OSs were at least as important: GM-NAA I/O (1956; first OS used for real work); Burroughs' MCP (1962; first virtual memory system released for general use); CTSS (first virtual machine & timesharing OS). Philcha (talk) 22:52, 20 November 2007 (UTC)[reply]

Wikipedia rules: "it seems false & it is unsourced => delete at will".
I've made a very simple correction to this sentence. Might help. It doesn't matter if other OSes alone were better or more innovative. The reason is: IBM provided most of the mainframe computers (hardware). Some OSes were commonly used to run the hardware. IBM hardware notable => OSes notable too. --Kubanczyk (talk) 23:52, 20 November 2007 (UTC)[reply]

Intro: Recent edit by User:BBCWatcher[edit]

User:BBCWatcher recently edited the intro - see [2]. I'm happy with the word "arguably" but not the rest, and particularly not with ".. in many innovative ways". What do others think? Philcha (talk) 12:44, 31 December 2007 (UTC)[reply]

I've rephrased bits of the intro. Philcha (talk) 11:09, 9 January 2008 (UTC)[reply]

BTAM[edit]

In section "OS/360", "data communications" was changed to "telecommunications". I have changed it back to "data communications" because this is more accurate: "telecommunications" includes voice, fax, etc. as well as data; "telecommunications" means "long-distance communications", but BTAM could support locally-attached terminals. Philcha (talk) 11:03, 9 January 2008 (UTC)[reply]

References for summary sections?[edit]

I've made some changes in the descriptions of OS/360, OS/VS1, OS/VS2 Release 1 (SVS) and MVS. These are all summary sections linked to main articles that have more detail. Is it appropriate to include references here to justify those changes, or do they belong only in the main articles? Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:42, 22 November 2010 (UTC)[reply]

360/44[edit]

Wasn't there a specialized OS for the 360/44? The "Model 44 Programming System" comes to mind. Would this be listed under "specialized systems?" Peter Flass (talk) 12:44, 12 July 2011 (UTC)[reply]

Yes, and History of IBM mainframe operating systems#System/360 Model 44 mentions it. Catalog of Programs for IBM System/360 Models 25 and Above has a brief description; the program number is 360F. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:44, 8 November 2011 (UTC)[reply]

TSS[edit]

I see TSS gets a brief mention, I believe it deserves a separate section. Peter Flass (talk) 12:18, 23 October 2012 (UTC)[reply]

Thrashing[edit]

Section: Early time-sharing and virtual machine systems - "learned how to make the thrashing problem negligible." Is it really "negligible", or did it learn "how to reduce the problem of thrashing" (or "minimize")? Peter Flass (talk) 12:26, 23 October 2012 (UTC)[reply]

In my personal experience, it could be minimized but never to the point of being negligible, especially with a large (and unpredictable) interactive user load on, say, CMS. I'm certainly not a reliable source, but you made a good catch here. — UncleBubba ( T @ C ) 14:28, 23 October 2012 (UTC)[reply]
Not in early time-sharing systems; it was only with the drastic drop in RAM prices that thrashing became negligibile rather than merely manageable. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:51, 25 October 2012 (UTC)[reply]
OK, "manageable" it is. Peter Flass (talk) 16:31, 31 October 2012 (UTC)[reply]

Use of term server for CICS et al[edit]

No, the term server was not used for CICS in the early days. CICS and IMS are still in use, so is it relevant whether the term was originally used or only whether it is used now? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:31, 20 November 2012 (UTC)[reply]

It's relevant only to the question of whether to use a pipe in the link to transaction processing system to have the link say "transaction server" or not. My inclination is not to use "server", even if CICS has been re-branded a "transaction server", as calling it a "transaction server" in a sentence discussing its introduction is a bit of a recentism, and not calling it a "server" might encourage people who have never heard of Big Datacenter Machines called anything other than "servers" to follow the link and learn a bit of history. Guy Harris (talk) 00:30, 21 November 2012 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on History of IBM mainframe operating systems. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:45, 25 May 2017 (UTC)[reply]

I found an alternative site (the Denning Institute) for the Denning paper, and redid that reference to use {[cite journal}}. The other link works, although they're two references to the same article, so I combined them. Guy Harris (talk) 19:06, 25 May 2017 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 5 external links on History of IBM mainframe operating systems. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 18:11, 4 November 2017 (UTC)[reply]

DOS nomenclature[edit]

I vaguely recall that somewhere between DOS/360 and DOS/VS, IBM briefly changed the name to DOS/370, although Bitsavers has some transitional DOS manuals with neither 360 nor 370 in the title. Does anybody have a timeline for the various names?

Between DOS/VSE and VSE/SP theree were several addons for DOS/VSE, e.g., VSE/AF. Does anybody have a timeline for those? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:29, 5 January 2018 (UTC)[reply]

FWIW I have no recollection of anything between DOS and DOS/VS. Of course my last DOS release was 21.x. Peter Flass (talk) 22:59, 5 January 2018 (UTC)[reply]

Fedora OS Should Be considered as part of the IBM Operating Systems list[edit]

https://www.cnbc.com/2018/10/28/ibm-is-reportedly-nearing-deal-to-acquire-red-hat.html https://uk.reuters.com/article/uk-red-hat-m-a-ibm/ibm-nears-deal-to-acquire-cyber-security-company-red-hat-sources-idUKKCN1N20N5


https://www.redhat.com/en/about/press-releases/ibm-acquire-red-hat-completely-changing-cloud-landscape-and-becoming-world%E2%80%99s-1-hybrid-cloud-provider


As of October 2018 theres talks that the owners of Fedora (Red Hat Inc) is merging with IBM.

— Preceding unsigned comment added by 2601:640:C600:8270:A563:D5B6:732C:339A (talk)

It's called "Linux"; the article says "Both IBM-supplied operating systems and those supplied by others are discussed here, if notably used on IBM mainframes." in the third paragraph, so is there any reason to mention Linux distributions from IBM (if they buy Red Hat) but not Linux distributions from others, or just mentioning Linux as a whole?
Furthermore, IBM may be supplying Red Hat Enterprise Linux, rather than Fedora, as their "standard Linux".
And the article should mention other UNIX-like systems as well, if it's to be a full history. Guy Harris (talk) 21:10, 28 October 2018 (UTC)[reply]
Is there any reason to believe that IBM is backing off from SUSE Linux Enterprise (SLE)? Nor are Red Hat Enterprise Linux (RHEL) and SLES the only Linux distributions that run on z. OTOH, I believe that OpenSolaris for System z is defunct. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:10, 30 October 2018 (UTC)[reply]

CTSS origin[edit]

History of IBM mainframe operating systems#Early time-sharing and virtual machine systems states MIT's Fernando Corbató produced the first experimental time-sharing systems, such as CTSS, from 1957 to the early 1960s, using slightly modified IBM 704 and IBM 7090 mainframes; however, Compatible Time-Sharing System states CTSS was first demonstrated on MIT's IBM 709 in November 1961;. Is the reference to the 704 incorrect? Was there a time sharing system on the 704 prior to CTSS? 03:26, 18 April 2021 (UTC)Shmuel (Seymour J.) Metz Username:Chatul (talk)

704 and 7090, but not 709, and not 7094? Perhaps they meant "slightly modified IBM 7090 and 7094 mainframes", especially given that the Additional Core Storage and IBM 7090-7094 Multiprogramming Package RPQs done for CTSS are listed as being for the 7090 and the 7094 (and *not* for the 704 or 709). (I thought I'd seen the "Core Storage Clock and Interval Timer" RPQ document, L22-6554-2, on Bitsavers, but I can't find it there; presumably that one adds a timer to generate interrupts to do time-slicing.) Guy Harris (talk) 05:55, 18 April 2021 (UTC)[reply]
The reference that Compatible Time-Sharing System gives for CTSS originally running on a 709, Compatible Time-Sharing System (1961-1973) Fiftieth Anniversary Commemorative Overview, corroborates that.
The 709 was slightly modified:

Corby states that he began talking with Marge Daggett (then Marge Merwin) and Bob Daley of the Computation Center staff about the system design in the spring of 1961, and the original demonstration was working by November of that year. They got IBM to provide an interrupt capability for the machine (an off-the-shelf change) which allowed them to take control of the machine. They created a special version of the operating system (which came to be known as CTSS). This operating system set aside 5 kilowords of memory (of 32kw total) for the time-sharing supervisor (and for buffering typewriter terminal input and output). Herb Teager had made four Flexowriters into special terminals, and these would work with the IBM 709. CTSS used tape drives to store the programs and files of the users of the four terminals. It was crude, but that was the original configuration for the desired demonstration of interactive computer use, and it allowed the traditional batch processing system to still operate (that was the “compatible” part of Compatible Time-Sharing System). Corby wrote the now famous first CTSS paper, with Daggett and Daley listed as co-authors,5 in January 1962 for presentation in May 1962.

Section 4, "Memories and views of CTSS", quotes Corbató as saying "My recollection is that it was at one of those Meetings in 1959 that John McCarthy presented to Morse his memo outlining the three key changes (RPQ’s) that would make the IBM 709 suitable for timesharing." I presume that the memo in question is "A Time-Sharing Operator Program for our Projected IBM 709". However, the memo starts out saying "This memorandum is based on the assumption that MIT will be given a transistorized IBM 709 about July l960.", so it sounds as if he's proposing changes to the IBM 709T(ransistorized), pronounced exactly as you'd expect :-) (i.e., it was proposing changes to what was eventually the 7090). The only modifications McCarthy appears to be proposing are 1) "An interrupt feature on the computer", 2) "Changing the stop instructions to trap instructions.", 3), "Providing a real time alarm clock as an external device.", and 4) optionally providing "a memory range trap"; he appears to propose relocation being done by the operating system at program load time. The RPQs IBM ultimately provided include changes that amount to base-and-bounds registers (it's a little different, in that the "bounds" registers apply to addresses after relocation by the "base" register), so the relocation could be done in hardware.
I don't know what modifications were done to the 709; I presume the 7090 and 7094 ultimately had all the RPQs.
My inclination is to eliminate any mention of the 704, although McCarthy mentions it in passing ("Changing the stop instructions to trap instructions. This is a minor modification to the machine. (At least it will be minor for the 704.)" and "Experiments with using the flexo connection to the real-time package on the 704 will help but we cannot wait for the results if we want a time-sharing operator program in July l960."), and mention the 709, 7090, and 7094 (I'm guessing that the reference to a 709 was to a vacuum-tube 709, not to a 709T. Guy Harris (talk) 06:37, 18 April 2021 (UTC)[reply]
I'm guessing that "the now famous first CTSS paper" is "An Experimental Time-Sharing System"; it also mentions the 709 only in passing:

To avoid memory allocation clashes, protect users from one another, and simplify the initial 709 system organization, only one user was kept in core memory at a time. However, with the special memory protection and relocation feature of the 7090, more sophisticated storage allocation procedures are being implemented. In any case, user swaps are minimized by using 2-channel overlapped magnetic tape reading and writing of the pertinent locations in the two user programs.

so it sounds as if the 709 had only minimal modifications, with the 7090 having two modifications:

Also installed on the 7090 are two special modifications (i.e. RPQ's): a standard 60 cycle accounting and interrupt clock, and a special mode which allows memory protection, dynamic relocation and trapping of all user attempts to initiate input-output instructions.

with the first of those presumably being the "Core Storage Clock and Interval Timer" RPQ and the second of those presumably being the "IBM 7090-7094 Multiprogramming Package" RPQ. The "Additional Core Storage" one came later. It sounds as if swapping to disk, and supporting a file system on disk, also came later. Guy Harris (talk) 06:49, 18 April 2021 (UTC)[reply]
McCarthy's "Reminiscences on the History of Time-Sharing" mentions a proposal to add an interrupt facility to a 704:
My first attempts to do something about time-sharing was in the Fall of 1957 when I came to the M.I.T. Computation Center on a Sloan Foundation fellowship from Dartmouth College. It was immediately clear to me that the time-sharing the IBM 704 would require some kind of interrupt system. I was very shy of proposing hardware modifications, especially as I didn't understand electronics well enough to read the logic diagrams. Therefore, I proposed the minimal hardware modification I could think of. This involved installing a relay so that the 704 could be put into trapping mode by an external signal. It was also proposed to connect the sense switches on the ccnsole in parallel with relays that could be operated by a Flexowriter (a kind of teletype based on an IBM typewriter).
When the machine went into trapping mode, an interrupt to a fixed location would occur the next time the machine attempted to execute a jump instruction (then called a transfer). The interrupt would occur when the Flexowriter had set up a character in a relay buffer. The interrupt program would then read the character from the sense switches into a buffer, test whether the buffer was full, and if not return to the interrupted program. If the buffer was full, the program would store the current program on the drum and read in a program to deal with the buffer.
It was agreed (I think I talked to Dean Arden only.) to install the equipment, and I believe that permission was obtained from IBM to modify the computer. The connector to be installed in the computer was obtained.
but it doesn't sound as if that change was made. Instead, McCarthy speaks of an existing RPQ for the 704, done for Boeing, which included support for an external interrupt that could occur at any time:
However, at this time we heard about the "real time package" for the IBM 704. This RPQ (request for price quotation was IBM jargon for a modification to the computer whose price wasn't guaranteed), which rented for $2,500 per month had been developed at the request of Boeing for the purpose of allowing the 704 to accept information from a wind tunnel. Some element of ordinary time-sharing would have been involved, but we did not seek contact with Boeing. Anyway it was agreed that the real time package, which involved the possibility of interrupting after any instruction, would be much better than merely putting the machine in trapping mode. Therefore we undertook to beg IBM for the real time package. IBM's initial reaction was favorable, but nevertheless it took a long time to get the real time package - perhaps a year, perhaps two.
Corbató's paper, on the other hand, speaks of running CTSS on the 709, and doesn't mention the 704 at all. The CTSS 50th anniversary commemorative overview also speaks of CTSS initially running on the 709, and mentions the 704, but not as a platform for CTSS.
So perhaps there's confusion somewhere. Perhaps the 704 was used for a very early prototype not called CTSS, and then went on to the 709, and then the 7090. Perhaps McCarthy meant the 709, although the IBM 709 page says it was announced in 1957 but was first installed (somewhere, not necessarily MIT) in August 1958, in which case it wouldn't have been there in the fall of 1957. Perhaps Corbató and company meant the 704, but the Corbató paper and the commemorative overview saying "709" make that seem unlikely. Guy Harris (talk) 07:57, 18 April 2021 (UTC)[reply]

There was an operating system for commercial work on the 1410/7010[edit]

While it is true that almost all of the IBM operating systems for machines prior to the S/360 were intended for scientific and commercial workloads, the 1410/7010 Operating System (1410-PR-155) was intended for commercial workloads. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:43, 23 February 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:History_of_IBM_mainframe_operating_systems&oldid=1202731114"