WP102726 at IBM Techdocs: ibm.
com/support/techdocs
Three Levels
The opening chart of the deck has this picture:
This sets the stage for the way in which the presentation is constructed. The intent is to offer
information at a level of detail appropriate for the audience. Executive management is more interested
in strategic value; technical staff more interested in detail and design/operational issues.
© 2017 IBM Corporation 1 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
Executive Management
The first chart in this section offers an overview of the focus points assumed to be of interest to
Executive Management:
This chart provides an initial platform for discussion to insure the information design maps to the
expectations of the Executive Management audience. The next chart is the final chart for the section:
This chart provides some detail to the four "points of interest" discussed on the previous chart. This
chart should be used as a backdrop for discussion of the four points. Additional areas of focus should be
noted and discussed. Points of disagreement should be noted and discussed as well. The objective of
this discussion is a better understanding of the Executive Management's business goals, and a better
understanding of how WebSphere Application Server z/OS maps to those goals.
© 2017 IBM Corporation 2 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
Technical Management
The points of interest for Technical Management are offered as:
The points offered on this chart should be reviewed and discussed to determine if they accurately and
comprehensively capture the interests and concerns. Note and discuss any additional points offered by
the Technical Management. Note and discuss any disagreements with the points offered here.
The first bullet from the initial chart is expanded upon. The points here emphasize the flexible nature of
© 2017 IBM Corporation 3 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
the design of WebSphere Application Server z/OS: it being based on Java; it being based on open
standards; there being a rich set of development tooling around Java and Java EE; and Liberty z/OS's
lightweight and flexible design.
Flexibility does not have to mean lack of control. Traditional mainframe change controle procedures can
be utilized with WebSphere Application Server z/OS as well.
Vendor and platform "lock-in" is an oft-cited concern. A solution that introduces lock-in will be viewed
cautiously unless no alternatives exist and the value statement is overwhelmingly compelling. The
points made on this chart emphasize the open-standard and cross-platform nature of WebSphere
Application Server z/OS. Further, the z/OS platform can be exploited where deemed of value, and that
can be accomplished without changes to the application design or programming.
© 2017 IBM Corporation 4 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
There are several emerging architectural patterns being evaluated by most organizations. These include
technologies such as APIs and micro-services. These patterns aim to provide greater flexibility and
agility to the business. This chart offers that WebSphere Application Server z/OS -- and in particular
Liberty z/OS -- can participate in these new patterns because it is built on open standards such as TCP,
HTTP, and REST. Further, WebSphere Application Server z/OS (including Liberty z/OS) can participate in
established patterns such as servlet, EJB, and MDB applications.
The topic of cost management is on the minds of nearly every executive and technical manager in the
© 2017 IBM Corporation 5 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
mainframe environment. Adequate time should be dedicated to discussing the points on this chart.
"Costs" take many forms, but for workloads on z/OS the focus is most commonly on general processor
(GP) cycles consumed. That is because monthly license charge (MLC) software charges are often based
on GP cycles used. Therefore, it is common to focus on reducing overall GP usage.
Two key points here:
1. WAS z/OS uses Java, and Java is eligible for offload to "specialty engines" (zIIP processor),
which do not count towards MLC license charges;
2. The "container pricing" model, new with z/OS 2.3, provides even better shielding of GP cycles
from MCL license impact (see the link on the chart); and
Then the discussion revolves around broader cost considerations and whether cost reduction can be
achieved through consolidation back to z/OS using WAS z/OS for Java workloads.
There is no simple formula when it comes to determining the cost of workloads. That's true on the
mainframe as it is on other platforms. The point of this chart is to surface the discussion and work
through the conversation with an understanding of cost avoidance mechanisms available for Java
workloads, including WAS z/OS.
Application workloads are in place to serve a business purpose. Part of that purpose is to provide the
required throughput and response time. What is required varies by business application.
There may be a perception, formed many years ago, of Java performance on the mainframe being
inadequate for the task. Java z/OS today is considerably improved over Java in the past with respect to
performance and efficiency. (This is particularly true on the latest hardware, where updates in the Java
SDK to take advantage of new processor instructions provides enhanced throughput.) In addition, z/OS
cross-memory technologies can further reduce codepath and latency, providing greater throughput and
less response time. Mainframe monitoring tools and Java profiling tools can be used to report on
performance achieved, as well as help further tune Java to perform better.
© 2017 IBM Corporation 6 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
This chart is a follow-on a point made on the previous chart. The ability to monitor workload activity is a
key consideration for adoption of the workload. That's particularly true on the mainframe, where
monitoring of resource usage is carefully conducted. The point of this chart is to walk through, at a high-
level, monitoring mechanisms available to Java workloads on z/OS. Existing tools are applicable;
standard Java analysis mechanisms are applicable; the IBM SDK extends monitoring further with its
HealthCenter API; and the OMEGAMON for JVMs produce provides a consolidated view of all JVMs with
the ability to monitor more deeply if desired.
© 2017 IBM Corporation 7 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
Security is a topic with increasing focus with each passing year. It is also a very broad and complex topic
that can not be fully covered in one chart. The point of this chart is to convey the key points that
WebSphere Application Server z/OS is built on the Java EE security model; that the underlying SAF
product (RACF in the case of IBM; comparable vendor products otherwise) can be exploited as part of
the Java EE security enforcement; that the IBM System z hardware encryption facilities contribute to
greater encryption performance; and with the newest z14 hardware the pervasive encryption facility
provides a more comprehensive mechanism for encrypting data on the platform.
The final chart in this section provides a graphic that can be used to summarize some of the points made
earlier in the section: WAS z/OS is part of the WAS family, which means the programming APIs are the
same across platforms; that means the DevOps tools used for the other platforms can be used across all
platforms; and that WAS z/OS has the added ability to exploit the z/OS platform.
© 2017 IBM Corporation 8 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
Technical Staff
The Technical Staff audience may have a different focus from Executive Management or Technical
Management. The points of interest shift to specific topics of design, implementation, operations, and
usage. Rather than start with a set of "points of interest," we go straight into charts with specific
technical content.
The first chart draws a distinction between the "WAS traditional" and "Liberty" runtime models. This is
important because a technical audience may have differing degrees of background with WebSphere
Application Server. Liberty is the more recent runtime model. The WAS traditional z/OS design goes
back 15 years. Both are valid, depending on use-case. WAS traditional z/OS is in production use by
many customers around the world. Liberty z/OS is the general focus now for new workloads because of
its smaller memory footprint model, its generally higher zIIP offload rate, and its better efficiency. WAS
tradtional is still considered for cases where exploitation of the WAS traditional z/OS CR/SR design is
called for. (That will center around WLM service classification and workload placement, and possibly
dynamic expansion of SRs to accommodate peaks in workload.)
© 2017 IBM Corporation 9 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
This chart is comparing the Java programming specification support between WAS traditional and
Liberty. This is across all platforms, including z/OS. This assumes both WAS traditional and Liberty at
the most recent levels. Both have the same Java EE 7 support, and the same Java EE 7 web profile
support. Where WAS traditional has additional support is around optional specifications such as JAX-
RPC-1.1, JAXR-1.0, and Java EE application deployment 1.2.
The reason this chart is in the deck is because a frequent question centers on application portability
between platforms; particularly with Liberty as a development platform and WAS traditional as the
production platform. It can be done depending on the program specifications used by the applications.
The next chart expands on this by offering more detail.
© 2017 IBM Corporation 10 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
This chart is present to address the reserve scenario -- an application written and deployed on WAS
traditional that is to be moved to a Liberty runtime. The consideration here is whether the application
makes use of any deprecated Java EE methods, or makes use of some "full WAS" APIs that do not exist
in Liberty. This chart provides a summary of the functions to be aware of. The next chart speaks to the
migration utility, which provides a more comprehensive analysis of the application binaries.
The migraiton toolkit provided by IBM (no fee) provides a utility to analyze application binaries and
evaluate their readiness for deployment to a wide range of potential target platforms. Based on the
© 2017 IBM Corporation 11 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
deployment target specified, the utility will generate a report about specific methods that may need to
be modified to support the proposed target.
By design there is a significant difference in the runtime configuration of WAS traditional compared to
Liberty. The design of Liberty is to have a far simpler configuration model. That means there is one main
configuration XML file. That file can be updated manually, or using any automated process you wish.
Further, Liberty is designed to be "no migration," which means moving to a new level of code does not
require any changes to the configuration. The simple nature of the Liberty configuration model is of
value because it makes Liberty far easier to create and administer, and it makes it far more accessible for
automation tools.
The operational considerations chart summarizes the comparison between WAS traditional and Liberty
© 2017 IBM Corporation 12 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
on z/OS. The two have very comparable operational profiles. The key difference is the SMF record for
WAS traditional (120.9) supports more request types than does the Liberty SMF record (120.11).
However, if your request type for Liberty is expected to be HTTP (which includes REST), then the SMF
120.11 may suffice.
This chart is used to compare the ability of WAS traditional and Liberty to take advantage of key
functions of the z/OS operating system platform. The key differences are: Liberty z/OS does not at
present support two-phase commit transaction processing; the WLM classification support of Liberty is
presently limited to just HTTP requests; the SMF record for Liberty is presently limited to HTTP requests;
and the MODIFY interface for Liberty is not as feature-rich as for WAS traditional.
© 2017 IBM Corporation 13 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
From a developer's viewpoint Liberty has a comparative advantage to WAS traditional. This is due to
Liberty's simpler design, and because Liberty on z/OS looks and behaves just like Liberty on a distributed
platform. (WAS traditional z/OS had several differences developers found to be a hinderance: the
different log format, the EBCDIC code page for log files; and the JES spool location for log files. Liberty
z/OS has none of those issues.)
As mentioned earlier, Liberty z/OS has a generally higher rate of zIIP-eligible work than does WAS
traditional. This is because the single address space design of Liberty z/OS does not involve as much
© 2017 IBM Corporation 14 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
native code as does the CR/SR model of WAS traditional.
Liberty z/OS tends to perform better than WAS traditional because of its simpler design. The
performance numbers provided on this chart -- please note the disclaimer -- suggest Liberty z/OS
servers start faster, consume less memory, provide greater throughput, and use less CPU when at idle.
This chart is designed to introduce the Liberty "collectives" management model, and provide a backdrop
for comparison against the WAS traditional "Deployment Manager and managed nodes" model for those
familar with that managment model. Liberty collectives are optional; you employ the collectives model if
© 2017 IBM Corporation 15 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
it suits your business needs, or you manage Liberty server individually if that suits your needs.
Collectives may be constructed across multiple platforms in a mixed fashion. Collectives use HTTPS,
JMX, and SSH to communicate between controllers and members, and those communications
technologies operate on distributed as well as z/OS.
This chart offers a brief review of three "optional modes" of Liberty on z/OS. This chart is in the deck
because there is a potential for some confusion given the different ways Liberty is used on z/OS. You
may have a combination of all three modes in use on your z/OS system.
© 2017 IBM Corporation 16 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
For those who today have WAS traditional in their environment, there is the potential for having both
WAS traditional and Liberty operate concurrently for some period of time. The purpose of this chart is to
convey the message that there is no technical restriction for having the two operate concurrently other
than standard z/OS considerations such as TCP ports conflicts, naming conflicts, and potentially overlap
of SAF security profiles. All of those considerations can be avoided with proper planning.
This chart introduces the Liberty z/OS JCL start procedure. The reason this chart is in the deck is to
show how simple it is to operate Liberty z/OS as a started task. The JCL start proc is relatively simple in
design, and provides placeholders for things such as rouing STDOUT nad STDERR to a UNIX file if you
wish.
© 2017 IBM Corporation 17 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
Liberty z/OS can be started as a started task, and is eligible for monitoring using SMF Type 30, or RMF
using Type 70, 72 records. It is also possible to classify Liberty z/OS requests to WLM report classes for
further RMF reporting. Liberty z/OS includes a Java Virtual Machine (JVM) and can be monitoring using
standard verbose GC analysis, the HealthCenter API (which is part of the IBM Java SDK for z/OS), or
using the IBM OMEGAMON for JVMs product.
This chart offers a summary of security for Liberty z/OS. It does this by separating the security topic into
three layers -- application security, operating system security, and hardware platform security. The
© 2017 IBM Corporation 18 IBM Techdocs: WP102726
WP102726 at IBM Techdocs: ibm.com/support/techdocs
bullets for each provide the summarization. Security is a very broad topic and can't be fully covered in
one chart. The key message here is that Liberty z/OS makes use of the Java EE security model for
applications; it makes use of z/OS security for SAF functions and UNIX permissions; and it takes
advantage of the hardware security functions of the IBM Z platform.
The final chart offers an overall summarization, and an invitation for discussion.
© 2017 IBM Corporation 19 IBM Techdocs: WP102726
