Associate User-Selected Package Approval Level(s) with Package Audit Requirement

by Ron Palaniuk on September 19, 2017

Resolve issues with installing ChangeMan ZMF packages that end-up having Audit out-of-synch situations because time has passed.

  • This particular issue has been around for a couple of decades, and we should look at resolving the issue to get around this particular “hole” in the ChangeMan ZMF software lifecycle.

    Here is the scenario:

    • You have a ChangeMan ZMF Package 1 that has Component A that was changed as part of a long-running project.  Package 1 was Audited successfully and Frozen, and then goes to, say, INTG testing for several weeks.  No additional changes end-up getting done to anything within Package 1, hence no reason for any additional Audits of Package 1.
    • While INTG testing is being done of Component A, a production maintenance change needs to be done to Component A.  So Package 2 is created.  Component A has the minor change done, and for whatever reason the developer does not notify the owner of Package 1 of this maintenance change.
    • Then Package 2 is Audited successfully, Frozen, and Installed into production within a day or two.
    • The owner of Package 1 would have had a “checkout conflict” TSO message flash by on his/her screen, but (s)he would have likely missed it when you end-up pressing function and/or the Enter keys in quick succession.
    • When the owner of Package 1 installs the project’s change into production, then the change from Package 2 gets accidentally regressed in production.

    Granted, we can implement (and have suggested implementing) a manual processes so that the final approver (or close to the final approver) has to submit a package Audit to ensure that there are no last-minute Audit errors.  However, anything that is manually done can be forgotten and missed.

    With regard to a design to get around this issue in ChangeMan ZMF, we are flexible.  But here is an idea:

    Maybe R&D can implement a Last Package Audit Date/Timestamp field that is stored as part of the ChangeMan ZMF package metadata.  Within Global Admin (which can be overridden in Application Admin), one can specify (1) which approval level number(s) must have a Package Audit be run before an approval can be done, and (2) how old the Last Package Audit Date/Timestamp can be until another Package Audit has to be run before the next approval level associated with a Package Audit requirement can be done.  If nothing is specified in one or both of these new configuration items in admin, then ChangeMan ZMF would act just like it has been with the scenario described above.  (As an aside, I suppose that this age-based requirement for Package Audit can also be applied to packages that are in DEV status that were Audited, say, 2 months ago.  In this situation, it is possible to freeze a package in DEV status with an Audit RC=00 from 2 months ago that now has a version regression situation that could go undetected.)

    The reason to have the ability to specify one or more approval levels that are associated with a Package Audit requirement is to take into consideration situations when a package may be in FRZ status while in QUAL and then INTG testing.  Testing could go on for months, and things can change in just a few days (if not hours).  If, for example, there was a Package Audit requirement prior to giving approval to promote to QUAL, and also an Package Audit requirement prior to giving approval to promote to INTG, and then finally a Package Audit requirement prior to giving approval to install into PROD, then one could avoid out-of-sync conditions earlier in the testing part of software lifecycle, and even eliminate them before going to PROD---even if the package stays in FRZ status (without any changes via selective unfreeze) for several months.

    As far as being able to quickly “eyeball” which ChangeMan ZMF packages’ Audit RCs are too old (or “expired”), maybe within the CMNLIST3 panel the “Aud” field could have a different color (e.g. red) indicating that the Audit RC has expired and a Package Audit needs to be re-run.  Of course, any package in BAS status would not have a different color, even after the age-based Package Audit criteria has expired.

    It was mentioned to associate an approval level number with a Package Audit requirement.  Thinking about it more, it may make more sense to associate the Package Audit requirement with an approval security entity.

    I do realize that the above idea still does not resolve the situation in which a package has had all its approvals done, and the package sits in APR or DIS status for days, weeks, or even months before production installation.  By then, something could have changed that would result in a package out-of-synch situation as far as Audit would be concerned.  I’m not sure what we could do to get around this, but at least being able to “eyeball” which ChangeMan ZMF packages’ Audit RCs have expired that are in a different color (such as red) within the CMNLIST3 panel would be helpful.  I suppose that something can be implemented where if anyone tries to reference the package through option U1, S2, BB, QP, etc., then a “PACKAGE AUDIT EXPIRED” ISPF message could be displayed as a warning.  This particular message would definitely show-up for packages in APR or DIS status, and maybe a Global and Application Admin setting can be created that would also show this message for packages in other non-BAS statuses (which I can see some users complaining about getting that message quite often...but for a critical application, this might be acceptable).

    Ideas

    Tags
  • Please login to view any attachments.

  • There are no user comments for this idea.
    Already have an account? or Create an account
     

PrintEmail