This document discusses IBM's z/OS Connect and Mobile Workload Pricing. z/OS Connect is a Liberty-based gateway that provides secure and simple RESTful access to z/OS applications from mobile, web and cloud applications. Mobile Workload Pricing is a sub-capacity pricing program that helps mitigate the impact of increased mobile transactions on z/OS workloads. Customers must track mobile transactions and report CPU usage to IBM using a new tool to qualify for adjusted pricing.

1. Insert
Custom
Session
QR if
Desired.
z/OS Connect and IBM
Mobile Workload Pricing
Ian J Mitchell,
IBM Distinguished Engineer, System Z
Middleware CTO
Session 16278
Wednesday 6th
August 2014

2. Insert
Custom
Session
QR if
Desired.

7. End-to-End Architecture for Mobile and Cloud Application
invoking z Services using APIs
Web Services
or REST based
services
On-Premise API
Enablement
Cloud APIs
Mobile
Applications
Cloud-based
Services
Enterprise
Transaction
Processing
CICS
IMS
WAS
DataPower
GW
appliance
DMZ
Access to systems of
records and enterprise
data via APIs
Enterprise
APIs
Management
Enterprise
API s
Cloud -
Integration
Services
Cloud –
Mobile App
Enablement
Service Enablement:
• Enables invocation of z
applications by remote
applications using standard
protocols (WSDL, REST)
API Enablement:
• Consumability by internal and
external developers (creation and
look up)
• Entitlement Management
(securing, workload
enforcement)
• Usage monitoring & Analytics
Cloud Integration
Enablement:
• Enabling integration with APIs
as well as technical services
Mobile Application
Development
• Invokes services and APIs

8. WebSphere Liberty Profile – What’s New ?
Extend existing enterprise data and business logic to Web, Mobile or Cloud apps
• Use WebSphere Liberty z/OS Connect for secure enterprise connectivity to easily extend
existing assets to Mobile and Cloud applications using RESTful services and JSON.
• Leverage Websphere Liberty Java Connector Architecture (JCA) feature to connect in
to and extend existing enterprise backend systems
• IBM WebSphere Liberty Optimized Adapters for z/OS (WOLA): a function of WAS
Liberty for z/OS that allows very fast, efficient, and low-latency memory to memory
exchanges between WAS z/OS and CICS, IMS & Batch.
Administer production apps with the WebSphere Liberty Administrative Center
• Flexible, extensible, mobile ready, next generation admin UI to manage Liberty Servers
WebSphere Liberty Repository to pick up new Liberty product features, samples,
and tutorials:
• Easily extend your development and production environments with new features
Different options for using WebSphere Liberty in the Cloud
• Build applications using the Liberty Buildpack and Caching services on IBM BlueMix
• Deploy WAS Liberty patterns using Pure Application Pattern service on SoftLayer
• Bring your own existing entitlement of WAS to SoftLayer or Amazon cloud environments
8

9. Problem Statement (s)
Customers on the z/OS platform today are increasingly expressing concerns about
their ability to handle large spikes of new requests originating from any number of
almost instantly available clients and systems that have a need for the business
assets available there.
The fast advancing worlds of mobile and cloud computing are putting more and
more pressure on applications and business logic located on z/OS in environments
like CICS, IMS, batch, and others.
Customers have expressed an interest in a common solution that can be used by
cloud, mobile, web and components like API management, that enables simple
discovery and secure access to z/OS business and infrastructure assets using
REST technology.
Infrastructure providers (cloud-based IaaS and SaaS providers) and mobile
services registries (ie: API Management) require a uniform way to interact with z-
based middleware for discovery, provisioning, data transformation, and service
invocation.

