Word Pro - WP100920 - 64 Bit Addressing Support.lwp - IBM

WebSphere Application Server for z/OS V6.1.0.4

64 Bit Addressing Support64 Bit Addressing Support64 Bit Addressing Support64 Bit Addressing Support

This document can be found on the web at:www.ibm.com/support/techdocs

Search for document number WP100920 under the category of "White Papers"

Version Date: February 1, 2012Please see "Document Change History" on page 44 for updates provided in this version of the document.

IBM Washington Systems CenterIBM Washington Systems CenterIBM Washington Systems CenterIBM Washington Systems Center

Nick CarlinIBM Hursley, UK44-1962-816567

[email protected]

Don BagwellIBM Washington Systems Center

[email protected]

Many thanks to ... Mike Cox, John Hutchinson,Lee-Win Tai, Brian Pierce and Dennis McDonald of

the IBM Washington Systems Center

Gary Puchkoff, Frank Golazeski, Evan Jennings,Dave Follis and Diana Steinmetz of the WebSphere

for z/OS development organization.

Peggy Rader and Steve Zemblowski of theAmericas Advanced Technical Support organization

John Cowel of Field Technical Sales Support

Phil Wakelin of CICS development, UK

Dermot Flaherty, Doug Burns and John Woolley ofMQ development, UK

Table of Contents

28Does enabling 64-bit update the START command held in the configuration XML? . . . . . . . . . . . . . . . . . . . . .28Some questions and answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Common mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Issuing the START command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Server JVM heaps and auxiliary storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Memory limits on a 64-bit server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Generating JCL when you don't have any saved definitions to work with . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21When you have the previous configuration information still saved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Overview of process to regenerate the JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Creating new JCL start procedures that support 64-bit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Verifying your JCL is at the right level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19The JCL start procedure used to start a server in 64-bit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Executing WSADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16Checklist to prepare for WSADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16A little background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16Enabling a server to run in 64-bit mode using WSADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Enabling a server to run 64-bit using the Admin Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Enabling a server to support 64-bit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Deployment Manager and Node Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13A note about which servers may be enabled to run 64-bit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12STEPLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12LPA/LNKLST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11STEPLIB updates or LPA/LNKLST updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11APF authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Program properties update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Basic system programming requirements to run in 64-bit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Checklist before you start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10An overview of what's involved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Enabling 64-bit Mode Operations for a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Restrictions possible in WebSphere for z/OS 6.1.0.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Does this require me to use the 64-bit version of IBM z/OS Java? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8How can I know what mode a server address space is really running? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7If I'm planning very large JVM heap sizes, what operating system things should I consider? . . . . . . . . . . . . . .7Is there some guidelines for what I should set my JVM heap sizes to? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Will this result in my WebSphere servers using more memory? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Can a 31-bit DMGR or Node Agent support a 64-bit application server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Does this apply to application servers only, or all WebSphere server types? . . . . . . . . . . . . . . . . . . . . . . . . . . .6May I have some servers at 64-bit but others at 31-bit? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6If I enable a server for 64-bit, can I revert it back to normal 31-bit operations? . . . . . . . . . . . . . . . . . . . . . . . . .6If I don't do anything, will my servers automatically start using 64-bit mode? . . . . . . . . . . . . . . . . . . . . . . . . . . .6Is there any downside to running my servers in 64-bit mode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6If I start a server in 64-bit mode, do all "regions" of server run in 64-bit mode? . . . . . . . . . . . . . . . . . . . . . . . . .6If I start a server in 64-bit mode, am I required to increase the JVM heap sizes? . . . . . . . . . . . . . . . . . . . . . . .5Is this something I must do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Some questions and answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Basic prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Quick "cheat-sheet" for those who want the most essential information quickly . . . . . . . . . . . . . . . . . . . . . . . . . .3Is 64-bit mode mandatory or optional? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3At the highest level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Introduction and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

WP100920 - 64 Bit Addressing Support

Section: IntroductionVersion Date: Wednesday, February 01, 2012

- 1 -© 2007, IBM Americas Advanced Technical SupportWashington Systems Center, Gaithersburg, MD

44Document Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Concluding points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Other sources of 64-bit programming reference information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Three key considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41User JNI application code issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39IMS: implementing the update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37IMS: The longer answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37IMS: The short answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36CICS: implementing the update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34CICS: the longer answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34CICS: The short answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34CICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34DB2: implementing the update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34DB2: The short answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Overview summary chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33IBM data connector issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Overview of the issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Data Connector and non-Java Application Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Sample servant (or adjunct) JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Sample controller JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30An example of a controller and servant JCL start procedure that support 64-bit . . . . . . . . . . . . . . . . . . . . . . . .30How can I check what mode a server is enabled for? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30What is the error symptom seen when a 64-bit enabled server is started in 31-bit mode? . . . . . . . . . . . . . . .29What is the error symptom seen when a 31-bit enabled server is started with AMODE=64? . . . . . . . . . . . . .29What do I need to do if I want to go back to 31-bit mode for a server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Do I need to increase my server's JVM heaps after enabling server to run in 64? . . . . . . . . . . . . . . . . . . . . .29How can I be certain a server truly is starting in 64-bit mode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Any advantage to the Admin Console method vs. the WSADMIN method? . . . . . . . . . . . . . . . . . . . . . . . . . . .29Is there a way to convert a whole cell at once, rather than server by server? . . . . . . . . . . . . . . . . . . . . . . . . .29Is there any way to make server start in 64 without AMODE=64 on the START command? . . . . . . . . . . . . . . .28If I enable a server for 64 bit, should I update my automation routines? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28What files are changed when a server is enabled for 64-bit mode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Section: IntroductionVersion Date: Wednesday, February 01, 2012


Introduction and Overview

At the highest level

With the 6.1.0.4 level of WebSphere Application Server for z/OS the ability to run servers in 64-bitJVM mode was made available. What that means is that the JVM that runs inside the servers cannow support far greater memory ("JVM heap") than before.

The 31-bit JVM implementation heap size is limited by the amount of private virtual storagebelow the 2-gigabyte line. On most z/OS systems, the private region is limited to approximately1.4 gigabytes. When you take into consideration the storage needed for infrastructure, themaximum usable heap in most z/OS systems is in the 768 - 900 megabyte range.

With 64-bit mode, that number jumps to 16 exabytes, which is 16 billion gigabytes(16,000,000,000 GB).

Note:

But before you can have a server's JVM start using that much addressable memory, you need toenable the server to support 64-bit mode. Enabling a server to support 64-bit mode is done eitherthrough the Admin Console, or with the WSADMIN scripting interface. They both end up doing theexact same thing -- changing some properties in a small handful of XML files. We'll cover all thedetails of this under "Enabling 64-bit Mode Operations for a Server" starting on page 10.

Once enabled, you then start the server with a new START command parameter: AMODE=64.

Pure Java applications require no modifications to make use of this larger JVM heap. That's thenature of Java -- the underlying platform and direct memory management is hidden from theapplication. But non-Java code is another matter. This would include things like Java NativeInterface (JNI) code and vendor supplied connectors that have non-Java code components. Wecover that topic under "Data Connector and non-Java Application Implications" starting on page 33.

What we'll do in this section of the paper is explain what the 64-bit support provides and engage in aseries of questions and answers that we hope will help you better understand what this is all about.

Is 64-bit mode mandatory or optional?

It is optional. It is function provided for those who can benefit from the increased memoryaddressing capability of the 64-bit mode. Generally speaking, that would include those whoseapplications -- written in-house or from an ISV -- are currently constrained within the 2GB limitsimposed by 31-bit addressing mode.

At the present time there is a general memory and performance overhead associated with 64-bitmode operations. Performance comparisons are always tricky because they involve so manyvariables, but to attempt to compare the two here's what IBM did:

� Established a 31-bit server environment and used the "Trade6" and "PingServlet" sample applicationsto establish a baseline. Two baseline values captured: throughput as a measure of performance; andthe Java garbage collection cycle duration and frequencies.

� The server was converted to 64-bit and the JVM heap sizes increased until the garbage collectionduration and frequencies was the same as was seen for 31-bit.

Findings:

� It took in the neighborhood of 20% to 30% more JVM heap to create an equivalent Java garbagecollection profile under 64-bit as was seen with 31-bit.

� The performance metric showed a degradation in the order of 7% (Trade6) to 11% (PingServlet).

This 64-bit degradation is due to a number of factors, such as the increased instruction sizeand the "glue code" that copies parameters between 64-bit modules and 31-bit services.

Note:

As stated, performance measurements are dependent upon many variables, so your results mayvary. This example is in no way meant to be a guarantee of specific performance.


Section: OverviewVersion Date: Wednesday, February 01, 2012


It should be noted that the IBM Java 5 implementation included with WebSphere V6.1 isgenerally a better perfomer compared to the previous Java 1.4.2 JVM. So going to WebSphereApplication Server for z/OS V6.1 from a previous or release is not in general where theperformance degredation is seen. The numbers just cited were a comparison between 31-bitand 64-bit of the same WebSphere V6.1 code level.

Note:

In addition to the general "cost" of 64-bit, there may be other application-related things that preventyou from going to 64-bit at the present time. Most of this is related to JNI code that invokesprograms that are not themselves 64-bit. This includes the area of data connectors, which makeuse of JNI to invoke native code. You should review "Data Connector and non-Java ApplicationImplications" starting on page 33 for more.

� Enabling a server for 64-bit mode should be done for the right reasons. You shouldnot feel compelled to do it, unless your applications require it. It should be somethingdone only after proper consideration is given to the implications of doing so.

� That said, we still encourage our WebSphere for z/OS customers to be aware of the64-bit support, and to consider the implications of enabling it at some point in thefuture.

� We expect the 31-bit support to one day go away. But that won't happen in the nearterm.

Key Points:

Quick "cheat-sheet" for those who want the most essential information quickly

If you scan through this and don't understand something, then read the rest of this document.Note:

� WebSphere for z/OS V6.1.0.4 or higher; z/OS 1.7 or higher or z/OS 1.6 with ++APAR BA17679 andAA17846

� Insure your system is sufficiently capable of handling any significant increases in JVM heap sizes youmay be planning once 64-bit is enabled. This relates specifically to real and auxiliary storage.

� APF authorize the SBBGLOAD library

� Place BBGCTL in the program properties table with KEY(2), NOSWAP, PRIV and CANCEL

� Make sure SBBGLOAD is either in LNKLST or STEPLIBed

� Make sure the JCL start procedures are at the proper level to support starting in 64-bit mode. Checkfor AMODE= on the PROC statement and a condition if-then-else at the bottom that invokes either

PGM=BBOCTL or PGM=BBGCTL depending on mode desired.

� Make certain the private region size is not limited to a value that precludes the use of a larger heap.See "Memory limits on a 64-bit server" on page 26.

� Enable each server to run in 64-bit mode either through the Admin Console or with WSADMIN:

For initial verification testing, you should choose a server that has no non-Java components,such as connectors or applications with non-Java code.

Note:

� Admin Console: "Run in 64-bit JVM mode" check box under server's "General Properties"

� WSADMIN: use the following JACL command:

$AdminTask setJVMMode {-nodeName aaaa -serverName bbbb -mode 64bit}

Where aaaa and bbbb are the node and server long names, respectively.

� Start the server with AMODE=64 added to the normal MVS START command

� Check for the following message:

BBOO03nnI <type> PROCESS ... IS EXECUTING IN 64-BIT ADDRESSING MODE.

Where nn is 07 through 10, depending on the type of region (Daemon, Servant, Controller or

Adjunct), and <type> is the region type: daemon, servant, control or adjunct.




� Once basic operations is enabled, do the following:

� Make sure any issues with connectors and non-Java code are properly accounted for. See "DataConnector and non-Java Application Implications" starting on page 33.

� Adjust JVM heaps sizes to meet your application requirements. Take into account the effect oflarger JVM heaps on system auxiliary storage.

