There is suddenly new interest in monitoring Java on mainframes - I'm not talking about running lots of Java VMs on Linux but about running Java against big mainframe systems on z/OS. This might be about modernising legacy COBOL applications (Java skills are easier to find than COBOL skills these days) or about extending the legacy with new business functionality. JAVA is very flexible, you can use it in DB2 stored procedures, or in CICs, or even in IMS programming (yes, IMS database is still in active use). According to BMC's 2015 Mainframe Survey, 46% of those surveyed say that Java usage on their mainframe has increased by over 10% in the past two years; and 70% of respondees reporting growth indicated that writing new applications in Java was a key factor in this.
That's good - looked at objectively, the mainframe is the "best" business computing platform available today and (provided you know what runs on it and when; and can ensure that it is heavily loaded), it can even be an extremely cost-effective platform. However, a poorly managed or neglected mainframe can be an expensive and poorly understood "black hole", which sucks up resources - basically, it's a governance issue.
Although Java is an opportunity to be exploited, the question of managing this Java then comes up - good governance of resources and outrcomes - as mishandled garbage collection (say) can impact critical mainframe applications. If asked, I would have said that this wasn't really a problem for mainframe support, as the mainframe separates different workloads well and collects information about just about anything and everything. Now, after talking to Jay Lipovich (Principle Product Manager, zSolutions Optimization - aka. BMC's mainframe business), I'm modifying that opinion a bit. A mainframe Java environment is different to the environments many Java experts are used to - in particular, zIIPs are available and (because vendors don't charge for zIIP processing) it's important to move as much processing onto zIIPs as you can (and this is not an issue you'll meet off the mainframe).
So, I think that one issue that monitoring JVMs on the mainframe hits is a mindset problem - people used to monitoring JVMs aren't used to the mainframe mindset and terminology (and vice versa). This is the sort of thing that all mainframe software manufacturers - IBM, BMC, CA Applications, Compuware - are promising to address, although I can believe that there might be deeper technical issues to address too.
BMC's product addressing this is Mainview for Java Environments, which GA'd on May 6, 2016. I think that BMC really does recognise Java opportunities on the mainframe (from modernisation with mobile apps, through zIIP, to simply the availability of Java talent), although it is not alone in that. But it also recognises that Java behaves differently to COBOL and PL/I; doesn't share resources in the same way; and appears in different environments (from CICS to DB2 stored procedures), where it can impact performance, availability and MLC (IBM's Monthly License Charges; see here for an idea of how complex these can be) in unexpected ways. So, Mainview for Java Environments autodiscovers JVMs, monitors key metrics in real-time, detects abnormal workload activity, and has customisable dashboards (so you could present a high-level view of your Java estate to management, which I think is important). Perhaps its most obvious ROI is that it provides information that can help to ensure that Java is executing on zIIPs whenever possible, but perhaps its best return, longer term, is that it helps to eliminate the mainframe Java "black box".
I was pretty impressed by the demo I saw - good visual interface, plenty of functionality. Other tools are available of course (for example, here and here) and you'll need to check out their specific capabilities for managing mainframe JVMs, but I can believe BMC's claim that it allows you to "deploy Java on z with confidence" - and I do think that Java on z/OS is something that companies with mainframes should be actively researching, and then exploiting.