Another way to load data into tables is to use the DB2 Loader for sequential sources of data. See theDB2 UDB for OS390 SQL Reference manual for more information about the DB2 Loader.
To support the EXTRACT command, you must allocate data sets to each user of that command, and deallocate these data sets after the user ends the command.
The data sets can be in DXT libraries that are common to all users, or can be data sets created for the individual users enrolled in DXT.
The data sets are described in the Data Extract: Planning and Administration Guide for Dialogs manual. If you are enrolling DXT dialog users, you need that document. If you are not, all you need to know about the process is included in the following discussion.
QMF can support English, Kanji, and Uppercase (UCF) DXT dialogs. Each requires different DXT data sets, all of which can be allocated with ISPF LIBDEF statements (see Allocating and deallocating resources using CLISTs for more information about using LIBDEF).
If you choose some other method of allocation, you can skip the following topics on modifying the CLISTs. The unmodified CLISTs will not interfere with the method you choose.
Table 62 shows the data sets required for several DXT Version 2 Release 5 dialogs. The table identifies the data sets and their associated ddnames. For any given ddname, the data sets in the table are in addition to any data sets that were already allocated for that ddname.
The names shown in the table are the default names provided by DXT. Your installation might be using different names for these data sets.
In the table, each n is the language key. For DXT dialogs, the language keys are E (English), K (Kanji), and U (uppercase English).
Note: If you are not familiar with the ISPF LIBDEF statement, see the ISPF V2 MVS Dialog Management Services manual before reading further.
To allocate the needed data sets, you can either add JCL to your users' TSO logon procedures, or use two IBM-furnished CLISTs.
QMF calls one of these CLISTs just before issuing an EXTRACT command, and the other just after the command executes. With appropriate modifications, the first CLIST can allocate the added resources; the second can deallocate them. DSQABX1L is a sample CLIST that you can use to do the necessary allocation. This method is superior to adding JCL to your users' TSO logon procedures because it ensures that the DXT data sets are allocated only when they can be used.
This CLIST is the member, DSQABX1L, of the library QMF720.SDSQCLTE. QMF calls this CLIST through the ISPF SELECT service whenever a user issues the EXTRACT command. The following modifications on DSQABX1L might be necessary before it can allocate:
The original PROC statement is: PROC 0 DXTPRE(DXT250) LKEY(E) OBJSHR(NO)
Because QMF does not pass parameters to the CLIST, you must ensure that the values for the following three keyword parameters are correct:
This is the statement EXIT CODE(0), the last statement in the CLIST. It ensures that the CLIST does nothing if you are not supporting the EXTRACT command or are making the allocations in some other manner.
Refer to the sample DSQABX1L CLIST in the 'QMF720.SDSQCLTE' sample library to see how the CLIST generates the data set names for its LIBDEF statements. These data set names are the defaults for DXT V2R5 dialogs. Modify the code, if necessary, to produce the names used at your installation, but do not modify the logic or the return codes for failed allocations.
The sample CLIST is the member DSQABX1F of the library QMF720.SDSQCLTE. QMF calls this CLIST through the ISPF SELECT service after the EXTRACT command runs. The following modifications of DSQABX1F might be necessary before it can deallocate:
The original PROC statement is:
PROC 0 QMFPRE(QMF720) LKEY(E) OBJSHR(NO)
Because QMF does not pass parameters to the CLIST, be sure that the values for the following three keyword parameters are correct:
This is the statement EXIT CODE(0). It ensures that the CLIST does nothing if you either aren't supporting the EXTRACT command or are making the allocations in some other manner.
The third statement after the comments in the prolog is the branching statement GOTO A. Following this statement are two blocks of code: section A and section B. Both blocks deallocate the DXT data sets, but do so in different ways. If you choose section B to do the deallocation, you must change the branching statement to GOTO B.
Section A nullifies every LIBDEF statement that the allocation CLIST issued. This deallocates the DXT data sets, but it might also deallocate data sets that the user needs after the EXTRACT command ends. Such data sets were allocated with LIBDEF statements before the user issued the EXTRACT command. If the user needs data sets that were allocated with LIBDEF statements issued before the EXTRACT command, then change the branching statement so that section B is invoked.
For a data set to fit this description, a LIBDEF statement for its ddname must appear in this CLIST and in its allocating companion. For example, the following LIBDEF statement adds a panel library, ABC.XYZ, to the libraries already allocated to the ddname ISPPLIB:
ISPEXEC LIBDEF ISPPLIB DATASET(ABC.XYZ)
In the allocation CLIST, this allocation disappears when the CLIST runs its LIBDEF statement for ISPPLIB. To restore it, you need to reissue the original LIBDEF statement in the deallocating CLIST. If this is the only allocation to restore, you might still use section A, just change the LIBDEF statement for ISPPLIB in that section.
The LIBDEF statements in section B reallocate QMF libraries to the ISPF ddnames. Change these statements to whatever is needed if you choose to use section B.
LIBDEF statements cannot deallocate data sets that were allocated through the TSO logon procedure or through TSO ALLOCATE statements. Therefore, you can always use section A if all the data sets needed for a QMF session are allocated in that way.