This article details the installation, including the steps required; what is needed on the mainframe; and how it's different from WebLogic installations on other platforms.

Mainframe Configuration and Installation
There are three key ways to install and configure WebLogic for deployment on the mainframe:

1. Install and run in z/OS
2. Install and runin z/VM under Linux
3. Create a Logical Partition (LPAR) and install WebLogic directly to Linux on the mainframe

WebLogic Under z/OS
WebLogic can be installed on z/OS, IBM's flagship operating system used on the zSeries line of hardware. When deployed on z/OS, WebLogic executes as a UNIX System Services (USS) task. USS can be thought of as a mode of execution on z/OS - all the POSIX APIs are implemented directly into z/OS, and provide a standard API set for a multithreaded environment. This execution model enables programs written using UNIX libraries to execute unchanged (or with minor changes) on the mainframe.

Naturally, WebLogic on this platform uses a Java Virtual Machine (JVM); on the mainframe we use IBM's JVM. The current version of IBM's JVM is based on JDK 1.3.1. and can be downloaded free of charge from www.ibm.com/java.

Once installation is complete, use the "java -version" command to verify successful installation.

WebLogic can now be installed - download a copy of WebLogic Server from the BEA Web site (www.bea.com/download) onto a local file system. Once the download is complete you're ready to start the installation process. This is where we need to note a few procedural differences between installing WebLogic on a Windows or UNIX platform.

At this point you have a WebLogic Server installed on the mainframe under USS. To someone familiar with WebLogic, this looks like a WebLogic installation on any other platform: the sample applications, graphical aids and deployment tools, steps to deploy applications, and administration console are the same.

The snippet of the WebLogic console shown in Figure 1 should look familiar. it's actually WebLogic on the mainframe. The only way to see this is by looking at the version information on the console for the platform information.

WebLogic can now be started, shut down, and administered as on any other WebLogic platform.

How can WebLogic make use of the mainframe environment attributes? You could follow the normal method of starting WebLogic, i.e., running the startweblogic script, but that requires the administrator to be logged on to the mainframe operating system via a Telnet session. A different and decidedly more mainframe approach is to create some JCL (Job Control Language) programs, which are like scripts for the mainframe operating system, to start and stop WebLogic. Using a simple JCL procedure, we can control WebLogic.

Listing 1 is an example of some JCL that could be used, although the mainframe system programmer would customize this for a specific site's use.

When using JCL to control the execution of WebLogic, we don't have to use a Telnet session to start WebLogic - this allows the operations staff to automate startup and shutdown, making WebLogic's operation on the mainframe more natural for the mainframe staff because they can use the tools they're accustomed to.

WebLogic and the WorkLoad Manager
Workload management is a very powerful function of z/OS. The WorkLoad Manager enables machine resources to be utilized efficiently to achieve the best performance for a given workload. For example, it might define that a workload must have its transactions completed within a given number of seconds - a Response Goal.

Like any workload on the mainframe, WebLogic can participate in workload management. For example, the administrator would define a Response Goal for WebLogic where a percent of transactions must be completed within a time period (specified in seconds). z/OS then prioritizes all the work on the machine to achieve this goal. As you might imagine, this is a very powerful, results-orientated scheduling mechanism.

In order to implement a Response Goal for WebLogic, the mainframe system programmer defines a group with the required goal. The goal is then defined to the WebLogic task, which associates the goal with the corresponding task to be completed. The goal and corresponding task are defined using the standard WorkLoad Manager screens in ISPF. Figure 2 shows a page cut from a WorkLoad Manager configuration session.

WebLogic Under z/VM and Linux
Also consider the z/VM deployment model, which has many benefits as well. The z/VM operating system enables multiple virtual machines to be created that represent a physical mainframe, thus allowing a high level of resource-sharing and reuse to be achieved. For example, using multiple z/VM virtual machines as z/VM Guests may allow for multiple UNIX or NT deployments to be consolidated on to a single mainframe server (see Figure 3).

