Appendix F. The GDDM Object Import/Export utility (IMS)

GDDM V3R2 System Customization and Administration

Appendix F. The GDDM Object Import/Export utility (IMS)

GDDM V3R2 System Customization and Administration
SC33-0871-02

The purpose of the GDDM Object Import/Export Utility is to enable objects to be transferred between (1) GDDM applications running on one IMS system, and (2) those running on either another IMS system, or in a totally different environment (for example, a TSO development system).

Note: ADMSAVE objects produced under IMS can be used only under IMS. Other GDDM objects are, however, transferable between IMS and other systems.

The utility runs either as an IMS type-3 Batch Processing Program (BPP), or as a type-2 Batch Message Processing Program (BMP). It uses two instances of GDDM: one, reached by means of the stub that is link-edited with it, operates in an IMS environment; the other, which is dynamically loaded, provides the environment-dependent code normally used in an MVS environment, which is used to access the partitioned data sets (PDSs).

The program specification block (PSB) for the utility must specify CMPAT=YES, so that there will always be an I/O program communication block (PCB), even when the utility is being executed as a BPP. The same PSB can be used for BPP and BMP execution -- the database PCB will always be the second one.

The PSBs required for this transaction are described in the GDDM/MVS Program Directory.

When run as a BPP, the utility can be used, with a suitable PSB, to perform the initial database load, although the input must be in alphabetical order of object name and type. If this is inconvenient, the initial load run can just refer to a single object (possibly a dummy), and the remainder can be specified on a subsequent update run.

Four PDSs can be used by the utility, one for each of the four possible object types. If both input and output is performed for a given object type, the same PDS will be used for it. The PDSs are located by DDNAME. The values assumed for these names are taken from the TSO GDDM external defaults module, and you should modify the sample JCL for those defaults.

The utility reads a control file containing a list of operations required. For an import/export operation, it retrieves the object from the appropriate GDDM instance, and passes it to the other. For a delete operation, it issues an explicit delete object call to the IMS GDDM instance.

Each record is either:

A comment, in which case it has an asterisk in column 1.

Or takes the form:


         B  function B objectname B objecttype (B (comment))

where:


       B            represents one or more blanks
       function     may be IMPORT, EXPORT, or DELETE.
       brackets ()  are not written, but indicate optional data
       objectname   is the name of the object to be processed
       objecttype   is any one of the currently defined GDDM objects.

For example:

IMPORT ADMCOLSD ADMSYMBL IMPORT ADMDHIIA ADMSYMBL IMPORT ADMDHIIC ADMSYMBL

The object name may be specified in generic form using an asterisk ((*)). Thus, "ADMI(*)" specifies all those objects that have a name starting with ADMI. Similarly, "(*)ITAL(*)" specifies all those objects that have the character string ITAL in their name, such as ADMITALA.

Because there is a large number of GDDM required symbol sets, a lot of input statements for the initial symbol set load are required. With the generic form of specification, it is possible to enter:

IMPORT * ADMSYMBL

Also, for subsequent activity on the database, statements of the form

EXPORT ADMDH* ADMSYMBL

DELETE *MY* ADMSAVE

are allowed. In general, the objectname specification must be alphanumeric and not more than eight characters. It can start, or end, or both, with an asterisk, but cannot contain embedded asterisks. The objecttype must always be specified in full.

Notes:

1. Only columns 1 through 72 are inspected.

The utility writes a SYSPRINT report, containing the results of processing each object. Sample JCL to run the utility is provided on the installation tape as job stream ADMUJI07. The input data stream corresponds to that required to install the main symbol sets distributed with GDDM.

2. Two PSBs are defined, ADMFOUL to be used when loading a database for the first time, and ADMFOU to be used when updating an existing database.

3. If the IMS subsystem has been defined to use different segment and key-field names for this database, this change should be reflected in the external defaults module.

4. The utility issues symbolic checkpoint calls when being used to update an existing database. This limits the impact on the system resources enqueue space and dynamic log space, and also reduces the possibility of enqueue lockout on the database.

Notices | Terms of use | Support | Contact z/OS