This chapter introduces the IBM System z New Application License Charge (zNALC) pricing structure. It also gives examples of zNALC workload scenarios, which are the focus of this book. For more information, see the IBM System z Software Pricing web page:

This chapter covers the following topics:

For many organizations, the ongoing pressure to manage long-term operational costs can be a psychological barrier when considering deployment of new applications to IBM System z. Yet System z is still one of the most capable and cost-effective platforms for running mixed workloads, with the qualities of service on which these organizations depend. In recognition of these ongoing pressures, IBM has introduced the Value Unit Edition (VUE) pricing model to provide clients with greater flexibility to balance the capital and operating expenses of new projects.

System z New Application Licence Charges (zNALC) gives organizations the opportunity to run a new workload on System z at a reduced cost if that workload is a qualified “new workload” application. An example of a qualified application is a Java language business application running in IBM CICS Transaction Server for z/OS Value Unit Edition (CICS TS VUE) or IBM WebSphere Application Server.

Running CICS Transaction Server for z/OS using the Monthly License Charge (MLC) pricing option is normally considered an operating expense (OpEx). This is because the expenses are charged monthly and are directly related to the CPU use for the month. However, IBM CICS Transaction Server for z/OS Value Unit Edition is a one-time-charge license, so it is categorized as capital expenditure (CapEx). This one-time-charge license can run in a reduced price zNALC logical partition (LPAR). The same principle applies to other qualifying software that is required to support the application.

CICS Transaction Server is part of a family of products that are available as a Value Unit Editions. Other IBM software that is available as Value Unit Editions include IBM DB2 for z/OS, IBM IMS database, IMS Transaction Manager, and IBM WebSphere MQ for z/OS.

CICS Transaction Server Value Unit Edition (VUE) allows you to deploy new Java workloads at a fixed cost. zNALC provides a reduced price for z/OS. For clients who have an IBM System z Application Assist Processor (zAAP), Java workload can be transferred to the specialty processor, further reducing the cost of running new Java workloads under CICS Transaction Server.

CICS Transaction Server Value Unit Edition contains a version of the WebSphere Liberty Profile at no extra charge, running in the highly scalable JVM server architecture within CICS. A separate WebSphere Application Server license is not required to run WebSphere Liberty Profile applications within CICS TS. Deploying new Java workload to Liberty on CICS allows you to use many of the Liberty capabilities as well as integrating Liberty applications with the JCICS API, providing the best of both worlds in a single managed runtime.

The IBM JVM uses the latest hardware advances in System z including features such as Transactional Memory (for improved concurrency in multithreaded applications) and large 1MB pageable memory using flash. An IBM benchmark shows 40% improvement in Java workloads running on zEC12 using Java7SR3 using hardware improvements compared to z196. CICS TS V5 supports Java7SR1 or later, which enables you to use the most efficient JVM runtime available on System z.

The Value Unit Edition (VUE) family of products provides a choice for how to budget for new projects. Previously, all new projects would primarily result in an increase in operational expenditure. Deploying to a VUE environment on a zNALC LPAR enables a proportion of the project cost to be a capital expense. In organizations where strict budgetary controls are in place, having the flexibility to choose between these two budgets can help to get new projects financed and delivered.

You can deploy VUE versions of products to use new capabilities without needing to migrate your existing installations to the latest software levels. For example, CICS TS VUE can interoperate with an existing version of CICS TS (MLC) at a lower level, without triggering the single-version-charging (SVC) window. Furthermore, you can start by deploying the CICS TS Developer Trial, a free version of CICS that allows you to evaluate product capabilities, and later upgrade it, in place, to either CICS TS VUE or CICS TS (MLC). There is no need to uninstall and reinstall software.

The idea that Java and the mainframe are a bad pairing is outdated and inaccurate. If you still hold the opinion that the two do not fit well together, it is time to reconsider.

Java is a language, and there are many to choose from, but not all languages get the same investment that Java has had, particularly on the mainframe. Perhaps more importantly, Java is also a runtime platform. Java on System z has received significant and ongoing investment from IBM, which has built the Java virtual machine for System z from the ground up, developed hardware that can be used by the JVM, and built core middleware technology using Java. This makes Java on the mainframe one the world’s most optimized Java environments.

System z is something special in itself. There is no other machine that has such a vast heritage with such a profound effect on business, science, and people, from helping to put man on the moon, to becoming the heart of the world’s financial system, or to buying cosmetics with a mobile phone from the comfort of a chair. The mainframe has continued to evolve to incorporate the latest advances in technology to deliver the most capable platform the IT industry has.

It's not surprising to find System z at the heart of the 24x7 always-on world that we have come to expect, processing millions of business transactions every day. IBM estimates that 80% of the world’s corporate data resides or originates on the mainframe. So you might say that it represents the “center of gravity” for business applications and data.