When using z/VM, install Linux into the z/VM Guest machine. WebLogic currently supports SuSE, but other Linux brands will be certified over time. Once Linux is installed on the virtual machine, WebLogic can be installed. Start the installation by accessing Linux running in the z/VM Guest from a Telnet session and run the install command shown below; you'll then be prompted for the remaining installation steps.

"java -classpath weblogic600sp2_generic.zip install -i console"

The only differences in the steps for installing on z/VM are:

Because z/VM has a high degree of resource-sharing, the configuration of the z/VM Guest machine that executes both Linux and WebLogic is important. The memory allocated to WebLogic is defined by the parameter Guest size. This sets the amount of memory the virtual machine will have. The actual amount of memory required will depend greatly on your application; however, an average value is 512MB. It's important to note that this is virtual memory.

Another important setting is the execution class. This value will differ from site to site, but WebLogic should be defined as a high-priority Guest machine to z/VM, as the transaction-response-end users experience is a factor of the execution class.

z/VM provides a number of key performance optimizations. For example, all network functions can be implemented as if they existed in a single virtual machine. This concept is called virtualization. z/VM provides an option, Guest LAN Support, where a LAN segment is defined in memory and all the Guest machines connect to it via a high-speed, in-memory network. WebLogic can use this option, and the z/VM virtualization will hide the actual implementation.

Other network options are available as well, such as the virtual channel-to-channel adapter (VCTCA) to establish a connection between two Guest machines via a virtual point-to-point network.

WebLogic Running Linux Within an LPAR
The last deployment model is the installation of Linux directly on the mainframe hardware. This is known as a Logical Partition (LPAR) installation. This type of installation reserves a portion of the mainframe hardware for a logically separate operating system environment. Although hardware reuse is limited and may not be allocated in the most efficient manner, this is an easy way to try Linux on the mainframe, as z/VM and z/OS at the respective levels are not required (see Figure 4).

Once Linux is installed in the LPAR, the installation of WebLogic follows the same steps as a z/VM Guest machine installation.

Because the WebLogic platform has so many third-party vendors building on or interfacing with WebLogic Server, a whole new breed of applications is becoming available. A number of traditional mainframe vendors are committed to supporting WebLogic deployments on the mainframe. These new offerings will allow WebLogic to be managed and administered using the tools and utilities with which mainframe staff are already familiar.

Which Operating System?
The question of which deployment model to use for the mainframe can be answered by identifying what hardware and operating system are available. Although an LPAR provides an easy way to test WebLogic, the ease of deploying WebLogic in z/OS or as a z/VM Guest enables customers to select the environment they're comfortable with.

Because WebLogic and the application are configured and deployed in the same way on all platforms, even if the production deployment is on different hardware or a combination of operating systems/hardware, picking the operating system is strictly a matter of selecting the one that provides the services (like WLM) you need.

What's Next?
With the execution and operational questions answered, we need to build an application that will access legacy applications and data. The mainframe has many applications, databases, and files that can be accessed in a variety of ways, including Web services, the J2EE Connector Architecture, native API calls exposed to Java, or JDBC APIs. A future article will explore each of these options in more detail, and will look at how using tools such as BEA WebLogic Workshop can make it easy to design and assemble applications with access to mainframe-based applications and data. We'll also detail a production application using WebLogic on the mainframe and some of the development, deployment, tuning, and management tips and tricks learned from production deployments.

A number of options are available to customers who need to deploy J2EE applications on the mainframe, including z/OS, Linux under z/VM, and running Linux natively on the mainframe operating system. The steps to install and configure WebLogic on the mainframe are similar to the steps required on other platforms, but there are some key differences. The actual deployment model the customer selects will depend on a number of factors (skills, availability, costs, etc.). Each option has benefits and drawbacks; however, WebLogic deployment on the mainframe provides a high level of performance and integration.

The next artice in this series will address development and testing strategies, and will describe lessons learned by current BEA customers running production WebLogic-based applications on the mainframe. We'll cover details of the integration strategies for access to mainframe systems and data, including how to use Web services to gain access to and from mainframe systems.