A LegStar Commercial License

Entreprises still intensively using mainframes these days tend to be very large. Although most of these companies are more and more comfortable using open source software, they are not comfortable at all with running unsupported code in production.

That creates a specific problem to LegStar since it is both Open Source an primarily of use for such large companies.

After receiving several requests from customers at LegSem we started looking into building some kind of commercial offering around LegStar.

Of course, we are not the first open source company to bang our head against this thorny issue, infoworld has a honest and funny write-up about this.

So this is what we came up with:

Committed to Open Source:

• First, LegStar is and will remain Open Source
• The core features will stay under the permissive LGPL as they are today and the advanced features will be GPL
• There won't be an entreprise product separate from the Open Source one. This means every single line of code will be available under an Open Source license

For Customers who need it:

• Besides the Open Source licenses, there will be a Commmercial License available. Yes, this a dual-licensing scheme
• The Commercial License describes the level of support that LegSem, or a business partner, provides
• LegSem will also shield Commercial Licensees from backward compatibility issues

This last point requires a little bit of explanation:

As we add new features or fix bugs in LegStar we generally pay attention to backward compatibility but we don't necessarily test it. As a result, new releases are not guaranteed to be backward compatible with your own developments. With the commercial offering, we will do additional, less frequent, releases that we will explicitly check for backward compatibility. These extra releases will only be available to commercial licensees.

LegSem is a small company and will not cover the entire world with that commercial license. What we intend to do is to work with business partners in territories where we are not present. So if your company would be interested in entering this type of deal with us please send a mail at contact@legsem.com.

Finally a LegStar JCA Connector

This article refers to JCA, the Java Connector Architecture, not the Java Cryptography Architecture.

When we considered J2EE several years ago as a potential target for mainframe integration, I was horrified and decided not to pursue that route. This has proven the right choice and the J2EE reputation was so bad that the name was later changed to Java EE.

The idea that overly complex technologies provide great opportunities to sell services and consulting is not new. Some very large companies made a fortune this way. Some of these same companies were very active during the J2EE specifications...

Of course J2EE completely failed to become the universal web engine it was meant to be, but it made it to most large Entreprise Systems. Or at least part of the technology was adopted by large IT departements and some of the complexity alleviated thanks to frameworks like Spring.

So the reality today is that most companies still using mainframes also use Java EE.

Another interesting development concerns the latest Java EE specifications (5 and 6). I don't know if the J2EE designers were humbled by their past failures but I have to say they did a much better job this time. Today, the technology is almost usable without Spring. For instance, you can inject a JNDI resource with a single annotation which would have taken about 10 lines of Java code previously. If you want to learn more about the latest Java EE, I recommend reading Antonio Goncalves's blog.

So with Java EE specs getting better and almost all mainframe shops using it, I thought it was time for LegStar to start supporting Java EE containers. The result is part of a series of extensions to LegStar that I am working on.

The first deliverable is a JCA Resource Adapter that uses CICS Sockets as its underlying connectivity.

It is conformant to the JCA 1.0 specifications but does not implement some of the CCI chapter (which is optional anyway). In practice we do not support CCI Records which are awkward indexed or mapped objects. In my view, Records are not suitable to represent COBOL structures. With the LegStar JCA connector, Instead of Records, you simply use regular LegStar Transformers.

I am convinced that separating Resource Adapter fonctionalities (Connection pooling, Transactions and Security) from Transformation is a much better approach than what most JCA connectors available on the market do. For one thing, you can reuse the Transformers outside Java EE which is good because, even if Java EE is largely used by mainframe shops, they also use many other java based technologies (ESBs, ETLs, ...).

I intend to support the other LegStar transports (HTTP, WebSphere MQ) in the future as well as some other transports I have in mind. There will be a different JCA Resource Adapter for each transport.

