Call Object Kernel Errors Clarification - jdeCallObject API and Error message COB0000*

Purpose of Document

This document is intended to give a brief cause of error messages written in the jde.log when a certain business function is requested from an application or a business function.

Two main errors may occur:

 

 

Error Codes from the jde.log

Error CodeError DescriptionCauseHow to Resolve
COB0000006 COB0000006 - No Function name passed.

Business function load failed - BAD LIBRARY - BAD FUNCTION
In calling jdeCallObject() the 1st parameter Function Name is missing Capture the Call Object kernel log that specifies the problematic business function then check jdeCallObject() API
COB0000007 COB0000007 -  No BhvrCom passed.

"Business function load failed (Bad BhvrCom) - szLibName - szFunctionName"
In calling jdeCallObject() the 3rd parameter lpBhvrCom is NULL InBhvr() is not performed correctly
COB0000008 COB0000008 - Could not retrieve BLC Header.

"Business function load failed - BAD LIBRARY - szFunctionName"
Failure in getting the library name from the BLC spec (or, jdeblc). Build package including problematic business function. Problematic bsfn can be retrieved by capturing valid jdedebug (call object kernel log)
COB0000009 COB0000009 - Allocation failure Failure to get the object key  
COB0000010 "COB0000010 - Allocation failure" Occurs when the library is not found Check parent DLL
COB0000011 "COB0000011 - Library load failed szPathLibszFuncName function Error = GetLastError() "
"Business function Library load failed -szPathLib - szFuncName"
Failure to Load Library Check package build process
Check file permission for library (read and execution have to be allowed for all)
COB0000012 "COB0000012 - GetProcAddress failed szLibszFuncName function Error = GetLastError() "
"Business function load failed - szLibName - szFuncName"
A certain business function is not found in the library defined Compile a specific BSFN or build package. For example, COB0000012 - GetProcAddress failed CFIN.dll function _F0911FSBeginDoc@12 Error = 127
Compile B0900049 - F0911FSBeginDoc through OMW
COB0000013 "COB0000013 - No DsTmplate." DSTmpl Spec was found, but template is NULL Build package to create another set of dstmpl specifications
COB0000014 "COB0000014 - Could not retrieve BLC Header, running locally." GetModuleName() failed Coexistence Environment
COB0000015 "COB0000015 - Failed to open table F0094." jdeChgWorldLibl() failed to open F0094 where Library is defined Coexistence Environment
COB0000017 "COB0000017 - Invalid library list entry."   Coexistence Environment
COB0000019 "COB0000019 - Environment not found." Able to access F0094 but environment not found in F0094 (F0094.LL)  
COB0000018 "COB0000018 - Could not retrieve BLC Header."
"Business function load failed - BAD LIBRARY -
szFunctionName"
Error given when a certain business function is not found from BLCSpec (jdeblc) Build package to create/correct blcspec
COB0000019 "COB0000019 - Could not retrieve Data Structure Format for fcn szFunctionName structure szDsTmplName." Failure to get associated data structure information from DSTMPL spec Build package to correct DSTMPL specification
COB0000020 "COB0000020 - No DsFormat." jdeBuildDSBlobFormatEx builds a "blob format string", which describes the layout of the DS so that it can be converted for different architectures (byte ordering, structure packing, etc.) It also delivers to AutoPilot a description of the data structure's format and field types (which is more info than is in the blob format string). Verify it through Data Structure design
COB0000069 "COB0000069 - jdeGetRemoteMsgHandle failed for szServerName. May cause problems on the application server if the process needed this auto commit user handle" 1. In getting the remote message handle here so to check the status of the server and handle it appropriately.

2. If there is no cache on the server, free the remote user (this really just cleans up client side structures since the jdenet_k containing the remote user handle is gone.
Then get new remote message handle. A failover needs to happen because the main server has gone down.
(When there is more than 2 logic servers and if it fails to get handle for Secondary server)

3. Secondary Server is down, so run locally. Possibly the business function runs too long and hUser is still in use, then free it try to get new handle

4. Try to reconnect
Determine offending interactive application or business function
COB0000070 "COB0000070 - Either pServerUserData (pServerUserData) or "pServerUserDataAuto (pServerUserDataAuto) is NULL. Because of this, the server status cannot be equalized and this may cause BSFN problems on the enterprise server. Equalize the server statuses for the AutoCommit and ManualCommit data structures. This way they will always be in sync with respect to the status of the enterprise server.  
COB0000120 "COB0000120 - Business function (szFunctionName) (calling (szFunctionName)) passed NULL error map (but specified nErr to CallObject!" Mismatch between pErrorMap (pointer to error map info; stored in the BSFN stack) nNumMap (the count of errorMap objects). For example, there is no error map but nNumMap is specified. Look for calling business function and search for existing bug to resolve issue.

Refer example below for this message.
COB00000250 "COB0000250 - Business function 'szFunctionName' is mapped to run locally. This is a web server and cannot process local business functions. To fix this, correct the OCM." A certain business function is mapped to run Locally (which is JAS) through OCM mapping After identifying function name, correct OCM mapping
COB0000250 "COB0000250 - Unable to register BSFN information. Text is too long! Function=szLocalFunc, Library=szLocalLib, File=szLocalFile,  Machine=LOCAL" In writing jdedebug.log, there is no room for writing string value. Informational
COB0000450 "COB0000450 - Business function szFunctionNameszServerName is causing problems on server ."
"Contact your system administrator to either change OCM or fix the problem with szFunctionName")
When it runs remotely, if this is the second retry to the same server, return failure.
Most commonly, jdenet_k falls into error/zombie
Capture jdedebug.log and contact GCS
COB0000451 "COB0000451 - There has been a problem with a jdenet_k process on server szServerName. The user must exit this application all the way to the menu and restart it. A certain business function fails to return. Trace jdedebug.log as call object kernel is dead
COB0000452 "COB0000452 - There has been a problem with server szServerName. The user must exit this application and restart it, then all processing will switch to szSecondaryServerName. Occurs when a request is NULL  
COB0000453 "COB0000453 - Attempting to reconnect to clustered server szServerName. Error occurred in connecting to clustered server  
COB0000454 This is an appending message which results from a Load Library Failure. Actual message in jde.log may be,

