ZMF: Take the Vanilla Challenge



The flexibility to customize ZMF to meet your user's requirements is one of the great advantages of ZMF.  This flexibility also introduces additional complexity as you upgrade ZMF from release to release.  Customer feedback tells us that forward fitting your customizations to a new ZMF release is a significant part of every upgrade project.  At xChange 2015, we hosted a 'best practices' session on this topic which received positive feedback on the recommendation to 'take the vanilla challenge'.  For those unfamiliar with my use of the term 'vanilla', it means 'as delivered' or 'out of the box'.  The challenge for you, is to to investigate your customizations and eliminate those that are unnecessary.

So, what are the items to consider as you attempt to minimize your customizations?

What our Customers are Telling Us

Let's start with some assumptions which we have discovered while working with customers over the past few years.

  • Forward fitting customizations is the largest upgrade effort
  • Customers have been very creative in customizing ZMF delivered code
  • Customizations are often propagated forward into new releases without consideration of the need
  • Large teams of ZMF administrators are shrinking
  • Original authors of the customization may no longer be available to help understand the initial requirement
  • Many ISPF customizations are not usable by other ZMF clients, such as ZMF4ECL and ZDD
  • Off platform integrations to ZMF are increasing, highlighting the need to have a common work process across all ZMF clients

Reducing Customizations to Simplify Upgrade Projects

So, how do you go about reducing the volume of customizations?  You may be thinking 'this is going to add additional effort to my upgrade project'.  While that is true, it is a one time cost which will reduce your upgrade effort down the road.  Here are some things to consider to help you decide whether to forward fit a customization. 

  • First of all, you have to identify all of your customizations.  ZMF customers are very good at isolating customized components away from delivered (vanilla) components, so you should be able to gather an inventory of your customizations.  These are typically in ISPF panels, skeletons, and exits.

Investigate each of these customized components and answer these questions:

  • Why have we customized this?
  • Is it still needed?
  • Does it still bring value to my company?  Or was it implemented years ago to appease a few vocal users?
  • When I introduce off-mainframe interfaces to ZMF, can this customization be implemented there too?
  • Do I know what it is actually doing?  Or am I simply copying it forward without consideration?
  • Can the requirement be implemented another way?
  • Is the customization covered by changes in the base product as new features and enhancements are delivered?
  • Does the benefit outweigh the cost of maintaining the customization from release to release?
  • Can it be implemented in a release agnostic HLLX (High Level Language eXit) point?

Once you have answered these questions, you can make an appropriate business decision about whether or not it should be carried forward in the new release.  I know a few of you are thinking, 'I don't have time for this extra effort because of tight project schedules'.  Am I right?  Let's take a look at a customer that has undertaken this exercise.

A Customer Upgrade Story

A ZMF customer that has been supporting ZMF for 10 years was frustrated with the effort to forward fit  customizations from release to release.  They had numerous customizations around Ideal, promotion, and many others.  During the upgrade, the company was abandoning Ideal, thus requiring the elimination of all of those customizations.  They took the opportunity to investigate all of their customizations and return to vanilla where possible. 

The exercise allowed them to identify customizations which were obsolete due to changing business requirements, those that were obsolete due to the evolution of ZMF, and those that were required to support a valid business process.

The benefit?

  • It was a one time cost, which has simplified subsequent upgrade projects.  The effort extended the project from roughly 3 months to 4 months, but subsequent upgrades have been much quicker.
  • The exercise allowed them to analyze each of the customizations.  For those that were carried forward to the new release, each customization was fully documented to minimize the investigation on future upgrades.  I.E. if the customization remains, there is a valid business need for it, and it is clearly documented.
  • As a side benefit, the effort simplified the interaction with Serena Customer Support.  Prior to 'going vanilla', the customer and Serena Customer Support would spend a lot of time trying to understand what the customization was doing in order to diagnose an issue.  Now, the customer can tell Serena "this is your delivered code, it's not a problem with my customization".


ZMF 8.1 is a perfect opportunity for you to 'Return to Vanilla'.  Many new features and enhancements have been delivered in previous years which may eliminate the need for your legacy customizations.  Did I mention HLLX?  Off platform integrations to ZMF are growing across Serena's customer base.  Your ISPF customizations are often not visible or usable by these off platform clients, making it difficult to deploy a common work process across ISPF and the off platform clients.  HLLX, delivered in ZMF 8.1, is the answer to this challenge.  To learn more about HLLX, take a look at Steve Downes KBTV video titled 'My First High Level Language eXit'.  Why not take the time to investigate your customizations with an eye towards removing those that are no longer valuable to your business?

As always, we encourage your feedback.



How To-Best Practice
Comment List