Do Citrix Client Calling Master BSFNs Use Specs?

[jdel6654]

I am having some performance problems and I would like to know more about the relationship between Master BSFNs and specs (ie. spec files) on the enterprise server. I have my MBFs mapped to the enterprise server for my Citrix clients (WPD7333). Do MBFs use specs on the enterprise server? Or, are MBFs the last part of the "call stack"? If MBFs do use spec files, how prevalent is this (ie. Do most MBFs call code in spec files?)?

The key thing here is that I am referring to Citrix clients and not batch UBEs running on the ES?

Your expert help would be greatly appreciated.

 

[Larry_Jones]

Mystery Person,

I don't believe BSFNs utilize spec files. BSFNs are called by the runtime system which interprets ER code (contained in spec files except for NERs and Triggers) - not the other way around. That doesn't mean though that the MBSFN is the end of the call stack. There's a lot of more BSFNs and System functions that will be called by the MSBFNs.

All that said, what does spec file usage have to do with your performance problems?

Why don't you share your performance issues and measurements with the group (along with your system configuration!) and I'll bet you'll get some good advice.

Cheers,

 

[jdel6654]

My, aren't we uppity non-Mystery dude.

The performance problems are complex. Goes back to the age-old question of why JDE says we need to run C code on the enterprise server. The performance issue in question is really a matter of optimization and system capacity. It is not a matter of end-user runtime performance.

My first inkling was that C code doesn't call I-code but you never know with OneWorld. Not only is it possible, but it doesn't seem unlikely that JDE would do that if it made sense to have C-code call I-code.

Thanks for your opinion.

 

[Larry_Jones]

Well . . .

Not sure why the need for a 'C' compiler on the ES is a question. A very hefty % of OneWorld is in 'C'. In order to build server packages and generate libraries/dlls you have to have a ANSI 'C' compiler.

Regarding Compiled code calling Interpreted code:
- ER code is only interpreted for APPL and UBE objects, NERs and Table Triggers are transpiled to 'C' code and then compiled.
- APPL objects cannot be executed on a application server or ES
- BSFNs CAN launch a UBE - in fact thats how you can get around limitations of the system function for doing the same.
- A MBSFN 'could' therefore run a UBE, but in general OneWorld's application architecture doesn't encourage doing this - transaction boundaries become a bigger problem then they already are.

My original reply to you was based on the understanding you were attempting to determine if there was a direct dependency on spec files by MBSFNs. Sorry if I offended you.

So it sounds like what you're really trying to get is a better understanding of OneWorld's system architecture rather than address a specific performance issue, right?

 

[jdel6654]

Larry/jdepro:

I've worked with OneWorld CNC for 5 years now (since B73.1) and I don't usually use this forum for help. It is too random and anybody that has enough time to read and respond to all the messages in this forum can't be under too much demand for their skills. I am fairly comfortable with my own expertise and (this may surprise you) disreputable jdelist lurker types sift thru this forum for prospective consulting gigs +o) Wow, SHOCKER! I have a BP login to the KG and I get most of my info that way.

My original question was very simple and I suspect any good developer would be able to answer: "Does the C-code call the I-code?". JDEPRO: This has little to do with type of ES you have. Whether or not C-code calls I-code would be unrelated to the type of ES you are using. I didn't ever say anything about performance problems, I said performance issues. If I had performance problems I would have posted to the OneWorld XE forum not the OneWorld XE DEVELOPERs forum. LARRY: I didn't say anything about compilers. I am well aware of the compilers. Finally LARRY, I know that you do not run APPL objects on the ES. On the other hand, I have seen enough C code to know a lot of BSFNs get processing option data from the Versions table on the ES. It seems perfectly logical that the BSFNs could retrieve spec data from gbrspec.ddb on the ES.

Guys, I appreciate your interest but if you aren't going to read the query first and don't know the subject matter, don't bother to respond. There are far too many people on this forum that respond to each and every post by pounding their chest and posting their opinions.

 

[jolly]

Hi There,

You posted that there is "age-old question of why JDE says we need to run C code on the enterprise server". When/where did JDE say that? In the vast majority of cases C code does not have to run on the ES.

Further to your question "Do MBFs use specs on the enterprise server?", you also posted "My first inkling was that C code doesn't call I-code but you never know with OneWorld. Not only is it possible, but it doesn't seem unlikely that JDE would do that if it made sense to have C-code call I-code". When you say I-Code do you mean Event Rules? What are you going in about? Of course C code doesn't call Event Rules. C code is compiled. NER's are converted into C code and compiled. Event Rules are stored in specs and cannot be called by C code as they are not business functions. So the answer to your question is No.

