Inquisitor program command syntax

The Inquisitor program includes SYSIN commands and optional command operands.

SYSIN commands

The Inquisitor program uses the SCANCMD, SCANDIR, and SCANPGM SYSIN commands that are described in the following table.

Table 1. SYSIN commands used by the Inquisitor
Command	Description
SCANCMD	Allows command syntax and operand consistency to be checked by the Inquisitor without initiating an actual scan for program libraries. It performs a parse only operation, although output files are opened. Error messages relating to syntax and operand errors are produced as usual. This verb is useful if you are formulating the best request combination when implementing on any given system.
SCANDIR	Collects data from program library directory entries. Contents of program members are not accessed. Compared to SCANPGM, its reduced data collection allows it to run faster. Although all syntactically correct operands are allowed, some operands relating to data from member contents are ignored during processing. SCANDIR collects all of the information needed for automated software identification, and is the command of choice for a production environment.
SCANPGM	Collects all data collected by SCANDIR, and information from member contents. Such information relates to program structure and history. Use SCANPGM without FULLIDR if you want to collect PDS load module link edit dates and can tolerate the additional I/O and elapsed time of the scan. Use SCANPGM with FULLIDR to collect LE compiler details. This is not recommended for ongoing system-wide scans. support might request SCANPGM output data to assist with problem diagnosis and resolution.
SCANDEV	Collects information about the input and output (I/O) configuration of the z/OS® system including online I/O devices, control units, and related channel path connectivity. The SCANDEV command has no operands.

The Inquisitor can process multiple requests in a single program run. The output of these requests is contained in the same file.

This syntax diagram shows the SYSIN commands and their operands.

Figure 1. Syntax diagram of library scan commands

Operand defaults are:

DSNAME(*) VOLUME(*) DEVICE(*) PROGRAM(*)

All operands are optional. They are:

DATASET Alias: DSNAME: This operand specifies one or more 1 to 44 byte data set name masks. Only data sets with names matching any masks specified here are processed. Data sets with names not matching any masks specified here are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for selection matching. The precise treatment of asterisks in these masks is altered by the presence of the CATALOG keyword in the request. When CATALOG is specified, mask matching becomes qualifier aware and a single asterisk represents one, or part of, one qualifier only. When CATALOG is specified, use a double asterisk to specify any number of qualifiers. The data set name selection mask is the only mask affected by the CATALOG keyword. When the CATALOG keyword is present, exactly one DSNAME mask must be specified.
XDATASET Alias: XDSNAME: This operand specifies one or more 1 to 44 byte data set name masks. Data sets with names matching any mask specified here are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for exclusion matching. If this operand is used, each mask must specify a subset of a DATASET mask.
VOLUME: This operand specifies one or more 1 to 6 byte volume serial number masks. Only volumes with serial numbers matching any mask specified here are processed. Volumes with serial numbers not matching any mask specified here, are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for selection matching. A volume serial number mask of six asterisks specifies the current IPL volume, which is ascertained during execution.
XVOLUME: This operand specifies one or more 1 to 6 byte volume serial number masks. Volumes with serial numbers matching any mask specified here are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for exclusion matching. If this operand is used, each mask must specify a subset of a VOLUME mask. A volume serial number mask of six asterisks specifies the current IPL volume, which is ascertained during execution.
DEVICE: This operand specifies one or more 1 to 4 byte device number masks. Only volumes with device numbers matching any mask specified here are processed. Volumes with device numbers not matching any mask specified here, are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for selection matching. Standard character string mask matching is used. The use of characters which are not hexadecimal digits will not be detected by the program.
XDEVICE: This operand specifies one or more 1 to 4 byte device number masks. Volumes with device numbers matching any mask specified here are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for exclusion matching. If this operand is used, each mask must specify a subset of a DEVICE mask. Standard character string mask matching is used. The use of characters which are not hexadecimal digits will not be detected by the program.
PROGRAM Alias: PGM: This operand specifies one or more 1 to 8 byte program name masks. Only programs with names matching any mask specified here are processed. Programs with names not matching any mask specified here, are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for selection matching.
XPROGRAM Alias: XPGM: This operand specifies one or more 1 to 8 byte program name masks. Programs with names matching any mask specified here are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for exclusion matching. If this operand is used, each mask must specify a subset of a PROGRAM mask.
STOGROUP Alias: SG: This operand specifies one or more 1 to 8 byte storage group name masks. SMS-managed volumes in a storage group with a name matching any mask specified here are processed. SMS-managed volumes in a storage group with a name that does not match any mask specified here, are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for selection matching. Volumes which are not SMS-managed are not processed unless the NONSMS keyword operand is specified.
XSTOGROUP Alias: XSG: This operand specifies one or more 1 to 8 byte storage group name masks. SMS-managed volumes in a storage group with a name matching any mask specified here are not processed. Multiple masks must be separated by one or more delimiters. This operand can be specified more than once in a request, whereupon all masks specified in all occurrences of this operand are checked for exclusion matching. If both this mask and a STOGROUP mask are used, then each mask must specify a subset of a STOGROUP mask.
NONSMS: This keyword operand specifies that volumes which are not SMS-managed are eligible for processing. The presence of this operand means that SMS-managed volumes are not processed unless the STOGROUP operand was used to supply a storage group name mask.
LINKLIST: This keyword operand specifies that all link list data sets are to be unconditionally included for processing.
AUTHLIBS: This keyword operand specifies that all APF authorized data sets are to be unconditionally included for processing.
NOALIAS: This keyword operand specifies that any program member marked as an alias is to be excluded from processing.
CATALOG: This keyword operand specifies that data sets to be processed are located from a catalog search rather than VTOC searches. Data set alias names are not processed. The Inquisitor triggers and waits for a RECALL operation for each migrated data set which passes data set name mask processing, unless NORECALL is also specified.
NORECALL: This keyword specifies that migrated data sets are not to be recalled and are excluded from processing. This operand only has effect when the CATALOG operand is also specified. Data sets with a catalog entry indicating a volume serial number of MIGRAT, or ARCIVE, are deemed to be migrated.
FULLIDR: This keyword operand specifies that a full scan of CESD and IDR records is to be performed, even when a module would not have been selected for such processing. Depending upon the exact nature of the request being run, this operand can significantly elongate the elapsed time of Inquisitor runtime.; This operand is ignored for a SCANDIR request.
REMIGRATE: This keyword operand specifies that when a data set which had to be recalled has been processed, DFHSM is requested to migrate the data set again asynchronously. Migrated data sets can only be processed when the CATALOG operand is also specified. Only data sets with a catalog entry indicating a volume of MIGRAT are remigrated.; The presence of this operand requires that the MCDS file is allocated to the DFHSM MCDS. Access to the MCDS allows the Inquisitor to avoid recalls for data sets which are not partitioned, do not have an undefined record format, and do not have a block size of at least 1024.
NOML2: This keyword operand specifies that data sets migrated to level two are not to be recalled and are excluded from processing. Migrated data sets can only be processed when the CATALOG operand is also specified. Only data sets with a catalog entry indicating a volume of MIGRAT are checked for level two status.; The presence of this operand requires that the MCDS file is allocated to the DFHSM MCDS. Access to the MCDS allows the Inquisitor to avoid recalls for data sets which are not partitioned, do not have an undefined record format, and do not have a block size of at least 1024.
ABRMIG: This keyword operand indicates that when a catalog entry with a volume of MIGRAT is encountered, the FDRABR product is to be invoked to determine whether a recallable archived copy of the data sets is available or not. If it is, then the data set is processed. If not, then the data set is not processed.; The NORECALL operand takes precedence over this operand.; The effect of ABRMIG is not affected by the ABRARC operand.; The presence of this operand requires that the ABRIN and ABRPRINT files are allocated.
ABRARC: This keyword indicates that, when a cataloged data set cannot be found on the volume, the FDRABR product is to be invoked in order to determine whether a recallable archived copy of the data set is available. If it is, then the data set is processed. If not, the data set is not processed.; The NORECALL operand takes precedence over this operand.; The effect of ABRARC is not affected by the ABRMIG operand.; The presence of this operand requires that the ABRIN and ABRPRINT files are allocated.
NOTAGDATA: This keyword indicates that data written to program libraries by the Product Tagger is not to be collected and written to the Inquisitor output file. Use this operand only when you do not want to update the Local Knowledge Base during the import process with the latest Tagger data that could be found by the Inquisitor.
MAXTASKS: This operand specifies the maximum number of VTOC-scanning subtasks to be activated by the Inquisitor. These subtasks reduce the elapsed time of an Inquisitor scan by enabling the concurrent processing of multiple volumes. Reducing the number of subtasks reduces the demand on storage in the region and does not impact performance unless the main task has to wait longer for VTOC scan results. The operand value is a decimal number in the 1 to 200 range. The default value is 10. The actual number of subtasks used does not exceed the number of volumes to be scanned. Too high a value may impact critical applications due to I/O queuing. VTOC-scanning subtasks are not used for CATALOG requests.
LIBMAINTASK: This keyword specifies that all library scan processing is to be carried out by the main task. Without this operand being specified, VTOC-scanning subtasks may scan PDS (but not PDSE) libraries for SCANDIR (but not SCANPGM) requests, which has the benefit of further reducing the elapsed time of the scan. Data collected by subtasks is held in region storage until it is processed by the main task, and SCANDIR collects a much smaller volume of data than SCANPGM. The main task uses DESERV FUNC=GET_ALL to read directories, whereas subtasks use QSAM which allows for efficient processing of corrupt PDS directories.
APISUBTASK: This keyword specifies that Program Binder API calls issued to process PDSE program objects during a SCANPGM FULLIDR request are to be performed by a subtask. Various conditions can cause Binder API calls to abend, and if such an abend occurs under the main task then Inquisitor processing is abnormally terminated. The main task can be insulated from such abends by attaching subtasks to perform the Binder API calls. Even if such subtasks abend, the main task can continue processing and should be able to complete a successful scan, provided that abending subtasks have not corrupted storage owned by the main task. Specifying this keyword will somewhat increase CPU overhead of a SCANPGM FULLIDR request, so its use is only recommended when it is known that such abends will be encountered and need to be tolerated.
INUSEWARN: This keyword specifies that failure to scan a data set because it was exclusively allocated to another job is to raise a warning condition instead of an error condition. When a data set scan attempt receives a DARC of hex 210, message HZAP092I is issued and the data set is queued for later retry. After the scan request is complete, queued data sets are reprocessed, and one of the messages HZAP093I (successful retry), HZAP094W (failed retry with INUSEWARN) or HZAP095E (failed retry without INUSEWARN) is issued, as appropriate.

