Access RPG on iSeries with Java

Question

Has anyone had a good experience communicating directly with RPG programs running on a V5R4 iSeries with Java? If so, what are the community recommendations and what problems should I avoid?

From various literary and spike solutions, I tried to understand that we can use ProgramCallBeans (via PCML or xPCML), talking to DataQueues (for asynchronous messages) or even JNI.

I am looking for something reliable, efficient, fast-paced, easily maintained and easily tested (not all of us!?!).

Answer 1

I suggest using the IBM Java Toolbox for Java. Put JT400.jar in your classpath (or JT400Ntv.jar if Java is running on iSeries). I 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 by which you pass the class com.ibm.as400.access.AS400. Then just use the run method as follows:

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

Of course, you will not use this particular CL command, but you will get this idea. When using the CommandCall class, it is always useful to handle any messages coming from the command. In one program, I use this, I display messages to the user in a text box on their screen as follows:

 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 does more work, but allows access to the returned parameters. I use this even more often because I usually call existing RPG work programs that return values. To do this, define an array com.ibm.as400.access.ProgramParameter. When you pass parameters to a program from Java, be sure to convert them to values ​​compatible with AS / 400 using the com.ibm.as400.access.AS400Text class. The details of the ProgramCall team are better explored using IBM documentation: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzahh/page1.htm

Answer 2

You should see JTOpen . It is quite easy to use to do what you want to do. Here is an example someone put together: calling as400 program using jtopen

Answer 3

We just use JDBC and stored procedures. A stored procedure calls an RPG instead of running SQL. I'm not an RPG programmer, but it seems like a very simple interface. DataQueues is fine, but they are not as reliable as JMS (without guaranteed delivery).

Answer 4

Just call the java methods directly from the RPG. I don’t know exactly what you are trying to do, I made calls directly to java methods several times.

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

Answer 5

I have had success with PCML docs. I decided to use PCML because encoding 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 into the rpg program as a parameter. The disadvantage is that the xml in the PCML document becomes a static interface and must be updated if the program is constantly updated. With the right build tools, it can be quite simple to automate the pcml xml update, but right now I'm doing it manually.

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

In the case where the logical stream was controlled by the rpg program, I used data for synchronous and asynchronous calls for java. This required writing a significant amount of code to standardize how to read and write data in a coordinated form from different programming languages.

Answer 6

Hmm, I'm new here and I will vote for KC Baltz, but I still can’t. Stored procedures are the way to go. I used JT open to call programs initially and found problems with the number of packets that could be transmitted, problems with data types, etc. Once you have the SQL procedure wrapper around your program, you will find Java support for SQL will far exceed java support for your own 400 calls.