WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #91: The z/OS Native Command Line Interface

By David Follis posted Wed May 20, 2020 08:18 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

A while back we talked about a command line interface (CLI for short) called batchManager.  This is just a little Java program that uses the Liberty Batch REST interface to submit jobs and perform other batch-related operations.  On z/OS there is a second CLI called, conveniently, batchManagerZos.  Why have two?

There’s nothing wrong with the Java CLI (batchManager).  But given a z/OS environment there are a few things that could be made easier or simpler.  First of all, since batchManager is written in Java, you have to start up a JVM to run it.  In a z/OS environment a Java Batch job is likely being run from inside some JCL.  One step of that JCL job will be used to submit the Java Batch job (more on this topic next time).  Well, if you’re going to have to start a JVM in order to submit the job, why not just start the JVM and run the batch work right there?  That makes the first difference between batchManager and batchManagerZos the fact that the z/OS specific CLI is written in ‘C’ and thus doesn’t require a JVM.

It is also often the case that the JCL job submitting the Java Batch job is running on the same z/OS system as the Java Batch job will run on (or at least where a Liberty Batch Dispatcher is located).  That means going through a TCP/IP connection to drive a REST interface is a bit heavy.  WebSphere Liberty supports the WOLA (WebSphere Optimized Local Adapters) interface which allows direct cross-memory communication between the client and server.  The batchManagerZos CLI uses WOLA to communicate with the target Liberty server.

Using WOLA means the communication doesn’t flow over TCP/IP which means it doesn’t need to be encrypted which allows you to avoid the configuration required for SSL.  That simplifies the setup.  The WOLA protocol also just ‘picks up’ the identity of the client and propagates it to the server (lifting it from the associated ACEE).  That means the client doesn’t have to supply a userid/password as part of establishing the connection.

Of course, SOME security set up is required to enable WOLA and allow the client to access the server using WOLA services. 

And, since the ‘L’ in WOLA stands for ‘Local’, batchManagerZos can only communicate with servers on the same z/OS system.  It can’t reach across the sysplex to a server on a different z/OS system. 

Next time we’ll look at integrating batchManagerZos calls into a JCL job.