Start keys and primary keys are purposely designed to be interchangeable.

This policy provides the opportunity to change the design of Gnosis by moving functions into and out of the kernel without changing the logical environment of programs. This policy also provides an opportunity to provide variant environments and debugging environments by substituting custom entries for primary keys.

The advantages are simple and direct.
The building of memory trees is better hidden.

Many programs no longer have to handle any page keys.

In many cases the parameter string and argument string do not have to be copied by the user.

No general key slot is needed to hold the parameter page key.

Sympathetic domains can share parameter pages. This cuts the cost of some of the terminal domain clusters, such as terminal support systems {(p2,tssc)}, by a factor of three.

The problems are obscure but real.
Consider the dilemma of the jumpee's parameter string being in a segment access to which requires calling that segment's keeper. This keeper must be provided with a resume key, presumably a fault key. If it were a fault key, the keeper would be able to trap the jumper, contrary to the principle of not allowing signals across jumps in that direction. One solution would be to provide a restart key in this case. This would cause a signal, presumably intended for the jumpee from the segment keeper, to be lost. Another problem is that we seem compelled to admit that there is still a process in the jumpee at the same time that we have a resume key for the jumpee!
A solution to the above involves defining a new state for a domain while it is trying to copy the argument string of a jump. We could even allow very long strings if we included in that state the kind of information that MVCL saves between interrupts.

Another solution is to invent a new kind of resume key, called a null resume key. When a jumpee's indicated parameter address required calling a segment keeper, the jumpee would be made busy, the segment keeper would get a null resume key to the jumpee and the jumper would be left with its process. When a null resume key is jumped to, the jumpee is made available and no process is left there. This would, in turn, cause the original jumper to retry the original jump. If a null resume key is jumped to with a nonzero code, that code is placed in the trap code of the designated domain.

Making available isn't right if the jumper is using a resume key to the jumpee!

Another disadvantage is that a caller of a public service is in a position to make the service un-prompt. If the caller specifies accepting returned parameter string in a segment with a slow keeper, the server will be delayed trying to return the answer and thus be unable to serve other clients.
The external returner is a poor answer here because the load on the external returner would be a function of programming practices instead merely of operating practices.
The external returner might solve the problem if the kernel were changed so as to give the external returner a new kind of resume key that provides for fetching a key from a specific slot of the indicated domain.

The external returner might use this resume key to get a prompt space bank that would be used to support the cost of keeping the string.

This might involve a difficult recursion problem -- the space bank may use the external returner who uses the space bank.

A similar strategy would be to have a class of external returners. The kernel would find a key to a returner in the jumpee's domain root. Such a returner would have to be somehow manifestly prompt to the kernel.

If we require that the parameter string be accepted without calling a segment keeper then we are open to a class of infrequent bugs.
In particular the virtual copy segment keeper was once written so that when the SSC of the top node of the segment was increased all of the pages were made unavailable for a moment while the keys in the top node were shuffled around.

It turns out in this case that a small change to this keeper overcame this deficiency.

I think the keeper FSX doesn't have this undesirable property.

Other segment keepers have been invented but not written {(p3,expseg)} that must make pages go for long periods of time.

The plex below this statement is two alternatives to the present spec. It is a proposed kernel architecture change. {I currently favor the scheme at (parmfault) which is somewhat different from either of these.}
Simple
A portion of the parameter string may designate a page that is undefined by the memory tree or is read-only. If an argument string portion belongs there the whole gate jump is nullified and the segment keeper is called with a restart key to the jumper in place of the fault key to the referencing domain.

If the restart key is used to attempt to trap the referencer, the signal is lost.

Complex
If we were to place a restart key to the jumper somewhere in the jumpee and leave the jumpee in a special mode, and give the segment keeper a fault key to the jumpee then the right information remains in the system to make things work.

There would be a new state, X, for a domain that would presumably be a variant on the waiting state.

When a gate jump is impeded by a parameter string that occupies an absent or read-only page and there is a segment keeper, the jumpee is put into state X, a restart key to the jumper is placed in some newly allocated slot of the jumpee, and a fault key to the jumpee is provided to the segment keeper.

When a resume key is used to jump to a domain in state X the jump is to the resume key found therein instead, but first any fault code is installed in the jumpee.

I am not sure that I see the ramifications of the complex scheme. If it there are no adverse ramifications then it should be easy to convert from the simple scheme to the complex scheme at a later date. I am inclined to do the simple scheme now.

See (parmfault) for another idea.

A painfully complex but seemingly complete solution to the above problem.
This is an idea that has evolved from the ideas around (parmfault).

Presume two new kinds of resume key, the available resume key and the waiting resume key collectively called "idle resume keys". Resume keys that are not idle resume keys {old style resume keys} are called "running resume keys". Presume also a superwaiting state of a domain. {Slot 13 holds DK(2).} Changes to the kernel specification are:

When an {available or waiting} domain D with a nonzero trap code is entered with a start key, the jumper is stalled {on D's queue} and a jump is made to D's domain keeper {who had better have a zero trap code}. D is made "waiting" and an {available or waiting} resume key to D is produced for the keeper.

If a jump is made to domain D and the argument string requires a part of the parameter string that cannot be stored into D's address segment, and a segmnet keeper might fix this situation then: an available or waiting resume key {depending on whether D was available or waiting} is produced to D for the segment keeper, and D is placed in the superwaiting state,

Start keys and running resume keys cannot enter superwaiting domains. The jumper becomes stalled instead.

When an {available or waiting} resume key is used to jump to a domain D, the order code {of the jump} becomes D's trap code {replacing the old trap code}. D becomes available or waiting. {Using idle resume keys does not cause resume keys to be destroyed.} Domains enqueued on D are awakened.

Let's imagine a sequence where a segment keeper decides that the segment may not be written into and provides a fault signal. We shall see that the right thing happens.
A invokes a resume key to B passing a long argument string. Part of B's parameter string is at a read-only address with a segment keeper C.

C gets a waiting resume key WE for D. After consideration C decides that no store should be allowed and invokes WE with an order code indicating refusal.

The order code becomes B's trap code and B changes to "waiting".

A is awakened and reinvokes the resume key to B.

We now have a invocation of a waiting domain with a trap code. B's domain keeper D is called with a waiting resume key WE to B.

D sees in B the trap code provided by the segment keeper. If D is DDT a status command might indicate that the domain was superbusy {slot 13 holds DK(2)}.

If a user should type ";n" DDT would try to invoke the resume key WE. This would change D to the waiting state and unstall A.

If the problem with the segment keeper had been overcome {segment replaced or some such} A would reinvoke its resume key and we should be off and running just as we should.

If the original problem was not fixed we would again appear to fault on the SVC.

Warts
A slightly ugly thing is that the segment keeper keeps WE since the invocation of idle resume keys does not destroy resume keys. If the keeper were malicious he could confuse the domain debugger who thinks that he holds the only resume key to the broken domain.

It seems natural that invocations of idle resume keys should zap all copies of idle resume keys. I know of no economical way to do this.

This scheme violates a principle that was nice but unrequired so far as I know. The principle was that "only fork commands increase the number of processes in the system".

Natural extensions to this idea
The first extension that comes to mind is to increase the limit from 4094 characters. Indeed it seems that 4096 is better than 4094. But what about 2**24 or 2**32. The kernel even understands addresses up to 2**48 almost as well as it does those less than 2**24.

Extending the limit much beyond 4096 seems to require that the jump no longer be a single unit of operation.

This in turn requires the attention of meta programs that study other programs.

Programs to monitor traffic at a gate would either become slow or complex.

Domains would have a new state of having partially emitted or absorbed a parameter string. Two domains would somehow have to be bound together, presumably with keys, to ensure the integrity of the jump. The relationship of such domain with other gate keys would have to be determined.

We might provide a type of jump that would make the domain act as if it were sending or receiving a long string in contiguous storage via byte stream conventions. The advantage over byte streams is that when the kernel encountered a jumper and jumpee both using this of jump, more than a single page of data might be copied at once.

We do not see the end of the ramifications of this idea.

There is an idea that a domain that wanted many bytes could be fed a few at a time. Several jumps by the provider would appear as one to the consumer. The converse is also possible.

See {(p3,ejp)} for a protocol that allows domains to pass long strings and many keys.

Early Benefits with Limitations
In order to achieve some of the more immediate benefits of these ideas we have implemented a version of these ideas that is limited in several ways. We hope that we are not painting ourselves into a corner.

Limitations

To limit the size of the string it would suffice to limit its length to 4096 or limit the number of pages it uses to two.
We choose the former because of an implementation technique that has been used in the current kernel. Much less code will have to be changed this way.

The pages holding the parameter string must be real.
This is much like the domain server seeing the jumpee's domain thru a no-call segment key. It is worse however -- in this case a jump to a domain with such a parameter string will result in the parameter value being lost to the jumpee -- as if the jumpee had had an invalid parameter page key.

A similar restriction for the argument {source} string seems now to serve no purpose.

Neither parameter strings nor argument strings may use more than one page.

These may be separate issues. We may not impose this limitation depending on the difficulty of the implementation.

When the kernel does an implicit call the kernel provides an order code which is determined by the reason for the call. Order codes that the kernel interprets in response to calls to primary keys are chosen so as not to be the same as any order code provided by the kernel in an implicit call. Because there are no side effects of calls to primary keys when the order code is invalid, and because implicit calls generate restart keys, the kernel is not obliged by this report to provide the normal function of the primary key when the jump is an implicit call.

The trapping caused by rejected return codes {(jtrap)} is inhibited for restart keys in order to prevent holders of restart keys from influencing {beyond impeding} the domain designated by the resume key. Thus you can blame the scheduler for not giving you enough time, but you cannot blame it for getting the wrong answer.

{arcane}See also (p1,strdes) and (p1,whyreal) for information on pathologies of string jumps.