Endevor

 View Only
Expand all | Collapse all

Endevor and DB2 Binds

  • 1.  Endevor and DB2 Binds

    Posted Sep 05, 2013 08:03 AM
    Anyone know of a way to have the QUALIFIER and OWNER parameters in the DB2 Bind statement be variable and be modified when moving/migrating from Test to QA and from QA to Production environment?
    In Test:
    BIND PACKAGE(DB2) MEM(VTPSQLRH) OWNER(PHDVUE) QUALIFIER(PHDVUE) VAL(BIND) ACT(REP) SQLERROR(CONTINUE)
    after moving to QA, we would want
    BIND PACKAGE(DB2) MEM(VTPSQLRH) OWNER(PHQAUE) QUALIFIER(PHQAUE) VAL(BIND) ACT(REP) SQLERROR(CONTINUE)
    and then to PROD
    BIND PACKAGE(DB2) MEM(VTPSQLRH) OWNER(PHPRUC) QUALIFIER(PHPRUC) VAL(BIND) ACT(REP) SQLERROR(CONTINUE)

    The BIND statement is in an Endevor PDS and would be checked out whenever the program is checked out
    Any suggestions would be welcome as well as samples of coding.


  • 2.  RE: Endevor and DB2 Binds

    Posted Sep 05, 2013 08:10 AM
    We use different owners and qualifiers in our implementation path
    Please email me at Brian.Churchill@nsrc.myflorida.com and I can give you samples.
    I would do it on here but you probably will have a lot of questions and too many emails will be generated


  • 3.  RE: [General Discussion] Endevor and DB2 Binds
    Best Answer

    Posted Sep 05, 2013 08:43 AM
    One suggestion would be to create a processor for the Bind Statement, that would invoke File Aid/File Manager to modify the bind statement according to the stage.


    From: CA ENDEVOR Global User Community [mailto:CommunityAdmin@communities-mail.ca.com]
    Sent: Thursday, September 05, 2013 8:03 AM
    To: mb.2255613.101710970@myca-email.ca.com
    Subject: [General Discussion] Endevor and DB2 Binds

    Anyone know of a way to have the QUALIFIER and OWNER parameters in the DB2 Bind statement be variable and be modified when moving/migrating from Test to QA and from QA to Production environment?
    In Test:
    BIND PACKAGE(DB2) MEM(VTPSQLRH) OWNER(PHDVUE) QUALIFIER(PHDVUE) VAL(BIND) ACT(REP) SQLERROR(CONTINUE)
    after moving to QA, we would want
    BIND PACKAGE(DB2) MEM(VTPSQLRH) OWNER(PHQAUE) QUALIFIER(PHQAUE) VAL(BIND) ACT(REP) SQLERROR(CONTINUE)
    and then to PROD
    BIND PACKAGE(DB2) MEM(VTPSQLRH) OWNER(PHPRUC) QUALIFIER(PHPRUC) VAL(BIND) ACT(REP) SQLERROR(CONTINUE)

    The BIND statement is in an Endevor PDS and would be checked out whenever the program is checked out
    Any suggestions would be welcome as well as samples of coding.
    Posted by:dale_mcjunkin
    --
    CA Communities Message Boards
    101713510
    mb.2255613.101710970@myca-email.ca.com<mailto:mb.2255613.101710970@myca-email.ca.com>
    http://communities.ca.com


  • 4.  RE: Endevor and DB2 Binds

    Posted Sep 05, 2013 09:31 AM
    Another solution would be to create several different TYPEs of BIND control cards. For example you might create a TESTBIND type which would contain your test bind control cards; a MODLBIND type which would control your model or QA bind control cards; a PRODBIND type which would contain your production bind control cards; etc. Then you could maintain each type bind control card within Endevor and you wouldn't necessarily have to write them to a PDS but just maintain within Endevor. Set you processors up to pull in the appropriate BIND cards depending on the environment / stage / etc where you need to invoke them with symbolics. We've been using this technique for several years andf it has worked well for us.


  • 5.  RE: Endevor and DB2 Binds

    Posted Sep 06, 2013 08:53 AM
    G'day, we use a REXX interface within our processors, which reads a flat file containing the stage specific DB2 OWNER and QUALIFIER
    (and occasionally the MEmber name). This allows us to manage what data structure is accessed as we migrate through our maps,
    including production migrations.

    The flat file is static, only requiring an update when a DB2 structure is added, changed or deleted. The file is Typed and stored in Endevor
    for control purposes.

    If you'd like further information, feel free to contact me at the email below.

    Val Valcourt
    Endevor Users of New England President 2009 - 2013
    Past EUNE President; when the dinosaurs roamed !
    Email: valerie.valcourt@nu.com


  • 6.  RE: Endevor and DB2 Binds

    Posted Sep 10, 2013 05:55 AM
    Hello,
    I am working with the Endevor for DB2 (EDB2) development team.

    Regarding the initial request of the user, the requirement is to have an utility to automatically change the data in the Bind cards. We have such a utility available in EDB2 which uses an inbuilt BIND processor.

    In this utility, a template of Bind card is provided. Then using this template all information of a Bind card is transformed.

    e.g.

    A Bind card has keywords like below,

    BIND PACKAGE ( EDB2_PKGSKGS ) +
    MEMBER (ENABSPKG) +
    OWNER (MOHRE01) +
    QUALIFIER (MOHRE01) +
    LIBRARY ('OFS.EDB2.WRK140S.DBRMLIB')

    Then using below template for transformation,

    BIND
    PACKAGE ( *001)
    OWNER ( PRD_*)
    QUALIFIER ( _PRD )               
    LIBRARY ( PRD* )

    The final BIND card will be,

    BIND PACKAGE ( EDB2_PKGS001 ) +
    MEMBER (ENABSPKG) +
    OWNER (PRD_E01) +
    QUALIFIER (MOH_PRD) +
    LIBRARY ('PRD.EDB2.WRK140S.DBRMLIB')



    This Templating utility has addiitional application to standardize the BIND card, usage of abbreviated keywords in Bind card and multiple template and multiple inputs.
    It is compatible with all DB2 V10 parameters.

    Please let us know if your requirement is somewhat related to this and we could help in this.


    Thanks and Regards.
    Abhishek Negi
    NEGAB01@CA.com


  • 7.  RE: Endevor and DB2 Binds

    Posted Jul 01, 2019 11:52 AM
    Where can I find more information about DB2 V11 and above DB2 Binds for MF DB2 with Endevor?  I need DB2 BIND Service to work the same as DB2 BIND Package.
    Thank You, Donna Kniveton

    ------------------------------
    Donna Kniveton
    ------------------------------



  • 8.  RE: Endevor and DB2 Binds

    Posted Jul 08, 2019 11:11 AM
    Hi Donna, I thinking it wold be good to start with your internal DB2 support group, then you can take care of any changes that may be required on the Endevor side. -Phil

    ------------------------------
    Senior Systems Engineer
    ------------------------------



  • 9.  RE: Endevor and DB2 Binds

    Posted Sep 14, 2013 08:25 PM
    Hello Dale,

    The Endevor V16 release will make available a program that can perform DB2 binds in a manner similar to the one that MizVee described in her response. The Rexx-based program is already in-use at many Endevor sites, and can automate the tailoring of Bind statements based on Endevor variables such as Environment, Stage, System, Subsystem, Type, Processor group and/or element name. Any or all of the clauses in the Bind statement can be dynamically tailored.

    You may already have what you need. If not, please indicate, and I will provide some additional information.


  • 10.  RE: Endevor and DB2 Binds

    Posted Jul 25, 2019 02:24 PM
    Edited by Mathew Goldstein Jul 25, 2019 03:48 PM
    ​We are using CONPARMX  to define the DB2 bind options for each processor group, we match the DB2 BIND options name with a subsystem and stage identifier, for example something like D&C1SUBSYSTEM&C1STAGEID. Ideally, there will be a DB2 object naming standard and the only character(s) that would change from stage to stage would be the lifecycle indicator character(s).


  • 11.  RE: Endevor and DB2 Binds

    Posted Aug 06, 2019 05:49 AM

    Mathew,

    Could you please elaborate the above idea of using CONPARMX for building DB2 Binds cards with the sample step.
    Thanks!!




  • 12.  RE: Endevor and DB2 Binds

    Posted Aug 06, 2019 07:39 AM
    Set your "PARMX" symbolic value however you need it to be set (for example, you may want to specify life cycle names instead of stage names).  This example sets PARMX as a combination of subsystem and stage names:
    //* For current Subsystem and Stage ID
    // PARMX='&C1SUBSYS(4,1).&C1STAGE(3,1)',
    If you need to back bind then you can add another set of these steps with additional symbolics for the prior stage(s).
    After the DB2 bind options are retrieved they are validated before they are executed to remediate the risk of executing arbitrary TSO commands. This example assumes that the libraries containing the DBRM and the DB2 bind commands are local to both ENDEVOR and the partition where the DB2 binds are executed and that SYSAFF will execute the DB2 bind on the target partition. If this is not the case then you will need to add step(s) to transfer everything to the remote partition(s). This example assumes BIND PACKAGE, but BIND PLAN could also be supported with some modifications.

    //*********************************************************************
    //* 2 TRY TO RETRIEVE DB2 BIND PARAMETERS FOR CURRENT STAGE *
    //* FOR THE PROGRAM ELEMENT *
    //* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    //DB2PRME EXEC PGM=CONPARMX,
    // MAXRC=0,
    // PARM=(D&PARMX,,Z,Z,&C1ELEMENT,,'N','Y')
    //PARMS DD DSN=&&DB2BIND,
    // DISP=(OLD,PASS)
    ++INCLUDE ##PARMX
    //*********************************************************************
    //* 3 CHECK IF DB2 PARAMETERS WERE RETRIEVED *
    //* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    //PRMCHKE EXEC PGM=IDCAMS,
    // MAXRC=4
    //SYSUDUMP DD DUMMY
    //SYSOUT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //SYSPRINT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //FILEIN DD DSN=&&DB2BIND,
    // DISP=(SHR,PASS)
    //SYSIN DD *
    PRINT INFILE(FILEIN) CHARACTER COUNT(1)
    /*
    // IF (PRMCHKE.RC EQ 4) THEN
    //* IF DB2 PARAMETERS NOT RETRIEVED *
    //*********************************************************************
    //* 4 TRY TO RETRIEVE DB2 BIND OPTIONS FOR CURRENT STAGE *
    //* FOR THIS PROCESSOR GROUP *
    //* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    //DB2PRMP EXEC PGM=CONPARMX,
    // MAXRC=0,
    // PARM=(D&PARMX,,$$$$DFLT,&C1PRGRP,Z,,'N','Y')
    //PARMS DD DSN=&&DB2BIND,
    // DISP=(OLD,PASS)
    ++INCLUDE ##PARMX
    //*********************************************************************
    //* 5 CHECK IF DB2 PARAMETERS WERE RETRIEVED *
    //* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    //PRMCHKP EXEC PGM=IDCAMS,
    // MAXRC=4
    //SYSUDUMP DD DUMMY
    //SYSOUT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //SYSPRINT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //FILEIN DD DSN=&&DB2BIND,0
    / DISP=(SHR,PASS)
    /SYSIN DD *
    PRINT INFILE(FILEIN) CHARACTER COUNT(1)
    /*
    //*********************************************************************
    //* 6 VALIDATE THE DB2 BIND PARAMETERS, CREATE CLIST *
    //* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    //VALIDBND EXEC PGM=IKJEFT01,
    // MAXRC=4,
    // PARM='%DB2BVAL &C1STAGE &DB2DSG &LPAR &C1ELEMENT'
    //SYSTSIN DD DSN=&&DB2BIND,
    // DISP=(SHR,PASS)
    //SYSPRINT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //SYSTSPRT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //SYSEXEC DD DSN=name of REXX library,
    // DISP=SHR
    //BINDOUT DD DSN=&#HLQ..&MIDLVL..DB2BIND(&C1ELEMENT),
    // DISP=OLD
    // IF (VALIDBND.RC = 0) THEN
    //* IF DB2 PARAMETERS WERE VALIDATED *
    //*********************************************************************
    //* 7 SUBMIT DB2 BIND FOR CURRENT STAGE  *
    //* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    //DB2BIND EXEC PGM=IEBGENER,
    // MAXRC=4
    //SYSIN DD DUMMY
    //SYSPRINT DD DUMMY
    //SYSUT1 DD DATA,DLM='/>'
    //&C1USERID(1,5)D JOB  &account,'&pgmfield',
    // MSGCLASS=&MSGCLASS,CLASS=&CLASS
    /*JOBPARM SYSAFF=&LPAR
    //*
    //*********************************************************************
    //* EXECUTE DB2 BIND CLIST IN BACKGROUND FOR CURRENT *
    //* STAGE *
    //* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    //BINDBG EXEC PGM=IKJEFT1A
    //STEPLIB DD DSN=&DSNEXIT,
    // DISP=SHR
    // DD DSN=&DSNLOAD,
    // DISP=SHR
    //SYSPROC DD DSN=&#HLQ..&MIDLVL..DB2BIND,
    // DISP=OLD
    //SYSTSIN DD *
    &C1ELEMENT
    /*
    //DBRMLIB DD DSN=&#HLQ..&MIDLVL..DBRM,
    // DISP=SHR
    //SYSTSPRT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //SYSPRINT DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    //SYSUDUMP DD SYSOUT=&SYSOUT,
    // FREE=CLOSE
    />
    //SYSUT2 DD SYSOUT=(&INTRDR,INTRDR),
    // FREE=CLOSE,
    // DCB=(LRECL=80,RECFM=FB,BLKSIZE=3120)

    The Type PARMX program elements can contain the DB2 options for one or more DB2 binds provided the validation REXX, which also creates the DB2 BIND CLIST, is coded to recognize the start of each DB2 bind. MEMBER() is appended to each BIND by the validation REXX exec:
    Dsubstg = 'BIND PACKAGE(collection1) - '+
    'QUALIFIER(qualifier1) VALIDATE(BIND) - '+
    'BIND PACKAGE(collection2) - '+
    'QUALIFIER(qualifier12) VALIDATE(BIND) - '