We would need developers to be able to DEMOTE a package from a second promotion level even though they were not authorized to PROMOTE it to that environment Has anyone come across this scenario? Have you been able to give it any alternative, any solution?

Hi, good morning.


We would need certain users (developers) to be able to DEMOTE a package from a second promotion level even though they were not authorized to PROMOTE it to that environment.

The point is that in ChangeMan ZMF it is a single RACF entity that manages both functions/actions (PROMOTE/DEMOTE). And while for the PROMOTE it is necessary for the QA team to pass certain controls and checks before executing the PROMOTE, if the tests in that environment by the developer teams determine that some component of that package must be modified again (which is audited and frozen) it would be necessary not to have to ask again, or depend on, the QA team to do the DEMOTE.

That would be the objective, not to depend on the QA team, which is the one who does the PROMOTE to that environment, in order to DEMOTE it.

Has anyone come across this scenario? Have you been able to give it any alternative, any solution?

Thank you very much.
Best regards.

  • Verified Answer

    Hi Oscar,

    Logically that is a difficult requirement/concept for ZMF itself to handle.

    Both the promote and demote functions will obviously have an effect on the content of the testing environment. In a simplistic model, the situation you describe could lead to a developer removing a component from the test environment whilst the QA team are 50% through execution of their test plan. This could, in turn, lead to confusion, at best, and potentially to completely invalidating all testing and causing production problems if other checks and controls are not also implemented alongside this. So, as you correctly state, the product is certainly working as designed in this area to ensure that a single team or group of users have control over the contents of the test environment.

    However, if you definitely have this requirement, and if you also have other checks and controls in place to cover the potential problems covered above, have you looked at the HLLX routines as a possible way of implementing your requirements?

    For example, you could

    a) grant both QA and the developers UPDATE access to the promotion security entity

    b) then allow or deny the promotion or demotion request based on the specific requirements that you would have implemented in one or more of the PRDM* HLLX points.

    Obviously you would need to ensure all of your user interfaces are covered by the selected HLLX(s) but, in theory at least, this may give you what you need.

     I hope this helps and gives you something to work with.

    Best regards,

    Steve