We are on the same page. I'm doing it this way.What I am saying is you probably do NOT want to do
But instead do:
found it. not sure exactly whats the deal. still investigatingHave 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
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....I mean change the variable declaration in the .c file for the JDETipsViewErrorStackIterate function.
HCURSOR hCursor = (HCURSOR)NULL;
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.
typedef void * HJDECURSOR;
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...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.