Changes to Dump Process JCL

SMFDLS Control Statement Reference › The SMFDLS Driver › Changes to Dump Process JCL

Changes to Dump Process JCL

In addition to changing the program name in the JCL from SMFD to SMFDLS, there are some changes that need to be made to your CA SMF Director JCL if data is being dumped from logstreams, due to ddname conflicts.

The table below indicates the non-logstream dump process ddnames that will need to be changed to logstream dump process ddnames:

Change this:	To this:
SYSIN	CAIIN
SYSPRINT	CAIPRINT

Note: Only the ddname needs to be changed. Nothing else about the file is different.

In addition to these changes, there are four new ddnames for the driver program:

CAILSNM

Placeholder ddname. This data set passes the name of the logstream to be dumped to SMFDLS. This data set is optional, and is only needed if the JCL control statement is coded in the SMFDLSIN file described below.

SMFDLSIN

Input control statement file for SMFDLS control statements. (These are not for SMFD control statements. Those should be allocated to CAIIN).

SMFDLSPR

Output print file for SMFDLS only. SMFD output will be written to CAIPRINT.

SMFDOUT

Output data set for SMF records being read from the logstream. This file has differing requirements that are based on whether CA SMF Director is deleting the SMF records from the logstream after copying and indexing them.

If the product is not going to delete the records, then the file can be allocated to DUMMY or it can be allocated to DASD or tape.

Note:

Delete the records means that the System Logger policy definitions are used to determine when the records are deleted.
DUMMY as defined in the sample CASFDUML PROC.

If CA SMF Director is set to delete the records, then the SMFDOUT must point to an allocated DASD or tape file. If SMFDOUT is allocated to DASD, the allocated file must be large enough to accommodate all of the records that are dumped, otherwise the dump process fails.

We recommend, that sites set up their SMF logstreams to be cleared through the definitions in their System logger policies. Having CA SMF Director delete the records after copying them results in an increase in overhead during the logstream dump process. This deleting method also adds another possible failure point in the process if something goes wrong with the SMFDOUT file.