Invoking is the basic operation on keys. Invoking a key is also called jumping at the key and an invocation is called a jump.
Parameters
Step 2. The action of invoking the key takes place. This action varies according to the specific key invoked. If the key to be invoked is a gate key, see (p1,gates). If the key to be invoked is not a gate key, see (p2,primary).
With few exceptions, step 1 is {conceptually} completed before step 2 is begun. Step 1 is the same regardless of what key is to be invoked or what the parameters are, and step 2 is the same regardless of the invoking domain or its state. This means that effects flow only from the invoking domain to the invoked key and not in the other direction.
The exceptions are:
If the invoked key is a start key, see (p1,entrystall).
{arcane}The invoking domain will stall until all pages and nodes needed to complete the jump are in core. This statement is at the kernel level of description. For example, in the case of keys other than gates, the last key parameter, which must be a resume key, refers to a domain and that domain must be in core to complete the jump. This situation will be brief unless a page or node is dismounted. See also (p2,returner-note).
To this extent, gate jumps and primary jumps are different. This might interfere with synthesizing primary keys: the user might sense the difference with charge sets. However, the difference is easily detectable by anyone with access to the real-time clock, so this difference does not represent a serious security exposure.
{ni}Some versions of Gnosis may provide buffering to avoid stalling. In this case the invoked key and the parameters would be held in a (_jump packet) and the disposition of the invoking domain would occur immediately. For example, a domain executing a fork to a start key to a busy domain could find that the fork completes, that is, the domain goes on to the instruction after the fork, while the action of invoking the start key has not yet occurred. You should not write programs that depend on the effects of stalling.
Gate keys that accept strings in two pages {see (p1,stringcopy)}.
All of the action of invoking the key {at the kernel level of description} depends on the meter of the invoking domain.
MMMM AA00 GGGG 0000 KKKK KKKK KKKK KKKK (8*)CCCC
"MMMM" Key argument presence bits - (keyargs) "GGGG" Gate key - (gatekey) "AA" String argument control - (argpage) "KKKK" Key argument slot numbers (keyargs) "CCCC" Order code - (ordercode)
If bits 4 & 5 of the exit block are 00 a zero length string is provided.
If bits 4 & 5 of the exit block are 10 the domain gets trap code '050000000002'. {This combination once specified that the string was held in a page designated by a key.}
To depict the code that calls key G we will write: "G(...;...==>...;...)". In this notation the text between "(" and "==>" denotes the values {arguments} passed to G. Since the invocation is a call, a return key to the invoking domain is passed {but not shown}. Assuming that that the return key is later invoked, the text between "==>" and "(" denotes the values passed {i.e., returned to the original domain}. In both cases, the text before the ";" represents the data, and the text following represents the keys.
In representing the data values passed and returned, the field may be: "" {empty}, "oc" or "oc, bs". Here "oc" means order code and "bs" means byte string. The notation "((2,u), (6,b))", for example, denotes an 8-byte string consisting of a 2 byte field of value u followed by a 6-byte field of value b. If the order code is omitted it is assumed to be zero.
In the key parameters and results, 0 to 4 key slots may be mentioned, separated by commas.
Thus "direc(3,'puzle.for';==>c;K)" might depict a call to a directory entry "direc" offering order code 3 and name "puzle.for", expecting in return an error code c and a key K.