CICS / WebSphere

Mobile devices often operate with restricted bandwidth, potentially costing the end user, so restricting the data that’s sent between the mobile and the mainframe to the minimum required makes more sense. 

So, you have a choice: preserve the rich interface and reuse it on the mobile, which for many will be the shortest route to mobile enablement, or create a set of discrete interfaces for the mobile application.

Step 2: Show Me the Copybook
We imagine for many people the first time they approach CICS from a mobile device they will want to exploit an existing service probably written in COBOL. We’re going to assume that’s the case for the remainder of this article, and describe how to call a COBOL-based service from a mobile client.

Having decided on our target application interface, we now need to create the necessary bindings to convert the inbound JSON data into a COBOL language structure. The CICS TS Feature Pack for Mobile Extensions provides tooling in the form of an assistant, DFHLS2JS, a JCL procedure that takes as input a language structure, such as a COBOL copybook, and creates the required JSON schemas and bindings to map between the two.

Running the assistant is a simple process: You configure a few parameters that point to the source copybook, the language type you’re converting to/from, which in our case is COBOL, and indicate where you want the resulting binding file and request/response schemas to be created. This process is similar to creating a SOAP-based Web service.

Step 3: Defining the Required CICS Resources
Once you’ve created the binding files and schemas in the previous step, you need to add some resource definitions to CICS that define your newly created service(s). Again, this step follows the same pattern you would use for defining a normal Web service to CICS:

1. Define, install and enable a JVMSERVER. JSON parsing is dependent on the AXIS 2 run-time hosted in a JVMSERVER, which is eligible for offload to an IBM System z Application Assist Processor (zAAP).
2. Create a TCPIPSERVICE resource that defines the port on which inbound requests are received.
3. Create a pipeline configuration file. The feature pack contains a simple pipeline configuration file (jsonjavaprovider.xml) that you can use and customize (see Figure 1).
4. Create a PIPELINE resource that specifies the location of the pipeline configuration file and where the bind file for the service can be found in IBM zFS.
5. Perform a PIPELINE scan to automatically create the required WEBSERVICE and URIMAP resources necessary to invoke the service.

Assuming you have program autoinstall enabled, that’s it. If not, then you will also need to create program definitions for the programs defined to run in the pipeline.

Example PIPELINE Configuration File
We’ve highlighted the interesting parts of an example PIPELINE configuration file in Figure 1, showing that you must specify the JVMSERVER defined in step 1 and reference the AXIS 2 handler.

 

4 Pages