Basic prerequisites

What follows are the most fundamental prerequisites to starting a bare-bones application server in64-bit mode:

� z/OS Version 1.7 or above

z/OS Version 1.6 will work if ++APARs BA17679 and AA17846 applied.Note:

� WebSphere Application Server for z/OS Version 6.1.0.4 or above

� Application server "enabled" to support 64-bit mode.

A simple process we describe in detail under "Enabling 64-bit Mode Operations for a Server"starting on page 10. At a high level this involves setting a property in one of WebSphere'sconfiguration XML files to indicate the server is to run in 64-bit mode, and the addition of theAMODE=64 operand on the MVS START command.

Note:

� JCL start procedures that have the conditional logic in them to recognize the AMODE=64 operand and

to invoke the proper program module if that operand is present.

If your cell was built fresh using the V6.1 code, then you'll have it. If your cell is one that'sbeen migrated up from earlier versions, your JCL may not have it. We explain all this morefully under "Creating new JCL start procedures that support 64-bit mode" starting on page20.

Note:

� The use of a START command that contains the AMODE=64 operand. For example:

START FZACRC,JOBNAME=FZSR01C,ENV=FZCELL.FZNODEC.FZSR01C,AMODE=64

We used the term "bare-bones application server" because the presence of non-Java things likeconnectors (CICS, IMS) and non-Java application code may require that they be updated to support64-bit mode. Those things tend to expand the list of prerequisites needed. See "Data Connectorand non-Java Application Implications" starting on page 33.

So the list above is the basic stuff needed for you to see the message which indicates your server isrunning in 64-bit mode. For example, a server's servant region message would be:

BBOO0308I SERVANT PROCESS FZCELL/FZNODEC/FZSR01/FZSR01C IS EXECUTING IN 64-BITADDRESSING MODE.

Some questions and answers

Here we'll try to anticipate some of your questions and provide some answers.

Is this something I must do?

No. Using the 64-bit addressing support of WebSphere Application Server for z/OS Version 6.1is optional. You use it only if you determine your applications could benefit from the additionalmemory addressing provided by the 64-bit mode.

See "Is 64-bit mode mandatory or optional?" on page 3.




If I start a server in 64-bit mode, am I required to increase the JVM heap sizes?

Not at all. What this function does is permit you to set the heaps to a far higher value than everbefore. But you are not required to bump the heaps.

That said, if you see no reason to increase the heap sizes, then there's a good chance you don'treally need the server to be running in 64-bit mode. See "Is 64-bit mode mandatory oroptional?" on page 3.

If I start a server in 64-bit mode, do all "regions" of server run in 64-bit mode?

Yes. When you enable a server to run in 64-bit mode and start it with AMODE=64, all regions

start in 64-bit mode: controller region, servant regions and the adjunct region.

Is there any downside to running my servers in 64-bit mode?

See "Is 64-bit mode mandatory or optional?" on page 3.

If I don't do anything, will my servers automatically start using 64-bit mode?

No. The act of enabling 64-bit mode for your servers is a very intentional thing. The defaultbehavior is the standard 31-bit mode. If you apply the 6.1.0.4 code and do nothing else, you'llstill run in 31-bit mode, just as before.

We cover how to enable the support under "Enabling 64-bit Mode Operations for a Server"starting on page 10.

Note:

If I enable a server for 64-bit, can I revert it back to normal 31-bit operations?

Yes, you may. It involves simply doing the same thing you did to enable, but in reverse. Forinstance, rather than checking the "Run in 64 bit JVM mode" check box in the Admin Console,you'd uncheck it. Or, rather than specifying -mode 64bit using WSADMIN, you'd specify

-mode 31bit.

The updated connectors we discuss starting on page 33 are capable of handling either 31-bitor 64-bit automatically. So once you implement the updated connectors and start the serverin 64-bit mode, you do not need to worry about the connector if you fall back to 31-bit.

Note:

It's all pretty simple once you get the hang of it.

May I have some servers at 64-bit but others at 31-bit?

Yes. The z/OS operating system supports some address spaces in 64-bit and others in 31-bit,and WebSphere for z/OS does as well. You are free to enable for 64-bit only those servers thatrequire it, and leave at 31-bit those servers that do not. In other words, you may incrementallyupgrade your environment to 64-bit based on your specific server-by-server needs.

Clusters are an exception -- you should set all servers in a cluster to operate at the same bitmode. This is not a strict technical requirement, but it is a strong recommendation.

Note:

That said, we suggest that you set your sights on eventually having all your servers run in 64-bitmode. The 31-bit support will be deprecated one day and eventually removed. But that won'thappen in near term, meaning 12 to 24 months. For now, it's not necessary to convert all yourservers to 64-bit mode.

Does this apply to application servers only, or all WebSphere server types?

The ability to start a server in 64-bit mode applies to application servers, Node Agents and theDeployment Manager.

Daemons have no JVM; they are a native code server. They can be configured for 64-bit. Butit's a manual process and not something that can be done through the Admin Console.

We suggest you not consider Daemon servers for 64-bit mode operations for now.Note:




Can a 31-bit DMGR or Node Agent support a 64-bit application server?

Yes. Enabling just the application servers -- but not the Node Agents or DMGR -- is anacceptable thing to do. See "Deployment Manager and Node Agents" on page 14 for more onthis.

Will this result in my WebSphere servers using more memory?

There are really three questions here:

Yes. But this is really no different than what's always been the case. If you increase the JVMheap it'll try to allocate more memory. What 64-bit brings to the table is the ability to set yourJVM heaps really high -- beyond the 2GB limit that applied before.

A3

If I increase the JVM heap sizes of a server enabled for 64-bit mode, will it use more memory?Q3

No. The controller, servant and adjunct heap sizes are whatever they are -- either the defaultvalues or whatever you set them to be. Java heap settings are not increased automaticallywhen 64-bit addressing mode is enabled.

That said, what 64-bit addressing mode allows is the ability for you to set the JVM heaps muchlarger.

A2

Does WebSphere automatically increase my JVM heap sizes once 64-bit is enabled?Q2

There's a lot of "it depends" qualifiers to this, but in general tests have shown that all else equal,a 64-bit server uses up to 10% more storage than a 31-bit server. Again, all else equal.

A1

Does a server running in 64-bit mode by itself use more memory, assuming no changes to theJVM heap sizes for that server?

Q1

Is there some guidelines for what I should set my JVM heap sizes to?

There are far too many variables involved to provide a quick answer to this. A lot will dependon the nature of the application, the amount of storage available on the system, and how Javagarbage collection ("GC") is managed.

On that last point, the Java 5 included with WebSphere for z/OS has some new garbagecollection policies. If you're interested in this topic, go to this URL:

http://www.ibm.com/developerworks/java/library/j-ibmjava2/index.html

If I'm planning very large JVM heap sizes, what operating system things should I consider?

In general, the same kinds of things you would consider for anything that looked to use largeamounts of storage:

� Is your real and auxiliary storage sufficient to handle the large memory requirements in anacceptable manner?

� Are there any exits (IEFUSI) that may prohibit allocation of the heap you desire?

The main point here is that WebSphere for z/OS is not an island unto itself, but part of a largersystem -- the z/OS operating instance and the broader Sysplex. Consider the bigger picturewhen thinking about increasing WebSphere for z/OS JVM heaps significantly.




How can I know what mode a server address space is really running?

Look for the BBOO0307I through BBOO0310I message in the started task's JESMSGLG,

depending on the type of address space:

BBOO0307I -- Daemon region

BBOO0308I -- Servant region

BBOO0309I -- Controller region

BBOO0310I -- Control Region Adjunct

An example of the output would be:

64-bit: BBOO03nnI xxx PROCESS yyyy IS EXECUTING IN 64-BIT ADDRESSING MODE.

31-bit: BBOO03nnI xxx PROCESS yyyy IS EXECUTING IN 31-BIT ADDRESSING MODE.

Where:

� nn is 07 through 10, depending on region: daemon, servant, control or adjunct

� xxx is the type of process: "control" or "servant"

� yyyy is the process name, made up of the cell short, node short, cluster short and server shortname, separated by a forward slash. For example:

FZCELL / FZNODEC / FZSR01 / FZSR01C

You may also issue a modify command against a running task to see the mode. Example hereis a modify against the DMGR's controller jobname:

F FZDMGR,DISPLAY,MODE

BBOO0309I CONTROL PROCESS FZCELL/FZDMNODE/FZDMGR/FZDMGR IS

EXECUTING IN 31-BIT ADDRESSING MODE.

BBOO0188I END OF OUTPUT FOR COMMAND DISPLAY,MODE

Does this require me to use the 64-bit version of IBM z/OS Java?

Yes, it does. But you don't need to do anything special to meet that requirement -- the 64-bitJava code is part of the WebSphere for z/OS V6.1 product, as is the 31-bit Java. Both are partof the configuration HFS (or ZFS):

The 31-bit Java 5 code lives under here

/<mount>

/DeploymentManager

/java

:

/java64

:The 64-bit Java 5 code

lives under here

Part of the process of enabling a server to run in 64-mode involves updating the serverconfiguration files to use either the 31-bit (/java) or the 64-bit (/java64). But you won't need

to modify any PATH statements; it's all done for you using the tools we describe under "Enabling64-bit Mode Operations for a Server" on page 10.

If you have V6.1.0.4 (or higher) installed -- that's the level needed to run a server in64-bit mode -- you have the necessary 64-bit Java code. You do not need to goacquire the IBM Java SDK separately.

Key:




Restrictions possible in WebSphere for z/OS 6.1.0.4

APAR PK35753 is what provides support for running WebSphere Application Server for z/OS in64-bit mode. That APAR also provides a listing of potential restrictions that have beenidentified. A listing of the APARs specific to each restriction is provided.

You should read APAR PK35753 and be aware of and familiar with the identified restrictions.




Enabling 64-bit Mode Operations for a Server

Before a server can be started in 64-bit mode, some of the properties within the configuration XML filesneed to be changed. Once that's done, then you can issue a START command with the new AMODE=64

operand to start the server in 64-bit mode.

An overview of what's involved

This really involves four high-level things:

1. Having the WebSphere for z/OS V6.1.0.4 or higher code in place. This is what provides the ability torun a server in 64-bit mode.

2. Making sure the basic system programming requirements are in place. See "Basic systemprogramming requirements to run in 64-bit mode" on page 11 for more on these requirements

3. Enabling the server to run in 64-bit mode. This is telling WebSphere to modify the server'sconfiguration XML files to indicate 64-bit support. There are two methods -- the Admin Console andthe WSADMIN scripting interface. Both accomplish the same thing, but do it in a different manner.

4. Starting the server in 64-bit mode with the AMODE=64 operand on the START command. And yes,

servant processes -- which WLM starts -- will be started with the AMODE=64 operand automatically.

None are particularly difficult to do. We'll cover the process in detail in this section.

Checklist before you start

The following checklist can be used to verify your readiness to switch a server to 64-bit mode:

� Verify z/OS V1.7 (with ++APAR OA14623) or higher, or z/OS V1.6 with ++APARs OA17679 andOA17846 applied.

� Verify WebSphere Application Server Version 6.1.0.4 or higher is applied correctly

Go into the Admin Console and drill down to "System Administration" and then "Nodes."Under the column labeled "Version" will be the level of code for that node. Make sure theDMGR and all the nodes in which you plan to start a 64-bit server are at 6.1.0.4 or higher.

Note:

� Verify the things like APF authorization and STEPLIB are completed. See "Basic system

programming requirements to run in 64-bit mode" on page 11.

� Decide which servers you wish to enable to run 64-bit mode. Capture the node and server longnames for each.

� Determine if the server currently contains any non-Java code that might need to be updated tosupport 64-bit mode operations. Examples of non-Java code would be connectors (CICS, IMS,DB2 Type 2) and application components written in native code (C++ for example). See thediscussion under "Data Connector and non-Java Application Implications" starting on page 33.

