Did your recall of archived datasets start working differently after applying maintenance?

Body

After you apply maintenance, processes that encounter recall of archived datasets no longer wait for the recall to complete. Has something changed to cause this to occur?

Prior to V4.7, Connect:Direct for z/OS handled archived datasets by checking if ARCH was coded in the ALLOC.CODES initialization parameter; if so, the process was to be requeued and retried. This also meant that the ARCH code and/or message ID SDEARCHI needed to be coded in the initialization parameters for the remote to requeue and retry the process properly. 　

After V4.7, it was determined at some point that the code doing the requeue was removed (or even ignored), and the result was that, if ARCH was coded in the ALLOC.CODES initialization parameter, the z/OS SNODE would simply wait for the recall to complete. PTF UI30080 (APAR PI45602) was generated to perform the requeue correctly when encountering a recall of an archived dataset.　

However, some customers had gotten used to it not working properly and coded their processes accordingly, and this caused problems for them.

It was decided that the easiest way to handle this was to create a new initialization parameter.

PTF UI39217 (APAR PI64815) allows you to determine how you want the recall of an archived dataset to be handled in the installation. PTF UI38217 is a Small Programming Enhancement (SPE) that introduces a new initialization parameter SNODE.ARCH.RECALL.WAIT.　

Overview
A Process that allocates a migrated dataset will either:　

1. WAIT for the dataset to be recalled.　

2. Terminate with an SDEARCHI RC=08.
　

The action taken depends on whether ARCH is coded in ALLOC.CODES. If ARCH is not coded then the Process will WAIT for the RECALL to complete. If ARCH is coded then the Process will terminate with the SDEARCHI RC=08. The behavior is the same regardless if the DTF is PNODE or SNODE.　

With this new initialization parameter, the RECALL behavior is controlled based on the setting when the z/OS DTF is the SNODE.　

Syntax

SNODE.ARCH.RECALL.WAIT = YES | NO　

SNODE.ARCH.RECALL.WAIT=YES (Process waits for the RECALL to be completed)　

SNODE.ARCH.RECALL.WAIT=NO (Process terminates with SDEARCHI RC=08) 　

If the recall is allowed to function as designed, the remote trading partners will need to add the message ID or code to initialization parameters

For Connect:Direct for z/OS, you add the code to the initialization parameters:

    ALLOC.CODES = (020C 0210 0218 0220 0234 0068 -
          0069 006A TAPR DSNR 04E5 ARCH)
　

For Connect:Direct for Microsoft Windows, you add the message id or code to the initialization parameters:

    retry.msgids=SDEARCHI
    retry.codes=ARCH
　

For Connect:Direct for UNIX, you add the message id or code to the initialization parameters:

    copy.parms:\
    :retry.codes=0x020C,0x0210,0x0218,0x0220,0x0234,0x0484,DSNR,GDGR,TAPR,PDSR,ARCH:\
    :retry.msgids=SDEDSNRI,SDEARCHI,SDEGDGRI,SDE0210I,SDE0410I:\

For Connect:Direct for HP NonStop, you add the following to the adjacent node definition for the remote node:

    ALLOC.RETRY.ADJ=(SDE0210I SDEDSNRI SDEARCHI)