2

Is the approach of running java batch programs in Liberty profile (supporting JSR352 specification) on z/OS relatively new to the market or been for a long time ?

The reason behind this question is because, am hearing that this is a relatively new attempt by IBM and there are not much of live systems in the market running in this approach. Is that true ?

Note: I understand that the JSR352 has been there for quite sometime but, my question is specific to its support by the Liberty profile in z/OS (mainframe)

piet.t
  • 11,718
  • 21
  • 43
  • 52
yathirigan
  • 5,619
  • 22
  • 66
  • 104

2 Answers2

5

Support for JSR-352 showed up in WebSphere Liberty as part of the Java EE7 support delivered in 8.5.5.6 which was back in June of 2015. It is supported on z/OS and all the other platforms supported by Liberty. There are some extra features supported only on z/OS (i.e. SMF recording, a z/OS-specific Command Line Interface).
Support in WebSphere traditional for IBM's proprietary Java Batch product (WebSphere Compute Grid) goes back at least a decade (on z/OS and distributed platforms).
There's a lot of information about Liberty JSR-352 support (especially on z/OS) starting from here: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102544

DFollis
  • 419
  • 2
  • 5
  • Thank you. Few folks whom I spoke to were not confident stating that JSR supported Liberty profile isn't mature or well proven in the industry for production grade systems. So they were suggesting to build and run java programs invoked via BPXBatch. I feel it is not worth to write the batch logic ourselves rather, we should be leveraging frameworks like Spring Batch and run them on Liberty. Would you have any thoughts on it ? – yathirigan Aug 14 '17 at 15:38
  • 2
    BPXBATCH (or the JZOS launcher) is a common place to start with Java Batch on z/OS. But it can easily lead to creating your own homegrown framework. There are a few implementations of JSR-352 besides Liberty. Spring Batch is another proprietary model, although it supports a JSR-352 mode. There are production users of Liberty Batch, including on z/OS, but I can't be more specific. We have also made quite a few improvements to the operational extensions since June, 2015 in response to customer requirements (RFEs). – DFollis Aug 14 '17 at 19:11
  • What are the advantages of using a batch scheduling framework inside Websphere compared to using a traditional mainframe batch scheduler such as TWS (OPC) or CA7 using JZOS (I would avoid BPXBATCH like the plague)? Mainframes already excel at running batch workloads and from what I've read of JSR-352 it doesn't seem like much of an improvement other than being able to split flows. Traditional mainframe batch schedules acheive the same as splits just running one step batch jobs, considered best practice by most z/OS shops. – David Crayford Aug 15 '17 at 04:17
  • Doesn't running the Java batch reduces the MIPS consumption? "Mainframe offload – on IBM z/OS Java workload is eligible for offload to specialty engines1, which provides a financial benefit to running Java" (Ref: WP102544 document from IBM) – yathirigan Aug 15 '17 at 04:58
  • @DFollis Can i invoke a Spring Batch based jar using the BPXBatch utility ? I can have the spring jars either packaged within my batch application jar or refer it from classpath. is that possible ? – yathirigan Aug 15 '17 at 05:01
  • @DavidCrayford: Actually we don't have a batch scheduling framework inside Liberty. You'd use a traditional enterprise scheduler (like those you mentioned or others) to run a script (or JCL that runs a script) that invokes our batchManager (or batchManagerZos) Command Line Interface to drive the JSR-352 job inside Liberty. The script waits for the job to complete and gets the joblog back. So the Enterprise Scheduler doesn't know the difference. I'd say the checkpointing (and error handling stuff) is the best part...you'd end up writing that all yourself, but also partitions and split/flow – DFollis Aug 15 '17 at 20:16
  • 1
    @yathirigan: Anything in Java will generally run on the zIIP engines instead of the GPs which generally reduces cost. There are exceptions and special cases and cost is complicated.... As to Spring Batch from BPXBATCH (or JZOS) I don't know... I think SpringBatch can run in a JSE environment so that would seem to make the answer yes... – DFollis Aug 15 '17 at 20:20
  • we have started trying to run a spring batch app by invoking via BPXBATCH. Seems some error in picking up the main file and the team is looking into it. – yathirigan Aug 17 '17 at 07:57
2

@yathirigan Java would not be viable on a mainframe if it were not for zIIP processors. Compared to traditional mainframe batch languages like COBOL or PL/I it uses enormous amounts of resources, both CPU and memory. One thing for sure is that you need to make sure you've got got enough zIIP engines for your workloads because if Java workloads spill over onto GCPs you may find your monthly license charge has gone through the roof.

David Crayford
  • 571
  • 1
  • 3
  • 10
  • that is a good heads-up warning to have. Thank you. Right now, we have a good chuck of processing power in zIIP engines unused, so we are taking a small step to offload few batch from COBOL to Java. With this warning, we will monitor the usage closely as we start moving programs one by one. – yathirigan Aug 16 '17 at 04:17
  • 1
    It's possible to configure z/OS so that Java workloads only get dispatched to zIIPs and never to GCPs. This may be acceptable for batch but it's certainly not for transactional systems. IIRC, there is a 2 to 1 rule so you can only acquire a maximum of two zips for every one GCP. We've got a customer who wants to add more zIIPS but can't because they will have to buy additional GCPs and their software licenses will increase. They would rather occasionally spill onto GCPs then buy extra engines. – David Crayford Aug 16 '17 at 06:22