z/OS DFSMS Installation Exits
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


ARCRPEXT: Return-Priority Installation Exit

z/OS DFSMS Installation Exits
SC23-6850-01

The return-priority exit (ARCRPEXT) is taken as each delete, recall, or recover request [in the form of a management work element (MWE)] is about to be queued on one of DFSMShsm's functional subtask queues for processing. Also, this exit can be used to prevent this processing. For a recall request, this exit is invoked by the host initiating the recall.

You can use the return-priority exit in the following ways:
  • To set a priority (ranging from 0 to 100, where 100 is highest priority) for each request for which the user is waiting for results (WAIT type).
  • To set a priority (ranging from 0 to 100) for each request for which the user is not waiting for results (NOWAIT type).

    DFSMShsm “primes” the priority field with either a default priority of 50 or the priority (for a data set recover request that is initiated from a volume recover request) that was assigned earlier to the initiating volume recover request. DFSMShsm then queues the nonpurged requests for work in priority order. A priority less than 0 is treated as 0; a priority greater than 100 is treated as 100. DFSMShsm queues two requests of the same type with the same priority in FIFO (first-in, first-out) order.

    For recall and delete requests, “priority order” on the recall queue means:
    • WAIT requests are queued before NOWAIT requests
    • Priorities of WAIT requests are relative to other WAIT requests
    • Priorities of NOWAIT requests are relative to other NOWAIT requests after WAIT requests:
      • NOWAIT requests (if any) with a relative priority of 50 are interleaved by the user ID of the submitter with other NOWAIT requests of priority 50
      • NOWAIT requests with a relative priority greater than 50 are queued before those with a priority of 50, without interleaving
      • NOWAIT requests with a relative priority less than 50 are queued after those with a priority of 50, without interleaving
    You can assign priority values other than 50 for those NOWAIT requests that you do not want interleaved by user ID.
    Note: Interleave means that the new MWE is placed on the queue so that if it is the nth request on the queue from that user ID, it follows all nth requests for any other user IDs, but precedes all n+1 requests from any other user IDs. All nth requests are put on the queue in FIFO order.
    For data set recover requests, “priority order” on the data set recover queue means:
    • WAIT requests are queued before NOWAIT requests
    • Priorities of WAIT requests are relative to other WAIT requests
    • Priorities of NOWAIT requests are relative to other NOWAIT requests, after WAIT requests
    For volume recover requests, “priority order” on the volume recover queue means:
    • WAIT requests are queued before NOWAIT requests
    • Priorities of WAIT requests are relative to other WAIT requests
    • Priorities of NOWAIT requests are relative to other NOWAIT requests, after WAIT requests.
  • Start of changeTo manage the EATTR parameter of the recalled data set. If the return code is set to RC4, the data set will be recalled with EATTR=OPT parameter. This does not guarantee that allocation will go to the extended addressing space (EAS) of an extended address volume (EAV), but having the EATTR=OPT does allow the data set to be EAS eligible. End of change
  • To direct DFSMShsm to enable extent-reduction recalls to a volume other than the original volume.
    • When MWEFEXT is set to 1, the recall is for extent reduction. Then you can use ARCRPEXT to set a bit in the output data structure. This bit indicates that the recall of the data set is permitted to select a level 0 volume other than the volume from which the data set has migrated.
    • When the data set is SMS managed, DFSMShsm uses the ACS routines for volume selection. For non-SMS managed data sets, DFSMShsm uses standard non-SMS volume selection.
  • To purge a request. Note: there might be negative consequences from purging the recall requests. In some cases this can cause failures in applications or JCL that expect the data set to be recalled in order to complete an allocation request. Do not purge the request unless you fully understand how purging the recall request will affect the issuer of the request.
  • To construct messages for a DFSMShsm activity log concerning the request.

The method of installing the exit means that you can activate and deactivate it dynamically. If the exit is not currently active or if it encounters an abend, DFSMShsm assigns a default priority of 50 to each recall, delete, and recover request being queued.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014