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:
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:
(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.
YES_STIMERM, YES_SUBTASK, NO
If, after this suggestion, the abend occurs again, please open a Case with CA Support.