Creating the Future by Slashing Complexity

Mainframe users have a problem: finding people with the right skills to service their mission-critical systems. It isn’t language: learning COBOL and PL/I is relatively easy.  The difficult part is understanding the logic of systems built by programmers who retired years ago.  Some mainframe users have elected to redevelop their systems yet this is risky and expensive, partly because nobody now understands the old applications and partly because one can’t always be certain that different technology can service the performance and concurrency requirements of these mission-critical applications. 

And does anybody really believe that converting an MVS/COBOL system to UNIX/Java simplifies it? 

Experience suggests otherwise. The definition of a legacy system is “Any system that has been successfully implemented”.  Will the legacies of the future be any easier to maintain than our old COBOL systems?  They’re even more complex, so future problems will be worse.  

COBOL legacy systems written when mainframes dominated computing still manage most of the world’s commerce, yet new programmers consider mainframes obsolete, and few learn COBOL. While mainframe hardware has continued to advance and mainframes can handle large loads at lower cost, the software environment has stagnated so that mainframes are still programmed in essentially the same way as they were 30 years ago, even sometimes with 3270 emulators.  This is not attractive to a new generation of programmers who expect the convenience of Visual Studio or better.   In the meantime, systems have become more complex as more and more layers are added to get information from System A to System B and back, with A and B being different technology communicating through common but complex technologies like WSDL and JSON.

If we’re to solve problems now and in the future, we must acknowledge the elephant in the room – system complexity – and reduce it dramatically. 

Consider any business system, in any technology.  Only a tiny fraction of its complexity relates to the actual business problem.  Almost all of its complexity is caused by the solution, in other words the complexity of the code required to instruct the technology (COBOL, Java, WSDL, whatever) to implement the business logic.  Make a minor error with the COBOL or WSDL and your web service fails with an incomprehensible message!  To reduce complexity we need software that takes business rules out of procedural logic and puts them into the schema, and reduces procedural logic to a bare minimum.  As the title of C.J.Date’s 2000 book states, “What Not How”.  Date’s solution was a SQL-based language, but as I recall this was still quite complex, and didn’t seem to extend outside the world of relational database.  Besides, I’m not aware of any implementation of Date’s ideas.

Never-the-less “What Not How” is a powerful idea that software products have used since we moved beyond Assember.  In the ‘80s the hot topic was “4^th Generation Languages” which allowed one to write a program with much less code than with COBOL and CICS.  You could say that the implicit message of a 4GL was “Tell us what you want to do, we’ll work out how”. 

Most 4GL’s were interpretive, although our Fujitsu MANASYS software, successfully marketed by Fujitsu in their mainframe market of the 1980’s, was unusual in being a COBOL generator.  As a COBOL generator it was more open-ended: if you could almost do what you wanted in MANASYS but needed a little bit of COBOL-level logic then extension was easy.  In contrast extending an interpretive 4GL with a little bit of COBOL or Assembler could be practically impossible.  On the other hand, a disadvantage of our approach was that if your program failed, instead of a high-level run-time message you could find yourself having to interpret a COBOL dump.

Invariably, 4GL’s were integrated with a particular software environment, for example the Natural 4GL worked with the ADABAS database.  Our product MANASYS was tightly integrated with Fujitsu’s AIM DB/DC.  This provided a communication layer (like CICS and IMS/DC) and both CODASYL and Relational databases.  Close integration avoids errors, for example our software could discover the layouts and access rules from existing Database and COBOL information, as could Natural from ADABAS and so on.  But it also means that a 4GL’s success is tied to the success of its underlying platform. By 1990 mainframes were losing their dominance, and our sales dried up as Fujitsu’s AIM environment lost market share.  I transitioned my company into Windows development, we became a local niche-market leader, and I moved on. 

It came as a surprise when, in 2012, I was contacted out of the blue by a previous MANASYS user: “Do you have an IBM version?”  He had liked the “What, not How” design of MANASYS so much that he’d been using it as a design language in IBM projects!  I discovered that the IBM mainframe was far less dead than I’d assumed.  But the world had changed.  Development within z/OS is not simply within the “MVS environment”.  Communicating with both local and cloud environments was now vital, and to deal with an increasing number of standards more and more layers had been added.  None of this simplifies things.  More than ever we need “What, not How”.

This was a challenge I couldn’t ignore, so from 2013 Jazz Software Ltd has been developing MANASYS Jazz.  The modern Windows environment has allowed everything to be re-thought, providing more powerful language and tools than with the earlier MANASYS Fujitsu product, and loosening the ties to particular proprietary software environments.  As before, Jazz generates COBOL and has no interpretive code, avoiding the risks from hidden interface routines and proprietary interpreters, as well as providing a layer of insulation between Jazz and the underlying technology.  But Jazz is not just a COBOL generator: it is a full programming system.  It uses COBOL in the way that COBOL uses Assembler or C.

We initially focussed on zOS/COBOL/VSAM because that’s where we saw the greatest need, we’ve extended from z/OS to support Micro Focus, and current development is validating DB2 support.  Conceptually Jazz is not limited to just enterprise systems, although that’s all that’s currently implemented.

We need feedback.  Is this a good approach to reducing complexity?  What have we got right?  What’s wrong? We need partners – marketers and more early-adopter customers – to work with us to refine its existing features and help us to extend the product.