Language Restrictions for Gnosis

CHECKPOINT/RESTART is not supported.

The position options of OPEN and CLOSE are ignored.

User Labels are not supported.

SORT is not supported.

Segmentation is not supported.

Dynamic subroutine linkages are not supported.

See (p3,osiorestrict) for further hints about file support.

We need the ability to save and refer to keys, conventions for order codes and return codes, mechanisms for sending and receiving message strings {with, if possible, some way for the receiving program to find out that an incoming message wouldn't fit in the space provided}, language to specify the three kinds of jumps {call, fork and return}, and a facility for a called domain to examine the databyte of the key via which it was entered.
{arch}We might also like to offer a way for the COBOL programmer to specify, at the time a domain makes itself available by return-jumping, where the domain's .program should begin execution the next time someone jumps an entry key to it.
About half a page beyond (p1, gates) appears the assertion "the gate to a domain restricts the holder merely to starting the program AT A PLACE SPECIFIED BY THE DOMAIN and offering some data and authority." {Emphasis added.} The architecture of Gnosis includes the concept of the domain state saved by the kernel; one element of that is a representation of where the domain's program will begin execution the next time a gate to it is jumped.

Thus, a return-jump still acts more like the typical machine-language CALL {which saves a "location counter" somewhere} than like the typical RETURN {which restores {part of} an earlier state without saving the current state}.

The language features discussed below are documented in IBM publication number GC26-3857-2 (_IBM VS COBOL for OS/VS). Page references in the form [IVCnnn] are to that manual.
To the COBOL programmer, RETURN denotes a statement which transfers records from the final phase of a sort or merge operation to an I/O area [IVC242]. What most other languages mean by RETURN is expressed in COBOL by EXIT PROGRAM [IVC305] or GOBACK [IVC306].

The IBM extension RETURN-CODE is documented at [IVC354] along with other extension collectively referred to as "special registers".

It has the implicit description PIC S9999 COMP, and can be set by the user to pass a return code to the invoking program or the system before executing an EXIT PROGRAM or GOBACK statement. When control is returned to the invoking program, the code passed by the called program is stored in the calling program's RETURN-CODE special register. The compiler initializes the field to zero; the maximum value the field can contain is 4095.
There is nothing in [IVC354] about minimum values, but it appears that, despite the "S" in the implied picture, negative values are ruled out. {Would you believe the compiler wants to generate "LA 15,value" instructions?}

The restriction to 12-bit values makes RETURN-CODE undesirable as a repository for the GO/370 return code. It might still be useful as a way for a gate-interface routine to report message string overrun to the COBOL program.

Via the ENTRY statement [IVC305], an extension to the ANSI standard language, IBM COBOL supports multiple entry points to a program. This may be useful in implementing the concepts represented by KENTRY and KENTRYID in PL/I if it is deemed desirable to mimic these features of Gnosis PL/I language support.

{ni}Here are some possible approaches to gate jump support.
A Gnosis message consists of a word, four keys and a string of from 0 to 4096 bytes.
Actually, there is one more component implicit in the key which was jumped to enter the domain, namely, the databyte {(p1, databyte)}. For a return (exit) key, the databyte is zero. For a start key, the databyte may have any value from 0 to 255 inclusive.

Imagine a record with fields for each of these components. Such a record would be used to either send or receive a message. The keys would be represented by integers as in PL/I support.

For programs that receive strings in a variety of formats the string portion of the record would be an undifferentiated string of maximum length.

Some global variable called "DATABYTE" might hold the databyte of the start key that delivered the most recent message.

The jump mechanism must know the length of the string. This is required both for sending and receiving a message. Cobol does not transmit the length to a called subroutine. There are two proposed schemes:

A field of the record could provide the length.

A field of the record following the real stuff could be passed as an extra argument thus allowing the jump mechanism to deduce the length.

These both assume that Cobol's rules for positioning fields within a record are simple byte alignment.

Another problem is to get the arithmetic values to and from the fields within the record. The S and SI functions of PL/I do this. Cobol has no functions.