Logo
Back

◆ Supervisor Solutions

Supervisor and MCP MORETASKS
The following link describes the relationship between SUPERVISOR and the MCP MORETASKS implementation that permits Unisys to increase the maximum number of stacks, mix and session numbers. This MCP functionality was introduced some time ago (initially in MCP 45.1) and all Metalogic software had been changed to support the higher values. MCP MORETASKS
LOG Search Opals

The ability to search multiple SUMLOG files using OPAL scripts from SUPERVISOR has been available for some time now. However, a certain degree of OPAL knowledge and familiarity with the SUPERVISOR EVAL command (and it's control options) is required, especially for the casual searcher. The SEARCH set of OPAL routines offers a tailored, menu-driven alternative.

The SEARCH Opals generate a run-time in-line SITUation and ODTSequence of OPAL context LOG that are combined using the EVAL command to generate the search. The EVAL uses SUPERVISOR command modifiers to filter the search by date and time, log record type, find target etc.

The SEARCH Opals can:

  • Search the current SUMLOG and multiple, contiguous SUMLOGs automatically
  • Process logs faster and with less CPU overhead than LOGANALYZER
  • Search on multiple log record types with or without a FIND target
  • Limit search to number of records searched or found
  • Route output to printer or, very conveniently, to email
  • Handle multiple, concurrent log search requests
Once installed (see instructions at the end of this note), from a SUPERVISOR window, enter the following command:
TT DO SEARCH

A formed screen will be displayed:

This screen allows the user to select log search criteria, similar to the MARC LogAnalyzer menu. Multiple SEARCH operations can be run simultaneously.

  • If no log start or end dates are given, today's date is assumed.
  • Selections are made by placing 'X' or 'x' into the log type selection fields.
  • Current record types include BOT/BOJ, EOT/EOJ, Messages, File OPEN and CLOSE, MCS, Operator commands, Volume entries, TCPIP, LOGON/LOGOFF and Libraries
  • Similar to LOGANALYZER, the search may be filtered by a mix number range.
  • If an email address or PDEF (with a SUPERVISOR mail destination and NOTE) is associated with the station's usercode and a TT USE DESTINATION that starts with 'MAIL' then the output will be sent to that usercode.
  • Otherwise, an email address in the last field of the form. The generated email has a subject line which is a condensed version of the requested fields.
  • As the scan progresses, for every 50 records retrieved, there will be updates to the terminal status line.
  • SEARCH will only work correctly on Supervisor version 50.500.03 or later
  • The FIND field will work in conjunction with selected record types - the find text is *NOT* case sensitive since both the FIND target and the LOGTEXT attribute are both up-cased.
  • Note that log analysis output is presented in REVERSE-CHRONOLOGICAL order; this is a design constraint but may be changed later.
When selections have been chosen, move the cursor to home and transmit.

The generated EVAL command can be seen using the TT INLINE ? command and can be re-run if desired.

The following is an example of the printout being routed to email and viewed in an Outlook email client:

Installation instructions

Download the SEARCH OPALs container from HERE.

Unzip and transfer the wrapped container to a mainframe where SUPERVISOR is running. From CANDE:

WFL UNWRAP *= OUTOF "SEARCH.CON"

The following file will be unwrapped:

(META) OPALS/SEARCH

From a SUPERVISOR window:

TT ENTER FROM (META)OPALS/SEARCH ON <family>
            
Tracking WFL jobs that have been Q-DSED

The following Flex SELECT will capture all files created in the past hour at the time the script is run:

Since Supervisor release 490.26 (Feb'2004), a new context called JOBREJECT has been available allowing the tracking of jobs that have been Q-DSED by the MCP (e.g. invalid queue, family mismatch etc.). Supervisor can detect the rejected job log entries (Major type 1, Minor Type 7) but there is limited information available from these records so Supervisor will read back in the current SUMLOG to retrieve an accompanying EI (Establish Identity) record associated with the job. This additional processing allows attributes such as the job name, usercode, accesscode and chargecode to be available.
 TT DEFINE + SITUATION JOB_REJECT(JOBREJECT):
    TRUE

TT DEFINE + ODTSEQUENCE JOB_REJECT(JOBREJECT):
 #A:=MAIL("To:Alerts@metalog.com;Subject:JOB Q-DS of "&NAME,
  #("The following job was Q-DSED at ",
   TIME(LOGTIME),,DATETOTEXT(LOGDAY,DDMMYYYY),/,
    "Job : ",NAME, " Usercode: ",USER,/,
     "Job No: ",LOGJOBNO,/,
      "reason: ",ERRORNUMBER)); % INVALIDQUEUE,INVALIDFAMILY etc

