A principal benefit of higher-level languages is to provide access to the functionality of the computing environment while suppressing much of the detail. One measure of the success of this is that the PL/I manual provides the information necessary to use a great deal of the functionality of MVS. The bulk of the manuals necessary for the assembler language programmer to harness the same MVS function is about ten times as great as the PL/I language reference manual.

We have extended PL/I and Pascal to incorporate Gnosis functionality.

In one sense we have done this with the provision for gate jumps expressed in PL/I {(pliext)}.

While these extensions provide access to the complete Gnosis functionality they do so by requiring the PL/I programmer to delve into Gnosis esoterica that seems, somehow, at a level inappropriate to PL/I.

The problems are two-fold:

PL/I multitasking is not yet supported in Gnosis despite the fact the Gnosis supports that function,

Functionality unique to Gnosis is not supported at a level consistent with PL/I.

Programs not written for Gnosis but required to run under Gnosis.

Programs written for Gnosis whose purpose it is to support programs in the next category.

Programs written for Gnosis at a semantic level compatible with PL/I.

We enumerate some functions that are commonly needed but not yet supported naturally by PL/I:

Multitasking
PL/I's multitasking is rather rich in that it supports many levels of sharing of storage as does our binder. This sharing is done under the assumption that the various tasks are running in the same address space. Tasks retain a dependency relationship which reflects their ancestry. {If A spawns B then A must last while B does.}

The normal Gnosis style of multiprogramming is to place each task in a different address space. The address map enforces the separation between tasks that the semantics of the language call for but that the MVS implementation does not enforce.

An esoteric violation is to copy {via external storage} a pointer to a variable in the automatic storage of task A to the storage of task B. This will "work" as long as task A remains active. It would not work even temporarily if tasks A and B were in different address spaces.

I think that we can support the PL/I task semantics better, in some ways, than MVS.

Co-routines: Producer - Consumer relationships
The Gnosis byte stream and the Unix pipes constitute a popular idea of how to organize programs.
Gnosis has over Unix the fact that a domain may delegate its responsibility to another program in another domain.

Unix has over Gnosis the fact that the scheduler can observe fullness of pipe buffers and schedule accordingly.

A PL/I construct that seems to be a part of this idea is the record or stream I/O.

With sufficient use of defaults one can write PL/I I/O statements whose semantics correspond to the simple idea of getting or putting the next of a sequence of values.

PL/I can pass off a file to another program but this is done with a reference to memory that is assumed to be shared with the called routine.