Case Study - How to Interpret Error CAC0001017 in jde.log?

Purpose of Document

Below information is a guide on how to interpret error message CAC0001017 in jde.log.

In Xe and ERP8 the way it writes error message in jde.log is different from what it is explained in this note. However same logic can be applied.

• Guide higher level debugging through jde.log
• Indicate max data pointer and max cursor in EnterpriseOne

If jde.log reads this error message, try to resolve it because it may cause wrong transaction owing to inappropriate memory handling.

Example 1:

• Component for this message:
• 29586/5: Process ID/Thread ID
• 1000393: User ID
• P58C010A: Interactive Application ID. For this example, it refers custom interactive application but unless you have modified standard business function same error will be occurred in it
• jdecache.c1840: Actual C Codes jdecache, 1840 is line number in jdecache.c file so this value can be vary per tools release (this code is encapsulated)
• CAC0001017: Error Code as defined in jdecache.c (this is system level code which is to be encapsulated)
• 2F42UI12: Cache Name. This is important clue to trace offending business function. Note that this information may not be appeared log in EnterpriseOne release Xe and ERP8. So in case you need to debug this error message, capture callobject kernel log which shows what are the business function which creates this cursor. For this example, 2F42UI12 is cache name which is made up of 2(=Job Number) and F42UI12 (=Static Cache Name) which hold additional Sales Order Detail information. Since it writes cache (not work file) it confirms that this action is caused by interactive application and since it holds sales order detail information open cursor is called by B4200311 - Internal function for F4211FSEditLine.
• How to identify and fix it?
• : Look for available fix (ESU) based on object ID you have specified above (for this example, B4200311).

Example 2:
In Batch Application: Application Id is to be appeared on top of jde.log.

• Component for this message which are made up of 2 portion (Main Thread or UBE Kernel and Call Object Kernel):
• 922/49: Process ID/Thread ID
• 707064/E1USER /R09410: This messge appears on top of UBE log with memory area/User ID/Batch Application ID
• jdecache.c1749: Actual C Codes jdecache, 1749 is line number in jdecache.c file so this value can be vary per tools release
• CAC0001017: Error Code as defined in jdecache.c (this is system level code which is to be encapsulated)
• 0D09000471 Cache Name. This is important clue to trace offending business function. Note that this information may not be appeared log in EnterpriseOne release Xe and ERP8. So in case you need to debug this error message, capture callobject kernel log which shows what are the business function which creates this cursor. For this example, 0D09000471 is made up of Data Structure (=D0900047) of offending business function and job number (=1). So the object you need to check is B0900047. To think of the usage of this batch application R09410 this type of error may cause unexpected result by using up all the resources in your logic server.
• How to identify and fix it?
• : Look for available fix (ESU) based on object ID you have specified above (for this example, B0900047).

Example 3:

• Component for this message:
• 919/50: Process ID/Thread ID
• MWEBER_80000000_P31113: User ID + Cache Address + Application ID
• jdecache.c1749: Actual C Codes jdecache, 1749 is line number in jdecache.c file so this value can be vary per tools release
• CAC0001017: Error Code as defined in jdecache.c (this is system level code which is to be encapsulated)
• 4Cache_B3102280_-> Cache Name. For this example the last character is corrupted. For this example, this cache name is made up of Job Number + Static Cache Name + idPointer. So for this example, the length for cache name defined is too short to fill in. This type of issue can be specific to server environment because the job number of pointer ID between server (starts with 1001) and client (starts with 1) can be different in size. Since cache name for this object is structured B3102280 is the object name to debug.
• How to identify and fix it?
• : Look for available fix (ESU) based on object ID you have specified above (for this example, B3102280).

Important Note:

• This note explains general routine to debug but it is important to understand this type of issue in the context of a certain application. For example, pointer (the address of memory/cache) can be created by business function A and value which is stored in address can be used by business function B. Then developer may design to have this business function B to remove the pointer instead of using business function A.
• In C programming language, ID or pointer is integer value so this value can have it's own limit.
• In client machine the maximum number of pointer to store is 1000 and if the pointer is not removed properly actual value and address will remained till you restart system or JDE service

Additional Note:

• Max data pointer which DB can handle is 1000
• #define JDB_MAX_DATAPTR 1000
• Defined at system/common/jdekrnl/jdb/jdbprv.h (encapsulated code)
• Max Cursor (temporary repository of data) is 100 (JDECACHE definition),
• #define JDECACHE_MAX_CURSORS 100
• This file can be accessed system\include\JDEKDFN.h
• JDECM_CacheInit can open maximum cursors up to 100 (defined at system\include\jdekprto.h)
• You MUST NOT change any default value listed here
• So data pointer error will come after 1000 open pointer and open cursor error will come after 100 cursor opened

• <Document 1050172.1> - E1: BSFN: Why is /* FP */ Written in Business Function C Source file ? explains how to minimize this type of issue technically
• If you see 'Memory Violation' message in PDF or jde.log which is reflecting a certain business function called by a certain report has failed to return called routine.
• Memory is utilized through JDE's business function so it is important to capture jdedebug.log (namely callobject kernel log)
• When issue is occurring in a certain report, turn on logging dynamically in submitting a UBE to server because this log will contain runtime (through batch kernel) and business function (through callobject kernel) are to be combined into one file
• Once jdedebug.log is ready, analyze it through Performance Workbench because all the cache information can be traced through 'Log additional APIs?'
• All the UBE is running in a single thread for this reason if a certain ube is calling another ube synchronously you need to check the routines from both UBEs
• In capturing callobject kernel log, set DataPointerTracing=1 and Output=FILE in the [DEBUG] section of the JDE.INI.