Determining the QUEUE64 size

The operand of the QUEUE64 (abbreviated Q64) parameter of the OPTIONS parameter statement (see Parameter file statements) controls the size of the queue that BMC AMI Defender uses to buffer records between the IEFUxx exits, the API, and the communication code. For more information, see BMC AMI Defender API. There is a single QUEUE64 operand size that defaults to 12. Size specifies the size of the area to hold SMF records that are accepted from the IEFUxx exits or the API but not yet processed by the communication code. The size is specified in mebibytes (2²⁰ or 1,048,576 bytes, often incorrectly referred to as megabytes). The queue is pageable and located in the 64-bit common address space, before the 4GB-bar.

SMF record type numbers that BMC AMI Defender does not process (1, 2, 3, …) are not placed in the queue, nor are records that are suppressed (not reformatted as syslog messages and forwarded), neither those that are suppressed under all circumstances, such as SMF Type 42 record subtypes 1 and 2, nor those that you have suppressed explicitly with parameter file values.

On the other hand, FILTER (see Filtering in and filtering out events) had no direct effect on queue utilization, filtered events are still queued before filtering. However, FILTER generally has a positive effect on performance and therefore on queue utilization.

It is necessary to queue records because records can arrive from the SMF exits more rapidly (hundreds per millisecond) than they can be formatted and forwarded (about four to sixty per millisecond). Obviously BMC AMI Defender cannot indefinitely sustain records arriving faster than they can be processed any more than you can continually spend more money than you earn, but the queue is like a credit card that can get you through short-term periods in which spending exceeds income. You might say that the QUEUE64 parameter controls your credit limit.

Since you can set your own credit limit with QUEUE64 then why not set it to the maximum value, QUEUE(1048576). Why did BMC Defender not just set QUEUE64 to that value internally rather than making you choose a value? The answer is that would be an excessive and probably unavailable amount of 64-bit common storage. 64-bit common storage is described in the IBM publication z/OS MVS Initialization and Tuning Reference, primarily in the description of the HVCOMMON statement of the IEASYSxx member.

The following paragraphs make frequent mention of BMC AMI Defender counters. These counters are displayed in CZAPRINT message CZA0215I and on your syslog console at BMC AMI Defender termination, as scheduled with OPTIONS STATS() and every midnight (z/OS local time). You can produce a counter display at any time with a console command. For more information, see MODIFY command. The counters are documented in Counters.

So your choice of QUEUE64 size is a trade-off between the size of the BMC AMI Defender queue (credit limit) and 64-bit common usage. BMC recommends that you start with the supplied default values QUEUE64(1024) and adjust as indicated by your experience. The following are guidelines for choosing an optimal queue size:

If BMC AMI Defender attempts to select an SMF record and finds that no queue area is available, it purges (deletes and discards) a number of the oldest records in the queue to make room for the new record and reports it by incrementing a counter (Queue events purged). If you are seeing non-zero value for this counter then you should consider increasing the QUEUE64 size. You should also consider the counter Swapped with work. An excessive value might indicate that the ability of BMC AMI Defender to format and transmit syslog messages in a timely manner is being impacted by z/OS swapping policy, and you might want to consider making BMC AMI Defender non-swappable with OPTIONS SWAPpable(No), or making configuration changes to your z/OS Workload Manager parameters. z/OS swapping and the Workload Manager are discussed in the IBM documentation. Swapping might significantly delay the ability of BMC AMI Defender to format and transmit messages, and hence cause unformatted SMF records to build up and overflow the queue.

BMC AMI Defender records the maximum number of bytes queued at any one time in the counter identified as Queued max bytes. If this counter is always considerably less than the queue size, then you might consider reducing the size of the queue.

If BMC AMI Defender fails on startup with CZA0224C Error nnn (X'xxxxxxxx') during queue allocation or deallocation (CSAALOQ) and CZA0340I IARV64 reason code explanation: Insufficient free space to satisfy request or your diagnostic tools are reporting storage constraints in 64-bit common then you should code a smaller size. You might need to move BMC AMI Defender started task to a more favored z/OS Workload Manager Service class, make BMC AMI Defender non-swappable or reduce the types of SMF records you are formatting. You might want to work with BMC Support to determine an optimal strategy.