|Built-in Reports|

BAS packages waiting to be aged

Submitted by scm.admin on Fri, 08/17/2012 - 20:18

Summary: List all BAS packages baselined before a given date.

Here is a real world use case of this report: a customer with about 8.500 change packages and with the package aging parm (in A.A.1) set to 365 days wanted to find out (simulate) what the effect would be of reducing this aging parm to 60 days (only!). The simulation showed that it would allow for aging over 4.500 change packages (that's more then 50 % of the total number of packages!).

Report ID:

PKGS2AGE

Report Specs:

Pkgs not aged yet / pkg archive candidates - specs

Report Variables:

The available report variable #RPTV_TIME_FRAME allows for some interesting report variations:

Using a value that matches the package aging parm (defined in A.A.1), it will create a list of all BAS packages that should have been aged already by ChangeMan ZMF housekeeping (but for some reason they were not aged yet).
Using a value that is smaller then the package aging parm (defined in A.A.1), it will create a list of all BAS packages that would be aged during the next ChangeMan ZMF housekeeping cycle (so it can be used to simulate the effect of changing value of the package aging parm).

Subject:

|Built-in Reports|

AbM SCM Solutions:

|CMN/ZMF Reporting|

ASR Category:

Audit packages reverted from production

Submitted by scm.admin on Fri, 08/17/2012 - 20:14

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.

Subject:

|Built-in Reports|

AbM SCM Solutions:

|CMN/ZMF Reporting|

ASR Category:

Backed out packages waiting revert

Submitted by scm.admin on Fri, 08/17/2012 - 20:08

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.

Subject:

|Built-in Reports|

AbM SCM Solutions:

|CMN/ZMF Reporting|

ASR Category:

Packages without DIS acknowledgement

Submitted by scm.admin on Fri, 08/17/2012 - 20:05

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.

Subject:

|Built-in Reports|

AbM SCM Solutions:

|CMN/ZMF Reporting|

ASR Category:

Planned packages created/baselined same day

Submitted by scm.admin on Fri, 08/17/2012 - 19:47

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

Subject:

|Built-in Reports|

AbM SCM Solutions:

|CMN/ZMF Reporting|

ASR Category:

Never promoted frozen packages

Submitted by scm.admin on Fri, 08/17/2012 - 19:39

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.

Subject:

|Built-in Reports|

AbM SCM Solutions:

|CMN/ZMF Reporting|

ASR Category:

Components deleted from STG without demote

Submitted by scm.admin on Fri, 08/17/2012 - 19:26

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)