Java’s popularity as a language for enterprise systems has grown steadily. Despite now being around 20 years old, eWeek ranked Java number 1 in its Top 10 Programming Languages for Job Seekers in 2014.¹ It is a well-structured language, suitable for writing clean and robust code, where the developer can focus on the problem, take advantage of the language features, and write something that a colleague will understand decades later, using the same tools that are used for writing code on distributed platforms.

Java also benefits from being the language of choice for many universities around the world, where it forms the basis of computer science and software engineering courses. Graduates understand it, have been trained to use it, and know its strengths. Java has an established ecosystem, which means it won’t be going out of fashion any time soon. Consequently, there are a huge number of open source projects that provide frameworks and services for all kinds of tasks. The number of Java programmers that exist exceeds nine million.

Plus, it performs. There might be people who can write tight assembler code to perform a very specific function faster than the equivalent COBOL or Java, but who can maintain it and for how long? The IBM Just in Time (JIT) compiler progressively optimizes Java code at runtime. Although our hypothetical assembler guru might be able to do a good job in a specific case, the JIT compiler considers all of it and optimizes code for the hardware on which it’s running. As IBM invests in hardware improvements on System z, it enhances the JIT compiler to take advantage of them. The result is continued performance improvements for Java applications as IBM updates the JIT compiler to produce more efficient code at runtime.

Some might say that Java and the mainframe didn’t get off to the best start, and it is certainly true that some people formed an opinion in the early years that the two were not suited to each other. You can still find these opinions in old blog posts and forums on the Internet, but they do not reflect the current state of Java on the mainframe.

It is not entirely surprising that a fledgling technology, as Java obviously was when it first came to the mainframe, did not perform as well as the longstanding applications that it was compared to, which were written in COBOL. Those existing applications had received years of progressive refinement and refactoring, perhaps even decades of it, so the comparison was unfavorable and some people formed a negative opinion by focusing on short-term comparisons.

Today's Java on System z runs in the IBM 64-bit JVM, uses features such as hardware transactional memory, large memory pages, and hardware instructions that go back to the IBM z990 that was introduced in 2003. It has more than a decade of investment and refinement behind it. The JVM and JIT have both been enhanced in step with Java specification developments, and the hardware has had capabilities added specifically to enhance Java workloads. IBM also introduced the z Application Assist Processor (zAAP) that runs Java workloads on dedicated processors, significantly reducing the long-term operating cost of Java workload on the mainframe.

Comparing Java today to the Java of 10 years ago is like comparing Formula 1 racing cars that are a decade apart and asserting that the technology has not changed much in the passing years. It's not really a comparison that is worth making because they are simply not the same thing.

Deciding whether System z is the right place to put new Java applications has not always been the simple decision that people would like it to be. Depending upon whom you ask, the answer can be anything from “Put everything on z” to “never” to “it depends,” with the last answer typically accompanied by a long technical discussion of the pros and cons. None of these answers are particularly helpful. The first leaves you wondering whether the person really understands why you have asked the question, the next leaves you wondering whether technology alone can provide the answer, and the last often feels like a passionate and unsubstantiated opinion.

Today, if you are asking yourself where the best place to deploy a new Java application is, you should probably first ask yourself, “Where is the center of gravity of the existing applications and data that this new Java application will interact with?”

You might wonder what we mean when we use “center of gravity” in the context of technology. Imagine a typical IT environment where there are lots of disparate systems that need to interact with each other. Now consider what the typical pattern of interactions will be between the proposed new Java application and those existing systems, applications, and data. The center of gravity is wherever the greatest concentration of interactions is. Positioning the new Java application on or near the center of gravity minimizes the architectural complexity of the solution, which in turn has a positive impact on things such as response time, maintenance costs, and resiliency.

Consider a simple example. Imagine that you are planning to build and deploy a new Java application. The new application will provide some entirely new capabilities but will need to interact with the existing business services hosted in CICS that modify data hosted on the mainframe. These services provide the business function that you need and they also embody preferred practices and comply with your audit and governance policies. So being able to reuse them is essential.

By applying the center of gravity principle, you can quickly assess the level of interaction that your new application will have with the existing mainframe solution. In this example, the center of gravity is clearly in CICS on the mainframe. So what Java environment can you expect to find there? CICS Transaction Server (TS) version 5 supports the IBM 64-bit JVM, so it provides a multithreaded JVM server environment directly in CICS TS. If your application could benefit from some of the capabilities of the IBM WebSphere Application Server Liberty Profile, for example a presentation layer built using JavaServer Pages (JSPs) and servlets, you will find that the Liberty Profile is embedded in the CICS JVM server and packaged without charge as part of CICS TS V5.

