Using the new log processing parameter for Workload Simulator for z/OS and OS/390

Answer

This update details the current issue with Workload Simulator Log processing and how this change to the log processing parameter improves it. Also provided are matters to be considered when using this new parameter with regard to log file size, blocking and test run performance.

The issue:
Currently when Workload Simulator for z/OS and OS/390 records to a log dataset the details of what actions are being carried out by the test run, Workload Simulator for z/OS and OS/390 first writes to a buffer in memory and then reads that buffer in order to write it out to the actual log dataset. The issue occurs when the amount being written out is larger than the capacity of the buffer to handle. When this overflow situation occurs, Workload Simulator for z/OS and OS/390 issues an ITP030I message and suspends writing to the log until the log buffer is cleared by the read process.

The typical way to deal with this is to accept the situation because the test performance is more important than logging all the data. Alternatively, you can increase the blocksize of the log data set to allow more data to be stored, or increase the value defined in the NCP parameter to increase the number of blocks allocated in memory. Doing this, however, usually requires several runs to find the optimum combination of blocksize and NCP value.

The solution:
To overcome this issue, a new parameter was created called INCRLOG. The values for this parameter determine how much the log buffer is increased and how often the increase can be done.

There are 3 values for this parameter, as shown in the table below:

• Ensure the region size you use is adequate for the task that has been set. If you run jobs with a small region size, there might not be enough space available to increase the buffer. This causes a Getmain error and the ITP030I messages are displayed.
• Each time the log buffer size is increased, it takes time to build the addition and link it to the existing buffer. This can slow down the performance of the testing as each block or set of blocks is added to the buffer.
• The DBLn and AUTO values both have advantages and disadvantages that should be kept in mind when determining which value to use. DBLn has less potential impact on performance because it adds a group of blocks to the existing buffer. However, it might allocate more space than is needed, affecting the amount of available memory. The AUTO value might impact performance because it allocates one additional block at a time, so it might be called multiple times if a large amount of data is being logged. However, memory usage is more efficient with the AUTO value because only one block is added at a time and is therefore more closely aligned to the buffering needs.
• The log dataset itself should also be considered before using this new parameter. Since it is possible that all of the data generated for the log will be captured, this could lead to a log dataset larger than expected. You should consider carefully what data you need to obtain in the log dataset and make certain the log dataset size is appropriate for that volume of information.