Talk:IBM System/370/Archive 1

Archive 1

Recent exchange about 10/7 changes

The following notes address a recent set of changes. 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'): http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_basinfo.html. 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 82.229.227.102 (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?

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: http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS370C.html), 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: http://www-306.ibm.com/common/ssi/OIX.wss?DocURL=http://d03xhttpcl001g.boulder.ibm.com/common/ssi/rep_ca/8/897/ENUS186-178/index.html&InfoType=AN&InfoSubType=null&InfoDesc=Announcement%20Letters&paneltext=Announcements&panelurl=OIX.wss%3Fbuttonpressed%3DNAV002PT090&singlehitflag=false&printableversion=yes) As far as I can see the boulder.ibm.com 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 (http://www-306.ibm.com/common/ssi/OIX.wss?DocURL=http://d03xhttpcl001g.boulder.ibm.com/common/ssi/rep_ca/8/897/ENUS186-178/index.html&InfoType=AN&InfoSubType=CA&InfoDesc=Announcement+Letters&panelurl=OIX.wss%3Fbuttonpressed%3DNAV002PT090&paneltext=Announcements) 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

[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 http://www.research.ibm.com/journal/sj/251/tucker.pdf). 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 (http://www.research.ibm.com/journal/rd/255/ibmrd2703B.pdf). 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

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

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

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

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

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 114.76.86.47 (talk) 02:17, 7 April 2010 (UTC)

The rise of plug compatible machines

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. 67.188.231.59 (talk) 19:07, 8 September 2010 (UTC)

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

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. 67.188.231.59 (talk) 19:07, 8 September 2010 (UTC)

MMU/DAT box

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. {{cite book}}: Unknown parameter |separator= ignored (help) Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:04, 12 September 2010 (UTC)

Performance

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. 81.187.162.109 (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?

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?

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". IBM System/370 Principles of Operation (PDF) (Eleventh ed.). IBM. 1987. pp. 4-10–4-11. GA22-7000-10. {{cite book}}: Cite has empty unknown parameters: |laydate=, |separator=, |author-name-separator=, |nopp=, |layurl=, |chapterurl=, |trans_title=, |trans_chapter=, |author-separator=, and |lastauthoramp= (help); Unknown parameter |laysource= ignored (help); Unknown parameter |month= ignored (help) 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)

Did S/370 use Advanced Solid Logic Technology for CPU circuits

? - Rod57 (talk) 11:29, 9 January 2016 (UTC)

When did the dual address space stuff show up?

The "1980s" section says:

In October 1981, the 3033 and 3081 processors added "extended real addressing", which allowed 26-bit addressing for physical storage (but still imposed a 24-bit limit for any individual address space). This capability appeared later on other systems, such as the 4381 and 3090.

Apparently, the dual address space stuff showed up in 1981 as well; did it show up at the same time as, and in the same machines as, the "extended real addressing" facility?

If so, perhaps it should be mentioned in that paragraph; if not, perhaps it should be mentioned in an item before the 370-XA item, rather than having the "The cross-memory services capability which facilitated movement of data between address spaces was actually available just prior to S/370-XA architecture on the 3031, 3032 and 3033 processors." comment in the section on 370-XA. Guy Harris (talk) 02:58, 8 April 2016 (UTC)

DAS came in with the 3031, 3032 and 3033, before the 3081. MVS/System Product Version 1 Release 3 was the first version of MVS to support DAS and extended real addressing. S/370-XA was never available on the 303x processors, only on 3081 and later. MVS/SP V1 could run on a S/370 mode 3081, 3083 or half of a 3084, but to use all four engines of a 3084 on a single system image you needed MVS/SP V2 (MVS/XA). Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:04, 8 April 2016 (UTC)

So IBM says the 303x came out in 1977; was DAS available, in the hardware, then, or was it added later (e.g. in a microcode update)? If it was available in the hardware, was it not supported by the OS until later? (The article says that "extended real addressing" was added in 1981; was that a microcode (or hardware) update, or was it always there since 1977 but not supported by the OS until 1981?) Guy Harris (talk) 20:48, 8 April 2016 (UTC)

Table Notable

This is a suggestion that the 40 or so words beginning "Notable machines in the 370 range include..." be "tabled."

A friend once noted that the American meaning is to take off the table (of discussion) whereas the British meaning is to put on the table, to be discussed.

This is meant to cover both: If there are no convincingly opposing statements, it is hereby recommended that "Notable" be deleted; the notability information has been added to the specific model texts. Pi314m (talk) 08:26, 26 December 2016 (UTC)

The text being removed says:

Note also the confusing term "System/370-compatible", which appeared in IBM source documents to describe certain products. Outside IBM, this term would more often describe systems from Amdahl Corporation, Hitachi Ltd., and others, that could run the same S/370 software. This choice of terminology by IBM may have been a deliberate attempt to ignore the existence of those plug compatible manufacturers (PCMs), because they competed aggressively against IBM hardware dominance.

Some OR/Original Research: Dr. Google's awards are- the 165 is top mention overall, the 135 is top mention on the IBM site, and the 125 seems to be top mention on Wiki (all languages). Pi314m (talk) 01:27, 23 January 2017 (UTC)

CORRECTION.. the above text stays; the text being removed says:

Notable machines in the 370 range include the IBM 370/195, the IBM 370/168, the IBM 3033, the IBM 3090 mainframe/supercomputer with its optional vector facility (VF) extension, and the relatively inexpensive IBM 9370 tailored for small-to-medium size businesses. Pi314m (talk) 01:35, 23 January 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on IBM System/370. 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/20061007194650/http://febcm.club.fr/english/information_technology/information_technology_3.htm to http://febcm.club.fr/english/information_technology/information_technology_3.htm

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

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) 01:11, 10 November 2017 (UTC)

Works, but I found a non-archived copy. Guy Harris (talk) 06:51, 10 November 2017 (UTC)

Infobox formatting

Figured I should add a note to apologise for my rather ugly fix for the way the infobox in the architecture section is rendering the surrounding text. Or mainly so that somebody who's less clueless about infobox markup than I am might do it properly. :D --Vometia (talk) 10:45, 28 June 2020 (UTC)

Cutoff point for S/370 compatible?

At what point should new or specialty processors no longer be listed in #Models sorted by date introduced (table)? In particular, should the box include:

• -155 II
• -165 II
• 9472
• P/370 card for PC
• R/370 card for RS/6000
• P/390 card for PC
• R/390 card for RS/6000
• Multiprise 2000
• Multiprise 3000
• 9672

Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:46, 28 June 2020 (UTC)

Architecture details

If "IBM documentation numbers the bits in reverse order to that shown above", why not reverse the position numbers to agree with the documentation? Peter Flass (talk) 17:25, 28 June 2020 (UTC)

@Peter Flass: Something like this?

IBM S/370 registers

00 07 08 15 16 23 24 31 32 39 40 47 48 57 58 63 (bit position)* General-purpose registers 0 R0 Floating-point registers FP0 FP0 Control registers 0 CR0 Basic mode Program Status Word System Mask Key 0MWP Interrupt Code ILC,CC Program Mask Instruction Address BC mode Program Status Word Extended Control mode Program Status Word 0R00 0TIE Key 1MWP S0,CC Program Mask 00000000 00000000 Instruction Address EC mode Program Status Word Note: IBM documentation numbers the bits from high order to low order; the most significant (leftmost) bit is designated as bit number 0.

Shmuel (Seymour J.) Metz Username:Chatul (talk) 05:10, 9 November 2020 (UTC)

@Peter Flass: I've added PSW layouts through S/370-ESA; the tables could use some tweaking. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:41, 7 December 2020 (UTC)

@Peter Flass: Does User:Chatul/sandbox/Registers look like what you had in mind for the registers? Shmuel (Seymour J.) Metz Username:Chatul (talk) 05:07, 4 January 2021 (UTC)

What is "the successor"?

The term successor might refer to immediate successor or to final successor, but the article lists ESA/390 as the successor, and it is neither. The sequence of architectures is listed below; the successor should be shown either as 370 XA or as z/Architecture.

• System/370
• System/370 Extended Architecture
• Enterprise Systems Architecture/370
• Enterprise Systems Architecture/390
• z/Architecture

Also, 390 ESA is *NOT* a renaming of 370 ESA; it includes new features. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:22, 16 October 2020 (UTC)

Recent updates

@Guy Harris: First, I apologize for inadvertently posting an incomplete update.

Second, my intent was that the footnote listing the constituent program products of MVS/XA include the table; I inadvertently terminated the {{refn}} prematurely. The table itself uses <ref>...</ref>, so I can't put it inside <ref>...</ref>. When I tried putting the table inside {{refn}}, the footnote rendered with just "{".

Also, there seems to be something wrong with my style="align:left"; the name header label is centered. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:04, 13 December 2020 (UTC)

Can footnotes include tables? And, if they can, would that make them too big to make sense? Guy Harris (talk) 23:10, 13 December 2020 (UTC)

I haven't been able to get tables to work inside footnotes, so I'm using definition lists instead. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:07, 8 January 2021 (UTC)

@Guy Harris and Tom94022: At this point in time I have included the register formats for base S/370 through ESA/390. I made it an infobox because the previous version was, but it might look better as a wikitable, possibly with different scaling or location. Should I add the Floating Point Control (FPC) register? What about the layouts of individual control registers?

I've added citations in #Evolution for all of the relevant Principles of Operation manuals, the assists for MVS and VM, and for Start Interpretive Execution, which is used by PR/SM and by VM/XA through z/VM. Some of the information in those manuals should be added to #Evolution or to #I/O evolutions. I've defined |ref={{sfnref|foo}} so that I can cite individual sections as {{sfn|loc=[section-url section]|pp=pages}} without dragging along redundant {{cite}} parameters. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:07, 8 January 2021 (UTC)

PSW tables

The article currently has these tables for PSW format

• S/370 BC mode
• S/370 EC mode
• S/370-XA
• ESA/370

The format for ESA/390 is identical to that for ESA/370, but the names of two bits in the program mask have been changed to reflect that they apply only to hexadecimal (legacy) floating point as opposed to binary (IEEE) floating point. I'm considering three options:

1. Add an ESA/390 table that is almost identical to the ESA/370 table.
2. Add footnotes to bits 22 and 23
3. Add text to the ESA/370 table to show both names for bits 22 and 23

Which option is best?

Also, the tables should be copied to Program status word once complete. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:35, 22 December 2020 (UTC)

I vote for 2 or 3. Creating a completely new table for two name changes seems like overkill. Peter Flass (talk) 15:38, 22 December 2020 (UTC)

How about a variation on 3; relabel the table as ESA/370 and ES/390 and distinguish the two bits with one local footnote Tom94022 (talk) 18:51, 22 December 2020 (UTC)

I think it's clearer the way that it is now, but if you want to change the name to ESA and change the Program Mask table to present the two nomenclatures in a different fashion, go ahead. Note that I've added layouts to Program Status Word, although I need to decide how to handle z. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:16, 27 December 2020 (UTC)