Talk:IBM System/370

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
WikiProject Technology  
WikiProject icon This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.

Recent exchange about 10/7 changes[edit]

The following notes address a recent set of changes. User:Spinality|Trevor Hanson]] 21:50, 8 October 2006 (UTC)

  1. I began what was intended to be a minor, corrective edit to this article, but it wound up going further than expected. (I'm still uncertain about the contents of the table; I corrected it as well as I could in the available time, but there seems to be some variation in how IBM has referred to its product series. I don't think the -XA architecture designation was an official part of the series name, but just a feature; and that may or may not have been true of the /ESA designation as well.)
  2. Based on discussion with Ross Paterson, I removed the compu-hardware-stub template. The article isn't very complete, but it is comparable with entries for other computer systems.
  3. The following exchange addresses the -XA and ESA/ tags:
Ross: As I recall it, XA-capable machines were still System/370, and it wasn't until ESA that they broke with the S/370 moniker. Which reminds me - I don't believe I ever heard "ESA" called "System/370-ESA". I was attending the Endicott/Poughkeepsie non-disclosure briefings in those days and it was always described "System/390" or just "ESA". And on a related point, "System/370 compatible" was always a term applied to Amdahl/Fujitsu and National Semiconductor/Hitachi clones, never to IBM machines. The 303x, 4331, and 4341 were genuine S/370. The 308x series almost got called "System/380" (but didn't) because they were the start of XA, which was briefly known inside IBM by that name. RossPatterson 20:28, 8 October 2006 (UTC)
Trevor: This is some of the contradictory stuff that made my edits drag on and on. To answer your specific comments:
  • One of the papers I cited talks about ESA/370 in those initial machines. (I pretty much followed the table that somebody else had put here though, which broke the product line down this way.) I removed the term 370-ESA because now I can't find it; I thought I saw that in an early R&D paper late last night but...?.
  • I too was surprised to see the term S/370 compatible on an official IBM historical site (I too always thought of 'compatible' as referring to Amdahl/Hitachi/etc., though we usually called them 'PCMs'): I figure if that's the party line then we better use it. I put a citation in for it in the table though, because I agree this is not how I remember normal terminology at the time. And I can't think of what else to call the 3033.
  • I now remember hearing about S/380 also. It's funny how many old factoids start to emerge as you rake over the embers.

Any further clarification from other dinosaurs will be helpful. (As you correct, though, do be sure to look at the IBM citations however, which include terminology that is different from what I remember at the time. But of course "no original research" means my memory is irrelevant!) Trevor Hanson 21:50, 8 October 2006 (UTC)

As is my memory :-) Thanks for recording this, Trevor. RossPatterson 23:17, 8 October 2006 (UTC)

The lines that where inserted in the I/O section the S/370 arch about Block Multiplexing probably don't belong in 'S/370 Arch' section (not saying they are untrue - just misplaced) Ivan Warren (talk) 16:52, 3 February 2011 (UTC)

I also question moving the block mux to I/O evolutions, and the citation needed template was syntactically incorrect. For the time being I've replaced the incorrect template with a reference to Principles of Operation, but I believe that the entire item belongs in the features list. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:21, 7 February 2011 (UTC)

9370 as XA?[edit]

937X are listed as XA systems.. I strongly believe 9370 were S/370 only systems - Any objection to switch S/370 from XA to S/370 compatible systems in the table ? Ivan Scott Warren 20:02, 16 November 2006 (UTC)

For Info : About the XA vs ESA bit - ESA is an extension to XA.. XA is 31 bits + Subchannels, ESA is XA + Access Registers. S/370 XA did exist as a designation. The designation of ESA/370 to ESA/390 was however, only a name change and there are no architectural differences between the 2. I believe the name ESA/390 was introduced when the ES/9000 series of systems was released. Note : I have no hardproof for any of that, so I'm not going to edit the article without prior consent from the original author.Ivan Scott Warren 20:11, 16 November 2006 (UTC)

