Xe ESU JD10733

[don_schoen]

Folks

Has anyone figured out what this ESU is and how it fits into the Xe Release
1, Release 2 picture?

We upgraded to Xe + Release 1 last month (there are still a lot of bugs
around), and we now have identified an ESU which incorporates over 500 SARs
from as long ago as last October, and which touches almost all of the
objects we just tested and updated.

It looks like we have to do all of this over again - does anyone have
another understanding? If these were not in Release 1 - why not? What
other batch of hundreds of SARs might be out there?

Also, it looks like there are still bugs in the hundreds being worked on.
When does the quality start showing itself?

Any thoughts on this are welcome.

Don Schoen

Xe, AS/400 Enterprise Server, 30 thin clients

 

[Carl_Fisher]

This ESU is the latest version of an on going sequence of ESU's (which seem
to be updated weekly!!) for the Procurement side, includes fixes for POs ,
receipting and accounts payable. We have applied a number of versions of
this ESU, and it keeps growing, if you have Update 1 and 2 then applying
this ESU should just update those objects which have changed since Update 2.


ESU's are cumulative - so they include all previous modifications. If you
have applied previous ESUs (or Updates 1 or 2, which are really only super
large ESU's) then the latest version only updates.

What this really means is that, as far as Procurement and A/P go, Xe did not
have it all, that a lot of objects were wrong, and that each ESU has fixed
one thing and breaks another. We currently have an outstanding issue which
is not fixed in ESU JD10733, but will no doubt be included in a later
version, expected late August. This problem was created by a SAR fix in
JD10733 (it is with Voided Vouchers, try voiding a voucher with any G/L date
other than the original G/L date and the Journal won't post - out of
balance, not all the records are created, in fact total garbage!!!). I am
sure there are other problems which JD10733 creates, so test it well.

As far as I can tell Xe was released with many problems in Procurement and
A/P (not advertised), attempts to fix it by ESU have so far been patchy, the
ESU process is flawed for major problems, it creates as many problems as it
fixes. ESU's are great for a few objects, but where a whole module is
basically poorly tested, you perpetuate problems.

It would be nice if JDE would come clean and tell us when there are major
problems with a module and do a proper analysis and a full rewrite if
necessary.

ESU JD10733 is like a doctor who fixes a major wound by applying lots of
sticking plasters, all overlapping, when blood continues to pour, he takes a
pile of plasters, overlaps them and hopes it will work, adding more where
there are gaps and he sees blood. What JDE should do is take some
development people, and look at the whole module properly, and not wait for
each SAR to fix it (what are SARs but the results of User testing.).

So the short answer is, if you use Procurement or A/P, you need ESU JD10733,
and you will probably need it's successors too!!

As a matter of interest, has anyone ever had a message from JDE telling them
that an ESU they have just applied has bugs and they need to apply a new
one? I never have, but I have seen the ESU which is now JD10733 change
weekly for the last 3 months, mainly adding fixes to fixes etc.. Why do they
insist on an email address and phone number before you can download an ESU,
when they do not use it.



OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development

 

[DBohner-(db)]

Carl,

Great waxing poetic... I have come to similar understandings - as I see
ESUs applied weekly to fix the fixes.

I did want to comment regarding JDE notification to clients. Addressing a
little tongue and cheek humor here... I would have to guess that JDE doesn't
notify its clients of each ESU due to the fact that there isn't a big enough
email server to handle the stress. When one compares the number of clients
that JDE has with the number of SARs/ESUs that go out - it would be a
difficult task to build a mail server to handle the capacity... perhaps JDE
needs to create a new mail server technology to address ESUs for their
customers.

Returning from dreamland, now.... I have spent several days trying to
understand ESUs, impact, how they update and what they could miss...
frankly I am frightened by the complexity and the number of objects touched
(300+ in some cases). I would not want to be the QC guy that has to verify
that all previous SARs/ESUs have been superceded...

My two cents...



Daniel Bohner
[email protected]
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x

 

[don_schoen]

I thought that Carl's and Daniel's responses to my question were very
helpful - but it puts a problem in perspective for me.

JDE has done a very inadequate job of building quality into their software
(the claim that all vendors are the same at this is not at all

 

[adri_valentim]

My two cents...

JDE should make the ESU's smaller. Like you said, "300+ objects". Sometimes,
it takes forever to transfer the project in OMW or even to do the backup.
Sometimes it is easier to apply the ESU to each environment one at a time
once it has been tested. If I see that there is 100+ objects, I don't do the
backup. I know this is risky but with earlier Service Packs, I have
encountered having problems with big ESU and backups. The other problem is
if for some reason the ESU fails to complete you can't restarted it.

Case in point. Last week at a client, I apply XU1 on 2 different machine (in
all 8 environments). 7 environments no problem. On the last environment, for
some reason, I got a memory violation (don't worry, I reboot the deployment
server before and after each update one, that wasn't the problem). So the
last step never ran and tried rerunning it and I couldn't but the spec merge
was successful. Called JDE, and they said, "Restore and start over". You
should be able to restart an ESU like we do an update plan or installation
plan.

If ESU's were smaller, you wouldn't have these problems.

Again, my two cents.


Adrian Valentim
Valmatrix Consulting Inc.





Valmatrix Consulting Inc.

 

[don_schoen]

FW: Xe ESU JD10733

This got cutoff last time

 

[Ritchie_]

Re: RE: Xe ESU JD10733

Hi there,

There is a way to re-apply an ESU.

look for document OTM-01-0004.

Have to make a remark however about this :
at one point it says:

"From the Software Update Environment Selection screen, press the Affected Objects button on the Exit Bar."

If I remember correctly when press the button you'll think nothing is happening but when checking the CPU usage it peaks at 100%.

For some reason this part of the process takes ages depending on how many esus and/or update1 / 2 you have installed directly into environments.

Could also be the next step in the process.

So it can be done (with a lot patience)



Richard Stam
CNC/System Administration
LIVE, B733.3 SP15, CO on AS400 Enterprise Server on V4R5 Citrix <100 users and some NT/W2K Clients

 

[Carl_Fisher]

Re: RE: Xe ESU JD10733

Daniel - I think you missed the point about email. I only want JDE to email if they are changing (Fixing) and ESU which I have already applied. After all they insist on an Email address and phone number before you can download the thing in the first place.

If they are not going to tell us that we have just applied potentially dangerous code (and some of the earlier versions of this ESU had plenty of that), then why bother!!!!

OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development<P ID="edit"><FONT SIZE=-1>Edited by Carl_Fisher on 7/9/01 04:27 AM.</FONT></P>