The book "IBM's 360 and Early 370 systems" by IBM Press goes DEEP into the development of these systems, and is one of my very favorite technical books. I paid $50 for a used copy more than a decade ago and it's well worth it. (also: "IBM's Early Computers" from some of the same authors, covers pre-360 stuff).
> Q: What sorts of radical changes can you foresee
that would cause the 360 architecture to be supplanted by a new architecture?
> A: That’s hard to say. If there is ever a breakthrough in harnessing thousands of micros into an
effective array for a wide-enough spectrum of big
jobs, then it might be time to rethink the major
computer product lines.
This is such a great punchline. It came out just as Sun and DEC were laying the foundation for modern networked systems, which along with PCs overturned mainframe hegemony.
Loved the article by the way. My first real intro to computing was the IBM/370 Principles of Operation.
The book "The Mythical Man Month" is about software engineering and project management based on Fred Brooks experiences at IBM while managing the development of OS/360.
> assigning more programmers to a project running behind schedule will make it even later.
> while it takes one woman nine months to make one baby, "nine women can't make a baby in one month".
You might be pleased to hear Fred Brooks apologised for JCL in 2015:[1]
> If we had been smart, we would also have done a schedule-time mode of PL/I instead of doing JCL, the Job Control Language. But we weren’t smart. The worst mistake we made was JCL. Its existence was a mistake. Building it on a card format was a mistake. Building it on assembly language was a mistake. Thinking of it as only six little control cards instead of a language was a mistake, because it had no proper subroutine facilities, no proper branching facilities. That we did not see it as a language was the fundamental problem; we saw it as a set of control cards.
Once at the Watson lab I rode in the elevator with Brooks and nearly kissed his ring for his The Mythical Man-Month but was nice enough not to mention JCL!
It was the interface for users essentially all of whom were programmers since there was essentially no on-line access then.
Calling JCL a scripting language is one heck of an insult to Rexx, etc. When Cowlishaw's Rexx became available right, away it swept IBM, e.g., ran the service machines that ran VNET, IBM's early thing to do internally for IBM what the Internet later did for the world.
Rexx could have run on MVS, etc. -- some people at Watson wanted that, but I doubt if it ever did.
I wrote a lot of JCL for MVT on the 360/91 and later on other 360 boxes, and I never saw anything like environment variables.
The horror was the DCB statements: They were to fill in control blocks needed in assembler to do I/O; if didn't understand those assembler control blocks, then DCB statements didn't make a lot of sense.
Perhaps I should clarify that I was referring to OS/MVS JCL. MVT was before my time. By "environment variables" I meant the ability to tie a logical device name (at the program level) to a physical device (or instance thereof, like a particular generation of a tape volume), like how environment variables link a logical name to a value.
I used to do all the JCL for my project group. Having come from being an operator first, I knew how to set up the JCL exactly how I wanted (including comments for instructions to / clarifications for operators and job control center staff) and syntax-test it. Meanwhile, the other groups stumbled through either hand-keypunching or laboriously filling out keypunch sheets. Many didn't even know we had a JES2 spooled card punch available before I came in.
The worst pain in the back side for me with JCL was that the job turnaround time was about 4 hours. So, miss one comma in JCL, and KaPOOF lose 4 hours of work.
I had two solutions:
(1) Walk my deck of cards to a card/printer remote terminal (about 300 yards away from my office) and have it print my card deck, then back at my office stare closely character by character by character at the printout.
(2) When a job did run, rush to copy the crucial JCL cards and KEEP them as something that WORKED.
In those days, the job control card struggles were not just for MVT or MVS but more general. At one meeting of users, a guy stood and said that he wanted the control cards that worked laminated in plastic with a hole in a corner and hung on a chain!!!
My later encounters with the IBM mainframes were via 3270 terminals, VM, Rexx, and with nearly no use of JCL. And in those days I was becoming a happy as a clam Prime customer. Did some good things with some Prime computers.
Then it was on to PC/DOS, OS/2, and Windows 9X, 2000, XP, 7, 10, .NET, SQL Server, the .NET version of Visual Basic (as far as I can tell, just a better flavor of syntactic sugar than C# -- I hate the idosyncratic syntax of C/C# -- wrote it? Yes. Like it, NO!), and soon Windows Server.
Here in the Mid Hudson Valley, IBM is running ads for people who know CICS to rejoin!!
Long turnaround is a property of batch not of JCL. While it was not pretty neither was the control deck for the CDC 3500 or the CDC 6400 and likely Burroughs big iron of the time.
But it sounds like you have a lot of issues with how a lot of the computer languages work.
"Issues"? Not really: As in Kernighan and Ritchie, C has "idiosyncratic syntax". To me the full generality of the type statement is unreadable; the book even has some code to show how to parse it. Also there is the notorious
i = ++j+++++k++
which is legal but on two compilers I tried it on got different answers.
To me idiosyncratic syntax is not a proof of worth or a trial by fire for admittance to the inner sanctum but just something more difficult to teach, learn, read, write, and debug than necessary.
C was designed at Bell AFTER IBM had PL/I running, and PL/I makes C look like kindergarten drool: Right off PL/I beats C in
(1) Scope of Names. What C has is a toy;
what PL/I has is powerful.
(2) Arrays. C doesn't really have any and asked the programmer to write pointer arithmetic using the usual array addressing arithmetic. PL/I has real arrays, and the compiler can pull constant expressions out of loops, optimize register usage, and otherwise have freedom to do things that the programmer can't see so that don't have to provide guarantees to the programmer.
(3) Strings. C doesn't really have any; the idea of ending a string with a null is the cause of too many buffer overflows. Each operation on a string is an external subroutine call, that is, resolved by the linkage editor. The PL/I people noticed that Fortran programmers did that, had a string package with a subroutine call for each little string operation, and some of the early IBM implementations of stings in PL/I did something similar, but by F level version 4 IBM saw that really compiling strings was MUCH faster. Basically PL/I and Fortran can be faster than C in array handling, and PL/I is faster than both C and Fortran in string handling.
(4) Structures. PL/I structures are just brilliant: Get to lay out some complicated looking trees with structures of arrays of structures of whatever elementary data types, and, still, ALL the addressing is just from the standard array addressing logic. And get to set the array bounds during execution via Automatic, Controlled, or Based -- powerful stuff. Then in tasking Controlled is tasked based so goes away on its own when not wanted.
(5) Exceptional condition handling in PL/I is gorgeous.
I like old Basic, Algol, Fortran, PL/I, the scripting language Prime used, the scripting language CMS on CP67 used, Rexx, Open Object Rexx, Kexx (with KEdit), the .NET version of Visual Basic. Is that enough? Oh, might as well consider TeX -- terrific stuff. I will probably like Power Shell when I take time out to learn enough of it. Am I out of the dog house now? Am I permitted to have a cookie, please?
Sometimes I wonder if anyone can write a JCL from scratch. A new JCL is always copied from an existing one and the gets modified. The first couple of lines of a JCL are particularly scary if I recollect properly.
The PDP-10 family ran a few operating systems in its life, some of which had better or worse user interfaces, but one of the things the all had in common was a focus on interactive use as opposed to batch operation or even block-mode terminals. Interactive use means each concurrent user represents more system load compared to the alternatives.
I appreciate the shout-out to the “Imprecise Interrupt” found only in the 360/91: “You divided by zero somewhere in there, but we’re not going to tell you where, and if you’ve done a Branch/Jump by the time we detected it, the current Instruction Pointer won’t give you much of a clue, either.” Fun times.
The 360/91's FPU was the first full on Tomasulo's algorithm OoO pipeline. Recovering from exceptions and unwinding state is one of the most difficult parts of those cores, so I don't really blame them for punting on that part
Later I used PL/I on CP67/CMS in Stamford to save FedEx the first time, to schedule the full planned 33 planes to cover the planned 90 cities. Founder, COB, CEO Smith's remark at the staff meeting was 'An amazing document, solves the most important problem facing Federal Express." Our two guys from BoD Member General Dynamics looked over the schedule and said "It's a little tight in a few places, but it's flyable." The BoD doubts were defeated; the BoD was pleased; crucial funding was enabled; and FedEx was saved.
PL/I is a nice language. When I got a phone interview from Google and they asked me what my favorite language was, of course I said PL/I. Apparently way wrong answer and they were looking for at least C and hopefully C++. I was later in the IBM Watson lab research group that did KnowledgeTool, a rule based pre-processor to PL/I. Some of my knowledge of PL/I internals let me do a trick that saved much of the language -- I got an award for that.
PL/I based structures are nearly as nice as C# objects and for addressing use essentially only generalized array addressing so are really fast. If want methods, then have some entry variables in the structure. For a light version of inheritance, use the attribute Like. For something like polymorphism, use Generics, or whatever it was called then, that is, the right version of the code is called depending on the types of what is passed. The scope of names support is terrific stuff. Similarly for the exception condition handling via On conditions and how they work with scope of names and the stack of dynamic descendancy.
There's a lot of good stuff in PL/I. Sorry people at Google didn't know about PL/I!
Sure, but that was already a solved problem outside Bell Labs, at least by reading IBM papers and interviews with well known compiler implementers from the 60 - 80's.
Not the OP, but you can find quite a good collection of info at https://www.multicians.org/, specially interesting is the B2 Security Evaluation (https://www.multicians.org/b2.html) with the pearl that none of the UNIX known exploits, possible due to C's lack of safety where possible to take advantage of on Multics, thanks PL/I.
Sadly, a buffer overflow attack has been found; it is possible to write bad PL/I. (The defective code is a user-space tool, so at best, a remote code exploit. No privilege escalation.)
A writeup is on my round tuit list; some day soon.
PL/I does bounds checking on arrays, but not on pointers.
The Kermit server allocated an insufficiently large buffer to decompress packets into, and used ptrs to write to the buffer. (Errors 1 and 2: allocation and ptrs)
Later in the code, there is a 'goto state(idx)' construct, with a declaration like 'dcl state (0:6) label init (state0, state1, ....);'.
Which label is jumped to depends on the value of idx.
The 'state' variable was not declared to be state (error 3), so the table is in writable memory, and due to whatever circumstances, is above the decompress buffer.
A correctly crafted packet, when decompressed, will write over the end of the buffer and onto the state array. Later, when the goto is executed, the address transferred has been changed. It is not the case that a transfer can be made into the decompress buffer, as it is not in an executable segment, there are lots of places that could be transferred to, leaving open the possibility of an exploit.
The error was discovered when a particular file transfer would reliably crash the kermit server, and analysis of the crash uncovered the coding errors.
Yes, when I was at IBM's Watson lab working in KnowledgeTool, a PL/I pre-processor (using some of Deremer's work, our software did fully parse the KnowledgeTool source and, thus, also PL/I), I got to chat with George Radin, essentially the father of PL/I.
For a while I was teaching computer science in the business school at Georgetown and taught a start on PL/I, e.g., enough to do quicksort.
I found this line interesting: “All of the reasonable designs that have been developed have been a lot closer to each other than people expected.”
It feels (to me, who is admittedly not a hardware person) as though instruction sets haven’t really been that important aside from a brief moment when RISC seemed revolutionary.
Intel, Alpha, ARM, SPARC, have clever legacy quirks and hacks. VLIW's, stack machines, tagged architectures etc. never took off.
RISC-V is the newest and coolest completely new instruction set. It's also one of the the most reasonable, practical and boring instruction sets you can imagine. It's basically updated and cleaned MIPS-style ISA with minimal surprises.
For modern high performance CPUs the benefit of RISC in terms of simpler/faster decoding fade a bit in relation to the memory bandwidth benefit of more concise instructions. Still, a lot of die space is dedicated to interpret x86 instructions and issue operations for the backend. I wouldn't mind having that silicon dedicated to more threads (which mean fewer context switches) or a larger cache (which somewhat negates the advantages of a more concise code)
Having a compressed ISA AND a smaller decoder is a win-win.
There are, sadly, non-intrinsic reasons why x86 holds the position it does - nobody has the kind of money Intel has to invest in high-performance desktop CPUs. The few companies that do either go after the x86 market or ignore the desktop and low/mid-range server niche.
My dad's factory in the 80s was managed by s360. I do not understand why, but 1 out of 4 companies in Italy I talk to, are still running AS400... This must be something like Maya architecture :)
> we wanted to emphasize that the architecture is, in fact, defined; the definition, however, specifies the operation to be unpredictable. That is, the operation may vary among models, and on any one model may differ among instances. Otherwise someone could ask when we are going to complete the definition.
This is quite an interesting way of combating Hyrum's Law!
https://books.google.com/books/about/IBM_s_360_and_Early_370...