INCLTIME

The period of time during which DSNEVENTs were lost and not handled by CMEM/Control-O. Once the CMEM monitor or Control-O is brought back up following an outage, the user must identify the period of time DSNEVENTs were not handled by CMEM/Control-O.

Can be specified only once. Mandatory.

Valid format:

yyyy/mm/dd,hh:mm-yyyy/mm/dd,hh:mm

The outage duration is the period of time passed between the CMEM critical error message or the message indicating the reason or command that caused the monitor to stop, and the CTO147I CTMCMEM - INITIALIZATION COMPLETE message of the new, functioning monitor.

The following are examples of critical error messages that CMEM/Control-O might issue before it stops:

• CTO107I SHUT DOWN UPON REQUEST FROM OPERATOR
• CTO109I CMEM/CONTROL-O MONITOR IS SHUTTING DOWN. A NEW MONITOR WAS STARTED
• CTO142S CMEM/CONTROL-O MONITOR DETECTED AN INTERNAL xxxx
• CTO121S CMEM/CONTROL-O MONITOR ENDED WITH ERROR
• CTO300S INTERNAL ERROR - REASON = xxxx. NOTIFY THE IOA ADMINISTRATOR

INCLTIME (continued)

Note: It is possible that the error occurred in the monitor before the last one as the last one was started automatically right after the failure but failed to recover from the error.

In addition to the outage time, there might be DSNEVENTs that took place before CMEM/Control-O ended, which CMEM/Control-O started to handle but did not complete before it went down.

The SMF records provided should cover the outage duration and also several minutes before CMEM/Control-O ended in order to include possible DSNEVENTs that were not fully handled. The exact duration prior to CMEM/Control-O ending that should be covered may vary. It depends on whether the jobs that are monitored for DSNEVENTs got fast service or were delayed (swapped out or did not get CPU). Since CMEM/Control-O handles such events under the jobs where they occur, the handling could be delayed when the jobs are delayed. If there were no such delays then it would be sufficient to cover one minute before CMEM/Control-O ended. Otherwise the delay duration must be estimated and added to the period that is covered by the SMF records provided.

SYSID

or

SYSTEM

System identification (from the SID parameter from SMFPRMxx or SYSNAME parameter in the IEASYSxx PARMLIB member). Mandatory.

INCLJOB

Job name or job name mask. Only the events triggered by these jobs will be listed in the DAEVENTS list. An example of a job name mask is FTP*.

More than one INCLJOB statement can be specified. Optional.

EXCLJOB

Job name or job name mask. The events triggered by these jobs will be excluded from the DAEVENTS list. An example of a job name mask is TEST*.

More than one EXCLJOB statement can be specified. Optional.

INCLDSN

Dataset name or dataset name mask. Only the events triggered by these datasets will be listed in the DAEVENTS list. An example of a dataset name mask is FILE.FROM.IBANK.*.

More than one INCLDSN statement can be specified. Optional.

EXCLDSN

Dataset name or dataset name mask. The events triggered by these datasets will be excluded from the DAEVENTS list. An example of a dataset name mask is FILE.FROM.IBANK.TEMP*.

More than one EXCLDSN statement can be specified. Optional.

_BPX_JOB

Job name of the FTP forked tasks. Specify one of the following:

• Job name of the FTP forked tasks as set by the _BPX_JOBNAME environment variable in the FTPD cataloged procedure.
• USER, when the forked tasks assume the name of the logged-in user.

Since this configuration is not commonly used, specifying this parameter is not required for most installations. For more information, consult your FTP administrator or see "Using _BPX_JOBNAME for similar job names" in the z/OS Communications Server: IP Configuration Guide.

Note: If you receive CTMR2RE or CTMR2ZE messages regarding FTP records during CTMEVRT execution, this parameter probably requires adjustment.

Optional; set if the _BPX_JOBNAME environment variable is set in the FTPD cataloged procedure or if the forked tasks assume the name of the user.