Defining I/O Configuration

The I/O configuration of the hardware is defined in a CSECT called GIODEFS. The current version of this CSECT is defined in GIOGEN ASSEMBLE.

The I/O configuration is defined by assembling a set of macros as follows:

IODEVICE TYPE=<type>,ADDRS=<addresses>[,NUMBER=<count>]
The IODEVICE macro is used to define I/O devices on un-shared control units such as Tymnet adapters and Tymnet bases.

SHRCU TYPE=<cutype>,CH1=( <chan-1-address>,<count> ),[CH2=...,[CH3=...,[CH4=...]]]
The SHRCU macro defines a shared control unit such as an IBM 3830. The CHn entries describe the first address and number of addresses for each channel path on the control unit.

STRING TYPE=<type>,NUMBER=<count>,ADDRS=<addresses>
The STRING macro is used to define a string of consecutively addressed I/O devices with the same device type connected thru a shared control unit (which must be defined with a SHRCU macro).

ENDUP
The ENDUP macro is the last macro in a Gnosis I/O definition . It is used to complete the generation of tables used by the Gnosis I/O system. It has no parameters.

Definitions of the parameters used in the I/O configuration definition macros.
<addresses> - defines in parentheses, separated by commas, the lowest address for each channel path to this collection of devices.

<count> - the number of devices in the collection being defined by the macro.

<chan-1-address> - The base address for the control unit and the number of address positions used in parentheses separated by a comma.

<cutype> - The type of control unit. Valid values are: 3830.

<type> - The type of the device. Valid values are: 3330, TIRETORE, BASE1.

Gnosis disks can be acquired in two ways. Define temp disk at address 130,131, and 132 (The LG exec will do this for you) or use the GDSKS PERM command to attach the permanent Gnosis minidisks.

Gnosis disk packs are defined by a CMS program that calls the subroutine GFORM. This program is currently called GF and defines the ranges on the Gnosis disk packs.

GFORM parameter definition

GFORM obeys normal OS linkage conventions. i.e. r15=entry point, r14=return address, and r1=parameter address vector. Each entry in this address vector points to a parameter as follows:
CMS virtual device address to be formatted (4 bytes).

Pack number in the pack set (4 bytes).

Volume label for the pack (6 bytes).

Packset identifier (unique for the Gnosis) (8 bytes).

Flag for checkpoint header as follows (4 bytes):

0 - No checkpoint header on this pack.

1 - Primary checkpoint header on this pack.

2 - Secondary checkpoint header on this pack.

N.B. Each Gnosis system should have two and only two checkpoint headers, one each primary and secondary.

Number of range descriptors in the range descriptor list (4 bytes).

Pointer to the range descriptor list (4 bytes) each entry is:

Range type (4 bytes) as follows:
-2 - Range is part of second logical swap area

-1 - Range is part of first logical swap area

0 - Normal range of pages or nodes

1 - Dump range (The kernel will automaticly try to place a dump of real storage in this range when the kernel crashes.) There should only be one of these ranges in a Gnosis system.

2 - IPL range (A copy of the kernel for the hardware IPL process)

first CDA for the range (4 bytes) (high bit = 1 for node range, 0 for page range or swap range).

Number of pages or nodes in the range (4 bytes).

Number of occurrences of this range (two for duplex) in the Gnosis system (4 bytes).

Space calculations for disks
3330 disk packs have 58 pages per cylinder. The first 5 pages on each pack are used for system information.

Each page in a node range will hold 29 nodes.

There is one allocation pot for every 1024 pages (or fraction thereof) in a page range. Swap areas do not have allocation pots.

The minimum space in each logical swap area depends on the number of core pages, the number of node slots in item space, and the number of swap area directory blocks allocated in core to the I/O system. There must be at least two swap ranges in each logical swap area with more space than that calculated by the following formula:

Number of core page frames + (number of item space nodes / 29) + 1 + (number of swap area directory blocks / 315) + 1 + 2 + 50

Each checkpoint header occupies one disk page.

.(1) Acquire the disks you are going to use and put them at device addresses 130, 131, and perhaps 132.
The userid GNOSIS2 had full pack minidisks at these addresses (not 132). The userid GNOSIS1 has permanent minidisks at these addresses. The LG exec will acquire these disks. Use the GDSKS PERM command to attach the Gnosis minidisks.

.(2) Format them.

.(3) Load a Gnosis with the item space "GNOSIS" and start it at "INIT".

.(4) Wait until the system becomes quiescent, or at least until a checkpoint has been taken.

Step 2 is needed to ensure that all nodes are empty except those explicitly initialized in Gnosis.

