“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 the planning phase of version 6, and with the growing popularity of Web Services, we could no longer assume that requests coming into ZMF were simply from TSO users as in the past. With product integrations, web service calls embedded in application code, and initiatives for Release Management and Orchestrated ALM, many requests were coming into ZMF and we needed to again address scalability. Along with a growing backlog of customer-driven enhancement requests that could only be achieved through major architectural changes, the time certainly arrived for the architectural overhaul of ZMF.
Sernet was redesigned to better accommodate the volume and diverse types of requests coming into the system. With this redesign, we moved away from 32K chunking/chaining to a continuous data stream. Redundant and obsolete code that was more relevant in previous releases was removed, and particular focus was placed on scalability and error recovery.
Impact Analysis (IA) was redesigned to reside in a data space and stored in a Linear Data Set when the task is down. Benefits of the redesign of IA :
- To improve performance.
- To expose XML/Web Service enablement to our customers.
- To position for Java support (which came in v7).
- To accommodate the new unlimited component history capabilities.
Promotion was enhanced to accommodate renames and scratch requests; the addition of a promotion scheduler was added, too.
Component Meta-data Rewrite/Expansion
Customers, particularly in the financial sector, have the requirement of maintaining unlimited component history. Previously, only 24 levels of component history were maintained. With the arrival of each new version, the 24th was pushed off the stack. ChangeMan ZMF Version 6 supports unlimited numbers of component history; it also accommodates variable length records and allows the storage of user meta data and/or parameters.
Today, more application development is being done off the mainframe to reduce costs and because new developers prefer to work in the environment of their choice. ChangeMan ZMF supports a variety of these development environments. For several years, Serena has offered ChangeMan zDD, which provides a Windows Explorer view and has worked very well for many of our customers. Other developers prefer to work in IDEs, such as Eclipse. We’ve provided WD4ZMF (WebSphere Developer for ZMF) and an Eclipse plugin allowing access into ZMF using WDz. Most recently, we introduced the ChangeMan ZMF Client Pack, which combined zDD, an Eclipse plugin that allows for native Eclipse access to ZMF, and a plugin for IBM Rational Developer for z/OS (RDz) – the rebrand of WDz.
In addition to this support for off-platform development, Serena aligned with the trend to support the large increase in hybrid application deployments — use of Java, XML and Web Services. This not only maintains its leading position with regard to managing legacy assets, but also provides ChangeMan ZMF governance for modern application development on the mainframe, including:
- Full Java support tightly integrated into the product, including build, promotion, audit, and impact analysis.
- Support of native file systems: HFS/zFS, which includes full support for 255-byte file names and 1024-byte path names within the product. This includes Development, Staging, Promotion and Baseline libraries.
- PDS/PDSE is still supported as well for legacy components. This support was incorporated into not only zDD and Eclipse, but into ISPF and all service interfaces as well.
While we have never expected ISPF to be the interface of choice with Java programmers, you never know. So, all of the appropriate panels have zoom capabilities to show the full names (in accordance with ISPF standards).
I mention this because this is where the Evolution vs. Revolution discussion is important. Support for the new trends of mainframe modernization (IDEs, deployment of hybrid applications, management of modern languages and file systems) built upon a quarter-century of stability, rigor and integrity. Like rings around a tree.
The ChangeMan ZMF team has been busy! We had 3 major product releases in the last 4 years with 9 maintenance releases across 3 versions. It’s a continuous effort to balance investment in the existing feature set with addressing customer enhancements and aligning with the market — all while ensuring the future of ChangeMan ZMF.
