The package aging parm is a number of days (set in global admin) that a package should be in BAS status (installed in production) before the meta data of that package (VSAM records stored in CMNPMAST) are allowed to be removed during ChangeMan ZMF housekeeping. The higher this number of days, the more people like IT auditors will like it (they are often the ones who are asking for such high number of days). While many countries have laws that force such data to be kept for (e.g.) 7 years, or even more ...
Staging libraries are the data sets related to a change package in which ChangeMan ZMF stores its changed components. Together with the meta data of the package and the components in it (both stored in ChangeMan ZMF control files like CMNPMAST), they actually constitute the change package. And the ChangeMan ZMF started task (server running on the mainframe) will take care of managing all such staging libraries: they get created (by ChangeMan ZMF) whenever they are needed, and they get removed during housekeeping, after the package became INS/BAS.
Here are some issues about these staging libraries:
A checkout is used to get a copy from the current production version of a component (or variations like the previous version or the upcoming nearly-GA version), so that you can start a new version of it. But what about all those checkout requests that happened long time ago (a few days, weeks, months or years ago), and which are still in the same checkout status (= creating a new version of it has not yet started yet)?
A change package is assumed to contain changed components and/or scratch requests (in 2 decades we have not ever found 1 ChangeMan ZMF customer that's using the rename function, so let's skip that one). Fine, but where do those empty (= no components + no scratch requests) packages come from?
Change packages follow a life cycle, starting from the creation of it, up to the installation of it into production (and optionally followed by a backout it needed). That's the theory, and also what happens most of the time.
However consider some change package that was created by some ChangeMan ZMF user, whereas such package is not yet installed in production (not BAS yet). What happens with such package if the ChangeMan ZMF user quits the company (variation: moves on to another job within the company)?
Each change package is assumed to be installed in production (and change its status to INS/BAS) some day. The date entered during package creation is the actual planned install date. But with package update (U7) you can change it again, typically to shift the date to some other (later) date. The idea of that is that it allows you to change your initially planned date (during package create) to somewhere later on. Because while the package content is being developed, it turns out that the date that was originally scheduled is too early. So far no problem ...
ChangeMan ZMF 5.3.x (available since 2003) was the first release delivered with a very rich set of functions that allows you to perform many (though not all) tasks in ChangeMan ZMF without using ChangeMan ZMF's ISPF client (to communicate with the ChangeMan ZMF server, aka the CMN started task). This set of functions is commonly referred to as "ChangeMan ZMF's XML services" (for short: the "XML services").
Anybody knows this issue, which is about all non-BAS packages that have a planned installed date that's somewhere in the past. It's entered on the last panel to create a package, or updated via the U7 panel.
We've been providing consulting services about ChangeMan ZMF (CMN/ZMF) for over 2 decades now. It keeps being fun to see how each CMN/ZMF customer always has some type of unique requirements, special customizations, etc. Not to speak about all the challenges that come with each release upgrade of CMN/ZMF (I started on release 3.2.1b in 1990, recently I was involved in an upgrade to the latest and greatest 7.1.x release).
ChangeMan ZMF 5.3.x (available since 2003) was the first release delivered with a very rich set of functions that allows you to perform many (though not all) tasks in ChangeMan ZMF without using ChangeMan ZMF's ISPF client (to communicate with the ChangeMan ZMF server, aka the CMN started task). This set of functions is commonly referred to as "ChangeMan ZMF's XML services" (for short: the "XML services").
We've been providing consulting services about ChangeMan ZMF (CMN/ZMF) for over 2 decades now. It keeps being fun to see how each CMN/ZMF customer always has some type of unique requirements, special customizations, etc. Not to speak about all the challenges that come with each release upgrade of CMN/ZMF (I started on release 3.2.1b in 1990, recently I was involved in an upgrade to the latest and greatest 7.1.x release).