Custom Search

ENDEVOR DB2 PROCEDURES

DB2 PROCEDURES

As part of normal production procedures, Endevor takes care of setting up your binds. When you move a DB2 load module to Endevor stage 2, the bind statements (from PROD.XX.END.BINDDECK where XX denotes the system that the bind cards belong to) for that load module are copied to the correct bind stageing library; PROD.OT.END.STAGE.ONLBIND for online, and PROD.OT.END.STAGE.BTCHBIND for batch. The binds execute on system G. This is true for ACES and SUBRO. FRACS binds need to execute on system A, so its binddecks are copied to PROD.FS.END.STAGE.ONLBIND or PROD.FS.END.STAGE.BTCHBIND.Drive-in App binddecks are copied to PROD.OT.DI.PRODBIND.

DB2 Binds (System G)

There exist four procs that run during the nightly batch cycle that handle
the Binds and Grants and cleanup. They are;

OTD2BIND for On-line & Nonconversational programs. (Executes a Bind & Grant)
OTBINDRP empties out PROD.OT.END.STAGE.ONLBIND
OTD2BBND for Batch programs. (Executes a Bind only).
OTBBNDRP empties out PROD.OT.END.STAGE.BTCHBIND

DB2 Binds (System A)

There exist four procs that run during the nightly batch cycle that handle
the Binds and cleanup. They are;

FSD2BIND for On-line & Nonconversational programs.
FSBINDRP empties out PROD.FS.END.STAGE.ONLBIND
FSD2BBND for Batch programs.
FSBBNDRP empties out PROD.FS.END.STAGE.BTCHBIND

Production binds should be done each time a new load module is created regardless of whether SQL has been changed. Endevor will take care of this for you; you just need to verify that the binddeck(s) have been copied after your move.

Follow the next 5 steps if adding a plan or changing a binddeck:
A. Create bind control cards for plan using generic bind control cards
OTXX94.DB2.BINDCARD(BINDCARD). The new bind control cards should be named the
same as the plan name. Replace XXXXXXXX with the plan name and replace the
YYYYYYYY entries with the correct member names. Be sure that the ACTION
parameter is always REPLACE. REPLACE will always work, even the first time.
The LIBRARY statement may need to have DPROP and XS libraries added. The complete concatenation order is:
LIBRARY (‘SYS1.DPROP.EKYDBRM’ +
‘PROD.OT.END.DBRMLIB’ -
‘PROD.XS.DS.OT.SRVS.DBRMLIB’) -

B. FIRST TIME: Grants: On-line and Nonconversational Programs ONLY:
Edit PROD.OT.PRODGRNT and copy the generic GRANT card from OTXX94.DB2.BINDCARD(GRANT). The Generic GRANT card is as follows:
GRANT EXECUTE ON PLAN XXXXXXXX TO PUBLIC ;
Replace XXXXXXXX with the desired plan name and save dataset. Remember that
other programmers may be doing a GRANT that night so you should copy your
GRANT cards after theirs.
C. Add the BINDDECK to Endevor using a processor group of *NOPROC*. Follow the procedures outlined for adding a linkcard for the first time in section V.3.

D. Update the appropriate binddeck for the system being changed: IE: OTBNDBAT
binds all plans in the ACES Batch system. OTBNDONL binds all ONLINE plans. The
prefixes used are FS, OJ & SU for FRACS, ALF & SUBRO. ALF only uses the
OJBNDBAT member since no online transactions use DB2.
Note: OTBNDBAT and OTBNDONL are only used if all ACES plans need to have BINDs run.

E. Update the DRPROP document found on PALINFO\OVERVIEW\DPROP. Go to page 22
under Nifty Things to Know and update either the table for IMS and DB2
propagation or the table for DB2 only propagation.


NOTE: You need to do this before you move your programs to Endevor stage 2. This is because the move processor will look for the bindcards to copy to the bind stageing library. If it is not there, the processor will get an error and your bind will not be set up.

Verification (System G)

If the bind was done for an On-line program then check job OTD2BIND or FSDBBIND in $AVRS on system G the following day.

If the bind was done for a Batch program then check job OTD2BBND or FSD2BBND in $AVRS on system G the following day.

Emergency Binds

There is JCL in OTXX94.SYSG.DB2.CNTL(BIND) to submit a bind immediately. The procedure is different from the normal bind procedure because Endevor normally does it automatically for you. A good reason for doing this would be a -818 abend (timestamp discrepancies between plan and load module). Please consult your project leader or someone on the technical team if you think this might be necessary. Copy the bindcards from PROD.XX.END.BINDDECK (where XX denotes the system they're associated with) into PROD.OT.BBNDBIND or PROD.OT.PRODBIND. Check that the library statement points to the proper DBRMs. Run the job and check the output in $AVRS.