The Cobwebb Server software uses Data Queues to pass information between programs as well as behind the Output Queues for the Spooled File Monitors to work efficiently. If the IBM i has an abnormal failure e.g. a power failure, or uncontrolled shut down, the data queues are the first objects to be damaged.

You may see messages appear in the joblog such as “WRITESTRFA damaged object”. If you check further up the joblog you should see the name of the actual Data Queue that is damaged.

We have tried to make recovery from these issues as simple as possible and simply ending the Cobwebb Subsystem, deleting the damaged Data Queue(s) and restarting the Cobwebb Subsystem will rebuild them.

If the STREML or STRFAX Data Queues are damaged then you may also want to check to see if any messages have been left in an “Active” state on the Cobwebb Queue. If they have then, after ending the Cobwebb Subsystem and deleting the Data Queue go to the Recovery Menu and select either:

•Option 1 - Check active faxes

•Option 3 - Check active emails

Note: Options 2, 4 and 5 on the Recovery Menu are no longer required as these are now built into the Cobwebb Subsystem start program.

The following Data Queues can exist in library CPPD and are created when the Cobwebb Server subsystem starts. The characters in brackets refer to the Max Length & Max Size for the Data Queue.

The default SPLMON Data Queue and any other Data Queue created via the Work with Spooled File Monitor should exist in library QUSRSYS. These are created when the Cobwebb Server subsystem starts. The characters in brackets refer to the Max Length & Max Size for the Data Queue. Note: If you do need to delete a SPLMON Data Queue then you may have to re-release the spooled file that was being processed at the time.