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 iTunes, Google Play, Stitcher, or use the link to the RSS feed.
Multi-step batch applications consist of a lot of steps that run your application code. But sometimes there are utilities that you have to use. How do you invoke those from inside a Java Batch application? You might be tempted to blend JCL jobs that run the utilities with steps that submit Java Batch jobs, which will work. But beware of the dataset allocation issues we talked about last time.
Before you try that, you might check for a Java interface to the utility you need to use. Conveniently, the JZOS library provides interfaces to both DFSORT and IDCAMS.
DFSORT is the IBM sort product, although under the covers it might be replaced by another product – the JZOS API doesn’t care. You can use the sort utility to do all sorts of very clever things, often very fast.
IDCAMS is the utility for managing VSAM datasets and ICF catalogs. A quick search online tells me that IDC is the IBM product prefix and AMS stands for Access Method Services. DFSORT apparently stands for Data Facility Sort…I always thought of it as my personal sort (starting with my initials…).
Anyway…. How does this help you? Well, having a Java API that drives the existing utility means that you could create a batchlet that calls the utility. Where you need a step in a JCL job that calls the utility, you simply have a batchlet step that calls the API that calls the utility.
But what about parameters? Both utilities support a pretty extensive (and sometimes lengthy) input syntax to tell it what to do. Normally that is just instream data in the JCL. How do you provide that to a batchlet that is calling an API?
Remember that any batch artifact can have string properties set in JSL that are injected into the artifact (the batchlet in this case) at runtime. If we set a property in the JSL that is the input string to the utility, it will get injected into the batchlet and be able to be passed to the utility. You might want to do this as a JSON string to make it easier to work with.
If you’d like to see more detail, check out WP102636 in IBM Techdocs which provides samples. Of course, for production use you’d want to ‘productize’ these samples to handle errors and such in a better fashion. But it is a start.