10. z/OS Connect
What is it and what are the benefits for customers?
z/OS Connect is a Liberty based gateway that provides a secure and simple way to
discover and call in to application assets/infrastructure on z/OS from Web/Cloud/Mobile
applications using RESTful services.
The benefits include :
• Fast on-ramp for z/OS customers to discover and reach z/OS applications securely/simply using
RESTful services. Service references can be copied from z/OS Connect and stored in any repository –
cloud based (such as IBM Cloud OE) or mobile based (such as IBM Worklight, API Management) or any
other web technology
• Light-weight and modular providing flexibility to run multiple copies on the same or different z/OS
systems and assign higher/lower priority to specific Liberty servers
• Integrated with z/OS management makes the operations of the environment automated and consistent
with the environments it is exposing
• Provides ability to standardize on security access for calling in to z/OS applications in all major
environments - CICS, IMS, batch, Unix System Services, and ISV software. Supports SAF-based
security integration allowing for individual z/OS Connect services to have unique sets of authorized
users.
• Provides ability to track and prioritize requests from cloud, mobile, web based external requestors
using standard z/OS mechanisms like SMF and WLMA. Fulfills audit/chargeback needs for access to
z/OS applications

11. WOLA
WOLA
IBM z/OS Connect
WOLA Link Server
Task CICS
Programs
IMS dependent
regions
BlueMix
IMS
VSAM
DB2
DLI
zosConnect
JSON to/from
byte[] (Cobol
copybook)
CICS
WOLA over
OTMA
WOLA direct
Batch
zosConnect
JSON to/from
byte[] (C
structure)
zosConnect
JSON to/from
byte[] (PL/I
structure)
WOLA
WAS Liberty z/OS
RESTful
RESTful
RESTful
z/OS Connect
A service that encapsulate calling z/OS target applications using REST
calls. z/OS Connect will support JSON payloads for calls from external
cloud or mobile-based clients and will enable the conversion of the
payload to the target program's expected format. It will also provide the
response payload conversion from a byte array into JSON format before
returning the response to the caller.
Data binding
conversion/routing
Mobile/
APIM
Mobile/
APIM
Security / Auditing /
Metering
CloudOE
Javascript
CloudOE
Javascript
CloudOE
Java

12. z/OS Connect Liberty under CICS
CICS
Programs
CloudOE
Javascript
CloudOE
Javascript
CloudOE
Java
BlueMix
VSAM
DB2
zosConnect
JSON to/from
byte[] (Cobol
copybook)
CICS
zosConnect
JSON to/from
byte[] (C
structure)
zosConnect
JSON to/from
byte[] (PL/I
structure)
CICS Liberty/JVMServer
RESTful
RESTful
RESTful
z/OS Connect under CICS Liberty
Same z/OS Connect implementation – the CICS JCICS service provider handles requests targeted to
existing CICS programs. CICS provides interceptors to integrate z/OS Connect with CICS security
Data binding
conversion/routing
Security / Auditing /
Metering
JCICS
Mobile/
APIM
Mobile/
APIM

13. Dependent Region
Message
Processing
Program (MPP)
WOLA
IMS
Connect
z/OS Connect Liberty for IMS
IMS dependent
regions
BlueMix
IMS
DB2
zosConnect
JSON to/from
byte[] (Cobol
copybook)
zosConnect
JSON to/from
byte[] (C
structure)
zosConnect
JSON to/from
byte[] (PL/I
structure)
z/OS Connect Liberty for IMS
RESTful
RESTful
RESTful
Data binding
conversion/routing
Security / Auditing /
Metering
z/OS Connect Liberty for IMS
Same z/OS Connect implementation – WOLA or the IMS Connect service provider handles
requests targeted to existing IMS transactions and data.
TCP/IP
OTMA
OTMA
CloudOE
Javascript
CloudOE
Javascript
CloudOE
Java
Mobile/
APIM
Mobile/
APIM
DLI
IMS
DB
ODBM
Dependent Region
Batch Message
Processing
Program (BMP)
Dependent Region
IMS Fast Path
(IFP)
Dependent Region
Java Message
Proc (JMP)
Dependent Region
Java Batch Proc
(JBP)
DLI

14. GUIDE SHARE EUROPE
Agenda:
 z/OS Connect... Mainframe Makes Mobile Magic
 Mobile Workload Pricing
 What's going on in CICS TS with IBM Design Thinking?

