All issues have been resolved.
I placed an ISPF dialogue in the USER MENU to make it easier for ENDEVOR users to run the report for any particular package with missing input components. The first panel prompts for the move from stage, and the second panel prompts for all of the package ID, starting with the package ID for the package with the missing input components, followed by the package ID of the packages that should be moving those input components to the next stage. The top portion of the JCL with the entered package information is file tailored, the rest of the JCL is appended, and then the JCL submitted.
I also use the report to get the complete current input component status diagnoses for all of the packages that are moving from a particular stage. Sometimes a package casts without missing input components but the subsequent package that moves from the next stage fails the cast with missing input components because the using elements have caught up to the input components in the migration path. The promotion package SCL history output DD needs to have a large size allocation when there are many packages.
This report makes it possible to mitigate various risks when the packages using updated input components and the packages moving those input components are different, such as deploying elements to production that are using updated input components that they should not be using, deploying to production using elements without also deploying all of the matching input components, and failing to identify all of the prerequisite packages.
It can be time consuming the maintain the report JCL for all of the packages moving from a particular stage. I do not know if it is possible for this report program to be enhanced so that it automatically processes all of the packages regardless of the from stage, automatically changing the relevant settings (in particular the PATHINIT) to match the from stage. We may then need two reports, one that diagnosis a particular package with missing input components and the other that automatically diagnosis "all" of the packages (that match one or more wildcarded package ID).
------------------------------
[FirstName]
------------------------------
Original Message:
Sent: Dec 13, 2022 09:13 AM
From: Joseph Walther
Subject: Unpackaged input component report
Please confirm that all issues are resolved. The adjustment for promotion packages and any future changes will be made at this location.... https://github.com/BroadcomMFD/broadcom-product-scripts/tree/main/endevor/Multi-Package-Reporting-and-Validations
.
Original Message:
Sent: Dec 06, 2022 01:17 PM
From: Mathew Goldstein
Subject: Unpackaged input component report
The current version of the report has a flaw. It identifies false positive unpackaged input components when promotion packages automatically update to change the move from stage. Since it is possible to retrieve the historical SCL for promotion packages it should be possible to eliminate this flaw, but I think the correction may require a substantial recoding of the report.
------------------------------
[FirstName]
Original Message:
Sent: Dec 03, 2022 06:45 PM
From: Mathew Goldstein
Subject: Unpackaged input component report
ENDEVOR validates input components for a single package. A non-packaged input component can be a multiple packages context problem. This problem needs to be addressed procedurally because ENDEVOR lacks a built function to address this problem. Broadcom worked with me to create a new unpackaged input component report found here https://github.com/BroadcomMFD/broadcom-product-scripts/tree/package-reporting/endevor/Multi-Package-Reporting-and-Validations
Unpackaged missing input components indicate a genuine problem that needs to be remedied one way or another before proceeding with the package (the remedy varies depending on the details and context). There is a practical need and benefit to suss out whether or not missing input component(s) are in another package and to try to ensure that you are aware of, and taking into account, the cross-package dependencies when you schedule package executions. This new report that I solicited assists with addressing both problems. It was primarily authored by long time Broadcom employee Dan Walther (I coded the PriorACMQStages procedure and provided some code fixes and enhancements, including introducing PATHINIT).
SET EXPORTDS='A FB 80 partitioned data set name'
SET ENVIRON=<YourEnv> <-From Env
SET STAGE#=<1 or 2> <-From Stage number
SET CIRCLRC=5 <-RC when finding circulars
SET PATHINIT='<Env1.Stg# Env2.Stg# etc>'
The JCL contains the above SET statements. The PATHINIT above represents the final stage(s) in the relevant migration path(s) where an ACM Query will find an input component and may depend in part on the ENVIRON and STAGE# values. The STEP1 TABLE DD reads the package ID that you entered for the packages that code the specified ENVIRON.STAGE# move action from stage.
New related idea "multiple package component validation" https://community.broadcom.com/idea/multiple-package-component-validation