I've never been very happy with that table. I did my best to correct it (referencing IBM sources such as this one:, and you see the exchange we had about the odd IBM term 'S/370 compatible'. However I can't find any source that describes the 9370 in detail. (IBM archives has a link to the announcement, but it seems to be broken: As far as I can see the server is AWOL.)
It would be surprising to me if the 9370, released in 1986(?), was not XA; if not, it would have trouble running the then-current OSes. But I can't remember...and so many 9370s were VSE machines anyway. You may be right that it did not, but I'd be a lot happier if we could find some hard facts on the subject. The whole point of Wikipedia, as you know, is to have material based on published sources rather than people's memories, which are sadly fallible. (As are published sources, of course, but then you can pass the buck.) So to answer your question, of course I don't care if you change it any way you like, it's a collaborative document; but I think the 'right' solution would be to track down some hard facts first. I will keep looking too. Trevor Hanson 21:03, 16 November 2006 (UTC)
Actually, I did own a 9370 (a 9370 Model 55) and I can assure you it wasn't a XA system (It ran VM/SP5, VM/SP6, etc.. which CANNOT run on an XA system).. The successor (the 9221) was the ESA evolution - there was even a MES (Miscelaneous Equipment Specification) upgrade that made it possible to go from the 9370 to the 9221 - which involved - among other things - replacing the 9332 FBA drives with CKD enabled DASDs.. I'm going to try to find definite reference for that - and will include it in the article (that's all if you are OK with it !) Ivan Scott Warren 21:27, 16 November 2006 (UTC)
I finally tracked down some announcement text with a valid link ( and 9370 appears to have only 8Mb and 16Mb configurations, which adds support to your view. Also, you obviously have much more than vague memories, so I defer to your judgment on this. (And again, I don't care if you change the article any way you like, it's a collaborative document.) Trevor Hanson 21:39, 16 November 2006 (UTC)
Another topic: extended real addressing....[subthread moved to new topic below]
There was one difference between ESA/370 and ESA/390: ESCON. Also, the 3090-J and 4381-91/92 were indeed ESA-capable. Yes, calling it 370/XA was indeed a bit misleading, but you can blame that one on IBM, since they committed it. Jay Maynard 22:08, 16 November 2006 (UTC)
Ah.. And the 4361 is missing from the 43XX line ! (for the record, the 9370 can actually be considered an evolution of the 4361 !) Ivan Scott Warren 22:10, 16 November 2006 (UTC)
I never knew very much at all about the 4361, having never used one. It was always too small for the workloads the shops I worked at ran. Same goes for the 4331, although I did run a couple of 4341s in my time. Jay Maynard 22:57, 16 November 2006 (UTC)
The 4361 was a fun beast.. its particular feature was having all those integrated control units (IFA (Intergated File Adapter, read disk/tape control unit), IPA (Integrated Printer Adapter), ICA (Integrated Commo Adapter) and possibly also an IWA (Integrated Workstation Adapter)) - so you could do without any 3803, 3830|3880, 37xx etc.. One of those few models (the other being the 138) on which you could connect a 3203 model 4 (the one without the control unit) - but I don't think you could go beyond 12MB of storage on it and it was (IIRC) slower than a 4341 (which was rated at a whoping 1.2 MIPS). Ivan Scott Warren 23:26, 16 November 2006 (UTC)

Extended real addressing[edit]

[first few paragraphs moved from above, through "***"]

Another topic: extended real addressing. You added the 4381 and 3090 to the 3033 and 3081, which were the first systems to get this capability (in October 1981). I reworded it to show the timeline more clearly; but I'm not sure that these machines even belong on that list. I believe both were initially released as XA machines (see for example Of course they had different microcode loads that would turn off XA, but in the timeline they seem to me to go in the next category after extended real addressing. Was there something funny about early 4381/3090 releases? Trevor Hanson 21:39, 16 November 2006 (UTC)

Ok.. More clarifications on that : The 308[1|3|4], The 4381 and the 3090 (and also the [P|R]/390 were all Dual Architecture systems (S/370 and XA or ESA) (Out of the blue : 308x : XA, 3090 XA except S (and maybe J) models which were ESA and 4381 XA except ES-4381 and possibly 4381 the late models 91 and 92 which might have been ESA).. All these had a very distinctive characteristic of having 4K Storage key pages in S/370 mode (STKE instruction available).. the 9370 however, didn't have the option to run in XA or ESA mode (despite the misleading ES/9370 brand name) and as a matter of fact (known fact - no written proof (yet)) had a 2K storage key pages system (STKE instruction not available) which is a tell tale sign of non-XA capability ! Now - On the other side - I've also noticed announcements to be down on the IBM site - which doesn't help ! The denomination S370/XA system in the table is what is misleading since S/370, XA and ESA are *architectures* but not *technologies* - however - IBM may have linked the capability to run said architecture to said technology (i.e : Machine X can run S/370 and XA architecture and is therefore considered a XA ..system) Ivan Scott Warren 21:46, 16 November 2006 (UTC)

I found this buried in the 9370 announcement letter (my stress added):

In February IBM announced four new models of the IBM 4381, expanding our System/370 data center offerings and providing significant new levels of price performance. The recently enhanced 4381 family with its multiple channel, high data rates, and large memory capabilities provides an attractive entry solution for System/370 data center environments -- as well as a low-cost entry into System/370 extended addressing architecture. The 4381 offers an excellent growth path for current IBM 4341 and 4361 users, as well as future IBM 9370 users.
In other words, 9370 did not have extended addressing architecture. Which is what you said all along. A problem with the table is that it refers to processors by 'series' based on the most advanced architecture supported; but this isn't how they were sold. (Though it is more or less how we viewed them. "That's an XA machine.") Anyway, it sounds like you're on top of things here. Trevor Hanson 21:57, 16 November 2006 (UTC)

Yes and no.. The problem (and it's not the first time I've seen these discussions) is that the term S/370 is ambiguous ! it refers to both a technology (for example, S/360 differs from S/370 by the memory technology) and an architecture (S/370 : 24 bit, channel/CU/device addressing based I/O Architecture - XA : 31 bit, Subchannel based I/O architecture)... It is possible that the 9370 may *not* be considered a S/370 technology machine although it ran exclusively the S/370 architecture (hence the much debated "S/370 compatible" discussion above).. Considering some transition machines ran *both* architectures - the boundary is very hard to determine.. Therefore, I am considering moving the 9370 to the "S/370 Compatible" category... how does that sound ? Ivan Scott Warren 22:10, 16 November 2006 (UTC)

Looks good...or as good as it can look given the presence of the strange "S/370-compatible" nomenclature. (Thank you, IBM.) Does it make sense to list the 4381 and 3090 as having "extended real addressing" since they were ESA-capable? To my mind, that special category is just for those few >16Mb machines that were available before XA. Trevor Hanson 05:41, 17 November 2006 (UTC)

I think it does make sense because the 308x, the 4381 and the 3090 were machines that could address more than 16MB when configured to run in S/370 architecture mode. This 'extended real addressing' feature is a S/370 only feature control that allowed overcoming the 16MB real storage limit by using a DAT mode trick (by using a couple of bits in the PTEs) and this is not related to XA or ESA (Principle of Operations wise). The fact that the 3081, 4381 and 3090 were XA capable (meaning they could be configured to run in XA or ESA architectural mode) is quite a different matter. The fact is, I'm not even sure the 303X could address more than 16MB - and if this is the case, all S/370 extended real addressing machines would be also XA capable machines. Ivan Scott Warren 22:57, 20 November 2006 (UTC)

I'm pretty sure the 3031 could not, and fairly sure the 3032 could not, but I do know for a fact that the 3033 could address more than 16 MB of real storage: one shop I worked at had a 3033 with 32 MB real. Jay Maynard 02:36, 21 November 2006 (UTC)
*** new comments follow
Extended real addressing definitely predated XA. See the Padegs paper System/370 Extended Architecture: design considerations ( He talks about "...the introduction of the extended-real-addressing facility, first shipped in October 1981 on the 3033 and 3081 processors" and says: "Most 370-XA facilities were made generally available earlier this year (as of the date of this publication [1983]) on the 3081 and 3083 machines." In other words, XRA (or whatever acronym was used) was available from 1981-83, on 3033, 3081, and unspecified other processors, until XA was made available in 1983. (And that's the sequence of events I remember. I too saw 3033 systems with >16Mb.)
Your (ISW's) point about accessing more than 16MB in S/370 mode is a good one. I was originally classifying the systems based on when they were released, relative to the interval before XA in 1983 – when XRA was the only game in town for large real memory. But as you point out, non-XA installations after 1983 were also using this capability. So I agree: leave it in.
We could use some release notes from the period or something, to clarify which capabilities were on which processors. Though I guess at the end of the day its just us three dinosaurs who care. :) And we can't come up with the answer anyway. Trevor Hanson 05:37, 21 November 2006 (UTC)

I don't think that citation is needed for the comment at the end of the section (about extended real mem being needed before extended virtual mem). Some IBM systems were seriously multi-user at that time. I worked at the University of Alberta at the time, and they had an Amdahl with 24 and later 32Meg of real memory. I once saw the system with 700+ logged-in users .. and still resonable response time. Nobody on the system had user access to the larger address space, but having the extra real memory would have easily made massive multi-tasking more feasible without having to expand the virtual memory space... (( Yes, the Amdahl wasn't, strictly, an IBM system, but it was used as a plug-in replacement in a situation reminiscent of other (real) IBMs )) Darkonc (talk) 03:30, 12 April 2010 (UTC)

Added architecture chapter[edit]

I just added a chapter (attempting) to make a description of the S/370 architecture itself. Could Trevor or Jay (or whoever) cross read it for me, add possible links to defined terms, etc, etc.. (I am not an expert in wikipedia matter so this chapter probably needs some editing !) Ivan Scott Warren 23:48, 23 November 2006 (UTC)

A very nice addition. It strikes me as having the right level of detail versus overview material. I'm quite happy with it. If I see some minor formatting/wikification edits, I'll stick my oar in.
I do see one point that might be made earlier and more strongly: the relationship between S/370 P.O.O. and its predecessor, the S/360 P.O.O., and the practical importance of both those documents. The S/370 manual is footnoted, and the backward-compatibility point is made at the end of the section, but this issue strikes me as fundamental to the S/360-370-390-etc. family. The S/370 architecture wasn't cooked up in a vacuum. I was still using a S/360-67 green card in the 90s, and that strikes me as remarkable.
Anyway, a nice improvement. Trevor Hanson 20:03, 24 November 2006 (UTC)
Thanks ! As suggested, I added a more detailed explanation in the chapter header about the evolution from S/360 to S/370. Ivan Scott Warren 23:02, 25 November 2006 (UTC)
Should most of the architecture stuff go into the System/360 page, if it's not there already, with the S/370 architecture stuff describing what stuff changed or was added between S/360 and S/370? Guy Harris 08:48, 10 December 2006 (UTC)

Violations of backward compatibility[edit]

Can anybody come up with some examples of S/360 problem state functionality that went away with the S/370? I'd like to be able to say that, from the standpoint of application programs coded in assembler, there were no violations of backward compatibility. However, I have the nagging memory of a few little things changing. Maybe some of the packed decimal instructions? (I never had to use them much anyway.) I understand why we changed the description to "mostly backward compatible" but I don't think today's programmers realize how much consistency was preserved through the entire product family. I think it would be good to get precise about this. Obviously there were lots of changes moving forward, especially in super state, but an awful lot of old code continued to run without modification. Trevor Hanson 06:18, 4 December 2006 (UTC)

The only change I know of that was visible in problem state was the ASCII mode bit in the PSW, which changed how the decimal instructions behaved in a subtle way. (IIRC, it changed the high order nibble of decimal values generated by the processor from X'F' to X'B'.) That turned out to not get used very much at all, and they removed that function in S/370, changing the meaning of the PSW bit to signal that the CPU was in extended mode. The authoritative answer will be found in the S/360 compatibility section of the S/370 POO. Jay Maynard 11:57, 4 December 2006 (UTC)

One annoying incompatibility in the channel programming area (privileged) concerns the conditions under which Channel Status Word Count Field is valid. In System 360, the count was Correct after a Chaining Check, Termination by HALT I/O or Interface Control Check. (source A22-6821-0 360 Principles of Operation page 154). According to GA22-7000-3 370 P of O page 250 all three of these conditions yield a count field which is Unpredictable. Rdmoore6 (talk) 06:14, 16 December 2008 (UTC)

Generic Family[edit]

By the way, do we have a generic name for the S/360-S/370-S/390 instruction architecture family (analogous to "x86")? I'd really like to have a convenient name for the class of systems that have run (for example) the VM family or the OS family. It seems stupid to just say "IBM mainframe" (since one might obviously consider 70xx systems in that group, or any huge IBM systems regardless of architecture) – and I hate just giving a list of all the different product lines, especially those with a 'z' in them. Trevor Hanson 06:18, 4 December 2006 (UTC)

Were it not for the z/Architecture, you could call it System/3x0, I guess (by analogy to x86 - whose analog to z/Architecture, namely x86-64, is still part of x86). Guy Harris 08:50, 10 December 2006 (UTC)
I'd say "stick to the IBM marketingese" in all this. We DIDN'T come up with a portmanteau term and so - for most of the likely readers - imventimg one probably is confusing and isn't useful. (I have the same problem with z10's cache infrastructure, with us apparently using different terms from the marketplace where again I assert "go with the marketingese for the sake of the likely reader - mainframe folks". Martin Packer (talk) 10:31, 26 June 2008 (UTC)

Removal of sourced discussion of virtual memory chronology[edit]

I note that User:WmHBlair removed a number of comments about early chronology of DAT and virtual memory hardware, stating flatly in the edit comments (for example) that the 135 and 145 always had virtual memory capabilities. This is clearly refuted by numerous authoritative sources that had already been cited in the deleted text. I suggest that this material be restored, and that alternative sources be cited if the original sources are disputed. I might point out that the Padegs and Pugh histories of the series are highly regarded, and also that some earlier contributors to this article had firsthand knowledge of this particular equipment – and that in some cases they had provided the clues needed to track down the basic facts. Spinality (talk) 23:06, 28 July 2008 (UTC)

The 3145 had an associative memory that was used by the DOS Emulation Feature to do block relocation. It is not plausible that the associative memory was designed for that use; it seems clear that it was present for paging and the designers of the DOS Emulation Feature exploited it rather than adding additional data paths. I certainly expected paging to be on its way when I saw that. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:08, 21 June 2010 (UTC)

S/370 Compatible Memory: An Unusual Bug[edit]

S/370 Compatible Memory: An Unusual Bug Discussed here is a bug which affected IBM System 370 Models 158AP and 158MP. These configurations had two processors. (The bug is not relevant to the single processor 158UP.) —Preceding unsigned comment added by (talk) 02:17, 7 April 2010 (UTC)

The rise of plug compatible machines[edit]

What I remember is that IBM used to bundle hardware and software, and the rise of plug compatible mainframes required that software become unbundled. I don't remember if that was because of a lawsuit or an anti-trust agreement with the Justice Department though. Maybe someone who remembers the specifics could add something to that effect.

Cheers, Neil.

When Applied Data Research sued IBM because of bundling, e.g., CRJE, with the operating system, IBM used it as an excuse for starting to charge for new applications software and compilers, but AFAIK they would have done so even without the lawsuit. Because of the 1956 consent decree IBM couldn't restrict free software to its own computers, and the PCM's had a free ride. Charging for operating systems didn't start until Amdahl started making inroads. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:19, 8 September 2010 (UTC)

Backwards Compatibility[edit]

The article talks about backwards compatibility from an instruction set point of view. More important, though, was backwards compatibility in the compilers and operating systems. Going from DOS R26 (or was it R27?) to DOS/VS was a major challenge in that regard, although my memory from that time is fragile. Maybe someone with a better memory that mine could add something to that effect.

Cheers, Neil.

MMU/DAT box[edit]

It was only on the larger System/370 processors that a large and expensive DAT box was required. On, e.g., the 370/145, it was handled in microcode. See IBM, IBM Maintenance Library 3145 Processing Unit Theory - Maintenance, pp. CPU 117–129, SY24-3581-2.  Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:04, 12 September 2010 (UTC)


It would be useful to have some comparison with the performance of other systems of the same era, and possibly a comparison with a processor of today with which readers are likely to be familiar. (talk) 15:19, 3 October 2012 (UTC)

Performance comparisons would b a bit dicey for several reasons
  • Overal performance debends of the balance between CPU load and I/O load
  • Both the S/370 and competitive lines ran over multiple models with different performance profiles
  • Even for CPU performance on a single product line, speed ratios depend on the exact instruction mix used.
  • Multiprocessor interference depends very much on details of the OS
I can see someone throwing in some rough timing metrics, but it would be very easy to draw incorrect conclussions from them unless the text included appropriate warnsings. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:31, 5 October 2012 (UTC)

Level of detail for 370/145?[edit]

It is misleading to state that The S/370-145 had relocation hardware (implemented in microcode) from its first shipments in June 1971. More precisely, the original microcode on the 370/145 had microcode for the OS DOS compatibility feature, but not for paging. A new floppy disk provided the microcode to support paging. I'm not sure whether to update the article only to clarify that the paging microcode was not in the initial version or also to mention the 8-line associative memory in the initial shipment that was used by both the old and new microcode. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:07, 11 December 2012 (UTC)

Page for the parts of the architecture that have remained the same for all S/3x0 architectures?[edit]

IBM System/360 architecture and this page have a number of details that really didn't change much from S/360 to S/390, such as the GPRs, the FPRs, the data formats, and, I think, at least some of the exceptions. Problem-state instructions were added over time, but that also applies to x86, 68k, SPARC, MIPS, PA-RISC, etc..

Should there be a page to cover the common parts of all S/3x0 architectures, with other pages discussing the major changes (DAT, 31-bit addressing, I/O interface changes), etc.?

I'm not sure what the right thing is to do about z/Architecture; ISAs that went from 32-bit to 64-bit varied from "we made the registers twice as wide, changed the page tables to handle bigger addresses, and added 64-bit load, store, and (if relevant) arithmetic instructions" (several RISC architectures) throught "we did all that, got rid of most of the segmentation stuff, added instruction-relative addressing, and doubled the number of registers" (x86-64) to "we made the registers twice as wide, doubled the number of them, changed the page tables to handle bigger addresses, and added 64-bit load and store instructions - oh, and we got rid of conditional execution for most instructions" (64-bit ARM). x86-64 has its own page, which, given the changes, is probably the right thing; 64-bit ARM doesn't, which, given the changes, might not be the right thing. I don't know where z/Architecture fits on the scale. Guy Harris (talk) 22:58, 15 September 2013 (UTC)

I'm not sure what to do about the common features, but there is some background to take into account. The major changes were DAT, XA, ESA and 64-bit virtual. Each of these changed the addressing as seen by unprivileged code. In what follows, I will not be dealing with how the OS was affected by the changes, only how application code was affected.
For the transition to DAT, the major visible change was that accesses to unallocated memory could cause a program exception even if the virtual address was within the region. This resulted in the failure of programs that had been "working" for years, sometimes revealing that they had been giving incorrect results.
For the transition to DAT, existing code was only affected if it referred to OS control blocks above the 16 MiB line, but new code could run in either 24-bit or 31-bit mode.
For the transition to ESA, memory access could still only be 24-bit or 31-bit, but there was a new AR mode that allowed access to multiple data spaces through a set of access registers. As with XA, you mostly only had to change your code if you wanted to exploit the new mode.
64-bit real only affected programs that dealt with real channel programs.
64-bit virtual again provided a new mode. While general registers are now 64 bits wide, code running in 24-bit and 31-bit modes can generally ignore the high 32 bits. In 64-bit mode, addressing uses all 64 bits of base and index registers.
Note that programs can use long displacement instructions even in 24-bit mode. Similarly, the upper 32 bits of a general register for arithmetic, although not for addressing.
IBM added new formats for save areas at various times, but those pertain to the OS rather than to the architecture. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:17, 16 September 2013 (UTC)
Yes, that's why I mentioned them as "the major changes" (I forgot about the ESA stuff).
Most 32-bit ISAs these days were "born" with some form of address translation, either in the ISA itself (VAX, IA-32, and MIPS, for example) or in the systems in which it's used even if the MMU itself wasn't part of the ISA or wasn't originally part of the ISA (68k - even with the 68000 there were some machines with two processors to work around the non-restartability of instructions after bus errors, and that was fixed in the 68010 - and SPARC, for example) - so they didn't have the "paging was added" transition. S/3x0, being much older than the others, was different in that regard.
Most of them also didn't have "we ignore some address bits" architected in at the beginning; the one exception I can think of is 68k, and I don't know whether that was explicitly given as a feature of the architecture or was given as "we ignore those bits in the 68000, but don't assume they'll be ignored forever". It did have such a transition, at least on the Mac, although Sun, I think, made it clear from the beginning that you Should Not Stuff Extra Stuff Into The Upper 8 Bits Of A Pointer, and people used to writing code for BSD on VAXes already knew that wouldn't necessarily work.
So a discussion of the S/3x0 architecture(s) has to do things for various flavors of the 32-bit architecture that don't have to be done for most other 32-bit ISAs.
But the "General-purpose registers" and "Floating-point registers" charts in IBM System/360 architecture and IBM System/370 are identical, and most of the "Features", "Memory", "Addressing", "Data formats", and "Instruction formats" sections of IBM System/360 architecture, and most of the first three top-level items in the "Architecture details" list in IBM System/370, apply to both (the only parts of the latter list that don't apply to S/360 are the control registers, the PSW in extended-control mode, and some of the timing facilities).
FWIW, I added the CPU register tables to both articles (as well as several other CPUs), but they need to be double-checked for accuracy by someone more familiar with the S/360 and S/370 architectures than me. In particular, I'm not clear on the organization of the CRn control registers, and I did not show most of the individual parts of the PSW (although I'm not sure we even need to). — Loadmaster (talk) 22:00, 17 September 2013 (UTC)
The control registers have enough different fields that I'd advise adding a reference to "Assignment of Control-Register Fields" (PDF). IBM System/370 Principles of Operation (Eleventh ed.). IBM. September 1987. pp. 4–10–4–11. GA22-7000-10.  rather than putting the individual fields in the table.
I agree; the CPU register table is meant to be a visual depiction of the CPU structure, but should not be excessively detailed. Showing individual control flags is about as detailed as it needs to be, and even that might be overkill for some particularly complex CPUs. Labeling each bit of each CR is definitely on the overkill/too-much-information side of things. — Loadmaster (talk) 17:42, 3 October 2013 (UTC)
Style question: when the page number includes a hypen, how should I show a range of pages in the {{cite manual}}?
I would use extra spaces (e.g., "4-10 - 4-11"), or periods (e.g., "4.10-4.11"), or the word 'to' (e.g., "4-10 to 4-11"), but I don't know what the WP recommended practice is. — Loadmaster (talk) 17:42, 3 October 2013 (UTC)
The bit numbering is inconsistent. If you use the IBM convention for the PSW then you should use it for the other registers. Also, The EC format of the PSW is more important than the BC format, although my preference would be to show both. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:15, 3 October 2013 (UTC)
How to do the bit numbering comes down to whether we want to be consistent with the manufacturer's numbering, or consistent across multiple WP articles having similar CPU register tables. For the first approach, the tables provide a visual depiction that should complement the text description of the CPU. For the second approach, the tables provide the user a common visual frame of reference to understand the CPU capabilities, particularly as compared to other CPUs. I probably lean towards the first approach, since CPUs may differ enough that trying to come up with a common bit numbering for all CPUs may ultimately be too difficult. But further opinions from other editors are needed. — Loadmaster (talk) 17:36, 3 October 2013 (UTC)
I think it's best to stick to the IBM conventions or it will be confusing. I think the "progression" would show both BC and EC PSWs. Peter Flass (talk) 20:22, 3 October 2013 (UTC)
One possibility might be to have an "IBM System/3x0 architecture" page that starts out with the common stuff and then has subsections for S/360, S/370, S/370-XA, and S/370-ESA and S/390-ESA. Whether to describe "S/3100" :-), a/k/a z/Architecture, there is another matter; as indicated, some 32->64-bit architectures have separate pages for the 64-bit version, others don't. Perhaps having a short section for z/Architecture, with a "main article" link to the z/Architecture page, is the right way to go. Guy Harris (talk) 22:19, 16 September 2013 (UTC)
I like the idea of starting out with the common/old stuff, then adding individual sections to discuss the additions and extensions for each subsequent model. Since there is no "standard" Wikipedia approach for this, we should probably use a historical feature progression as the basis for the article structure. — Loadmaster (talk) 22:00, 17 September 2013 (UTC)