No matter which way you try it, interfacing a mainframe from an application server or servlet is never fun. Among other hurdles to overcome, the mainframe could exist on a different platform or use a different character set. Think you can simply access the data directly and rebuild your business logic? Perhaps, if your database is not hierarchical and you enjoy reinventing the wheel. However, a few tricks using XML, XSL, and Java can make it easier than you think.

XML describes the structure of the data you are sending. Add XSL to complete some simple transformations. Use Java to encapsulate it with a few simple classes. You will then leverage a host of legacy system transactions written decades ago and format them into an XML document. Once your data is in an XML format, manipulating it becomes a much less daunting task, and development becomes easier. In addition, the solution you employ is realtime, which circumvents the frustrations and problems that arise from working with an extract file or batch interface.

The versatile XML


While many may only think of XML in terms of marking up structured documents, you can use XML to describe anything that has a particular structure. For the purposes of this article, we shall assume that our legacy system stores data in a hierarchical database that may be accessed through COBOL programs residing on the system. Why not access the database directly to retrieve the information? While the hierarchical database offers some advantages for the mainframe system, directly accessing it requires extensive knowledge of the database. Usually, the underlying database features significant complexity, which makes traversing it exceedingly difficult, if not downright impossible. Since the COBOL programs are already available for that purpose, there remains no reason to undertake such a complicated task.

You must know the structure of the transaction you will interface in order to invoke the COBOL program. To obtain that knowledge, refer to the program copybook, which contains the directions for use. Those directions include information about the length of the field, name, left or right justification, etc. Think of those descriptors as a set of fields that are described by attributes. Those descriptors provide directions on how to format the request and how to parse the returning data from the subsequent call.

Using XML, you can now implement that copybook metadata to generate your copybook markup language. Below, this short, simplistic example of an XML document containing our COBOL program's metadata retrieves a name when given a social security number:


<transaction>


      <configuration>


            <name>CobolNameProgram</name>


            <requestlength>30</requestlength>


            <replylength>200</replylength>


      </configuration>


      <request>


            <field identifier="SSN", justification="R", length="12"/>


            <field identifier="username", justification="L", length="8"/>


      </request>


      <reply>


            <field identifier="firstname", length="15"/>


            <field identifier="lastname", length="25"/>


      </reply>


</transaction>




The name describes the name of the COBOL program you invoke, and the lengths of the corresponding request and reply messages. The attributes of each field you will encounter describe the name, field length, justification, or any item you need to know to process this request.

The Java engine


Referencing the structure above, you can write the code to hook up your values into your request's structure and parse the incoming reply with

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine