TAPEDATASETORDER: Specifying order for processing tape

Explanation: TAPEDATASETORDER is an optional parameter that specifies the order in which you want DFSMShsm to recall or recover data sets from a single tape.

PRIORITY | FBID are mutually exclusive sub-parameters of the TAPEDATASETORDER parameter. If you specify TAPEDATASETORDER, you must also specify either PRIORITY or FBID, otherwise DFSMShsm does not make any change to the TAPEDATASETORDER state and issues an error message.

Subparameter	Explanation
PRIORITY	DFSMShsm processes data sets in the priority order. Data sets within the same priority are processed in the FIFO order.
FBID	DFSMShsm processes the data sets in the ascending file block id order.

If you specify TAPEDATASETORDER(PRIORITY | FBID) parameter, the parameter applies to both recall and recover processing. If you specify a specific functional parameter, TAPEDATASETORDER applies only to that function. If you specify a general option and a specific function in a single command, the command fails. If you specify the RECALL(PRIORITY | FBID) parameter, the parameter applies to recall processing only. If you specify the RECOVER(PRIORITY | FBID) parameter, the parameter applies to recover processing only.

SETSYS default: None.

DFSMShsm default: If you do not enter the TAPEDATASETORDER command, the DFSMShsm default is PRIORITY. DFSMShsm recalls and recovers data sets from a single tape in priority order. Recall requests with the same priority are processed in FIFO order.

Note:

The TAPEDATASETORDER command provides the installation with additional flexibility to handle circumstances in which ascending FBID order offers a significant reduction in tape repositioning, such as when a large number of data sets are being recalled or recovered from a single tape. Specifying FBID might increase throughput, but might cause lower priority requests to be processed prior to a higher priority requests.
If a host connected to the Common Recall Queue issues the SETSYS command to change the TAPEDATASETORDER, all hosts connected to the Common Recall Queue adopt the same processing order.
If you enter the SETSYS command to change the TAPEDATASETORDER while there are requests residing in the Common Recall Queue, it might take some time before the new processing order takes effect.
If you enter the ALTERPRI command to re-prioritize requests residing on the Recall or Recover Queue to HIGH, ALTERPRI takes precedence over FBID.