Retreive Error Message Desc from BSFN from NER

What I am saying is you probably do NOT want to do

BSSV
-F4211FSBeginDoc
-CheckErrorsBSFN

But instead do:
BSSV
-MyBeginDocWrapper
----F4211FSBeginDoc
----CheckErrorsBSFN
 
What I am saying is you probably do NOT want to do

BSSV
-F4211FSBeginDoc
-CheckErrorsBSFN

But instead do:
BSSV
-MyBeginDocWrapper
----F4211FSBeginDoc
----CheckErrorsBSFN

We are on the same page. I'm doing it this way.

BSSV
-MyBeginDocWrapper
----F4211FSBeginDoc
----CheckErrorsBSFN
 
Have the CNC check the package library on the iSeries (I mean the library with the same name as the package). There are logs explaining why it failed to compile. I believe they are in a file called FAILED.

It might be the iSeries compiler is sensitive to where variables are declared. i.e. at the top of the function before any code. That's a total guess

Craig
 
Have the CNC check the package library on the iSeries (I mean the library with the same name as the package). There are logs explaining why it failed to compile. I believe they are in a file called FAILED.

It might be the iSeries compiler is sensitive to where variables are declared. i.e. at the top of the function before any code. That's a total guess

Craig

found it. not sure exactly whats the deal. still investigating