� Decide which of the two methods of enabling 64-bit support you wish to use -- the AdminConsole or WSADMIN.

We describe the two methods in detail in the next section.Note:

� Verify the JCL start procedures used by those servers is capable of invoking the server in 64-bitmode.

This involves checking to make sure the JCL has logic in it to invoke either the 31-bit moduleor the 64-bit module, depending on whether AMODE= is specified on the START command.

See "Verifying your JCL is at the right level" on page 19. If you don't have the proper JCLprocedures in place, see "Creating new JCL start procedures that support 64-bit mode" onpage 20.

Note:


Section: Enabling 64-bit modeVersion Date: Wednesday, February 01, 2012


Basic system programming requirements to run in 64-bit mode

There are three areas we'll focus on here. These are in addition to the list of system programmeractivities required to get WebSphere for z/OS to run in general. We're assuming you have a cellalready configured and that you're able to start the servers at the 6.1.0.4 level (or higher) in thenormal default 31-bit mode. What this is describing is what's needed to support the 64-bit modeoperations.

Program properties update

The new BBGCTL program needs to be added to the program properties table. Here's what our

SYS1.PARMLIB(SCHED00) looked like after the update:

PPT PGMNAME(BBODAEMN) /* CB DAEMON */

CANCEL NOSWAP SYST PRIV

KEY(2)

PPT PGMNAME(BBOCTL) /* CB CONTROL REGION */


KEY(2)

PPT PGMNAME(BBGCTL) /* CB 64-BIT CONTROL REGION */


KEY(2)

Program properties for the WebSphere z/OS Daemon and 31-bit Controller

Update to support the 64-bit Controller program (BBGTL)

We issued the command SET SCH=SCHED00 to activate this update.

APF authorization

In total, four of the WebSphere for z/OS program data sets need to be APF authorized:

WAS610.V6104.SBBOLPA

WAS610.V6104.SBBOLOAD

WAS610.V6104.SBBOLD2

WAS610.V6104.SBBGLOAD

This is new with V6.1, and is what comes into play when a

64-bit server is started.

Or whatever your high level qualifier happens to be

The first three are required to be APF authorized for the basic operations of WebSphere forz/OS. The last one -- SBBGLOAD -- is what's required for 64-bit mode operations. Make sure all

four are APF authorized, and in particular make sure SBBGLOAD hasn't been overlooked.

We found that one other data set needed APF authorization: SYS1.CPP.SCLBDLL2. If you

see APF problems even though your SBB* data sets are all authorized, check to see if yourSCLBDLL2 dataset is authorized.

Note:

STEPLIB updates or LPA/LNKLST updates

Whether this access is provided via STEPLIB or LPA/LNKLIST is up to you. The key is making

certain access to the 64-bit module library -- SBBGLOAD -- is provided.




LPA/LNKLST

Include the **.SBBGLOAD data set in your LPA/LNKLST concatenation and activate.

We found that access to one other data set was needed: SYS1.CPP.SCLBDLL2. The

symptom we saw was the failure to find the module IOSX64. If you experience this,

locate your **.SCLBDLL2 dataset, verify IOSX64 is present, and make the data set

available through LPA/LNKLST.

Note:

STEPLIB

Again, a 64-bit server needs access to the WebSphere for z/OS **.SBBGLOAD data set.

Your STEPLIB references may already have this, but it may not (it'll depend on when your

cell was built -- before the V6.1 level or at the V6.1 level). So what you need to do is verifythe presence of a STEPLIB to SBBGLOAD, and if not present then include it.

This process is complicated ever-so-slightly by where WebSphere for z/OS places itsSTEPLIB pointers. There are two places:

1. In the "Z-member", which is brought into the JCL start procedure with an INCLUDE statement

2. In the shell script setupCmdLine.sh, which is found in the configuration HFS (or ZFS) for

each node.

We'll show you both so you can verify and update to STEPLIB references the SBBGLOAD

library.

We found that access to one other data set was needed: SYS1.CPP.SCLBDLL2. The

symptom we saw was the failure to find the module IOSX64. If you experience this,

locate your **.SCLBDLL2 dataset, verify IOSX64 is present, and provide a pointer to

the data set through STEPLIB.

Note:

STEPLIB in JCL

WebSphere for z/OS uses an INCLUDE member to bring STEPLIB (and other DD

statements) into the main JCL start procedure. The INCLUDE member's name is simply

the main procedure's name with a Z appended to it. For instance, if your controller start

procedure is FZACRC, then the include member will be FZACRCZ.

If you ever wondered why WebSphere for z/OS JCL start procedure names werelimited to 7 characters, that's why. The 8th character was reserved for the "Z".

Note:

For those servers you intend to start in 64-bit mode, check the JCL start procedure's"Z-member" (in INCLUDE member) and make sure there's a STEPLIB reference to the

SBBGLOAD data set.

This would include controller region JCL as well as servant region JCL.

STEPLIB in setupCmdLine.sh shell script

Any STEPLIB updates to the JCL must be done also in another location: the

setupCmdLine.sh shell script. The location of that file is as follows:

/<mount>/<home>/profiles/default/bin/setupCmdLine.sh

Where:

� <mount> is the mount point where the node's configuration HFS (or ZFS) is mounted. For

example, /wasv61config/fzcell/fznodec

� <home> is the node's home directory, typically either /DeploymentManager or

/AppServer.




There's another copy of that file under /<mount>/<home>/bin, but that copy does

not have a STEPLIB reference. Make sure you're looking at and changing only the

one under ../profiles/default/bin.

Note:

That file will be in EBCDIC format, so viewing and editing can be done with the standardOEDIT facility. The STEPLIB reference in the file looks like this:

if [ -z $WAS_STEPLIB ]; then

STEPLIB=$STEPLIB:WAS610.V6104.SBBOLPA:WAS610.V6104.SBBOLD2:WAS610.V6104.SBBOLOAD:WAS610.V6104.SBBGLOAD

export STEPLIB

export WAS_STEPLIB=true

fi

STEPLIB=$STEPLIB:WAS610.V6104.SBBOLPA: ... :WAS610.V6104.SBBGLOAD

The STEPLIB string may run past the right side of your screen.

If SBBGLOAD not present, add it to the end and separate with a colon ( : ).

If the reference to SBBGLOAD is already there, you're all set. If not, then add it.

Each node has its own copy of setupCmdLine.sh. Check each node in

which you plan to run a 64-bit server. A suggestion: update thesetupCmdLine.sh file in all nodes so the reference to SBBGLOAD is active

in all nodes.

Key Point:

A note about which servers may be enabled to run 64-bit mode

We mentioned earlier that this 64-bit mode support is enabled on a server-by-server basis. There isno "big switch" that will change the whole cell over to 64-bit. You do it one server at a time until allthe servers you wish to run in 64-bit mode have been enabled to do so.

That brings up a question -- which of the different types of servers in a WebSphere for z/OS cell canbe enabled to run in 64-bit mode? The following table provides the answer:

Note: Daemon servers are capable of running in 64-bit mode, but enabling them to do so involves manuallychanging XML files. It can be done, but it's not something we recommend you worry about at the present time.

� noteDaemon Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

�Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

�Node Agents Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

�Deployment Manager Server . . . . . . . . . . . . . . . . . . . . . . . . . . .

NoYesType of ServerCapable of Running in 64-bit Mode?

But there's another question -- which servers should be enabled to run in 64-bit mode? We'll breakthis into two sections: application servers and DMGR/Node Agents.




Application Servers

You should consider enabling an application server for 64-bit mode if you have applications thatare presently constrained by the addressing in 31-bit mode. The benefits you'll derive from64-bit mode are centered around the applications and their use of the additional heap sizecapability. If your application doesn't need more than the 2GB heap (1.4GB usable) available in31-bit mode, then the server in which that application runs is probably not a good candidate forswitching to 64-bit mode.

If you do choose to enable a server for 64-bit mode, you should also evaluate the applications inthat server to determine if going to 64-bit mode will cause any problems. There are twofundamental areas of possible issues:

1. Any data resource connectors, such as CICS, IMS, DB2 Type 2 or MQ

2. Any user-written or vendor supplied Java Native Interface (JNI) code

These things may not be ready to operate in a server that's switched to 64-bit mode. We go intothese issues under "Data Connector and non-Java Application Implications" starting on page 33.

Applications that are pure-Java don't have these concerns.Note:

Deployment Manager and Node Agents

As noted earlier, Deployment Managers and Node Agents can run in 64-bit mode. But theydon't need to.

In most cases it is not necessary to enable a Node Agent or Deployment Manager for64-bit mode just because an application server in the cell is operating at 64-bit mode.

Key Point:

So why would you ever enable a DMGR or Node Agent to run in 64-bit mode? A few reasonscome to mind:

� If your application servers are all over at 64-bit and you want your whole cell that way soeverything is consistent.

� They're easy servers to practice enabling 64-bit mode on -- the risk of having a non-Javaapplication issue pop up with a Node Agent, for example, is nonexistent.

The bottom line here is that there are few technical reasons to enable 64-bit for DeploymentManagers or Node Agents.

One such technical reason would be when you have a 64-bit server with an enormousapplication. Deploying that application through the DMGR and Node Agent might requireboth to be 64-bit. But it would have to be a pretty big application -- many GB in size.

Note:

They can be enabled for 64-bit if you wish, but there's not a strong technical reason to do so atthe present time. As stated in the "Key Point" above, a 31-bit DMGR or Node Agent will supporta 64-bit application server.

Enabling a server to support 64-bit mode

We mentioned earlier that to run a server in 64-bit mode it's necessary to modify some configurationXML files. While it's technically possible to hand-modify those files, we don't recommend that.There's way too much chance for human error.

Instead, there are two recommended ways to modify the configuration settings for a server so it'll runin 64-bit mode:




1. From the Admin Console(Covered in detail under "Enabling a server to run 64-bit using the Admin Console" on page 15)

With the 6.1.0.4 level of code, the Admin Console has been updated so a new check box appears inthe "general properties" for a server. That check box is labeled "Run in 64 bit JVM mode." Checking

that box for a server and synchronizing the change out to a node will update the appropriate XML files.

This is the route we'd recommend unless you're already somewhat familiar with WSADMIN.Note:

2. Using a WSADMIN function(Covered in detail under "Enabling a server to run in 64-bit mode using WSADMIN" on page 16)

