从Java访问iSeries上的RPG

Question

Has anyone had good experiences of talking direct to RPG programs running on a V5R4 iSeries machine from Java? If so, what are the recommendations of the community, and what pitfalls should I try to avoid?

From the various pieces of literature and spike solutions I have attempted it looks as though we can use ProgramCallBeans (either through PCML or xPCML), talking to the DataQueues (for asynchronous comms), or even JNI.

I'm looking for something that's robust, performant, quick to develop, easy to maintain, and easy to test (aren't we all!?!).

Answer 1

I suggest using IBM's Java Toolbox for Java. Put the JT400.jar into your classpath (or JT400Ntv.jar if the Java is running on the iSeries). I've used both the ProgramCall class and the CommandCall classes.

The com.ibm.as400.access.CommandCall class is easy to use. It has a simple constructor that you pass a com.ibm.as400.access.AS400 class to. Then just use the run method like this:

CommandCall command = new CommandCall(as400);
command.run("CPYF FROMFILE(BLAH) TOFILE(BLAHBLAH) CRTFILE(*YES)");

Of course, you wouldn't use that particular CL command, but you get the idea. When using the CommandCall class, it's always a good idea to process any messages that came from the command. In the one program I use this for, I display the messages to the user in a textbox on their screen like this:

AS400Message[] messageList = command.getMessageList();
for (int i=0;i < messageList.length;i++) {
String sMessageText = messageList[i].getText();
    sMessage+=sMessageText + "\n";
}

The com.ibm.as400.access.ProgramCall class takes more work, but it allows you to access the returned parameters. I use this one more often because I'm usually calling existing RPG worker programs that return values. For this, define a com.ibm.as400.access.ProgramParameter array. When you pass parameters to a program from Java, remember to convert them to AS/400-friendly values using a class like com.ibm.as400.access.AS400Text. The details of the ProgramCall command are better researched using IBM's documentation: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzahh/page1.htm

Answer 2

You should look at JTOpen . It is fairly easy to use that to do what you want to do. Here is an example someone has put together: program call to as400 using jtopen

Answer 3

We just use JDBC and stored procedures. The stored procedure calls the RPG instead of running SQL. I'm not an RPG programmer, but it seems like a very simple interface. DataQueues are OK, but they aren't as robust as something like JMS (no guaranteed delivery).

Answer 4

It is quite simple to call java methods directly from RPG. I am not sure exactly what you are trying to do, I have made calls directly to java methods several times.

For an example of how this is done. Take a look at RPGMail . You can look at the source and see how Aaron used RPG to connect to JavaMail.

Answer 5

I've had some success with PCML documents. I decided to use PCML since encoding the commandcall into a string when passing parameters to an RPG program can get really ugly.

PCML allows you to somewhat transparently pass java data types to an rpg program as a parameter. The drawback is that the xml in the PCML doc becomes a static interface and must be updated if the program is ever updated. With the right build tools, it might be pretty straightforward to automate the update of the pcml xml, but right now I'm doing this manually.

I've used this approach when the rpg program needs to be called from java, and the logic flow is controlled by the java program.

In a case where the logic flow was controlled by an rpg program, I've used dataqueues for both synchronous and asynchronous calls to java. This required writing a significant amount of code to standardize on how to read and write to dataqueues in a coordinated manner from different programming languages

Answer 6

Hmm, I'm new here and would vote KC Baltz answer up, but cannot yet. Stored procedures are the way to go. I've used JT open to call programs natively and found issues with the number of parms that could be passed, issues with data types, etc. Once you have an SQL procedure wrapper around your program you'll find the Java support for SQL to be far superior than the java support for native 400 calls.