| < Day Day Up > |
|
There are not very many operational considerations for CQS's use of the System Logger. If there are no errors, and if the log stream doesn't get full, then it pretty well takes care of itself. Even some errors are handled automatically by CQS with little or no (CQS) operations involvement. Most of the operational requirements are the responsibility of systems management.
CQS requires that the System Logger be available, and that a log stream be defined for full function shared queues and one for fast path EMH shared queues (if fast path is defined in your environment). If the log stream name is not defined in CQSSGxxx, CQS will fail during initialization. If the System Logger is not available, CQS will issue a message (CQS0350W) and wait.
CQS does not dynamically define log streams and it does not use model log streams. The CQS log streams must be defined in the LOGR policy before CQS is started.
There is an MVS command that displays information about the status of the System Logger or about the log stream connections. The command is:
D LOGGER,STATUS D LOGGER,CONN,xxxx
Where 'xxxx' is zero or more parameters defining the output of the command. This command does not display the current utilization statistics of the log stream. It just tells you the status of the log streams and what structures are defined for them. 4.3.4, "Monitoring for offload conditions" on page 128 describes a better way to get useful information.
"Printing the log stream" on page 120 shows a sample job that can be used to print the log stream itself. All normal DFSERA10 control statements apply.
Unless additional extents are requested by the DSEXTENTS parameter in the LOGR policy, the log stream will become full when there are 168 offload data sets allocated and all are full, and interim storage is full. If this occurs, you will get a LOG FULL condition. CQS issues a message, deletes a few log records from the log stream to make space for structure checkpoint log records, takes a structure checkpoint, and continues processing. The CQS message is:
CQS0350W CQS LOG CONNECT DS DIRECTORY FULL LOG STREAM logstr-name STRUCTURE str-name
While the structure checkpoint relieves the shortage, it will have a temporary impact on the availability of the log stream and CQS will not be able to process any IMS PUT requests until the structure checkpoint is complete and CQS has deleted the tail of the log stream. To avoid this problem, you can run the IXCMIAPU utility periodically to determine how many offload data sets are in use. If you find that the number of offload data sets is close to 168, you should either increase the size of the offload data sets (LS_SIZE parameter) so that you don't need so many offload data sets, or format a new LOGR CDS with a larger DSEXTENT value, which will allow you to have more than 168 offload data sets.
Example 4-6 shows a sample job that will let you monitor the log stream offload data set usage. The output of this job reports information about the log streams and the logger structure itself. Among other information, it tells you exactly how many offload data sets are currently in use. It also provides structure information, such as what average buffer size was specified and what the effective buffer size really is. In this example, the System Logger will have changed the entry-to-element ratio.
Example 4-6: Sample job to list log stream information
//MIAPU JOB .... //STEP1 EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=* //SYSIN DD * DATA TYPE(LOGR) REPORT(NO) LIST LOGSTREAM NAME(MSGQ.LOG.STREAM) DETAIL(YES) LIST STRUCTURE NAME(MSGQ.LOGR.STRUCTURE) DETAIL(YES) /* ****************************** SAMPLE OUTPUT ******************************** LOGSTREAM NAME(MSGQ.LOG.STREAM) STRUCTNAME(MSGQ.LOGR.STRUCTURE) ..... .....<logr policy parameters for this log stream> .... .... <other detailed information about the log stream and offload data sets> .... NUMBER OF DATA SETS IN LOG STREAM: 43 STRUCTURE NAME(MSGQ.LOGR.STRUCTURE) LOGSNUM(1) MAXBUFSIZE(65272) AVGBUFSIZE(512) EFFECTIVE AVERAGE BUFFER SIZE(1024)
In the beginning, you should do this often enough to get an idea of how long it takes to fill an offload data set during peak processing periods. You can use this information to adjust the size of your offload data sets (LS_SIZE) and your structure checkpoint frequency.
| < Day Day Up > |
|