RHDCUCFC ABEND S018 in CA Dispatch
search cancel

RHDCUCFC ABEND S018 in CA Dispatch


Article ID: 16699


Updated On:


Dispatch Output Mgmt


When attempting to log on to CA Dispatch a user receives a RHDCUCFC ABEND S018 error. 

What causes this error and how can they be avoided?




The most common cause for a user receiving a "RHDCUCFC ABEND S018" error is that the user did not "gracefully log off" of CA Dispatch (using either the BYE or LOGOFF commands) from a previous active logon. 


These errors are commonly received after a user TERMINATES their CA Dispatch session using exit methods such as PA1, PA2, ATTN or ESC. 


When a user terminates their CA Dispatch session this way, the IDMS resources that are associated to the users LTERM/PTERM do not get cleaned up. IDMS does not like this as the L TERM/P TERM is sort of left in a state of "limbo". So when the same user attempts to logon to CA Dispatch again after exiting this way, they may receive S018, U0100 and/or S010 abends. 


The S018 abend is documented in IDMS as: 


S018 Reason: Matching PTERM waiting for VARY IN. The signon physical terminal is in the process of being varied in service. Module: RHDCD0ZU Severity: 0 Published by Scroll Versions from space IDMSM and version . 


If these abends are being received, then the only way to get IDMS to clean up the resources that were associated to the users LTERM/PTERM would be to recycle the CA Dispatch started task. 


Our suggestion would be, after a recycle of the CA Dispatch started task, to have the problem user try logging on and see if they can get in after the recycle. If the user is able to successfully signon at that point, please inform them that in the future, they need to logoff of Dispatch using either the BYE or LOGOFF commands. 


If the user continues to receive the S018 even after the recycle, the problem "may" somehow be related to security, or possibly to the actual terminal they are trying to log on to CA Dispatch through. A customer would want to begin their investigation into the problem keeping these possible causes in mind. It might also be worth it for the customer to check the users actual TSO SESSION to see if his logon session contains any additional error messages or information.

Additional Information

SGL - 10/6/23 - Corrected broken link to ABNDS018