“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!
|Al Slovacek joined Serena in 1995 and has functioned in a variety of technical and management roles including ChangeMan ZMF development. He currently serves as Senior Director of Mainframe Products. Prior to Serena, Al was a developer of a variety of mainframe products ranging from z/OS performance management, storage management, VSAM optimization and compression. Prior to this he worked in IT as a Systems Programmer specializing in mainframe performance analysis, tuning, installation and configuration.|
Very Excited to see Part-1, Looking forward for Part-2.
All technical information we can find in Dumps, these information very little rare until… Product owners reveals.
What do you feel were the trade-offs made in moving from an RPC based access to an XML based one ? How did you approach XML’s inherent verbosity in the move from one technology to another?
@Satyasai – Thank you.
@Camille – There were several benefits to making this move:
- An industry-accepted standard method of integration is beneficial over a proprietary API.
- Abstraction. A process layer that reconciles tags with the underlying construct resolves the data-driven API issue, where customers and users need to be concerned with layout/offset changes and field deprications.
- The RPCs were constructed in such a way that effectively caused the entire product to be recompiled even for the most innocuous changes.
So there was so much benefit in this move that there weren’t any tradeoffs to speak of. It was all upside. Verbose, yes, but also much more granular levels of control.
Great recap Al ! It reminds me about the late 80s when I started with CMN 3.2.1b (when even CMNAPI, CMNAPI2 or CMNRPC2 were not born yet). I’d like to add my favorite ZMF quote to it, which is: “XML services in CMN/ZMF is the best that ever happened to CMN!”. It is what allowed us to create our XML based add-on to CMN/ZMF also.
[...] Evolution of ChangeMan ZMF (Part 2) By Al Slovacek on Wed November 9, 2011 9:29 AM In my last post I took you through the history of ChangeMan ZMF during the time it underwent several name [...]
May I ask if there is any company using ChangeMan ZMF in Hong Kong ? If so, could you let us know the company name?