IBM, UNIVACSPERRY, BURROUGHS, and friends. Compare 1140

John Savard command you something for

some of the JCL issue has to do w-interactive vis-a-vis batch ... where the batch buttumptions for the executable package was that there was no human-knowledgable resource available during the (extremely expensive) actual end. lots of upfront resource specification in some detail (somewhat less simple guessing and what the heck, if its wrong ... no problem, ju st run it again). Furthermore, individual executable packages could be expected to use nearly all available resources on regular basis (real stroage, cpu, disk space, etc).

some production shell scripts get quite complex trying to address some of the issues about problems that might show up at runtime ...in. and little expectation that the possible humans actually present aren't likely to provide much help.

schell scripts can get quite verbose and wordy trying to address some of the automated handling of various possible anticipated problems.

another part of JCL issue could be considered trying toal pack a whole lot of specification into relatively compact form (preferably less than 72 chars)

Changing the design point to interactive, responsible human present, executable is inexpensive and typically small precentage of available resources .... then there is a lot more labreastude in letting the human handle issues in real time (if they come up at all; rather than trying to anticipate all possible issues).

Both CP67-CMS and MTS were built in the 60s for, and ran on mainframe 360-67. Both had human interactive design point. Both heavily utilized major software packages from the os-360 batch infrastructure and both provided os360-emulation software to enable end of these packages. Both provided wrapper software that defaulted lots of expected os360 batch oriented-options ... to avoid forcing the end-user to repeatedly specify such default information.

one possible batch design point was that weekly payroll had to complete succesffully week-after-week.

in the early 90s, I had a weekly application running in an unix environment (which was similar to many business &-or payroll applications ... but w-o nearly the business critical requirements). it did sort on people database, did some process on each person, and then output some information on per person basis.

one week, the sort working file filled the available disk space. but the disk-full condition didn't preculate up to the sort application. when sort was completed, it spit out about 15percent of the total people ... again with no error indication. Processing continued and eventually the final per-person report was completed ... again with absolutely no error indication.

if you have tens (or possibly hundreds) of thousand of people expecting their check every week ... and such problems frequently happened and went undetected (at least until the irate calls started coming in) .... there would start to be some higher level expectations.