15. Mobile Workload Pricing for z/OS
●
Benefits
− Improves the cost of growth for mobile transactions processed in
System z environments such as CICS, IMS, DB2, and WAS
− Mobile Workload Pricing (MWP) for z/OS enhances Sub-Capacity pricing
•Mitigates the impact of Mobile on MLC charges where higher transaction volumes cause a spike in
machine utilization
•Normalizes the rate of transaction growth
− No infrastructure changes required, no separate LPARs needed
•It is an enhanced way of reporting sub-capacity MSUs
•System runs as it always has, workload execution is not altered
●
Hardware requirements
− Available to all enterprises running a zEC12 or zBC12 server (actual mobile work may run on
any zEnterprise machine including z196 and z114)
●
MWP Announcement Letters – 2014-05-06
• AP14-0219 Asia Pacific
• A14-0429 Canada
• ZP14-0280 Europe, Middle East, Africa
• JP14-0279 Japan
• LP14-0279 Latin America
• 214-223 United States

16. Mobile Workload Pricing Reporting Process
●
New Mobile Workload Reporting Tool (MWRT) – available 30 June 2014
− A new Windows-based Java tool to report sub-capacity MSUs and make adjustments
to reported LPAR MSUs based on Mobile transaction data
• Standard SCRT methodology plus new feature to adjust for Mobile workload impact
• New tool will replace SCRT for customers who take advantage of Mobile Workload Pricing
●
Customers must track mobile transactions and produce a file showing mobile
CPU consumption each month
• Record mobile program transaction data, including CPU seconds, on an hourly basis per LPAR
• Load the resulting data file into MWRT each month (IBM-specified CSV format)
• Run MWRT and submit the results to IBM each month (Replaces SCRT process)
●
MSU adjustments and monthly peak calculation for billing
− MWRT will subtract 60% of the reported Mobile MSUs from a given LPAR in each hour,
adjusting the total LPAR MSU value for that hour
• This will function like a partial “off-load” from a software pricing perspective
• When an LPAR value is adjusted, all software running in the LPAR will benefit from lower MSUs
• Tool will calculate the monthly MSU peak for a given machine using the adjusted MSU values

17. Example: reducing Mobile impact to LPAR peak
z/OS
&
Other
CICS
Measure LPAR MSUs:
Standard SCRT
methodology, SMF 70
records1,500
Usag
e
Tag Mobile transactions:
e.g. Capture CICS
transaction details (SMF
110 records) and filter by
transaction type
Other
Mobile
Other
1,380 MSUs
Subtract 60% of mobile MSUs:
-60% * 200 = -120
Measure CICS
usage:
Capture SMF 89
record in new IBM
reporting tool
(replaces SCRT);
SMF 89 is IBM usage
standard
CICS,
z/OS
&
Other
200
100
100
80
Adjusted LPAR MSUs:
Per new MWRT reporting tool
Transaction
definitions
Adjusted LPAR
MSUs used to
determine peak
for month;
Pricing & billing
BAU based on
peak
MSUs
1
2
3
4
5
6
300
Mobile
LPAR MSUs
for billing (Standard)
z/OS/Other 1,500
CICS 1,500
LPAR MSUs
for billing (Adjusted)
z/OS/Other 1,380
CICS 1,380Figures are for illustrative purposes only.

18. Example: Sample LPAR MSU values by hour
●
SCRT calculates the Rolling 4-Hour Average (R4HA) MSU
peak
− All workloads are included
Peak R4HA value = 1404 MSUs

19. LPAR MSU values adjusted for mobile contribution
●
MWRT removes 60% of the Mobile workload, interval-by-interval
− Non-mobile workload is unchanged
− Billing for the month is based upon the newly calculated R4HA curve after the
mobile workload has been reduced
New Peak R4HA Value = 1231 MSUs
MWRT savings = 173 MSUs
Provides benefit when Mobile workloads contribute to monthly peak MSUs;
Off-peak MSU adjustments will not affect MSUs used for billing.
Original Peak R4HA value = 1404 MSUs

