A Beginner’s Story: An Approach of Mobile to Mainframe
Step-by-step guidance on using APIs to let mobile applications tap in to mainframe data.
At a recent SHARE conference, I learned about the existence of IBM’s z/OS Management Facility (z/OSMF) and its Representational State Transfer (REST) Application Programming Interface (API). I was really excited to try some of these APIs after learning about them. Using this knowledge as my starting point, I decided to learn what other pieces would be needed to create a basic mobile application that could access mainframe data. My goal was to learn how all the parts fit together, end-to-end, coming from a place where I did not even know what others parts existed.
In this article, I will share a high-level overview of the bits and tools I used to prototype a mobile application capable of accessing mainframe data. Specifically, I will focus on creating an Android application to retrieve and display z/OS job information. There are other approaches to access mainframe data, but I found this to be a light, straightforward means to learn something new.
Mainframe development offers a unique environment to work on really exciting and complex projects. This is especially true when mixing assembly and metal C, running in different addressing modes, executing in supervisor state, switching PSW keys, entering cross-memory mode, scheduling SRBs and maintaining proper system integrity with escalated authorizations. However, mainframe development can also be viewed as incredibly insulated from the distributed and mobile world.
Putting APIs to Work
Getting z/OS job data off the mainframe and onto an Android device may seem like a complex problem; however, there is a simple and elegant solution in the form of an API. I would make use of the APIs available through z/OSMF, and I planned to use the z/OSMF REST APIs that retrieve z/OS jobs’ data. This seemed most interesting and relevant to me. It is worth mentioning that there are other groups of APIs available through z/OSMF. For example, there are APIs that can be used to retrieve z/OS dataset members.
If z/OSMF access is not immediately available, you can always test against one of many Web sites that host JSON data through a REST interface. Early on, I used these sites to experiment with REST before trying to get legitimate mainframe data.
Making Mainframe Mobile-Ready
Mobile applications may be written native to a specific OS, Web-based for multiple platforms, or hybrid combining native and Web-based elements. To keep scope small, I elected to write a native application for Android, and Java is the language used for developing native Android applications.
When working with Java, you need to download and install the Java Development Kit (JDK). The Java Runtime Environment (JRE) is also required, but fortunately this is bundled with the JDK if you do not have it already.
Android Studio, which is built on IntelliJ IDEA, is the newest available development environment, and this is what I chose to use for my development environment. Within Android Studio I accessed the Android Software Development Kit (SDK) Manager and downloaded packages for my target API level (my device’s OS level).
The Android Virtual Device (AVD) Manager is used to define and run emulated Android devices. The emulated devices can run painfully slow if not used in conjunction with the Intel x86 Emulator Accelerator, which can be found and installed under the Android SDK Extras folder.
When creating a new project using a blank activity, all of the minimum pieces are built automatically to make your first “Hello World” Android application. After getting to this point, I took a bit of time to learn a few introductory basics of Android. I found it valuable to learn about the Android “Activity” (especially the Activity lifecycle), how to define screen layouts through Extensible Markup Language (XML), and associate a view that will ultimately display the results of my API request.
Having already seen some of my z/OS job data through a Web browser, I needed to retrieve that same data programmatically through Java then parse the JSON response to populate my mobile display. Due to the numerous online resources, I found plenty of packages available to accomplish these things.
One complication that I ran into was supplying the logon credentials programmatically with the security protocols that were in place. Once again, I found packages and sample code online to assist me with this as well. Another complexity that I came across was that the API request calls made in Java had to be done as asynchronous tasks. Once the asynchronous tasks were nailed down and I could programmatically obtain my data, I finally surfaced my parsed JSON results into my Activity’s layout view.
I wanted to test my Android applications both on an emulated device and a physical device. After defining an emulated device, building my project caused the emulator to startup and run my newly compiled Android project without any other setup.
Testing my Android application on my physical device required that I enable USB debugging. In my case, I had to tap my device’s build number seven times to enable this. Also, before my Android application could access any mainframe data, I had to make sure that my device was connected onto the proper network either through Wi-Fi or through a VPN.
Overall, it is possible to create Android applications from scratch by taking things step-by-step. All the pieces to get an Android application up and running are free to use, and you can test on an emulated device if you do not own a physical device.
Keep in mind that when you are left to work through the details, this is not a trivial undertaking. I found the experience of going through this exercise incredibly rewarding and challenging, and I hope that you have been encouraged to explore some new technology in a similar fashion.