DB2 V9 coprocessor reporting DSNHDECP loaded from 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. 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 module DSNHDECP was loaded. For example:
DSNHDECP LOADED FROM -(DSN910.SDSNLOAD(DSNHDECP)
Module DSNHDECP is used to determine the DB2 subsystem to be used in the run when the program being executed does not explicitly connect to a particular subsystem. Therefore this message may be useful in diagnostic situations
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.
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 as an Endevor problem. However, it is caused by a problem in the IBM code, 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 DSNHDECP was loaded from, DB2 seems to ignore the fact that it is executing in a subtask having its own tasklib, and apparently 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. Should DB2 use that fake DSNHDECP it would probably fail to connect to any DB2 subsystem.
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
