• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3556
  • Last Modified:

iSeries - CL - QSH - Java - Return Codes

Hi,

Working on iSeries V5R4.

Running Java for the first time on the iSeries where we are using a CL to call a Java component that will process files sitting in a directory on the IFS. The file name and file location will be sent to the Java component which will transform the file from a flat file to an XML and put the output into a different directory. Depending on the return code from the Java component the CL will move the input file from an input directory to either an error or a successful output directory.

If the Java component fails (eg invalid character on a record etc) we want to return an error code and we want the CL to act accordingly. ie move that file to error directory and read in the next file until all files in the directory are processed.

We have successfully called a Java component using both QSH and via the RUNJVA comand however processing the return codes is still a mystery.

The CL calls QSH which calls the Java component. But how do you bubble the error codes back from Java to QSH and on to the CL?

We are hoping not to use MQ or data queues to pass messages back - we are hoping there is a simple way to just pass back a code?

Thanks
0
bilfusiontech
Asked:
bilfusiontech
  • 2
1 Solution
 
Gary PattersonVP Technology / Senior Consultant Commented:
RUNJVA starts a JVM in a different process from the one where your CL is running, so you can't use the normal program message queue mechanism for message passing (since program message queues are local to a single process).

If you have very simple return code requirements, you can use System.Exit(returncode) to pass a nonzero return code back to your CL.  The CL will see JVA0122, with the return code passed as message data:

http://archive.midrange.com/java400-l/200905/msg00066.html

If you need to pass more sophisticated data structures, or need to pass multiple messages, then you'll need to resort to "out of band"  mechanisms.  Write to a file, write to a data area, write to a persistent message queue (user message queue, or a *MSGQ object created specifically for your process or job), write to a data queue (I personally like using data queues- fast, flexible, and easy to manipulate from RPG, CL, and Java), write to an IFS stream file, etc.

I will note that unlike CL, ILE RPG programs can declare Java Objects and Methods, and invoke them directly, including passing parameters in both directions.  This means you can use a simple RPG wrapper between CL and Java to handle more sophisticated parameter and message passing requirements for you.

http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/com.ibm.etools.iseries.pgmgd.doc/c0925076170.htm

- Gary Patterson
- Gary Patterson
0
 
tliottaCommented:
Using a RPG wrapper makes good sense. It's probably the best direction for at least the near term. (IBM might add more features for other options eventually.)

For any continued work with CL plus QSH plus Java (aside from RUNJVA), you might review examples and discussion beginning at this point in the 'QSH Error Trapping' thread. Various facilities are available in CL, QSH and Java for manipulating their different and generally unrelated error handling and signaling methods. Choices may depend on existing expertise and other factors.

Tom
0
 
bilfusiontechAuthor Commented:
Hi Gary and Tom,

Thanks very much for taking the time to answer.

I think we are happy to go with return codes.

So in summary to get this working:

As advised we used the RUNJVA command to call the Java component where the Java component does a System.exit(1) or System.exit(2)...

This gives the message JVA0122 which we do a MONMSG for. When we get this message we do a RCVMSG (of type *LAST) and put the MSGDTA field into a CL variable. As the link suggested this is in binary which we then convert to a character using %BIN giving us the return code that the Java component return which we then act upon.

Many thanks again,

Patrick.
0
 
tliottaCommented:
At V5R4, conversion to binary should only take a CL data structure. The MSGDTA() variable would have a STG(*DEFINED) sub-field of TYPE(*INT).

But %BIN should work fine. Either personal style or site standards would make the choice.

Tom
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now