Applying ESUs

lessardj

Well Known Member
We would like to know if Xe users apply ESUs to their Pristine path code. If not, do they start with DV and promote through PY and PD? And, if you have time to answer, what are the reasons for your strategy?

Thanks in advance for any answers!

Xe, SP 15.1, Update 2, ES=AS/400 V4R5, CO=AS/400, Deployment=AS/400 INS Card, Thick & Citrix Clients
 
We leave pristine alone. We apply ESUs to DV, PY and PD. Response line will sometimes have clients try to reproduce an issue in pristine just to make sure that the clients' mods and/or ESUs hasn't caused the issue.

C Ho
Intermediate Programmer/Analyst
Xe SP 15.1, update1
AS/400 V4R5 coexistant
CO on SQL 7.0 SP2 + hotfix
 
I should also add to this question the issue of applying updates (as in
Update 2) to Pristine. Thanks again.



Xe, SP 15.1, Update 2, ES=AS/400 V4R5, CO=AS/400, Deployment=AS/400 INS Card, Thick & Citrix Clients
 
John :

I don't apply ESU to Pristine, because it's supposed to be a static
environment where JDE could eventually reproduce bugs.
I start on DV, and then promote to PY and PD.
Nevertheless, I've always been doubtful if Xe Updates (Update1, etc)
should be installed (or not) on Pristine.

Sebastian
 
Yes, we apply ESUs to pristine (JD7333).

I don't understand why people think they should not update JDE code with JDE updates. If I am running XE with Update 2 applied and I have customizations I need to check my problems against pristine code AT THE SAME LEVEL in order to determine if my customizations are at fault or not. Even JDE remasters their product with each Update. ESUs should follow the same rule if I am attempting to determine if my code or JDE's code is at fault.

The following is a quote taken from document OTM-01-0063 on the knowledge garden:

"Also, the pristine environment is many times not thought of as a valid install place, however, the recommended procedure is to apply any ESUs or ASUs to the pristine environment to provide a place for JDE pristine code to reside for testing. This will allow for clients to test the ESUs or ASUs outside of any customizations that are in their development or production pathcodes. "

One thing to remember, if an ESU causes a problem, it is not the "Client's" ESU, it is "JDE's" ESU.

'Nuff Said,


Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials
 
Larry :

You gave me an excellent argument to install Updates and ESUs on the
Pristine environment. I've been quite doubtful on whether to install
them or not there.
A little question : Could any of you build a full client Pristine
package?

Sebastian
 
Re: RE: Applying ESUs

Hi Sebastian,

In answer to your question we just built a full pristine package (Client and Server) 2 weeks ago. Both client and server have been successfully deployed. Why do you ask?



Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials
 
We do not touch Pristine, this allows us to prove to JDE that it was an ESU
that messed up our System.

As we only have a small amount of Modification we apply ESU's into PY, test
then promote to PD.

We have only four environments:

JD (Pristine) - JDE Base Code, JDE Test Data, no Modifications or ESU's
DV (Development) - JDE Base Code, Our Test Data, Set up as per live
Environment, no Mods or ESU's, we use this to identify Set vs Application
problems. We also apply ESU's here when we have problems - to compare Modified and Unmodified code, with the ESU, in case it is our modifications which cause the problem.
PY (Prototype) - JDE Base Code + ESU's, Our Test Data, our Modifications.
PD (Production) - JDE Base Code + ESU's Tested, Our Live Data, our
Modifications Tested.



OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development
 
I would disagree with the approach, yes apply Update 2 and any other
Official release of JDE to Pristine, but not ESU's.

ESUs are not always fully tested, and it is good to see where the ESU has
broken standard JDE code, we have had to rely on this frequently, as without
proof that it is the ESU which causes a given problem, it is hard to get JDE
to fix it!

I agree that it is good to have a 'Standard' JDE environment with ESU's but
no Mods, again to prove it is the ESU that is the problem not your Mods, if
you do any modification you need to be able to prove to JDE that it is the
ESU that has failed.

As a small shop we use DEV for applying ESUs on Standard JDE, and only do
our Mods in CRP (PY).

If you have a lot of Mods, I would recommend an additional environment,
between DEV and CRP, where your mods start life.




OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development
 
I think both the for and against arguments have merit.

JDE may or may not be testing your problem on a system that has your ESU's applied. In past versions (B7332, etc.) it was almost always the case that they were working on a pure pristine system. They often could not duplicate your issue because you had applied a "paperfix" or ESU that introduced a bug or "feature".

In past situations I have advised clients who have the disk space to create a Prist-Plus environment that included ESU's. Of course the drawback is an additional path code to maintain. We found this outweighed by our increase ability to track down ESU-related problems.

Recently it seems that response line has been getting there systems kept more up to date. They now appear to be testing on a Pristine + Cumulative/major ESU platform. So you are probably safe applying cumulative ESU's to Prist.

I guess at the end of the day it really depends on how involved you plan to be in resolving application issues yourself. If you feel that JDE will not help you because you have touched Prist then leave it alone or create a Prist-Plus path code and get the best of both.

Regards,



Justin Miller
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX
 
Back
Top