Some programs crash by calling the error key (p2,errkey). Today this stops the kernel.

Some programs crash using the Virtual Domain Keeper in the womb. To see if this has happened, log in as SYSADMIN and explore new branches.

Getting the Domain Creator for Primordial Programs

During a big-bang the program WOMBKEEP initiates, one after the other, the primordial subsystems. As WOMBKEEP runs it executes either the macro AUXSUBR or COMPFACTS or COMPFACT for each of the primordial systems.

AUXSUBR or COMPFACTS adds a key to an array of keys (called SWOMBLIST) kept by WOMBKEEP and available to SYSTOOL {(p2,systool)}. The SYSTOOL subroutine GETAUX retrieves such a key given the index into SWOMBLIST.

If the subsystem is initiated by AUXSUBR then some of the primordial code of that subsystem is executed by a domain whose key is placed in SWOMBLIST. Slot 14 of the node for a AUXSUBR program holds the domain key.

If the subsystem is initiated by COMPFACTS then a factory is created for the subsystem and the builder's key for that factory is placed in slot 14 of a node whose key is deposited in SWOMBLIST.

Getting a key from SWOMBLIST

"020000;C0280" to SYSTOOL's DDT will print the primordial directory for SWOMBLIST. This is merely an array of subsystem names (those of the MODULE file used at big bang to get the code of the subsystem.) If the name of a subsystem is in slot i of this array (starting from 0) a debugging key for that subsystem may be found in slot i of SWOMBLIST. SWOMBLIST is in SYSTEMKEYS..

To Get key i from SWOMBLIST while in SYSTOOL, put i at location WORK thus: "work;x4;i<cr>", put WORK in R2 thus: "2r/work<cr>", put 3 in R14 thus: "0er/3<cr>" and then go to GETAUX thus: "getaux;g". The key will be placed in slot K3.

Getting the Primordial Factory Builder's Keys
Primordial factories are built by WOMBKEEP by issuing a COMPFACT macro. It is coded thus: "COMPFACT , ,ndx". The "ndx" is an index into WOMBLIST {(p2,womblist)} which is a node holding node keys to nodes whose component 14 is the builder's key.

This technology is broken at the moment. I intend to fix it when I have time. (NH)

The CMS file "FIRST TEST" on the Gnosis application's disk can be used to test most modifications to the systems installed by the "FIRST CMDFILE" method {(first)}. FIRST TEST should be run in a pristine context such as created by the "create test" command of the context switcher {(p2,cswitchc)}. You must provide a key called "TYMNET.GNOSIS" which leads to a CMS machine like that of the CMS user GNOSIS. The real "TYMNET.GNOSIS" will work.

We have had difficulty finding an adequate place to debug such fundamental domain code as the space bank. While VM provides the natural place to debug new kernel code, the overhead and other considerations tends to make debugging domain code there awkward.

We have noted before that one kernel could support two or more "worlds" simultaneously. Let one of these worlds be the world in which we test the new code. How can we arrange that the old productions world is safe? There are several ways to slice the cake.

Let's first explore the idea of disjoint disk packs and range keys.

Suppose that we can devote a set of drives to the test. We format them for a new range of CDA's. We then introduce into the system a test version of domain land holding range keys to the test packs.

There are two problems to discuss here: how to introduce the new world, and how the worlds interact.

Suppose the new packs were merely mounted on an unsuspecting running Gnosis. We must ensure that there are no duplicate ranges and that there are no keys in the new world to the old world!

This does not come to grips with the question: "Where are the primordial pages and nodes whose CDA's are in no range?" I think that those pages and nodes are now in limbo, shuffling between swap areas. If the new packs had their own swap areas we would also have to ensure that there was no duplicate "primordial material".

I presume that there would be only one external migrator. The BWAIT multiplexor would need its own primordial BWAIT key. The Tymnet adaptor are perhaps need its own base key. This might be synthetic. There are perhaps a few more issues here.

It could be a powerful tool for a debugger in the real world to acquire (somehow) a key to SYSNODE in the test world. I can see no danger here except for real world domains becoming blocked on dismounted material. This is by no means fatal.

Another scheme is to write a program to interpret the yield of the assembly GNOSIS ASSEMBLE.
The interpreter would buy nodes from a spacebank to play the role of the primordial nodes described in GNOSIS ASSEMBLE. Pages from the same spacebank would be filled with data from CMS files over Tymnet circuits. (This is what the kernel module INIT does now at big bang time.)

Here is a list of the primary keys and how the interpreter would provide them:

Wait
A multiplexed wait key will do.

Range keys
The important operations now are: Produce key for page i, Identify a page, Sever a page. If the simulator kept a supernode of page keys indexed on i it could do these operations. The range server could use the real UNSPEC key to do identify fast.

The Domain Tool
I believe the real domain tool will do.

UNSPEC
The UNSPEC server would use the real UNSPEC and the RANGE server's tables to do its job fast.

{ni}DECONGESTER_TOOL

MIGRATOR CAPABILITY

I think the Never key will serve most purposes.

Error Key
Leads to the human debugger.

PEEK; NOP

Charge Set Tool; Depends

Raw I/O keys

The Tymnet base key would preferably be to a real base but could be to a synthetic base.

The device allocator server could subscribe to the services of the real allocator.

BADGEC
The real one will do.