z/OS Explorer Aqua is an software platform that provides the ability to install any, or all, of currently sixteen different tools into a single workbench. The benefits of doing this are to optimize integration scenarios between tools, only having a single desktop offering for IT shops to assemble and distribute to z/OS developers and system programmers, and a smaller runtime footprint for end users to launch on their PCs or Macs. The vector for the z/OS Explorer Aqua project has aways been one of increasing simplicity for customers, for end users, and for IBM.
I was challenged today by a customer who told me that in doing this we had introduced an unintended complexity, which was that when he assembles a single desktop solution containing an number of Aqua tools he is responsible for CICS Explorer support internally in his mainframe shop and now he now gets helps requests for the MQ Explorer, Fault Analyzer, File Manager, and other tools that are now present in the combined desktop offering. How can he ensure that when one of his end users has a query with function in an Aqua based workbench he can identify easily which constituent tool has caused this. This blog covers how to do that so the end user can see which tool is the active one at any particular time.
IBM has the same issue
At IBM we’re used to this problem with how we support our Aqua customers. A user might raise a help request against a workbench that starts with IBM Developer for z Systems that gets identified as being in the CICS Explorer component and routed to the IBM team who thereafter provide support and any potential fix. The trick for this lies in how Java classes are named together with a utility called Plug-in Spy.
Java package naming – com.ibm.xxx
The z/OS Explorer and its tools are written in Java and to ensure that different code modules, or .class files, don’t collide when they are run in the same Java virtual machine, a unique name is given to each Java class. A Java class name is made of string segments, and the first part of the name is designed to be unique so there is no duplication and it’s always possible to identify where a Java class originated. Within IBM all our classes are prefixed with com.ibm. and after that with an identifier for the group who created it, e.g com.ibm.cics from the CICS team or com.ibm.mq from the MQ Team. Whenever a problem comes into IBM we often ask for the log files as these will capture the name of the Java class that writes each entry. For the customer who was supporting his users it wasn’t so much dealing with errors but queries about operating a piece of function. This is where Plug-in Spy comes in.
Plug-in Spy reveals where you are in Aqua
To activate plug-in spy use the keystroke Alt+Shift+F1, or on a Mac Option+Shift+F1. This will open a pop-up window that shows details about the area beneath the cursor. In the view below I’ve mixed elements from five different Aqua tools together.
With the cursor above the MQ Explorer – Navigator selecting Option+Shift+F1 (or Alt+Shift+F1 on a Windows PC) you can see the Plug-in Selection Spy window. This shows that the active class view is from the contributing plugin com.ibm.mq.explorer.ui. This is part of the MQ Explorer.
The above example was possibly not necessary as the view title itself is MQ Explorer – Navigator, but things aren’t that clear in view titles often. The perspective has a view called MQ Connection Definitions. This could be mistaken for an MQ Explorer view, but plug-in spy reveals a different origin. The active help context identifier shows that this is contributed by com.ibm.cics.core.ui. The CICS packages are used by the CICS team so this is part of the CICS Explorer, and is the view used to show MQ Connection Definitions in a CICS CSD file.
The Fault Analyzer view at the bottom of the perspective possibly comes from Fault Analyzer, and the plug-in spy reveals that it comes from com.ibm.etools.fa.pdclient.analytics plugin. The FA is the two character prefix used by fault analyzer so it does indeed come fault analyzer.
The two or three character name that maps to a particular tool isn’t always the third segment of the package name, as shown above where FA is the fourth segment in com.ibm.etools.fa.pdclient.
Using plug-in spy it’s possible for a user to select an area of their z/OS Explorer workbench that may have tools from multiple sources and determine which tool is responsible for which user interface element, and from that where they should go for help and support.
One customer I worked with recently actually wrote their own help assistant plugin that combined plug-in spy’s Java API to determine what the view was together with a chat client plug-in to Eclipse so that their users could open a window directly talking to the relevent group in their IT shop for help. Another customer extended this so that they did a lookup on the CICS transaction ID that was select and mapped this to the application team who supported that part of their software and routed e-mail and chat requests directly to the correct group.
There are a host of other plugins available and tricks and techniques to extend the z/OS Explorer Aqua platform. Please let us know if you are thinking of more “I find this hard” or “wouldn’t it wonderful if I could this” requests, and we’d love to help find solutions to make you successful with z/OS Explorer Aqua as a tools platform for your extended z/OS IT organization and end users.