One thing you might notice is that the licence has changed for these extensions. While the core LegStar project remains LGPL for the time being, the extensions use the more restrictive GPL. LGPL is often used when OSS projects start and need to get the wider acceptance possible, while GPL is for more mature OSS projects. LegStar is 7 years old now and if you look at what Google has to say about open source mainframe integration:

You will agree with me that it has gained sufficient traction to become part of the higher class GPL projects out there.

This is all thanks to you of course since I haven't devised a scheme to get Google to better rank my sites and never paid Google a dime either :-).

Mapping Dates from COBOL to Java

Date (and Time) types are difficult to map between COBOL and java. Here a few comments on why this is hard.

Dates in COBOL

For a very long time, the COBOL compiler on IBM mainframes didn't know anything about dates. Developers typically used structures and managed dates semantics by hand. The Y2K issue was largely a consequence of this situation since the compiler couldn't solve the problem all by itself.

Recently ("recently" on the mainframe time scale means in the last 15 years or so), IBM introduced the DATE FORMAT keyword. This is used to further qualify a regular numeric or alphabetic data item. It introduces some restrictions on what you can store in the data item but fundamentally, the data item remains a numeric (binary, compressed or zoned decimal) or an alphanumeric.

The DATE FORMAT keyword must be followed by a pattern using Y and X characters (no relationship to chromosomes) such as YYXXXX or YYYYXXXX.

• YY designates a "windowed" date. This is relative to a century window given by the YEARWINDOW compiler option.
• YYYY is an "expanded" date. This is a regular century + year date.

MOVE of a windowed date to an expanded date will expand it as expected. There are also intrinsic functions such as DATEVAL and UNDATE to convert dates to non date data items.

For more details, see the programming reference in IBM COBOL documentation.

Dates in Java

If dates are messy in COBOL, well, they are even messier in Java.

At the beginning there was an overly simple java.util.Date (with a weird java.sql.Date variation with 9 methods, 6 of which are deprecated!).

Then came java.sql.Timestamp which inherits from java.util.Date but about which the documentation states: "it is recommended that code not view Timestamp values generically as an instance of java.util.Date". It is as if to say: Timestamp inherits from Date, but please don't use that fact in your programs...

But worst, came the dreaded java.util.Calendar. In this article, Joshua Bloch, an ex Sun engineer, says:

As an extreme example of what not to do, consider the case of java.util.Calendar. Very few people understand its state-space -- I certainly don't -- and it's been a constant source of bugs for years.

java.util.Calendar was designed at a time (long gone now) when Java was to overtake the programming world, so this monster was born and several, often used, java.util.Date methods were deprecated as a consequence.

To further complexify things, JAXB has introduced the javax.xml.datatype.XMLGregorianCalendar in order to map the XML Schema date and time.

All in all, at least 5 different ways of representing a Date

Mapping COBOL dates to Java Dates

So far, Legstar has taken the, rather lame, approach of not attempting to map COBOL dates to Java dates automatically.

When starting from COBOL, this means you will never get a java Date/Timestamp/Calendar property, even if the corresponding COBOL data item is marked with a DATE FORMAT. Date semantics are lost in translation...

When starting from Java though, chances are that some property is a Date/Timestamp/Calendar. Actually Date/Calendar, because with Timestamp you would get "error: java.sql.Timestamp does not have a no-arg default constructor" from JAXB.

LegStar maps Java Date/Calendar properties to a COBOL PIC X(32).

At runtime, the PIC X(32) content is assumed to follow the form: "yyyy-mm-dd hh:mm:ss.fffffffff" known as the JDBC timestamp escape format.

This is rudimentary but following this conversation, the latest LegStar has introduced a new annotation, inspired from Patrick's comment: @CobolJavaTypeAdapter(value = SomeClass.class) where SomeClass is code that a developer implements. (Here is a sample).

An extension mechanism is probably the best way to handle COBOL to Java date binding.

Migrating off the CTG?

CTG, the CICS Transaction Gateway, is an IBM product that has been around for a long time and is largely deployed in mainframe shops.