WSADMIN is the administrative programming interface to WebSphere, and with it you can do prettymuch anything you can do through the Admin Console, only with WSADMIN you do it by running aprogram (or really, a "script" -- either JACL or Jython -- which is why WSADMIN is called a "scriptinginterface).

One of the WSADMIN functions is setJVMMode, and with that we can switch a server's settings so

it'll run in 64-bit mode.

Both end up doing the same thing, but in different ways. We'll show you both methods. You maychoose which one best suits you.

Enabling a server to run 64-bit using the Admin Console

This way is pretty simple. We recommend this for those not already familiar with WSADMIN.Each server now has a check box on its "General Properties" labeled "Run in 64 bit JVMmode:"

Clicking on that check box, and then saving and synchronizing the change out to the node inwhich the server lives, will update the configuration XML files and allow the server to be startedin 64-bit mode.

The need to synchronize the change out to the node is really important. A save withoutsynchronization means only the Deployment Manager knows about the updates, not theserver. If you try to start the server in 64-bit mode when the 64-bit updates haven't beensynchronized out to the node, the server will fail to start. That server will still think it'sconfigured for 31-bit.

Always remember to synchronize when the update is to a server in a federated node.

Note:




Accessing the "General Properties" of a server is simple:

System Administration � Node Agents � <Node Agent link>Node Agent

System Administration � Deployment ManagerDeployment Manager

Servers � Application Servers � <server link>Application Server

Navigation Path in Admin ConsoleType of Server

You would perform this operation against each server you wished to run in 64-bitmode.

Key Point:

Enabling a server to run in 64-bit mode using WSADMIN

As mentioned earlier, WSADMIN is a like a programming interface to WebSphere -- things youcan do through the GUI Admin Console can also be done programmatically with WSADMIN.

A little background

For those not familiar with WSADMIN, a really quick introduction:

� WSADMIN is really a programming interface to WebSphere. There are five main "objects"(commands), each with a long list of "methods" (parameters) and options.

Don't worry, you won't have to learn it all to enable 64-bit mode. We'll simply giveyou the command to invoke.

Note:

� To make it even more powerful, the WSADMIN commands can be part of a program -- calleda "script" because the two programming languages supported are interpreted scripts: Jythonand JACL.

� What we're going to show you doesn't really use the scripting power ofWSADMIN. We're just going to invoke a few commands and be done with it.

� We generally recommend any new WSADMIN script development be done withJython, not JACL. JACL works, but is "deprecated" in V6.1 and is slated foreventual withdrawal from support as a WSADMIN scripting language.

Notes:

� Access to the programming interface is through the WSADMIN "client" -- really a shell scriptcalled wsadmin.sh. We'll invoke wsadmin.sh (the "client"), pass in the commands, and the

client will drive the programming interface.

� There are two basic ways to "connect" to WebSphere and use this interface:

1. Network connection to the running Deployment Manager -- this is done with either-conntype SOAP or -conntype RMI.

2. Direct modification of the XML files by WSADMIN client -- this is done with -conntype

NONE

Both have their place. We're going to illustrate the use of -conntype SOAP.

Checklist to prepare for WSADMIN

� We're assuming you have an "ND" configuration -- Deployment Manager, NodeAgent(s) and servers. We'll point out how a "Standalone" (or "Base") server differs.

� If you're familiar with WSADMIN and want to get straight to the commands needed,it is:


Where aaaa is the node long name and bbbb is the server long name. Then:

$AdminConfig save

Then make sure the changes are synchronized to the nodes.

Notes:




� Make sure your Deployment Manager is up and running

� Make sure the Node Agent is up that supports the servers you'll be enabling for 64-bit.

� Go into the Admin Console and capture the SOAP port of your Deployment Manager:

System Administration � Deployment Manager � Ports, then capture the value for theSOAP_CONNECTOR_ADDRESS port.

Servers � Application Servers � <server_link>, then capture theSOAP_CONNECTOR_ADDRESS for the server.

Standalone:

� Make certain you know the userid and password of the Admin ID used to log onto theAdmin Console.

If security is disabled, you don't need to worry about this.Note:

� Capture the long names (not short names) for the servers you intend to 64-bit enable:

Server Long NameNode Long Name

� The DeploymentManager server long name is always dmgr

� Node Agents always have a server long name of nodeagentNotes:

Executing WSADMIN

Do the following:

� Establish a Telnet or OMVS session

� Switch users ("su") to the WebSphere Admin ID

There are cases where this is not required. However, you may find it easier to do itthis way:

1. The Admin ID has write file access permissions to the configuration structure.Without that, WSADMIN will likely fail attempting to open its log files.

2. If security is enabled, access to the keystore where the certificates are locatedis necessary. The WebSphere Admin ID will very likely have that from when thecell was initially built.

If you're well-versed in WSADMIN usage, you may opt to skip this step. Theultimate objective is to establish a WSADMIN session so the AdminTask commandscan be executed. Switching users to the WebSphere Admin ID can make thateasier. But you may do whatever you know works best for you.

Note:

� Change directories to:

/<mount>/DeploymentManager/profiles/default/bin

Where:

� <mount> is the mount point where the node's configuration HFS (or ZFS) is mounted. For

example, /wasv61config/fzcell/fzdmnode

/<mount>/AppServer/profiles/default/binStandalone:




� Invoke the WSADMIN client using the following command, entered onto one line inTelnet or OMVS (line broken here to show all the parameters)

./wsadmin.sh -conntype SOAP -host <host> -port <port>

-user aaaaa -password bbbbb

� If you prefer to use -conntype RMI, you may do that. You would then supply

the BOOTSTRAP port value, not the SOAP port value.

� If security is disabled, omit -user and -password

Notes:

Where:

� <host> is the IP host name of where the Deployment Manager is listening. For example,

wsc2.washington.ibm.com, or whatever yours happens to be.

Or the host address on which your Standalone is listening.Standalone:

� <port> is the SOAP_CONNECTOR_ADDRESS port you captured earlier.

� aaaaa is the WebSphere Admin ID you normally use to log onto the Admin Console.

� bbbbb is the password for the WebSphere Admin ID

� Verify you are at the WSADMIN command prompt:

wsadmin>

� Type in the following command for the first server to be enabled for 64-bit:


Case matters. Type carefully. And those are braces, not brackets.Important!

Where:

� aaaa is the node long name, as captured earlier

� bbbb is the server long name, as captured earlier

� Now repeat that command for each server you wish to enable for 64-bit.

� When you've issued the $AdminTask for each server you wish to 64-bit enable, then

issue the following command:

$AdminConfig save

� Issue the following command to exit WSADMIN:

quit

� Go into the Admin Console and synchronize those changes out to the nodes:

This step is not necessary if it's a standalone server configuration.Standalone:

� System Administration � Nodes

� Place a check in the check box next to each node

� Click on the "Synchronize" button




� Why? Because the WSADMIN changes were made to the DeploymentManager's "master configuration." Synchronization is needed to copy thosechanges out to the node, where they must be to start a server in 64-bit mode.

� Is it possible to just wait until the Node Agent automatically synchronizes? Yes,that's possible. That happens by default every 10 minutes. But it's better toforce the synchronization just to be sure.

� Is there a way to do synchronization with WSADMIN? Yes, but the command israther long and complicated. Easier to go into the Admin Console for this.

Notes:

The JCL start procedure used to start a server in 64-bit mode

The JCL start procedure used to start a controller or servant region in 64-bit mode is slightlydifferent from JCL start procs in the past. That's because the 64-bit mode uses a different programmodule than does the older 31-bit mode. For example, a controller starting in 64-bit mode willinvoke BBGCTL, while a controller in 31-bit mode will invoke BBOCTL.

The new JCL we speak of has an "If-then-else" check in it.: if 31-bit, then invoke BBOCTL, else

invoke BBGCTL.

It is therefore important you have JCL start procedures that will support this. We next show you howto verify your JCL will support this, and if not, then how to create a set of start procedures that will.

Under what circumstances might your JCL not be correct? If your JCL was created at an earlierlevel of WebSphere and you've migrated your cell up to V6.1. Rather than chance it, we'll verify it.

???

Verifying your JCL is at the right level

In order for the 64-bit support to work, you must have the correct JCL start procedure format inplace. Earlier versions of WebSphere for z/OS did not have the appropriate stuff, and it'spossible you're still using those older procs.

The following picture illustrates a typical V6.1 controller JCL start procedure that has thenecessary pieces to support starting a server in 64-bit mode. Compare the sample JCLpresented here against one of your controller JCL start procedures and determine if your JCL isready to support 64-bit mode.

The servant JCL start procedure is shorter, but it too has the test of AMODE= value and the

if-then-else logic. In other words, the following picture applies to servant JCL procs as well.Note:




//FZACRC PROC ENV=,PARMS=' ',REC=N,Z=FZACRCZ,AMODE=

// SET ROOT='/wasv61config/fzcell/fznodec'

// SET FOUT='properties/service/logs/applyPTF.out'

:

(lines removed to save space)

:

//STEP1 EXEC PGM=BBOOMTST,PARM='&AMODE.'

// INCLUDE MEMBER=&Z

//TEST1 IF (STEP1.RC = 0) THEN

//BBOCTL EXEC PGM=BBOCTL,REGION=0M,TIME=MAXIMUM,

// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") / x

// &PARMS. REC=&REC'

//BBOENV DD PATH='&ROOT/&ENV/was.env'


// ELSE

//BBGCTL EXEC PGM=BBGCTL,REGION=0M,TIME=MAXIMUM,MEMLIMIT=NOLIMIT,

// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") / x




// ENDIF

// ENDIF

//IFTSTEND ENDIF

1

2

3

4

Note the REGION=0M

Note the REGION=0M

Notes:

1. One quick initial test is to see if the JCL proc you have has the AMODE= variable on the PROC

statement. The presence of this is a good sign your JCL is okay. You should still verify the otherparts though.

2. The purpose of the program BBOOMTST is to do a simple test to see whether to start the 31-bit

module or the 64-bit module. It interrogates the value of AMODE= you specify, and if it's anything

other than an explicit AMODE=64 it sets RC=0 so the 31-bit module is invoked. If you code

AMODE=64, then RC is something other than 0 and the 64-bit module is invoked.

The &INCLUDE MEMBER=&Z may or may not be there, depending on what level of the

zPMT you used. If it's not there, what you should see in its place is something like this:

STEPLIB DD DISP=SHR,DSN=WAS610.V6104.SBBOLOAD

Which will work equally well, provided the data set pointer to SBBOLOAD is correct.

Note:

3. The "then" clause of the if-then-else condition. This gets invoked when the results of the programin numbered block #2 is RC=0. For this controller JCL example, it shows the module BBOCTL

being invoked, which is the 31-bit code. From there the normal stuff takes place -- theconstruction of the BBOENV pointer to the was.env file and the include of the "Z-member."

4. The "else" clause of the if-then-else condition. This gets invoked when the results of the programin numbered block #2 is something other than RC=0. As mentioned, it appears the only case inwhich this would happen is if you explicitly coded AMODE=64 on the START command.

If the JCL your server will use does not have the components shown in the previous picture,you'll need to create some JCL procs that do have them. That's discussed next.

Creating new JCL start procedures that support 64-bit mode

If you find that your current JCL start procedures do not have the things we just discussed, thenyou'll need to create ones that do. There are two ways to do this:




1. The easiest way to do this is to go back into the zPMT tool (or the ISPF panels) and generate aset of customized jobs. One of those jobs (BBO*CPY1) is what copies the JCL start procs into

your PROCLIB.

If you're unfamiliar with the zPMT, see WP100871 on ibm.com/support/techdocsNote:

We'll discuss this option here, in this section.

2. Another way is to modify your existing JCL start procedures so they have the components we justdiscussed. See "An example of a controller and servant JCL start procedure that support 64-bit"on page 30 if you're interested in going this route.

Overview of process to regenerate the JCL

Creating a new set of JCL start procedures with the zPMT (or the ISPF panels) is really justgenerating the full set of jobs. In other words, there is no "generate JCL only" option. You'llgenerate all the jobs, but rather than run all the jobs you'll just run one -- BBODCPY1

(Deployment Manager) or BBOWCPY1 (federated node).

There are two ways you can approach this:

1. Use an existing saved configuration definition and simply regenerate the jobs using the exactsame set of definitions kept in the saved definition. This applies to either the zPMT or theISPF panels.

For the zPMT the "saved configuration" can be in the form of the whole definition stillpresent in your zPMT, or simply a "response file". Either way you can have thezPMT very quickly regenerate the jobs and the new JCL.

For the ISPF panels the key is the SAVECFG data set, which would contain all the

variables for a customization run. If you still have the SAVECFG, you can veryquickly have the ISPF panels regenerate the jobs and the new JCL.

Note:

See "When you have the previous configuration information still saved" on page 21 for moreon this approach.

2. If you don't have the saved information from before, you can still run through the zPMT (orISPF) from scratch, supplying key information so the JCL is built correctly.

The nice thing is you do not have to have every field exactly correct ... only a handfulof fields need to be correct to have the JCL generated properly.

Note:

See "Generating JCL when you don't have any saved definitions to work with" on page 22 formore on this approach.

When you have the previous configuration information still saved

If you still have the configuration definitions for the cell saved -- either in the form of a saveddefinition in zPMT or the SAVECFG data set for the ISPF panels -- then your job gets easier.You can quickly regenerate the jobs using the saved information from the previousconfiguration definition.

The key to this is making sure you have the latest code so the regeneration processgenerates the proper format JCL. Here's a checklist of things to do:

� Make sure you have at least the following level of code:

� For zPMT, have "zPMT Plugin-in" feature 6.1.0 or higher. � Invoke AST� Select "Help" and "About" from menu bar� Click on "Feature details" button� Look for "zPMT Plugin-in" at the bottom of the scroll list� Validate version of 6.1.0 or higher




� For ISPF, have WebSphere for z/OS V6.1.0.4 or higher. This is the level you needto start a 64-bit server.

� Invoke the tool of your choice -- zPMT or ISPF

� Load the saved definition:

� For zPMT, do one of the following:� If the definition is still seen in the list of "WebSphere for z/OS customization

definitions," then select the definition and click on the "Regen" button� If all you have is a response file, then click on "Create" button

� For ISPF, go to the type of configuration (DMGR or AppServer) and point to theSAVECFG data set from the "Load customization variables" option.

� Regenerate the jobs:

� For zPMT, you have to click "Next" through all the panels, then "Finish"

� For ISPF, you can select the option to "Generate customization jobs"

We'd recommend you go through the panels in any event, just to make sureeverything looks okay -- data sets, STEPLIB, etc.

Note:

� Inspect the JCL and make sure it's ready to support 64-bit servers:

� For zPMT, use the "Upload" function, upload the data sets, then inspect the JCL inthe CNTL data set.

� For ISPF, inspect the JCL in the CNTL data set.

� Run the BBO*CPY1 job to copy the JCL over to PROCLIB. This applies to either zPMTor ISPF. (Once files are uploaded from zPMT, the process from there is identicalbetween zPMT and ISPF.)

Generating JCL when you don't have any saved definitions to work with

If you don't have the saved definition for the cell you can still regenerate the JCL. It simplyinvolves running through the zPMT (or ISPF) and supplying a few key pieces of information.

What we're discussing here is the generation of jobs for the sole purpose ofextracting the JCL only.

We are not talking about generating jobs to actually build a cell.

Here we're suggesting some fields aren't that important. For the JCL they're not.For the construction of a real cell they are all important.

Please understand the distinction. If you're looking to run the jobs to create acell, then you must be much more careful about all the fields in the zPMT.

Important!

zPMT

� We're going to assume you're sufficiently familiar with the zPMT or ISPF panelsthat we can refer to the key parts and not walk through the whole job generationprocess. If you're not familiar, see WP100653 (for ISPF panels) andWP100871 (for zPMT).

� There was a recent update to the AST and zPMT, and some of the panelschanged slightly. What you see here may not be exactly what you see on yourscreen. The important thing is the information being captured, not the exactlylocation or look of the panel itself.

Notes:




Here we'll show you what fields are important when regenerating the jobs to create newJCL start procedures.

� "Target data sets"

1

Notes:

1. This is where the customized jobs from the zPMT will be uploaded. You'll wantto make sure this does not overwrite any existing target data sets.

Remember also that many of the fields in this zPMT run will be allowed todefault. We don't really care about most of the fields for what we're doinghere. Therefore, make the target data set HLQ some name that you'llrecognize immediately as good for only the JCL copy job, but not the otherjobs.

Note:

� "System Locations: Names and data set qualifier"

1

2

3

Notes:

1. For the sake of generating new JCL start procedures, the "System Name" and"Sysplex Name" values don't matter.

2. The PROCLIB data set is important -- this is where the BBO*CPY1 job will put the

new JCL.




3. The "WebSphere product data set high level qualifier" is used to populate thefields on the next zPMT panel. You should make sure this is set to accuratelyreflect where the WebSphere for z/OS product is installed.

� "System Locations: Product data sets"

1

2

3

Notes:

1. The high-level qualifier for all these data sets is first set on the panel just before thisone. The zPMT then carries the HLQ over to this panel and populates the fields withit. If the HLQ isn't correct, back up one panel, fix it there, then come back to thispanel.

2. You should make sure all the data set names are correct, but making sure theSBBOLOAD is correct is especially important. This is what's needed by the

PGM=BBOOMTST, which does that simple test to determine which module to

invoke: 31-bit or 64-bit. If your JCL is counting on STEPLIB to access libraries

and this data set name is wrong in some way, then BBOOMTST will fail to be

found and you'll get a really quick JCL error trying to start your server.

Note 3 is what determines whether the generated JCL will use STEPLIB orassume modules are in LPA/LNKLST.

Note:

3. This check box is what determines whether STEPLIB statements will be built inthe "Z-member." If you want STEPLIB statements, make sure this is checked. Ifyou have WebSphere in LPA/LNKLST, then uncheck this.




� "System Environment: Configuration file system"

1

Notes:

1. The value you provide here is what gets used for the SET ROOT= variable at the

top of the proc. It is really important this be exactly correct -- and case matters,so make sure it's matches exactly what the actual mount point is.

The mount point is everything up to -- but not including -- the/DeploymentManager or /AppServer directory.

Note:

� "Server: Process definitions"

3

2

4

1

Notes:

1. The zPMT will generate the "Job name" values based on the server short namevalue from a few panels before. For the sake of generating new JCL start




procedures, the value that appears here doesn't matter. The JOBNAME is not

part of the proc, it is something passed in on the START command.

2. The "Procedure name" values are critical -- they must be equal to the names ofyour existing JCL ... and by that we mean the JCL you discovered wasn't readyto start a 64-bit server. The value here will be used to create the member nameof the proc, will be used for the name on the PROC statement, and will be usedwhen naming the "Z-member".

3. For the sake of generating new JCL start procedures, the User ID and UIDvalues don't matter. The userid will be assigned based on the existing STARTED

profiles. As long as your replacement JCL start procedures are the same namesas your existing ones, it'll all work as before.

4. For a Deployment Manager configuration you won't see "Controller adjunctprocess." Otherwise, all the other notes apply to both an application server orDMGR.

When the zPMT has generated the jobs, you may then upload them to your z/OS systemand run the BBO*CPY1 job -- BBODCPY1 for a Deployment Manager; BBOWCPY1 for an

application server node.

That will copy the new JCL start procedures over to your PROCLIB. It will also overwriteany members that exist with the same name. You may want to back up your existingJCL procs, just in case you need to fall back.

ISPF panels

The ISPF panels have a slightly different location for some of that information, but ifyou're familiar with the ISPF panels you should have no trouble mapping the zPMT keyfields to the equivalent ISPF panel locations.

The ISPF panels have the exact same requirements as do the zPMT when generatingreplacement JCL.

Memory limits on a 64-bit server

A server started in 64-bit mode has the ability to make use of far more memory than it did before.The really significant additional memory usage doesn't occur until the JVM heaps in the server areincreased, and that's something you would do, not WebSphere.

Therefore, if you bump the heaps for a 64-bit server way up, you'll want to make sure some othersystem settings don't block it.

There are two settings that come into play: REGION= on the JCL JOB or EXEC statement; or

MEMLIMIT= in the JCL or in the PARMLIB member SMFPRMxx:

Specifies the limit on the use of virtual storage above 2 gigabytes for a single addressspace. If you specify a JVM heap greater than 2GB, it may extend up into this range. Avalue of MEMLIMIT=NOLIMIT means it will not be limited above the 2GB bar.

MEMLIMIT

Specifies the maximum size of the execution region for the step in this job between 0Kand 2GB. A value of 0M means it'll take all it needs in that range with no limit imposed.

REGION

Values coded in the JCL will take precedence over the value coded in PARMLIB.




By default the WebSphere for z/OS JCL start procedures have REGION=0 coded on the EXEC

statements of the proc, and MEMLIMIT=NOLIMIT for the invocation the 64-bit BBGCTL:

:

//BBOCTL EXEC PGM=BBOCTL,REGION=0M,TIME=MAXIMUM,

// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") /




// ELSE

//BBGCTL EXEC PGM=BBGCTL,REGION=0M,TIME=MAXIMUM,MEMLIMIT=NOLIMIT,

// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") /



:

That means by default your new 64-bit server will be permitted to acquire as much memory as itneeds.

The default JCL start procedure used for WebSphere for z/OS 64-bit servers will provideREGION=0M and MEMLIMIT=NOLIMIT, which implies no limit. If you change that to a

lower value, or remove it, other limitations may be imposed. It is up to you to insure yoursystem will permit the memory implied by the JVM heap sizes you set.

Key Point:

Server JVM heaps and auxiliary storage

If you bump your server JVM heap sizes way up, it'll mean the server will go out and try to allocatemore memory. Here the fundamental principles of MVS storage management comes into play -- ifthe storage isn't available in central, it'll go to auxiliary. If there's insufficient auxiliary, it'll suggest anallocation problem or excessive paging.

It's up to you to insure your physical resources (central and auxiliary) are sufficient to handle theincreased memory requirements you impose when you increase your JVM heaps.

Starting a server in 64-bit mode does not itself imply a significant amount of additionalstorage demands. The big hit will take place if you bump your JVM heaps -- particularlythe minimum heap, but also the maximum heap if your application expands the heap tomaximum.

Reminder:

Issuing the START command

The MVS START command used to start a server in 64-bit -- once it's enabled to run in 64-bit, of

course -- is simply the common START command with AMODE=64 appended to the end:

S <proc>,JOBNAME=<jobname>,ENV=<cell>.<node>.<server>,AMODE=64

Look for the BBOO0309I message in the controller's output to verify that the server is indeed comingup in 64-bit mode. See "How can I be certain a server truly is starting in 64-bit mode?" on page 29for more on the format of that message.

Common mistakes

� Issue START with AMODE=64 against a server not enabled for that mode. The error symptom is

provided under "What is the error symptom seen when a 31-bit enabled server is started withAMODE=64?" on page 29.

What are some reasons why a server might not be enabled for 64 bit mode?

� You never actually enabled it

� You enabled it (Admin Console or WSADMIN) but changes not synchronized out to the node

� You used WSADMIN but forgot to issue the $AdminConfig save command




� Issue a basic START against a server that's been enabled for 64-bit mode. In other words, you

forgot that the server was 64-bit enabled and you forgot to put the AMODE=64 operand on the

START command. The error symptom you'll see is provided under "What is the error symptom

seen when a 64-bit enabled server is started in 31-bit mode?" on page 30.

See "How can I check what mode a server is enabled for?" on page 30 for an explanation ofhow to verify a server has been 64-bit enabled.

Note:

� You overlook one of the system programming requirements, such as APF authorizing theSBBGLOAD data set or not providing access to the SBBGLOAD through LNKLST or STEPLIB.

� The WebSphere for z/OS V6.1.0.4 code is not really applied to the node in which the server isbeing started. Check the Admin Console under "System Administration" and "Nodes" and makesure the Admin Console sees the node as "Version 6.1.0.4" or higher.

Some questions and answers

Here again we'll try to anticipate some of your questions and provide some answers.

Does enabling 64-bit update the START command held in the configuration XML?

WebSphere is sometimes called upon to issue the MVS START command for a server. This

would be the case when you click the "Start" button in the Admin Console for a server. Howdoes WebSphere know what JOBNAME= and ENV= string to use? It gets that information out of

the configuration XML files it maintains for the server. WebSphere builds the complete START

command and passes it to z/OS for execution.

What this question is getting at is whether or not the AMODE=64 operand is added to the

properties held in XML that define what the START command will be. And the answer to that is"Yes." When you enable 64-bit mode through the "Run in 64 bit JVM mode" check box in theAdmin Console or the WSADMIN method, that process will update the internally-held valuesthat are used to make the START string. If a server is enabled for 64-bit mode, it will have theAMODE=64 operand on the START value. It's all automatic.

However, if you the human operator issue the START command from the MVS console, then

it's up to you to add the AMODE=64 to the START command. If WebSphere issues the

START command, it'll use the information kept in the configuration XML files. And that

information is updated when a server is enabled for 64-bit mode.

Note:

What files are changed when a server is enabled for 64-bit mode?

We do not expect you to crawl into XML files to make any updates. This was provided tosatisfy curiosity. ☺

Note:

The Admin Console reports three file updates when a server is enabled for 64-bit mode:

Two separate properties are set to reflect the server running in 64-bit mode.variables.xml

The AMODE=64 value is updated on the START command properties, and

the jvmmode property is set to 64.

server.xml

But in reality nothing is changed inside the file.serverindex.xml

If I enable a server for 64 bit, should I update my automation routines?

If you have automation routines that start the server, then yes. Those routines should beupdated with the AMODE=64 operand added to the START command.

If you don't have any automation routines, you can ignore this question.




Is there any way to make server start in 64 without AMODE=64 on the START command?

Yes. It would require you to manually modify the JCL start procedure for the controller andhard-code AMODE=64 on the PROC statement. The AMODE= variable will already be present.

What won't be there by default is the value 64. Hard-coding that in the proc eliminates the need

to pass it in as an operand on the START command.

Is there a way to convert a whole cell at once, rather than server by server?

In reality, no. You can make it appear as if the whole cell is being done at once by writing aWSADMIN script that simply invokes the AdminTask object multiple times, once for each serverin the cell. But that's really just doing the whole cell one server at a time.

Yes, it is possible with WSADMIN to query for the server names, then loop through them.So it would be possible to write a script that really automates this thing. But that's beyondthe scope of this document.

Note:

Any advantage to the Admin Console method vs. the WSADMIN method?

Not really. It's really just a matter of which you're most comfortable with. At the end of the daythey both do the same thing: update XML files.

How can I be certain a server truly is starting in 64-bit mode?

Look for the BBOO03nnI message in the started task's JESMSGLG:

BBOO03nnI xxx PROCESS yyyy IS EXECUTING IN 64-BIT ADDRESSING MODE.

Where:

� nn is a value of 07 through 10, depending on the process type: daemon, servant, control or

adjunct

� xxx is the type of process: daemon, servant, control or adjunct

� yyyy is the process name, made up of the cell short, node short, cluster short and server shortname, separated by a forward slash. For example:

FZCELL / FZNODEC / FZSR01 / FZSR01C

Do I need to increase my server's JVM heaps after enabling server to run in 64?

Not necessarily. The 64-bit mode does not itself require a bigger heap. However, you may wishto increase the heaps because of some application need you've identified.

There is, as noted, a basic performance cost to running in 64-bit mode as compared to31-bit mode, all else equal. It is possible to overcome some of this by increasing the JVMheap to offset the additional Java garbage collection overhead that would otherwise occur.A rough planning number is that a 20% increase in the heap will offset the GC overhead.

Note: That's an approximation only ... your results may vary depending on many things thatcome into play when evaluating total system performance.

Note:

What do I need to do if I want to go back to 31-bit mode for a server?

Two things:

1. Disable the 64-bit support for the server, either by going into the Admin Console andun-checking the "Run in 64 bit mode" check box, or using WSADMIN and changing the-mode parameter value to 31bit rather than 64bit.

2. Restart the server, but this time without the AMODE=64 operand on the START command.

What is the error symptom seen when a 31-bit enabled server is started with AMODE=64?

BBOO0330E THE SERVER IS CONFIGURED FOR 31-BIT MODE AND CANNOT

STARTED IN 64-BIT MODE. START THE SERVER IN 31-BIT MODE.




What is the error symptom seen when a 64-bit enabled server is started in 31-bit mode?

BBOO0329E THE SERVER IS CONFIGURED FOR 64-BIT MODE AND CANNOT

STARTED IN 31-BIT MODE. START THE SERVER IN 64-BIT MODE.

How can I check what mode a server is enabled for?

There are two ways you can do this:

� Through the Admin Console

This would be the easiest way. Just drill down to the "General Properties" of the particularserver, and see if the "Run in 64 bit JVM mode" check box is checked. If it is, then theserver is enabled for 64-bit mode. If it is not, then the server is still only enabled for 31-bitmode.

� Inspecting contents of was.env file

This way might prove handy to know this if you can't get access to the Admin Console. Dothe following:

� Drill down to the directory in which the was.env file resides. This is way down under:

/<mount>/AppServer/profiles/default/config/cells/<cell>/nodes/<node>/servers/server

� Browse the was.env file and search for the string jvmmode=. If the server has been

enabled for 64 bit, you'll see this:

was.com.ibm.websphere.zos.jvmmode=64bit

An example of a controller and servant JCL start procedure that support 64-bit

If you find your server JCL start procedures aren't ready to support starting a 64-bit mode server,you may choose to modify the procs so they can start the 64-bit server. The following exampleshighlight some of the key things to watch for.

If you're at all in doubt about modifying the procs, perhaps you should consider regenerating theprocs using the zPMT tool (or the ISPF panels) as we described on page 20.

Note:

Sample controller JCL

********************************* Top of Data **************************

//FZACRC PROC ENV=,PARMS=' ',REC=N,Z=FZACRCZ,AMODE= 1// SET ROOT='/wasv61config/fzcell/fznodec' 2// SET FOUT='properties/service/logs/applyPTF.out'//*************************************************************//* Test that OMVS can successfully launch a shell and return *//*************************************************************//TOMVS EXEC PGM=BPXBATCH,REGION=0M,// PARM='SH exit 13'//STDOUT DD PATH='&ROOT./&ENV..HOME/&FOUT.',// PATHOPTS=(OWRONLY,OCREAT,OAPPEND),PATHMODE=(SIRWXU,SIRWXG)//STDERR DD PATH='&ROOT./&ENV..HOME/&FOUT.',// PATHOPTS=(OWRONLY,OCREAT,OAPPEND),PATHMODE=(SIRWXU,SIRWXG)//*********************************************************//* If the shell RC code is as expected (13) - proceed *//*********************************************************//IFTST IF (RC = 13) THEN//*********************************************************//* Start the Multi-Product PTF Post-Installer *//*********************************************************//APPLY EXEC PGM=BPXBATCH,REGION=0M,// PARM='SH &ROOT./&ENV..HOME/bin/applyPTF.sh inline'//STDOUT DD PATH='&ROOT./&ENV..HOME/&FOUT.',// PATHOPTS=(OWRONLY,OCREAT,OAPPEND),PATHMODE=(SIRWXU,SIRWXG)//STDERR DD PATH='&ROOT./&ENV..HOME/&FOUT.',




// PATHOPTS=(OWRONLY,OCREAT,OAPPEND),PATHMODE=(SIRWXU,SIRWXG)// IF (APPLY.RC <= 4) THEN//*********************************************************//* If the RC from the Post-Installer is LE 4 then start *//* the WebSphere Application Server *//*********************************************************

//STEP1 EXEC PGM=BBOOMTST,PARM='&AMODE.' 3// INCLUDE MEMBER=&Z 4//TEST1 IF (STEP1.RC = 0) THEN//BBOCTL EXEC PGM=BBOCTL,REGION=0M,TIME=MAXIMUM,// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") / x// &PARMS. REC=&REC'//BBOENV DD PATH='&ROOT/&ENV/was.env'// INCLUDE MEMBER=&Z// ELSE//BBGCTL EXEC PGM=BBGCTL,REGION=0M,TIME=MAXIMUM,MEMLIMIT=NOLIMIT,// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") / x// &PARMS. REC=&REC'//BBOENV DD PATH='&ROOT/&ENV/was.env'// INCLUDE MEMBER=&Z// ENDIF// ENDIF//IFTSTEND ENDIF////* ================================================================ *///* PROPRIETARY-STATEMENT: *///* Licensed Material - Property of IBM *///* *///* 5724-I63, 5724-H88, 5655-N01, 5733-W61 *///* (C) Copyright IBM Corp. 1999, 2006 *///* All Rights Reserved *///* US Government Users Restricted Rights - Use, duplication or *///* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.*///* ================================================================ *///* File Tailored on 06/11/16 at 17:55:31.52 by BAGWELL//* From source skeleton: WAS610.V6104.SBBOSLIB

Notes:

1. Several points:

� The controller proc name is tied to a STARTED profile which assigns the ID. If you're creating a new

controller proc for 64-bit mode, make sure it has the same name as before.

� The Z= value must point to the actual Z-member. Just like the controller proc name, this should be

equal to what it was before.

� The AMODE= is one thing that's new with the 64-bit support

2. The SET ROOT= value is critical. It must point to the mount point of the HFS (or ZFS) of the node for

the server you intend to start in 64-bit. This requirement isn't new with the 64-bit support; the SET

ROOT= variable has been part of the procs since V5.0.

3. This whole section blocked in gray is what's new with the 64-bit support. This is really an if-then-elsestructure based on the outcome of the execution of PGM=BBOOMTST, which reads the AMODE= value

supplied to determine whether the 31-bit module (PGM=BBOCTL) or the 64-bit module (PGM=BBGCTL) is

to be run. (We outlined the logic of this under "Verifying your JCL is at the right level" on page 19.) Ifyou're creating a new servant proc for 64-bit mode, you should make sure it contains a section like this.

4. Rather than &INCLUDE you may see a STEPLIB DD here. It depends on the level of the zPMT tool you

used at the time you generated the JCL. The ISPF panels at the 6.1.0.4 level will produce the&INCLUDE. The STEPLIB will work, provided it accurately points to the correct SBBOLOAD data set.




Sample servant (or adjunct) JCL

********************************* Top of Data *************************

//FZASRC PROC ENV=,Z=FZASRCZ,AMODE= 1// SET ROOT='/wasv61config/fzcell/fznodec' 2//STEP1 EXEC PGM=BBOOMTST,PARM='&AMODE.' 3// INCLUDE MEMBER=&Z 4//TEST1 IF (STEP1.RC = 0) THEN//BBOSR EXEC PGM=BBOSR,REGION=0M,TIME=NOLIMIT,// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") /'//BBOENV DD PATH='&ROOT/&ENV/was.env'// INCLUDE MEMBER=&Z// ELSE//BBGSR EXEC PGM=BBGSR,REGION=0M,TIME=NOLIMIT,MEMLIMIT=NOLIMIT,// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") /'//BBOENV DD PATH='&ROOT/&ENV/was.env'// INCLUDE MEMBER=&Z// ENDIF////* ================================================================ *///* PROPRIETARY-STATEMENT: *///* Licensed Material - Property of IBM *///* *///* 5724-I63, 5724-H88, 5655-N01, 5733-W61 *///* (C) Copyright IBM Corp. 1999, 2006 *///* All Rights Reserved *///* US Government Users Restricted Rights - Use, duplication or *///* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.*///* ================================================================ *///* File Tailored on 06/11/16 at 17:55:33.32 by BAGWELL

Notes:

1. Several points:

� The servant proc name must be equal to what WebSphere is maintaining in its configuration XMLfiles. If you're creating a new servant proc for 64-bit mode, make sure it has the same name asbefore.

� The Z= value must point to the actual Z-member. Just like the servant proc name, this should be

equal to what it was before.

� The AMODE= is one thing that's new with the 64-bit support

2. The SET ROOT= value is critical. It must point to the mount point of the HFS (or ZFS) of the node for

the server you intend to start in 64-bit. This requirement isn't new with the 64-bit support; the SET

ROOT= variable has been part of the procs since V5.0.

3. This whole section blocked in gray is what's new with the 64-bit support. This is really an if-then-elsestructure based on the outcome of the execution of PGM=BBOOMTST, which reads the AMODE= value

supplied to determine whether the 31-bit module (PGM=BBOSR) or the 64-bit module (PGM=BBGSR) is to

be run. (We outlined the logic of this under "Verifying your JCL is at the right level" on page 19.) Ifyou're creating a new servant proc for 64-bit mode, you should make sure it contains a section like this.

4. Rather than &INCLUDE you may see a STEPLIB DD here. It depends on the level of the zPMT tool you

used at the time you generated the JCL. The ISPF panels at the 6.1.0.4 level will produce the&INCLUDE. The STEPLIB will work, provided it accurately points to the correct SBBOLOAD data set.




Data Connector and non-Java Application Implications

In the previous section we discussed how to enable and start a server in 64-bit mode. We made anassumption: there were no application-related issued that would pop up and cause problems when theserver came up in 64-bit mode.

In reality, application-related issued might come up. For the purposes of this section we're going tofocus on two areas:

1. IBM connector issues -- connectors for back end data system such as IMS, CICS, DB2 and MQ. Theconnectors supplied by IBM to be used within WebSphere to access those systems may need to beupdated to work within a 64-bit server. We'll cover in more detail the current plan for delivery of thoseconnectors.

2. User JNI application code issues -- your in-house written application code might make use of JNI to callnon-Java code. If so, they may need to be modified.

If you are using third-party (ISV) applications that run within WebSphere for z/OS, you should makecertain that ISV supports their code running in 64-bit before you starting the server in 64-bit. Onlythey can say whether they do or do not support 64-bit operations at this time.

Note:

Overview of the issue

The following paragraph sums up what the issue is:

Programs interacting with the 64-bit Java product, whether launching the JVM or being called from theJVM through the JNI interface, must be 64-bit programs. Programs dependent on JNI interfaces mayrequire changes at the interface boundary to conform to 64-bit data types. Application JNI routineswritten in C will need to be recompiled for 64-bit, which may require some code changes.

(emphasis added)

Reference: http://www.ibm.com/servers/eserver/zseries/software/java/j5pcont64.html

IBM data connector issues

The introduction of the 64-bit mode in WebSphere brings with it a need to insure that key dataconnectors are compatible with the JVM running in 64-bit mode. Many of the connectors use JNI toinvoke native code, and that code needed to be changed to interoperate with a 64-bit JVM.

We'll focus on four connector groups: DB2, CICS, IMS and MQ.

IBM data connectors are not the only ones that work with WebSphere. Other software vendorsmake connectors that operate from within the J2EE framework of WebSphere for z/OS. Checkwith those vendors for their support statements relative to 64-bit mode operations.

Note:

This topic can be somewhat confusing because these connectors often have different ways they canbe configured. Some configuration options require a change for 64-bit, some others may not. We'lldo our best here to explain the different options and offer information on what updates you require.

Overview summary chart

391Q-2007PK312896.0.2.1MQ

1Q-2007PK30868IMS DB RAR

1Q-2007PK31179IMS DC RAR

37TM9IMS

34nowCTG for z/OS V7.0CTG V72CICS (CTG)

34nowPK25139V81DB2

PageAvailabilityAPARVersionType


Section: Data Connector and non-JavaVersion Date: Wednesday, February 01, 2012


2 There is no plan to provide 64-bit support for CTG for z/OS for versions prior to V7

1 64-bit support is part of the base DB2 V9 product. There is no plan to provide this for DB2 V7.

DB2

DB2 and WebSphere for z/OS provide two basic approaches to accessing DB2:

� A local (cross-memory) connection. This is a Type 2 driver.� A network-based request, which requires DRDA listening on a TCP port. This is a Type 4 driver.

Strictly speaking, a Type 4 driver will work with a 64-bit server without requiring any PTFs orupdates. The fix really only applies to Type 2 drivers. That said, the PTF brings with it agood many other fixes and enhancements beyond just 64-bit support, so applying it might bea good thing to do even if you have Type 4 drivers configured.

Note:

DB2: The short answer

To get support for accessing DB2 from a 64-bit WebSphere for z/OS application server, getthe PTF for PK25139, applicable to DB2 V8:

currently availablePK25139JDBC Universal Driver that supports 64-bit

Planned DeliveryAPARDescription

The PTF will update existing drivers.

DB2: implementing the update

Once the PTF is applied, all that's required is that you stop and restart the server in whichthe application resides. Restarting it will pick up the new provider modules and allow a Type2 driver to work with a 64-bit application server.

There is no need to redefine JDBC providers or redefine data source definitions.

CICS

Accessing CICS is interesting because the IBM product that delivers the CICS connectivitysupport is called "CICS Transaction Gateway," and that product has several differentconfiguration options. We'll offer a short answer and a more detailed one.

CICS: The short answer

15-Dec-2006n/aCICS Transaction Gateway V7.0


64-bit support is provided in the V7.0 release of the CTG product. There are noplans to offer a PTF applicable to earlier versions of CTG.

Key Point:

CICS: the longer answer

When it comes to accessing CICS on z/OS from WebSphere on z/OS, there are two basicconfiguration options:

� Local -- the CTG "resource adapter" is all that's needed. The adapter, packaged in theform of a RAR file, is installed into the WebSphere for z/OS runtime environment orpackaged with the application EAR file. This configuration is applicable only when theWebSphere application server and the CICS region are present within the same MVSimage. A picture of this would be:




CICS Region

WebSphere Application Server

MVS Image Application server operating in 64-bit mode

CTG V7.0 resource adapter RAR file installed

CICS region, either application or routing

EXCI

� Here it is absolutely critical that the RAR file containing the CICS resourceadapter code be the CTG V7.0 (or higher) level. WebSphere, running in 64-bitmode, is going to call native modules to drive against CICS, and those modulesmust be the updated 64-bit flavor. CTG V7.0 is the only delivery method forthose new 64-bit modules required to drive CICS locally, as is pictured above.

� The CTG V7.0 resource adapter is smart enough to know whether the server isoperating in 31-bit or 64-bit mode. It'll automatically call the appropriate DLL.So you don't need to change anything if you switch from one mode to the other --provided you have the CTG V7.0 adapter installed.

Notes:

� Remote -- the CTG "resource adapter" provides the communication code tocommunicate over a TCP network to the CTG "Gateway Daemon" -- a long runningprocess that listens on a configured TCP port and drives CICS EXCI on behalf of theremote requester. A picture of this would be:

Application server operating in 64-bit mode

CTG V7.0 resource adapter RAR file installed

CICS region, application or

routing


MVS Image A

CICS Region

CTG V7.0 Gateway Daemon

MVS Image B

EXCI

Gateway Daemon, configured and

started, listening on defined TCP port

request flow over TCP

3

2

4

1

Notes:

1. The key to this picture is that the WebSphere for z/OS application server and the CICSregion are not co-located on the same operating system instance (MVS image). Whetherthe two MVS images are in the same Sysplex or different Sysplexes doesn't really alterthis picture.

Though being on the same Sysplex offers other advantages. But in either case-- within same Sysplex or not -- the CICS resource adapter connection factorywill have its "connection URL" configured as something other than local:

Note:

Also, even if the part of the WebSphere cell is on the same MVS image with the CICSregion, it's the proximity of the application to the CICS region that's the key. If theapplication is in a server on SYSA and the CICS region is on SYSB, this remoteconfiguration is necessary, even if there's another application server for this cell on SYSB.




The presence of a routing region on SYSA would change things ... then youcould use the "local" option as presented earlier.

Note:

2. Even though the connection is remote, it still requires the CTG V7.0 resource adapterinstalled into the application server node.

3. There are other protocol options than merely TCP (such as HTTP). We use TCP as anillustration because it's so commonly understood.

4. The CTG Gateway Daemon is entirely separate from the WebSphere application server.The only "connection" is across the network. The Gateway Daemon only runs in 31-bitmode, but it makes no difference whether the remote WebSphere application server is in31-bit or 64-bit mode -- the connection is over the network so those issues don't pop upas they do when it's local. But it is important that the CTG Gateway Daemon be at V7.0(or higher) -- the Gateway Daemon must be at an equal or higher level from any resourceadapters that are making contact with it.

CICS: implementing the update

Once you've acquired the new CTG V7.0 code and installed it, it's then time to incorporatethe new function. As the previous discussion showed, there are several places where thatmight apply: the resource adapter (in WebSphere or in application EAR), the CTG GatewayDaemon, or both.

Resource adapter inside of WebSphere Application Server

This will come in the form of a new RAR file, delivered with the new CTG V7.0installation. To implement this RAR file you need to delete the old RAR file and reinstallthe new.

Do the following:

� Install the CTG V7.0 code.

� Go into the Admin Console and capture all the information from the connection factoriesdefined under the currently installed CICS resource adapter.

Unfortunately, deleting a resource adapter also deletes any connection factoriesdefined "under" the adapter. You'll need to rebuild them.

Note:

� Delete the currently installed resource adapter.

� Reinstall the new resource adapter using the RAR file supplied with CTG V7.0

� Redefine the connection factories.

� Restart the application server

Resource adapter inside of application EAR file

� Acquire the CTG V7.0 RAR file

� Repackage your EAR file

� Redeploy the application

CTG gateway daemon

If any remote clients connecting to the gateway are using the new CTG V7.0resource adapter, the gateway must be updated to CTG V7.0 as well. The CTGV7.0 gateway is backwards compatible and will accept connections from downlevelclients.

Note:

There are two basic ways to approach this:




1. Change your existing gateway so it ceases to use the CTG V6 code and starts using theCTG V7 code. This would involve a temporary outage, but would mean no changes tothe configurations of remote clients that connect to the gateway.

2. Put up a new gateway alongside the existing one. It would necessarily have a differentlistener port. Remote clients would need to be reconfigured to point to the new gateway

The first may be the easiest. It would involve modifying the JCL start procedure andconfiguration files to point to the new CTG V7.0 code locations. Then stopping andrestarting the gateway.

IMS

In this section we'll cover the connection solutions used with IMS.

IMS: The short answer

There are two basic ways in which an application in WebSphere for z/OS can connect toIMS. Each has its own PTF delivery and schedule for support for WebSphere for z/OSapplication servers running in 64-bit mode:

1Q-2007PK30868IMS DB RAR (formerly IMS JDBC)

1Q-2007PK31179IMS DC RAR (formerly IMS Connector for Java)


Both these methods of connecting to IMS involve the use of a new "Resource Adapter"packaged in the form of a RAR file, installed into WebSphere for z/OS. Each method has itsown separate RAR file. The PTF in each case involves a replacement RAR file. BothAPARs list IMS TM V9 as a basic pre-req.

For more details of each, read on ...

IMS: The longer answer

Let's explore just a bit more closely the two options we just cited:

IMS DC RAR (formerly IMS Connector for Java)

This way of connecting to IMS makes use of an IMS Resource Adapter (RAR file) andproperties set in the connection factory to specify the type of connection. There are twotypes of connections:

� Local -- the connection to IMS is made directly. This requires IMS to be on the sameMVS image as the WebSphere for z/OS application server in which the requestingapplication resides:

IMS Region



IMS DC RAR with APAR PK31179

IMS Region




� This requires PTF for PK31179 if coming from a 64-bit application server. It

involves the deleting of the existing RAR file and the installation of thereplacement RAR file.

� Updated code works for either 31-bit or 64-bit servers. Automatic detectionof mode and load of appropriate modules.

� The 64-bit support provided for a "local" connection is set up to "tolerate"64-bit mode. It works, but it's something less than optimal. The desireddirection is to use TCPIP as the connection method.

Notes:

� TCPIP -- the connection is made to IMS Connect (or IMS itself, if IMS TM9) listeningon a defined TCP port. With this there is no restriction on WebSphere for z/OS andIMS being co-located on the same MVS image. They can be on the same, or ondifferent images:

Application servers operating in 64-bit mode


MVS Image A

IMS Region

MVS Image B

1


Defined port on which IMS listens for connections

1

2



� Updated code works for either 31-bit or 64-bit servers. Automatic detectionof mode and load of appropriate modules.

Notes:

Notes:

1. Like the CICS Transaction Gateway RAR file, the IMS RAR would need to beinstalled in each WebSphere for z/OS node in which applications connecting to IMSresided.

2. Starting with IMS TM V9 the listening function was integrated into IMS itself. Prior tothat, it required the "IMS Connect" product, which was a separate started task thatlistened on a TCP port and connected to IMS using the local method.

IMS DB RAR (formerly IMS JDBC)

This method of accessing IMS also uses a resource adapter, but a different RAR filefrom the one used for "IMS DC RAR." This provides DB access to IMS using IMSODBA, where both IMS and WAS have to be in same LPAR:




IMS Region



IMS DB RAR with APAR PK30868

IMS Region

ODBA



� Updated code works for either 31-bit or 64-bit servers. Automatic detection ofmode and load of appropriate modules.

Notes:

IMS: implementing the update

Do the following:

� Apply the appropriate PTF to the target libraries.

� Capture all the information from the connection factories defined under the currently installedIMS resource adapter.

Unfortunately, deleting a resource adapter also deletes any connection factoriesdefined "under" the adapter. You'll need to rebuild them.

Note:

� Delete the currently installed resource adapter.

� Reinstall the resource adapter using the new RAR file supplied with the PTF.

� Redefine the connection factories.

� Restart the application server.

MQ

There are two basic ways applications in a WebSphere for z/OS server may access MQ Series:

� Bindings mode -- the connection from WebSphere to the MQ queue manager is through a directprogrammatic linkage. There is no network interaction between application and the queuemanager. This mode requires that the WebSphere for z/OS application server and the MQ queuemanager be located on the same MVS image.

� Client mode -- the connection from WebSphere to the MQ queue manager is across a TCPnetwork. The application communicates programmatically to code in the application server, whichthen bundles up the requests and sends them to the MQ queue manager over a TCP/IP MQ clientconnection to the queue manager. The MQ queue manager may or may not be located in thesame MVS image.

A loose analogy would be the JDBC Type 2 and Type 4 drivers ... Type 2 is a direct invocationof native DB2 code, much like bindings mode is a direct invocation of native MQ code. Type 4involves a network connection, as does client mode.

Explaining the combination of product levels for both WebSphere Application Server and MQcan get a bit confusing. We feel it best to include information on connectivity to MQ 5.3.1 aswell since many customers are still on that level. So to map this out we'll use the followingmatrix:




The following table assumes WebSphere Application Server or z/OS V6.1.0.4 as astarting point -- that's the level that brings in the 64-bit support and is the purpose ofthis document. Earlier levels of WebSphere for z/OS may work in some cases, but wedon't go back to earlier levels of Websphere in this matrix. Our "stake in the ground"for the purposes of this document is WebSphere for z/OS 6.1.0.4 and we work fromthere.

This table is specific to z/OS. Requirements are slightly different on distributed.

As you see, in some cases we require updates to WebSphere Application Server forz/OS. So do not assume that Websphere 6.1.0.4 is all you need.

Important:

Requires WAS 6.1.0.6+ MQ 6.0.2.1

(PK31289, planned1Q2007)

Works with WAS6.1.0.4

No planned support forthis combination

Requires WAS 6.1.0.5+ MQ CSD 13

(PK31290)

BindingsMode

Requires WAS 6.1.0.6Works with WAS

6.1.0.4See note3Works with WAS

6.1.0.4ClientMode

WAS 64-bitWAS 31-bitWAS 64-bitWAS 31-bitMQ 6.0MQ 5.3.1




3 Supported as long as the MQ client shipped with WebSphere V6.1.04 or above is used. Other sources of the MQ clientmay work but is not supported. This only applies to client mode, not bindings mode.

User JNI application code issues

In the majority of cases, no changes should to be needed for Java applications that you haverunning in WebSphere Application Server in 31-bit mode today. You should find that after startingyour WebSphere servers in 64-bit mode your 100% Java applications will "just work".

There's one thing you should be aware of. It's not related to 64-bit as much as it is related to thenew Java. There were some incompatibilities introduced industry-wide (not just IBM Java, but allvendor Java) between Java 2 SDK 1.4 and SDK 5 APIs. You can see a list of theseincompatibilities at the Sun Java website:

http://java.sun.com/javase/technologies/compatibility.jsp#incompatibilities

Again, this is not so much a 31-bit vs. 64-bit issue as it is Java 1.4 vs. Java 5.

A general guideline would be this: if your applications are behaving properly in WebSphere forz/OS V6.1 at 31-bit (which uses Java 5), then you very likely do not have an issue with theseincompatibilities. Switching to 64-bit would not introduce them -- going to Java 5 would haveintroduced them, going from 31-bit to 64-bit would not.

Switching to 64-bit might introduce issues with non-Java code, though. Read on ...

Note:

There are situations where Java alone does not meet the needs of your application. An examplewould be exploiting platform-dependent features needed by the application that Java class librariesdo not supply. In these cases programmers might use the Java Native Interface (JNI) to write Javamethods that can call (or be called) by native (non-Java) code. For instance, perhaps you alreadyhave a library written in another language and wish to re-use the business logic contained in thislibrary from Java. Or you may have certain time critical routines that you wish to implement inassembler. Both are examples where the JNI is typically used.

Here's the key with respect to WebSphere for z/OS running in 64-bit mode: any time a Javaapplication in a 64-bit server looks to call a native program through JNI, that native program mustalso be 64-bit programs. Typically these native programs will be code written in C or C++, orperhaps LE compliant assembler.

Native non-Java code can also launch a JVM through the JNI interface. If the native code is64-bit then the JVM launched would also have to be 64-bit. While in both cases theconsiderations we're outlining here would apply, for the sake of WebSphere for z/OS discussionsthe most likely scenario is going to be a Java program in the WebSphere for z/OS JVMlaunching native code through JNI.

Note:

Three key considerations

There are three key things to keep in mind when considering moving to WebSphere for z/OS64-bit mode operations:

1. Java code that calls native code through JNI should be written to work in either a 31-bitserver or a 64-bit server.

This is simply to make your code as compatible as possible. One way to accomplish this is withthe com.ibm.vm.bitmode JVM system property that's part of IBM's Java implementation. This

property will return the bit-mode of the JVM in which the code is executing:

JVM operating in 64-bit mode64

JVM operating in 31-bit mode32

MeaningReturn

Here's a sample snippet of that code that illustrates that in use:




public static int getBitMode()

{

if ( bitMode == 0 )

{

String CurrentBitmode = System.getProperty("com.ibm.vm.bitmode");

try

{

bitMode = Integer.parseInt(CurrentBitmode);

}

catch( Exception e )

{

bitMode = 32;

}

}

return bitMode;

}

a

b

c

d

Notes:

a. The com.ibm.vm.bitmode system property is invoked and the results placed in the string

variable CurrentBitmode.

b. If no exception was thrown, it means com.ibm.vm.bitmode operated properly and returned

some value -- either 32 or 64. "32" means the JVM is operating in 31-bit mode; "64" meansthe JVM is operating in 64 bit mode. The value is parsed and placed in an integer variablebitMode.

c. If an exception is thrown on the System.getProperty, then the integer variable bitMode

is simply set to 32.

This code sample is making an assumption that if an exception is thrown the JVM istherefore in 31-bit mode. In a WebSphere JVM that catch block should never be hitsince the IBM JVM inside WebSphere will always have set com.ibm.vm.bitmode.

Note:

Once the variable bitMode has been set, other code can now interrogate the variable and

determine which flavor of the DLL should be loaded -- in pseudo-code: "If bitMode=32 then load

31bit.dll; else if bitMode=64 then load 64bit.dll."

2. Native code called from a 64-bit server will need to be recompiled to support 64-bitoperations and be in a separate DLL from 31-bit code.

� 64-bit and 31-bit code cannot exist in the same DLL.

� Your native code DLL may reside in a z/OS data set. But the Java code can't directlyreference a z/OS data set. Therefore, a symbolic link for the DLL is needed in the UnixSystems Services file system. If you have a 31-bit version and a 64-bit version of the samecode residing in z/OS data sets, that implies two USS symbolic links -- one pointing to the31-bit copy, the other pointing to the 64-bit copy.

This is where the com.ibm.vm.bitmode property check mentioned in item #1 from

this list comes in handy. Pseudo-code: "If bitMode=32 then load 31bit.dll; else

if bitMode=64 then load 64bit.dll."

Note:

3. Code changes may be necessary to support 64-bit data types at the interface boundarybetween Java and your native code.

64-bit addressing mode supports addresses that are 8 bytes (64 bits) in length, which allowsaccess to data in virtual storage up to 16 exabytes. In 31-bit mode addresses are 4 bytes inlength. If you are passing pointers between Java and native code, both Java and the native codewill need to know if it is dealing with single (4 byte) or double (8 byte) length addresses.




Other sources of 64-bit programming reference information

We really don't want to turn this document into a re-hash of what's already published out there.Rather, we'll point you off to so some good references for this kind of information.

� "z/OS 64-bit C/C++ and Java Programming Environment"

http://www.redbooks.ibm.com/redpapers/pdfs/redp9110.pdf

� "z/OS Language Environment Programming Guide for 64-bit Virtual Addressing Mode"

http://publibz.boulder.ibm.com/epubs/pdf/ceeam110.pdf

� "IBM 31-bit and 64-bit SDKs for z/OS, Java 2 Technology Edition, Version 5SDK andRuntime Environment User Guide"

http://www.ibm.com/servers/eserver/zseries/software/java/pdf/sdkguide.zos.pdf

� "Java on z/OS Reference Information"

http://www.ibm.com/servers/eserver/zseries/software/java/javaintr.html

� "Java™ 2 on z/OS"

http://www.ibm.com/servers/eserver/zseries/software/java/

Concluding points

We really had five key points to make in this section:

1. Pure Java code will more than likely run the same in a 64-bit more server as it did in a 31-bitserver. You should do some cursory testing in any event, just to be sure.

2. The thing to be aware of is non-Java code, specifically code that makes use of JNI to call nativecode (for instance, C++). If the JVM is running in 64-bit mode then any native code called throughJNI must also be in 64-bit mode.

3. There are implications to coding native code in 64-bit mode, particularly around interfaceboundaries.

4. If you have Java code that uses JNI you should make sure it's flexible enough to call theappropriate native code, whether the Java code is running in a 31-bit server or a 64-bit JVM. Asupplied system property called com.ibm.vm.bitmode will hold the bitmode of the JVM. You

can query that property and call the native code appropriate for the mode, based on the returnfrom System.getProperty("com.ibm.vm.bitmode").

5. At the heart of the data connector issue is this issue of Java code calling native code. In order forthose data connectors to support WebSphere for z/OS 64-bit server operations, those connectorsneeded to supply updated native code components -- ones compiled for 64-bit and with theappropriate 31-bit/64-bit addressing boundary issues taken into account. Hence all the referencesearlier to PTFs.

See "IBM data connector issues" starting on page 33 for a more on this connector topic.




Document Change History

Check the date in the footer of the document for the version of the document.

Added a short note on clusters -- every member of a cluster should operate at the samebit mode.

February 1, 2012

Corrected the ++APAR numbers for z/OS 1.6 and 1.7. Earlier versions of the documenthad "AA" and "BA" rather than "OA." Correct numbers are: OA17679 and OA17846 (forz/OS 1.6) and OA14623 for z/OS 1.7 and the CTRACE writer.

July 9, 2007

Updated information on display message issued to indicate what mode, 31 or 64, theaddress space is running in. Previous information suggested two messages, but in factthere are four -- BBOO0307I through BBOO0310I. One for each major type of region:

Daemon region, Controller, Servant and Adjunct.

Also provided information on MVS display command that will report the mode. Thissaves you the trouble of digging through held output.

April 11, 2007

Updated the data connector section with the latest information on PTF or CSDavailability, as well as removed planned dates for WebSphere for z/OS 6.1.0.5 and6.1.0.6 as both are now currently available.

February 12, 2007

Removed references to 64-bit support for DB2 V7 when using the Type 2 driver. Theoriginal document included a reference to APAR PK25139 applying to both DB2 V7 andV8, but that was incorrect. It was an error in the APAR documentation itself that wasincluded in this document. It now shows APAR PK25139 as applicable to V8 only.There is no plan to make the V7 Type 2 driver compatible with 64-bit mode.

January 19, 2007

Original document.December 15, 2006

Document Change History

End of Document WP100920


Section: Document Change HistoryVersion Date: Wednesday, February 01, 2012


Word Pro - WP100920 - 64 Bit Addressing Support.lwp - IBM

Documents