If P is a segment key whose databyte bit 1 {no-call (p1,nocall)} is zero and whose bits 4:7 are 0 {thus a red segment key} and P designates a node whose slot 15 holds a well formed format key {(p1,redseg)} indicating a segment keeper key {(p1, segkeepslot)} then any jump to P goes to the segment keeper key.

If bit -29 {(p1,bit-num)} of the data key in slot 15 of the segment node {(p1,nonodekey)} is off, the segment keeper receives a node key to the segment node as key parameter 2. The key argument 2 offered by the jumper is lost. The databyte of the node key is from the segment key. {This is also described in (p1, nonodekey).}

{arcane}If the segment node is the jumper's domain root or general registers node, the jumper traps instead of jumping {(p1, worsejump50)}.

{arcane}Design Notes:

Why we switched from passing the fault address to a segment keeper via a data key to passing it via a string argument.
The holder of a segment key to a node with a keeper is in a position to fake a fault and cause the keeper to execute its algorithm when there was no fault. This is not serious if argument 1 {DK(invalid address)} is suitable for that algorithm. If that argument were, however an unprompt key the keeper would delayed. The keeper could use DISCRIM to verify that argument 1 was a data key but this would be an unfortunate cost.

If the implicit jump to a segment keeper were to provide the address argument as a byte string we would not only avoid the use of DISCRIM but also the cost of calling the data key. We did not do this in the beginning because it was difficult to implement as the kernel was then coded. It is now easy.

Passing Three Keys.
With the current red segment node design only two keys may be passed to the segment keeper upon an explicit call.

If it becomes useful to be able to pass three keys, another field could be allocated in the format key to name a slot within the red node where key argument 2 from the jumper is to be placed. See (p1,localslot) for a design.

Avoiding fake keeper calls
There is a hazard that a call to a red segment node may be misinterpreted by the segment keeper as a segment fault.

We have not seen cases where this possibility has been catastrophic but:

It is a pitfall for a segment keeper written without this possibility in mind.

It might be a true impediment to some uninvented scheme.

Here is a fix to this wart if it should become necessary:
Define a new four bit field in the format key to designate a slot in the red segment node to receive the order code from an explicit jump if that code be between -256 and 0 and in such case provide -256 as the order code to the keeper.

In this scheme the overhead of code substitution occurs only when explicit jumps specify order codes that might be confused with segment faults.

N(0;==>;K) returns a key like N except the read only bit is 1.

N(kt;==>c;) returns binary RLLLL00000101 in c where R is the read only bit {(p1,robit)} and LLLL is the lss field from the key {(p1,lss)}.