CTG is usually used from a Java client to make outbound, synchronous, calls to a CICS program. In this case, the API offered to Java clients is known as ECI (External Call Interface ). Because ECI is how most users access the CTG some of them refer to the CTG itself as ECI.

CTG is a separate product from CICS itself. Some people confuse both (probably because the names are so close: CICS Transaction Server and CICS Transaction Gateway).

CTG runs in a Java VM that could sit on z/OS (in the Unix System Services environment) but most frequently runs off a distributed server. It is also frequently used in conjunction with WebSphere and as such, can be thought of as middleware between WebSphere and CICS.

CTG’s major strength is transaction support and J2EE integration. It supports the JCA connector architecture and provides 2-phase commit and XA support.

Although CTG might sound like the definitive solution for CICS/java integration, a number of users are considering moving away from it.

I can see 3 reasons why this is happening:

• The emergence of integration standards such as Web Services (and the slow erosion of older standards such as J2EE/JCA)

• Loose coupling as a preferred architecture pattern over tight coupling

• The Open Source revolution which drives more and more enterprises to consider Open Source software as a valid alternative to closed products

An uncomfortable position within IBM

Today, CTG is competing internally with other IBM integration features particularly when it comes to SOA. You can of course create Web Services on top of JCA but there are more efficient alternatives within IBM.

CICS itself has built-in support for SOAP Web Services. This feature, known as CICS Web Services, offers programmers a standard way to call CICS programs without the need for CTG.

WebSphere, when it is installed on z/OS, also now offers CICS integration directly (an option known as OLA for Optimized Local Adapters).

WebSphere MQ can also be used to support Web Services.

CTG seems to have less and less room within the IBM offering.

Not a serious contender for loose coupling

CTG has support for asynchronous calls but it is hard to justify the heavyweight 2-phase commit support in such a setting.

Asynchronous calls can’t support 2-phase commit and therefore could run with a much more lightweight infrastructure.

Furthermore, IBM has WebSphere MQ as its preferred asynchronous programming interface so it is hard to see how CTG could be justified to support a loosely coupled architecture.

Not Open Source

CTG is not Open Source and is a complex black box that users struggle to operate.

It is hard to tell how much this costs companies but I have met with very frustrated customers.

CTG is not free of charge but it is often bundled with WebSphere, CICS and other products and it is difficult to isolate its cost from the rest.

The true cost becomes apparent though for customers migrating off WebSphere because the bundle offer does not apply anymore.

Poor and confusing tooling

So far we have discussed the runtime aspects of CTG but how about the development time tooling? How do you map the target COBOL data structures to java beans?

Here there is some confusion. This mainly stems from IBM changing names and branding several times over the last few years.

The COBOL mapping tools are usually an option buried deep into a much larger developer product:

• Enterprise Application Builder (EAB) within VisualAge for Java (No longer supported)

• J2C within RAD (Rational Application Developer for WebSphere Software which used to be named WSAD for WebSphere Application Developer)

• J2C(?) within RDz (Rational Developer for z/OS which seems to have been recently renamed Rational Developer for zEnterprise)

I am not sure about J2C being part of RDz. RDz seems to cover CICS Web Services with tooling that looks quite different from J2C. I know CICS had a “Web Service Assistant” a sort of command line utility to map COBOL to XML. RDz might have some GUI on top of that.

Although these tools are Eclipse based, they are not open source. There is usually a per seat license to be purchased.

There are several issues with J2C:

Users complain that the java beans mapping COBOL structures that J2C produces are awkward, the morphology does not always match the original COBOL structure (flattening), property names derived from COBOL data items are unfriendly (use of double underscores), arrays are turned to java arrays instead of more flexible java.util.List, no support for REDEFINES, …

J2C also produces java classes that intermingle java to COBOL transformation with remote execution of CICS programs. This tight coupling of language translation features with RPC mechanism was customary 10 years ago but has proven quite limited since then. This is because integration today is a lot more than calling CICS programs. Mainframe data can originate from files, messages, non IBM transaction monitors, etc… Also data might have to be processed asynchronously, as part of a flow (BPEL) or even in batch which was completely missed by the JCA specs.

