Contents


z/OS concepts for Java developers

Understanding z/OS basics

Comments

Introduction: Mainframe 2.0?

I have never worked with punch cards or 3480 tape devices. I was not part of the mainframe generation. I did, however, work in a mainframe shop early in my information technology (IT) career. I was the Internet guy, and the mainframe systems programmers took me under their wings and tried to prove to me that the mainframe was going to change the world. I was impressed with many features of the mainframe: multi-user access, high-bandwidth backplane, high-throughput disk, and the rock-solid stability. When we moved to a new office (ourselves) and carried two 3280 series mainframes down two flights of stairs, I gained a new kind of appreciation for the platform. What I found especially fascinating was the step-by-step process surrounding the decommissioning and implementation of the system. There were thick manuals for each and steps that had to be performed along the way. Unfortunately, the manuals didn’t include any easy methods for carrying a mainframe down two flights of stairs.

Mainframes have changed significantly since then, as have other platforms. These days, mainframes are much smaller and far more capable. The mainframe platform has also grown and so has my appreciation for it. The demise of the mainframe has been predicted for more than years, yet the mainframe business has been solid, if not thriving. Much of the recent revitalization of the platform can be attributed to the embracing of open computing standards and the diversification of software available for the mainframe. The mainframe is cool again as shops move to consolidate servers and run enterprise systems on a single platform with robust diversification. Some are even speculating that a rebirth is occurring and are talking about Mainframe 2.0.

The modern mainframe

Today, the mainframe is often at the center of an organization’s Service-Oriented Architecture (SOA) strategy. Legacy mainframe applications are often old enough to have children or grandchildren and, in most cases, have tens of years of business logic built into them. These applications are generally core to the organization’s business and enabling them for SOA is often a high priority.

Currently, IBM z/OS® supports many open protocols and other recent innovations including TCP/IP, SOAP, and Java™. IBM has also been expending significant effort into porting their family of products to the z/OS platform. IBM WebSphere® Application Server and IBM WebSphere Portal Server are both available for z/OS (as are many other IBM software offerings), and Java developers have this platform as an option for application deployment.

Why choose a mainframe?

Why deploy a Java application to WebSphere Application Server on the mainframe? The following are among the advantages to z/OS as a WebSphere Application Server platform that can help justify the cost:

  • The 390-based mainframe has been an effective platform for server consolidation.
  • The 390 can support the Linux® operating system, as well as many services and databases traditionally found on distributed platforms.
  • z/OS is exceptionally good at virtualization.
  • Stability and reliability are unrivaled on the platform.
  • Many enterprise applications already reside on a mainframe platform. Deploying Java applications to a mainframe can provide easier access to these resources.
  • WebSphere on z/OS can connect directly to IBM Customer Information Control System (CICS®), which can help SOA enable legacy applications.

After you make the architectural decision to implement WebSphere Application Server on the mainframe, the next challenge is determining a deployment strategy. This is where cultural differences often occur. Java developers and mainframe system operators are not usually in close contact -- they don’t really speak the same language and often have not even met. To work well together, they need to understand the language of each other. As a Java developer, it’s a good idea to have some understanding of mainframe nomenclature and context before approaching the mainframe team to discuss deployment.

Mainframe terminology

There are several terms and concepts that are specific to the mainframe. Most of them have correlations in the distributed systems world. Table 1 provides definitions of some terms that are common in the mainframe world:

Table 1. Mainframe terminology
TermDefinitionDescription
ABENDAbnormal EndABEND is a program crash -- think core dump.
BatchNon-interactive execution of a series of programsSimilar to a chron job that runs every night with an interconnected series of scripts.
CICSCustomer Information Control SystemCICS is a transaction server for online and batch processing.
COBOLCommon Business Oriented LanguageCOBOL is a business-oriented programming language.
DASDDirect Access Storage DeviceDASD is a disk storage or Storage Area Network (SAN).
DB2®Database 2Database 2 is the IBM relational database management system, also available on other platforms.
EBCDICExtended Binary-Coded Decimal Interchange CodeEBCDIC is a standard similar in concept to, but not compatible with, ASCII.
IMS™Information Management SystemIMS is the IBM hierarchical database that was first released in 1968.
JCLJob Control LanguageJCL is a scripting language for executing batch.
MVS™Multiple Virtual StorageMVS is an operating system from IBM that allows for virtualization of resources.
REXXREstructured eXtended eXecutorREXX is a scripting language that is similar in concept to Perl and Python.
VSAMVirtual Storage Access MethodVSAM is a type of file for data storage.
z/OS64-bit operating system from IBMz/OS is an operating system that allows for virtualization of resources.

Nomenclature is not the only difference between the mainframe and distributed systems. The operational processes surrounding the mainframe have often had tens of years to evolve, and mainframe applications are often critical in nature. This combination lends itself to a highly-structured process for application deployment. Don’t expect to simply send your Enterprise Archive (EAR) file to the production server using File Transfer Protocol (FTP) and start testing. Most likely you'll need to define some additional processes and procedures for Java Platform, Enterprise Edition (Java EE) application deployment.

Working with the mainframe team

