A System 522 (S522) timeout abend can occur if the operating system cancels a task because its CA Datacom call had to wait, with no CPU time, longer than z/OS permitted. Before Version 14.0, you could protect your tasks from S522 abends by having a subtask attached by the interface during the connection to MUF and then detached during the disconnect from MUF. That subtask used a STIMER macro to generate CPU usage that prevented the S522.
Note: If CA Datacom CICS Services was the caller, the STIMER subtask was never performed.
The STIMER subtask could cause occasional problems. For example, an A03 abend could occur if you tried to end a job that was executing while a CA Datacom User Requirements Table (URT) was still connected to a MUF. The correction to this problem was for the application to properly CLOSE all URTs that were opened.
In Version 14.0, the STIMERM macro provides another way to avoid S522 timeout abends. We recommend that you use STIMERM because it is more efficient than the subtask. The STIMERM macro is driven and stopped at the same points as a subtask would be attached and detached. However, STIMERM can have 16 different occurrences in each TCB, and can usually be done in the same TCB as the user application, instead of as a subtask. Because of the limit of 16, it is possible for you to have an application that is using, or expects to use, all 16, in which case the subtask method is still required to be an option.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|