Let's understand Mainframe
Home Tutorials Interview Q&A Quiz Mainframe Memes Contact us About us

Module 2: ChangeMan Packages


ChangeMan- Packages

A package is the unit of change in ChangeMan ZMF. Instead of moving individual programs to production, you collect every component of a change - source, copybooks, JCL, DDL - into one package, and the whole package moves through checkout, audit, approval, promotion and install together.

Simple vs complex packages

  • Simple package - one change, one application, installed as a single unit. This is the normal case: a bug fix or enhancement for the PAYROLL application.
  • Complex package - a parent package that groups several child (participating) packages, usually across applications. Use it when one business change touches PAYROLL and BILLING together and both must install at the same time.
  • Each participating package in a complex package still goes through its own checkout, audit and approval, but they install together.

Creating a package - panel walkthrough

  1. From the ZMF Primary Option Menu (CMNPRIM), select the Create option.
  2. Enter the package name (site convention, often 6 characters, for example PAY001) and the application mnemonic.
  3. On the Package Creation panel, fill in the description fields: package title, requestor name and phone, department, work request number.
  4. Choose the package type: S for simple, C for complex.
  5. Enter the planned install date and time (when the change should go to production) and whether the change is temporary (temporary changes are automatically removed later).
  6. Press Enter to create. ZMF allocates the package staging datasets, one per library type.

A typical package creation panel looks like this:

ChangeMan ZMF - Package Creation Package name . . . . PAY001 Application . . PAYR Package title . . . Payroll tax table update 2026 Requestor . . . . . J.SMITH Phone . . . . . 555-0142 Department . . . . PAYROLL Work request . WR-45231 Package type . . . S (S=Simple, C=Complex) Install date . . . 2026 10 20 Time . . . . . 02:00 Temporary change . N (Y/N) Removal date . ________ Implementation instructions . . . Install during the nightly batch window. Restart not required.

Package description fields explained

  • Package title - a short business description of the change. Approvers read this first.
  • Work request - links the package to the change ticket in your tracking system.
  • Install date/time - when the scheduler should run the install. Must be a future date; the site calendar may block weekends.
  • Temporary flag - Y means the change is backed out automatically at the removal date (used for one-off fixes).
  • Implementation instructions - free text for operations: restart requirements, special steps, contacts.

Adding components to a package

  1. From the package menu, select Components to open the component list.
  2. Use the add function and enter: component name (member name, for example PAY1000), library type (SRC, CPY, JCL...), and the compile procedure (language, for example COBOL2) for sources.
  3. For an existing program, mark it for checkout: ZMF copies the current baseline member into your staging dataset and locks it.
  4. For a brand-new program, add it as a new component: ZMF creates an empty member in the staging dataset for you to edit.
  5. Repeat for every component of the change: sources, copybooks, load modules, JCL, procs, DDL.

Participating packages (complex packages)

  • In a complex (parent) package, use the participating-package function to attach the child package names.
  • Children must belong to their own applications and each follows the full lifecycle: checkout, audit, freeze, approve, promote.
  • The parent installs only when all children are approved and ready; they install together in one install event.
  • Use complex packages sparingly: they are harder to back out than simple packages.

Package memo and documentation

  • The package memo (long description) explains the business reason for the change in plain language.
  • Write the memo for approvers and auditors, not developers: what changes for the business, what was tested, what the risks are.
  • Attach any supporting notes (test results, rollback plan) in the implementation instructions or memo.





© copyright mainframebug.com
Privacy Policy
MainframeBug Assistant