OW: AS/400 Full package corruption by update package build

Hello all,
It's been a while since I've posted but I've come upon something that I
believe is necessary to communicate.

If you are on the following platform:
AS/400 OneWorld XE
SP 16_11 thru SP 17

you may experience the a problem with update packages running on the server
when UBEs/Versions are contained in the package. The issue is exhibited by
the PAKTOTAM job on the AS/400 running at 30% - 40% and never finishing.

There is a one-off for SP17 and SP17.1 on reportedly has the fix.

The risk here is to the parent package of the failed update. During the
server build process for an update package the .pak files that are shipped to
the 400 are unpacked and merged directly into the parent package. This is why
you look at the /oneworld/packages/updatepkg/spec folder and it's alway empty.
It's because it merges the objects in the update into the parent specs (check
the dates of the /oneworld/packages/fullpkg/spec files after an update package
build if you need proof).
Upon Deployment of the update package, what you are really doing is
redeploying the parent full with the newly merged update specs to the pathcode
location.

Now to the problem. The update package process is flawed in the above service
pack ranges in that it removes the tam records from the parent specs for
UBEs/Versions in the update but cannot merge the new specs in from the update
pkg. So essentially, those UBEs no longer exist in the full package specs.
If you deploy this update or any another successful update package (like one
without UBE/Versions but with BSVWs in it) or IF YOU REDEPLOY THAT FULL, you
will deploy a set of TAM files to your pathcode on the AS/400 that are
incomplete and based upon what I've seen on the log files, potentially corrupt
by way of a .xdb/.ddb correlation mismatch.

The resolution until you get to SP17.1 or beyond is to only build full
packages when you need to deploy UBEs or Versions. All other objects seem to
build fine (i.e. BSVW, BSFNS, DSTR, TBLE, NER, etc).

Just remember, if you see the PAKTOTAM run away and you have to kill it for an
update package, consider your parent package toast. Especially if you're
working with the PD7333 environment. Go for the full.

Regards,

Bruce Gilmore

Hello Bruce,

we have also been having some serious problems with update package failures. Sometimes they work and sometimes they don't! We thought initially it was UBE versions causing the problem but the problems still persisted even when we omitted them.

Latest thoughts are that when a developer removes all code (event rules) from a UBE you get a warning message when exiting RDA that links to a non-existent event is being deleted. When the update package is built and it tries to 'merge' the spec files with the parent it tries in fact to delete the GBRSPEC record which is no longer required. It is this delete action which appears to hang and subsequently the build never completes successfully.

Like you we have had to resort to full builds whilst this problem exists. We don't know for certain that this is the cause but whilst we investigate further we are advising the developers to comment out redundant code rather than deleting. If this is true then the problem may be more apparent at a site which is producing a lot of custom code where the above scenarios are more likely to occur

I would be interested if anyone else out there has experienced these kind of problems?

Regards

Andrew Holder

Xe SP16.1, AS400

We are also having the problem with update packages and have resorted to full builds in production (likely it only takes 8 hrs). The update builds do sometimes work but who wants to take a chance in production. I have been told by JDE support that there is a fix in SP17 and beyond.

For are other environment we do an update and if it does not work then we do a full build (these take 12-14 hrs).

Ellen

XE SP16.1 and all oneoffs
6 ES os/400 V5R1M0 lastest PTF's
8 Citrix
NT Deployment Win2K

On the non AS/400 side (AIX), there exists a very similar problem. Specs not being built/included in update packages. However, according to JDE our fix wasn't in place until SP18. Which we went two 2 weekends ago. Everything looks good now.

Dan Richards
Plexus Corp.
Xe, SP16.1, XU3, RS6000, Oracle 8.1.7, Metaframe XPe