It takes quite some effort to ensure (verify) that for each ChangeMan ZMF application all DSNs defined as promo-, prod- or baseline DSN are allocated (with the appropriate LRECL, etc), and if not get them allocated. Not doing so will cause promotion and/or installation jobs to run into JCL errors (DSN not found) or system abends (because of invalid DCBs). Wouldn't it be great if you could automate this labor intensive task and reduce/simplify the required effort to just migrating a (special) change package which, on the fly, verifies and allocates all appropriate DSNs?

Here are some situations where this issue comes up:

•  When you define a new application (you'll have to allocate at least all DSNs that are not shared with any other application, while for shared DSNs the other application 'should' already have allocated the DSN before).
•  When you add a new promotion level or production site in various applications (for which you want to ensure that all DSNs for this new target are defined).
•  When you add a new library type (for which you want to ensure that all corresponding promotion, production and baseline DSNs are defined).

Here are some related advantages that come with such approach of just migrating a change package to complete this task:

• Creating an audit trail about when exactly, and for which promotion / production sites, such verification and allocation was performed (all you'd have to do is query the package history for the latest (special) package).
• Having a straight forward, easy to use, facility to recall all migrated datasets of a specific application (e.g. to prepare a training application that hasn't been used anymore for a while and for which you don't want training participants to be waiting for recalls of any DSNs during audit, promote, install or baseline ripple).

Well, believe it or not, but there IS a way to automate this process (dramatically), as documented in the Z-Clues (login required).

Note: AbitMORE SCM Commander also comes with a builtin solution that uses a different approach and which is based on all sorts of XML services, and with (a) facilities to target either a single ChangeMan ZMF application or all of them in one shot, and (b) optionally combined with only targeting a single (remote) promotion and/or production site. Even (Abit...) more: if TCP/IP is enabled, everything can be done (triggered) from the originating DP-site. Do the math: what if you have 100 ChangeMan ZMF applications, and want to add 1 promotion target (site or level), with (e.g.) 5 library types with each of them a real promotion DSN and a corresponding shadow DSN ... 100 appl X 1 prmtarget X 5 ltps X (1 promDSN + 1 shadDSN) = 100 x 1 x 5 x 2 = 1.000 entries ... Have fun doing this without any automation ...