TT WHEN JOB_REJECT DO JOB_REJECT

The above will capture all Q-DS entries and email an alert message to alerts@metalog.com. Note that LOGGING must be turned on for EI records (Log Major type 1,Minor type 0).

How can Supervisor handle Saturday and Sunday as working days

An OPAL script with a context of LOGON can be used with the SUPERVISOR EVAL command to 'scan' one or more SUMLOGS by specifying start/end log date and times. For example, to print all log-ons records for the time period 1st October 2003 to 30th October 2003:

	TT EVAL (LOGON:USER="META") [@0000  1/10/2003-2359 30/10/2003]         
   DO (LOGON: PRINT(LOGTEXT))	

This command will automatically search ALL logs for this time period; note that EVAL returns log records in reverse chronological order i.e. most recent first. If any SUMLOGs are missing, the EVAL will stop with a warning message. The SUPERVISOR command SHOW LOGS will indicate all available SUMLOGS found on the DL LOG family and that specified by SUPERVISOR's own USE FAMILY FOR LOGS

Why do my OPAL compiles generate 'Warning, This construct is unsafe' ?

This behaviour was a change introduced to protect against unexpected output being sent to the MCP by an ODTSequence. It was primarily to warn about PUTSTR and GETSTR use as statements but, in this implementation, it also affects stand-alone GET, PUT, COUNT, MAIL where numeric values would be passed to MCP.

For a DO or WHEN, can the script determine usercode it's running under

The WHENID self-knowledge attribute has a variety of parameters including USER; so, the construct

WHENID(USER)

will return any usercode associated with the slot, as assigned by the FOR prefix.

How can the automatic COPY of the SUMLOG file after a TT TL be disabled?

If the system DL LOG setting matches the disk family specified by SUPERVISOR's own 'TT USE FAMILY... FOR LOGS' setting then released SUMLOGs will not be automatically copied and removed after a SUPERVISOR TL. You can interrogate the current setting from an ODT or a SUPERVISOR window:

TT USE

To change the setting to the family LOGPACK:

TT USE FAMILY LOGPACK FOR LOGS
How do I stop a WHEN.. DISPLAY from an ODT that I don't have access to?

SUPERVISOR WHEN..DISPLAYs can only be terminated from the original source station except for ODTs. For an ODT, the VIA modifier can be used to prefix the WHEN disable e.g

TT VIA 1 WHEN LABEL DISP

This command can be used from another ODT or any SUPERVISOR window and will trick SUPERVISOR into thinking that the command came from ODT 1. Note that this command cannot be used to terminate WHEN..DISPLAY that originated from a SUPERVISOR COMS window or REMOTESPO.

It should also be noted that if a COMS window or REMOTESPO is closed, any WHEN that originated from that station will:

1. If the WHEN is a WHEN..DISPLAY, it will be immediately terminated by SUPERVISOR.

2. Any other WHEN or DO will have it's originating unit, as seen in a TT WHEN ? response, set to the value 0. All subsequent output, generated by SHOW or CALL DISPLAY, will be routed to the 'master' ODT (as seen in a TT USE response).

Can I find out the unit number of the base pack of multi-volume disk family

Typically, you might want to know this to automatically IL a waiting entry which is looking for a file on the wrong family. One simple way to find this information, is to use the OBJECTS function.:

	$U:= OBJECTS(PER=PK:LABEL="MERGE" AND UNITNO=BASEPACKUNIT)

