ICL 1900 Series George 3 Operating System Macros

VIDIMOP

Function

Provides MOP facilities on 7181/4 visual display units (connected via a 7180/2 local VDU control unit) and on 7181/4 visual display units connected via a message buffering system or, if Communications Manager is in use, via a character buffering system.

Format

1. To run MOP via a local cluster control unit:-
   
   VIDIMOP *ID,JTtime,*CRfile description,NOGP
   
   
2. To run MOP via a message buffering system:-
   
   VIDIMOP *CC,JTtime,CLconceptual name,*CRfile description
   
   
3. To run MOP on VDUs controlled by Communications Manager (via cluster control unit, communications processor or scanner only):-
   
   VIDIMOP *CM,JTtime,*CRfile description

The JT, *CR, NOGP and CL parameters are optional and may occur in any order.

The JT parameter specifies the jobtime for the job. This parameter is not relevant when a *CR parameter is present. timehasthe same format as the milltime parameter in a JOBTIME command.

The *CR parameter indicates an initialisation (or reconfiguration) run. file description defines a basic file which contains details of the displays to be addressed. If the parameter is absent a normal MOP run is initiated.

The NOGP parameter is permissable only in format 1. If it is absent general poll procedures will be used, otherwise specific poll procedures will be used. General poll procedures are more efficient in terms of mill utilization, so normally this parameter will not be required. This parameter is not relevant when a *CR parameter is present.

The CL parameter is permissable only in format 2. If it is absent a 7900 Series communications processor will be ONLINEd. This parameter is not relevant when a *CR parameter is present.

Although MOP facilities on 7181/2 VDUs connected via a message buffering system are now built in to GEORGE, format 2 has been left for reference purposes.

Forbidden contexts

None, but not recommended in MOP and USER contexts.

Execution

Before the system can be put into everyday use the displays which are to be polled must be defined in an initialisation run. Thereafter normal runs adopt the procedure described in normal runs, but to define a new configuration to be polled another initialisation run must be made.

The Initialisation Run

This macro runs a job IDVSETUP (format 1), CCVSETUP (format 2) or CMVSETUP (format 3) under :LIB. This job loads :LIB.PROGRAM XKLn, and assigns to it the file named in the *CR parameter. The program reads in the parameter records until it reaches a terminator and then it is SAVEd into :LIB.PROGRAM XKLn(+1). The operator is then informed that the initialisation is complete.

The format of the parameter file differs between the local and remote programs:-

For the local case (VIDIMOP *ID), the file must contain one record for each display to be used. The format of each record is #xxyy or #xxyy*, where #xxyy is the octal representation of the hardware address of the display; the presence of the * denotes that this is a Code 2 display, and the absence of * denotes a Code 1 display, for example #0103 or #0305*.

The hardware address may be ascertained from the engineer: xx corresponds to the channel number of the cluster control unit and is in the range 00 to 17; yy is the specific hardware address of the display, in the range 01 to 17.

The last record in the file must be ****.

For communication with the operator about displays the program assigns each display an identifier number (numbering the displays consecutively from 1) in the order specified in the parameter file. Each parameter record is re-output to the job's monitoring file as it is read, together with, in the local case, the identifier number assigned to the display, and it is suggested that the listing of this file be retained for reference by the operator/engineer.

For the remote case (VIDIMOP *CC) each record in the file defines a seperate identifier or group of identifiers and takes the form n, n*, n(m), or n(m)*, where n is an identifier number and must be a decimal number in the range 1 to 4095, m is the number of additional identifiers in the group and must be a decimal number in the range 1 to 63. The group therefore consists of identifiers n to (n+m) with (n+m) < 4096. When the last character is *, the identifiers defined in that record are all Code 2 displays.

Identifiers must be defined in numerical order. For example:-

  1
  3*
  20(9)
  40(3)*

defines identifiers 1 and 20 to 29 to be Code 1 VDUs, and identifiers 3 and 40 to 43 to be Code 2 VDUs.

