Allocating ISPF data sets
- DDname
- Data set name
- IDIIPKOR
- IDI.SIDIPKOR
- IDIIMKOR
- IDI.SIDIMKOR
- IDIISKOR
- IDI.SIDISKOR
- IDIITKOR
- IDI.SIDITKOR
Typically, data sets for an ISPF application are allocated in either the TSO logon procedure, a program or an EXEC run prior to invoking ISPF, or dynamically (for example, in an EXEC) prior to invoking the application using the ISPF LIBDEF service.
When Fault Analyzer is invoked using the Language(KOR) option, then Fault Analyzer uses the ISPF LIBDEF service to logically place the data sets that are allocated to the IDIIPKOR, IDIIMKOR, IDIISKOR, and IDIITKOR DDnames ahead of the data sets that are allocated to the ISPPLIB, ISPMLIB, ISPSLIB, and ISPTLIB DDnames. The stacking feature of the LIBDEF service is used to ensure that any data sets defined using LIBDEF prior to invoking Fault Analyzer are restored on exit.
If a LIBDEF for either ISPPLIB, ISPMLIB, ISPSLIB, or ISPTLIB is already active at the time of invoking Fault Analyzer, then the existing LIBDEF data sets are included in the new LIBDEF, after the IDIIPKOR, IDIIMKOR, IDIISKOR, or IDIITKOR data sets. Because the maximum number of data sets that can be specified with LIBDEF when using the DATASET option is limited to 15, any data sets in excess of 14 that is already specified using LIBDEF, are not available. (This arithmetic assumes that only one data set is specified for the IDIIPKOR, IDIIMKOR, IDIISKOR, and IDIITKOR DDname, as is normally the case.) Therefore, it is important that any Fault Analyzer base function ISPF data sets that are specified using LIBDEF at the time of invoking Fault Analyzer are among those that are included in the Fault Analyzer established LIBDEF, otherwise ISPF failures might result due to untranslated members not being found.