Introduction

The Context Switcher is the KeyKOS facility by which the user manages his or her resources. Resources such as Space (disk space) and CPU are managed separately from directories of keys. The Context Switcher provides natural mechanisms for each required management function. In addition the Context Switcher provides a way to multiplex the user terminal among a large number of objects that wish to use the terminal as an Input-Output device.

The user controls the actions of the Context Switcher with the Context Switcher command system described later in this section.

Space and CPU

Space and CPU are allocated in a hierarchy with the Prime Spacebank as the root. Each Group administrator has a sub-allocation of the Prime Spacebank and each use User of the Group has a sub-allocation of the Group administrator's spacebank. The Context switcher allows the user to create spacebanks that are sub-allocations of the user's spacebank. Each named context that the user creates has an associated spacebank independent from the spacebank associated with any other context but subordinate to the user's spacebank.

Context are therefore the prime tool the user has to allocate his or her space resources. Objects that last a long time should be built in contexts that will last a long time. Objects that are being tested should be built in contexts that can be destroyed. In the extreme case one might use a separate context for each object. In practice contexts are associated with "projects" much like sub-directories are used in UNIX. The important difference between sub-directories and contexts is that context can be used to manage resources as well as to manage the name space.

Directories
Each context has a directory that is the root of a tree of directories. This is the opposite view of a UNIX system but is more natural to the user. The current project (context) contains the most important data because it is where the changes are being made. More global information is of less importance and is therefore toward the leaves of the directory tree.

The root directory of the context may be thought of as a directory with the context name (much as the spacebank is "named"). The initial content of the context directory includes the context SPACEBANK and METER and a key to a directory shared by all contexts created by a single instance of the Context Switcher. This shared directory is called USER. and should not be thought of as the user's root directory because there is no such concept. The context directories are not subdirectories of the USER. directory.

Within the USER. directory can be found keys to more global directories. USER.GROUP. (now known as USER.PUB.) is a key shared by all users administered by a single administrator. USER.SYS. is a subdirectory containing widely available "system" utilities. (asside: SYS. should properly be a sub directory of GROUP. as in USER.GROUP.SYS. which would allow different views of the system for different groups. This is not implemented now but may be in the future.)

It should be clear that directories and contexts are organized differently and each is managed in its natural way. In KeyKOS keys to objects and objects themselves are managed separately. Keys to objects are stored in directories and objects are built from spacebanks. Deleting a key from a directory does not effect the object. However, reclaiming the space of an object by destroying the context it was built in does turn all keys to that object (no matter what directory they are in) into zero datakeys. Copying a key to an object to different directories does not alter the impact of destroying the context in which the object is built but does determine who can access the object (use the key to the object). This allows (and requires) the user to manage these separate concepts differently.

Terminal multiplexing
Many of the objects created by the user need access to the terminal. The Context Switcher provides a terminal multiplexor for this purpose. Paths from the object to the terminal are called branches (for historical reasons) and are represented by keys (SIK3, SOK3, and CCK3). Branches are obtained by invoking the SWITCHER key found in the directory of each context.

A branch might be thought of as a window on the screen (only one of which can be open at a time in the current implementation) however, one should not think of these windows as vessels. Branches are not allocations of space but simply a named path to a terminal. Each branch initially has a name (each window has a name) that is derived from the SWITCHER key used to obtain the branch. The name of a branch is a concatenation of the context name in which the SWITCHER key was located with some letters beginnning "A" through "ZZ". This name is only a convenience and has no cosmic significance.

A branch is an object. The SIK, SOK, CCK keys refer to this object. The branch object holds a key to a particular multiplexor and the user object that holds the SIK, SOK, CCK keys to that branch object communicate through the multiplexor that the branch object holds a key to. When a branch is obtained from a SWITCHER key, the branch holds keys to the multiplexor used by the Context Switcher managing that multiplexor. The space for the branch object is taken from the context in which the SWITCHER key is found. A branch can be disconnected from a multiplexor and connected to another (or the same) multiplexor using some SWITCHER key. When a branch is moved in this way its name changes based on the SWITCHER key used to connect it but the branch object will be destroyed when the original context is destroyed.

Command systems
When a Context Switcher creates a new context it also initiates a command system built from the space of that context and holding a key to the context directory. This command system prompts the user for commands the manipulate the keys available in the context directory. Nominally this means that each command system manipulates only the objects created in that context but in fact it may use any key found in the directory tree beginning at the root which is the context directory.

Command systems are simply one object that runs within a context. A user may create other command systems in the same context. All programs in a context have the same authority (the keys in the directory of the context). A user may write his or her own command system in a fashion similar to any other application.

The key USER.SWITCHCMD can be used to select alternate command systems for contexts created after a call to USER.SWITCHCMD.

