CA Endevor

Expand all | Collapse all

Blocking load module creation following DB2 bind failure

  • 1.  Blocking load module creation following DB2 bind failure

    Posted 11-16-2019 06:08 PM
    Edited by Mathew Goldstein 11-17-2019 03:54 PM
    For some of the subprogram object modules we can identify the DB2 data sharing group (from our processor group names) and we can identify the DBRM library (standardized library names with stage name qualifiers match the inventory area names). Is anyone retrieving the CONTOKEN by executing DB2 SELECT commands in ENDEVOR and comparing that against the DBRM timestamp to verify that the required pre-production and/or production DB2 binds for the main program and its subprograms were successfully executed prior to moving main routine DB2 load modules to the next stage?


    I think it should be possible to reduce the risk of a runtime failure by verifying that all of the target stage DB2 binds for (at least) the first level called subprograms were successfully completed before moving DB2 load modules to the target stage. For this to work properly the subprograms are object modules, the main routine load modules are created using a separate type from the types utilized to create the object modules, and the DB2 binds are executed on package move actions to ensure proper type sequencing. A REXX exec or CLIST could read information about the first level called subprograms from the prior stage input component list. Then for each subprogram, read the current stage DBRM for the hex timestamp, create a DB2 SELECT command (sorted on BINDTIME?) to obtain the hex CONTOKEN, compare them , and fail the move action for the load module when they do no match. The ACM also identifies subprograms called by other subprograms. The generate time information for the subprograms is not available but that information is arguably unnecessary. So reading the ACM using information may be better than relying on the sometimes incomplete input component information.

  • 2.  RE: Blocking load module creation following DB2 bind failure

    Posted 11-19-2019 09:02 AM
    Have you looked at whether or not the old "Endevor for DB2" option might help?

    John D Consulting Inc.

  • 3.  RE: Blocking load module creation following DB2 bind failure

    Posted 11-26-2019 12:57 PM

    This may be too simplistic an answer but the way our DB2 processor group moves are set up, the binds are done first using the source stage DBRM. If the bind fails, the BSTCOPY steps are skipped and the move is flagged as failed.


    Karen Turner


    CONFIDENTIALITY NOTICE: If you have received this email in error,
    please immediately notify the sender by e-mail at the address shown. 
    This email transmission may contain confidential information.  This
    information is intended only for the use of the individual(s) or entity to
    whom it is intended even if addressed incorrectly.  Please delete it from
    your files if you are not the intended recipient.  Thank you for your
    compliance.  Copyright (c) 2019 Cigna

  • 4.  RE: Blocking load module creation following DB2 bind failure

    Posted 11-26-2019 01:26 PM
    The DB2 bind is executed by a routed job which is submitted by an IEBGENER step ​in the processor. That IEBGENER step will complete with a RC=0 regardless of whether or not the DB2 bind failed. We cannot rely on the people who execute the packages to know to route the package to the correct partition. A single package could need to be routing DB2 binds to different partition for different program elements. We could need to simultaneously execute DB2 binds on different partitions for a single program element (for different categories of pre-production testing). DB2 staff told me that they do not implement the routing capability within DB2 because that was deemed to be a security weakness. I am being told DB2 bind issues are an ongoing difficulty. Management instructed me to tackle this problem for the platform across all applications, not piecemeal for individual applications.