20. Identifying Mobile Transaction Workload
●
Customers are responsible for processing their mobile transaction data into
a predefined format to be loaded into MWRT for each sub-capacity reporting
period.
− IBM must approve the data gathering methodology.
●
The data must consist of general purpose processor CPU seconds for
each mobile transaction program summarized by hour by LPAR for all
machines processing mobile transactions.
− Detailed instructions, including CSV file format, available in the MWRT user's guide.
●
Mobile Workload Pricing Defining Programs:
5655-S97 CICS TS for z/OS V4 5635-A04 IMS V13
5655-Y04 CICS TS for z/OS V5 5655-DSQ IMS DB VUE V12
5722-DFJ CICS VUE V5 5655-DSM IMS DB VUE V13
5635-DB2 DB2 V9 for z/OS 5655-L82 WS MQ for z/OS V6
5605-DB2 DB2 10 for z/OS 5655-R36 WS MQ for z/OS V7
5615-DB2 DB2 11 for z/OS 5655-W97 WS MQ for z/OS V8
5697-P12 DB2 VUE V9 5655-VUE WS MQ VUE V7
5697-P31 DB2 10 VUE 5655-VU8 WS MQ VUE V8
5697-P43 DB2 11 VUE 5655-N02 WebSphere App Server for z/OS V7
5635-A02 IMS V11 5655-W65 WebSphere App Server for z/OS V8
5635-A03 IMS V12

21. New MWP Contract Addendum
●
Mobile Workload Pricing is available for Mobile workloads running on a
zEC12 or zBC12 server with AWLC or AEWLC sub-capacity pricing
− Alternatively, if you install and operate a zEC12 or zBC12 in your enterprise you
will be eligible for MWP when running a Mobile Workload Pricing Defining
Program on a z196 or z114 server with sub-capacity pricing
●
There is a new contract addendum:
− The System z AWLC and AEWLC Addendum for Mobile Workload Pricing
− Contract number Z126-6300
●
Agreement to and compliance with the terms and conditions specified in
the MWP contract Addendum is required
− If the MWP Addendum is not implemented, MWRT Reports will be rejected!

22. Measuring GP CPU for Mobile Workload Pricing (MWP)
From Announcement ZP14-0280 (EMEA) - https://ibm.biz/MWPAnnouncementLetter
.... Mobile workloads are defined as the transactions processed by a named mobile
application, or transactions that can be identified as originating from a mobile
device.
You must be able to track and report the general purpose processor time (CPU Time)
for mobile transactions and report those values in a pre-defined format to IBM
each month ....

It is necessary to provide evidence a transaction is eligible for MWP and quantify the
GP CPU consumed.

Evidence must originate outside of the system and be associated with the CPU
measured for the request.

Some measuring techniques use an address space as the measurement 'container' and
others require the finer granularity of a transaction.

The quantified amount of GP CPU consumed must be captured to provide input to the
MWP reporting tool (MWRT).

23. Providing evidence of eligibility
We have identified two classes of evidence – implicit and explicit:

Implicit evidence:

Something about where the work is routed to – eg if all mobile work is routed to
particular servers, then all their consumption is eligible (transaction-level
measurement is not required).

This is the most invasive option for system programmers as it requires new servers or
changes to routing to existing servers.

Something about where the work arrives from – eg if particular routes are reserved for
mobile requests, then their identity can serve as evidence (transaction-level
measurement is required).

This evidence might only be known in the receiving system, and might not flow to other
systems deeper in the infrastructure.

Explicit evidence:
Something in the request itself. Requires transaction-level measurement.
• Its target transaction id, its security context, an element of its payload (an explicit
parameter asserting evidence), ...

This is also quite invasive, especially for the application developers.
You might already be operating your systems with the necessary evidence – it
won't always require large changes to provide it.

24. Quantifying GP CPU eligible for MWP

No new CPU measurement techniques have been created for MWP. It is
intended that the mobile defining products' existing capabilities can be
used to satisfy the requirements for quantifying GP CPU eligible for MWP.

It is expected that SMF records and other log data containing GP CPU
consumption measurements will be used to contain the evidence that the
transaction(s) consuming the CPU are eligible.

Using the evidence associated with the measurement 'container' (address
space or transaction), you can calculate the total GP CPU eligible for
MWP and provide it as input to MWRT.
The diagram on the following page illustrates these concepts.

25. Mobile Workload Pricing: Technology Requirements
CICS
IMS
DB2
MQ
WAS
SMF MWRT
Mobile
CPU
Measurement
MWP peak
CSV file
Mobile
Trans
Non-
Mobile
Trans
Mobile CPU Measurement:
Varies by product, application
and installation.
Types
70 & 89

