CA Deliver - Printed Output Cannot be Found
Article ID: 132062
Updated On:
Products
Deliver
View
Issue/Introduction
In a system that runs CA Deliver using pre-spool processing (RMOPARMS JOBCLSL and SYSCLSL), there was a situation where an operator had wrongly entered a $P command, without parameters, on the system.
The situation was reversed within an hour by issuing a $S comand.
There was no impact, except that it was noticed that a single client's remote line was not restarted on their end, so the node was effectively drained during batch processing.
The reports did generate and go into the CA-View database, but did not distribute as expected.
The output was in the ST queue, under the proper remote/DEST, but it never went to the output queue.
When the line was restarted, there was nothing to send.
Upon restart of the line, the reports were manually re-spooled from CA-View, and things processed as normal.
If the DEST does not exist, or is down, the normal behavior would be for Deliver to send the output to the output queue and not go anywhere.
Is this an expected result?
Why did the print never make it to the output queue?
The situation was reversed within an hour by issuing a $S comand.
There was no impact, except that it was noticed that a single client's remote line was not restarted on their end, so the node was effectively drained during batch processing.
The reports did generate and go into the CA-View database, but did not distribute as expected.
The output was in the ST queue, under the proper remote/DEST, but it never went to the output queue.
When the line was restarted, there was nothing to send.
Upon restart of the line, the reports were manually re-spooled from CA-View, and things processed as normal.
If the DEST does not exist, or is down, the normal behavior would be for Deliver to send the output to the output queue and not go anywhere.
Is this an expected result?
Why did the print never make it to the output queue?
Environment
CA Deliver - All Releases
Resolution
If CA Deliver is down, and it is to do pre-spool processing, then the work that was meant for it will go to the spool.
If there is post-spool processing, then the work will wait in the spool for RMOSTC to be started again.
If the reports that were generated went straight to CA View, via the SARSTC task, they will not be distributed, as they did not process through Deliver.
Correspondingly, the reports would be named per the Jobname of the executing job.
------------------------------------------------------------------------------------------------------------------------------
In this instance, the RMOSTC task remained active during the incident.
The client isolated the issue as some system automation that moved the print out of the output queue.
Though there was no explanation for reports being purged, the client discovered (via a $HASP... message) that the reports were changed to "/rerouted", rather than being deleted.
If there is post-spool processing, then the work will wait in the spool for RMOSTC to be started again.
If the reports that were generated went straight to CA View, via the SARSTC task, they will not be distributed, as they did not process through Deliver.
Correspondingly, the reports would be named per the Jobname of the executing job.
------------------------------------------------------------------------------------------------------------------------------
In this instance, the RMOSTC task remained active during the incident.
The client isolated the issue as some system automation that moved the print out of the output queue.
Though there was no explanation for reports being purged, the client discovered (via a $HASP... message) that the reports were changed to "/rerouted", rather than being deleted.
Feedback
Yes
No
Powered by
