Logreader Software Changes

Internal change only.

Previously, it was possible for LOGREADER to send corrupted tape notices to SUPERVISOR, causing a SEG ARRAY fault at 86928000, if multiple SUMLOGs had been processed and a large number of tape events had been created. The problem was due to incorrect handling of job/task number collisions tracked from the various SUMLOG files.

LOGREADER will again correctly handle COPYAUDIT tapes that have been created with either COPY or QUICKCOPY (either with or without the CHECK option). Also, tape scratches and 'New Vol' event entries will now be better handled.

This is a major change to the LOGREADER utility. It no longer uses SUPERVISOR's FPORT port file interface to process missed tape notices that have been extracted from the SUMLOG. Further, LOGREADER cannot now be run standalone from MARC, CANDE or WFL; a new SUPERVISOR command called LR replaces this functionality. Please refer to SUPERVISOR DNote 531.22 for more information.

Use new INCLUDE/META

LOGREADER will now pass all tape log VOLUME ONLINE records for analysis by SUPERVISOR so that UNSTACK-ed tapes, created by the Unisys TAPESTACK utility as unlabelled tapes, can be updated in the database with the correct volumeid and fileid when the tape first goes on-line after being created.

Due to the way that TAPESTACK unstacks a virtual tape volume, multiple unlabelled tape notices would have been sent by LOGREADER, one for each file being written. This behaviour is detected BY LOGREADER and is automatically suppressed.

Previously, running LOGREADER without any file-equation caused all SUMLOGS to be searched by default, including the current *SYSTEM/SUMLOG file. This behaviour has been changed; LOGREADER will now default to the current SUMLOG only if there has been no file-equation. For LOGREADER to search ALL Sumlogs, the utility must be now be run with the SW2 task option set.

The internal version for LOGREADER has been change to reflect MCP 5.1 compatibility.

Elimination of diagnostic DISPLAY message during SUMLOG scanning.

The fix applied in 500.04 to always update the timestamp of the last TRIM update did not work correctly under all circumstances. This behaviour has been corrected

LOGREADER will now always inform SUPERVISOR of the timestamp of the last record in the current SUMLOG during a SUPERVISOR restart. This timestamp is used by SUPERVISOR to tell LOGREADER from which log time it should start reading on the next restart but was only being updated if no tapes were found during the run. This change helps to reduce the time that LOGREADER may take in subsequent restarts.

COPYWRITE now writes LOG VOLUME ADD (Major Type 15, Minor Type 6) records into the SUMLOG when a Disk Farm or CD image has been created by the Flex FAMILYMANAGER and MERGETAPE utilities. These log records are now automatically detected by LOGREADER during a SUPERVISOR restart or H/L.

The change documented in DNote 500.02 caused some normal tape creations to appear with the prefix 'APPENDED' instead of 'CREATED' in the tape log. This problem has now been fixed.

LOGREADER will now detect log volume tape append operations (Major type 15, Minor type 17) and pass them to SUPERVISOR for processing. Please see SUPERVISOR DNote 500.10 for more information.

Internal Metalogic Change.

LOGREADER will usually automatically set the FILEID of any new library/maintenance tape detected in a SUMLOG to 'FILE000', even for continuation volumes. If a COPY dumped more than 999 files, LOGREADER would use the FILEID retrieved from the close record of the log (which always has the file count built into the FILEID e.g 'A/FILE24556') and not reset it to 'FILE000'. This effect had implications for Opal attributes such as TAPENAMESERIALS, which searches the METATAPELIB database for exact tape name matches.

This change also fixes a problem where a tape-tape COPY using the DUMPALL utility caused multiple tapelabel events generated after each file was copied.

If LOGREADER was run against a SUMLOG with software configuration records that were created when the system did not have an established HOSTNAME, LOGREADER would fault with a SEG ARRAY error at 76508000. Since a SUMLOG may have several software configuration records, LOGREADER will just ignore these entries.

Previously, running the LOGREADER utility required to be run with a parameter of the SUPERVISOR usercode under the Tape Librarian usercode. LOGREADER will now automatically determine Supervisor's usercode which eliminates the need for a parameter. Hence, LOGREADER can be run:

RUN *METALOGIC/SUPERVISOR/LOGREADER;
FILE SUMLOG=*SUMLOG/1/110802/000123 ON DEV

LOGREADER will abort if the calling usercode is not the Tape Librarian or Supervisor's usercode cannot be determined.

LOGREADER will now handle 'foreign' SUMLOGS correctly passing the system serial number and hostname from the SUMLOG instead of the calling machine. This means that hostname-based rules will now be correctly applied to tape notices extracted from foreign SUMLOGs when LOGREADER is run stand-alone.

Finally, when LOGREADER is processed by SUPERVISOR during a restart on either master or slave systems, only SUMLOGs which belong to the local system will be processed. Previously, LOGREADER would inspect all logs on the relevant families, regardless of source.

This is only to change the version to 48. Version 470.01 is still valid on MCP 48.

Previously, LOGREADER would fault with an INVALID INDEX when processing tapes created with newer density formats e.g. DDS2, DDS4, FMTDLT20 etc. This problem is now fixed.

The LOGREADER utility now supports the Unisys MORETASKS implementation allowing the provision of mixnumbers up to 65535. This is achieved by setting the system options MORETASKS (OP+MORETASKS), halt-loading and changing the MAX command. In particular, this change supports the same implementation in OPAL and SUPERVISOR, see SUPERVISOR Dnote 460.12 or OPAL Dnote 460.02 for more information.

Previously, LOGREADER could have faulted with an INVALID INDEX when scanning the SUMLOG, after a Supervisor restart, if no mix information was found for a new volume log entry.

This problem is now fixed.

Also, a BNA warning log entry concerning data truncation was also logged during LOGREADER's port file interchange with SUPERVISOR. Although no data was ever lost, the occurrence of such warnings has now been eliminated.