If LegStar was architected on the same principles, it would be impossible to support ESB’s or ETL’s for instance.

LegStar might help

To summarize the CTG situation today, it has relatively limited tooling, is tightly related to JCA and has a weak position within the IBM offering.

For users considering Open Source and loosely coupled alternatives to CTG, LegStar could come handy.

At LegSem, with help from some of our pioneer users, we are building a service offering to help customers move away from RAD/CTG.

Our first step is to develop migration tools that can exploit meta data produced by tools such as RAD.

We are also working on an ECI transport for users who want to adopt LegStar COBOL Transformers (to replace the J2C beans) but would rather stick to CTG to get to their mainframe.

If you are interested, drop us a message at admin (at) legsem (dot) com or use this form.

When it comes to Mainframes, nothing is simple

The IEEE Software review has published an article by Belgian researchers who made an attempt at re-engineering a mainframe application using automated tooling they knew worked in other environments.

Although the article mentions important lessons learned, it proved once more that it is extremely difficult to reconstruct mainframe applications knowledge automatically from static code analysis.

They typically ran into an issue, I for one, encountered several times, where an apparently autonomous set of COBOL programs actually calls some Assembler magic that turns control to other hidden programs only identified at runtime. There is little you can't do on a mainframe using Assembler. One thing you can do, is load executables dynamically.

During the 80's, the heydays of Mainframe programming, every IT shop had one or more Assembler guru's. With much looser budget controls than today, it was possible to spend considerable time developing in-house frameworks, optimizing performances and so forth. Not to say that this only had negative effects, these optimized assembler routines probably saved large amounts of money by reducing CPU consumption, a major parameter on IBM bills.

Most code analysis tools are COBOL centric. One reason for that is that COBOL is not that hard to parse. To my knowledge, there are no automatic code analysis tools for MVS Assembler (DataTek has an impressive tool for Assembler to COBOL but it usually requires some level of human assistance). That's probably because the level of complexity such a tool would require would be several levels of magnitude higher than COBOL.

For a typical Mainframe shop, the volume of MVS Assembler programs is much smaller than COBOL. That might explain why vendors would have a hard time cost justifying writing a very complex Assembler code analysis tool.

So the result of such a situation is that COBOL code analysis tools fail on multilanguage boundaries. Of course there are other multilanguage boundaries on Mainframes for instance: COBOL to BMS or MFS macros, COBOL to JCL, COBOL to SQL, COBOL to CICS, COBOL to IMS not to mention all third party tools one can find on Mainframes. One thing for sure, I have never seen a pure COBOL application.

The problem is that without reliable code analysis tools, you can't reconstruct knowledge in a bottom up approach. What you end up doing is taking the top down approach, by chasing the last application expert on site, hoping that he hasn't retired yet.

The complexity revealed by this IEEE article explains a good part of the Mainframe applications longevity. I know IBM prefers the reliability, availability, security explanation. But I know many IT shops who would have happily migrated off their mainframes if it was easy.

LegStar is also affected by this complexity of course. I often have a hard time explaining to Java developers why the Java side of LegStar works so easily while the Mainframe side, which has much less code in it, is often much harder to get to work properly...

COBOL in a flat world

We just released a version of LegStar for Talend Open Studio. Talend is a well known ETL tool that also expands to the MDM and ESB spaces.

This is the second ETL tool we interface with. The first one was Pentaho Data Integration a.k.a Kettle for which we released legstar-pdi back in November 2010.

With this experiences behind us it becomes clear that ETL tools are row centric. This means that data flowing from one step to another needs to be modeled as a flat, fixed, list of fields. This exactly maps to a classical database row. Not surprising as ultimately, an ETL, must feed database tables somewhere.

When the starting point is COBOL though, where data structures tend to be very hierarchical, fitting in a flat model is challenging. Here are some considerations to keep in mind.

