b_gilmore
Well Known Member
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
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