Why MANASYS Jazz?

Since 1980, when the first version of MANASYS was released, we have had a single goal:

to make programming as simple as possible

without sacrificing flexibility, efficiency, or the safety of proven technology.

Modern systems are overwhelmingly complex.

· We manage data in a server (a mainframe?) with files and databases, so we have to understand the rules of the data management systems.

· We need to present this data in reports and screens, so we must understand the rules required to reformat and present the data.

· We need to get the data from the server to a client device - whether a web page, a Windows program, a mobile app, or even a 3270 screen, so we need to understand the differences between the architecture of the server and the client devices, and the different rules of the languages used in these environments

· We need to understand the rules required to move the data between environments.

· We need to think of the issues of shared data - what happens if we update an account at the same time as somebody else?

· We need to think of security - how do we ensure that the data gets from A to B without interference or discovery by others.

Yet our problem seemed relatively simple: "Maintain accurate records of our customer's bank balances, and record all transactions affecting these balances". So how did it get this complex?

Every one of the bullet points above represents one or more software systems that have been developed to solve a lower-level problem. Databases organize data in more flexible ways than basic files, allowing better data sharing and multiple ways of using the same data. Our programming languages – COBOL, Java, etc – will reformat data stored as binary or packed into characters, and editing rules like PICTURE insert sign, currency and punctuation symbols, and move the data into the report line or display screen, and issue a command to write this to a printer or screen. And so on for all these points and many more that weren’t mentioned. Our solution ends up with layer upon layer of separate software managing the computer, data, communication, security, etc, none of which can be omitted, and very few of which coordinate with others. It becomes the developer’s responsibility to manage the coordination, ensuring that the Job Control Language (JCL) corresponds to the data definitions used by the COBOL program, that we use the right statements to access and update the data, that the data sent to a client device is appropriate and sent at the correct time, and that a host of other details are correctly managed.

Now ask yourself – how much of this is related to the original problem? And how much is related to your technology solution?

Almost all of the complexity relates to the solution, very little relates to the business problem. Developers spend most of their time implementing choices already pre-determined by the technology choices that have been made. For example, the COBOL logic to read a series of records from a VSAM file is very different to the equivalent logic reading a series of records from a DB2 table. But if the choices are pre-determined, then why can’t the development system choose the necessary code? Two key principles that MANASYS has followed from the beginning are “Say it once” and “Say What, not How”. Thus, you’ve already told MANASYS whether “IN1” is VSAM or DB2, you don’t need to tell it again by writing different code,
for VSAM using READ, IF logic, and an explicit SORT,
for DB2 using EXEC SQL SELECT … with cursors.

The logic below will generate different COBOL, but perform the same function, whatever IN1’s type. And because Jazz definitions are more complete than COBOL’s, MANASYS will also generate JCL to run this report program.

COPY IN1;

COPY FR;

PROCESS IN1 WHERE (IN1.Region IN (1,6))

ORDER (IN1.Region BREAK, IN1.District BREAK, IN1.Name);

GET FR WHERE (FR.Region = IN1.Region);

PRINT (IN1.Region BREAK(IN1.District),FR.Name BREAK (IN1.District), IN1.District BREAK,

IN1.Name, IN1.SalesThisMonth SUM);

END PROCESS IN1;

An even more extreme example of these principles is shown in the web service program used in the Bridging Two Worlds video. Here we created a Jazz definition of DB2 table Employee and then we created a web service from this definition with a few clicks. The definition already defines the validity rules for each field, so MANASYS Jazz has no difficulty in generating COBOL to check that input fields have valid values. Once the web service is created, another two dialog clicks creates the client-side interface, and again the validity rules of the input fields are built into the interface from this definition, ensuring that invalid data is unlikely to even reach the web service. In this example

· We started with 21 lines of DB2 table definition, mostly written for us with the dialog: Import From SQL.

· Dialog New/Logic/WebService created 25 lines of Jazz web service program, plus 58 lines of Jazz message definition

· Which became about 2500 lines of COBOL

· From which 320 lines of JSON was generated

· From which MANASYS Jazz generated about 1000 lines of C# client interface

· All of which compiled and worked first time

Very little information that was already known had to be repeated. All the required code – COBOL, JSON, and C# – was inferred from the data definitions and the dialog responses.

Click here to learn more about MANASYS Jazz. Download a free evaluation copy of the software if you want to try it out. Or contact me if you have any questions.