Replicating spooled files

Asynchronous replication of spooled files

Since spooled files do not change after they are created, there is no reason to wait for the spooled file to be created on the target node before returning control to the program or user. Therefore, spooled file replication is implemented using an asynchronous method, which runs in a server job QSPMRSYNC.

The QSPMRSYNC job waits for spooled file requests so that it can combine multiple requests into a single replication operation. This reduces the overhead on your system.

Changing the interval for asynchronous updates

The replication of spooled files is processed on an interval basis. This interval can be customized by using the Db2 Mirror GUI or by using the QSYS2.CHANGE_MIRROR SQL procedure. Once the spooled file is closed, it will be replicated at the next interval.

To configure the spooled file processing interval from the Db2 Mirror GUI, on the main dashboard click Manage the selected Db2 Mirror pair. For each node, right click on the node and select Properties, then set the Wait time for spooled file replication to a value from 2-3600 seconds.

Replication of spooled files during blocked state

Spooled file operations are allowed on both the source and the target node at all times. You may continue to create, delete, and move spooled files during active, tracking, and blocked replication states.

Active/passive replication of spooled files

The primary reason for replicating spooled files is so that there is a backup copy readily accessible if one node becomes unavailable. While it is possible to work with spooled files on the same replicated output queue from both nodes at the same time (active/active), it is better to only process them from one node and use the replicated queue on the target node as a backup (active/passive) to prevent the same spooled file from being processed on both nodes at the same time. This processing could cause duplicate output to be produced, or spooled file error entries to be added to the Object Tracking List (OTL).

Replication of existing spooled files when adding a new rule to the RCL

When adding a new rule to the RCL to include a library and its contents, if the library contains an output queue with spooled files, both the output queue and its existing spooled files will be replicated to the target.

However, when adding a rule to the RCL to replicate an output queue, only new spooled files that are created after the rule has been added will be replicated. Spooled files that already exist on the output queue (on either node) are not synchronized at the time the rule is added. If you want the spooled files to be identical on both nodes, you must delete the output queue on the target, if one exists, add the output queue rule, then save all the spooled files from the source node and restore them on the target node.

Finding replicated spooled files

When a spooled file is replicated to the target, it is detached from the job that created it on the source node since the source job does not exist on the target.

To locate replicated spooled files on the target node, use the Work with Spooled Files (WRKSPLF) command and specify the job name (JOB) or use the Work with Output Queues (WRKOUTQ) command. Work Job (WRKJOB), Work User Job (WRKUSRJOB), and Work Subsystem Job (WRKSBSJOB) can only be used to locate spooled files on the node where they were created (assuming they have not been detached (SPLFACN(*KEEP)).

Moving spooled files from one output queue to another

There are special considerations for moving spooled files from one output queue to another. It is important to understand if one or both output queues are replicated, and if only one is replicated, whether it is the source or the target of the move.

Replicated to replicated

If you move a spooled file from a replicated output queue to another replicated output queue, the spooled file will also be moved on the target node.

Replicated to non-replicated

If you move a spooled file from a replicated output queue to a non-replicated output queue, the spooled file will be deleted from the replicated output queue on the target node.

Non-replicated to replicated

If you move a spooled file from a non-replicated output queue to a replicated output queue, the spooled file is moved to the new output queue on the source node and then the spooled file will be restored into the replicated output queue on the target node. If the spooled file already exists on the target node (for example, because it was on an output queue that was cloned to the target, or because the non-replicated output queue was replicated at one time), the restore operation will fail on the target node.

Restoring replicated output queues

When restoring a replicated output queue, the output queue along with the spooled files (if saved with SPLFDTA(*ALL)) will be restored on both the source and target nodes. The spooled files may not be available immediately on the target node after a restore because of the asynchronous processing.

The spooled files status will be HLD (Held) after being restored on the target node (unless the status was SAV at the time of the save operation, in which case the status will remain as SAV).

Troubleshooting replication of spooled files

If at any time you do not find a spooled file on the target node as expected, check the Object Tracking List for possible errors during the replication process, or outstanding requests that have not yet been processed.

The QSPMRSYNC job processes spooled file replication requests asynchronously. This job runs in the background and does not report errors back to the job that performed the spooled file operation. This job must be active in order for spooled file requests to be replicated. Check the joblog for QSPMRSYNC for any possible errors while replicating spooled files. If the spooled file is created in an IASP, this processing is done in a job named QSPMR000nn, where nn is the number that corresponds to the IASP.

If there are no errors, check the value for Wait time for spooled file replication in the Db2 Mirror GUI or by using the QSYS2.MIRROR_INFO view. The defined interval can be up to an hour.