"COB0000454 - The Business Function Library szLibName could not be loaded on server szServerName. Because of the unknown cache-state on the server, you must exit this application all the way to the menu. Please notify your OneWorld System Administrator to have the problem corrected before attempting to run the Business Function szFunctionName again."
   
COB0000455 This message will be appended when it fails to get ProcAddress as below,

"COB0000455 - The Business Function szFunctionName was not found in the Business Function Library szLibraryName on server szServerName. Because of the unknown cache-state on the server, you must exit this application all the way to the menu. Please notify your OneWorld System Administrator to have the problem corrected before attempting to run""
   
COB0000455 "COB0000455 - CallObject error - JDB_AudtingOn failed. Setting audit flag to FALSE" CFR - check if auditing is on  
COB0000601 "COB0000601 - invalid parameter." Through GetBFPath() it fails to find Business Function path  
"UNKNOWN" "On szServerName, calling Business function szFunctionName from Level 1 for UNKNOWN USER. " In Multi-threaded Call Object Kernel Configuration when it did not return correct cache information Capture jdedebug.log and analyze it after identifying the offending interactive application

Back To Top

Arguments for jdeCallObject():

ArgumentsDescription
szFunctionName name of business function to invoke
lpBhvrPtr OBSOLETE pointer to business function; not present in V2 interface. Contained pointers, not a good idea in a shared memory environment.
lpBhvrCom new version BSFN structure pointer. See next item
lpVoidInfo hold error info returned from BSFN. This and plBhvrCom area generally created in jdeCreateBusinessFunctionParms (see below) and freed right afterwards
lpDs pointer to business function's data structure carries data into and out from BSFN.
pErrorMap pointer to error map info; stored in the BSFN stack
nNumMap the count of errorMap objects
szLibName name of library containing business function
szExeLocation over-ride of default run location
nRetryCount (formerly nFlags) used to indicate depth of retry
recurse a recursion depth counter
lpCout NULL in normal use; during unit testing points to a structure for commanding/tracking/returning debug data. Linked list, added to for each recursive call - linked structures need to eventually eventually be freed back to the heap


Example:

idReturnCode = jdeCallObject(_J("GetSoldToBillingInstructions"), \* szFunctionName *\
                                                      NULL,                                                 \* lpBhvrPtr *\
                                                      lpBhvrCom,                                        \* lpBhvrCom *\
                                                      lpVoid,                                                 \* lpVoidInfo *\
                                                     (LPVOID)&dsD4200100,                 \* lpDs *\
                                                     (CALLMAP *)NULL,                       \* ErrorMap *\
                                                     (int)0,                                                   \* nNumMap *\
                                                     (JCHAR *)NULL,                               \* szLibName *\
                                                     (JCHAR *)NULL,                              \* ExeLocation *\
                                                     (int)0);                                                 \* nRetryCount *\                                                  

   : Last two parameter can be omitted as appears above

Back To Top


Returns (or return value when a certain BSFN returns or return()):

Back To Top



Example of message in logs
This section is to describe example of messges in jde.log which is the result of callobject kernel.


Example 1: COB0000120

Message in JDE.LOG:
First of all, analyze components of message:
2736/3320 WRK:JDE_USER_077940E8_P31113        Thu Oct 20 12:09:58.610284            Jdeerr.c1775
COB0000120 - Business function (F3111WOIssuesEditLine) (calling (CacheProcessDualUnitOfMeasure)) passed NULL error map (but specified 1 entry) to CallObject!

As-Is Code:
              jdeCallObject (_J("CacheProcessDualUnitOfMeasure"),
                             NULL ,
                             lpdsInternal->lpBhvrCom,
                             lpdsInternal->lpVoid,
                             (LPVOID) &ds4101450A,
                             (CALLMAP *) NULL,
                             (int) 1,
                             (JCHAR *) NULL,
                             (JCHAR *) NULL,
                             (int) 0);
    : For this example, 7th parameter is specified as (int)1 pointer for CALLMAP is NULL so this syntax is not valid

How to resolve message:

  1. Review JDE.LOG and look for C function (for this example, B3102270)
  2. Open C Function and Look for called BSFN (e.g., CacheProcessDualUnitOfMeasure). Latest code is located in your deployment server (e.g., \\DeploymentServer\E900\PD900\Source\B3102270.c)
  3. Focus on how JDE API jdeCallObject and look for parameter for pErrorMap and nNumMap
  4. Ensure ErrorMap and nNumMap are in synch
  5. Look for a bug for mentioned issue and if you are not able to locate bug on this error message contact Oracle Global Support

Back To Top