Question on jdecallobject API

Lucky.2811

Active Member
Can a OMW function be called from other OMW function of same BSFN directly without using jdeCallObject API?

Here is the scenario. We have two functions called Function1 and Function2 in a BSFN B55TEST. Function1 needs to be called in Function2. In XE they have called Function1 directly in Function2. I know that it is suggestible to use jdeCallObject to make BSFN calls, but as it is directly called in XE we have also left it as it is.

Question 1: It works in fat client, however I am concerned about it's behavior in AS/400 server.
Question2: Can functions be called directly if they are in same DLL after including .h file of the respective BSFN
 
If I understand you correctly, no. There are loads of BSFNs that have several modules that end up calling one another as they process.

Look at N0700003 DBACalcMonthsBetweenDates.
It calls N0700003 DBACalcFetchNextF09026LimitRange on line 0157.

So those are in the same object.

I appreciate this is a NER but have a look at the C++ behind it

Fetch F069026 using the Return Result 1 (Based on PPED) - Return Amount
00156 | | | // Lower Limit 1
00157 | | | -DBACalcFetchNextF09026LimitRange(N0700003.DBACalcFetchNextF09026LimitRange)

This is the C++ for that NER line

/* BF call : DBACalcFetchNextF09026LimitRange */
MathCopy( &zDS81.mnVariableName01 , &lpDS->mnReturnResult01 );
zDS81.cCharVariable01 = evt_cTypeOfTable_TABT;
jdeStrncpyTerminate( zDS81.szStringVariable01 , evt_szBenefitDedTable_DTAB ,
DIM( zDS81.szStringVariable01 ) );
pAppVars->iBusFuncRetCode = idRtnVal =
jdeCallObject( _J("DBACalcFetchNextF09026LimitRange") ,
(LPFNBHVR)NULL , lpBhvrCom , lpVoid ,
&zDS81 , cmErrorMap_82 , NUMMAP_82 ,
(JCHAR*)NULL , (JCHAR*)NULL , 0 );
MathCopy( &evt_mnAmountLowerLimit1_LCL , &zDS81.mnReturnResult01 );
 
Last edited:
Yes, this is supported if the function is in the same library. There are APIs/Macros to faciliate this: CALLIBFRET and CALLIBF. The idea is to avoid the overhead that occurs with a callobject call (OCM lookup etc.). You mention XE and I'm not sure if the API/macro was available then, but I would believe the direct call would work on all servers.

Craig
 
You lose a couple of things by calling a public BSFN directly (statically linking):
1. Visibility in the JDE Debug log - which is a considreration since I use the debug log a lot to put together call stacks, timmings, etc.
2. The whole OCM mapping thing (provided the called function is in another src file) which, in practice, is pretty much a moot point - or even a good thing depending on what you are doing.
3. CALLMAP support - or worse, weird CALLMAP results. I.e. - an error that was intended to show in the Qty Field in a grid for example, shows up on the Description field of the grid instead.

Personally, unless the public BSFN is in the same source file I generally use jdeCallObject. Even then, a lot of times my real logic is usually in internal subroutines and not directly in the public call scope itself so I am just calling an internal subroutine not the public BSFN.


Aside from a small amount of overhead savings, one other definite advantage to calling directly is you get compile time type checking on lpDS.
 
Back
Top