The Evolution of ChangeMan ZMF (Part 1)



“Evolution not revolution” – Have the changes and upgrades made to Serena’s mainframe software change and configuration management solution, ChangeMan ZMF, been an evolution or a revolution? The ZMF development team has been cranking out new features over the last couple of years: fully integrated Java support (including Impact Analysis, Audit, Build, ISPF, Eclipse, zDD, XML and Web services); HFS and zFS support for Development, Staging, Promotion and Baseline libraries; a new Eclipse Plug-in that combines Rational Developer for z (RDz) and native Eclipse capabilities, as well as the ZMF Client Pack (which includes the Eclipse Plugin and ChangeMan zDD).

These enhancements, combined with everything done in ChangeMan ZMF v6, would make it easy to assume “revolution”. But let’s take a step back and trace the history of ZMF and how it has evolved over time.

Change Man vs. ChangeMan

In its earliest carnation, ZMF (which was then called Change Man) had many of the same constructs — the package orientation (which was pioneered by Serena) and a package lifecycle — so, in many ways it looked very similar from the outside. However, on the inside it was quite different. For starters, it was purely an ISPF-driven application. Hence, there was no started task, just ISPF users serializing on the VSAM package master, log and delay files while the physical artifacts were moved or copied as appropriate.

With Change Man gaining traction in the market and higher customer adoption, the product found that it was hitting the upper bounds of the workload it was capable of managing under the then-current design. In subsequent releases, the product ran as a started task where MVS facilities such as ECB lists, Cross Memory Services and the Subsystem Control Table (SSCT) allowed better coordination and multiple instances of the product, therefore allowing for higher concurrent usage while maintaining data integrity.

Then came Sernet, the underlying architecture which was introduced to facilitate all session, program, data and storage management, a subsystem interface, and a communications layer that allowed for cross-platform communication. As things moved forward, most of the heavy lifting done by the user (which in those days were TSO and batch) were beginning to get done on the server side. New features such as Remote Promote were added in addition to a new API set known as Remote Procedure Calls (RPCs). The RPCs allowed for an interface to ChangeMan outside of the usual ISPF interface, however, it was still a very data-driven API. It relied strictly on DSECTS and correct data mappings, so data structures had to map out accordingly.

Name Change to ‘ChangeMan ZMF’

With v5, ChangeMan ZMF emerged. The name, ‘Change Man,’ became ‘ChangeMan’ and ‘ZMF’ was added. In v5, most of the processing was moved from the client side to the server side. A new API set was introduced, which was then known as the Extended Services. Functions that previously existed in the ISPF programs were service enabled, which modularized the code base and allowed for code reuse. Extended Services were reworked into what is now known as the XML Services. No more sensitivity to offsets, record layouts and pairing of DSECTs to data structures. With XML’s extensibility, the user no longer needed to be concerned with offsets changing from release to release. The XML Services are the basis of what are now ChangeMan ZMF’s Web Services although the XML Services remain in use as well. Version 5 is also where ERO, LBO, cross-application support for auditing and IA and WD4ZMF were all introduced.

In my next post, I’ll go through the evolution of ChangeMan ZMF v6 and v7. Let me know what you think about ChangeMan ZMF and write a comment below!

Share this post:
Tweet about this on TwitterShare on FacebookShare on LinkedInGoogle+

Leave a Reply

Your email address will not be published. Required fields are marked *