Acquire disks for use by Gnosis (p3,initdisks).

Access the Gnosis disks with, e.g., GDSKS RUNFT TOOLS.

Do LG STARTM. If you get back to CMS, do it again.

Do INIT;G.

Do as much of the procedure for 2686 as you want.

FIRST NOTIFY ALL USERS AND SHUT DOWN ALL APPLICATIONS
To shut down the FTS application the following script is used.
Determine that host 2688 (2686) is operational

LOGON to GNOFTS:2686 (2688)

Switch to the application controller branch (usually "i")

LIST

Shut the creator of FTS (usually item 2)

Kill all active FTS applications (KILL nnnn)

Switch to branch a

KEYCALL FTS2VM.STATENODE 17

This causes the FTS2VM task to do ONLY a file transfer and NOT use any tapes. This is done to avoid confusion with which tapes to use (the correct ones may already be in the mail)

KEYCALL FTSTIMER.BWAIT 2 (%x0000000000000000)

KEYCALL FTS2VMLOG 14 () (%E)

Repeat this until the message says process complete and the time and date indicates that it completed after the keycall to ftstimer.bwait

NEXT BACK UP THE GNOSIS TAPE LIBRARY
On system 2686 only. Log on to userid GNOSIS and switch to the tape library program on branch B. Type a CR and look at the resulting menu. Select item for Tape Library Backup. You will be prompted to enter a VM system number. Enter the current VM home for Gnosis (currently 85). Wait for the acknowledgement that the job is done.

Check with Mag Monitor users to see if they have backed up the Expected mag record collection or have a desire to do so. Use ESTONS and AUXFILE to do so.

Log in to GNOSIS1 (using the project of TEST sets up the Gnosis environment) on host 85 (to BB 2688 use GNOSIS2 on system 85)

For host 2686 BB, the 4 packs must be mounted and attached. First detach the packs that GNOSIS1 owns (det 130, 131, 132, 133), and then get the operators to mount the Gnosis packs. GNOSYS, GNO001, GNO002, and GNO003 at 130 through 133 respectively.

DEF STOR 4M

IPL FTCMS

Format the disks:

Note: if you don't want to format all the disks at once you can edit the following programs and reassemble to format the ones you want.

