WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #92: Integrating with JCL Driven Jobs

By David Follis posted Wed May 27, 2020 08:13 AM

This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.

To start at the beginning, follow the link to the first post.

The next post in the series is here.

This series is also available as a podcast on iTunesGoogle PlayStitcher, or use the link to the RSS feed

We’ve talked about how Enterprise Schedulers can run scripts that run batchManager to submit Java Batch jobs to WebSphere Liberty.  But what if you want to run JCL on z/OS?  How do you integrate the two together?

Both batchManager and batchManagerZos are command line interfaces that can be invoked from JCL using the BPXBATCH program (EXEC PGM=BPXBATCH).  Or you can use one of the other flavors of BPXBATCH such as BPXBATSL (which might be a better choice). 

However, you probably don’t want to invoke the CLI directly from JCL.  The reason has to do with return code handling.  BPXBATCH itself has return codes to indicate errors with its own processing (such as not being able to find the thing you told it to run).  Those return codes values are likely to collide with return values from the thing it ran (your program, or in this case batchManagerZos).  To avoid that, BPXBATCH shifts the executed program’s return codes over one byte.  Thus, a return code of 0x8 (hex 8) becomes 0x800.  That’s all well and good if the return codes from your program are small values. 

If your application (or batchManagerZos) returns 0x10 then that gets shifted to 0x1000 which is all fine, except that JCL condition codes are only 3 digits (hex) which means the actual JCL condition code for a step that used BPXBATCH to run a program that returned 0x10 is going to be…. Zero.  That high-order ‘1’ gets lopped off. 

Well guess what – the return codes from batchManagerZos are often bigger than 0xF and run into this behavior. 

The answer is to use BPXBATCH to run your own shell script which, in turn, runs batchManagerZos.  The shell script can examine the return codes from the CLI and convert them into its own return values that are less than 0xF and can be handled in JCL condition code processing as values from 0xF00 down to 0x100 (with values less than that being return values from BPXBATCH itself – or zero…zero is always zero no matter how much you shift it : -  

For a sample to start with, have a look at the WASdev/sample.batch.misc project in GitHub.  You may need to adjust that to meet your own conventions or handle exit status values from the batch application itself (for which you hopefully have some standard established).