How does your site handle "cross package dependencies"?
Let's say I have 2 packages.... one package (PKG1) contains all the copybooks and the second package (PKG2) contains all the programs. I'm going to execute PKG1 a few days before PKG2 because I have a limited window.
How do you (at your site) ensure PKG1 has completed (aside from physically looking) before kicking off PKG2?
IMO, Endevor is missing the ability to "link" packages such that you can specify pre-req packages and post-req packages; a dependency of package-to-package, if you will.
Or am I just stating another case for the resurrection of Enterprise Packages (Resurrect/Redefine Enterprise Packages)?
Are you familiar with Type Sequencing? Since that has become an option, a few releases ago, we have latched onto defining the sequence a package will Add/Upd, Move, Delete or Transfer elements.
So to answer your question, we don't waste time creating multiple packages. Everything is thrown into a single package and things like Copybooks, control statements, CICS maps, etc are first in our type sequencing before 4GL, so they are always added first regardless where they are in the SCL.
Don't forget to also have fun with CAP when you're moving very large package. Another feature we use that makes it unnecessary to use multiple packages
We have package dependency issues. There are common input components and there are input/output dependencies between different applications. Currently, we require a memorandum that includes information on dependencies. This requires advanced coordination between developers, including reserving their package ID for future use. We are planning to add another pre-production stage to queue packages so that they can be executed together in related bunches. I do not know if, or how, this issue is addressed by competing products. A mechanism to link together promotion packages so that they must be executed together as if they were a single package (co-requisite) or in a fixed sequence (pre and post-requisite) relative to each other is an interesting idea.
I'm intimately acquainted with GTS and CAPS. Making "larger" or making a single "large" package is not really an option at this time. Our scenario is more like Mathew's; a very large pool of common elements, an extremely large pool of copybooks, followed by another large pool of COBOL, CICS maps, and DB2 Binds.
Mathew, I'm going to add your mechanism comment to my original idea... although I may repost it again as "new" since CA/Broadcom unilaterally decided it was not worthy originally...
I like the idea of cross-package dependency capability. This seems like a simple solution. Perhaps Package Type Sequence