This solution will help the user troubleshoot the following error in R47011 (Inbound Purchase Order).
EventRule : Business Function R47011DetailDoSectionProcess at line 36 for Event 13 in Section Read/Edit EDI Detail has caused a memory violation.
Troubleshooting Steps
R47011 (Inbound Purchase Order) ends in error as below when the number of detail lines are more than 1000, - Error message in PDF:
EventRule : Business Function R47011DetailDoSectionProcess at line 36 for Event 13 in Section Read/Edit EDI Detail has caused a memory violation.
- Message in jde.log
6056/5396 Tue May 03 01:12:27 2011 JDB_UTL1.C2484 JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr()
Sequence of referencing for Processing Options.
In processing option of R47011, get the version of P4210
In processing option of P4210 referenced version, get the version of P4310
Note: This is one of many possible example for Memory Violation. For example, error may come from different business function as <Bug 11020549>: R47011 EXCEEDING DATA POINTERS - SAR: 8939166
Do not call version for transfer order as it is written in <Document 655648.1> - E1: 47: Inbound 850 (R47011).
Excerpt: The Inbound Purchase Order (P47010) program supports most types of Sales Orders that can be manually entered using Sales Order Entry (P4210) except for Transfer Orders. The EDI program does not support the generation of Transfer Orders.
Additional Note:
Business function written in PDF output is the first level business function which is called directly from Event Rule
As we can see from this example, maximum cursor which operating system can hold is 1000
Since open cursor is not closed properly, the error may persist until the server is restarted
For this example, R47011DetailDoSectionProcess (B4700110 - R47011 Detail Do Section Process) is representation of 'Row Is Exited Changed - Async' in P4210 (Sales Order Entry) so this is to call B4200310/B4200311 - F4211FSEditLine (F4211 Edit One, note that there are 2 spaces in between F4211 and Edit Line)
Most of case, actual issue is not coming 1st level BSFN rather issue is caused by inner/sub routine of 1st Level Business Function so it is important to analyze jdedebug.log
1000 signifies that issue is related with F4211FSEditLine which is called by each rows to create data into F47UI11/F47UI12 if all the validation are successful
In assigning wrong referencing version, pointers (the address of memory/cache) are created 1000 without closing it. The reason for this is that in transfer order, data pointer for Sales Order detail is to be opened till corresponding Purchase Order detail lines consume it. Eventually when cache/work file for purchase order is created correctly this pointer will be removed
Max data point which DB can handle is 1000
#define JDB_MAX_DATAPTR 1000
Defined at system/common/jdekrnl/jdb/jdbprv.h (encapsulated code)
Cf., Cursor (temporary repository of data) are defined as below (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
For this case it is not easy to determine because cache verification for this example may be appeared correctly
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 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
At 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