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
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.
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>
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).
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
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.
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.
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
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).
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)
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.
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.
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
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;
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.