Another example is a new Java application that interacts with one or more non-mainframe systems, such as a distributed IBM DB2 database, perhaps in combination with a third-party packaged application that us running in an IBM SoftLayer® public cloud. If there is little or no requirement for your new Java application to have access to applications or data on the mainframe, the center of gravity for that application is clearly not on the mainframe. In this example, the question to ask might be whether the center of gravity is nearer the distributed DB2 database or the cloud-based third-party application. Either way, WebSphere Application Server has deployment options in both of these environments.

The center of gravity principle works because no matter where the center of gravity is, there is an enterprise-grade Java environment there to accompany it. The goal of the center of gravity principle is not to define an absolute answer, because there might be more considerations that steer you in another direction. The goal is to consider options that are congruent with past business decisions and that recognize the broad range of Java capabilities available to you, regardless of their locations.

Although the center of gravity principle helps to keep your decision-making process grounded, there are some specific cases where following the principle without question might not be optimal. The most likely case is in a mixed platform environment, where both System z and distributed servers co-exist. In mixed platform environments, the center of gravity might appear to be in the distributed server environment, even if it has interactions with System z based services. So the logical conclusion would be to locate a new Java application somewhere in the distributed environment. Is this the right answer?

To be clear, we are not suggesting that this is a wrong answer, but it is worth stopping to consider the economics of growing a distributed server environment, particularly when System z is also present. The case for consolidation onto System z, in particular Linux for System z, is strong, because it breaks the economic pattern of incremental costs associated with each new distributed server.

Linux on System z virtualization enables new instances to be added to the environment quickly and easily, without needing to worry about floor space, power, cooling, cabling, physical maintenance, and much of the cost associated with the introduction of a physical device. Moreover, if your organization is motivated by the economics of a cloud environment but concerned about migrating sensitive data to the cloud, the combination of Linux on System z and z/OS can form the basis of an efficient private, hybrid cloud environment.

The economic argument extends further. In the same way that System z provides zAAP processors dedicated to running Java workloads, it also provides the Integrated Facility for Linux (IFL) processors. These are dedicated to running Linux on System z, which provides cost and scalability benefits. Consolidation onto System z also offers advantages from the collocation of applications and data, reducing network latency by taking advantage of System z IBM HiperSockets™, and simplifying the application architecture. The IBM z/VM® operating system provides an efficient virtualization environment that enables you to reach nearly 100% processor use, even in mixed workload environments. This reduces the cost per transaction.

Managing costs, particularly operational expenses, is a top priority for all organizations. Consolidating distributed server environments can directly reduce operational expenses, but if the economics for consolidation don't apply to your environment (perhaps you have already consolidated), there are still options to consider for managing operational expenses on System z when deploying new Java applications to the platform. These options, described throughout the remainder of this book, explain how CICS Transaction Server Value Unit Edition can be used to deploy new Java workloads, using a one-time-charge pricing model.

This IBM Redbooks publication provides a set of technology-lead scenarios that demonstrate how CICS Transaction Server Value Unit Edition can be deployed to address some typical business challenges, ranging from mobile enablement of existing applications to the development of a modern, hybrid batch environment. All of these examples share two common traits: They are new workload scenarios and they can be deployed to CICS TS VUE.

We begin with a review of the WebSphere Application Server Liberty Profile (Liberty), which is packaged with CICS Transaction Server, and consider how Liberty can be used to modernize existing interface technologies. Liberty provides capabilities such as JSPs and servlets, which offer developers familiar who are with web technologies the capability to build rich web-based interfaces that interact with existing CICS applications and services. For many clients, these backend applications represent the cumulative investment in business process, governance, and audit requirements, and they represent core business value in the form of intellectual property and competitive advantage. For many, these are irreplaceable, so providing new methods to interact with these CICS TS services enables businesses to continue to benefit from their investments yet do so using modern interfaces, languages, and capabilities that are available in the Liberty profile.

The following chapters explain more about the Liberty profile:

Part 3, “Mobile devices” on page 45, addresses the growth of mobile technologies that require new mobile workloads. This has been well described in the press. For many, it is the primary driver of growth and new development. Building mobile solutions requires so much more than simply building the mobile application, because a mobile application must meet the expectations of users who live in the always-on, always current, world of connected mobile devices.

Business process optimization for both business-to-consumer (B2C) and business-to-employee (B2E) are dominant factors in the next generation of mobile application development as business moves beyond simple interaction using a mobile device into the realm of the integrated mobile channel. In both of these cases, the value of the mobile application is not simply that it's on a mobile device but that it is integrated with the corporate systems, data, and processes that the business has built to offer competitive services to its customers. When these systems reside on the mainframe, it is natural to want to use them.

The Mobile section explains how CICS TS can provide mobile enablement of existing backend services. It begins by considering the capabilities offered by Liberty, such as JAX-WS and JAX-RS for XML web services and RESTful web services, respectively, before considering z/OS Connect and later options for connecting to Java applications by using the data transformation services of CICS.

