4.3 CQS and System Logger operational considerations

 < Day Day Up > 



4.3 CQS and System Logger operational considerations

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.

4.3.1 Controlling the use of System Logger

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.

4.3.2 Defining log streams dynamically

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.

4.3.3 Displaying log stream information

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.

4.3.4 Monitoring for offload conditions

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

start example
 //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) 
end example

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 > 



Systems Programmer's Guide to--Z. OS System Logger
ASP.NET for Web Designers
ISBN: 738489433
EAN: 2147483647
Year: 2002
Pages: 99
Authors: Peter Ladka

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net