gerd_renz3
VIP Member
Yes, this is confusing! And does JDE-suport always have the right answers?
No, surely not.
My point of view is close to what brother_of_kara is writing.
When you build an Update package the parent package's SPECs and bin32 do get
updated. One will have to recompress the parent package to install it with
the update together. That works fine technically.
Now, what about ESU's and dependencies? Let's say there was a change in a
table or as data structure (DS...) defined in an dot-H file. You would have
to recompile ALL BSNF's that include these dot-H files. If you build an
update package you would have to include ALL objetcs that are touched by
these changes. I would never trust that development has put all these
objects into the automatically created update package.
If you have an ESU with just one BSFN or just a couple of programs and
reports you might be able to do the cross-referencing yourself. But not with
a couple of hundred objects!
What about the "mark-all-checkboxes" that boaterdan mentioned? If you are on
B7332 or less it comes with the "delete-output-first" box unchecked by
default, in Xe it is checked. Why is it important to check this box after an
ESU-update?
Let's say there was a change in F123 . So there is a new f123.h file. You
would have to recompile ALL BSFNs that include f123.h . Now, Busbuild is
using the make tool (nmake for Microsoft). The make tool compares the
timestamp on B0000xyz.c with the one on B0000xyz.obj . If the dot-obj is
newer, it will not recompile B0000xyz.c, even in a full package . But what
if B000xyz.c includes f123.h ? You will get tons of memory violations. And
who has not seen them after ESUs?
The error lies in the simplyfied busbuild architecture. If you say
clear-output-first, it will simply delete all dot-obj files and the
make-tool is forced to call the compiler for ALL BSFNs.
So, yes, after a big ESU, I would always build a full package, with
clear-output-first checkbox marked!
I explained all this once to a very good response line consultant (oh yes,
there are some). He listened for about have hour and I think he understood.
But even those R/S-guys have trouble to report things up to the gods of
development. But let's see the positive side: the clear-output-first
checkbox comes checked by default in Xe and maybe they will get their
make-tool and ESU acts together in B9.
Thanks for your patience reading all this,
Gerd
B732 through Xe, NT, Unix, JAS, etc.
No, surely not.
My point of view is close to what brother_of_kara is writing.
When you build an Update package the parent package's SPECs and bin32 do get
updated. One will have to recompress the parent package to install it with
the update together. That works fine technically.
Now, what about ESU's and dependencies? Let's say there was a change in a
table or as data structure (DS...) defined in an dot-H file. You would have
to recompile ALL BSNF's that include these dot-H files. If you build an
update package you would have to include ALL objetcs that are touched by
these changes. I would never trust that development has put all these
objects into the automatically created update package.
If you have an ESU with just one BSFN or just a couple of programs and
reports you might be able to do the cross-referencing yourself. But not with
a couple of hundred objects!
What about the "mark-all-checkboxes" that boaterdan mentioned? If you are on
B7332 or less it comes with the "delete-output-first" box unchecked by
default, in Xe it is checked. Why is it important to check this box after an
ESU-update?
Let's say there was a change in F123 . So there is a new f123.h file. You
would have to recompile ALL BSFNs that include f123.h . Now, Busbuild is
using the make tool (nmake for Microsoft). The make tool compares the
timestamp on B0000xyz.c with the one on B0000xyz.obj . If the dot-obj is
newer, it will not recompile B0000xyz.c, even in a full package . But what
if B000xyz.c includes f123.h ? You will get tons of memory violations. And
who has not seen them after ESUs?
The error lies in the simplyfied busbuild architecture. If you say
clear-output-first, it will simply delete all dot-obj files and the
make-tool is forced to call the compiler for ALL BSFNs.
So, yes, after a big ESU, I would always build a full package, with
clear-output-first checkbox marked!
I explained all this once to a very good response line consultant (oh yes,
there are some). He listened for about have hour and I think he understood.
But even those R/S-guys have trouble to report things up to the gods of
development. But let's see the positive side: the clear-output-first
checkbox comes checked by default in Xe and maybe they will get their
make-tool and ESU acts together in B9.
Thanks for your patience reading all this,
Gerd
B732 through Xe, NT, Unix, JAS, etc.
