Supporting the EXTRACT command on VM

To support the EXTRACT command, you must make files available to the users of that command, and reallocate these files after a user ends the command.

These files do not appear in the QMF Invocation exec that is described in Installing and Managing QMF on OS/390. The file types can be in DXT libraries that are common to all users, or can be files created for the individual users when the users are enrolled in DXT.

The data files 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.

Allocating resources on VM

Table 63 shows the files required for any variety of Version 2.3 dialogs. The figure identifies the files and their associated FILEDEFs. For any given FILEDEF, the files in the table are in addition to any files that were allocated for that FILEDEF. The names shown in this table are the default names provided by DXT. Your installation might be using different names for these files. In the table, each lowercase letter n is the language key. For DXT dialogs, the language keys are E (English), K (Kanji) and U (Uppercase).

Example: For DXT dialogs in which the language key is E, the file name and file type to be added to ISPMLIB is named DVRMLIBE MACLIB.

Allocating and reallocating resources using execs

There are two IBM-supplied execs that QMF calls. One is called just before the execution of an EXTRACT command, and the other just after execution ends. After modifying the execs, the first can allocate added resources, and the second can reallocate them.

DSQABX2L is a sample exec that you can use to do the necessary allocations. It has the following advantages over adding exec statements to your users' CMS invocation exec:

• It can apply to every user of the EXTRACT command.
• It does the allocations ONLY when a user issues an EXTRACT command.

Preparing the allocation exec

This exec is named DSQABX2L and is located on QMF's production disk. Whenever a user executes the EXTRACT command, QMF calls this exec through the ISPF SELECT service. The call passes the exec no parameters- a fact that is used when we consider possible exec modifications.

Before the exec can do its allocations, you must modify it. The following list describes some modifications that might or might not be necessary, and one modification that is mandatory:

1. Remove the first executable statement.

   This is the statement EXIT 0. It ensures that the exec does nothing if you are not supporting the EXTRACT command or are making the allocations in some other manner.

2. Set the language key.

   The first thing the exec does is to set the DXT language key variable (LKEY), to E for English. If your DXT product is not the English version, you must set the language key to the proper DXT value.

3. Set the object sharing variable.

   If you have taken advantage of the DXT dialogs object sharing capability, you need to set the variable OBJSHR to a value of YES. By doing this you allocate the shared variable DVRTLIB located on the DXT production disk. If you are not using object sharing, set the variable OBJSHR to a value of NO. Values for this variable can either be YES or NO.

4. Update the disk linkage.

   After setting LKEY and OBJSHR, the next thing that the exec does is to link to and access the DXT production disk. You might have to alter any or all of the following to fit your DXT installation:

   • DXT production disk owner ID
   • DXT production disk address
   • DXT production disk READ password
   • The QMF user's disk access address for the DXT disk
   • The QMF user's disk access mode for the DXT disk
5. Modify the code as necessary.

   Refer to the sample DSQABX2L exec on the QMF production disk to see how the exec generates the file names for its LIBDEF statements. These file names are the defaults. Modify the code, if necessary, to produce the names that are used at your installation, but do not modify the logic or return codes for failed allocations.

Preparing the reallocation exec

The DSQABX2F exec is located on the QMF production disk. QMF calls it through the ISPF SELECT service, right after the execution of the EXTRACT command. It is called to reallocate QMF libraries if the ISPF LIBDEF function was used to allocate DXT libraries. The call passes the exec no parameters, just as the call to the allocating exec passes that exec no parameters.

Before the exec can work properly for your users, you might need to modify it. If you allocated all your DXT libraries before you started QMF or ISPF, you should not modify this exec. It then exits without performing any library reallocation.

If you allocated QMF libraries using the ISPF LIBDEF function, you must execute this exec to reallocate the QMF libraries because they were replaced by DXT library definitions when the exec DSQABX2L was executed.

Possible modifications to the exec are:

• Remove the first executable statement.

  This is the statement EXIT 0. It ensures that the exec does nothing if you are not supporting the EXTRACT command or are making the allocations in some other manner.

• If necessary, change the DXT disk address.

  The first thing the exec does is to release the DXT production disk. You need to modify the statement USER_ADDRESS = '291' depending on the changes you made when updating the disk linkage to DXT when executing the exec DSQABX2L.

Other allocation methods

Previously, we recommended that you use the exec for the DXT allocations and mentioned certain advantages for doing this. If you elect to use some other method of allocation, do not modify the exec. The unmodified exec will not interfere with your alternate method of allocation.