Skip to Content

Missing, empty or forgotten staging libraries

Printer-friendly versionPDF version
R&D Topic
Solution ID: 
S028

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:

  • Sometimes they just disappear from the zOS catalog, even though ChangeMan ZMF did allocate them (and registered that allocation in the so called "defer bit" in CMNPMAST). That typically happens for staging libraries allocated long time ago, which have not been used for a long time anymore. In this case, it is typically some DASD management procedure that just removes them (without informing ChangeMan ZMF about that). For more details about this issue, checkout this related link: Synchronize DEV staging library list with catalog.
  • Some staging libraries are just empty. Typically because (scenario a) they got allocated during the creation of a package, but that package does not (yet) include any components for the library type corresponding to such staging library. Another case (scenario b) is where a component was staged in a package (with no other components), and then deleted from the package again.
  • Some staging libraries (or variations of it like the xNode DSNs) are not ever removed (during ChangeMan ZMF housekeeping as part of the staging libraries aging process), though the related package is in status BAS. Probably the easiest scenario for such situation is a package that was first installed in (say) 3 remote sites (which created 3 xNode DSNs). Then it was backed out and revert (because of problems in 1 of the installed sites). Then the site causing problems was removed from the list of remote sites to install the package (U7-panel), followed by a freeze/approve (which recreated the xNode DSN again, but not for the remote site that was deleted from the U7-panel). Here is the issue: the xNode of the removed site will still exist (from the previous time the package was installed). And when later on housekeeping (for aging of staging libraries) comes along it will not consider the xNode of the removed site anymore (because the site info was removed on the U7 panel also).

Reminder: if you're in a hurry (anxious) to get Dr.Chgman to deliver this item faster, consider contributing via the Z-Bounties program.