The Pankian Metaphor 3131

trivial preprocessor would open some number of default files with some amount of default allocation ... and then hope that most applications would never exceed the default ... somewhat like a lot of desktop applications. lots of the "system monitors" from the period implemented that sort of paradigm for one reason or another. A fairly representative case that is still around is CICS that provides support for "light-weight" transaction subsystem environment. Most CICS light-weight stuff only require a trivial amount of system resources (much more akin to many interactive commands in other kinds of interactive systems). CICS acquires a large block of system resources and then manages them internally for light-weight transaction operation (w-o having to go thru the normal system resource management processes for every light-weight transaction).

part of all this was starting way back in the days of real storage paradigm and much less resources. major applications could require both tapes as well as disks to be mounted on drives ... potentially all available drives (nearly all available resources). with PCP (no multiprogrammer) ... there was the real storage not required by the system, application either fit or it didn't.

later MFT & MVT supported multi-programming. regions with max amount of allocated real storage was defined. "jobs" had max real storage requirement which then mapped to a job "clbutt" that would feed to processing "region" that allowed at least that amount of real storage.

the "x37" processing aborts (abends) were when resources ran out. default was to take default system termination. however, applications could set up traps for nearly every kind of abort and attempt remedial action.

this was more typical for service oriented applications that provided online support ... and had application specific programming for recovery from numerous kinds of anomolous operation ... as part of providing availability. other events were things that had specific deadlines and requirements to be run ... say like periodic payroll for large organization ... where tens or hundreds of thousands (or even millions) of people were expecting to be paid on specific date.

a typical payroll application might have various kinds of processing plus a sort phase before printing checks. a mission critical application might have a B37 abort trap provided (exhaust all available disk space). The B37 trap might do things like invoke system backup-archive-removal of non-critical files (i.e. the files would still be listed in system directory but have been moved to some other media). Then the B37 trap would restart processing in attempting to complete.

ten years ago, i did a comparison of moving such an application to a platform that had much less mission-critical derived infrastructure. put in into regular use ... but one run happened to exhaust available disk space during sort processing. the system file processing reflected end-of-file to sort ... which then continued processing using abbreviated set of entries. The final result had a file listing only about ten percent of the total people ... but completed w-o any obvious error condition.

... a little drift about CICS subsystem monitor. it had been developed at a customer site in the midwest (possibly utility company or some such). IBM decided to turn it into standard product offering. A few customers were selected to "beta-test" the product before general availability. One was the university library that had a ONR grant to do an online "card" catalog. As a result, one of the other things I got to work on as an undergraduate was debugging various early CICS problems (primarily related to the library attempting to define CICS configruation & use that hadn't been done before). misc. past posts mentioning CICS

--