GDDM V3R2 Base Application Programming Guide
Previous topic | Next topic | Contents | Index | Contact z/OS | Library | PDF | BOOK


The structure of GDDM application programs for use on IMS

GDDM V3R2 Base Application Programming Guide
SC33-0867-01



The following list contains the steps that an IMS transaction program might make when using GDDM.

  1. Issue a GU call to the I/O program communication block (PCB) to acquire the first segment of the input message.
    
    
  2. Issue FSINIT, or any of its aliases, to enable GDDM processing.
    
    
  3. Optionally issue an FSEXIT call to nominate a user-provided error exit to replace the default exit provided with GDDM, or to raise the threshold of errors below which errors are not reported.
    
    
  4. Issue one or more ESPCB calls to identify to GDDM the PCBs that it may use.
    
    
  5. Issue one or more ESLIB calls to show which databases are to be searched when retrieving and storing GDDM data.
    
    
  6. If the I/O PCB has not been identified by an ESPCB call above, or if output is to go to a destination other than that of the I/O PCB, issue DSOPEN calls to define to GDDM the possible output destinations.
    
    
    If the PCB to be used by GDDM is modifiable, the destination of the PCB must be set using the CHNG call before the DSOPEN call is issued.
    
    
    This step is not needed if output is to go to the source of the input message and the I/O PCB has been identified to GDDM because this is the default destination and PCB used by GDDM.
    
    
  7. Process the input message using GN calls to acquire subsequent message input. Generate output messages using the GDDM subroutines to describe any field-formatted or graphics output. Use the DSUSE statement to select the output destination if devices have been explicitly defined by DSOPEN.
    
    
  8. Issue DSCLS statements for each device opened using DSOPEN.
    
    
  9. Issue the FSTERM call to end GDDM processing.
    
    
  10. Repeat from step 1 to process any more input messages.
    
    

This arrangement of an application program ensures that GDDM is inactive across a GU call that may reset certain information used by GDDM. Its drawback is the repeated initialization and termination of GDDM. An alternative structure that avoids this overhead is shown below. Care should be taken to ensure that all devices are closed across the GU call.

  1. Issue FSINIT, or any of its aliases, to enable GDDM processing.
    
    
  2. Optionally issue an FSEXIT call to nominate a user-provided error exit to replace the default exit provided with GDDM, or to raise the threshold of errors below which errors are not reported.
    
    
  3. Issue one or more ESPCB calls to identify to GDDM the PCBs that it may use.
    
    
  4. Issue one or more ESLIB calls to show which databases are to be searched when retrieving and storing GDDM data.
    
    
  5. Issue a GU call to the I/O PCB to acquire the first segment of the input message.
    
    
  6. If the I/O PCB has not been identified by an ESPCB call above, or if output is to go to a destination other than that of the I/O PCB, issue DSOPEN calls to define to GDDM the possible output destinations.
    
    
    If the PCB to be used by GDDM is modifiable, the destination of the PCB must be set using the CHNG call before the DSOPEN call is issued.
    
    
    This step is not needed if output is to go to the source of the input message and the I/O PCB has been identified to GDDM because this is the default destination and PCB used by GDDM.
    
    
  7. Process the input message using GN calls to acquire subsequent message input. Generate output messages using the GDDM subroutines to describe any field-formatted or graphics output. Use the DSUSE statement to select the output destination if devices have been explicitly defined by DSOPEN.
    
    
  8. Issue DSCLS statements for each device opened using DSOPEN.
    
    
    If the default destination was used, GDDM automatically opens a device with an identifier of 0. This should be closed using a statement of the form
    
    
    
             CALL DSCLS(0,1)
    

  9. Repeat from step 5 to process any more input messages.
    
    
  10. Issue the FSTERM call to end GDDM processing when all input messages have been processed.

Go to the previous page Go to the next page



Copyright IBM Corporation 1990, 2012