Header and source files not always copied into pathcode when applying ESU.

Hello, List.

I install several ESUs at once. Then I build full package. It finished with errors on compiling stage. I look build.log file and see that two problem objects in CINSTALL have 150 errors (Some data structure and other was undefined). I check include files and see that file is very old (It must be replaced when I install other ESUs previously - I check reports for that ESUs: spec merge for that objects successfull, all other successfull). All ESU was applyed successfully, but not for all affected objects header and source files copied into pathcode directiories. It happens for several ESUs not for all.
Have anybody any idea?

No ideas but we've seen the same thing and with ASU's too - with ASU's we're currently having to force the inclusion of all objects in the update manually.

Richard,

I'm not sure that I underst you correct. You say when you apply ASU/ESU software update application doesn't select all objects and you force selection manualy or you say not about that?
When I apply ASU/ESU then in some cases OneWorld doesn't copy .c and .h files even for affected objects (in other cases it copied).

What we get is two types of situation which may or may not be related.

First, when applying an ASU, JDE decides it's not going to merge some of the objects (possibly because it believes the already installed version is more recent for some reason). Note that this happens with objects that have changed - I'm not worried about it not merging them if they're unchanged and have only been included in the ASU for completeness.
To get past this we use the affected objects exit in the software updates app and then used the advanced exit in that to change status to force them to be merged. Then at least we get the objects on the deployment server.

The second situation we get is, I think the one you see. Objects are loaded - new .c and/or .h exist, we build a package to include the objects BUT the makefile, or whatever, ignores the new .c and just re-links with the old object files. We end up with an update package without the modified functions (for example). I haven't yet been to determine where the real problem lies. I had thought it was related to a difference in sate stamps between source and object files (after all with ASUs and ESUs the source may have been programmed weeks before it reaches us and if we've done an update which touches the dll for other reasons more recently maybe the makefile is deceived?)

However, that might tend to indicate that the only way to be sure of including any changes would be to touch ALL the source and header files before each package build and I have a feeling that might just push up package build times to a length we wouldn't want to see.

Hope that clarifies a bit what I was trying to convey.

It isn't a first case. The problem cause for objectst that was affected for merge.
But it happens before package build. In several cases OneWorld doesn't copy new .c and .h files from ASU/ESU into path codes on Deployment server during aplying ESU. As result - package build failed (then I copy new files from ESU into path code by hands - package builds normally).