W environment

hi,list

we use oneworld b7332,and we have 2 product environment:
prd733 and wprd733.
i know that wprd733 is used for the WTS ,
but our wprd environment is bad,cant be use,.
i have asked the consultants,they say we can use prd733 on WTS.
is that right?what is the different between the 2 environment ?
any help will be appreciated.

bee[blush]

Hi Bee,

Your consultant is right, you can use the PRD733 on WTS. With the WPRD733 environment the Business Functions are mapped to your enterprise server instead of local.

Disadvantage: Jdedwards does not recommend this but I have used it in the past. It could be slower especially if you are using advance pricing.

Adrian,
could you please explain this further!?
I have a client running Xe on AS/400 and Citrix clients. We had serious
performance problems with P4210 (SOE) using advanced pricing. We were
able to *improve* SOE-performance mapping the BSFNs to the AS.
Why would that slow things down in your oppinion?
Thanks, Gerd

The difference between the 2 environments are the Object Configuration Mappings (OCM). On terminal servers (W environment) business functions are mapped to run on your as400. The non-W environment business functions should default to the local processor (for fat clients that would be your pc, for terminal servers local is the terminal server). SO if everyone used prd733 on the terminal server all your business functions would be running from the terminal server hence degrading performance and possible corruption of objects.

The 'W' environment has JITI turned off. This is suppose to improve performance.

Hi Gerd,

I don't know why but I was told (by someone on JDELIST) that this is the main function that for some reason needs to be on the enterprise server. Maybe someone else can answer this question.

per JDE they recommend not using W environments and I have implemented =
many Citrix and Terminal Services without W.

However, from fat client, run the R92TAM and R98CRTGL for full data dict =
specs and full global table specs (environment specific) and copy to =
X:\B7\PD7333\spec location to avoid jiti corruption



Trish Sutterfield
Cell 678-576-6201
[email protected]

Re: RE: W environment

hi,trish,
do you mean u run R92TAM and R98CRTGL from a fat client and copy
the specs to the Terminal Server?
could i run the that directly on the Terminal Server (of course when no user use it )?

RE: RE: W environment

Can't run UBE's locally on terminal servers

Trish Sutterfield
Cell 678-576-6201
[email protected]

Gerd,

<<performance problems with P4210 (SOE) using advanced pricing.

We also had performance problems, still do from the users standpoint, our
advanced pricing has several 100 steps per line so not much we can do about
it. The reason things take longer when not mapped back to the ES is
because of data movement. If you are moving a lot of data across the lan,
no matter how fast it is, it is slower that a local read. You want to map
your BSFN's near their data, wherever that is.

Another function we were having problems with was supply & demand. The
users were processing about 3M records in this function (bad selection
criteria), it was taking 50 min to come back. When we mapped S&D back to
our AS/400 this dropped to about 51 seconds, with the same selection
criteria. The users now select only about 1M records and get a response
in about 20 seconds.

Hope this helps.

Tom Davidson
XE U1 & 700+ ESU's; AS/400; CO on SQL 7; W2K TSE Citrix Xp.




OW 7332 SP 11.3VER, NT 4.0 SP 5, TSE 4.0 SP 4, Metrframe 1.8, CO SQL 7.0

Re: RE: RE: W environment

hi,trish:

because our Default UBE is local,our terminal users always run the UBE locally.
now i'm serious about it.can u say it more,why can't run UBE locally on Terminal Server?

thank you .

bee

Re: RE: RE: W environment

You can map the UBE in OCM to run "LOCAL"

when you run the UBE, it will run on the Terminal Server.

Theres no reason why you cannot run UBE's locally on a Terminal Server - no reason whatsoever anymore.

Under B7322 there used to be an issue - but a service pack fixed it even on that version.

However, don't plan on running GL Post or some nasty UBE on your terminal server - it'll suck all the performance out of the machine to the detriment of other users - AND like all locally running UBE's, your PDF won't be accessible all the time in a citrix farm (with multiple Terminal Servers).

Bee - you're fine.

We started using W Environments but gave up, we found there were some BSFN which had performance issues on the Enterprise Server, but could never pin it down.

We now use the none W environments with no issues.

We have Terminal Servers to the JDE Minimun Spec and to be honest most of the time they do very little work.

I note earlier comments about network traffic. This has not been a factor for us, we specifically placed our Terminal Servers close to the Enterprise Server, both Geographically (same room) and on the Network, with dedicated 100Meg LAN.

This is not too expensive for a Farm of Servers, and improves performance dramatically.

The main problem with the W environments is that the BSFN were originally written for a Client Server environment, and do no always behave well when run on the Server. I think some improvements in more recent Service Packs (especially SP20) for HTML clients, will also help W environments as the issues are the same, for HTML clients you have to run BSFN on the Enterprise Server.

In the end what performance you get and what set up you need is unique to your site, it depends on your LAN/WAN, what Enterprise Server you have, what spec of Terminal Servers, number of users, mix of applications, and so on.

If you have specific problems then look for the bottleneck and try to open it up.

In fact, there are 2 ‘sub-types’ of W* environments.
One ‘sub-type’ that was shipped with OneWorld Xe out-of-box (Sep 2000) had about 300 (400?) business functions mapped to enterprise server and all other bus functions were mapped to the client (LOCAL datasource) by default.
Sometime after that, JDE folks have changed their mind, and now they recommend to map all business functions to the ES by default, and only 200-300 specific function should be mapped to the client.

We started with 1st type of W* environment, and, eventually switched to the 2nd type.
The problem is that there is no ‘ideal’ set of mappings. When we asked JDE to send us their current set of OCM for W* environments, we found out that mappings for at least 4 BFs were making problems, and we had to change these mappings. The funny part of it is that these 4 issues are described on JDE Knowledge Garden. So it looks that some people in JDE don’t know what other people in JDE are doing.

I am saying ‘at least 4’ because we are not using HR/Payroll, we are almost not using Distribution, and don’t use all possible application in Financials and Manufacturing.
So I believe that our mappings are not 100% error free.

As to performance issues, we didn’t mention any speed degradation after switching from type 1 to type 2 mappings, but we don’t use advanced pricing as far as I know.
On other side, we didn’t mention any significant performance improvement

As to UBEs – we always had them mapped to the Enterprise server in W* environments, so I can’t say anything about performance difference.


By the way, W* environments are not purely Citrix environments; it also makes sense to use them on Fat clients, especially if network speed is not ideal.


Yaroslav Mudrenko

Xe, XU1, SP16.1, HP-UX 11.11, Oracle 8.1.7.1
W2000/Citrix Metaframe 1.8a.