Prod FULL package and best practice

Thanks again gents.

So what you're saying is it really depends on what's in the ESU and not so much on it's size?
Although I'm a bit surprised that if an ESU had an increased .h DSTR that the ESU doesn't then include all the other .hs that reference it. (I used to do a find in files in C++ and redo the typdef for them all and add to the same OMW)

Yes, that was my point - that it really depends on WHAT is in the ESU (as well as every day packages) that should determine if a full is required. I doubt that if a .h file definition changed they (Oracle) would include everything that referenced it - in some cases it becomes a very recursive task to find all true dependencies. Besides even if an ESU did have all referencing objects it certainly wouldn't have any of your custom objects that may reference the changed .h file definition.

....and Brian, Shaun of the Dead, obviously ;)

LOL. In the end I think I would have to agree.
 
Brian,

well I guess its a matter of Trust. I trust that Oracle does in fact do what they seem to do in including ALL affected objects in a ESU. If I'm wrong someone please tell me so - but failing a detailed examination of their ESUs that does seem to be their practice from my perspective.
 
But what if you have custom objects (BSFNs C or NER) that reference changed BSFN data structs for example. Your code would need to be recompiled.
 
I was curious. Using my very first example (D4200310F) I found the latest ESU (JL19248 - a Baseline btw) for my apps release that has that data structure listed.
They added the following parameters:

MATH_NUMERIC mnTaxedUnitPrice;
MATH_NUMERIC mnTaxedExtendedPrice;
MATH_NUMERIC mnUnitTaxAmount;
MATH_NUMERIC mnExtendedTaxAmount;
MATH_NUMERIC mnForeignTaxedUnitPrice;
MATH_NUMERIC mnForeignTaxedExtendedPrice;
MATH_NUMERIC mnForeignUnitTaxAmount;
MATH_NUMERIC mnForeignExtendedTaxAmount;
JCHAR cTaxedPriceOverrideCode;
JDEDATE jdInternalSOTaxDate;

In just a few minutes I found the following objects that use D4200310F but are NOT in the ESU:

N4900960
b3104160
b3200790
b3200791
b3201590
b3201790
b3202370
b3202890
b32c0060
b4202290
b4202520
b4204050
b4204100
b4204200
b4205030
b4205110
b4205150
b4205170
b4205195
b4205220
b4205250
b4206010
b4206020
b4210060
b4277712
b4500300
b4500540
b4502340
b4601310
b4700110
b4700900
b49t0040
 
My experience has been the same as Larry's. Some things may change, but not be used by some BSFN's. I've been doing this almost 15 years and have never had this issue installing an ESU. I wouldn't expect Oracle to list my changed/copied objects, I do that analysis myself.

But this is possibly part of the cause of the Data Structure too short message that often shows up in the logs. The message is an Info only one though.
 
So can we just all agree that a Full Package is the best practice no matter what ? I recently had someone try and use this very thread to justify why they "didn't need to do a full package" - and, of course, spun their wheels trying to troubleshoot an issue - when a full package completely resolved the issue.

IF IN DOUBT, BUILD A FULL PACKAGE - it's a LOT faster than trying to spend a week troubleshooting....

Damn those developers who think they know CNC ! (JK)
 
Damn those developers who think they know CNC ! (JK)

Oh, the way I do a full package is with an email to my CNC guys telling them I need a full package (of course they think I am just trying to torture them). :)

I do know what a full package does (and what an update does NOT do) and I do know what a segmentation fault is and what causes it. Actually I think it is very important for developers to understand what a build does (and does not do) and I think it is very important for CNC to understand exactly what the effects are of a C code change and how it relates to the C compilation portion of the build.

My only point is there are times when a full build is absolutely required. And I do mean required. Not some optional thing that's good to do but you can skip if you want like defragging a DB index or something.
 
I do know what a full package does (and what an update does NOT do) and I do know what a segmentation fault is and what causes it. ...

Actually Brian - yes you do. Your answer was extremely concise and correct and answered fully exactly why the original poster needed to perform a full package.

I wasn't directing my joke comment to you - but to those Developers who do NOT know the difference between an update and a full package ! (I actually failed to realize you were a development manager/developer !!!)
 
You're right Jon and Brian, and ...

I'm a lazy developer who hates the idea of rolling out full packages every time there's a change.

But I'm NOT a CNC and should defer to those who are <bowed head>.

Cheers Guys
 
Brian,

you destroyed my trust in Oracle. I will no longer believe ANYTHING that Larry Ellison says anymore :-(

Seriously though thanks for the analysis. You totally changed my mindset on ESUs.
 
Jon, sometimes tone gets lost on message boards. I didn't take your joke as a dig at me... and even if it was I can take a joke.
 
you destroyed my trust in Oracle. I will no longer believe ANYTHING that Larry Ellison says anymore :-(

LOL. Well that wasn't my intent. Actually Ellison just needs to tweak his package build process to restore all of our unwavering trust - a way to do an update but still perform a full BUSBUILD. Or at least some sort of official (well thought out) best practices document that really details some of the stuff discussed here.
 
Well this has been interesting, thanks for all the useful info guys :)

Obviously the CNC guys here will say they need to do a full package every time a developer so much as sneezes, as it keeps them busy and makes them look important ;)

Meoooow....Saucer of milk for table 2, lol

Also a joke before anyone gets upset :)

If a full package is needed then that's fine. I've not seen that applied on my travels before, so thought I'd ask.

If an ESU introduces a new element in a DS and an older object calls the new object but does not map anything into the new element (as it's code and response doesn't care about this new element), surely it's just a warning and not a full blown error?

It's only when the functionality DOES need the response and function of that new element that JDE would include those objects into the ESU...?

I'd be interested to see the number of CNC guys here who do perform a Full build for an ESU, vs those who don't
 
If an ESU introduces a new element in a DS and an older object calls the new object but does not map anything into the new element (as it's code and response doesn't care about this new element), surely it's just a warning and not a full blown error?

It depends on the calling object. If the calling object is an APPL or UBE then there isn't an error or even a warning - no harm no foul. If the calling object is a BSFN (NER or C) then it absolutly will cause an error - an extremely bad one. It can result in a buffer overrun and then a call object kernel crash. You may be confusing the warnings you see in the jde.log due to a change to a processing option template data structure and not recompiling the C code with the updated PO typedef. There is a C api to retrieve processing option values. This C api has a size parameter so it can bound check the passed buffer before writing to it. If it doesn't match the PO data structure size defined in the specs it throws these warnings in the jde.log. This is a benign warning and will NOT cause a buffer overrun or really any other error - its just annoying. This is NOT the same thing as a change to a BSFN data structure and failure to recompile C code. These buffer overrun errors happen at the OS level (in the case of a memory violation) or it results in corrupt data in memory.

Maybe we need a "lab" or simple example to illustrate.
 
Back
Top