In a smaller Java development group, a Java developer might have the root password to the production server and handle all of the code deployment, database, and even the administration of the system. In the mainframe world, these roles are usually discrete and highly segregated with control points along the way to reduce the opportunities for casual mistakes. To a Java developer who is unfamiliar with this approach, it can seem bureaucratic and unreasonable. It is important to understand and respect the process and realize that the motivation for the controls is to help manage change on the mainframe and reduce the opportunity for disruption.

WebSphere on the mainframe is the merging of two worlds: the mainframe world and the Java world. If you are approaching the mainframe group for the first time and are looking to deploy WebSphere Application Server or a Java EE application, it's a good idea to ask for a copy of policies and processes for the mainframe. In addition to gaining information about the system procedures, you also demonstrate that you are aware of the mainframe context and will show understanding and respect of that environment. If you are going to deploy WebSphere Application Server on the mainframe, you need the support and assistance of the mainframe group, so establishing a strong working relationship is essential.

Mainframe virtualization

The mainframe is the king of virtualization (see Figure 1), and to the uninitiated this can be a significant difference between the mainframe platform and other environments. On other platforms, such as the IBM System x™ and Intel®, it is becoming more common to see highly virtualized environments -- with VMWare ESX Server, for example. On the IBM System p™, mainframe virtualization has arrived in full force with full logical partitioning (LPAR) management facilities basically ported over from the IBM System z™. If you have been working on silos (standalone servers) though, this virtualization can be somewhat confusing. One key point in mainframe virtualization is that even though the logical partitions might reside on the same system, everything is so well virtualized that you can think of them as discrete systems from an application point of view.

Figure 1. Mainframe virtualization
fig1
fig1

Mainframe architecture

After you become familiar with some of the terminology, it also helps to understand the architecture on the mainframe. Most of the core innards of the mainframe are things you would expect -- processors, short-term storage, long-term storage, permanent storage, and so on. The mainframe does things slightly differently internally. I won’t get into details on the hardware architecture, but it does help to know that there are several types of processor units (PUs) on the mainframe that can be specialized to specific tasks, as shown in Table 2.

Table 2. Mainframe architectural components
Processor unit (PU)Task
Central processors (CP or CPU)Central processors are the main processors on the system that can run VM, z/OS, ESA/390, Linux, and Coupling Facility Control Code (CFCC).
CP Assist for Cryptographic Function (CPACF)CPACF assists the CPU by handling workload associated with encryption/decryption.
Integrated Facility for Linux (IFL)IFL assists with Linux workloads -- regular processors with a few instructions that are not needed by Linux operating systems removed.
Integrated Coupling Facility (ICF)This facility executes internal code and it is used to coordinate system efforts.
System Assisted Processor (SAP)SAP assists the CP with workload by executing internal code for the I/O subsystem.
SparesSpares are available in case of failure.
IBM System z Application Assist Processors (zAAP)zAAP is dedicated to specific application code, currently supporting Java.

IFLs and zAAPs are considered to be good additions for organizations that want to execute Java and run zLinux (that is, Linux on the mainframe). These specialized processors increase the performance for these types of operations and also reduce licensing costs.

Mainframe processing modes

One mainframe concept that can be challenging to grasp at first is that of batch processing. The concept of jobs being scheduled to execute is not new to most developers, but the importance of this type of processing in the mainframe environment is often a surprise. Mainframes usually handle two types of load: Online Transactional Processing (OLTP) and batch. Batch processing is more than the mainframe equivalent of a few nightly chron jobs. On many systems, batch processing represents a significant portion of the processing of the application. Batch processing can do the following:

  • Facilitate integration with other systems and organizations.
  • Generate reports.
  • Validate data.
  • Prepare the system for events for the following day.

Since mainframe environments can be highly virtualized, physical resources are assigned to logical partitions. These logical partitions are often configured for various forms of testing and production use. Think of them as completely different server instances with no real connection between them, even though they are housed on the same physical system. Logical partitions are managed as though they are separate systems. Figure 2 shows a screen shot of an LPAR data report that demonstrates LPAR usage and utilization:

Figure 2. Partition data report
fig2
fig2

The Linux factor

One of the more recent mainframe advances is the ability to run Linux on the mainframe (zLinux). This advancement allows you to create a Linux logical partition on the mainframe. I was an early Linux adopter and was skeptical when I first worked with Linux on the mainframe. Over time, however, I became impressed. Linux on the mainframe is just Linux as you know it, but highly virtualized and more scaleable. The IFL engine helps to facilitate the Linux load, but it is not necessary to run zLinux. The IFL engine also helps with licensing and handling workload. zLinux has reinvigorated many mainframe environments and brought many new services to the mainframe world. Many of the IBM Software offerings (such as WebSphere Application Server, DB2, and Lotus® Domino®) also ship for zLinux.

Conclusion

The twenty-first century mainframe is a different system than its 1964 predecessor in that it takes an open standards approach, it can run a great variety and type of applications, and it is both smaller and lighter and more robust. The modern mainframe is a workhorse, and it is worth consideration as a WebSphere Application Server platform if your Java EE applications require the type of stability, scalability, and performance that the mainframe has to offer.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Java development, WebSphere
ArticleID=168968
ArticleTitle=z/OS concepts for Java developers
publish-date=10032006