Talk:History of IBM mainframe operating systems

From Wikipedia, the free encyclopedia

Contents

[edit] Discussion leading to creation of the article

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)

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)

[edit] Need to restructure IBM operating system articles?

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)

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)

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

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.

  • Absolute top of article hierarchy: IBM mainframe operating systems a summary introducing those subordinate articles:
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.
    • Text to write
    • BOS/360 and TOS/360
      • Exist
    • DOS/360 line a summary introducing those subordinate articles:
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.
      • Move DOS/360 here and upgrade to Summary Style
      • Job control language (DOS)
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".
        • Text to write
      • IBM DOS/360 utilities
        • Text to write
      • DOS/VSE
        • Exists
      • z/VSE
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.
      • Move OS/360 here and upgrade to Summary Style
      • Memory management in OS/360 line
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.
        • Exists
        • Single Virtual Storage, aka OS/VS2 Release 1
          • Text to write
      • MVS
        • Exists
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.
    • CP/CMS line
      • Move CP/CMS here and upgrade to Summary Style
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)

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

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

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

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

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

"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)

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)

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)

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)

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)

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)
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)
Glad to read that, I'll start tomorrow. --Kubanczyk 17:22, 22 October 2007 (UTC)

[edit] The plan

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)

[edit] Refs for use when appropriate

Philcha 15:09, 24 October 2007 (UTC)

[edit] Structure of History of IBM mainframe operating systems

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)

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

[edit] Where do we go from here?

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)

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

[edit] Remove first para?

The current first paragraph is vey questionable:

“ The history of IBM mainframe operating systems is the most important chapter of history of mainframe operating systems, because of IBM's long-standing position as the world's largest supplier of mainframe computers. ”

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)

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)

[edit] Intro: Recent edit by User:BBCWatcher

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)

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

[edit] BTAM

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)