3 ms·

COBOL development had (has?) a completely different development and deployment experience. Sure, you keyed your code directly into the mainframe, but your code

by delinka 10y ago

COBOL development had (has?) a completely different development and deployment experience. Sure, you keyed your code directly into the mainframe, but your code and your session were isolated - you, the developer, had limited privileges. Only once your code took the prescribed input and produce the prescribed output was it allowed near "production" data. That said, the language itself was (is?) so limited in scope and ability that stability was nearly guaranteed. You READ and PRINT using tape or disk and printers, but the programmer didn't worry about what devices were available - some system admin pointed these devices at a job, and READ came from that tape and PRINT went to that printer. The setup and management of the jobs that ran your code was a very manual process. No pointers, no memory management ... nothing low-level at all. Just high-level abstraction. Then there's hardware reliability. As an example: you can walk inside the mainframe, pull a CPU, and the thing keeps working. Replace that CPU, and the system makes use of it. None of the system's users ever know that it happened.

ams6110 10y ago
That job setup uses a language called JCL. And while COBOL reads more or less like english statements, to the point that anyone who has ever programmed procedurally could follow it, JCL is quite inscrutable. One old joke was that nobody ever writes JCL from scratch, they just take what worked last time and change the dataset names. http://www.jargon.net/jargon/jargonfile/j/JCL.html http://www.jargon.net/jargon/jargonfile/j/JCL.html
sedachv 10y ago
> Then there's hardware reliability. As an example: you can walk inside the mainframe, pull a CPU, and the thing keeps working. Replace that CPU, and the system makes use of it. None of the system's users ever know that it happened. From what I understand, until Tandem came along and started to seriously eat away at the market in the late 1970s and forced all the other manufacturers to follow, mainframes were not known for reliability.
- nickpsecurity 10y ago
  Im still looking for data myself on reliability over time. I recall one OS for IBM mainframes bragging about its reliability because it ran six months or so without a reboot. I was think, "Wow... some good numbers there..."

by delinka 10y ago

ams6110 10y ago

That job setup uses a language called JCL. And while COBOL reads more or less like english statements, to the point that anyone who has ever programmed procedurally could follow it, JCL is quite inscrutable. One old joke was that nobody ever writes JCL from scratch, they just take what worked last time and change the dataset names. http://www.jargon.net/jargon/jargonfile/j/JCL.html http://www.jargon.net/jargon/jargonfile/j/JCL.html

sedachv 10y ago

> Then there's hardware reliability. As an example: you can walk inside the mainframe, pull a CPU, and the thing keeps working. Replace that CPU, and the system makes use of it. None of the system's users ever know that it happened. From what I understand, until Tandem came along and started to seriously eat away at the market in the late 1970s and forced all the other manufacturers to follow, mainframes were not known for reliability.

nickpsecurity 10y ago
Im still looking for data myself on reliability over time. I recall one OS for IBM mainframes bragging about its reliability because it ran six months or so without a reboot. I was think, "Wow... some good numbers there..."