When Gnosis Breaks

Crashes during initialization
Usually crashes during initialization are due to some expected CMS file not existing. If you display 1r]
;c020; ddt will probably type out the name of the parameter list to some CMS I/O request. The two most common types of errors are:
The file did not exist.

The PAGES or CMSFILE macro did not reserve enough space to hold all of it.

Crashes during execution
HARDSTOP
The error key {(p2,errkey)} was invoked. Resume at HARDSTOP+2.

JMISC + 0F (A jump to an invalid miscellaneous key)
If some domain jumps to an invalid misc key Gnosis will stop. {Invalid misc keys were once assembled in primordially for the error key function.} When this occurs 8r]
;x098; will display the domain root of the caller of the misc key, 10r]
;x0a8; will display the DIB of that domain.
8r-frstnode+anodes_ will tell the name of the domain if it was assembled into item space, and if symbols are present. If the gate jump was to the domain keeper of the domain, 8r] 064;x8; will display the trap code. 1r]
;x; will show the order code to the misc key.

Identifying primordial code.
If the system should fail before enough system is available to use higher-level tools, primordially loaded code may be identified by determining the cda of the primordial page holding the code and then consulting the CSECT PPMAP (Primordial page map).

Entries in this map are generated for each execution of the macro PAGES in the assemble of primordial item space. The form of these entries is DC CL13'code name',AL3(cda). These entries are in cda order making a search easy.

See (dwpsw) about some wait state PSW's and their causes.

Finding Assembled things in Item Space
If you load the symbol table for item space it is usually useful to do "ANODES;D FRSTNODE,ANODES;U". This compensates for the fact that INIT moves the assembled item space from where it was loaded to where it runs {FRSTNODE}.

If swapping is occurring, a primordial node can be identified by considering the CDA of the node {3 bytes at 9 in the node}. Suppose that the CDA is 00009C. Type "09C 1-098*ANODES+_". DDT should then print the assembler name of the node.

To find a slot or node given an item index such as C390 let DDT compute ITEMBASE]
(0FFFFC390*8) or 0FFFFC390*8 0164840. ITEMBASE] was recently 0164840. ITEMBASE]
is ITEM+X'40000' and is usually in 9r.

To display a DIB, get the item index from domain root(012,2) and display 0FFFFnnnn (0230]
)/ .

To find a page, if the key is of the form "01xxnnnn nn000001" add 01f to nnnnnn. The result is the relative page number of the page. Thus if nnnnnn is 09c, the specified page begins as 0bb000.

If x is the address of the DIB of a program ("208] " for the running program) type "x 088+]
]
=" to see the segment table descriptor. If the segment table is 64 bytes long (the shortest) then the first byte of the descriptor will be 00 and you can see the table by typing ";q;x040;". To see the first page table type ".] ;x020;". If you see something such as 0B200690 that means that there are two pages at addresses B2000 and 69000. If the should happen to be primordial pages (even if they have been swapped) they may be identified as follows:

Type "0B2 31-8*annex 2+;x3;" DDT will print the CDA of the page. If it small the page is primordial. In that case type ";q 8*8-acortbl+_" and DDT should type something such as "DCCWOMBCODE3" where "DCC" is the label of a WOMB macro in the assemble of item space.

See <Landau,DDTDOC,> about DDT.

N.B. The kernel will be un-runnable after dumps.

If you are running a kernel without kernel DDT then dumps will be taken automatically whenever:

A system restart function is executed.

An unanticipated program interrupt occurs in kernel code.

If any of certain fatal errors occurs in the attempt to take a dump, a wait state PSW 200A0X00 00000D0A will be loaded instead. General register 15 has one of these error codes:
1 Dump range could not be found.

2 Error writing dump file

3 Not enough pages in the range

4 Permanent error writting file

5 No online path to dump range device

After the dump the system will automatically re-IPL from the primary IPL range.

If you are running a kernel with kernel DDT then issue the following commands to take a dump.

>0r;x4; xxxxxxxx >14R]
{linefeed or Control-J}

04 xxxxxxxx >15r]
{carriage return}

0rp/ xxxxxxxxxxxx >0{carriage return}

>CALLDUMP;G

# the kernel will stop with the wait state code 00000D0A #

# xxxxxxxx above is hex data to be replaced by the DDT commands #

The SYSTOOL command CREATEDUMPDDT;g must be done after a big bang and before any use of GETLASTDUMP;g. This command creates a new branch on SYSTOOL's switcher and puts its ASCII name in DUMPDDTBRANCHNAME. This branch is to a DDT which knows the command "KERNSYMS;;" {(ddtdoc,0477)} (which should be executed after each use of the GETLASTDUMP command). "028;x8;" shows the PSW at the point of failure.

GETLASTDUMP installs the last crash from the crash directory under the DDT already created by command CREATEDUMPDDT.

For further insight see the commands in SYSTOOL.

Every once in a while a Gnosis bug arises of such a nature that it will not manifest itself while running under CP. If such a bug also prevents the kernel from taking crash dumps, then a stand-alone dump is the only available tool. Start by phoning the operator and asking to have a stand-alone dump taken of the dead Gnosis host. After the dump is completed, have the operator mount the dump tape on a drive connected to your VM host, linked to you as device 181.

Create a 3330 tempdisk in which to receive the dump file, allocating five cylinders per megabyte of memory on the crashed host. Access the tempdisk as "A" since the programs of interest only want to operate there. Typing "VMFSADMP DUMPFILE<CR>" to CMS will get the dump loaded as DUMPFILE DUMP A. VMFSADMP will ask you if the version of CP on the tape is the same as the version you are running under. The tape contains an image of Gnosis, not CP, so answer "N<CR>" to this question. The file load begins, and may take several minutes under heavy load.

Enter DDT by typing "DUMPDDT<CR>" to CMS. Access the dump by typing "DUMPFILE%#" to DDT. DDT inputs DUMPFILE DUMP A and responds with "SAD000..." to let you know that loading is complete. You can now examine the dump image using normal DDT commands. There are no symbols here, so you will need to navigate using a copy of REALKERN MAP. You can also use the "MODMAP" command at CMS to type a symbol value list. The argument to MODMAP is the module filename. In either case, remember you will have to add 1000 hex to the listed symbol value to get the actual value, since page zero has not been accounted for.