Name conflicts:

Flattening a simple hierarchy such as:

01 ITEM-A. 05 ITEM-B PIC X. 05 ITEM-C. 10 ITEM-D PIC 9(4) COMP.

is relatively easy, it intuitively maps to: [ItemB:String, ItemD:Short].

Now what happens for this one (perfectly valid in COBOL):

01 ITEM-A. 05 ITEM-B PIC X. 05 ITEM-C. 10 ITEM-B PIC 9(4) COMP.

In a flat model, field names must be unique so [ItemB:String, ItemB:Short] does not work. You need to disambiguate names and produce something like [ItemB:String, ItemC_ItemB:Short].

Arrays:

Assuming a COBOL data item such as:

05 ITEM-A OCCURS 5 TIMES PIC X.

we have an new issue since arrays are usually not handled by database schemas.

Now the solution is to expand each item into a different field. Something like [ItemA_0:String, ItemA_1:String, ItemA_2:String, ItemA_3:String, ItemA_4:String].

This is quite wasteful but no real alternatives here.

In COBOL, the DEPENDING ON clause is often used to limit array sizes and processing time. Here we hit another limitation of the flat models, they are usually fixed in the sense that all fields declared must be present in each row.

Filling unused fields with null values is a common technique used to tell downstream steps that fields have no value.

Redefines:

The COBOL REDEFINES clause, a cousin of the C union, is another interesting challenge. Since the flat model is fixed it can't be dynamically changed depending on the REDEFINES alternatives.

The best solution here is to manage a different set of flat fields for each combination of alternatives. This can be demonstrated with a simple example:

01 RDEF01-RECORD. 05 COM-SELECT PIC 9(4) COMP. 88 DETAIL1 VALUE 0. 88 DETAIL2 VALUE 1. 05 COM-DETAIL1. 10 COM-NAME PIC X(10). 05 COM-DETAIL2 REDEFINES COM-DETAIL1. 10 COM-AMOUNT PIC 9(5)V99 COMP-3.

Here the COM-SELECT field value determines if COM-DETAIL1 or COM-DETAIL2 is present in the COBOL data.

This would result in 2 field sets (schemas in ETL parlance):

• set1: [ComSelect:Short, ComName:String]
• set2: [ComSelect:Short, ComAmount:Decimal]

The number of field sets you need to contemplate depends on the number of alternatives in each REDEFINE group (an ITEM followed by a set of items redefining its location). Furthermore, if a COBOL structure contains multiple such REDEFINE groups, than all combinations are possible. So lets say a COBOL structure has a first group of 3 alternatives and another of 2 alternatives, there are 6 (3 x 2) possible field sets.

Fortunately, the number of REDEFINE groups and the number of alternatives in each groups are usually small.

What this all means is that COBOL structures need somehow to be shoehorned to fit the ETL data model. This is an important difference with ESBs where the data model is usually a much more versatile Java object.

See you at Maven central

Maven central has long been restricted to a few very large players such as the Apache foundation.

This has changed recently thanks to a new free offering by Sonatype for OSS projects.

LegStar has been using Maven from the very beginning and more and more users rely on the availability of artifacts in the LegStar Maven repository.

This proprietary repository is not very secure and not always available. Now that it is possible to push artifacts to Maven central I have been busy figuring out how to take advantage of this.

The major issue is that Maven central's policy is to host artifacts only if their dependencies are also in central. And of course LegStar has dependencies on oss libraries which are not in central

One of the bad players is the Eclipse foundation. So far, no complete sets of Eclipse bundles are available as Maven artifacts. There are lengthy discussions going on but no results yet.

Besides Eclipse the only other annoying dependency we have in LegStar is Websphere MQ. Of course this one being proprietary, it will never make it to central.

In order to bootstrap the process of moving to Maven central, I have started to split the modules into separate release units. the first, very limited, release is now in Maven central. You can see the result at this location by entering the legstar keyword.

It feels good to be part of the big league