Users installing mainframe systems have long been familiar with ISPF and REXX systems. These systems are used to install applications written in traditional mainframe programming languages. Not only were load libraries and application-specific files created, these systems also performed configuration of the application. This could mean creating files and updating them with input provided by the user at install time. Efforts at mainframe modernization have added a new language to the mix, Java. Applications written in Java quite often have a properties file that contains configuration information. Users are accustomed to editing this file after the application has been installed; so, it follows that installing Java applications on the mainframe should be similar to, if not identical to, installing traditional applications.

The phrase “mainframe modernization” covers a lot of ground. One aspect is the replacement of systems written in COBOL, PL/I or Assembler with systems written in Java. One benefit is that Java programs can run on attached processors such as System z Integrated Information Processors, commonly referred to as zIIPs. Running your Java code on a zIIP can lead to significant cost savings. You can find out more about this specialty engine on IBM’s website.

Some background at this point is useful. IBM has provided very extensive support for running Java on the mainframe. Java executes on the UNIX System Services (USS) side of z/OS. In fact, USS is being called z/OS UNIX lately. There are a great many resources describing USS so I won’t go into detail here. The Rexx program and the Java program must run on the same logical partition (LPAR).

As previously mentioned, Java applications may have a properties file. This file contains run-time values that users can easily change. However, many mainframe users are not comfortable using USS-specific commands. They are even less comfortable using traditional UNIX commands. You can provide a more familiar interface to the properties file using a REXX to Java approach. To do so, you would present an ISPF panel to your users. The labels would be more descriptive than just a simple key. You could also provide a help panel to further explain what is being asked of them. Users would update the panel. The ISPF code would perform validation on the entered values. The ISPF code would invoke the REXX EXEC, which, in turn, calls the Java code. The Java code updates the properties file and should return a pass/fail indicator.

This could be part of a multiproduct installation system or a standalone application. It is especially useful in a mainframe modernization effort. You can create a system that installs the Java executables, updates properties files and creates JCL to run the application, thus, giving traditional mainframe users a familiar interface into this ”write once, run everywhere” world.

The glue that holds this together is the bpxwunix REXX function. This function is described in the Using REXX and z/OS UNIX System Services manual. The description is quite simple.

“Runs a shell command and optionally:

• Provides its stdin
• Traps its stdout
• Traps its stderr
• Exports a set of environment variables.”

The shell command can be a standard UNIX command or a program. Here’s a simple example of what you need to do:

I think Rexx has been misUsed a lot over the years. It is great glue, and they have built more functions into it than it really needs ... but it really should not be doing heavy lifting on its own (go ahead and send hateMail for that comment). Years back, we had Rexx code that was merging data from 4 sources (memory mapping data, JIT, LLA, ... merging with instrumentation address data). It ran for about 2 hours. When asked to reWrite it, I chose C (there were technical reasons at the time to not use java) ... it was nonTrivial in that it exploited rexx functionality quite well. My goal was to get it from 2 hours to 5 minutes. In the end, with some rudimentary memory management, I got it to run in 5 seconds. As time went by and the sources of data became much larger, my C program ran for a minute (12x the original time) ... Rexx never would have come back. That said, java is a fine replacement for Rexx (would have been my choice were not some other factors involved) ... as it can also be quite efficient. So, IMHO, if you've got REXX doing heavy lifting, reWriting in java is an excellent idea. If you've got Rexx as a controller or glue for a lot of functions that do the real heavy lifting ... then reWriting doesn't make sense.