In the above example, the OBJECTS call will return, into the string variable U, the base pack unit number of the family MERGE and is ideal for the IL command you want to do. The UNIT=BASEPACKUNIT check prevents all family indices, except for the base pack, from being included.

So, if running an ODTSEQUENCE whose context is MX then the following statement would perform the IL:

	ODT(MIXNO,"ILPK",$U)
How can I report on Defined Opals?

The TT SHOW command gives some brief information on Define OPALs, but it is possible to write an ODTSequence to give a more detailed report. Follow this LINK for more details.

How can I have Supervisor SN a series of blank tapes? can I have Supervisor SN a series of blank tapes?

A situation of type PER=MT could be used to react to an unlabelled tape being mounted, with an ODTS performing the SN. An example based on a customer request can be found HERE.

How to programmatically check if another OPAl script is running?

Apart from TT WHEN ? is there any other way of checking whether or not a Supervisor script (situation + odtsequence) is actually running?

Ans: The OPALINUSE attribute provides this capability: HELP ATTR OPALINUSE

---- HELP ATTRIBUTES ---- 
OPALINUSE (SYSTEM) RETURNS BOOLEAN           
          PARAMETERS : 1. STRING           
          SEMANTICS : OPALINUSE

is true if the contents of the string parameter matches a program assigned to the OPAL machine. The string can be a wildcard pattern. A TRUE is returned for any matching identifiers. The attribute will match situations, odts, and displays.

Examples:

IF OPALINUSE("ODTS TEST") THEN % Active ODTS called TEST IF OPALINUSE("ANYOPALNAME=") THEN % Any active SITU, ODTS or DISP starting with ANYOPALNAME

Tracking real-time deletion of active codefiles

This problem can be very inconvenient; if a running codefile is deleted often the first you know about it is a NO FILE the next time the system is restrted. The following SUPERVISOR log script uses the FILESTATUS context to trap files being deleted and checks FILEKIND and TITLE to see if the fail matches user-specified criteria. This script will even trap codefiles deleted by a directory removal (e.g. REMOVE OBJECT/LIVE/=).

TT DEFINE + SITUATION FILEREMOVAL(FILESTATUS=REMOVE):
OLDFILEKIND GEQ COMPILERCODEFILE AND OLDFILEKIND LEQ CODEFILE AND
OLDTITLE HDIS {"*SYSTEM/","(LIVE)OBJECT/","(RT)CODEFILE/"}

The ODTS constructs the codefile title and adds the ON <family part. The OBJECTS call checks the whole mix looking for anything in the mix using the CODETITLE attribute. This always has the ON part associated with the name and is immune to the effects of task name changing for programs with MP+TASKING. The alert go to the Hotline program (either PC or A-Series variants) using a mapping called CRITCL and also generates a waiting entry

TT DEFINE + ODTSEQUENCE FILEREMOVAL(FILESTATUS):
$OLDTITLE:= OLDTITLE&" ON "&LABEL;
IF $LIST:=OBJECTS(MX=A,W,S,LIBS:CODETITLE EQL $OLDTITLE) NEQ EMPTY THEN
BEGIN
$MSG:="WARNING!! RUNNING CODEFILE REMOVED: "&$OLDTITLE;
RECORD[CRITCL] ($MSG);
RECORD[CRITCL] ("AFFECTED MIX NOS=" & $LIST);
SHOW("BEGIN JOB SUP/ALERT;",
"DISPLAY ACCEPT(""",$MSG," (",$LIST,")"");END JOB");
END;

What changes are needed for RECORDER/HOTLINE to use TCP/IP instead of BNA?

By default, RECORDER and HOTLINE will use the BNAv2 protocol; to change this behaviour, use the following SUPERVISOR command:

	TT REC TCPIP 44444

Where 4444 is the TCPIP port number to be used by Hotline and Recorder programs; we use this an example so you can choose whatever number you wish as long as it is the same value on each system. You will have to do a TT REC QUIT and manually restart your Hotlines on each system but I think that's all you have to do.