You say that "I have my MBFs mapped to the enterprise server for my Citrix clients". Do you mean *all* your MBFs? If so then no wonder you are having performance "problems" . Every user doing the slightest activity is queuing up BSFN calls on the ES. There's a lot of overhead in making an off-processor BSFN call. Unless the BSFN does very heavy DBMS I/O you wil be much worse off than if run locally.

But then, you a) already knew that or b) will get a better answer from the KG.

On top of insulting respected members of this forum, you first posted "I am having some performance problems " subsequently posted "I didn't ever say anything about performance problems". Duh!

For someone who has "worked with OneWorld CNC for 5 years" you give the impression of not having a clue.

Don't let the door hit you on the ass on the way out.

 

[jdel6654]

Your welcome to join the fracas. I wouldn't cry foul play unless and until you know what you are talking about.

I presume you are familiar with the W environments (WPD7333, WPY7333, etc.). Believe me when I say, I would not touch that goofy configuration if JDE had not recommended it to my clients in base B733. JDE has recommended for some time that MBFs run on the ES. Only recently has JDE backed off a bit on MBFs mapped to the server. Your not questioning me on MBFs to the server, this is standard JDE CNC. I guess Jolly knows OneWorld better than JDE? And I will tell you unequivocally on one of my OneWorld installations the fat client users prefer to run the W environments (that right WPD7333) because they run faster than the regular PD7333 envirnonment.

You say of course that C code does not call I-code, but there is absolutely no reason why C code could not call I-code. JDE is basically a totally interpretive application (I-code=interpretive code). All the kernel has to do is read in the specs. What do think UBEs do? (duh) Read in I-code from the gbrspec files at runtime. Again, C-code reads in processing options from BLOBs in F983051. It is absolutely NOT impossible for kernels to read in I-code.

You are right, in one of my previous posts I used the word "problems" instead of "issues". My mistake. To be perfectly honest, I never expected much from this post. It is like a lot of public forums, there are a few individuals that think they know everything. If you ask a very, specific pointed question, they can't answer it so they try to take it to a personal level. Hence Larry's snide remark about "mystery dude". I have no problem alienating people who make lame, snide remarks. Just like the lame comment about "the back door". Don't let this flame leave you reaching for the door.

 

[jdepro]

Re: Do Citrix Client Calling Master BSFNs Use Specs? *DELETED*

Post deleted by ekempter

 

[jdel6654]

Ah yes, when all else fails shoot the messenger....

Before the rest of you sign up for the flat earth society, read this post. I went ahead and did a search on my C code for the text jdeTAM. The system functions that API to the spec files begin with the string jdeTAM. Anyone that has seen the interoperability suite documentation or debugged a log probably has seen these APIs.

Below is some text from the C module B9200001. B9200001 is a type 2 BSFN (meaning that it can run on the ES as well as the client). It is part of the CDICT dll. This is an example of where the C code accesses the spec files at run time. If you do a search on your own C code you'll find this code.

_________________________________________________
lpTamDDDict = jdeTAMInit(FILENAME_DDDICT);
if (lpTamDDDict == NULL)
{
return ER_ERROR;
}

TAMKeepFileOpen(lpTamDDDict);

lpTamDDText = jdeTAMInit(FILENAME_DDTEXT);

if (lpTamDDText == NULL)
{
return ER_ERROR;
}

TAMKeepFileOpen(lpTamDDText);

TAMSetIgnoreFreeSpace(lpTamDDText);
lpDDText = (LPDDTEXT) jdeAlloc(COMMON_POOL,
(uint) TAM_VARIABLE_LENGTH_DATA,
MEM_FIXED | MEM_ZEROINIT);

