Bridging Unisys MAPPER to Cloud-Ready Java

Featured article by John Dandeneau, VP of marketing and business development, Astadia

During a recent webinar, Astadia legacy modernization expert Craig Marble and Abbey Road Software CEO Dave MacSwain discussed how companies can cost-effectively solve the ever-increasing demand for Unisys MAPPER/BIS conversion as they move to the cloud. Today, CIOs take a very different view of MAPPER. Most see it as an increasingly costly application that is keeping them from modernizing their legacy systems and realizing the promise of digital transformation and cloud computing. Typically, the only way available to convert MAPPER to a more modern system is to manually rewrite millions of lines of code and recreate the embedded critical business logic. This is an error-prone process that is loaded with risks and can cost millions or tens of millions of dollars.

Fortunately, there’s a better alternative now: Six years in development, MAPPER2Java is a new conversion tool on an automated transformation platform that takes native MAPPER applications and transforms them into cloud-ready Java applications, leveraging the SQL database of the customer’s choice. This enables the customer to rapidly move these applications and related databases to the cloud while avoiding the costs and risks associated with a full rewrite of the code. It also helps CIOs avoid further paying significant amounts of money for the recurring high costs of maintaining the Unisys hardware and software. During the webinar, a holistic, step-by-step approach to legacy modernization was outlined, focusing on MAPPER2Java as the tool to migrate legacy Unisys MAPPER/BIS systems to the cloud.

Scott Adams, vice president and CTO of Abbey Road Software, also joined the webinar to answer questions by participants. I have selected the best of the bunch:

• Craig: How do you handle MAPPER calculate commands?

Scott: That’s one of the most complex commands in MAPPER. One of the things MAPPER is known for is that it’s very succinct. You can do a lot of things in a few lines of code. A calculate command tends to have a lot of additional things in it. The calculate command itself is short, and then there are the expressions and conditionals that actually do the work. When you’re in Java, you don’t have the same sort of expression language built into Java. So what MAPPER2Java does is use formulas, and we use it for @ART, @CHG and @DC as well. That allows us to carry forward some of that succinctness of an expression that’s embedded as part of the instructions on how you process results with @CAL. So, that’s one key part of MAPPER2Java — the idea of formulas. We also modify Spring (open source project), which is a lightweight framework in the Java world. It’s called a “Spring Expression Language” (SpEL), and we based our formulas off this standard SpEL. That’s a key part of it. There are also some Java patterns we have to apply to iterate through the result set. There’s the idea of decorators for things like summing a column using the vertical functions; record projection comes into play which is a large topic in itself. Also, the idea of context is important, meaning you are on a row identified by line number, which is another thing we could segue into: “How do you handle line numbers?” which are very prevalent in a MAPPER application; how do they carry forward in an M2J application?

• Craig: Do you support other relational databases as target platforms for MJ support?

Scott: Yes. We’re agnostic. We’ve been targeting Oracle because it has a high penetration in the enterprise space. But since we’re using Hibernate for object relational mapping, it has a number of other dialects. For example, you could do Microsoft’s SQL Server, Derby or MySQL. There are a number of options there.

• Craig: Does Java run on Windows with the same JVM interface as other operating systems?

Scott: Yes, it does. You can get a JVM that runs fine on Windows from Oracle. IBM sells a variation of the old Sun JVM that they’ve enhanced that can be run on commodity hardware. What we recommend is that you have a 64-bit JVM. If you have some 32-bit machines lying around, those are great for development, but for anything serious in production or for performance testing, you definitely want a 64-bit JVM.

• Craig: How are the result RIDs handled in the new framework?

Scott: Everything is a RID in MAPPER. It could contain a run; it could contain a screen; it could contain data. And what M2J is doing is converting the data reports to a relational database. You can query that relational database with a “search” or a binary find, and you can get a result out of it. And there are other ways to get results. What we do there is, since it’s Java, everything is a class, but you’ve got a collection of classes, and we leverage something called CQ engine which is a very fast, efficient way of representing a collection of objects. Once again, we’re in the Java world now — bridging that gap between MAPPER and Java — and you can search using SQL dialect, but you can also search using what I’ll call some sort of “algebra” on a collection. The upshot is that the search features that work on a MAPPER report or a MAPPER results set can be carried over to Java.

• Craig: Does it handle line continuations in the MAPPER code, or does each line need to start with @?

Scott: No, you can cram all of your MAPPER commands onto one line. If that’s what you’ve got, we would parse that.

• Craig: How are line types handled?

Scott: The line type is preserved because that’s something we just have to do. So, let’s go back to our first question on the conversion of MAPPER (which is very succinct and has served a lot of these organizations very well) and what do you do when you’re trying to get to the cloud, which is easier to do with another technology like Java and JEE. When we migrate and move, we retain the line type which can be enumerated if it makes sense. For example, if you have multiple line types that somehow convey information about the type of record, we can create in Java what is called an enumeration so you can get a better representation of what the line type represents. The line type might signify an order that has been fulfilled, an order that is back ordered or something like that. Or you can just store the actual line type character itself. But it gets stored on something we call a “shadow table.” We take the rows, and there could be trailer lines because they represent a different entity, that represent entities and convert them into a relational database. They’re represented in Java as “entity objects.” And the line type is stored in a shadow table that is joined to the table that stores the business data.

The idea is that after you have converted the application, you run it for a while and make sure that it works; as part of the migration, you’re going to have this shadow table. As you evolve and enhance away from some of those paradigms that came over from MAPPER and refactor some code, you can drop that shadow table. So the line type goes away after a while. It doesn’t have to. You can continue to run the initially migrated code for as long as you want, but most organizations eventually get to this “enhance and evolve” phase where you remove things like the shadow table as an artifact of the migration.

• Craig: How is code with looped @RLN handled?

Scott: The line numbers are tricky to migrate. What we do with the line numbers is we carry them over as well, but we carry them over for the purpose of having them be relative positions. They are carried over in the shadow table. Therefore, if you had 10 lines in the MAPPER report, the line numbers would be 1 through 10 in MAPPER, but when that data actually gets loaded into the shadow table, the line numbers are spaced at intervals. For example, the first line might be loaded as line number 500, and the next one might be line number 1,000. In other words, there are gaps that allow inserts to occur. You can still seek to a line number, but the main thing we are interested in is going back and forth, traversing by line number. You can increment the line number (or decrement the line number). So when you add to a line number and the application seeks to it, you’re really saying “advance to the next line.”  If the application is adding three to the current line number (for example, line number 1), you can see how those kinds of things can be tricky to deal with. We treat this example as a relative thing — advance three rows instead of seeking to row with line number 4.

The move from MAPPER to Java is a path that many will take. To learn more, the on-demand recording of the webinar can be accessed at http://www.astadia.com/insights.

As first published in Dzone

About the Author

John Dandeneau is vice president of marketing and business development at Astadia, a premier cloud consultancy for businesses expanding to the cloud. He brings more than 20 years of experience to planning and executing marketing and partner strategies. John holds a bachelor’s degree in Management Science and Decision Support Systems from Virginia Tech. Follow Astadia at @AstadiaInc, Facebook/AstadiaInc, and LinkedIn/Astadia.