{nonref}Promptness

A call to a key is said to be (_prompt) if it always returns within a reasonable (finite) length of time. A key is said to be prompt if all calls to it are prompt. All primary keys are prompt unless otherwise specified. A call to a prompt key will stall if there is another call in progress. Every call, once begun, is completed in a reasonable length of time, but since there may be a large number of processes stalled waiting to call the key, it is possible for a large (but still finite) delay to occur.
Some start keys lead to programs such as front ends {(p3,front-end)}. Such start keys may become available much sooner than they return. They may in fact become available promptly but not return promptly.

The above definition assumes that no disk pack remains unmounted forever. Many services, however, are concerned with promptness where some disk packs are unmounted. We need better definitions here.

See (p2,prompt1) about unprompt space banks, for example.

Promptness is likely to become a relative term. It is as if there were a hidden parameter in the term. This is satisfactory in most cases because a program need distinguish just two levels of promptness.

The following is a concrete example of the need for a program to determine the promptness of a start key before it calls the start key:

A segment creator runs in a single domain. It serves many users. Two space banks are required by the creator when a new segment is to be created. The first bank must be prompt and will be used directly by the creator to get a small fixed number of nodes and pages from which the initial segment and its keeper are created. The second bank need not be prompt. It is called by the keeper as new storage is required for the segment.

The creator should verify, by calling the transformer {(p2,sbtp)}, that the first bank is prompt.

The creator calls the first bank and if that bank were not prompt the creator might be out of business indefinitely. It is important that the second bank need not be prompt for the reasons described in (p2,prompt1).

A meter M is (_multiplex) if it answers the call M(1;==>c;N) by placing 0 in c and producing in N a new meter which does not "bog down" M and is multiplex. N is said to be derived from M. The Gnosis meters are designed to be used by gross schedulers to administrate resource allocation. Such schedulers are likely to impede the domains under a meter for long periods when those domains are resource bound. The scheduler impedes the domains by turning off the meter. Such a meter is said to be (_bogged down). Meters derived from multiplex meters are unable to use so many resources that the original multiplex meter is bogged down. Resource bound systems can be placed under N without causing non-bound programs under M to be impeded.

This needs to be redesigned without requiring explicit calls on meters for reasons given in (p1,tj).

A string of bytes in serial terminal format. Segment size convention gives length. When coercing to OS formats, data is copied until a Carriage Return is found and padded with blanks if necessary. The Carriage Return, plus any Line Feeds following it, are not presented to the program. When coercing from OS formats, the OS records are copied into the segment, any trailing blanks are removed, and a Carriage Return plus Line Feed is appended to each one.
Problems:
ASCII or EBCDIC

What about terminal dependent screen formatting orders?

Advantages:
This format probably provides the most compact storage format for textual data available.

This format allows "unlimited" length records.

Because this format does not have imbedded control information, it allows programs to easily process data on arbitrary delimiters.

This format is simple to implement and easy to understand.

Disadvantages:
This format requires that the OS simulator copy the data.

This format allows for only sequential forward access.

An array of fixed length records. Segment size convention gives length.
Advantages:
This format allows efficient random access.

Because this format does not have imbedded control information, it allows programs to easily process data on arbitrary delimiters.

This format is simple to implement and easy to understand.

Disadvantages:
This format is wasteful of storage for many applications.

A collection of variable length records in standard os variable length record format. N.B. Standard OS format includes spanned records! Segment size convention gives length.
Advantages:
This format allows QSAM programs to treat the segment as one giant block. QSAM programs can process the records directly in the segment without having the OS simulator copy it.

Disadvantages:
This format allows for only sequential forward access.

A collection of variable length blocks in standard os variable length block format. Each block contains variable length records in standard os variable length record format. N.B. Standard OS format includes spanned records! Segment size convention gives length.
Advantages:
This format allows BSAM and QSAM programs to treat the segment as one giant block. BSAM and QSAM programs can process the blocks and records directly in the segment without having the OS simulator copy it.

Disadvantages:
This format allows for only sequential forward access.

A collection of variable length records with a full word length followed by the record. Segment size convention gives length.
Advantages:
This format allows for adequate size records.

Disadvantages:
This format requires that the OS simulator copy the record before the OS program can operate on it.

This format allows for only sequential forward access.

A collection of variable length records with a full word length followed by the record. The end of the segment (2**48-1 and below) holds a table of record starting addresses that can be used for reading backwards and fast random access.
Advantages:
This format allows for adequate size records.

This format allows for random access.

Disadvantages:
This format requires that the OS simulator copy the record before the OS program can operate on it.

This format does not allow for the segment length convention.

When an object fails in Gnosis it would be nice to notify the user of the object that the failure has occurred. The following are some conventions for implementing this notification.

For the moment we will define a failure to be when a virtual domain keeper (vdk) creates a real DDT over the domain. Other definitions will be necessary for programs like Pascal and PL/I which trap all failures through SPIE and STAE. It may be the use of the standard input/output keys by their internal debugger/error monitor. It would be useful for the %F command in DDT to clean up the DDT and restore the virtual domain keeper as keeper of the domain.

%F does that, but it does not reclaim the space it should.

If the object runs under the caller's meter then an order code can be defined to call a meter keeper {somewhere up the meter hierarchy} that a failure has occured. This call could include authority to communicate with:
The debugger over the domain or

the owner of the object {via a mail system}.

Each meter keeper would either act on the order code or just reflect it up the hierarchy to the next meter keeper. If it got all the way to the prime meter then KT+2 {undefined order code} could be returned to the caller.

Notes on Above by Norm {with comments by *Bill})

It seems to me that something much like this is needed. There are alarm bells ringing somewhere however.

A practical problem is that now every meter must be equipped with a keeper, which is not now the case. In fact each keeper should obey this convention. I am not sure about the loyality of some of these keepers.

This convention would somehow {I have faith} be thwarted in some cases by factories because it is counter to the purpose of keeping the object inventor uninformed. Indeed in the classic factory justification there is no one{!} who can look into the domain. I hasten to admit that something like the above is needed in common cases however.

In this case it is hard to argue that the object inventor needs to {or can} keep a secret of the fact that is code broke.

There may be conflicts here with yet undefined scheduling use of meters.

I am reminded of the dilemma of "how soon do you send out a search party" after a failure to return.

I am attracted to the semantics of PL/I's SIGNALS except I don't know how to implement them {efficiently & transparently} and I am not sure that they are any more compatible with Gnosis principles.

I think that the PL/I semantics can be described as follows: Suppose that each PL/I procedure were augmented by a "in case of error" parameter and that each procedure call were augmented by a "in case of error" argument. The value passed in these cases would be a procedure. This procedure is called upon error. Any of the so augmented routines is free to execute an "ON ERROR" command and effectively replace the error procedure for the duration of its activation.

It is common practice to give an object a key to the space bank from which it was created. This makes it possible to define a call on the object to destroy itself without requiring the caller to pass the space bank. A subtle consequence of this is the bank from which object X is created should not be destroyed until after X is destroyed.

See (fb) for ideas that may support this stuff.

Several qualities come to mind that justify such treatment:

Discreetness (No Spy)
The discretion of a factory and the objects that it produces is described by the .holes {(p2,hole)}.

Promptness (No Delay)
Promptness is now considered a binary quality. With current space bank design unpromptness of a bank stems from more fundamental banks whose exhaustion reports are diverted from the caller {(p2,prompt1)}.

A given bank is prone to delay by each such diversion. If one bank is subject to each diversion that another one is, we might say that the second one is as prompt as the first.

Integrity -- Durability
I think that we should combine durability and integrity under the name "integrity". See (vb).

Integrity (No Sabotage)

Our current space banks are currently the same with regard to this. If we produced banks and transformers that produced pages and nodes that were subject to prying by some powerful debugger, such nodes would be not only indiscreet but also provide potentially less integrity. We can again imagine degrees of integrity.

Durability (No Destroy)
Banks that are guarded or depend upon such banks produces pages and nodes that are subject to disappearing. Again this depends on who holds what keys that may be used to "pull the plug". It again seems possible to profitably compare two banks perhaps to ascertain that one will not recall its pages any sooner than another.

To be able to destroy without being able to sabotage seems unlikely just now.

Uniqueness (No Copy)
Some space banks may be equiped to make copies of the material controlled by them. Such banks are inappropriate for some purposes.

Degrees measured by sets of keys
Factories have been designed and built to support the notion of a degree of discreetness. This degree denotes an obscured set of .holes. We say "obscured" because the holder of the requestor's key cannot directly discern the members of this set. He can, however ask if the set of one factory is included in the set of another factory. We call these obscured set values "lattice values".

In each of the above cases we can measure the quality in terms of a set of obstacles to that quality. An obstacle to durability is that some particular space bank in an object is guarded. This is manifest in that some key to a guard, if invoked, will ruin the object. We say that this key is a guard for the object. If the set of guard keys for A is included in the set of guard keys for B we say that A is as durable as B. It seems that the obstacles to other qualities are keys also.

Disappearance of obstacles
Banks may become more discreet if they lose some of their holes. This may occur when some factory disappears and a requestor's key to that factory is held as a component by another factory.

We judge that this increase in discreetness may be unimportant and that implementations of key set value abstractions will be constant when keys disappear. We might justify this by saying the key to the old object still exists, merely that slots holding keys to the old object get DK(0) when that object ceases to exist.

This greatly simplifies the implementation of the key set abstraction. A key set value is now constant after its creation.

See (p2,kid) for current lattice function and (formative,kid) for some older ideas.