Resolving DB00137E - INVALID RELEASE DBSYSID MODULE Message
Article ID: 236711
Updated On:
Products
Issue/Introduction
How do I identify the problem in my Datacom MUF or my application from these messages:
DB00137E - INVALID RELEASE DBSYSID MODULE - DBSIDPR
DB00502E - REQUEST ERROR - RETURN CODE 94 (098)
This what I am seeing from the MUF start-up:
AD11STRT:DB00249I - DBSIDPR 2021/05/15 14.55 SVC=000 TOGROUP= CCISYS= PC=PROD
Environment
Component : Datacom/AD
Component : Datacom/DB
Cause
This error is usually the result of a DBSIDPR module assembled at a different release from the MUF release. However, it may be the result of missing or incorrect version loadlibs in use, or if one of the loadlibs is not APF authorized, an unexpected Linklist loadlib may be involved.
This article will help identify the errant loadlib.
Resolution
The Datacom/DB or Datacom/AD Multi-User Facility (called MUF) and applications that connect to the MUF can use program objects/load modules from one of three locations:
- The JOBLIB or STEPLIB allocated custom configuration loadlib (commonly called the CUSLIB)
- The JOBLIB or STEPLIB allocated base loadlib (commonly called the CABDLOAD or CAAXLOAD)
- Linklist-defined loadlibs (these are not recommended for use with Datacom - please see Knowledge Base article 22678, titled "Linklist is not recommended for CA Datacom Libraries")
The expected usage of the loadlibs is with A and B, above. As part of the installation process, the CUSLIB and CAxxLOAD should be APF-Authorized. However, in the event that the JOBLIB or STEPLIB contains any non-authorized loadlibs, if the module being loaded is found in the Linklist, it will be loaded from there (please see Knowledge Base article 15457, titled "Why a module is loaded from LINKLIST when it is in STEPLIB" for more details about this).
Since the subject error is the result of mixed or unexpected lower versions of load modules/program objects, one of the locations above could have been corrupted. Below is a process to track down the errant loadlib.
1. Review your MUF JCL and ensure that the STEPLIB in use there has the same loadlibs as the STEPLIB in the failing job or started task.
2. If they are the same, a quick check of the base loadlib can be made by browsing member DBINFPR in CAxxLOAD, and issue a F #MID command. Just past that eyecatcher, you should see some identifying information. For example for Version 15.1, you should see this (the FMID CABDF10 indicates 15.1, as does the literal R15.1 at the end of the string):
DBINFPR CABDF10 ~RMID(LU01280)~ 20210507 15.34 .......CA Datacom/DB R15.1
3. If this does not help, we now need to look at the libraries in more detail. The DBCGSPR utility will process the members of the CUSLIB to identify the version of each module, and we recommend using a STEPLIB that points to the SMP/E defined target loadlib for CABDLOAD or CAAXLOAD.
//DBCGSPR EXEC PGM=DBCGSPR,REGION=0M
//STEPLIB DD DISP=SHR,DSN=<<Your SMP/E CAAXLOAD
//SYSPRINT DD SYSOUT=*
//SYSPUNCH DD SYSOUT=*
//CUSLIB DD DISP=SHR,DSN=<<Your MUF or Application CUSLIB
//SYSIN DD *
FLAG_CUSTOMIZED
FLAG_DEFAULTS
VERBOSE
/*
There is a module summary report at the bottom of the SYSPRINT which will show all modules and their release level (modules DDVPEFT and DRQXXPR may not match the rest). If the release level here does not match the release level you expect, then it is likely that this loadlib (or some of its members) was inadvertently replaced with an older version.
4. If all the members in the CUSLIB are at the expected release level, you will need to run a Common Services batch command to display information about the base loadlib (or you can display the module information via a TSO command. Please see Knowledge Base article 235047, titled "View Product Maintenance Details for Broadcom Load modules" for a useful interactive display of load module details.).
//BATCHTSO EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//LOAD DD DISP=SHR,DSN=<<Your MUF or Application base loadlib - normally CAAXLOAD or CABDLOAD
//SYSTSIN DD *
CAMODID DDN(LOAD) detail
/*
Review the output from this job to verify the release level of the modules. If you find modules at a different level than expected, this might be your corrupted or replaced loadlib.
5. If both of the above steps show that all the modules are at the correct level, it is possible that something in the JOBLIB or STEPLIB is not APF-authorized, and the internal routine that loads modules might have found one in the Linklist (which, by definition, is APF-authorized). This same Common Services command can show modules that match a name or mask in the linklist.
//BATCHTSO EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
CAMODID SYSTEM LMOD(DB) detail NOCOMMON
CAMODID SYSTEM LMOD(@IP) detail NOCOMMON
/*
Note that this will show modules beginning with the specified string, and these may or may not be Datacom modules. Hopefully, the identification of the loadlib will help you identify these modules.
Additional Information
Hopefully, one of the above steps will help you identify the bad modules or the bad loadlib. If you need further assistance after running these jobs, please contact Broadcom support for Datacom.
Feedback