SYSIN syntax rules for the Inquisitor

Syntax rules are as follows:

Only the first 72 bytes of an input record are ever scanned.
Short records are extended to 72 bytes with blanks.
Blanks and commas are equivalent.
Subparameters of value operands are specified in parentheses.
A continuation to the next record is requested by a plus or a hyphen when it follows a delimiter, or is at the start of a record.
A continuation cannot be requested in the middle of a word or value.
The part of the record following a continuation character is ignored and can be used for comments.
Records beginning with an asterisk are comment records.
Records containing only blanks or commas are comment records.
Comment records are ignored by syntax parsing logic, and do not alter continuation status.
TSO conventions apply to abbreviations. That is, operands can be abbreviated to the minimum unambiguous length. Verbs cannot be abbreviated.
If the input record contains an ampersand, the system symbol substitution routine ASASYMBM is called to perform symbol substitution processing.
All input requests are parsed and stored before the first request is processed.
If a syntax error is encountered, no requests are processed. This is to reduce the instance of incorrect or unproductive requests triggering lengthy DASD subsystem scans. The error is in the last record echoed in SYSPRINT.
Value masks are character strings which are compared to data found at run time. Comparison is performed one byte at a time, from left to right. For a match, the characters must compare equal, unless a generic mask character is found.
System static symbols, system dynamic symbols, and &SMF (SMF system identifier) and &SYSLPAR (LPAR name), can be used to construct value masks. &SYSLPAR may resolve to a null string if z/OS® is running in a virtual machine.
Valid generic mask characters are a percent (%), to flag a match for any single character, and an asterisk (*), to flag a match for any character string segment of zero or greater length.