IBM, UNIVACSPERRY, BURROUGHS, and friends. Compare 1141

John Savard

I'd love to see some discussion of Burroughs and Univac vs. IBM. I can't contribute much, me experience with Burroughs is ancient (ca. 1972, B-5500), and I have only a nodding acquaintence with Univac.

JCL is an acquired taste. It is big and complex, but you can do everything with it but cook your lunch. We've had this discussion before, too, but one of the jobs of JCL is resource scheduling. It lays out everything your job will need to run, and a step won't be started until everything is available. This was before virtual memory, so you had to specify (in MVT) the memory size your job needed. You also identified any non-sharable devices you needed: tapes, private disk packs, and stuff like printers and card-readers (no spooling in those days). The system interpreted your JCL, gathered up all the resources you needed, and *then* ran your job. No getting 5 steps into a 6-step job and discovering that you needed another tape drive that was offline for maintenance; no deadly embrace between jobs who each needed resources that the other owned.

Unix command-lines are fine for a time-sharing system where basically everything is shared and non-sharable resources are the exception, but they fail miserably in the other case.

JCL looks especially bad today because it was designed to look like macro buttembler, and not too many people program in buttembler today, but there is a one-to-one correspondence between many JCL constructs and buttembler constructs, the idea being that a programmer should have been able to understand it right-off. The notorious DCB=(...) parameters, for example, match what the programmer would code in the DCB macro to define a file in his program.