Detached Jobs
A job may or may not have one "controlling terminal" from which it can
accept keystrokes or deliver character output. A job without a controlling
terminal is called a "detached" job.
Detached jobs are very important
tools in TSX-32. TSX-32 starts life by running a detached job which
performs many initialization functions. When a program has a controlling
terminal it means that when KMON runs on behalf of that job it accepts
commands from that terminal. Keystrokes are collected and the display
is updated as typing occurs. When a job does not have a controlling
terminal KMON must read its commands from a command procedure. Output
may be written to a log file or it may be discarded.
The KMON DETACH command is used to 'launch' detached jobs. When you
launch a detached job you specify a command procedure to run. KMON
uses the syfn_detach system service to tell the OS
to create another copy of KMON and associate it with the specified
command procedure. KMON reads and processes the commands from the command
file. When it runs out of commands the detached job terminates.
Another way to start a detached job is to specify a program to run,
instead of a command file. In that case the OS launches the program,
not KMON, and the detached job exists for as long as the program runs.
This latter form is quite common in TSX-32.
System Generation and Booting TSX-32.
As shipped, TSX-32 cannot execute until it is told about the disk
and other devices on the system. This is done in the TSX32.GEN file,
discussed earlier.
The TSGEN program is used to modify the OS to specify the devices
which are defined in the system.
The TSGEN program reads the ASCII file TSX32.GEN,
interprets it, and uses the contents to modify the kernel file, TSX32.SYS.
To use this program is to "gen" (pronounced jen) the system.
The kernel, TSX32.SYS, contains a data area which is actually modified
by the TSGEN program. When the system boots it does not consult the
TSX32.GEN file, it already has the device and tuning information it
needs in a form it can quickly process.
Under DOS, the program RUNTSX loads the file C:\TSX32.SYS into memory,
goes into 32 bit mode and transfers control to it.
The OS initializes built-in device handlers and starts the very
first job, which executes the command procedure sy:startup.cmd as
a detached job. Thus, system initialization is broken into two phases:
a phase which occurs internally to the OS and a phase which uses the
same tools (KMON, detached jobs, command procedures) as any user of the
system would use. As much as possible TSX-32 is designed to do as little
as necessary internally. The ideal goal is to use the tools available
to any developer to initialize the OS and its components.
Functionally, the startup command procedure does the following work:
- Runs a program called MAKELOAD which locates any loadable handlers
and creates a command procedure called sy:tsxload.cmd with a series
of HANLOAD statements.
- Executes the TSXLOAD command procedure, which loads any loadable
handlers via the execution of the HANLOAD commands. The best example
of what happens in this step is the loading of networking software
by loading SY:LHTCPIP.REX.
- Execute the command procedure SY:LSTARTUP.CMD, which contains
any "local" processing which the user wants to perform during system
startup.
After system initialization is complete the OS is ready to run user jobs.
Terminal Initialization and User Logon
Once the system has initialized users are ready to use the system.
Devices have been initialized, the network (if in use) is initialized
and ready, the terminals are ready for use, and any local first time
initializations have been done.
At this point TSX-32 is ready for work, and what happens here
is purely dependent on how the system is to be used. For instance,
a shop with office folks who run WP and custom software will proceed
differently than folks who are automating a warehouse.
In the traditional timesharing model of computers, users would connect in,
type a return, get a "Username:" or "Login:" prompt, type in a
user name and password, and get a command prompt. They would then type in
commands or run programs. In TSX-32 they would be interacting with the
TSKMON program, or KMON.
Resellers or developers of vertical applications would
then develop a layer on top of that with custom programs and command
procedures so that users would log in and automatically be placed
in an application menu from which they had access to specialized
programs, all layered on top of the basic TSX-32 OS. TSX-Online is
such a layered and vertical application.
So, the first question relating to customization is how to tailor system
startup so that a specified program gets run when the users log in.
To illustrate how this can be done we'll discuss how the system is
shipped.
The first place to look for custom start-is in the TSX32.GEN file.
Without digressing, terminal devices are defined with a statement of the
form
DEVICE=TT/HANDDEF=SERIAL/CONTROLLER=A
UNIT=1/ ...options...
Where "...options... " are a set of parameters for controlling the
terminal. There are many options.
Starting a job on a terminal
After system initialization is complete, if nothing is done
to customize the system,
the terminals will do nothing until the CR key is pressed. At that
point they will issue a startup message and KMON will be launched.
The user will be presented with a command prompt.
The first customization we can do is to have KMON automatically start
when the line is initialized, instead of waiting on a CR. To do this,
we specify the following option:
DEVICE=TT/HANDDEF=SERIAL/CONTROLLER=A
UNIT=1/START
This just means "start the line automatically".
Running a command procedure on line startup
In our discussion of command files recall we said that KMON reads and processes
lines from the command files. The next thing that we can do to customize
the system is to associate a "start up command procedure" with a terminal
line. This is a command procedure which executes the first time a job
is initialized for the line. This can be used to perform first time
initialization for the line. The command procedure can run a program
or simply display additional information.
Here is how we specify a startup command procedure:
DEVICE=TT/HANDDEF=SERIAL/CONTROLLER=A
UNIT=1/START/CMDFILE="SY:START.CMD"
Now, when the system initializes the line it will start KMON and KMON will
execute the file SY:START.CMD. This command file can contain anything
valid for a command procedure, including execution of a program.
User privileges
An important concept to introduce at this point is the concept of
user priveleges. These specify various things that the user can and
cannot do with respect to system operation or device access
and are used to allow access to a restricted and safe subset
of items for a set of users. Each job has a set of "privilege bits"
which enable or disable access to specified features. When the system
starts in the way we have been describing a job has "all" privileges
set. For developers of vertical applications it is desirable to restrict
privileges on a user by user basis. Thats where the LOGON program comes
in.
The logon program, Usernames, UIC, and TSAUTH
The LOGON program puts up a "Logon Please:" prompt and collects
username and password information from the user. It then
consults a file called SY:TSXUAF.TSX to see if that user exists,
and if so initializes the user to a specified UIC and sets the
user's privileges. A "UIC" is a set of two numbers (like 100,101)
which identify the user. The UIC is used to control access to
system facilities, and is part of the big picture of restricting
access to privileged facilities.
A program called TSAUTH is used to maintain the "User Authorization File",
or UAF. With it you add users, modify them, and delete them.
Running the logon program at startup
We now have two bits of knowledge about startup: We know how to
start a specific named command procedure on a specific terminal line
(by modifying the TSX32.GEN file) and we have a body of knowledge
that tells us of a way to restrict access to privileges through
the TSAUTH and LOGON programs. Lets put them together by
modifying the contents of SY:START.CMD, our startup command procedure,
as follows:
!
! Contents of SY:START.CMD
! Log on the user
!
r logon
The lines beginning with '!' are comments and are ignored. Now what
happens? When the system starts, the terminals automatically start
and execute the SY:START.CMD command procedure (because we told that
line to do that in the TSX32.GEN file) and that command procedure runs
the LOGON program, which prompts for a username and password and sets
the initial privileges for the user. At the end of that we still drop to
a KMON prompt, but now access to the system is password restricted to
people who are in the UAF.
Note that since the startup command procedure name is specified
on a line by line basis you could easily have a different startup
command procedure for each terminal,
or have some set share the same one and others
have a different one, or have them all execute the same one.
Custom logon processing for each TSAUTH user
The next level of customization is to allow each user who runs
the logon program to have a command procedure specific to them
execute when the log in. This command procedure would execute
no matter which terminal they were logged in at, after they
successfully logged in.
This level of processing is now within
the domain of the LOGON program/TSAUTH; the OS neither knows nor
cares about the concept of logon command procedures. It is simply
executing programs. There is a field in the
UAF for each user which allows you to specify a logon command
procedure for the user. When the user logs in successfully the
LOGON program exits and lets KMON execute the specified command
procedure, which may change directories, run a "cookie" program,
set the prompt, or any other custom logon desired by the user.
A conceptual point about LOGON and TSX-Online startup
The important point about LOGON/TSAUTH user authorization is that it
takes a OS job concept, the concept of UIC's and the concept of
privileges, and places a layer around it by adding custom command
procedures and a prompt for a username and password. The LOGON
username is important, and certain things will not function without one,
like network device access.
However, you can develop applications which
bypass running the LOGON program. The best example
is TSX-Online. The line startup for TSX-Online is not the LOGON program
which consults the TSXUAF.TSX file, it is a TPR program which consults
the TSX-Online user file. This user file is much more complex than the
TSAUTH user file because it contains information about file uploads
and download and accounting information far beyond the scope required
for a TSAUTH user.
So, the point is that as a user of TSX-32 there
is no automatic and mandatory processing which occurs as the system
boots for each line. You could have line run a program which didn't have
any concept of a logon but simply launched into an application. You
could devise your own logon concept and have IT start up when the
line started instead of the LOGON program. You could use the TSAUTH
type user concept and launch custom command procedures based on
TSX-32 UIC's and user ids.
A short quiz
Here are some questions which will test your knowledge of TSX-32 startup.
-
Which command procedure is first executed during TSX-32 system startup?
-
What is the relationship between the MAKELOAD program and the TSXLOAD
command procedure?
-
Files with names "*.REX" are loaded into memory during startup.
What program loads REX files?
-
What is the name of the .REX file which contains the networking code?
-
What is the command procedure which starts networking? What command
procedure starts it?
-
The keyboard monitor is a program. What is the program's name?
-
(Not a question)
Remember that KMON can do 3 useful things: Execute a command procedure,
start programs, and execute internal, or built-in commands.
-
What is a "built-in" or "internal" KMON command? Give an example.
-
How does KMON "know" when you type "DIR" that DIR is a program and not
a built in command?
-
When you type "@CMDFILE.CMD" at a prompt who opens the file? The OS or KMON?
-
When you type at a prompt KMON is the current program. When KMON starts
a program like DIR the OS replaces KMON with the DIR program for the duration
of the execution. What happens in your job when the DIR program is finished?
-
This is a trick question:
When you are executing a command file how does KMON "know" which line to read
from the command file? How does it advance through the command file?
-
What is the command to start a command procedure as a detached job?
Is it a program or built-in KMON command?
-
What happens to output from a program when it is run as a detached job?
-
When you execute a command procedure as a detached job how do you
tell the system to write the output to a log file?
-
When a job starts on a line, what is the name of the command procedure
executed for line? How do you change this?
-
How do you set up a command procedure to be executed when a particular
user logs on with a TSAUTH style username and password?