View Only
  • 1.  Cross Package Dependencies

    Posted Feb 22, 2019 01:20 PM

    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)?

  • 2.  Re: Cross Package Dependencies
    Best Answer

    Posted Feb 22, 2019 02:15 PM

    Hi John..


    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 



  • 3.  Re: Cross Package Dependencies

    Posted Feb 23, 2019 10:28 PM

    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.

  • 4.  Re: Cross Package Dependencies

    Posted Feb 25, 2019 09:22 AM

    Hi Joe! 


    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...  

  • 5.  Re: Cross Package Dependencies

    Posted May 07, 2019 08:31 PM

    I like the idea of cross-package dependency capability. This seems like a simple solution. Perhaps Package Type Sequence

  • 6.  RE: Cross Package Dependencies

    Posted Oct 11, 2019 10:23 AM
    John as a reminder you can build the Batch Package SCL to execute the packages without utilizing the option "​Multiple Jobstreams".  Then you can define both packages and the 2nd one wont execute unless the 1st one is complete (without baby sitting).  However, it would not stop the 2nd package execution if the 1st package failed,  that I can remember.


    [Software Engineer]

  • 7.  RE: Cross Package Dependencies

    Posted Oct 14, 2019 11:19 AM
    John, you know me, I always code my way out of these issues. We have similar special processes, and the final step in our processor is to submit the special process. So, in this case, you could have a simple Rexx that is executed at the end of your processor to check a cntl table for the next process - 'submit batch SCL to execute the next package'.

  • 8.  RE: Cross Package Dependencies

    Posted Oct 19, 2019 01:56 PM
    Edited by Mathew Goldstein Oct 19, 2019 10:13 PM
    A control table that automates subsequent package executions could be helpful. However, sequencing subsequent package executions is not what is needed. What is needed is a way to prevent premature execution of packages that are dependent on not yet successfully executed packages. Without an enterprise package, a package pre-execute exit that reads a package control table to identify the current package's pre-requisite packages and verify that they were all successfully executed would probably be needed.​