SWITCHCMD(0;CSF ==>)
Used the Factory CSF to create the command system for contexts created after this call. CSF is called as follows.
CSF(kt+5;SB,M,SB ==>kt+5;,,,CO)

CO(0;DIRECTORY) a fork.

SWITCHCMD(1 ==>)
Restore the default command system factory.

If CSF is a zero datakey then the default command system will be used.

The command syntax is ill-defined at this point. An attempt has been made to provide compatibilty with the current switcher. This compatibilty issue makes for some rather odd conventions. It is assumed that if this experiment is a success, the command system will be redesigned and maybe even integrated with the "New Command System".

General Comments

Context names are 16 characters with no imbedded blanks, ".", "?" or ":". Branch names are one or two characters with names beginning at "a" and ending at "zz". The colon ":" at the end of command is optional (it was thought that it might be necessary, and may yet be with more general branch names). Dots "." are used to separate context and branch names when a specific branch within a context is specified.

Contexts and branches are time stamped when they are created and the time stamp is printed on the STATUS display.

A bell will sound any time a branch becomes active. This behavior differs from the old switcher.

Nesting of context switchers is not recommended. The SWITCHC key may be used to obtain simple switchers within a context.

In the command descriptions below the short (3 character) version of a command (if it exists) is shown in parenthesis after the command description. When the context-name is shown as optional (between curly brackets) the "current context" is substituted. The current context is the last one active or displayed via "STATUS" or "OUTPUT".

ALERT{:} {context-name.}branch number
The designated branch is put into "alert" status. This means that when there is output pending on the branch the numbered "alert field" in the 3270 status area will display rather than ringing the bell. This allows some branches to indicate that output is present without intruding on one's concentration by ringing the bell.

There are seven "alert fields" in the status area (numbered 1-7) and each of these has a corresponding character that displays if the number of branches in alert status designating the numbered field is non-zero. The character disappears when the alert condition for all branches designating the same "alert field" has been cleared. Switching to the branch clears the condition for that branch.

Branches in "alert" status will not be switched to automatically. They must be switched to explicitly. The STATUS command will show a branch in "alert" status and show what the current alert character is for its "alert field"

ALERT FOO.A 5 causes the FOO.A branch to go into "alert" status. When FOO.A has output pending the "alert field" character selected (via the ALERTCHAR command) will be displayed in the 5th alert position of the 3270 status area.

ALERTCHAR{:} number character
Set the display character for the numbered "alert field". The default characters are the letters ABCDEFG for fields 1234567.

ALERTCHAR 5 M sets the "alert field" display character for field 5 to an M

CREATE{:} context-name (CRE)
A context with the name specified is created. A command system is built and started. At some time in the future a bell will beep to indicate that the new command system wants to speak.

CURRENT{:}
Displays the name of the current context and indicates what the last active branch was.

DESCRIBEBR{:} {context-name.}branch-description (DES)
Up to 32 bytes of descriptive text is associated with the named branch. This information is printed in the status display after the branch names.

DISCONNECT{:} (DISC)
The circuit is zapped.

ESC{:}
An escape is sent to the current branch.

GOBBLEOFF{:} {context-name.}branch
Reverses the effect of a GOBBLEON command and causes the producing process to wait.

GOBBLEON{:} {context-name.}branch
Causes the output for the named branch to be discarded.

LOGOFF{:} (LOG)
The circuit is zapped.

NOALERT{:} {context-name.}branch
The named branch is taken out of "alert" status. That is the effect of ALERT is reversed. When the named branch has output pending the bell will ring.

NOALERT FOO.A restores the branch to the normal automatic switch to active branch mode.

OUTPUT{:} context-identifier{.*} (OUT)
Like STATUS except that only those contexts and branches that both meet the criteria for printing AND have OUTPUT or ALERT status are displayed.

PROTECT{:} context-name
disable ZAPCONTEXT for this context

RENAME{:} contextname1 contextname2 (REN)
Rename the context

SETPFKEY{:} n string
The first 64 bytes of string becomes the value of PF key N. No activation is supplied when the PF key is hit (much as PF6 works). If String is omitted the default action is taken for the designated PF key.

SPACE{:}
Only the Space available status line is displayed.

START{:} context-name
The stopped context is restarted. THe meter is replenished with the value it had at the time it was stopped.

STATUS{:} context-identifier{.*} (STA)
Show the status of all contexts that match the context identifier. The context identifier is of the form "ABC*" where the * (a wild card) matches an arbitrary number of arbitrary characters. The characters that preceed the "*" must match exactly. STATUS A* will give the status of all contexts with the first letter of A.

The presence of the ".*" after the context idenifier indicates that the branches and their descriptions are to be listed as part of the information about a context. The dot "." may be replaced by a blank for compatibility with the previous implementation.