The last record in the file must be ****. Each record must start at column 1; leading and embedded spaces are not permitted.

If conceptual multiplexers are to be used, then better GEORGE core utilisation will result if the identifiers are consecutively numbered.

Each parameter record is re-output to the job's monitoring file as it is read together with, in the local case, the identifier number assigned to the display.

For the Communications Manager case (VIDIMOP *CM) the format of the parameter file is exactly the same as that for remote VIDIMOP, described above. The identifiers defined refer to the identifier numbers compiled into Communications Manager, and it is these identifiers that should be used.

Normal Runs

The macro runs a job IDVMOP (format 1), CCVMOP (format 2) or CMVMOP (format 3) under :MANAGER. (The username :MANAGER may be changed by suitably editing the macro VIDIMOP, but the new user must have REALTIME budgets if the local (*ID) or Communications Manager (*CM) version of the macro is to be used.) This job loads the version of :LIB.PROGRAM XKLn with the highest generation number, ONLINEs the appropriate communications device or conceptual and ENTERs the program.

If a display becomes inoperable, having previously been operable, or vice versa, the job outputs the appropriate informatory message:-

    IDENTIFIER n UNAVAILABLE

or

    IDENTIFIER n AVAILABLE

or

    IDENTIFIER n OFF TEST (*CC version only)

If output to a display fails the job outputs the message:-

    IDENTIFIER n ERROR

and attempts to output to the display again.

If the communications device fails the job outputs the message:-

    *ID (or *CC) INOPERABLE: SESSION ABANDONED

and finishes.

If the operator wishes to terminate the MOP session he should CONNECT to the VIDIMOP job and issue the command ON n,

where n=

    0 for Communications Manager (VIDIMOP *CM) version #XLK8 Mk.2

    2 for remote (VIDIMOP *CC) version #XLK4

    2 for local (VIDIMOP *ID) version #XLK2

After the ON n command the operator should DISCONNECT. The program will then output the message:-

    MOP SERVICE TEMPOARILY SUSPENDED

to each operable display, release the communications device, display:-

    VIDIMOP SESSION FINISHED

to the operator's console, and the job will end.

The following additional messages apply to VIDIMOP running with Communications Manager.

If, during setup procedure, VIDIMOP cannot open a WMC link to Communications Manager because the program slots are full, or Communications Manager is not loaded, the job displays the message:-

    NO LINK TO COMMUNICATIONS MANAGER SET UP

and asks the question:-

    SHALL I CONTINUE?

If the operator answers YES, the propram will continue searching for a link to Communications Manager, and will run normally if it finds one. If the operator answers NO, the job ends.

If VIDIMOP discovers that Communications Manager is no longer answering (because, perhaps, it has become suspended or deleted) the job displays the message:-

    WMC LINK TO COMMUNICATIONS MANAGER FAILS

and asks the question:-

    SHALL I CONTINUE?

If the operator answers YES, VIDIMOP will attempt to continue with its curent task;if the operator answers NO, the job will end.

Notes:

1. The operator may not CONNECT to IDVMOP, CCVMOP, or CMVMOP from a VDU running under the system as this will result in an irredemiable deadlock ni which neither thed MOP job nor the control job can be ABANDONed, but he may CONNECT from any other MOP device.
   
   
2. If any other failure occurs the job will take a postmortem print of the program then attempt to output the message:-
   
       MOP SERVICE TEMPORARILY SUSPENDED
   
   to all operable displays, and release the communications device.
   
   When this has been done the operator is asked whether he wishes to continue the run. If the answer is YES, the job initiates another run, jobname :MANAGER.IDVMOP1 (or CCVMOP1), then ends. If the answer is NO the job ends without attempting to start a new run.
   
   The monitoring file listing of the job should be examined to determine whether the fault can becorrected; if not the listing should be submitted through the normal GEORGE error reporting channels.
   
   
3. If installations which do not wish to run VIDIMOP on both a local cluster control unit and a message buffering multiplexer, it is possible to edit the VIDIMOP macro to preset the *ID/*CC parameter, so that the operator need only type VIDIMOP to run the job after the initialisation run has been completed.
   
   
4. If the remote (*CC) version is being used with a conceptual, identifiers may be ATTACHed to and removed from the system at any time by the central or cluster operator, using the ATTACH and CANCEL ATTACH commands.
   
   
5. It is possible to have one local (*ID) macro and one remote (*CC) macro being obeyed by the system at the same time. If it proves necessary to run two or more local, or remote, controlling jobs simultaneously (for example, where there are two cluster control units, or where the routing of LISTFILEs, as described below, is required for some displays but not for others) this is made possible by issuing a RUNJOB command to initiate the second or subsequent VIDIMOP job, rather than using the VIDIMOP macro itself. The format of this command should be:-
   
   RUNJOB jobname,:username,VIDIMOP,PARAM(*ID,JTtime)
   
   or
   
   RUNJOB jobname,:username,VIDIMOP,PARAM(*CC,JTtime,CLconceptual name)
   
   where
   
   jobname is arbitary.
   
   username will normally be :MANAGER
   
   the JT and CL parameters are optional
   
   
6. Response times on 7181/2 displays may be enhanced by making the controlling program REALTIME; this can be done by editing the VIDIMOP macro.
   
   
7. If the VIDIMOP macro (or RUNJOB) is issued fromm a remote console, acting as a cluster control, any listfiles initiated by VDU MOP jobs will go to output devices (if any) in the remote cluster, unless specifically directed elsewhere.
   
   
8. If the remote (*CC) version of VIDIMOP is to be used the NPUSIZE restore time macro should be included in the restore, specifying at least 131 words.
   
   
9. If an installation wishes to run VIDIMOP via Communications Manager only, it is possible to edit the VIDIMOP macro to preset the first parameter to *CM; the operator can then just type VIDIMOP to run the job, following the completion of the initialisation run.
   
   
10. When the Communications Manager version is in use, VIDIMOP input/output times may be improved by giving PRIORITY to the controlling program #XKL8 Mk.2, as well as REALTIME ON. In this case Communications Manager should also have PRIORITY. GEORGE response times in the system as a whole may, however, be adversely affected by having both programs with PRIORITY, in which case only Communications Manager should keep it.
    
    
11. When the Communications Manager version is in use the output buffer space required is 135 workds, and this should be included in the calculation for the value of parameter a to the NMOPB macro for a Communication Manager compilation (see TP4455 Communications Manager).
    
    
12. Under Communications Manager, since VIDIMOP attempts to fully open identifiers, where HNMOPTIONS2 is not present in the Communications Manager, parameter a to the NMIDE macro for a Communications Manager compilation should be set to 0.
    
    To cater for the CLEAR PASSWORD facility sites running #XKL8 under Communications Manager with single station VDUs require the following one-word change:-
    
    ALTER 2226,BRN 2227
    
    Without this ALTER, Communications Manager stops polling a line with a single VDU should a control character be typed when no output is waiting.

Library Entrants Accessed

:MACROS.VIDIMOP is used as a job description file
:LIB.PROGRAM XKL2 is loaded to control 7181/2 VDUs (VIDIMOP *CC)
:LIB.PROGRAM XKL4 is loaded to control 7181/4 VDUs (VIDIMOP *ID)
:LIB.PROGRAM XKL8 is loaded to control VDUs under Communications Manager (VIDIMOP *CM)

Examples

VIDIMOP *ID,*CR:MANAGER.DISPLAYS
VIDIMOP *ID,JT300MINS
VIDIMOP *CC,CLDISPLAYS,JT3600
VIDIMOP *CC
VIDIMOP *CM,*CR:VIDIMOP.IDES
VIDIMOP *CM,JT30MINS

Error Messages

These are generated by DISPLAY commands within the job description, and are self-explanatory.

Halts in the VIDIMOP Program

All halts in the VIDIMOP program are handled by the VIDIMOP macro. More details can be found in the manual TP4438, George 3 and 4 Operations Management.