• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

OCMs in Server Map

gerd_renz3

VIP Member
.Hi List,

I have a question about OCMs in the Server Map.

The J* and W* environments usually have default mappings for UBEs and BSFNs,
pointing to an application server, so all UBEs and BSFNs (except for a few)
are executed on the server. These mappings are kept in the OCM table in the
system datasource, used by clients, as well as WTS and JAS, which
essentially are OW-clients as well.
The app-server has it's own set of OCMs, stored in the Server Map. My
question is: do I need OCMappings in the server-map for UBEs and BSFNs,
pointing to the app-server itself?
We had a specialist here from GATS (JDE Global Advanced Tecnology Services)
who recomended these mappings. On our question he said: I am not sure
either, but we have it this way in Denver and we recommend them! (Not a very
satisfying answer!). Some BSFN mappings were set to LOCAL in the server-map.
What is LOCAL for a Unix app-server?
So, listers, please help me! What sence does it make for a server to tell it
to call all BSFNs within itself? After all, if there is no mapping at all
(not even a default mapping) for a BSFN or a UBE, it gets executed right
there from where it is being called. Does a server have a mechanism, like a
OW-client, to send out a BSFN to be executed on another server?
If I am not mistaken, there are no such mappings in original installs. In
our case, they do not seem to hurt, either.

Thanks for any input,
Gerd
Xe, SP16.1, AIX app-server, AIX JAserver
 

altquark

Legendary Poster
Don't do that.

If there is no BSFN mapping or UBE mapping in the OCM - then it will default to local (ie the platform where it was being called from). This GAT's "Expert" will have performance issues in his/her configuration.

Lastly - NOTHING SHOULD BE SET TO LOCAL in the Server Map. LOCAL is actually a hard-coded datasource name for the Clients. The server will not correctly understand what "LOCAL" is.

OH - and for all those listening intently to GAT's recommendation to use the "W", "J" and standard environments based on the client type being used - my question is WHY ? What happens if a used logs into a "J" environment in a Citrix session ? What happens if you have a user log into JPD7333 and one log into WPD7333 and they get different information on their screen ? What is the purpose of having a bazillion production environment mappings ? Look out for another scathing whitepaper on running by this little issue in the real world....


ERP Sourcing
http://www.erpsourcing.com
cto@spla.sh
 

adri_valentim

Reputable Poster
I personally don't agree with the W environments. I have not got a good convincing reason to use W environments. WTS are usually big servers which can handle the heavy processing of 30-40 users. Why create exact network traffic to run business functions on the enterprise server and also maybe overload the Enterprise which is already processing all UBEs.

How many times has this happens. It works fine in CRP but does not work in WCRP. Then you find out that there is a Business Function mapping that is incorrect. Does anyone have the correct mapping for the W Environments?

This is just my two cents. Please feel free to disagree.

Adrian Valentim
Valmatrix Consulting Inc.
 

SSAJAROFF92

Reputable Poster
Adrian :

I agree, W environments are a pain in the worst part of your body.
I also had lived those unforgettable experiences of trying and
retrying these BSFN mappings.
Finally, I prefer to use plain standard environments and forget W's!

Sebastian
 

hotm6654

Well Known Member
I asked myself the very same questions when they first came out with the W environments in 1998. Since I am not a JDE user (I just install and fix the stuff), I never paid much attention to it. Last year I was doing an implementation and observed trying to import to the a part list grid. From the non-W environment the I/O went floppy disk to memory to OneWorld grid (asychronous JDE editing). It took forever to import 250 lines. However when the logged into a tse environment (using a fat client or a citrix session), that same operation was extremely fast. The I/O on the Citrix TSE session went from floppy disk to memory to network I/O to Citrix server memory to OneWorld grid to AS/400 memory for editing. It was tens of times faster than the regular JDE environment. GO FIGURE!!!!!! All of our fat client users now log into the W* environments.

Even with that much more I/O, that same process was multiple times faster with BSFN's mapped to the enterprise server. One of the things that just blows your mind about CNC.


JD Nowell
OW: B7332
ES: AS400 V4R4 CO: DB2/400 SP: 11.2
Users: 250 TSE Users: 100
 

Jack_Crouch

Well Known Member
I with you guys on the W environments. HOWEVER... we recently brought up some big Advanced Pricing users and Sales Order entry performance with WPD7333 environment is 15 seconds an order versus Minutes per order using straight PD7333.

Huge difference. Enough for us to take the plunge on the big W.

So we tried a "new" W mapping from JDE and struggled awhile... best approach is to basically map EVERYTHING to the ES except the documented BSFNs that cannot run there.

It has been working pretty well so far.

AS400 V4R5, XE+XU1+35ESUs, SP16, NT-SQL7 for CO
 
Top