DB2 V9 coprocessor DSNHDECP reporting the wrong load library when running under Endevor processor.
Article ID: 4079
Updated On:
Products
Issue/Introduction
Using enterprise COBOL V4.x with the SQL compiler option invokes the DB2 coprocessor (DSNHDECP). Starting with DB2 V9, the coprocessor enhances the compiler output with a report of the DB2 options in effect and also a message showing the library from where DSNHDECP was loaded. For example:
DSNHDECP LOADED FROM -(DSN910.SDSNLOAD(DSNHDECP)
When running the compiler this way in an Endevor processor, it may happen that the above message shows a library name other than the one from which DSNHDECP was actually loaded, or even just show <UNKNOWN> as the library name. This causes confusion, especially when an SDSNLOAD library from an unexpected DB2 release is shown in the message.
Environment
Component:
Resolution
This symptom only arises when running the coprocessor under an Endevor processor, and does not arise when compilation is run outside Endevor, causing customers to report it to CA as an Endevor problem. However, it is caused by a problem in the IBM code, probably in the DSNHDECP logic, as explained below.
In order to execute a processor step, Endevor uses the ATTACH macro so that MVS runs the program as a subtask of the program that drives the processor execution. Whenever the processor step includes a STEPLIB DD, the specified library chain is passed to the subtask in the TASKLIB operand, which causes MVS to search that library chain first thing for any module load requested during the execution of the subtask.
This procedure effectively causes DSNHDECP to be loaded from the processor step's STEPLIB, if found there.
However, when formatting the message showing what library it was loaded from, DSNHDECP seems to ignore the fact that it is executing in a subtask having its own tasklib, and assumes it's running as the main program in the job step.
Consequently, despite whatever is coded in the processor step's STEPLIB, the message DSNHDECP LOADED FROM will show the name of the first library found in the jobstep steplib, joblib or linklist (in this order) holding a copy of a module with name DSNHDECP.
This can be ascertained with a simple test, as follows:
1 - Locate the STEPLIB for the step running NDVRC1. For example:
//ENDES000 EXEC PGM=NDVRC1,
// DYNAMNBR=1500,
// REGION=0M,
// PARM='C1BM3000'
//STEPLIB DD DISP=SHR,DSN=SYS2.ENDEVOR.AUTHLIB
//CONLIB DD DISP=SHR,DSN=SYS2.ENDEVOR.CONLIB
2 - Create a dummy loadlib with APF authorization and chain it ahead of the steplib. This is to avoid updating the Endevor .AUTHLIB library.
3 - Using the binder, catalog a copy of SYS1.LINKLIB(IEFBR14) into the dummy library chained ahead of AUTHLIB) under name DSNHDECP.
IEFBR14 is a system utility that does nothing except returning to the caller with RC 0. Trying a DB2 compile (inside or outside Endevor) with that fake DSNHDECP in the steplib being used will produce unpredictable results.
4 -Run a DB2 compile with the JCL setup this way. Note that the coprocessor will issue message:
DSNHDECP LOADED FROM -(SYS2.ENDEVOR.AUTHLIB(DSNHDECP)
Which is just not possible and proves that the message is incorrect.
Don't forget to undo the changes done to the JCL and/or the loadlibs.
Feedback