If no contexts match the context identifier then a message to that effect is printed.

STOP{:} context-name
The named context is stopped. Its meter is set to zero CPU.

SWITCH{:} {context-name.}branch-name
The named branch is switched to. If the context is not specified, the current context (last active) is assumed.

UNPROTECT{:} context-name
Enable ZAPCONTEXT for this context

ZAPBRANCH{:} {context-name.}branch-name (ZAP)
The named branch is deleted and its space returned. If the context is not specified, then the current context (the last active context) will be assumed.

ZAPCONTEXT{:} context-name (ZAP)
The named context is destroyed. All space associated with the context is returned to the space bank from whence it came.

?
Lists the commands.

<CR>
Switch to an active branch. An active branch in the current context has priority over an active branch in another context.

<ESC>
Repeats the "[" prompt.

{context-name.}branch-name
Switch to the named branch. Since all branch names are shorter than any command (at the moment) there is no ambiguity.

A Context switcher is created. SB is a prompt official spacebank. M is a good meter which will be subdivided to provided individual meters for the contexts. Node contains the materials needed to build the switcher and the command systems. Any keys that are not provided in the node are put into the command system's directory as DK(0) unless they were absolutely necessary to build the command system, in which case the context switcher will probably crash.

Node Contents

Slot 0 SIK3

Slot 1 SOK3

Slot 2 CCK3

Slot 3 SB2 This spacebank is subdivided to provide contexts with their own guarded banks

Slot 5 Context switcher database (record collection)

If this is a new context switcher then the record collection is empty. If this is the record collection of a currently active context switcher then the new context switcher will take over control and the old context switcher will evaporate. A new Multiplexor is also built to support the new context switcher.

The records in this record collection are described here. There are 4 types of records. A master record holds a copy of the original parameter node with additional keys, a context record describes each context, a branch record describes each branch, and a BID record exists for each BID assigned. All Names are in ASCII and fixed in length with trailing blanks.

TYPE 0 - the master record NAME=(1,1) STRING=<NULL> KEY=NODE
Slot 3 - User's Spacebank]
Slot 4 - User's ZMK key]
Slot 5 - Key to this record collection] Slot 6 - The USER. key]
Slot 7 - Entry key to SWITCHER domain] Slot 8 - Small interger allocator for BIDs] Slot 9 - The TMM CCK3 key]
Slot 10 - Domain Creator for the context switcher] Slot 11 - Entry key to a domain to zap a spacebank] Slot 12 - Altername command system Factory key] Slot 13 - Domain key to the DB domain] Slot 14 - The guarded bank out of which the MUX is built

TYPE 1 - Bid records NAME=(6,BID) STRING=(18,context || branch)

TYPE 2 - Context records NAME=(16,context) STRING=(48,context block)

(2,0)]
(1,flags) - 80=running,40=stopped]
(4,activity count)]
(4,TOD of create)]
(4,alert count)]
(1,reserved)]
(31,0)

Slot 0 - The context spacebank]
Slot 1 - The context meter node]
Slot 2 - The context directory]
Slot 3 - Small integer allocator for branch names] Slot 4 - Switcher key NODE for this context] Slot 5 - Key to the node in master record

TYPE 3 - Branch records NAME=(18,context || branch) STRING=(46,context block) KEY=NODE
(1,0)]
(1,alertnumber)]
(4,TOD of create)]
(1,flag) - 80=active,40=gobble on,20=alert] (6,BID)]
(4,branch-name-number)]
(28,description)

Slot 0 - The CCK3 key for the branch]
Slot 1 - The ZMK key for the branch]
Slot 2 - THe CCKZ key for the branch]
Slot 3 - Data key with BID

Slot 6 USER. (the common subdirectory for all contexts)

Return codes
c = 1 SB not prompt

c = 2 SB out of space

The following calls are for the SWITCHER key that is in the directory of the created command system. Its behavior is much like the old switcher key (p2,switcher) with the addition of the "destroy branch", "switcher to branch", and "describe branch" operations.

SWITCHER(0; ==> c,(name);CCK4,SIK4,SOK4) create branch in this context

"name" is an ASCII string known by the terminal user to distinguish the branches. The length of name is one for branches "a" thru "z" and thence two characters.

SWITCHER(2;ZMK ==> c,(name)) attach branch to this context

SWITCHER(3,(name); ==> c) destroy branch

THe space used for this branch is returned. The zapper is destroyed via CCK(4) and the branch is destroyed via TMMK(1;CCK).

c = 5 branch not found

c = other nonzero values mean big trouble

"description" is in ASCII. "name" must be padded on the right with an ASCII blank {S(1, 32)} if it is short.

c = 5 branch not found

c = other nonzero values mean big trouble