illustration" /> When the archive log is written

 

When the archive log is written

The process of copying active logs to archive logs is called off-loading. The relation of off-loading to other logging events is shown schematically in Figure 11.

Figure 11. The off-loading process

active log. Next, there is a triggering event, then the offload process. Finally, the data is written to the archive log and recorded on BSDS." />

 

Triggering an off-load

The off-load of an active log to an archive log can be triggered by several events. For example:

The data set is truncated before the point of failure, and the record that was not written becomes the first record of the new data set. Off-load is triggered for the truncated data set as for a normal full log data set. If there are dual active logs, both copies are truncated so that the two copies remain synchronized.

Message CSQJ110E is issued when the last available active log is 5% full and at 5% increments thereafter, stating the percentage of the log's capacity that is in use. If all the active logs become full, WebSphere MQ stops processing, until off-loading occurs, and issues this message:

CSQJ111A +CSQ1 OUT OF SPACE IN ACTIVE LOG DATA SETS

 

The off-load process

When all the active logs become full, WebSphere MQ runs an off-load and halts processing until the off-load has been completed. If the off-load processing fails when the active logs are full, WebSphere MQ abends.

When an active log is ready to be off-loaded, a request is sent to the z/OS console operator to mount a tape or prepare a DASD unit. The value of the ARCWTOR logging option (discussed in the WebSphere MQ for z/OS System Setup Guide) determines whether the request is received. If you are using tape for off-loading, specify ARCWTOR=YES. If the value is YES, the request is preceded by a WTOR (message number CSQJ008E) telling the operator to prepare an archive log data set to be allocated.

The operator need not respond to this message immediately. However, delaying the response delays the off-load process. It does not affect WebSphere MQ performance unless the operator delays the response for so long that WebSphere MQ runs out of active logs.

The operator can respond by canceling the off-load. In this case, if the allocation is for the first copy of dual archive data sets, the off-load is merely delayed until the next active log data set becomes full. If the allocation is for the second copy, the archive process switches to single copy mode, but for this data set only.

 

Interruptions and errors while off-loading

A request to stop the queue manager does not take effect until off-loading has finished. If WebSphere MQ fails while off-loading is in progress, off-load begins again when the queue manager is restarted. Off-load handling of I/O errors on the logs is discussed in the WebSphere MQ for z/OS System Administration Guide.

 

Messages during off-load

Off-load messages are sent to the z/OS console by WebSphere MQ and the off-load process. We can use these messages to find the RBA ranges in the various log data sets. For an explanation of the off-load messages, see the WebSphere MQ for z/OS Messages and Codes manual.