Running CA Disk HSMGENx jobs, during IBM DFSMShsm to CA Disk conversion, it can happen to get an abend SA03 in unknown module and the job abnormally terminates.
Article ID: 7384
Updated On:
Products
Issue/Introduction
In CA Disk 12.5 Installation Guide – Appendix G section we document the procedure to automatically convert from IBM DFSMShsm to CA Disk and in the target library CCUWJCL we provide sample jobs for this conversion.
Jobs HSMGEN1 and HSMGEN2 are part of this conversion as they manage the creation of the correct commands to promote the data movement from IBM DFSMShsm to CA Disk.
It can happen that they abnormally end with Abend Code SA03 and the conversion is stopped.
How to correct this situation, allowing the conversion to progress?
Environment
Cause
In most cases an sA03 abend is a symptom, not a specific problem itself.
It means that a task is trying to end and it has not properly detached or cleared all subtasks that it may have previously attached.
In our situation, this can happen for example when CA Disk is trying to end the subtasks started to execute the HSMGENx generated commands.
A task or subtask may have previously abended, and even though CA Disk recovered from the problem and continued processing, something was not cleaned up properly.
Resolution
One of the subtasks created during the HSMGENx execution by CA Disk is the one which manages the CA Datacom communication and activity requested to progress with the convert.
In order to bypass the abend it is necessary to add the option:
PREVENT_S522=YES_STIMERM
to the DBSIDPR macro defined and generated during the CA Disk installation, in the Ca Datacom Interface customization phase, and relink it, then refresh it in CA Datacom MUF.
In fact, as we detail in the CA Datacom DB Administrator Guide:
PREVENT_522
(Required.)(z/OS only) This required parameter exists to provide a choice of whether to allow or prevent z/OS S522 failures. This failure occurs if a CA Datacom request stays in the MUF longer than the Operating System limit for an Address Space waiting and doing no work. This is not a normal condition, but it can occur in special cases, for example if the LXX (Log Area) becomes full and is unable to spill in a timely manner.
There are two ways CA Datacom can prevent the S522 failure. The method in CA Datacom releases prior to Version 14.0 was to use a subtask named DBISBPR. This subtask used a z/OS STIMER to generate occasional low volume activity. This option is available by specifying PREVENT_S522=YES_SUBTASK.
An option is also now available that can be more efficient. To use it, specify PREVENT_S522=YES_STIMERM. This option uses no subtask but instead uses a STIMERM to generate occasional low volume activity in the same TCB that issues the OPEN which connects to the MUF.
Note: This option is overridden when used by an application using a URT assembled with the DBURSTR macro option PREVENT_S522 specified.
Valid Entries:
YES_STIMERM, YES_SUBTASK, NO
Default Value:
No Default.
If, after this suggestion, the abend occurs again, please open a Case with CA Support.
Feedback
