Description
Requests a chronological listing of the error entries in the order in which they appear in ERRFILE.
Selects error log entries for display by specifying up to five physical device I/O addresses or (if
a
is specified) specifies that error log entries for all devices are to be displayed.Requests a graphical display of error log entries.
Displays the current state of the four types of boundaries.
Terminates ELLA and exits to the monitor.
Selects error log entries for display by specifying up to five model numbers or (if
a
is specified) specifies that error log entries for all models are to be displayed.Resets all boundary parameters to their default values.
Reassigns the listing and message output device assignment during execution of ELLA. LP specifies line printer. KP specifies oper-ator's console for the ghost and batch modes and on-line terminal for the on-line mode.
Requests a sorted listing of the error log entries.
Requests a summary of the contents of the error file which lists the total number (in decimal) of qualified error log entries for each error type.
Sets· both the date and time boundaries where beg in and end have the form
[month/day/year][, hour:minute]
or
. [hour:minute]G month/day/year]
Selects error log entries for display through the specification of error record type codes (see Table 33) or (if
a
is specified) specifies that all types are to be displayed.These three services are all invoked by a CAll, 6 fpt in-struction; the addressed FPT contains a code and a parameter.
The FPT codes and the functions performed are as follows:
The following three CALs are intended for use by the monitor in performing diagnostic functions relating to the hardware-error log and must be issued by a program from the :SYS account. They provide the following services: reading from the hardware-error log, writing to the hardware-error log, and initiation of diagnostic ghost jobs.
FPT Code
a
1 6
Function Read Error Log Write Error Log Initiate Ghost Job
Hardware-Error Diagnostic CAts 85
The status of the requested operation is reported via condition-code settings summarized below. (Not all of the status indicated are appropriate to, or reported by, all three CA Ls. )
CC 1 CC2 CC3 CC4 Status
o o o
o o o
o o o o
o
o
Norma I return.o
Request denied: insufficient privi-lege, not in :SYS account, or buffer is not a data page.o
Error during operation (Read or Write), or job unknown (Initiate).o
Last buffer.o
Error log does not yet exist (Read).In each case, the calling program must be of privilege level CO or greater; otherwise CC 1 is set to 1 and no action is taken.
READ ERROR LOG
The format of the FPT for a read-error-Iog request is
A variable number of words up to a maximum of 256, de-pending upon the contents of the error log, is read to the area addressed by the FPT. This is a 'destructive' read, returning error-log granules to the monitor's avai lab Ie pool as they are exhausted.
The error-log file is not protected against simultaneous use;
thus only one program in the entire system should read this fi Ie.
86 Hardware-Error Diagnostic CALs
WRITE ERROR LOG
The format of the FPT for a write-error-Iog request is
The second byte of the data record addressed by the FPT must specify the number of words to be written, up to a maximum of 253. The first byte of the record should con-tain a type code.
INITIATE GHOST JOB
The format of the three-word FPT for an initiate-job request is
word 0
words 1 and 2 (Name of job to be initiated)
n a
1 a
2 a
3
a n-3 a
n-2 a
n-1 a
n
0 1 2 3 14 5 6 7 8 9 10 11112 13 14 15 16 17 18 l'iT20 21 22 23 24 25 26 27128 29 30 31
(Name of job must be in TEXTC format.)
If the program to be initiated is already in execution at the time of the request and is not in a waiting state (WAIT CAL with unexpired time), the norma I return is made (CCI =0).
If the program is in a waiting state, it wi II be activated immediately at the WAIT CAL plus 1 and a normal return is made to the initiating program.
7. SHARED PROCESSOR FACILITIES
INTRODUCTION
This chapter describes the shared processor facilities of CP-V. These facilities permit the sharing of the code for compilers, assemblers, command language processors, de-buggers, libraries, and other programs among all simulta-neous users.
Shared processors are not limited to programs provided by Xerox. The faci lities may be effectively used when-ever a program has a high probability of common usage.
Service bureaus, for example, may use the mechanism for proprietary packages. Corporate installations may use the mechanism for programs with a high use frequency.
Most programs may be established as shared processors by naming them at SYSGEN time. This causes the file copy of the program from the :SYS account to be written on the swapping disk during system initial ization. The program is then avai lable through high-speed swapping I/O.
The file copy of the program is retained for recovery pur-poses and may be copied to another account and run as an unshared program under Delta for development and debug-ging purposes. If the load module in the :SYS account is replaced, the shared copy of the program on the swapping disk is updated to the newer version in the event of a sys-tem recovery.
To qualify as a shared processor, a program must meet cer-tain requirements. These requirements are outlined in the remainder of this chapter. The most stringent requirement relates to the single overlay level that is described in the section below titled "Overlay Restrictions ".
PUBLIC PROGRAMS
A program whose load module is in the :SYS account is a public program in the sense that it may be called either by a control card containing the ! symbol and the program name, or by an entry of the program name in response to a TEL prompt (I) for commands. Each user of a public pro-gram has his own copy of the propro-gram.
OK
32K40K
Available area Monitor Context
SHARED PROGRAMS
Shared programs are called in the same manner as pub I ic programs. However, each user of a shared program has his own copy of only the data and DeB portion of that program;
the procedure portion is shared by all users associated with the shared program.
There are four distinct kinds of shared programs:
1. Ordinary shared processors.
2. Special shared processors.
3. Shared debuggers.
4. Public libraries.
All shared processors must be built by the batch loader.
Ordinary shared processors occupy the same virtual memory as user programs and may not be associated with them.
Special shared processors, shared debuggers and publ ic I i-braries occupy (and are overlayed in) the special processor area. Figure 11 shows the virtual memory allocation for shared programs that are biased within the special processor area. Shared debuggers may be associated only with user programs; they may not be associated with any other shared processors. Public I ibraries may be associated with user programs or ordinary shared processors; a public library may not be associated with a special shared processor. Note that both a shared debugger and a core library may be con-currently associated with a user program. This is possible because the procedure portion of the debugger and the library may be overlayed in the special processor area.
LOG-ON CONNECTION
Commonly used programs, such as BASIC, may be called automatically by LOGON. The name of the program to be called, which may be either a shared or public program
112K 128K
Special processor area
area area
(User program or dynamic data) Data (i f any)
I
DeBs (i f any) Procedure Figure 11. Special Processors - Virtual MemoryShared Processor Facilities 87
from any accessible account, is establ ished in the user's log-on record by Super. LOGON calls the named program for the user following a successful log-on.