530 368 | /********** Open a new Cursor if not all ready open **********/
| 368
531 369 25 | if(!hCursor)
| 369
532 370 | {
| 370
533 371 26 | if(jdeCacheOpenCursor(hCache, &hCursor) != JDECM_PASSED)
| 371
534 371 26 + if(jdeCacheOpenCursorX(hCache, &hCursor, "/OneWorld/Packages/DVU141208/source/CCUSTOM
/b59jdet1.\+ 371
535 ===========> ...............................................a.......................................
...........
536 5770WDS V7R1M0 100416 IBM ILE C compiler b59jdet1.c E1ENT2 12/0
8/14 16:15:40 Page 11
537 *=SEVERE==========> a - CZM0280 Function argument assignment between types "void**" and "const stru
ct HICON__**" is not allowed.
538 371 +c", 371) != 3)
+ 371
539 372 | {
| 372
 
Huh, I have always used HCURSOR but maybe I should be using HJDECURSOR.

In other words try changing

HCURSOR hCursor

to

HJDECURSOR hCursor
 
Last edited:
I mean change the variable declaration in the .c file for the JDETipsViewErrorStackIterate function.

HCURSOR hCursor = (HCURSOR)NULL;

s/b

HJDECURSOR hCursor = (HJDECURSOR)NULL;


Researching now, but it looks like JDE changed from using HCURSOR to using HJDECURSOR a few years back and I missed the memo. And by "few years back" I mean somewhere around the late 90's.
 
I mean change the variable declaration in the .c file for the JDETipsViewErrorStackIterate function.

HCURSOR hCursor = (HCURSOR)NULL;

s/b

HJDECURSOR hCursor = (HJDECURSOR)NULL;


Researching now, but it looks like JDE changed from using HCURSOR to using HJDECURSOR a few years back and I missed the memo. And by "few years back" I mean somewhere around the late 90's.

I understand the substitution. I looking for a definition of what type of data HJDECURSOR actually is....struct/pointer/int etc etc. It must be defined in a .h file somewhere or constant of some sorts....

reading through this some documentation

https://docs.oracle.com/cd/E17984_01/doc.898/e14700/working_with_apis.htm
 
It's just a handle, a VOID * or an opaque pointer.
 
Last edited:
So after a quick look, I can see why HCURSOR works just fine on windows based OSs. HCURSOR is defined in the standard windows headers. Not sure what the definition is on non windows OSs like the iSeries which is why JDE probably moved to HJDECURSOR way back. HJDECURSOR is simply a void pointer.

from JDEKDCL.h
Code:
typedef void * HJDECURSOR;

The correct way is to use HJDECURSOR, not HCURSOR for all the jdecache api so it works on all OSs, all compilers, all JDE tools releases, etc. and your code will work on future tools releases. Sorry for the confusion. And now I have over a decade of code to do a search and replace on in the event someone wants to move from windows to iseries at my organization...
 
No need to apologize Brian. Your contribution is a useful tool in the E1 devs toolbox. It is difficult to "support" all releases/configurations of E1 when sharing a resource. I mean, who has a spare iSeries to test on?

Craig
 
Thanks Craig. Actually really thankful he found the issue and enlightened me. For windows its no big deal since for all intensive purposes HCURSOR and HJDECURSOR effectively compile to the same thing but if Oracle ever changed HJDECURSOR from a void pointer to something else I would be scrambling to fix some code. Also my organization may move to Linux one of these days and I wouldn't be surprised if the linux/gcc compiler has the same issue. At least now I can change my code to be cross platform compatible. And, we are about to do a tools upgrade and will be doing some extensive testing so now is a really good time to retrofit our code so timing couldn't be better.

What I am wondering is how pristine functions like B0701830 is able to compile on the iSeries since it makes the same mistake I did. I guess because they do an explicit cast on the api calls???
 
Good and bad news.

Good - With all your help we were able to get it to compile and deploy. Thanks for this!

Bad - The kernel is dying when trying to init the cache...

BSSV
-MyBeginDocWrapper
----F4211FSBeginDoc
----CheckErrorsBSFN
----B59JDET1.JDETipsViewErrorStackInit <--this zombies by kernels

logs

BSSV LOGS

10 Dec 2014 08:52:13,775[DEBUG][JDBJ]Execute Business Function:MyWrapperFunction, Host: E1Server:6016
10 Dec 2014 08:52:13,775[DEBUG][JDBJ]CallObject flattening: Encoding UTF-16LE
//bunch of params
10 Dec 2014 08:52:13,775[DEBUG][JDBJ]CallObject sending: Error Count = 0 Warn Count =0
10 Dec 2014 08:52:13,775[DEBUG][NET]Sending AuditInfo for MyWrapperFunction: GUID [10.10.10.84:6196614182231337750], WID [BSSVSERVER], PID[INTEROP], IPAddr[10.10.10.1]
10 Dec 2014 08:52:23,884[SEVERE][KERNEL]*ERROR* Associated kernel 427 not found host E1Server:6016(32823) SocID:61931, freeLocal com.jdedwards.system.net.JdeNetAssociatedKernelException: Kernel for associated message not exist
10 Dec 2014 08:52:23,884[DEBUG][KERNEL]freeLocal
10 Dec 2014 08:52:23,884[DEBUG][KERNEL]freeLocal
10 Dec 2014 08:52:23,884[WARN][RUNTIME]*ERROR* CallObject@788158b: COSE#1017 Associated kernel not found. Please see Enterprise Server log for details: host E1Server:6016(32823) SocID:61931 PID:427 BSFN:MyWrapperFunction user:USER Env:Environment


E1 Kernel Logs


Dec 10 08:52:58.344856 jdeobj.c2610 - 427/5 WRK:USER_80000000_DConnector **********************************************************************************

Dec 10 08:52:58.344872 jdeobj.c2613 - 427/5 WRK:USER_80000000_DConnector *** Start dumping data structure for business function JDETipsViewErrorStackInit

Dec 10 08:52:58.344888 jdeobj.c2615 - 427/5 WRK:USER_80000000_DConnector **********************************************************************************

Dec 10 08:52:58.344912 jdeobj.c2705 - 427/5 WRK:USER_80000000_DConnector IN->Ý 1¨ <Item>: mnHandle <type>: MATH_NUMERIC <Value>: Ý0¨

Dec 10 08:52:58.344928 jdeobj.c2705 - 427/5 WRK:USER_80000000_DConnector IN->Ý 2¨ <Item>: nWarningCount <type>: INT <Value>: Ý0¨

Dec 10 08:52:58.344944 jdeobj.c2705 - 427/5 WRK:USER_80000000_DConnector IN->Ý 3¨ <Item>: nErrorCount <type>: INT <Value>: Ý0¨

Dec 10 08:52:58.344960 jdeobj.c2705 - 427/5 WRK:USER_80000000_DConnector IN->Ý 4¨ <Item>: nTotalCount <type>: INT <Value>: Ý0¨

Dec 10 08:52:58.344976 jdeobj.c2712 - 427/5 WRK:USER_80000000_DConnector **********************************************************************************

Dec 10 08:52:58.344992 jdeobj.c2715 - 427/5 WRK:USER_80000000_DConnector *** End dumping data structure for business function JDETipsViewErrorStackInit

Dec 10 08:52:58.345008 jdeobj.c2717 - 427/5 WRK:USER_80000000_DConnector **********************************************************************************

Dec 10 08:52:58.345024 jdeddapi.c315 - 427/5 WRK:USER_80000000_DConnector Entering jdeCloseDictionary

Dec 10 08:52:58.345032 jdeddapi.c349 - 427/5 WRK:USER_80000000_DConnector Exited jdeCloseDictionary with DDType 0

Dec 10 08:52:58.345056 jdb_ctl.c6507 - 427/5 WRK:USER_80000000_DConnector Entering JDB_InitBhvr

Dec 10 08:52:58.345120 jdb_ctl.c6596 - 427/5 WRK:USER_80000000_DConnector Exiting JDB_InitBhvr with Success (UserHandle SPP:0000 :0000 :0:1:12)

Dec 10 08:52:58.345144 jdecache.c355 - 427/5 WRK:USER_80000000_DConnector Entering jdeCacheInit - Name:ÝB59JDET1A44¨

Dec 10 08:52:58.345176 jdecache.c3005 - 427/5 WRK:USER_80000000_DConnector Incremented cache count to 18

Dec 10 08:52:58.345216 jdecache.c614 - 427/5 WRK:USER_80000000_DConnector Created new cache - hCache:ÝSPP:0000 :0000 :0:2f:12¨

Dec 10 08:52:58.345248 jdecache.c2985 - 427/5 WRK:USER_80000000_DConnector hCache:ÝSPP:0000 :0000 :0:2f:12¨ Nm:Ý91B59JDET1A44¨ Recs:0 Curs:0 Hnds:1 Cchs:18 INIT new

Dec 10 08:52:58.348288 jdeerr.c440 - 427/5 WRK:USER_80000000_DConnector Copying the 1 error/warning into curErrorRecord

Dec 10 08:52:58.383552 jdecallstk.c525 - 427/5 WRK:USER_80000000_DConnector Entering jdeGetCallStack: PID=427

Dec 10 08:52:58.705440 jdecallstk.c453 - 427/5 WRK:USER_80000000_DConnector Generating Call Stack for PID 427 from PID 427 with 7 active threads out of 7 total threads available

bunch of call stack information
 
Last edited:
This would explain why it was crashing on my fat client using jdeveloper(it was killing the kernel). I don't understand why call the function from ObjectBrowser acts differently than executing it from BSSV. I think I might try calling this from a ube and seeing what happens.
 
Hmmm, other than the HJDECURSOR thing I don't think there is any other "windows only" declarations or anything. It looks like from the log it is dying on the init call and passing in junk - meaning its like it's crashing just trying to invoke JDETipsViewErrorStackInit and not actually running any of the code in JDETipsViewErrorStackInit - that is unless JDETipsViewErrorStackInit is corrupting memory and/or the logging. I haven't called this BSFN through BSSV (well in the call stack that is) but have done so through XML CallObject w/o any problems (again on windows though).

I would look at the DSTR of JDETipsViewErrorStackInit and the other functions. I assume you had to manually create them using the typedefs in the .h file as a guide. Make sure the DSTR specs match the actual typedefs for the BSFNs in the .h file. Maybe even regen/repaste the BSFN DSTR into the .h file (if you didn't all ready do that). I wouldn't think that would be the problem since it is pretty straight forward and the DD items I listed in the comments are unlikely to be different across releases, but doesn't hurt to check.

You might want to actually take out all the actual logic and just have empty function calls to simply test the public BSFN interfaces. Once that is working put the "logic" back in.
 
Hmmm, other than the HJDECURSOR thing I don't think there is any other "windows only" declarations or anything. It looks like from the log it is dying on the init call and passing in junk - meaning its like it's crashing just trying to invoke JDETipsViewErrorStackInit and not actually running any of the code in JDETipsViewErrorStackInit - that is unless JDETipsViewErrorStackInit is corrupting memory and/or the logging. I haven't called this BSFN through BSSV (well in the call stack that is) but have done so through XML CallObject w/o any problems (again on windows though).

I would look at the DSTR of JDETipsViewErrorStackInit and the other functions. I assume you had to manually create them using the typedefs in the .h file as a guide. Make sure the DSTR specs match the actual typedefs for the BSFNs in the .h file. Maybe even regen/repaste the BSFN DSTR into the .h file (if you didn't all ready do that). I wouldn't think that would be the problem since it is pretty straight forward and the DD items I listed in the comments are unlikely to be different across releases, but doesn't hurt to check.

You might want to actually take out all the actual logic and just have empty function calls to simply test the public BSFN interfaces. Once that is working put the "logic" back in.

Thats what I'm doing now...slowly add in the logic and see If I can get an exact place where it's dying. Still boggles my mind that it works with object browser...

also dotting my t's and crossing my i's on DSTR's

more to come
 
Have you tried running it through the Object Browser, but selecting the server to run it on? (rather than locally) That might help narrow down where the problem is.
 
//after here
//perr = jdeErrorGetNextDDItemNameInfoEx(lpBhvrCom, lpVoid);
//before here

As you can see above i've narrowed this down to one statement, reviewing the api
 
Back
Top