|CMN/ZMF Release Management Dashboard|

Printer-friendly version PDF version

Audit packages reverted from production

Summary: List all packages installed in production for a while and reverted afterwards.

About such packages:

Report ID: 
AUDRVPRD
Report Specs: 

Audit packages reverted from production - specs

Report Variables: 

Because of the nature of this report, it doesn't have/require any report variables.

AbM SCM Solutions:

Backed out packages waiting revert

Summary: List all packages installed in production and backed out afterwards, but not yet reverted to DEV again.

This is a variation of packages reverted from production (checkout this link for more background info about such packages). Both reports are about packages that have been installed in production and then backed out again, but the major difference (nuance?) between both reports is related to the selection criteria used to select packages, which is either:

Report ID: 
QUEUEREV
Report Specs: 

Backed out packages waiting revert - specs

Report Variables: 

Because of the nature of this report, it doesn't have/require any report variables.

AbM SCM Solutions:

Packages without DIS acknowledgement

Summary: List all packages distributed to production, but for which some handshaking data seems to be missing.

After a package is fully approved, CMN/ZMF will automatically take care of getting it activated in production (optionally taking into account all sorts of extra requirements, e.g. related to the requested package install date/time).

Report ID: 
NOACKDIS
Report Specs: 

Packages without DIS acknowledgement - specs

Report Variables: 

Because of the nature of this report, it doesn't have/require any report variables.

AbM SCM Solutions:

Planned packages created/baselined same day

Summary: List all planned packages baselined on the day they were created.

A planned package that was baselined (= installed in production) on the same day that it was created? Seems like something is wrong with the "planning" here. Or is it maybe because such package creators are looking for ways to not show up on the radar(s) related to unplanned packages?

Report ID: 
PKGBASPL
Report Specs: 

Planned packages created and baselined same day - specs

Report Variables: 

The available report variable #RPTV_START_DATE allows for limiting the list of packages to only those created on or after a specific date (e.g.: the date the release management process was introduced ?).

AbM SCM Solutions:

Never promoted frozen packages

Summary: Visualize the applications with FRZ packages that have never been promoted to any promotion target.

A frozen package implies that the package is waiting approvals, and ready to be shipped to production. It's a common business practise to only allow package in FRZ status to be promoted to the highest level(s) of promotion (like to a QA environment). But if a FRZ package has not ever been promoted to any promotion target, what environment would have been used to for unit testing or integration testing?

Report ID: 
PPNOPRM
Report Specs: 

Never promoted frozen packages - specs

Report Variables: 

Because of the nature of this report, it doesn't have/require any report variables.

Report Output: 

Never promoted frozen packages - output (chart)
This graph shows the number of such FRZ packages by application, it seems like there are a few applications that are worth further investigation (about which environment they use to perform their actual testing). By swapping the APPL and PKG CREATOR data the graph reveals similar data by package creator ...

Note: the above graph was created by asking for saving the report in basket format (a kind of CSV format), and then downloading or eMailing the report output to a workstation. On the workstation it was opened in a spreadsheet application that accepts CSV files to read from, after which some standard graphing features where applied to build the chart.

AbM SCM Solutions:

Components deleted from STG without demote

Summary: List all components deleted from staging without a prior demote from one or more promotion levels.

Report ID: 
PCDLNODM
Report Specs: 

Components deleted from staging without demote - specs

Report Variables: 

Components deleted from staging without demote - report variables
Specifying values for report variables can be done using the edit vars feature, for which two options exist:

  • option P will bring up an ISPF pop-up panel (as illustrated above). Using this option, the values entered can be validated using any of the available ISPF panel validation techniques (even ISPF panel exists should that be required), which adds another dimension to the power of report variables.
  • option I will invoke the standard ISPF editor. Checkout orphan component promotion history for an illustration of this option.
Report Output: 

Components deleted from staging without demote - output (XML basket)

AbM SCM Solutions:
Subscribe to |CMN/ZMF Release Management Dashboard|