Part 4, “IBM Operational Decision Manager” on page 71, is also relevant to our always-on, always-connected world, where it becomes increasingly important to make the right decision at the right time. Essential to successful decision management is being able to make decisions in a timely fashion and to locate the decision-making process close to the systems that are dependent upon them. In times gone by, the decision process could be a human task, but these days, efficient decision-making process are codified and embedded in software components that are accessible from across the enterprise. IBM Operational Decision Manager provides the capabilities necessary to codify, manage, update, and deploy decisions, and it can be hosted in CICS TS. This enables you to build a highly scalable and robust decision management solution that is located with critical enterprise workloads.

For more information about decision management and the architectural options for deploying Operational Decision Manager, read Chapter 8, “Decision management integrated in IBM CICS Transaction Server” on page 73. For details about deploying it to CICS TS, see Chapter 9, “Implementing decision management in CICS TS” on page 85.

The last section, Part 5, “Modern Batch feature” on page 95, covers modern batch processing. It explains how you can use new technology to reduce the size of your batch window and transform your batch processing and OLTP workloads to make them more cooperative. The traditional batch window, where online systems are shut down, is shrinking as the need for always-on processing increases. Yet the two approaches to data processing are, in their traditional forms, mutually exclusive. By using WebSphere Java Batch and the CICS Feature Pack for Modern Batch, you can build a hybrid batch environment that allows for both methods to operate together, where online applications remain online longer, and new or existing batch workloads co-exist and use some of the capabilities that have previously been unavailable to use for batch processing. By using the WebSphere and CICS combination, you have an alternative way of managing and pricing batch workloads.

Chapter 10, “Modern batch workloads” on page 97 reviews batch processing considerations and the inherent benefits that can be gained by building a hybrid batch environment. Chapter 11, “Modern batch use scenario” on page 113, provides an example of how to build and deploy a modern batch application into CICS TS VUE.

Section 1.5, “When and where to put Java on System z” on page 6, described a range of technical capabilities that can be deployed to CICS TS VUE. This list is not exhaustive, and there are many other use scenarios. However, there are a few common reasons that an organization considers deploying new workloads to VUE.

For most businesses, a large proportion of what they are doing with their IT budgets can be categorized as solutions that either get things done sooner or cost less. CICS TS VUE provides both, because it reduces the cost of new workloads and provides capabilities that enable you to get things done faster.

For those who are focused on cutting costs, one obvious consideration is consolidation, either of the physical servers or the software architecture components. Both carry a cost. As an example, consider an organization that has progressively developed an application in CICS. Such an organization might have initially developed a terminal-based application, eventually replacing that with a fat-client solution running on distributed servers, perhaps also building some applications that use web technology hosted on web servers and interact with CICS applications.

The concept of consolidation can be applied in many ways to this example, bringing various benefits depending on exactly what it being consolidated. For example:

Before the introduction of CICS TS VUE, these examples, although valid, might have involved challenges when considering the financial factors involved. This no longer has to be the case, because VUE changes the pricing and allows a fixed price for such projects. By using VUE, a client in the circumstances described would be able to benefit from all of these consolidation options. Therefore, they could minimize architectural complexity, remove unnecessary hardware, improve the response time of applications, and use new languages and technology to create rich mobile and web applications.

The second type of IT budget spending is directed toward increasing service agility or doing things faster. The latest features of CICS TS, particularly those offered by the inclusion of the Liberty profile and the mobile capabilities of CICS TS, are well suited to organizations that want to build dynamic interactions that use the applications and services in existing CICS applications. VUE enables you to consider building these new workloads by using all of the features of CICS, integrating with existing CICS applications and services that are already in production, yet doing so with a degree of separation and financial security. You can price the project to use capital budgets and rapidly deploy new applications that use the existing skill base of development and operations staff.

Consider another client, again with an investment in CICS applications, who wants to build a “next generation” mobile application to replace their existing mobile solution. In this example, the client has a broad range of services hosted in CICS and wants to provide a simple interface to these services that doesn't require additional servers in the data center, is built by using popular programming models for mobile development, and provides a lightweight interface for operations staff to track and monitor key performance metrics for the application. For this client, improved service agility might include the following elements and benefits:

In this example, before CICS TS VUE, a client who saw value in the Liberty, mobile, and applications packaging capabilities of CICS would have needed to migrate their existing CICS installation to the latest level of CICS TS to gain access to these features. But using CICS TS VUE, the client can deploy the latest version of CICS to a separate LPAR, yet connect to all of the applications and services in their existing CICS environment and use the latest CICS capabilities. This offers all of the capabilities of the latest technology and enables the cost of the project to be allocated from the capital budget.

Although these two scenarios are somewhat trivial, they demonstrate that VUE is not simply about changing the price of a project from an operation expense to a capital expense, but that VUE offers a complete CICS solution to many different business problems.