Case Study: IBM's System/360-370 Architecture (1987) [pdf]
cs.tufts.edu
cs.tufts.edu
https://books.google.com/books/about/IBM_s_360_and_Early_370...
> 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.
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".
Again, what examples of existing languages were available at the time the JCL was invented?
It says this was introduced "soon after 1961", though I doubt the IBM people were aware of it.
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.
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.
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!!
But it sounds like you have a lot of issues with how a lot of the computer languages work.
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?
> 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.
[1] https://cacm.acm.org/magazines/2015/11/193333-an-interview-w...
There he really nailed the problems with JCL.
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!
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!
And what was the role of PL/I in Multics?
See https://multicians.org/pl1.html for details.
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.
I always find such stories interesting.
At one point I did have Level 6 (root) on all of BT's primes and level 7 on the billing systems.
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.
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.
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.
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.
This is quite an interesting way of combating Hyrum's Law!