3143 File can not be accessed.

[nkuebelbeck]

I've been tasked with creating a custom function to delete work order in case it was created in error because jde doesn't have a really friendly way to do it.

I've got it coded and everything is working great on my fat client. Boom, life if good.

I got it deployed to the Enterprise server (ISERIES) and when I went to execute it my BSFN from a custom interactive application it errors with a 3143 file can not be accessed.

hmmmmmmmm didn't see this in development on my fat client.

Asked the as400 guru to double check everything security wise is ok. check.

turned on some E1 debug logs to the kernel I was attached to and I see this

Feb 17 12:12:05.694048 jdb_rq1.c1169 - 748/4 WRK:MYUSER_80000000_P550102 Entering JDB_OpenTable(Table = F31122)
Feb 17 12:12:05.694064 jdb_rq1.c1570 - 748/4 WRK:MYUSER_80000000_P550102 JDB3100001 - Failed to open table F31122 because of invalid user handle
Feb 17 12:12:05.694480 jdb_rq1.c1180 - 748/4 WRK:MYUSER_80000000_P550102 Exiting JDB_OpenTable(Table = F31122) with Failure

I don't get it. This is my first time really using JDB API so there's a very likely possibility I've missed a quirk.

attached is the code snippet that appears to error, and the error that display on the screen from the interactive program.

Can anyone guide me in the right direction?

 

[Lucky.2811]

I hope you have retrieved huser before opening the table. I didn't see it as only partial code is attached. if not used please use below API to fetch user handle.

JDEDBResult = JDB_InitBhvr((void *)(lpBhvrCom),&hUser, (JCHAR *) NULL, JDEDB_COMMIT_AUTO);

 

[JMR]

just looking at your code snippet, everything looks ok to me. Is that snippet complete? By that, I mean is that piece of code exactly as it is in your source, with no portions you possibly left out thinking it was irrelevant? Getting different results between fat and server could be a memory violation issue that may only rear its head in a non-debug build (on server).

How are the following declared:
dsF4801
szF00095GenericKey

Those are the only two places I see in that snippet that could possibly be trouncing on another variable's memory. Based on that entry in the log, it's as if the hUser was invalidated between the F4801.open the F31122.open. If that snippet is a complete listing of that section of code, then I don't see an issue.

Good luck.

 

[jdelisths]

The code looks OK to me ... can you check the iSeries job log for the call object kernel (option 5, then 10)? It will tell you if something is wrong at the database level.

 

[nkuebelbeck]

I hope you have retrieved huser before opening the table. I didn't see it as only partial code is attached. if not used please use below API to fetch user handle.

JDEDBResult = JDB_InitBhvr((void *)(lpBhvrCom),&hUser, (JCHAR *) NULL, JDEDB_COMMIT_AUTO);

Yes, this was done. it's just earlier in the code

 

[nkuebelbeck]

just looking at your code snippet, everything looks ok to me. Is that snippet complete? By that, I mean is that piece of code exactly as it is in your source, with no portions you possibly left out thinking it was irrelevant? Getting different results between fat and server could be a memory violation issue that may only rear its head in a non-debug build (on server).

How are the following declared:
dsF4801
szF00095GenericKey

Those are the only two places I see in that snippet that could possibly be trouncing on another variable's memory. Based on that entry in the log, it's as if the hUser was invalidated between the F4801.open the F31122.open. If that snippet is a complete listing of that section of code, then I don't see an issue.

Good luck.

JCHAR szF00095GenericKey[] = {0};
F4801 dsF4801 = {0};

 

[craig_welton]

You have to give the szF00095GenericKey a size.

JCHAR szF00095GenericKey[41];

 

[nkuebelbeck]

You have to give the szF00095GenericKey a size.

JCHAR szF00095GenericKey[41];

Yeah, just caught that too. I actually opted out of created another variable and just used FormatMathNumeric(dsDSD0000602A.szGenericKey,&lpDS->mnWorkOrderNumber); straight to the data structure.

CNC is deploying. more to come.

 

[jdelisths]

.. that will hopefully fix the issue .. unless you explicitly enforce runtime checks, native C programs (on most platforms) will let things slide through until it reaches a certain indeterminate point, when it will just crash.

 

[nkuebelbeck]

Yeah, just caught that too. I actually opted out of created another variable and just used FormatMathNumeric(dsDSD0000602A.szGenericKey,&lpDS->mnWorkOrderNumber); straight to the data structure.

CNC is deploying. more to come.

problem solved. thanks everyone!