Talk:OS/360 and successors

Comments

Potential editors may find user:Chatul/References to be of use. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:07, 27 June 2010 (UTC)

The first few threads have been copied from Talk:OS/360 as OS/360 is now redirected to OS/360 and successors.

A disaster?

I don't think it's wholly unreasonable to tag this with Category:Software engineering disasters - although now that I look at the contents of that category, I'm reconsidering! It was extremely late, extremely over-budget, extremely over-sized - you name it, along almost every axis it was a nightmare. A smaller company might have been sunk by such a problem - and many were, by smaller ones! Brooks himself had to step down from running the entire System/360 project to overseeing OS/360 to try and pull their irons out of the fire. Yes, it eventually got going, and was not too bad - but as Milo Medin's saying goes, "with enough thrust, anything will fly". Noel (talk) 03:49, 17 August 2005 (UTC)

I have no idea what you are talking about. Sam Tomato (talk) 02:03, 2 May 2017 (UTC)

Restructure of articles about IBM mainframe operating systems

After a big edit of MVS I concluded that the whole set of articles about IBM mainframe operating systems from System/360 onwards needed to be re-structured to minimise overlap and to make clearer the evolutionary relationships between these operating systems (notably in memory management, which is historically a major distinguishing feature). There is already some support for this proposal. Please add comments at Talk: MVS. Philcha 23:56, 20 October 2007 (UTC)

The idea of merging this article with "OS/360 and successors" denies the importance of MVS (and others of its kind - DOS/VSE for instance). Each operating system should have its own page - I see nothing wrong with this page existing standalone as it does now, and think it should.  DavidDouthitt  (Talk) 16:37, 24 November 2009 (UTC)

Rewrite of Job Control Language in progress

As part of the proposed restructure of articles on IBM mainframe operating systems (above), I've rewritten Job Control Language to: cover IBM's DOS/360 and its descendants as well as OS/360 and its descendants; focus more on the facilities and flavour of the 2 JCLs rather than on details of some statement types and some of their options. Please comment in Talk: Job Control Language. I'd be particulary grateful for more info on DOS/360 and its descendants, especially after 1980 - I only used DOS JCL a handful of times, and only in the late 1970s.

The rewrite does not currently take account of Truthanado's point in Talk: Job Control Language about use of "JCL" by computer suppliers other than IBM, which may entail further restructuring of articles about JCLs.Philcha 00:00, 21 October 2007 (UTC)

Merge with OS/360

Per discussion in Talk:History of IBM mainframe operating systems: proposition was to move OS/360 to a better name OS/360 and successors. No need for two articles with almost exactly the same topic. --Kubanczyk (talk) 15:39, 24 November 2007 (UTC)

Oops, I thought I'd made OS/360 redirect to OS/360 and successors. Must have forgotten click "Save". I'm doing it now. Philcha (talk) 15:45, 24 November 2007 (UTC)

Not too great. To remind you, the normal process of changing a page name is through a "move" function. There is a help there, which also explains why what you have done is not advisable. --Kubanczyk (talk) 16:11, 24 November 2007 (UTC)

Thanks, will use "move" in future. Philcha (talk) 17:52, 25 November 2007 (UTC)

Variants of OS/360

IBM maintained for a while that PCP, MFT and MVT were just different configurations of the same kernel (OS/360 Introduction), but that is not technically credible:

• PCP (one job at a time) needs only one set of all the control blocks needed to define a job, and no precautions against 1 job interfering with another (memory, files, etc.).
• MFT needs a fixed number of sets of control blocks; and needs precautions against inter-job interference.
• MVT needs to allocate an indefinite number of sets of control blocks dynamically; and needs the precautions against 1 job interfering with another. Dynamic allocation means the top-level control blocks of each job will be scattered around in memory and therefore need to be linked list; while in MFT a simple fixed-length array would suffice.

In fact IBM gave the game away - OS/360 Introduction says "there are two configurations of the [OS/360] control program: ..." (MFT and MVT), which admits that PCP was different.

I'll rephrase accordingly. Philcha (talk) 22:02, 25 November 2007 (UTC)

Clarify, what are you talking about? What game? My previous point was not to force OS/MxT names too much, that's all. At least not without explaining to a reader that those were neither separate OSes or separate releases. It is per official creator's docs. --Kubanczyk (talk) 22:48, 25 November 2007 (UTC)

"there are two configurations of the [OS/360] control program: ..." (MFT and MVT) implicitly admits PCP was different; if PCP was just another configuration of the same kernel, OS/360 Introduction should have said "there are three' configurations of the [OS/360] control program: ..." Re MFT and MVT note at the wording in the article - "IBM maintained that ..." is very neutral. Philcha (talk) 17:41, 26 November 2007 (UTC)

Is this by any chance your original research? --Kubanczyk (talk) 00:23, 27 November 2007 (UTC)

