Preventing interactive TSO users from being placed in a wait state during a data set recall

When an interactive-time-share (TSO) user refers to a migrated data set, DFSMShsm recalls the data set to the user’s level-0 volume. During the data-set recall, the user is put into a wait state. To allow the recall to continue and yet return to an interactive session, the user can press the attention key.

After the user "attentions out" of the recall, the screen is left with meaningless data. To clear the screen of meaningless data and to return to the user’s TSO session, it is necessary to press the PA2 key.

Many users do not know that pressing the PA2 key clears the screen of meaningless data. A site can eliminate the need for users to know about the PA2 key by issuing the following PATCH command. Issue the following PATCH command to change the default for wait states to a default of no wait. When the PATCH command is in effect, DFSMShsm schedules the recall, and issues message ARCI020I to let the user know that the data set is being recalled and that the data set may be accessed after the recall completes. If the data set recall is generated as a result of accessing the data set through a TSO panel, ARCI020I is followed by another message indicating that the locate failed.

PATCH  .MCVT.+52 bits(..1.....)  /* Alter the default for tape    */
                                 /* data set recalls from a wait  */
                                 /* state to a no-wait state      */
 
 
 
 PATCH  .MCVT.+52 bits(...1....)  /* Alter the default for DASD    */
                                  /* data set recalls from a wait  */
                                  /* state to a no-wait state      */

If you want the no-wait default to be effective at startup, ensure that you include the previous PATCH command in the startup procedure. If the PATCH commands are entered after DFSMShsm startup, they are not effective for the first recall.

After a recall is generated because of the UNCATALOG function from TSO option 3.2, a second recall is automatically generated by option 3.2 after the first recall is intercepted by DFSMShsm. The second recall is not processed until after the first recall has completed. Consequently, the second recall fails because the data set has already been recalled.