/* Check for existence of this data item */
memset(&DDDict, 0x00, sizeof(DDDICT));
strcpy(DDDict.szDict, lpDS->szDataItem);
if ((lpDict=TAMAllocFetchByKey(lpTamDDDict, INDEX2_DDDICT,
DDDict.szDict, 1)) != NULL)
{
/* Copy the input text strings into the TAM file */

/* Row Description */
nTextSize = 0;
_fmemset(lpDDText, 0x00, (uint) TAM_VARIABLE_LENGTH_DATA);
lpDDText->cTextType = DDT_ROWDESC;
/*lpDDText->idText = lpDict->idDict; obsolete CSS NID */
for (i=41; (--i>0)&&(lpDS->szRowDescription==' ');
iEnd=i;
if (iEnd>0)
{
for (i=0; i<=iEnd; i++)
lpDDText->szText[nTextSize++]=lpDS->szRowDescription;
}
lpDDText->szText[nTextSize++]='\0';
lpDDText->lVarLen = (LVARLEN)(sizeof(DDTEXT) - 1 + nTextSize);
memset(&XText, 0x00, sizeof(XDDTEXT_2));
/*XText.idText = lpDict->idDict; CSS NID */
jdeNIDcpy(XText.szDict, lpDS->szDataItem);
XText.cTextType = lpDDText->cTextType;

TAMDeleteByKey(lpTamDDText, INDEX2_DDTEXT, &XText, 5L);
TAMAdd (lpTamDDText, lpDDText);

/*************************************************************************
* Column Headings
* The first two column headings are stored in one text record,
* with a carriage return inserted to separate them.
*************************************************************************/
nTextSize = 0;
_fmemset(lpDDText, 0x00, (uint) TAM_VARIABLE_LENGTH_DATA);
lpDDText->cTextType = DDT_COLTITLE;
/*lpDDText->idText = lpDict->idDict; obsolete CSS NID */

_____________________________________________


Yes, I know this is the data dictionary dll. Yes I know this is not the core business application. If you look at some other C modules, you will see some references (commented out) to jdeTAM functions in the business application. So it is possible. If you read my original post, my question was "does this occur" and how prevalent is it. This is the C code to which we have access, who knows what is the kernel code.

JDEPRO: Please feel free to ignore me. If my posts bother you that much after your less than full month on this forum, please feel free to shoot the messenger.

 

[DBohner-(db)]

Citrix Clients, using BSFNs do use DLL(s). BSFNs are DLL(s). DLLs are in the BIN32 directory. They may be compiled from either Named Event Rules(NERS), Table Event Rules(TERS), C code (from the Source and Include folders) or externally created.

Your questions is do the BSFN(DLL)s use specs? Not really, ER calls the BSFN and the BSFN returns answers, builds cache for later use, updates tables/cache/stuff... but the BSFN doesn't (properly) use ER... ER uses BSFNs.

ER is run on the THIN client - BSFNs (Larry can correct me) are mapped to run 'wherever' -ER isn't.

Use comes back to where they are mapped(the BSFN). Experience has shown that, though they are mapped other than on the thin client, they may use CACHE on the thin client. If you have them mapped elsewhere, you may have performance issues... Place a net sniffer between the ES and the Thin and see for yourself... If your thin clients are slow, and low on resources, your ES might be a better place... and vice-versa....

IMHO- you can ignore my rant against your aggresive behaviour if you wish:
I must agree with the others that have tried to help you - It ain't worth the air. I find it very difficult to believe that you have 5 years of experience as a CNC (you were a manager, right?)... 'cause you really don't understand the development process (what's interpretive and what's compiled).

ER is primarily interpretive - SPEC wise(in the spec folder, too). Any time a BSFN is called, you are calling a COMPILED Object (which isn't interpretive). BSFN(s) are compiled into those little (and not so little) things called DLL(s) which are NOT SPECs. ER (interpretive) can call the BSFN (Compiled). Unlikely, but possible, BFSN can call APPLs and UBEs that contain ER, but do not execute ER outside of APPLs and UBEs...

NER(s), if you know what those are - are created using ER, but MUST BE COMPILED (as a DLL) in order to work (oh, its not interpretive anymore).... TER(s) are the same way...

ER can call BSFNs, but BFSN don't call ER. BSFNs can call BSFN....

Ya have a lot to learn, and don't brag about your experience... Most of us would agree... we wouldn't want you working with us. You must be a manager (cuz you don't know what yer sayin), but I wouldn't want to work under you (kuz your people skills are lacking)...

Your initial questions was good, but then you attacked one of the KIN-Folk. That ain't a pretty thing to do... You came out against Larry (823 Post / since 11/28/00) without cause. you have a meager 23 Post / since 5/17/02... He's helped an awfull lot of us...

final question - do the companies you work for survive implementation with your help, have they gone the ways of most dot.coms?

Oh, btw, I have a meager 360( +1) post / since 1/17/01 - and I know I have a lot to learn from Larry and the others....

Daniel

No, I didn't want to ignore your posts - I did want to give you the answer you 'might' be looking for, and chastize for poor behaviour/netiquette.