LOAD GF250DUP (START formats 2 3350 packs with duplexed ranges.

LOAD GF4PKDUP (START formats 4 disk packs.

LOAD GF6PKDUP (START formats 6 disk packs.

LOAD REALDPLX (START was used to format 2 packs.

LOAD V2688PKS (START used to format host 2688 packs.

LOAD GF2PKTST (START for 2-pack test system.

LINK GNOSIS1 134 134 M (for 2688 use GNOSIS2)

GSENDFMT

Except, for 2-pack test system, do LOAD GSENDTST (START

GSEND REALKERN MODULE E <remember the return code>

LG START

INIT;G

Then, on another (perhaps virtual) terminal:

Log in to SYSTOOL:2691

When doing a BB for host 2686 under userid GNOSIS1, it is necessary to log on as S370:85 and DIAL to GNOSIS1.

;T

0,B;U

;W

DDTRECEP;G

[b]

;T

0,RECEP;U

PW%A7; <insert "new password">

[A]

OPENBASE;G

2R/ <insert the return code from GSEND>

LOADKERNEL;G

For host 2688 do the following

When you get a prompt, go back to the GNOSIS2 terminal and type:

Unit Separator

DEF STOR 1M {to get the V=R region}

IPL 130

Unit separator

DISCONN

For host 2686 do the following
Log off the userid GNOSIS1

Ask the operators to move the packs to host 2686 and IPL the GNOSYS pack.

{obsolete}Log on the SYSTOOL:2691 again and on branch a type: INSTALLUSERS;G

Log on the GNOSIS:2691 and type: [create users]

Wait for a bell, then type carriage return.

DEBUG

AUXFILE GET RECORD JOINUSERCMD TYMNET.GNOSIS 85 JOINUSER CMDFILE "XFER"

CMDFILE JOINUSERCMD

EXECUTE JOIN /FILE

When this has finished or concurrently, type <ESC> and then [create main]

Wait for a bell, then type carriage return.

DEBUG

[b]

[a]

If you did the first part of the big bang with two disk packs and now have four (formatted by GF4PKDUP), you must expand the space bank size as follows.

KEYCALL SYSNODE 2 () (,PRIMORD)

KEYCALL PRIMORD 0 () (,PSBDOM)

KEYCALL PSBDOM 64 (%X20) (,KICKPRIMEBANK)

DEBUG PSBDOM

[c]

010084;x4;

Decrease the fullword at 010084 by at least 7 but not too much.

[a]

KEYCALL KICKPRIMEBANK 69

AUXFILE GET RECORD GETDIREC TYMNET.GNOSIS 85 GETDIREC CMDFILE "XFER"

CMDFILE GETDIREC

AUXFILE GET RECORD GETFIRST TYMNET.GNOSIS 85 GETFIRST CMDFILE "XFER"

CMDFILE GETFIRST

If there are errors, repeat the AUXFILE commands for the files that failed.

CMDFILE FIRST

[create os]

DEBUG

[b]

[a]

AUXFILE GET RECORD OSXFER.CMDFILE TYMNET.GNOSIS 85 OSXFER CMDFILE "XFER"

CMDFILE OSXFER.CMDFILE

At the end of each command file, you will be directed to execute other command files. Do so unless an error occurs. Answer bells.

[main.a]

CMDFILE KERWATFCMD

Then (or concurrently) log in to GNOFTS:2691 and type:

[create main]

Wait for a bell, then type carriage return.

DEBUG

AUXFILE GET RECORD FTSGET TYMNET.ALAN 85 FTSGET CMDFILE "XFER"

CMDFILE FTSGET

If this is host 2688 the following editing should be done

EDIT FTSBUILD

TOP

locate the line "KEYCALL FTSTIMERCREATOR 40 (%E00.00.00FTSDALL)"

change FTSDALL to FTSBACK and change 00.00.00 to 23.00.00

CMDFILE FTSBUILD

When it waits after an ADDLUDKY GNOX0 command, log in to GNOX0:2691 and type:

RABBIT

The circuit will be zapped. Go back to GNOFTS:2691

On 2686 do the following

If this happens after the TAPE context has run (installation of the tape library) Then
CMDFILE CLAIMTAPECMD

to claim the tapes needed by FTS. If TAPE hasn't completed wait for it and issue the fork command. There will be about 30 messages on the FORKed branch referencing errors claiming tapes for slots with numbers divisible by 3. Ignore these.

LOG

Then, on SYSTOOL:2691 again:

START2686;G or START2688;G

This sets the host number and timeout for these two systems.

The circuit will be zapped. Then log in to SYSTOOL:2686 (2688) and:

DISCONNECT;G

On 2686 do the following on userid GNOSIS

[create kerwat]

CMDFILE USER.KERWATCMD

[create tape]

A:AUXFILE GET RECORD INSTTAPE TYMNET.GNOSIS 85 INSTTAPE CMDFILE "XFER"

A:CMDFILE INSTTAPE

[create monitor]

A:AUXFILE GET RECORD MONITORCMD TYMNET.GNOSIS 85 MONITOR CMDFILE "XFER"

CMDFILE MONITORCMD

[create applmon]

A:AUXFILE GET RECORD APPLGET TYMNET.GNOSIS 85 APPLGET CMDFILE "XFER"

CMDFILE APPLGET

A:AUXFILE GET RECORD CAMGET TYMNET.GNOSIS 85 CAMGET CMDFILE "XFER"

CMDFILE CAMGET

[create ftsmon]

A:AUXFILE GET RECORD FTSMON TYMNET.GNOSIS 85 FTSMON CMDFILE "XFER"

A:CMDFILE FTSMON

[create tymnet]

A:AUXFILE GET TYMNETCMD TYMNET.GNOSIS 85 TYMNET CMDFILE "XFER"

CMDFILE TYMNETCMD

[create tmplint]

A:AUXFILE GET TMPSETUP TYMNET.GNOSIS 85 TMPSETUP CMDFILE "XFER"

CMDFILE TMPSETUP

[create plipack]

CMDFILE COMMON.PLIPACK

[logoff

On 2686 it is nice to install the MAG Monitor. Follow the script here.
Log on to CMMSRC:2686;MAG MONITOR

[create magmon]

A:AUXFILE GET RECORD INST TYMNET.CMMSRC 85 INSTMAG CMDFILE "XFER"

A:CMDFILE INST

You will need to log on to three userid's to complete ADDLUDKY commands.

MARSPLSMONCR:2686;MARS PLUS type RABBIT

MPMON:2686;MARS PLUS type RABBIT

OPMON:2686;OPS MON type OPS_MON

[logoff

The problem of installing software in the post-big-bang stages without Tymnet is solved by producing a tape on CMS that looks like a Gnosis BACKUP tape. This tape is RESTORE'd and the post-big-bang scripts are run.

Making the BOOT tape

Edit the MAKETAPE EXEC to add any files that you want brought over at Big Bang time. This EXEC is on the Domain Disk. Make sure that the files to be transferred are also on the Gnosis system disks.

Log onto KLOGGNO2 or the ID under which Gnosis is to run.

GDSKS RUNFT OS (with extensions)

Get the operators to mount the tape KL0001 (or some other tape) with a ring as 181.

MAKETAPE

A protection exception probably means you need to define more storage. 1 Meg isn't enough.

When the tape is complete (some 140 files), CP DEFINE 181 580

Bringing up Gnosis
DEF STOR 4M

IPL CMSL

Format the disks if necessary.

LG START

INIT;G

Reading the Boot tape
Dial KLOGGN02 and log on as GNOSIS password GNOSIS.GNOSIS and create the context BOOT.
KC USER.SYSNODE 6 () (,EXT)

KC EXT 3 () (,BOOTSEG)

CREATE BOOTCMD BOOTSEG

CMDFILE BOOTCMD

This command file will pause waiting for the tape to go ready. On the console of KLOGGN02 enter the CP command READY 580. This "mounts" the tape. The command file sits a long time on the following:
KEYCALL RESTORE 1 (,ACCESS) (,USER.BOOTS.)

Which is creating the BOOTS directory from backup tape. If there is a bad return code from RESTORE there is trouble. Most likely is a duplicate name. In this case go back and re-create the tape without the duplicate names.

Running the initial CMDFILE's
The following steps ask you to create a number of contexts and run a command file in each one. Follow the instructions carefully. Some of the command files ask you to run other command files and give names xxxxxxx where the actual name is USER.BOOTS.xxxxxxx.

First Create the context MAIN

CMDFILE USER.BOOTS.FIRST

CMDFILE USER.BOOTS.KERNLOADCMD

This load the kernel into the IPL range. It is suggested that a KC CKERNPROD 1 is issued at this point to IPL the new kernel to make sure it works before proceeding.

Context OS - CMDFILE USER.BOOTS.OSXFERCM and answer bells.

Context NCS - CMDFILE USER.BOOTS.TMPSETUPCMD

Context PLIPACK - CMDFILE USER.BOOTS.PLIPACKCMD

Context KERWATRC - CMDFILE USER.BOOTS.KERWATFCMD

Context KERWAT - CMDFILE USER.BOODS.KERWATCMD

Context READER - CMDFILE USER.BOOTS.READCRDFCMD

Context PRINTER - CMDFILE USER.BOOTS.PRINTERFCMD

Context TAPE - CMDFILE USER.BOOTS.INSTTAPECMD

Then log on as GNOTAPE (pw TAPE.OP) and create the tape operator.

Context MAIL - CMDFILE USER.BOOTS.FULLMSYSCMD

Context CMS - CREATE BLDCMS USER.BOOTS.SIM360_CMDSEG;CMDFILE BLDCMS

Context APPLMON - CMDFILE USER.BOOTS.APPLGETCMD

Context USERS - CMDFILE USER.BOOTS.JOINUSERCMD

Initializing the CMS context
The tape KL0002 has 3 files that must be loaded onto 3 minidisks for use by CMS environments. The first two are the Y and S disks and are loaded by running DDR. The third file on the tape is a TAPE DUMP of the "tools" disk.

Context CMS1 - CMDFILE USER.BOOTS.CMS1CMD

It will pause waiting for the tape to be mounted.

Getting the tape KL0002 mounted is an exercise in patience. You need three terminals. One is logged on as GNOSIS in the context CMS1. Log one on as GNOTAPE (pw TAPE.OP) as the KeyKOS tape operator. Log on the third as the VM console of the Virtual KeyKOS machine. (This latter step is eliminated on a native machine.)

You must induce the VM operator to mount the tape and attach it to the KeyKOS virtual machine at the address that appeared in the MOUNT message (on the Tape Operator screen type the command STATUS). When the VM operator has mounted the tape, READY it, then type the command MOUNT xxx (xxx is the address of the drive).

If you run into trouble, use the Tape Librarian screen of GNOTAPE and select option 8 to list the library. The password for KL0002 is listed for you.

Branch CMS1.B will be a CP simulator. Type:
IPL 181
Wait for DDR to prompt you.

INPUT 181 2400 (LEAVE

OUTPUT 190 3350

RESTORE ALL

OUTPUT 19E 3350

RESTORE ALL

Enter a blank line to exit DDR.

DEF STOR 4M

IPL 190

FORMAT 193 A

TAPE LOAD

Shutdown the Tymnet driver as follows:
KC USER.SYSNODE 1 () (,PRIV)

KC PRIV 13 () (,TYMLRECE)

KC TYMLRECE 256+8+4