The reasoning about the control blocks is, but the quote is from [OS/360 Introduction and clearly excludes PCP. Another IBM doc (ref in article) describes MFT and MVT as "separate versions". Philcha (talk) 07:54, 29 November 2007 (UTC)

When discussing the status of various OS/360 options it is important to pay attention to the release that the manuals you are reading from are for. In particular, GC28-6534-3 ia for Release 21, after IBM had dropped support for PCP. Look at, e.g., the Release 13 manuals. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:20, 20 November 2011 (UTC)

Merge with MFT (operating system)

Support, but let's wait a while for another opinion. --Kubanczyk (talk) 23:04, 25 November 2007 (UTC)

Merge with OS/VS1

Oppose keep it as subordinate per Wikipedia:Summary Style; there is very specific info on that article; it would feel awkward on this page. --Kubanczyk (talk) 23:04, 25 November 2007 (UTC)

Support The amount of OS/VS1 info that isn't already in OS/360 and successors is very small: number of releases; the expansion pack to support new disks; withdrawal anouncement & MVS migration aid. OS/360 and successors already presents more info about OS/VS1 but concisely because it builds on the info about MFT. Philcha (talk) 09:34, 26 November 2007 (UTC)

Merge with MVT

Support, but let's wait a while for another opinion. --Kubanczyk (talk) 23:04, 25 November 2007 (UTC)

Support; the three variations of OS/360 can reasonably be talked about together, as the basic hardware architecture supporting them is the same. Pemungkah (talk) 01:04, 17 April 2010 (UTC)

Support merging PCP, MFT, MFT II and MVT, contingent on cleaning up the text. In particular, it should be noted that a large amount of code is common to all three (four if you count 65MP) versions and that they were all shipped on the same tapes. Much of the code unique to MFT was replaced with MVT equivalents as part of MFT II.

Comments elsewhere refer to IBM not mentioning PCP in particular manuals, but the editions cited were after IBM had dropped support for PCP. Shmuel (Seymour J.) Metz (talk) 14:59, 28 May 2010 (UTC)

Merge with MVS

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result was no merge. -- Salix (talk): 04:34, 2 October 2010 (UTC)

---

Strong oppose keep it as subordinate per Wikipedia:Summary Style; there is very specific info on that article; it would feel awkward on this page. --Kubanczyk (talk) 23:04, 25 November 2007 (UTC)

I suggest the best way to resolve this is to look around and see if there's much more to MVS/XA, MVS/ESA and OS/390 than the current Wikipedia articles state:

• If there is a lot more, then I suggest we merge MVS/XA, MVS/ESA and OS/390 into MVS. I don't think it's useful to have many duplicated descriptions of multiple virtual address spaces, VSAM catalogs, tightly-coupled muiltiprocessing and JES2 and JES3.
• If there is not a lot more, we should merge all MVS versions and OS/390 into OS/360_and_successors
• Either way, keep z/OS separate. Philcha (talk) 12:12, 28 November 2007 (UTC)

Notes for MVS/XA (Google shows very few relevant hits for "MVS/XA" in 1st 100 hits):

• [1] gives a lot of info and looks written by a competent author, but author name not given (Thierry Falissard, I think) and no guarantee that it will be around in 5 years.
• IBM's [2] outlines the change in address space size.

Notes for MVS/ESA:

• [3] gives a lot of info and looks written by a competent author, but author name not given (Thierry Falissard, I think) and no guarantee that it will be around in 5 years.
• ESA designed to ease I/O bottlenecks
• Industry comments on ESA
• ESA memory management - very technical and written from the point of view of CICS
• MVS/ESA OpenEdition DCE: Application Development Cookbook summary page, details in linked PDF
• The facilities and evolution of MVS/ESA IBMSJ - summary page, details in linked PDF

Notes for OS/390:

• IBM announces OS/390
• IBM announces end of support]

Philcha (talk) 13:10, 28 November 2007 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Merge with MVS/XA

Better merge with MVS per above. Wasn't that the re-implementation of I/O subsystem? Introduction of subchannels/CHPIDs/...? --Kubanczyk (talk) 23:04, 25 November 2007 (UTC)

Merge with MVS/ESA

Better merge with MVS per above. --Kubanczyk (talk) 23:04, 25 November 2007 (UTC)

Merge with OS/390

Oppose keep it as subordinate per Wikipedia:Summary Style; there is very specific info on that article; it would feel awkward on this page. --Kubanczyk (talk) 23:04, 25 November 2007 (UTC)

Personally I'm happy to see all such members of the family on one page - with one exception: z/OS. And that's only because it's the current incarnation. Putting them together gives a nice sense of history: Them building on one another. Martin Packer (talk) 10:28, 26 November 2007 (UTC)