26. Example 1:: Measuring by defining product instance

27. Example 1:: Measuring by defining product instance
If you are not currently measuring CPU at the individual transaction or request level, and do not wish to move to
a finer grained level of measurement, then you have the option to use existing mechanisms to route eligible
mobile workload to dedicated instances and use the SMF 89 records that are recorded with the CPU
consumption for each of the instances processing that workload. The address spaces dedicated to eligible
workload could be existing ones which you now use exclusively for such transactions, new ones that are
required to support growth in such workload, or a mixture of new and existing.
If, for example, work arrives via TCPIP, then the mobile requester will use an IP address which resolves to one or
more listening ports associated with specific address spaces running one of the mobile defining products. It is
important that only eligible workload is routed to these regions, as you will be recording the entire CPU
measurement as eligible workload for those address spaces in MWRT.
Similarly, it would be possible to dedicate intermediate resources (such as CICS Transaction Gateway) to mobile
workloads and route from them to the defining product - however only CPU measured from the defining
product's address space will be valid input to MWRT. You will need to add up the total CPU measurements for
the address spaces you are dedicating to eligible workload and use these in the CSV file input to MWRT.

28. Example 1:: Measuring by defining product instance (continued)
Some instances of defining products MUST serve both eligible and non-
eligible workloads - for example, a CICS File Owning Region cannot
be cloned into one that is used for eligible work and one for ineligible
work. In these cases you will NOT be able to attribute the CPU
consumed in such an address space to mobile workload.
Pros: does not require introduction of transaction-level measurement.
Cons: requires existing or newly created middleware instances to be
dedicated exclusively to eligible workload, with a 'fence' between the
execution resources.

29. Example 1:: Measuring by defining product instance (continued)
CICS regions
1-10
CICS regions
11-15
SMF MWRT
Mobile
CPU
Measurement
MWP peak
CSV file
Mobile
Trans
Non-
Mobile
Trans
Mobile CPU Measurement:
Calculate the total GP CPU
consumed by regions 11-15.
Types
70 & 89

30. Example 2:: Measuring by transaction name

31. Example 2:: Measuring by transaction name
Transaction names (or tranids) are a very familiar mechanism used to distinguish workloads
of different types. Although most commonly used as a functional distinction, it is common
to use them for accounting and charge-back purposes. Also tranids are already commonly
used to informing routing and workload management decisions, and many performance
analysis tools have excellent support to split out work by tranid, so extending their use to
distinguish workload for mobile CPU measurement might be appropriate.
However, this will mean defining new tranids in order to ensure that eligible and non-eligible
workload is robustly distinguished. Also, you might have application or system code which
is sensitive to tranid values already, so overloading their use for MWP might not be
appropriate, and you would want to consider one of the options below.
In CICS TS, tranids dedicated to mobile workload can be associated with the same
application programs and run alongside tasks using the existing tranids.

32. Example 2:: Measuring by transaction name
CICS regions
1-10
SMF MWRT
Mobile
CPU
Measurement
MWP peak
CSV file
Mobile
Trans
Non-
Mobile
Trans
Mobile CPU Measurement:
Calculate the total GP CPU
consumed by MOB1
transactions
Types
70 & 89
MOB1
MOB1
MOB1
TRN4
TRN4
TRN4
Type 110

33. In Summary
●
Mobile Workload Pricing (MWP) Benefits
− Improves the cost of growth for mobile transactions processed in
System z environments such as CICS, IMS, DB2, and WAS
− MWP for z/OS enhances Sub-Capacity pricing
•Mitigates the impact of Mobile on MLC charges where higher transaction volumes
cause a spike in machine utilization
•Normalizes the rate of transaction growth
− No infrastructure changes required, no separate LPARs needed
•It is an enhanced way of reporting sub-capacity MSUs
•System runs as it always has, workload execution is not altered
●
Key requirements
•Available to all enterprises running a zEC12 or zBC12 server (actual mobile work
may run on any zEnterprise machine including z196 and z114)
•Use a Mobile Workload Pricing Defining Program to process mobile transactions
•Implement sub-capacity using AWLC or AEWLC under standard pricing terms
•Meet the mobile workload tracking and reporting requirements