• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

DSI script error in JDE Xe

mofern

Member
Hi All,
We are having an issue with dcLink 4.2 SP5 (DSI) and JDE XE Update 6 SP 24.21. When we execute a dcLink script from Trancollector that calls NER ND3N4116 we receive the error “Open Cursor for cache I09UI002”.

Reviewing the jdedebug.log we see two calls to ND3N4116 (dcLINKInventoryReclassification). First call execute F0911FSBeginDoc and F0911FSEditLine creating header cache I09UI002 having one record. The second call to ND3N4116 executes F0911FSEditLine again and the cache init does not found any reference to the cache, so it creates a new one. Then F0911FSEditLine returns an error because there is not any record in header cache I09UI002. All the business functions are executed in a fat client Xe installed in the same computer where DSI resides.

The only strange point here is that first call to ND3N4116 is executed under thread 4248/4848 and the second call under thread 4040/5068. Is it possible that cache cannot be seen between these two different threads?

When we execute the dcLink script using the dcLink debugger, all the calls to ND3N4116 are executed by JDE under the same thread and everything works ok.

Any help will be appreaciated.


Extract from JDEDEBUG.LOG

Nov 14 16:56:17 ** 4248/4848 Calling Business function dcLINKInventoryReclassification for CRDDCDV. Application Name [], Version [] (BSFNLevel = 1)

Nov 14 16:56:17 ** 4248/4848 Return value is 0 for dcLINKInventoryReclassification. (BSFNLevel = 1)
Nov 14 16:56:18 ** 4040/5068 Entering JDB_AuditingOn
Nov 14 16:56:18 ** 4040/5068 Exiting JDB_AuditingOn with success
Nov 14 16:56:18 ** 4040/5068 Calling Business function dcLINKInventoryReclassification for CRDDCDV. Application Name [], Version [] (BSFNLevel = 1)

Nov 14 16:56:18 ** 4040/5068 Calling Business function F0911FSEditLine for CRDDCDV.

Nov 14 16:56:18 ** 4040/5068 Entering JDB_InitBhvr
Nov 14 16:56:18 ** 4040/5068 Entering jdeCacheInit - Name:[I09UI0024]
Nov 14 16:56:18 ** 4040/5068 Created new cache - hCache:[07ACF5C8]
Nov 14 16:56:18 ** 4040/5068 Entering jdeCacheOpenCursor (Called by: \NARAODP810\B7333\DV7333\package\DVFF1110B1\source \B0900049.c line 1176)
Nov 14 16:56:18 ** 4040/5068 hCache:[07ACF5C8] Name:[0I09UI0024] Recs:[0] Cursors:[1]
Nov 14 16:56:18 ** 4040/5068 Entering JDB_InitUser with commit mode 0.
Nov 14 16:56:18 ** 4040/5068 Entering JDB_BeginTransaction
Nov 14 16:56:18 ** 4040/5068 Entering JDB_FetchKeyed
Nov 14 16:56:18 ** 4040/5068 ORACLE DBRsetReq conn=0305F700 requ=07A65910 dbnap81a (jdenap81)
Nov 14 16:56:18 ** 4040/5068 SELECT * FROM DD7333.F9207 WHERE ( FRDTAI = '078M' )

Nov 14 16:56:18 ** 4040/5068 Return value is 2 for F0911FSEditLine. (BSFNLevel = 4)

Nov 14 16:56:18 ** 4040/5068 Return value is 2 for dcLINKInventoryReclassification. (BSFNLevel = 1)


Best regards.

Marcelo
 

JMR

VIP Member
Well, you're on a very old version of DSI and I don't have any experience with that release. Back then I believe the only option was to have the DSI services run on a dedicated fat client. Things are much better now.

As for your dilemma, I would suggest always using a dcLinkActionCode = "0" when calling any of the ND3N* functions. This will perform the entire unit of work in one function call as opposed to trying to perform separate BeginDoc, EditLine, EndDoc combinations...this type of function calling is just more prone to possibly having subsequent, related function calls running in different processes than the first call and that will always fail like you're seeing.

Again, I really don't know how that release of DSI manages those calls. I guess I should ask for clarification on the parameters you're using in your calls... what actioncode combinations are you using? If you're already passing "0", then I have no idea what is going on.

Good luck
 

mofern

Member
Hi Jeremy,
We had some problems using dcLinkActionCode = "0" but we created a NER calling the same ND3N* functions used in the DSI's script. As all the calls are executed from a single NER, they are run by the same kernel process and the error dissapear.

Thanks.

Marcelo
 
Top