S213 Abend Exit › F1-DSCB Not Found S213 Abend Exit (IFG0EX0A Exit)

F1-DSCB Not Found S213 Abend Exit (IFG0EX0A Exit)

The recommendation to not use this exit is:

• The methods that cause the exit to be invoked are not generally practical and they are not compatible within an SMS environment. These methods are:
  • Archiving data sets and not changing the volume indicator in the catalog to reflect that they are archived.
  • Coding the VOLSER in JCL to allocate to data sets that are already in existence.
• The S213 exit has the following significant limitations:
  • Only non-VSAM data sets can be auto-restored.
  • No pooling capabilities.
  • Restores cannot be invoked by ISPF.
  • Installation requires an IPL.
  • False invocation of this exit has been known to occur.

The Catalog Management hook (see the Two Auto Methods section) has the following advantages over this exit:

• VSAM and non-VSAM data sets can be auto-restored.
• Restored data sets are pooled by CA Disk, CA Allocate or DFSMS.
• Restores can be invoked by ISPF.
• Installation, removal, or both of the Catalog Management hook is accomplished dynamically with a started task.

The first exit that CA Disk supported was the F1-DSCB-not-found user exit in OPEN and EOV processing. The exit is also called the S213 abend exit. It is invoked during OPEN processing (non-VSAM) when the data set being opened is cataloged to a volume, but no F1-DSCB exists on that volume for that data set. It is also invoked by batch jobs when the volume of a data set is hard-coded in the JCL, but does not exist on the volume.

At this point, the exit is invoked as a last-ditch effort to save the job from a system 213 abend. If the data set is restored to the volume by the exit, it can signal OPEN to retry the DSCB search again; since it just restored the data set, there should be one out there! If it couldn't restore the data set, the job gets the S213 abend. The dummy exit that IBM supplies with the base MVS system merely sets the return code to tell OPEN to go ahead and abend. The exit name that gets called is IFG0EX0A.

Why two different methods? Because neither of them alone can initiate auto-restores at all times when they are needed. The IFG0EX0A exit does not get called for VSAM data sets, nor does it get invoked for TSO/ISPF functions-- the catalog management hook does, however. So why not implement just the catalog management support? If you only did that, you cannot automatically restore data sets in batch jobs that had the volume hard-coded in the JCL, or when OPEN is processing a data set that is cataloged to a real volume on which the data set doesn't reside (F1-DSCB missing!). Conceptually, think of the two methods as complementary functions. Whenever processing for a data set is going to occur, two primary questions must be answered:

• What volume does the data set reside on?
• What are its attributes on the volume?

To answer the first question, catalog management is invoked with a locate option, which asks where the data set is currently located. It searches its catalogs until it finds the entry for the data set. With this information, OPEN can allocate the volume and then perform an obtain for the F1-DSCB to get the data set attributes and extent information. By understanding the order of information retrieval, you understand how these methods work, and also why the catalog management hook allows more flexibility.

Assume in the above example that the data set is cataloged to a real volume instead of the CA Disk pseudo-volume. If the data set was being opened for processing, a catalog locate is issued to determine the location of the data set. Since the data set is cataloged to a real volume, the catalog management hook lets the locate pass through without any modifications. OPEN processing allocates the volume(s) for the data set. It issues an obtain for the F1-DSCB that describes that data set. If this obtain fails, the IFG0EX0A exit gets control to determine if it can restore the data set. If it can restore the data set at this point, however, it must go back to the volume to which it is cataloged. OPEN has already allocated the volume and is expecting the data set on that volume only. This is why the catalog management hook allows more flexibility--it intercepts the locate before OPEN allocates the volume(s). It can therefore put the data set back to any volume it wants, as long as it passes back the correct volume list to the requester of the locate.