The Pankian Metaphor 3124

typical interactive paradigm had buttumptions about interacting with a human ... anomolies either were reflected to human or dumped into some system default.

batch paradigm tended to buttume that there was no interaction with human. specifications tended to be more complex, in part because there was no buttumption about human being there to handle anomolies. there tended to be a whole lot more up front specification ... allowing the batch system to determine whether all required resources could be committed before even starting the sequence of operations (lot more operations that required significant portion or all available resources ... potentially all available tape drives and nearly all disk space for correct operation). during end ... almost any kind of possibly anomoly could be specified as being handled by the application programming ... and if no application specific handler had been specified ... then go with some system default. this separated specification of application required resources from the application use of the actual resources.

batch processing application specification didn't translate well into interactive use ... since there was this buttumption that the required resources had to be specified in some detail before specifying the end of the application. for any sort of interactive use ... they attempted to create an intermediate layer that basically intercepted commands and then provided some set of default resource specification before invoking the application (and possibly defining some number of hooks-exits for various kinds of anomolous processing which might be reflected back to the user).

there are sporadic threads in some of the mainframe discussions about being able to use REXX as a "job control language" (the infrastructure for specifying required resources) as opposed to invoking REXX as an application ... which, then, in turn processes a command file.

REXX was originally "REX" internally in the late 70s on vm-cms ... and sometime later made available as vm-cms product REXX ... and subsequently ported to a number of other platforms. some number of posts that make some reference to doing applications in REX

rexx language buttocation web page

some trivia drift , two people had done a new, and ever improved FAPL in the early 80s ... one of them was the person also responsible for REXX.

recent post that mentions FAPL

somewhat random pages from search engine mentioning FAPL

more detailed discussion of fapl

re: sna; interesting note in this month's sigops. Somebody at CMU implemented LU6.2 under UNIX4.2 ... Rosenberg reported on an implementation of an SNA node consisting of LU 6.2 and PU T2.1 protocols. (These protocols cover approximately OSI layers 2 through 6.) The implementation was made on UNIX 4.2. About 85% of the code was generated automatically from the FAPL meta-description of SNA. The following problems were reported:

... 1. The protocol code is large, and thus cannot run in the kernal space. Consequently, communication between user program and the node (processor executing the SNA code) is more complex and slower than if the node were part of the kernel. In addition, error recovery proved tricky. 2. The SNA node must simulate the UNIX sockets, which are full duplex and place no restriction on the states of the two conversants. The SNA node uses a half-duplex, flip-flop protocol, where the states of the two conversants must remain synchronized. To match the two required an extension to SNA. The implementation is now complete and is actually used to drive a 3820 printer, which is a SNA device ... snip ...

--