Jul 22 ’14
Extending the Reach of the Mainframe to the Mobile System Administrator
Far from being left behind in the mobile application market space, the IBM mainframe is in a prime position to exploit its existing suite of applications to become a major player in the tablet and smartphone world. Here we will show you how this can be accomplished.
For years, command-line interactions with the mainframe have been derided and used as evidence of its growing irrelevance. However, now this so-called legacy system positions these applications to be exploited by Web services and made accessible to any mobile device.
To illustrate this capability, we created a prototype based on the CA Technologies VM:Manager suite, which provides the user with a systems management interface to their z/VM system. This might be considered a strange choice perhaps, as most mobile applications tend to be written for clients of the business, not system administrators. However, given the sensitivity of exposing such an interface, the security issues involved with mobile access are more acutely examined.
Note: This isn’t a sanctioned product or a project of CA Technologies. As long-term users of their products, our familiarity enabled the quickest way of demonstrating how mainframe services can be “mobilized.”
Other key technologies that enable this mobilization include:
• Web services, which are simple web methods that invoke the commands and capture the responses.
• Web Service Definition Language (WSDL), which is an XML-based interface description language used for describing the functionality offered by a Web service. A Web service provides a machine-readable description of how the service can be called, what parameters it expects and what data structures it returns.
• Tools that consume WSDL and create program stubs callable by the mobile application
VM:Manager Mobile Overview
The VM:Manager suite is a rich collection of services that let you manage the z/VM system in a consistent, controlled, robust and auditable way. The suite of packages enables you to control such functions as:
• System accounting data with VM:Account
• Tape and tape libraries with VM:Tape
• Backup and recovery with VM:Backup
• Data archiving with VM:Archive
• Security and user administration with VM:Secure
• Batch jobs with VM:Batch
• Spool files with VM:Spool
• System operation with VM:Operator
• Scheduling with VM:Schedule.
IBM has products such as Operations Manager, RACF, Dirmaint, etc. that provide similar functionality.
The VM:Manager products have a long, rich history within many z/VM installations and have become an integral part of day-to-day operations. However, current function is restricted to either line-mode commands from the console or via 3270 full-screen dialogs. Our prototype exploits this function via Web services to enable interaction with mobile devices such as tablets or smartphones. We were able to achieve this without modifying the current suite of VM:Manager products.
We “mobilized” VM:Manager by implementing three components:
• An extension to the z/VM System Management API (SMAPI) that provides VM:Manager services. Such user extensions are a supported feature of the facility.
• A Web services provider that implements web methods that represent VM:Manager functions. This is a Linux-based appliance running Apache or a lightweight Web services facility such as XSP.
• A VM:Manager Mobile application that runs on a tablet or smartphone that exploits the Web services published by the server.
Using the technologies described in the previous section, we developed an integrated system composed of the VM:Manager back-end, a Web services component acting as a middleman and an application residing on the mobile device.
The flow of a request/response is as follows:
1. An application logs into the Web service as described in the following section titled “Security and Authorization.”
2. A web method is invoked causing the Web service to validate if the user is a) logged on and b) is authorized to utilize the specified web method using the profile returned as part of the log-in function.
3. A SMAPI request is issued by the web method, which contains the service being requested, along with the parameters required by that service.
4. The SMAPI agent validates the request and parameters (for presence, not for content) and issues the required VM:Manager command.
5. The SMAPI agent processes the data returned from the VM:Manager command:
• XML tags are used to identify command and parameters. The output from the VM:Manager commands is uninterpreted and wrapped in generic tags.
• The SMAPI client parses results returned from each command and wraps each field in a command-specific tag.
• The return code from the VM:Manager command is placed into the root tag, along with any reason code (<VMCOLON rc=”rc” reason=”reason”>).
6. SMAPI returns the XML data as a string to the Web service, which then passes it back to the originator of the request.
Security and Authorization
For this prototype, we implemented the following security:
• The Web service provider maintains control over commands that may be issued.
• Transmissions are via https and require user/password authentication.
• The Web service uses a SMAPI call to validate user/password and have a “profile” returned that describes the functions that user is allowed to perform.
• The SMAPI interface uses native facilities to validate the user/password combination.
• A trusted root certificate is required on the Web service server.
The Web service was written in C# and uses either Apache with the mod_mono module or the XSP lightweight ASP.NET server. The vast majority of web methods map directly to a single VM:Manager command. Figure 1 shows a sample of calls. The web methods are very simple and take the form shown in Figure 2. These same Web services may be accessed from any endpoint, whether it be a mobile device, a browser or an application. In Appendix A (available at http://esmpubs.com/nm2mv), we show a simple Java application that will avail itself of the services offered.
Using an unchanged VM:Manager suite with a user-written, REXX-based SMAPI agent called VMCOLON, we’ve implemented a number of web methods that enable network-connected devices to access the mainframe services. These web methods invoke the SMAPI extension, which then issues the appropriate VM:Manager command, captures its output, wraps XML around it and returns the results to the web method.
For example, users or administrators can login to the service; interrogate their jobs; respond to requests; hold, resume or cancel jobs; and logoff—all by interacting with the web methods presented to them by the Web service.
Using the APIs published by the Web service, and available by interrogating the WSDL produced by the server, we’ve created a prototype mobile application that executes the web methods. The user is presented with a series of dialogs and displays that enable the VM:Manager components to be managed.
The screen shots included with this article were captured from a Galaxy S III. This same application has also been deployed successfully to a Nexus 7.
The user interface (UI) isn’t pretty, but it does illustrate the important concepts; in particular, combining the output of multiple transactions to create a single display. By doing so, the user is presented with a consolidated view of all the pertinent information relating to the facility and is able to act on all that information. This simplifies the navigation process and the interaction between user and facility.
The key is to have the server present web methods that do a single well-defined task and allow the application on the mobile device to make requests of one or more of these methods before returning the results to the user.
We used these tools to create the application:
• REXX to create the SMAPI extension
• SMAPI to start/recycle virtual machines and to invoke the user-written extension
• XSP/Apache to provide access to the web methods
• gcc to create a stub between the web methods and SMAPI
• Xamarin Studio to create the mobile application.
In addition, prior to the mobile application being written, the Web services were executed using a simple user-written driver program (see Figure 3) that issued requests and displayed the results on the Linux console. In this example, a user is checking his backup jobs, holding one of them and then releasing it.
We created the mobile application using the Xamarin Studio tool on a Mac. This tool supports creating applications for iPhone/iPad, Android and MacOSX. It integrates with the iPhone/iPad and Android emulators, which allows the developer to test the application before deploying it to a real device. This tool, and tools like it, will import WSDL data from the Web service provider and create stubs the application can call to invoke the desired web method.
The user can install Android applications from their own locations rather than having to go to a virtual store. In this case, we downloaded the application from the same web server providing the VMCOLON Web services. Clicking on the file with the .apk extension starts the installation process (see Figure 4).
The Sign-On Screen
Following the installation step, the application can be started. The first screen of the VM:Manager Mobile application is the sign-on screen (see Figure 5). From here, the user enters his z/VM credentials. A log-in request is generated to the Web service, which then initiates a transaction to the z/VM Systems Management API where the user/password combination is verified and a profile is returned. This profile describes which functions the user is allowed to perform. Each of the web methods uses this profile to ensure the user is authorized to use it.
If the user’s credentials are verified, the mobile application will then kick off the product status function.
Note that the screen shots presented here show an early version of the prototype where the http protocol was used rather than https because the Android device we used didn’t accept self-signed certificates (except for establishing Virtual Private Network [VPN] connections). In practice, https with certificate authority signed certificates would be used to enable secure communications across public networks.
The product status activity involves executing a simple transaction that will return a list of all products supported by VM:Manager, whether the product is installed, and, if so, whether it’s available (see Figure 6). For those products that are available, a button is enabled that will allow the user to get further details. There’s a second button that will let the user recycle the server. For servers that are down, the user is provided with a button that will start the server. The table containing the products is scrollable.
Starting a Server
If the user clicks on the “Start” button, a Web service request is generated that will result in a SMAPI Image_Activate operation to be performed. Figure 7 shows that the user has requested the start of the VMSPOOL facility. This will cause the z/VM system to bring up the virtual machine and start executing the VM:Spool suite. When the operation is completed, the screen is automatically refreshed and that facility may now be interrogated.
Getting Product Details
If the user clicks on a product button, a new activity is initiated. As shown in Figure 8, the user clicks on the VMACCT button, which results in a Web service being initiated and two commands within VMCOLON being executed: the first to get version data (VMACCT QUERY VERSION) and the second to get the service data (VMPTFS VMACCT).
Interaction With Facilities
On each of the product status screens there’s a button that enables the user, if authorized, to interact with the facility. For example, by clicking on the VM:Tape button, there are several services the user can invoke, such as simply querying what tape drives are under its control (see Figure 9). Similarly, contrast the 3270 presentation of VM:Archive with its mobile counterpart (see Figures 10A and 10B).
Using Web services that exploit the once derided command line interface of the mainframe’s operating system and applications provides a quick and reliable way to extend the reach of the mainframe from the data center to the mobile user. In the prototype described here, the time from concept to Android application was just less than four weeks of a single programmer’s part-time efforts. The programmer hadn’t been exposed to the Android development environment before, but it was intuitive, powerful and enabled the application to be created in just over a week.