Yes you are right. Once again: Wikipedia:Summary Style. This guideline says that you can build a history here and have some detailed pages, too. --Kubanczyk (talk) 10:38, 26 November 2007 (UTC)

Kubanczyk, can you please clarify your last post. Do you mean you agree with the whole of what Martin Packer says (merge all except z/OS, which is also what I'd like to do) or are you still opposing merging in OS/390? Philcha (talk) 17:44, 26 November 2007 (UTC)

Hmm lets see... "Putting them together gives a nice sense of history: Them building on one another." -> "Yes you are right. ... you can build a history here and have some detailed pages, too". I agreed with Martin's last sentence, not with the merge proposition. --Kubanczyk (talk) 00:20, 27 November 2007 (UTC)

fred brooks + mythical man month...

isn't even mentioned in the article. nor is the number of programmers, etc. —Preceding unsigned comment added by 71.116.135.45 (talk) 22:56, 15 April 2008 (UTC)

Fred Brooks & "Mythical man month" are mentioned in History of IBM mainframe operating systems. Thanks for raising the point, it might be good to mention Fred Brooks & "Mythical man month" in OS/360 and successors too - but we'll wait until we see how the rest of the article develops, as it's potentially rather long.

Do you have a good source for number of programmers? That would be valuable in either article, and possibly in the articles on Fred Brooks and Mythical man month. Philcha (talk) 14:12, 16 April 2008 (UTC)

merge with OS/390

Oppose. It may be desirable, in time, to work together : MVS, MVS/XA, MVS/ESA, anything beginning with MVS. That is the keyword that people will use first. z/OS should be kept separate, with just a mention of it at the end to direct the user. Reasons for keeping MVS as separate are numerous. In the working world, systems programmers refer to all versions as MVS only. Next, there are thousands of copies of MVS still running, esp. outside the USA, but even here. Mainframes are not like PC's when it comes to upgrading. It takes an installation years to plan the conversion, get educated, and if hardware upgrades are dictated, wait in line for IBM factories to fill the order and then install difficult equipment and work out chilling requirements. Finally, data centers have a saying, "don't go first." Any new thing like z/OS is viewed with dark suspicion. Every program in the installation - typically thousands - will be recompiled and tested on the new system. So I think the term MVS is being used, it is probably the most-used IBM term along with CICS and VTAM. And people will type it in as their search. <User: S.Byczynski, Systems Programmer, Dec. 22, 2008, user> —Preceding unsigned comment added by 4.238.136.107 (talk) 03:01, 23 December 2008 (UTC)

Timeline data only here or also in IBM Mainframe Operating Systems infobox

I plan to add an OS/360 timeline to this article, based on IBM 360 Operating Systems Release History, and wonder whether those data also belong in the IBM Mainframe Operating Systems infobox. Would that be TMI there? Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:41, 27 June 2010 (UTC)

Proposed merge with OS/VS2 (SVS)

User:TeleComNasSprVen has added a merge template to OS/VS2 (SVS). That proposal should be considered in the context of the other OS/360 descendants, e.g., if OS/VS1 is merged here then SVS should be also, if not, not. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:53, 18 August 2010 (UTC)

Yes, but this also follows from your edit which added the OS/VS2 to the merge template here. :| TelCoNaSpVe :| 16:00, 18 August 2010 (UTC)

OS/VS2 (SVS) is quite a substantial article so it would be a tricky merge. For the sake of convenience rather than any content considerations I've removed the merge tag.--Salix (talk): 13:01, 28 November 2010 (UTC)

Proposed solution to merging mess

For reference, I'll be using this table: {{History of IBM mainframe operating systems|os_only=os_only}}. Note that this table will be left intact while this merging is implemented.

• Merge MVT, MVS, OS/VSR1, and 65MP (will be created as a redirect) to MVT and successors.
  • Note that MVT is short while OS/VSR21 and MVS is long. If combined, this page should result in a reasonable size.

Multiprogramming with a Variable number of Tasks has virtually no content, and most of what has to be added applies to other options of OS/360. For that reason I believe that the MVT article should be merged into the OS/360 article, with a redirect.

I assume that by OS/VSR1 you meant OS/VS2 R1, not OS/VS1. Deciding where to place the OS/VS1 material should be part of any merger proposal. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:37, 27 September 2010 (UTC)

• Merge ALL MVS-related articles (SE, SE2, and SP will be created as redirects; XA, ESA, OS/390, and z/OS (if needed) will be redirected to this new page) into MVS successors.
  • Since MVS is already a large topic, this should have its own subsection. Merging several large topics (e.g., z/OS, as that is fairly large) would violate several WP:SIZE rules.

The term MVS encompasses the successors to OS/VS2, and even appears in some of the names. I propose retaining the article as MVS, possibly splitting out some material into separate articles, e.g., Data Management. Before doing so there should be some discussion of the relative merits of vertical splits versus horizontal splits. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:37, 27 September 2010 (UTC)

• Merge all other articles (MFT 2 and its successors) into OS/360 and successors.
  • Since only one topic is known for this group topics, this merge should be easier to handle than the previous two since no size rules will be present in this merge.

There doesn't seem to be an MFT II article to merge. MFT (operating system) is just a redirect.

The reason why I'm not asking for the MVT articles to merge with OS/360 is because OS/360 is already somewhat long, and the MVT articles need extra room for improvement (WP:SIZE again). If need be, MVT and successors can be merged to the OS/360 article, but I don't recommend it. Totlmstr (talk) 01:36, 27 September 2010 (UTC)

I'd estimate that 90% of the material that needs to be added to an MVT article applies to PCP, MFT II, or both. As such, I believe that a single article is appropriate. If a split is needed, I'd propose a base OS/360 article and a separate OS/360 successors article with extensive Wikilinks. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:37, 27 September 2010 (UTC)

I've been a little WP:BOLD and closed part of the merge discussions. I've drawn a line at MVS and suggest MVS/370, MVS/XA, MVS/ESA be merged into that. Discussion Talk:MVS#Merge MVS articles. OS/VS1, OS/VS2 (SVS) and Multiprogramming with a Variable number of Tasks remain as candidates to be merged here. OS/390 has also been removed.

I'm not sure WP:SIZE really comes into the equation as the sizes are short enough even after merging.

Keeping this article as summary style seems fine. But there do seem to be some major technical changes which deserve their own topics.--Salix (talk): 05:24, 2 October 2010 (UTC)

While only broadly familiar with these technologies, looking at the hierarchy, it would appear that MVT had in fact led to it own tree of successors. While this article summarizes that hierarchy and 'tree of life', the article on MVT will focus on the technology. It appears merger proposals have 'died on the vine' in at least a few cases. I will add the 'main' template to further link between the two. Cander0000 (talk) 05:28, 28 November 2010 (UTC)

I've now merged MVS/370, MVS/XA, MVS/ESA into MVS. Hope that OK.--Salix (talk): 12:56, 28 November 2010 (UTC)

Do you consider a version with multiple releases to be a subtree? How do you categorize M65MP, as a dead end, as just MVT or as a precursor to MVS? The descendants of OS/360 MVT are

• OS/VS2 Release 1 (SVS)
  • Release 1.0
  • Release 1.6
  • Release 1.7
• MVS base
  Everything through MVS/SP V1 is MVS/370
  • Release 2
  • Release 3.0
  • Release 3.6
  • Release 3.7
    • MVS/System Extensions Release 1 (MVS/SE)
  • Release 3.8
    • MVS/System Extensions Release 2 (MVS/SE)
    • MVS/System Product Version 1 (MVS/SP)
      Last MVS/370 version
    • MVS/System Product Version 2 (MVS/XA)
    • MVS/System Product Version 3 (MVS/ESA)
    • MVS/ESA System Product Version 4 (MVS/ESA)
    • MVS/ESA System Product Version 5 (MVS/ESA)
    • OS/390 Version 1
    • OS/390 Version 2
    • z/OS Version 1

Everything from MVS/SP V1 through z/OS went through multiple releases, some of which overlapped releases of previous products. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:50, 28 November 2010 (UTC)

It now looks like all the merge proposals have now been closed. Have we finally arrived at an acceptable solution?--Salix (talk): 13:08, 28 November 2010 (UTC)

Is there agreement to leave OS/VS1 where it is? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:50, 28 November 2010 (UTC)

References for components mentioned only in footnotes?

I added a footnote explaining that while OS/360 was originally announced as a batch operating system, IBM later added interactive facilities. Should I add manuals for CRJE and ITF to References and link to the citations from the footnote, or is that TMI? Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:58, 28 February 2011 (UTC)

Inappropriate {{main}} tag

The {{main|Multiprogramming with a Variable number of Tasks}} tag for MVT is inappropriate; the cited article has less detail on MVT than the OS/360 article does. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:52, 16 November 2011 (UTC)

Is that a bug or a feature? I.e., should Multiprogramming with a Variable number of Tasks give more detail on MVT than the MVT section of this article (so that this article gives a summary and points to the MVT article), or should the stuff in the MVT article be absorbed into the MVT section of this article and Multiprogramming with a Variable number of Tasks changed to redirect to that section? Guy Harris (talk) 01:50, 17 November 2011 (UTC)

I see a lot of merging discussion, and I'm coming to it late, but I submit that the OS/360 variants shared most of the code, with a few, tho major, pieces different. I'd like to see PCP, MFT, and MVT here with the separate articles being redirects, basically I agree with Guy.Peter Flass (talk) 03:53, 17 November 2011 (UTC)

IMHO it doesn't make any sense to give details in separate articles on PCP, MFT, MFT II and MVT, aince the overwhelming majority of the OS/360 code base is common to all, and most of what does not exist in PCP is common to MFT II and MVT. As an illustration of this, I've used PCP logic manuals as a guide to MVT code and MVT logic manuals as a guide to PCP code, in cases where IBM had not added relevant information at the same level of detail. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:03, 20 November 2011 (UTC)

Merger proposal

OK, it sounds as if User:Chatul thinks the right thing might be to move the stuff from Multiprogramming with a Variable number of Tasks here and make Multiprogramming with a Variable number of Tasks just a redirect to the MVT section of this page. Is that correct? If so, it sounds reasonable to me; here's the place to discuss that. Guy Harris (talk) 02:47, 20 November 2011 (UTC)

Yes. There's very little material in the MVT article, and much of the detail that could reasonably be added also applies to either MFT 2 or to both MFT and PCP.Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:50, 21 November 2011 (UTC)

Done. Peter Flass (talk) 00:33, 3 August 2013 (UTC)

Available Languages

The article lists Assembler(E) and Assembler(F) separately, but nothing for FORTRAN or COBOL. Weren't there COBOL(E) and COBOL(F), FORTRAN(E),and FORTRAN(G)? I don't believe there ever was a FORTRAN(F). Of course PL/I is PL/I(F). What about RPG? It seems reasonable to list either all or none. Peter Flass (talk) 03:23, 20 November 2011 (UTC)

FORTRAN(G) and FORTRAN(H), I think. FORTRAN(G) was a Digitek compiler; I think FORTRAN(H) was an IBM-developed compiler written mostly in FORTRAN with some special extensions, with a special command-linePARM= option to the FORTRAN(H) compiler to turn on the extensions (documented in an appendix or a PLM or something such as that; as I remember, it referred to it as an option for "compiling the compiler"). Guy Harris (talk) 04:17, 20 November 2011 (UTC)

OK, a little bit of Teh Google (for "RPG OS/360", which first found information about role-playing games on the Xbox 360) found some information on compilers that came with MVT 21.8f; they include ALGOL(F), an ANSI COBOL with no memory-requirement letter, FORTRAN(G), FORTRAN(H), PL/I(F), and RPC with no memory-requirement letter.

Digging into Uncle Al's bitsavers.org found FORTRAN manuals listing FORTRAN(E), FORTRAN(G), and FORTRAN(H). Guy Harris (talk) 04:30, 20 November 2011 (UTC)

And the PLM for FORTRAN H, as mentioned above; see Appendix J, starting at page 235. The PARM= option was XL, and the extensions were data structures and pointers to them, and bitwise-logical operations, shifting operations, and bit-testing-and-setting operations implemented as builtin functions. Guy Harris (talk) 05:57, 20 November 2011 (UTC)

I probably have manuals for most of these; I don't recall the design points for ALGOL and RPG.

• ALGOL 60
• Assembler (E)
• Assembler (F)
• COBOL (E)
• COBOL (F)
• COBOL (U); came out fairly late in the game
• FORTRAN (E)
• FORTRAN (G)
• FORTRAN (H)
• PL/1 (F)
• Report Program Generator
• TESTRAN

Later there were program product upgrades:

• OS/COBOL, 5734-CB1
• FORTRAN G1
• FORTRAN H Extended
• FORTRAN H Extended Enhanced Optimization IUP
• PL/I Checkout Compiler
• PL/I Optimizing compiler

Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:09, 21 November 2011 (UTC)

As well as I know, many of those, especially the E level, are for DOS/360. They should, then, be moved to the appropriate article. Gah4 (talk) 22:55, 3 September 2017 (UTC)

unlimited?

was the max number of jobs/tasks really unlimited? I'm sure there was a limit - was it a sysgen option? or was it indirect limited by some other resource ( number of entries in a table e.g.)? Peter Flass (talk) 18:46, 6 August 2013 (UTC)

There was a limit of 15 Initiators due to the 4-bit storage protect key. There was also a total limit of 52 for MFT II, but that did not apply to MVT. For Both MFT II and MVT, the 16 MiB address limit imposed a practical limit on the number of partitions/regions. For both MFT II and MVT, the size of the system queue area specified during SysGen also imposed a practical limit on the number of subtasks. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:44, 8 August 2013 (UTC)

As well as I remember, the lower limit on REGION is the size of the initiator itself. So, 16MB/(initiator size) or, as noted, 15 protect keys, would be the limit. Gah4 (talk) 22:59, 3 September 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on OS/360 and successors. 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:

• Added archive https://web.archive.org/web/20090304014628/http://www.zjournal.com/index.cfm?section=article&aid=293 to http://www.zjournal.com/index.cfm?section=article&aid=293
• Added archive http://web.archive.org/web/20051013071230/http://www.jaymoseley.com:80/hercules/vstutor/vstutor.htm to http://www.jaymoseley.com/hercules/vstutor/vstutor.htm

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y 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:26, 20 July 2016 (UTC)

The first archive link works; the second one might have worked, but was unnecessary - the page moved on Jay Moseley's site, it didn't disappear, so I put the new link in and got rid of the archive link. (Perhaps the first reference is still there on enterprisesystemsmedia.com, but I couldn't find it.) Guy Harris (talk) 19:24, 20 July 2016 (UTC)

The IBM 360/67

I see the reference for The IBM 360/67 and CP/CMS. I believe the IBM 360/67 was the first model that supported virtual storage; I don't know if it would be appropriate to mention that here but I am suggesting that. Sam Tomato (talk) 02:10, 2 May 2017 (UTC)

This is about OS/360, the OS meant for System/360 processors. (Though not for the smaller ones.) As OS/360 doesn't use VS, there might not be so much point. The article on S/360 hardware should mention it, and if it doesn't, it should be added. There are some time sharing systems to use with OS/360, but those don't use VS, either. Gah4 (talk) 03:27, 2 May 2017 (UTC)

The article mentions TSS/360 in passing at the top:

IBM originally intended that System/360 should have only one batch-oriented operating system, OS/360. It also intended to supply a separate timesharing operating system, TSS/360.

which I changed to

IBM originally intended that System/360 should have only one batch-oriented operating system, OS/360. It also intended to supply a separate timesharing operating system, TSS/360, for the System/360 Model 67.

to mention the M67 in passing as well, and to indicate that TSS was M67-specific, unlike OS. I'm not sure that the M67 needs to be mentioned any further, although we might want to note that TSS/360 required DAT and that's why it was M67-only, the M67 being the only model with DAT.

(Yes, the M67 was the first shipped model that supported DAT and thus that supported virtual storage. IBM CP-40 indicates that IBM hacked up a special M40 with DAT support to do early research, but that was never shipped as a product.) Guy Harris (talk) 03:50, 2 May 2017 (UTC)

Don't forget the S/360 models 64 and 66, the DAT versions of models 60 and 62. While they were not shipped to customers, I believe that IBM used them for the initial development of TSS/360. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:17, 3 May 2017 (UTC)

256K

Quoting: Experience indicated that it was not advisable to install OS/360 on systems with less than 256 KB of memory, As well as I know, PCP is supposed to be able to run in 64K. It is likely slow running that way, and so might not be advisable, unless one wasn't in a hurry to see results. (That is, 20K for PCP, 44K for user program. Gah4 (talk) 23:03, 3 September 2017 (UTC)

PCP was used this way to run a single dedicated software package. Attached Support Processor is one example, I believe there were others. I think this fell by the wayside later. Peter Flass (talk) 00:52, 4 September 2017 (UTC)

One that I know is that PL/I (F) was designed to run in 44K, with PCP on a 64K machine. I don't know that it would be fun to run that way, it might take days to compile a small program. At the end of every run, PL/I (F) tells you the minimum region size to keep the symbol table in memory (instead of disk). I suspect that RPG was more useful in 64K. But yes, MFT in 256K might not be so bad. Gah4 (talk) 05:27, 4 September 2017 (UTC)

We could IPL MFT in 128 KiB, but that wasn't suitable for production. Similarly, we could IPL MVT in 256 KiB but that didn't leave room for a reasonable mix of regions. With 256 KiB for MFT and 512 KiB for MVT performance was adequate. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:32, 7 September 2017 (UTC)

All the "F"s. I don't think there was a FORTRAN(F), but I know there was COBOL. I seen to recall even a COBOL(E)!Peter Flass (talk) 11:32, 4 September 2017 (UTC)

Yes all the "F"s, but fitting a full PL/I compiler in 44K is somewhat harder than RPG. There are also ALGOL F and Assembler F. As well as I know, the E level are for DOS/360. And getting the linkage editor to fit in 44K isn't easy, and so it puts much on disk, and is slow. Gah4 (talk) 20:03, 4 September 2017 (UTC)

Not to beat the topic to death, the D compilers were DOS, I used to think the D stood for DOS, but now realize it's the memory size. I looked this up and see an Assembler(E), COBOL(E), and FORTRAN(E), all for OS, along with Linkage Editor (E). [4] Peter Flass (talk) 21:49, 4 September 2017 (UTC)

I suppose I never used an OS/360 system that small. I always thought that they were for DOS. I do remember a system with a high priority job class for up to 128K and 15 seconds, and sometime using it to get jobs through faster. I thought that 64K (20K for PCP and 44K for user program) was small enough. I never did get to use DOS. Gah4 (talk) 04:07, 5 September 2017 (UTC)

At ADR we ran PL/1 (F) under PCP quite nicely in 128 KiB, and I know of installations running PCP in less than 64 KiB, although, of course, they were restricted to E level compilers.. Is there any reason not to revert the change? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:37, 5 September 2017 (UTC)

I think I tried once to run PL/I (F) in 44K on MVT, but you can't make the REGION that small for MVT. I wanted to see the message at the end. I did, not so many years ago (well, about 20) run PL/I (F) on an AT/370 with VM/PC, which I believe runs in 512K real storage, and it was very slow. Another message from the compiler tells the available storage, virtual under VM/CMS. I always wondered if it had to allocate all that, to see how much it was, and how long that took. Gah4 (talk) 22:32, 5 September 2017 (UTC)

Actually, you could have a small region in MVT; the scheduling included a region swap. AT/370 ran VM/PC, not OS/360; presumably your virtual machine was large enough to run the CMS compilers, but the processor was still fairly slow and the paging device was nothing to write home about. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:32, 7 September 2017 (UTC)

The story I remember at the time, was that you can't make REGION smaller than the size of the initiator, and that was more than 44K. Yes, the comparison with VM/PC isn't fair. The way CMS allocates storage, and also the way it does LINK, is different enough. But it was two different things I tried with that compiler, some years apart. Gah4 (talk) 18:28, 7 September 2017 (UTC)

To be more precise, a batch job couldn't have a region smaller than what the Initiator needed, but a started task, e.g., SYSOUT Writer, could. If you hav a copy of the MVT job management PLM, the key terms are "L-shaped task" and "IEFSD263". Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:01, 11 September 2017 (UTC)

Best explanation that I have seen for the difference between batch job and started task. I only tried once to run PL/I (F) in a small region on MVT, which I suspect is once more than anyone else. I suspect around release 21, if that matters. Gah4 (talk) 22:43, 11 September 2017 (UTC)

Maybe just tone it down to "not recommended" or somesuch. Peter Flass (talk) 22:07, 5 September 2017 (UTC)

PCP version

The article speaks of things omitted from OS/360 PCP. I remember some others, from using 19.6 PCP on an 360 model 44 in college. In particular, I remember PCP did not support time limits; a job would run indefinitely unless canceled by the operator. I think there also were no time keeping system service requests. The background for that is the student Fortran compiler WATFIV, which would run a whole stack of student programs as a single OS job, and would use time limits per student program. PCP could not do that and forced the operator to cancel the whole OS job, then rerun it with the portion of the student program decks that hadn't been started yet. Possibly these were sysgen options, but I'm fairly sure at least the latter was not because I spent a while looking for a solution for this troubling limitation. (The eventual solution was an OS security hole exploit where I hooked WATFIV to the interrupt vector for the "interrupt" button on the 360/44 front panel, and instructed the operator to "push 'INTERRUPT' to cancel a WATFIV job". Paul Koning (talk) 19:24, 31 January 2022 (UTC)

I believe the interval timer is optional on low-end S/360 models. Also, storage protection is optional on some. Gah4 (talk) 22:26, 31 January 2022 (UTC)

Correct. I would think IBM could have made the timer a sysgen option. Peter Flass (talk) 00:21, 1 February 2022 (UTC)

Actually OS/360 Concepts and Facilities only says the timer is optional on some models, apparently including the /44, so maybe this system didn’t have it. The other thing is that the /44 had to emulate come instructions to run OS, so maybe this wasn’t emulated. I guess we’ll never know.Peter Flass (talk) 00:30, 1 February 2022 (UTC)

AFAIK the 360/44 has an interval timer, but timer support in OS/360 is optional and PCP does not support job-step timing. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:50, 1 February 2022 (UTC)

New section Structure, interface and logic

@Gah4 and Guy Harris: I've started writing OS/360 and successors#Structure, interface and logic, with the intention of adding a similar section to MVS that links to OS/360 and successors#Structure, interface and logic rather than repeating details. I'm soliciting the following

1. Editors interested in adding material
2. Guidance on the structure of the section
3. Guidance on the appropriate level of detail
4. Secondary sources to supplement the primary sources that I have.

I've concentrated on MVT; PCP and MFT are very similar, and I'm concerned that a proper discussion of MVS would make the article too large. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:01, 23 May 2022 (UTC)

Citation structure for multiples sections in same source

I am planning to add text that will cite multiple sections of each source. While I could get better appearance using {{R}} with R-style shortened references, it is far less work to add a definition list| to OS/360 and successors#Manuals, to include |ref=anchor in each {{cite manual}} template and to refer to them with |1=anchor, |page=page # and |loc=section in {{sfn}}. For the easier option, I might code:

 Bytes 8-23 read and transfer to the bootstrap record{{sfn|IPL|p=[http://bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/plm/GY28-6661-5_Inital_Program_Loader_and_Nucleus_Initialization_Program_Rel21_PLM_Mar72.pdf#page=11 3]|loc=THE INITIAL PROGRAM LOADER}} cylinder 0 track 1, which in turn reads and transfers to the IPL Loader. 
 ===Manuals===
 ;IPL
 ;{{cite manual
  | title       = IBM System/3S0 Operating System - Initial Program Loader and Nucleus Initialization Program - Program Number 360S-CI-535
  | id          = GY28-6661-5
  | date        = March 1972
  | edition     = Sixth
  | ref         = {{sfnref|IPL}}
  | url         = http://bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/plm/GY28-6661-5_Inital_Program_Loader_and_Nucleus_Initialization_Program_Rel21_PLM_Mar72.pdf
  | work        = Program Logic
  | publisher   = [[IBM]]
  | access-date = May 23, 2022
 }}
 :MVTSUP
 : {{cite manual
  | title       = IBM System/360 Operating System - MVT Supervisor
  | id          = GY28-6659-7
  | date        = May 1973
  | edition     = Eighth
  | url         = http://bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/plm/GY28-6659-7_MVT_Supervisor_PLM_Rel_21.7_May73.pdf
  | ref         = {{sfnref|MVTSUP}}
  | work        = Program Logic
  | access-date = May 23, 2022
 }}

Rendering as

Bytes 8-23 read and transfer to the bootstrap record cylinder 0 track 1, which in turn reads and transfers to the IPL Loader.

Manuals

IPL

IBM System/3S0 Operating System - Initial Program Loader and Nucleus Initialization Program - Program Number 360S-CI-535 (PDF) (Sixth ed.). IBM. March 1972. GY28-6661-5. Retrieved May 23, 2022. {{cite book}}: |work= ignored (help)

MVTSUP

IBM System/360 Operating System - MVT Supervisor (PDF) (Eighth ed.). May 1973. GY28-6659-7. Retrieved May 23, 2022. {{cite book}}: |work= ignored (help)

Any thoughts on whether it is okay to use the second approach so that the backlinks will be automatic? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:18, 29 May 2022 (UTC)

Notes

References

IEEVIPL

Most names with V in them are the VS version. Does the OS/360 version have a different name? Gah4 (talk) 02:13, 8 June 2022 (UTC) OK, it seems that IEEVIPL is the MVT version. I don't know about PCP or MFT. Gah4 (talk) 02:19, 8 June 2022 (UTC)

Generally the IEC, IEE, IEF and IGG names are the same while some other O/360 names change from Ixx to Hxx (OS/VS1) or Axx (OS/VS2). Off the top of my head I can't think of any that add a V for VS versions. IEEVIPL does not exist in MFT. NIP transfers to IEESD569 in MFT; I don't know whether IEEVIPL calls IEESD569 in MVT or just performs the same functions. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:49, 8 June 2022 (UTC)

There are many IEAV names that I first knew in the OS/VS2 days, and believed were related to the VS system. Many are documented here including the explanation of names starting with IEAV. I am now wondering if those trace back to MVT and not OS/VS. Gah4 (talk) 20:24, 8 June 2022 (UTC)

Some, e.g., IEAVELK, are for functions new to MVS, while some, e.g., IEAVEEXT, replace OS/360 routines, e.g., IEAQNUOO. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:30, 9 June 2022 (UTC)

According to IBM System/360 Operating System: Job Manalgement, Program Logic Manual (release 19), there are a bunch of job management modules in "the IBM System/360 Operating System Primary Control Program" with names beginning with IEFV. Guy Harris (talk) 22:43, 8 June 2022 (UTC)

Also the earlier http://bitsavers.org/pdf/ibm/360/os/plm_1966-67/Y28-6613-1_Job_Management_PLM_Mar67.pdf, and I'm pretty sure some of those go back to Release 1. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:30, 9 June 2022 (UTC)

DSECT

It occurs to me that there is no article for DSECT. I wanted to link to it, but there isn't one. Since I don't know where else to ask, I am putting it here. I believe it deserves its own article. I am not sure how it works in DOS/360 and its successors. It would also be interesting to know of other (non-IBM) assemblers with a similar system. Gah4 (talk) 20:10, 30 August 2023 (UTC)

That's a language entity rather than an OS entity; I believe that the article currently mustitled as Basic assembly language is the correct place for DSECT, as well as USING. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:20, 30 August 2023 (UTC)

The suggestion was that it should have its own article. I suppose Basic assembly language would be a good place to ask, though. The idea of symbolic representation of offsets into a data structure separate from those with the offsets. It seems that in Data structure they suggest that assemblers don't have such things. As I understand it in B, the predecessor to C, structure offsets are not attached to variables they way they are in C. As with DSECT, you have to know where you are using them. Gah4 (talk) 01:44, 31 August 2023 (UTC)