PRS3357 - Introducing the WCT for zOS - IBM · PRS3357 - Introducing the WCT for WebSphere z/OS...

PRS3357 - Introducing the WCT for WebSphere z/OS Version 7

1 Version:September 29, 2008

© 2008 IBM Corporation

WebSphere Application Server for z/OS V7.0

Introducing the WCT for z/OS

The WebSphere z/OS Support Team

IBM Washington Systems Center

WebSphere Customization Tools, including the zPMT and the zMMT

PRS3357 at ibm.com/support/techdocs



© 2008 IBM Corporation2 IBM Americas Advanced Technical SupportWashington Systems Center, Gaithersburg, MD

Table of Contents

• Introduction and Overview

We explain the key concepts of “locations” and “definitions” and “perspectives” and “views”

• Exploring the PMT

Here we delve into the specifics of the Profile Management Tool and how it can be used to create V6.1 or V7.0 runtime environments

• Exploring the MMT

We finish up with the specifics of the Migration Management Tooland how it can be used to migrate V5.1, V6.0 or V6.1 runtime environments up to V7.0

We start with a few slides that set the stage … explaining what the WCT is, how it compares to the previous ISPF dialogs and zPMT tools, and where the WCT can be acquired. Then …

The contents of this presentation.




Basic Introduction to the WCT for z/OS

The WCT for z/OS is a workstation graphical tool that is used to generate the customized jobs used to create, migrate or augment a WAS z/OS configuration

Customized JCL batch jobs

You enter configuration specifics into the tool

Objective - creation of customized jobs for the purpose of creating or modifying a configuration

The WCT for z/OS -- WCT stands for “WebSphere Customization Tools” -- is a workstation based

graphical tool used for the creation of the customized jobs that build and migrate a WebSphere

Application Server for z/OS environment.

The concept is fairly simple: you enter information into the tool and it generates the customized JCL

jobs. Those are then uploaded to the z/OS platform where they’re run to create the WebSphere

z/OS runtime.

The concept is not new. The tool is. It’s new for V7.




Types of Things You Can Do With the WCT

Here’s a peek at the things the WCT will allow you to create. We’ll explore these more later in the presentation.

PMT

MMT

Things you may already be familiar with

There is new V7.0 function under the “Management” option

This tool is capable of generating jobs to create V6.1 cells

New V7.0 functionality

Migration from V5.1, 6.0

or 6.1 up to V7.0

Note: WCT is extensible framework … more function may be added later

Here are the types of things you can do with the WCT. It comes with two basic functions:

• PMT - Profile Management Tool … used to create runtime components. The picture shows the

things you can create. Some of those are what we’re already familiar with from previous

versions of WebSphere z/OS; others are new to WebSphere z/OS V7. We’ll explore the new

things in a bit.

• MMT - Migration Management Tool … used to create jobs to migrate an environment from an

earlier version or release.

It’s important to understand that the WCT is designed to be extensible … which means that in the

future other functionality may be added to the program to allow it to do other things as well.




Evolution of This Function

Before the WCT there was the AST, and before that the ISPF panels:

ISPF Panels

• Began in WebSphere z/OS V4 and continued into V5 and V6

• Was effective, but somewhat difficult to use with a tool like the planning spreadsheet

• Deprecated in V6.1 and withdrawn in V7.0 of WebSphere Application Server for z/OS

Function inside the Application Server Toolkit (AST)

• AST served as an Eclipse runtime to host the z/OS customization and migration functions

• First used for WebSphere z/OS V6.1 configurations

• Integrated nicely with the planning spreadsheet, which produced a response file used as input

• AST has considerable function beyond what was needed to customize WebSphere z/OS … which made AST at 800MB+ a very heavy download for some

Both did the same basic thing: creation of customized jobs for the purpose of creating or modifying a configuration. Now the WCT fills that role.

If you’re thinking, “Well, this is something like what we had before.” You’d be right. The WCT did

not spring up in a vacuum. It is a product of an evolution of function over time.

In the beginning, going all the way back to Version 4, we had the ISPF customization dialogs. They

did the same thing in concept as the WCT -- that is, creating customized jobs from specific input --

but it did it in a 3270, green-screen manner. Effective, but it had its limitations.

What came next was function provided as part of the Application Server Toolkit, or AST for short. It

was referred to as the “zPMT” … the “z Profile Management Tool.” The zPMT and the WCT share a

common bond in the fact that both are based on Eclipse, which is an application and tooling

framework. That’s what makes tools that use Eclipse appear to be so similar in look and feel.

The issue with the AST-zPMT was that to get just the zPMT required the entire AST, and that had

quite a bit of function beyond what the zPMT was designed to do. The AST has many wonderful

things, but to most who used the zPMT it was never used.

The WCT now takes over, relieving the AST of having to carry the z/OS customization tool. This is

good … it allows the AST return to what it does best, and it allows the WCT to be a much smaller

package.




Acquiring the WCT

You have two options for securing a copy of the WCT:

From the product installation DVD/CDs. The WCT is located on the kit number indicated here:

From IBM web page: ibm.com/support/docview.wss?rs=180&uid=swg24020368

Download using “Download Directory” or FTP

The WCT is available from two sources, as indicated in the chart.




Supported Platform Operating Systems

At the time of publication of this document, the supported platforms were:

Windows

•Windows XP Professional

•Windows Vista Business

•Windows Server 2003

Linux

•Red Hat Enterprise Linux 4.6

•Red Hat Enterprise Linux 5.1 and higher

Please check back -- this list may grow to include other operating system platforms

The WCT is commonly thought to be “Windows only” but that’s not really the case. It does run on

Windows, but it’s also applicable to Linux. The list above is what was supported at the time this

presentation was built. The list may grow. Check back.




Introduction and OverviewWith an emphasis on where the tool keeps the stuff it creates




Eclipse as Framework for Functional Plugins

The WCT is really an Eclipse-based framework. It’s a container for specific functional features. The two features we’ll look at: PMT and MMT.

Eclipse Framework(WCT has a subset, which is why the install image is only

about 160MB in size)

WCT = “WebSphere Customization Tools”

PMTProfile

Management Tool

MMTMigration

Management Tool

Additional features

added as they become available

PMT -- used to generate the customized jobs that create the configuration for a node

MMT -- used to generate the customized jobs that migrate a configuration for a node

They’re each handled as Eclipse “perspectives” if you’re familiar with that term

As mentioned, the WCT is based on Eclipse, which is an open standard framework for applications

and tooling. Eclipse is used because it is designed, by its very nature, to an extensible framework.

What that means is that later, if new function is delivered, it can easily be added to your existing

WCT and work along side the other function that’s already there.

The WCT is being delivered initially with two functions, the PMT and the MMT as we explored a

moment ago. Additional features may be added later as IBM sees the need.

Each function is presented in Eclipse as a “perspective,” which is a term used to mean the display on

the computer screen of the various features related to the function. So the PMT is one “perspective,”

and the MMT is a different “perspective.” If you want to use one tool you switch to that perspective

and the Eclipse framework will bring to the foreground the features that make up that perspective.




Installation is Typical for Windows

Very simple and straight-forward:

Initial Splash License System Pre-Req Test

Installation LocationProgress Bar Success

Installation is very easy … the least complex element of this

Installation image found on “WebSphere Customization Tools” CD that comes with product

Let’s establish something before we get too far down the path. The installation of the WCT is really

easy … it’s like the installation of any other workstation tool. For Windows (for example), it’s a

matter of clicking on install.exe and then going through a small number of panels and the program is

installed. It’s truly that easy … the least complex element of the whole thing.




The Welcome Page

When you launch the tool you should see the following “Welcome” panel

This little tip is a handy way to navigate to get to a known place in the WCT(You can also launch the PMT or MMT using this approach)

From here you can launch either tool

If for some reason you don’t see this panel, you can easily get to it:

Window �� Open Perspective �� Other

That will bring up the panel you see pictured here

Click “OK”

Select “Welcome”

The Welcome panel is one of three “perspectives” that comes with the tool initially. The other two

are the PMT and the MMT. The Welcome perspective should become active when you first start the

tool, and from there you can launch the PMT or MMT.

But just in case you don’t see the Welcome panel, or you simply wish to return to a “known state,”

you can use the tip shown on this chart. In any Eclipse-based tool you can use this technique to go

to any perspective defined to the tool.




WCT Repository -- Locations and Definitions

The WCT maintains a file location where it keeps information about a customization. Let’s explore “Locations” and “Definitions” …

A “Location” is where the customization files are kept. It may be a shared network

drive if you wish.

“Definitions” are specific to the customization task --create a DMGR, federate a node, etc.

“Definitions” are kept inside a “Location.”

Multiple definitions per location is permitted and expected.

The WCT takes input from you as part of its role in creating the customized jobs. Naturally it’s going

to store that input, and other information, somewhere. That somewhere is a “location,” and as the

name implies it’s simply a place on a physical storage device -- a local hard drive, a network drive, a

file system, a network file system, etc. Any physical storage device recognized by the WCT as being

available through the host operating system can be used as a place where the “location” will reside.

You may defined multiple locations. You might do this as a means of maintaining a logical and

physical separation of work you’ve done with the WCT. We’ll see that unfold as we go through this

presentation.

Within a location the various “definitions” are maintained. A “definition” is what the WCT uses to hold

all the pieces of information related to a specific customization you’ve done. So the work you’ve

done to create a Deployment Manager is kept in a definition. If you then defined a Standalone

server customization it would be a separate definition. The definitions are stored within a location.




Think of Locations as Logical Groupings of Related Definitions

You could create one location and put every single definition in there. But it might get a bit confusing as the list of definitions gets longer and longer.

As an alternative, consider the following example:

C:\WCT\

\DEV_A_Cell

\DEV_B_Cell

\Test_Cell

\QA_Cell

\Prod_Cell

DMGR

Node

Federate

Standalone

DMGR

Node

Federate

Node

Federate

Cell

Cell

Cell

Backup could be at highest folder or at

lower folders

Group all the definitions for a cell within a

location; organize locations

under a single root folder.

This is just a suggestion … it helps see relationship of definitions to locations

These folders would be the

Locations

Could make location

folders the cell short or long name if you wished

Also makes location locking more granular, as we’ll see in a bit

This is what we mentioned before -- you can think of locations as a way to logically group related

definitions into a single spot. For example, image you had five cells planned -- two development

cells, a test cell, a QA cell, and a big production cell.

You could create on location and put all the definitions related to all those cells in one spot. It might

get somewhat confusing, though.

Better, we believe, to logically group the cells into separate locations. For instance, imaging you

defined your locations as showin the chart. The first development cell might be only a single

standalone server and thus it might have only one definition inside of it. But the production cell at the

bottom might have five definitions inside of it. If you were focused on working on the production cell,

and you didn’t want to be distracted by other things, all you’d have to do is tell the WCT to go to the

production cell location. The WCT would then show only those defiitions.

The usefulness of this is also evident from a backup and restore point of view. If you wanted, you could backup at the C:\WCT level … or backup each individual folder.

Nothing on the chart above should be taken as requirements … they’re all just suggestions;

illustrations of how this might be accomplished.




Creating a Location in the WCT

Relatively simple process of indicating the source (existing vs. new) and providing information about drive and folder location:

“Add”

1

2

3

4

Existing -- similar to an “import” function … bring in a location created by someone else.

New -- as it suggests, the initialization of a brand new location

The PMT supports creating V6.1 or V7.0 nodes

The MMT supports V7.0 migrations only

Select feature --PMT or MMT

The creation of a location is done within the WCT tool by clicking on the “Add” button next to the list

of locations. The location may be new (which means the WCT will create the folders or directories)

or an existing WCT location that you’re simply making this copy of the WCT aware of.

Let’s pause and go over that again, but there’s an important distinction there:

• A location is a physical location on a storage device

• That location must be recognized by the copy of the WCT you’re working in

This is easiest to understand when you think about network drives. Someone else might create the

location on the network drive using their copy of the WCT. They tell you about it. You then “add” the

location by telling your copy of the WCT about it. (And yes, network drive locations can be “shared”

… there is a locking mechanism.) Adding an existing location does not create the folders and files, it

merely updates a list within your WCT of the known locations. Adding a location that doesn’t already

exist will create files and folders.

Note: The PMT has separate locations from the MMT. Same concept, you can’t have the same

drive and path as both a PMT location and a MMT location.

Let’s look at the numbered blocks from the picture:

1. Two radio buttons exist -- “Add an existing” or “Create a new customization location”. We just

finished discussing this.

2. The name of the location is just what will show on your copy of the WCT. It’s a way to provide

a meaningful label so when you see the list of locations you can easily understand what’s in it

3. The version pulldown will show either just V7 if it’s the MMT, or V6.1 / V7.0 if the PMT. That

means the PMT is capable of producing customized jobs to create V6.1 runtimes.

4. Finally, the physical location … here’s where you’d specify drive and path (Windows) or path

(Linux)




Locations are Specific to the WCT Feature

The previous chart implied this -- locations are created and initialized by the WCT feature (PMT or MMT) selected at that time.

MMT chosen here

Locations for MMT displayed

Only migration definitions can exist in those locations

PMT chosen here

Locations for PMT displayed

Definitions for PMT only … can’t mix MMT and PMT definitions in the same location

We mentioned this on the previous panel, but this chart helps understand it a bit better.

Locations are specific to the function within the WCT. MMT locations are separate from PMT

locations. In fact, the locations that show in the list will depend on which “perspective” you select.

This makes sense … PMT definitions are something quite different from MMT definitions. If they

were all mixed together things would get confusing. There’s also some “initialization” of a location

that takes place and that initialization is specific to the function. So the location for the PMT has

certain files and settings that are different from what the MMT would use. So again, they’re kept

separate.




Locations Maintained on a Shared Network Drive

The tool now has a locking mechanism that prevents two users from accessing the same location:

E:\WCT\

\DEV_A_Cell

\DEV_B_Cell

\Test_Cell

\QA_Cell

\Prod_Cell

User A User B

Location E:\WCT\Test_Cell unlocked when User A closes WCT or selects another

location. But during use it is locked and others can’t access.

User B is free to work with other locations while User A has the one locked. That’s another reason to consider more granular locations like we suggested.

This is something new with the V7 WCT for z/OS … the ability for the tool to “share” locations on a

network drive.

Now we have to be somewhat careful here because by “share” we do not mean concurrently. What

we mean is that a location with definitions can be defined on a network drive that is accessible to

multiple people. What’s new in the V7 WCT is the ability to lock the location so nobody else can use

it while you’re using it. The previous zPMT (in the AST) didn’t have a very good locking mechanism

so we were reluctant to encourage shared network drive locations. It was quite possible to do it, but

back then we urged caution.

Now, however, putting the locations on a shared network drive solves one the issues most often

mentioned by people -- that is, the ability to access definitions when they’re on someone’s personal

computer hard drive. It means zipping and e-mailing and that was inconvenient. Now the locations

can be put out on a shared drive, and there’s a locking mechanism to prevent corruption while one

person is in working on something.




Creating a Definition in the WCT

Also a simple process … it’s something created “under” the location you highlight when you create the definition:

First, select the location under which the

definition will reside

“Create”1

2

3

4

The key here is really block #3 -- those are the different types of definition environments that can be created with the PMT (the MMT has different environments)

Block #4 is just a name … it ends up being a folder under the location.

Once a definition is created and selected, then the WCT will display the definitions that are held

within that location. The WCT may have many locations defined to it, but only one is selected at a

time. A location may have multiple definitions within it, but only one can be worked on at a time.

Creating a definition is easy … you click on the “Create” button (for the PMT; the MMT’s button is

labeled “Migrate”) and the tool brings up what kinds of definitions can be created. For instance here

we see the PMT options we saw in larger format earlier.

Let’s walk through the numbered blocks:

1. A location is selected.

2. The “Create” button is clicked

3. The tool brings up the type of definitions you can create … called “environments”

4. The tool then asks for a definition name. This can be any name you want to give it … it will be

what displays on the WCT’s screen when you’re in that perspective. That panel also has a field

for a “response file,” which is a flat file with variable name/value pairs. This is important

because it provides a place to bring into the WCT the variables needed to fully populate a

definition. Where might that response file come from? Well, from someone else perhaps (they

e-mail you a response file from their WCT) or from the “Planning Spreadsheet” we’ll see in a bit

that creates a response file for the WCT.




Demystifying the “Location / Definition” Thing

It’s nothing but a set of folders on a hard drive -- local or network -- where the tool maintains its information:

Three definitions under C:\WCT\Test_CellWe’re illustrating a typical ND cell -- DMGR, then a Standalone, and finally the federation

Five locations under C:\WCTSimilar to what we showed earlier.

C:\

Contents of C:\WCT\Test_Cell\T1DMGR

Instruction HTML file

Response File

There’s a lot more file in the location as a whole, but any one definition consists of just those two files

It’s tempting to think of this “location” and “definition” thing as somewhat mysterious. It shouldn’t be

mysterious. Here’s an example of what the WCT created when a handful of locations were created under a common C:\WCT root, and within one location we had a few definitions:

• As you can see, the locations are physically represented as subfolders. By the way, the

“location name” you gave it is not necessarily the folder name. It can be, but it does not have to

be. The location name is simply something displayed in the tool; the actual location path is what

is represented down in the file system.

• Note: incidentally, if you “remove” a location in the WCT tool it does not delete the file system

directories and files. It simply removes knowledge of that physical location from the copy of the

WCT.

• If we drill under the “Test_Cell” folder (one location) we see some subfolders called “lib” and

“log” and then one called “profiles.” It’s under “profiles” that the definitions are found.

• The definition name you provided when you created the definition does become the folder name.

We can see in this example that four custom definitions exist and the “default” one that’s always

there. In this example we see that the definition names were given something like “z/OS short

names,” though the actual definition name you give can be more descriptive than that.

• The contents of the definition folders is very simple -- an instruction file in HTML format, and a

response file, which is that flat name/value pair file we mentioned earlier. We don’t see the

generated jobs or the files that get upload to z/OS. Those are generated on the fly and uploaded

to z/OS.

There are many other files in the location -- template files, Java JAR files, etc. But this shows that

the contents of a definition is pretty straight forward.




Locations are Portable -- You can ZIP and Send to Others

If you want to carry a location and its definitions to another computer, you can easily do that. New with V7 WCT -- it can be unzipped anywhere:

C:\Fred\stuff\WCT

The location really “starts” here -- at the folder above “lib,” “logs” and “profiles”

ZIP File

E:\WebSphere\WCT\locations

Or just

copy it

Key point is that the locations and the definitions inside are no longer tied to

the absolute path

Other instances of WCT simply “Add an existing

customization location” and point to this

Locations are portable things … they can be zipped up and sent to someone else if you wish.

Note: definitions are portable on to the extent the response file can be sent to someone. They can

easily reproduce the definition in their WCT by creating their own definition and then using the

response file from you as input.

The older zPMT -- the one based on the AST -- had a limitation in that the location and the files in

the location had the full drive and path embedded in various files. That made the location portable

only as long as where it was “installed” was the exact same drive and path.

But the new WCT is different. It does not have those hard-coded drive/path values embedded in the

location itself. So the location can be zipped up and sent to someone else, and they can unzip it

anywhere they like and it’ll be usable.

Now, here’s where “adding an existing location” comes into play. Just because you unzip a location

into your network E: drive does not mean anyone’s copy of WCT knows anything about it. But their

copies of WCT can be made aware by adding an existing location. The WCT does not try to initialize

the location, it simply “registers it” (for lack of a better term) into that copy of the WCT and it’s then

available.




Eclipse “Perspectives” and “Views”

“Perspectives” and “Views” are a way Eclipse-based tools bring to the screen a specific user interface:

Other views represented

in tabs

Perspective:• Think of it as what’s showing on the

screen

• Is really a collection of “views”

• You can close perspectives to clear the screen, and then open other perspectives

View:• A portion of the screen devoted to the

display of specific information

• Multiple views may be active at once

• Views may be tiled or tabbed, or may not be displayed at all

With the WCT you don’t need to be quite as aware of “perspectives” and “views” as you do with other tooling, but they are used by the WCT because it’s based on Eclipse

We’ve already introduced the notion of a “perspective” -- it is a way for Eclipse to show the related

features of a function in a united way on the screen. Within a perspective we have “views” -- those

are like “windows” or “panes” within the perspective. We’ve already seen views -- the list of

locations is one view; the definitions within the selected location is another view. There are tabs that

we’ll see in a bit that represent still more views.

If you’re new to Eclipse this may seem intimidating, but please don’t let it be. We’re lucky … the

WCT is relatively user friendly. Other tools employ far fancier use of views and perspectives and it

can get quite perplexing. But the WCT is nicely designed and relatively easy to navigate.




Help! The Layout of My WCT is All Messed Up!

Eclipse allows you to drag-and-drop and resize the views … and it’s easy to get to a state where you don’t recognize it any more.

The “Reset Perspective” function will return it to something more familiar:

Window �� Reset Perspective

You don’t lose data … it simply

returns the layout of the views to the default settings

Eclipse is wonderfully customizable. So much so it’s possible to get things to a point you can’t find

things any more. The WCT is less prone to that some of the more powerful application development

tools based on Eclipse, but it’s still possible to find yourself not recognizing the layout of the tool.

You can reset to the “factory defaults” so to speak. The chart shows how that is done.




Exploring the PMT and the MMT

Let’s now turn our attention to the two features that are included with the WCT from the start -- the PMT and the MMT:

Used to customize the jobs that construct the runtime environment

Used to customize the jobs that migrate a

runtime environment

Features to augment a runtime for additional

functionality

They have specific roles, but each results in the same basic thing -- a

set of customized jobs that are

then uploaded to z/OS to affect the runtime environment

“Perspective” “Perspective”

“Perspective”

Now we’ll drive into the specifics of the two main functions -- the PMT and the MMT.




Exploring the PMTProfile Management Tool




The zPMT in Context to the WCT

Here’s our picture from earlier, with the PMT highlighted:




PMTProfile

Management Tool

MMTMigration

Management Tool

Additional features


We’ll use this picture to position the PMT against the MMT, all within the context of the WCT which

relies on Eclipse.




PMT is One of the Basic Features of the WCT

Out of the box the WCT includes the PMT and the MMT. More can be added because WCT is extensible, but those two come with the WCT from the start

PMT is a “Perspective” in the WCT toolWhen the perspective is open, it appears as a tab

LocationsSpecific to the PMT. MMT and other features would maintain their own

list of locations.

DefinitionsUnder the selected location.

Action ButtonsThese are used to initiate

actions within the PMT tool

• Create a definition

• Regenerate (modify) a definition

• Delete a definition

• Process (upload to z/OS or export to file system) a definition

As we’ve seem, the Profile Management Tool (the PMT) is one of the two out-of-the-box basic

functions of the WCT. (The Migration Management Tool, MMT, is the other.)

The PMT is a perspective within Eclipse, as is the MMT. They appear as tabs at the top of the

display, and by selecting the tabs you can “switch perspectives” -- go between the PMT and the

MMT.

When you select one or the other, the locations specific to that function are displayed. As we noted

earlier, the PMT and the MMT can not share the same location. Those locations may be kept under a common root, such as C:\WCT or whatever, but a given folder cannot be a PMT location and an

MMT location at the same time.

When a location is selected, the definitions within that location are displayed. Off to the right we see

the action buttons that are supplied with the PMT. There are four -- create, regenerate, delete and

process. We’ll go through and see each one.




V6.1 PMT Environments

Here’s what it will allow you to do when V6.1 is the selected version:

Feature Pack EJB 3.0

Feature Pack Web Services

Familiar “Build a Cell” Tasks

These two Feature Packs are rolled

into V7

As we mentioned earlier, the PMT has two choices for a location’s version value -- V6.1 and V7.0. A

location has to be one or the other but not both. If you selected V6.1, then the “environments” you

can create with the WCT mirror what is possible with the AST/zPMT -- that is, the standard

WebSphere z/OS components, as well as the EJB 3.0 and Web Services feature pack augmentation

features.

What this allows you to do is have one tool for V6.1 and V7.0.

If you want to bring a configuration from the AST/zPMT into WCT, use the response file. Copy the

response file out of the AST/zPMT and then import it into a definition in the WCT. It’ll recreate the

definition in WCT format, with the exact same values you had in the AST/zPMT.




V7 PMT Environments

Here’s what the PMT will help you create when V7 is specified

A Deployment Manager and a federated node in one set of jobs

“Management” has three sub-selections:

• Administrative Agent -- new in V7, it is part of the “Flexible Management” functionality

• Deployment Manager

• Job Manager -- new in V7, also part of “Flexible Management”

A standalone server

An empty federated node

Job to federate a standalone into a DMGR

Admistrative server

for the secure proxy

Secure proxy

server

Some of that is new in Version 7, and some of it is what we learned to do going all the way back to Version 5.0 of the product.

Back then we used the ISPF panels … then the AST/zPMT … now the WCT/PMT

If the location is specified as a V7, then the environments you see here are available to you. The

topic portion is what we had in the AST/zPMT, and some go back into the ISPF dialogs. But there’s

also things new to V7: the Administratve Agent and Job Manager (under “Management”) and the

“Secure Proxy” elements. Let’s see what those are all about next.




New in V7 - The Administrative Agent

Think of the Administrative Agent as an Admin Console that can be switched to manage many different Standalone Server environments:

CR SR

Standalone

CR SR

Standalone

CR SR

Standalone

Daemon CR SR

Cell and Node

Administrative Agent

Admin Console

“Farm” of Standalone

Servers

Test or Development

• Administration is done by direct update of each Standalone’s configuration file system

• Admin Agent may be on same z/OS system or in the same Sysplex if file systems are shared

• Standalone servers are “registered” to the Admin Agent. The Admin Console function of the standalone is then disabled.

• Note that the Admin Agent is itself a kind of Standalone Server

Daemon

Daemon

Daemon

The V7 Administrative Agent is part of the new “Flexible Management” function, which includes this

as well as the Job Manager and the Secure Proxy, all of which we’ll touch on here and the next few

pages.

The Administrative Agent is meant to address the issue some have where many standalone servers

are used for test and development purposes, and having to access each’s Administrative Console

through a different host/port was cumbersome. What the Administrative Agent provides is a single

Administrative Console that can be used to administer multiple standalone servers. Think of it like

one of those computer terminals with the switches that allow the terminal to be switched from

computer to computer.

But convenience is not the whole story here. When you have a farm of standalone servers, each

has the Administrative function loaded up in its JVM, and that takes up cycles and heap. By having

the Administrative Agent act as the administration point, you offload that from each standalone and

the burden falls on a single server instance.

The way the Administrative Agent works is it directly manipulates the configuration XML of each

standalone server registered to it. That’s why the requirement is for the Administrative Agent and

the standalones registered to it to be on the same z/OS system -- so it can have write access to the

configuration file systems of each standalone server. There’s also a degree of communication that

takes place between the Administrative Agent and the standalone so the Administrative Agent can

“see” if applications are running, and if the standalone is in fact up and running.




New in V7 - The Job Manager

The idea is to have a central place to administer the asynchronous submission of WSADMIN “jobs” to multiple locations in your WebSphere environment:

Daemon CR SR

Cell and Node

Job Manager

Admin Console

Managed Standalones

Daemon CR SR

Cell and Node

Administrative Agent

Daemon CR SR

Deployment Manager

Managed Nodes in Cell

Over Network

• Administrative Agents or DMGRs are “registered” to the Job Manager so it knows about them

• Administrative jobs are maintained in repository local to the Job Manager

• You may then “submit the jobs” asynchronously to the targets and:

• Set the job submission to take effect at a specified time.

• Set the job submission to expire at a specified time. • Have the job submission occur at a specified time

interval. • Notify the administrator through e-mail that the job has

completed.

Again, note that the Job Manager is its own cell/node/server structure.

Naming and port planning applies here as well.

The Job Manager is another single management interface intended to support a large and widely

arrayed WebSphere environment. In this case rather than acting as the Administrative Console for

the remote systems, what the Job Manager does is provide the ability to schedule and submit

various tasks to other WebSphere servers -- either an Administrative Agent (managing a farm of

standalones) or a DMGR with its federated nodes.

From the Job Manager you can do things like start and stop servers and submit WSADMIN scripts to

deploy applications. This can be done on a scheduled basis. So we see not only remote

administration, but also a degree of automated and time-managed administration.




New in V7 - The Secure Proxy and Its Administrative Agent

This is designed to be a more “DMZ Friendly” WebSphere Proxy device:

• JRE, not full JDK … can’t compile code in DMZ

• No web container

• Not administered from Admin Console … use separate Admin Agent in DMZ (or local WSADMIN)

• Switches to unpriviledged user after binding to low-order ports

• Static routing (based on XML) or dynamic (requires DCS port kept open)

Daemon CR

Cell and Node

Secure Proxy Server

CR SR

AppServer

CR

Node Agent

CR

Daemon

CR SR

DMGR

CR SR

AppServer

Node

Secure Proxy

ManagerEssentially an “Admin Agent” but specifically for the Secure Proxy

Earlier versions of WebSphere z/OS had proxy servers, but what differentiates this new function is

the ability to be more “DMZ friendly” … by that we mean several things:

• The proxy itself is a Java Runtime Environment (JRE) but not the JDK, so nobody can use it to

compile code in the DMZ. It runs the IBM proxy code, but that’s all it can do.

• There is no web container so no servlets or other harmful code can be run on the platform.

• It has the capability of requiring only the barest minimum ports on the back firewall. This is

because the proxy has two modes -- static (its routing based on XML, much like the Plugin), or

more dynamic … but going dynamic requires that the DCS port be opened.

• Administration of this is not done from the cell’s Administrative Console. It’s done from a special

server called the Secure Proxy Manager, which is essentially like an Administrative Agent except

limited to managing only the Secure Proxy.

What this represents is a further refinement of the Plugin/Proxy evolution that’s been taking place for

several years now.




A Flowchart View of Creating an Environment

There are considerable similarities between the different environments. So let’s take a high-level look at the general flow of the PMT

Definition Name and Response File

Default Values

Target Data Set HLQ

Configuration Group

Configuration Common IDs

System Info and Proclib

Cell, Node and Server

Configuration File System

Product File System

Optional Applications

JCL Procs and Userids

Host and Ports

Daemon Information

SSL Information

Administrative Security

JOB Card

There are slight differences in some of the environments,

but this is the essential flow that is

common

The “Response

File” is important because it ties in with the planning

spreadsheet

Now let’s see what the flow of panels looks like for creating a definition … again, a “definition” being

the customized input that creates one of the supported environments -- a DMGR, or a Standalone, or

a federation, or one of the new flexible management environments.

The flow is as shown in the chart … and much of it is very much like what we’ve seen before with the

ISPF dialogs and the AST/zPMT. It’s a process of working through and supplying all the information

that’s needed to create the environment that has been selected.

As anyone who has done this before knows, the issue is not typing into the panels … the issue is

coming up with all the names and maintaining an effective, consistent naming convention

throughout. That can be done by hand. Or it can be done with a tool that will generate those values

in a response file format that can be brought into the PMT to populate the fields automatically.

One such tool is an Excel spreadsheet … and one is available for your use.




The PMT and the Planning Spreadsheet

The spreadsheet provides a way to easily create input variables the PMT uses to populate the fields.

Provide key variables in the “Variables” sheet

Copy the generated variables from the appropriate

worksheet and paste into Notepad to create a file Then point to the file in the

“Response File” field of the window where you gave the

definition a name

Then just tab through the PMT windows and generate the jobs

See PRS3341 on ibm.com/support/techdocs for V7 spreadsheet

The spreadsheet tool is simply a device used to create a response file in the format used by the

PMT. The key to the spreadsheet is a couple of things:

• It is designed to take just a few key variables from you and from those generate all the other

values

• By doing so, it enforces a consistent naming convention throughout

• Finally, it creates the names for a complete cell … a DMGR, nodes, federation … all with a

consistency of namings and values throughout.

This consistency for a whole cell is known as a “top down” design, and by that we mean one where

all the elements of the cell are considered as a big picture first, then working down the individual

details for each element. That could be done by hand. The spreadsheet simply makes it easier.

For V7 a new set of spreadsheets have been created. One set is for the traditional environments

(DMGR, nodes, federation, etc.), and another for the new Flexible Management things

(Administrative Agent, Job Manager, Secure Proxy, etc.). These can be found on ibm.com/support/techdocs under the number PRS3341.

The key here is really the way the spreadsheet produces a table of variable/value pairs and that can

be copied/pasted into a file that is then brought into the PMT to create the environment.




Converting ISPF “SAVECFG” into PMT Response File

You may have some configurations saved from the ISPF panel days that you’d like to use. The tool allows you to download and convert those:

The function is found under:

File �� Download ISPF Variables …

Fields:

• Source z/OS -- the host name

• Source dataset name -- this must be a **.SAVECFG sequential data set

• User ID and Password

• Port and timeout

• Target -- where you want the PMT-format response file placed on your workstation

• Type -- what environment type you want the created response file to be. Easiest is to set it equal to the SAVECFG type on the host. But it is possible to have the tool convert it to a different environment type.

Purpose is to allow you to re-use existing definition assets

Some of you will have SAVECFG data sets from the old ISPF days, and they may still be of value to

you. The PMT gives you a facility to download those and convert them to PMT-style response files.

The process is pretty straight forward as you can see from the chart.

A few points:

• What this is designed to work with is the **.SAVECFG sequential data sets from the ISPF

customization dialogs of WAS V5.x and V6.x. If you have some definitions on the z/OS system created by the AST/zPMT tool, you can simply download the ZPMT* member from the DATA

target data set.

• The tool is capable of converting one environment type to another -- for example, a DMGR SAVECFG can be converted to a standalone. But be aware that doing that might mean you have

to update or supply some fields in the PMT once you have the response file on your workstation.

When doing this SAVECFG-to-response-file process you should always review with some care

the values you see in the PMT. It’s just a safe precaution to insure you get the configuration you

really want.

• You can put the response file anywhere on your workstation that you want. And the file

extension may be anything you like.




Panels Throughout the PMT Customization

Should be things you’re already familiar with from either ISPF or AST/zPMT …the concepts are largely the same as they’ve been since V5.0 days

That said, we’ll point out a few interesting things that are new or worth noting

The panels inside the PMT should look very familiar … they ask for the same kind of information

that’s been required since back in the V5.0 days. There’s been a few new things added along the

way … mostly additional ports required to support additional functions … but in concept and in

essence the panels are the same as we’ve seen before.




Vertical Scroll Bars!

It’s easy to overlook the fact that some PMT panels are taller than others, and vertical scroll bars sometimes pop up. Don’t overlook stuff not shown.

Panel prior to this may not

have a scroll bar. Much depends on how the windows

are sized

In this example, there’s another SAF ID to be named

and defined below what’s

shown on the visible panel

Always watch for the vertical scroll bar!(or maximize the window)

The first thing we’ll mention is something fairly mundane, but it’s worth reminding ourselves about.

Some panels may very well introduce a scroll bar because the panel itself extends below the bottom

of the window. The scroll bars come and go, depending on the layout of the panel. The reminder

here is to watch for those scroll bars and to make sure when one appears that you scroll down and

make sure you’re entering all the information asked for. For example, in the bitmap shown above,

there’s another SAF ID field below the bottom of that panel. It’s really easy to overlook these things,

and that would result in an inconsistent value. (Unless you used the spreadsheet, then the fields

would be consistent based on the spreadsheet and the response file it created.)

One strategy to help with this is to maximize the PMT window. That will avoid scroll bar issues.




In V7, 64-bit JVM is Now the Default

Back in V6.1 the default was 31-bit, but now it defaults to 64-bit:

31-bit mode is “deprecated,”meaning while it’s still there and

still supported, it will eventually be retired and removed.

Generally speaking, the switch to 64-bit should be transparent to you.

Exception: if you have JNI code that is not yet written to 64-bit

Be aware of this change in the default

The next thing we’ll point out is that with V7 the default JVM mode is 64-bit. Back in V6.1

WebSphere z/OS introduced the ability to toggle 31-bit or 64-bit, and by default in V6.1 it was 31-bit.

But with V7, the default is 64-bit.

This should be a relatively transparent thing for you. The one concern we’ll highlight is if you have

custom JNI (Java Native Interface) code that has not yet been written to support 64-bit. A 64-bit

JVM calling native code must call a 64-bit native component. That’s just a given. So if you have JNI

code now and it’s calling 31-bit native, you’ll need to recompile the native to 64-bit to use the 64-bit

support of WebSphere z/OS V7.

Or … toggle that value you see here to 31-bit. That will mean the JVM will start in 31-bit mode and

your current JNI code will continue to work as it has in the past.




Intermediate Symbolic Links

In V7 PMT there is a facility for automatically creating the intermediate symbolic link between the configuration file system and product file system:

/wasv7config/mycell/mynodea

/wassmpe

/usr/lpp/zWebSphere/V7R0

The concept of using intermediate symbolic links is not new. We’ve

been advocating it since the days of WebSphere z/OS V5

See WP100396 on ibm.com/support/techdocs

What’s new is the automatic creation of the symlink by the BBO*HFSA job

Config File System Product File System

Created inside the node’s configuration file system. Created by BBO*HFSA.

For some time now we’ve advocated the use of “Intermediate Symbolic Links” as a way to provide a

degree of isolation between the node configuration and the product file system. The intermediate

symbolic link is really just an alias point between the configuration file system and the read-only

product file system … it allows a node to be switched over to a new level of product by changing the

alias. It’s proven to be quite effective as allowing sufficient isolation to “roll” maintenance through a cell. See WP100396 on ibm.com/support/techdocs for more on this concept.

The main point here is that for the first time the PMT will capture your desire for intermediate symbolic links and will create them for you. It does this in the BBO*HFSA job, which is run after the

job that allocates and mounts the configuration file system. The intermediate symbolic link is created

inside the node’s configuration HFS or ZFS, which means the intermediate link is nicely associated

with the node, and is subject to backup when the node file system is backed up.




The Created Definitions and the “Views” Associated with Definition

When completed, the definitions are listed relative to the location that is selected. Tabs provide different “views” of the selected definition:

Locations

Let’s see what those views provided …

Definitions

Views

When you’ve finished creating the definition, the PMT will bring you back to the main perspective,

and there you’ll see the different “views.” One if the location. As we’ve seen, when you select a

location the tool will display all the definitions associated with it. When a definition is selected, the

tabs highlighted in blue will be populated with information about the selected definition.




Views: Summary, Instructions and Response File

These three views are specific to the definition that’s been selected:

Summary Instructions Response File

Instructions -- provide information on preparing the system and submitting the jobs. Instructions also in hlq.CNTL(BBO*INS)

Response file -- can easily be copy/pasted into an e-mail or text file. Also included in the hlq.DATA(PMT*) member.

A definition has three views associated with it:

• Summary -- this provides the key things about a definition … the definition name, the

environment type, the location path, and the z/OS target data sets.

• Instructions -- it’s very important to know of the existence of these instructions. They spell out

the sequence of job submission, the requirements of the ID under which the job runs, and other

pre-submission system programming requirements that are needed. Instructions are not new

with the V7 PMT … instructions have been around since the days of the ISPF dialogs. But for

anyone new to this, please consult the instructions to see what steps are needed to create the

environment. The instructions are uploaded to the target data sets, into the DATA target under the BBO*INS member.

• Response File -- this is the complete response file for the definition. It is available for

copy/paste directly from this view, so if you’re looking for a handy way to send someone the

response file, this would be it. It’s worth noting that the response file is also uploaded to the

target data set.




The “Process” Button and What it Does

Two options offered: “Upload” and “Export.” Upload will FTP to the specified z/OS system. Export will put the CNTL/DATA members to external folders.

Upload Export

• Host picked up from node host value, but can be overridden

• Userid/password is whatever allows FTP

• Port and timeout can be set

• Target data sets fixed based on what was specified in the tool

• Allocate data sets on the fly if you wish

• Name the external file location

• Two sub-folders created: \cntl and \data

• Those sub-folders are populated with the same files as would be uploaded to the CNTL and DATA data sets

• You may then transfer to the z/OS system using whatever manual system you prefer

• (Note: must preserve HLQ as set in customization)

Once a definition is complete, the “Process” button is used to act upon the definition. There are two

choices -- upload and export.

Upload performs an FTP of the files to the z/OS operating system. It will allocate the data sets on

the fly if you indicate it should, and will take the generated files from the tool and create members in

the data sets.

Export will put the “members” out to a set of files on a drive accessible by the operating system

running the PMT. It creates subfolders and then places the files that represent the members under

those folders. You then send the files to someone else, or you may upload them manually.

The one key warning we give you is that if you upload manually, the HLQ of the data sets on the

z/OS system must match the HLQ given to the PMT during the creation of the definition. That HLQ

is used in various places in JCL to specify where to get input files. If you were to upload the files into

a different HLQ, many of the jobs would fail.




Example of Generated Jobs for Deployment Manager

The jobs and the sequence they’re run is very similar to before, with a few differences:

BBOCCINS

BBOSBRAK

BBODBRAK

BBOSBRAM

BBODCPY1

BBODCFS

BBODHFSA

BBOWWPFD

No more “BRAJ” to create script for “BRAK” to

execute. Combined; one for common groups, one for the node’s security profiles.

HFS or ZFS … your choice (same as V6.1)

CPY1 job brings in JCL procs, which have different format

No more HFSB job … combined into WWPFD

Instruction member … same as before

Message -- very similar to what we saw in V6.1. Some consolidation of jobs and streamlining. But overall very similar to before.

Will automatically create intermediate symlinks based

on setting of option in the WCT

The “Z member” is now combined into the main proc, so now there’s one member rather than two.

Here’s a listing of the jobs that create a Deployment Manager, which we’ll use as an example. The

jobs are similar to what we’ve seen in the past, with a few jobs now removed as some consolidation

has taken place. Bor instance, there’s no more “BRAJ” job that simply created the RACF script.

And the HFSB job is now gone, rolled into the WWPFD job as the last job run.




Summary

The PMT is the runtime configuration feature of the WCT:

• One of the included features of WCT

• Will display as a “Perspective” within the WCT

• Has “Locations” and “Definitions”:• Location is a place on a physical storage device

where the tool maintains information about the customizations

• Definition is a specific customization, for example a DMGR, or an application server

• PMT works with spreadsheet• New version of spreadsheet for V7

• Output from PMT is a set of customized jobs and scripts that create the runtime component on the z/OS platform

z/OS Profile Management Tool

Here’s a summary of the PMT. Let’s turn our attention to the MMT.




Exploring the MMTMigration Management Tool




The MMT in Context to the WCT

Here’s our picture from earlier, with the MMT highlighted:




PMTProfile

Management Tool

MMTMigration

Management Tool

Additional features


The MMT is another one of the basic functions of the WCT. It is used to configure migration jobs.




Very Similar to Look-and-Feel of the PMT … Because Eclipse

The appearance “on the glass” is nearly the same as the PMT because both are based on Eclipse, and thus have a common tool framework.

MMT is a “Perspective” in the WCT toolWhen the perspective is open, it appears as a tab

LocationsSpecific to the MMT. Can’t use the same location for MMT and PMT.

DefinitionsUnder the

selected location.Action Buttons

These are used to initiate actions within the PMT tool

• Create a migration definition

• Regenerate (modify) a definition

• Delete a definition

• Process (upload to z/OS or export to file system) a definition

The look and feel of the MMT is very similar to that of the PMT, and that is as expected. Since both

are built on the Eclipse base, they will by design have similar appearances. Going further, the two

look very much alike because they have very similar objectives -- the PMT is used to generate

customized jobs that create the runtime environment; the MMT is used to generate customized jobs

that migrate a runtime environment. They both capture data from you, the user, and generate

customized jobs.




Migrating a Cell -- Node by Node Operation, Transform Config

Two key points about migration -- it’s done node-by-node, and what it involves is copying out the existing configuration, transforming it, writing new:

CR SR

AppServer

CR

Node Agent

CR

Daemon

CR SR

DMGR

LPAR A

CR SR

AppServerNode

Cell

Migration Utility(Customization done by MMT)

Migration Utility(Customization done by MMT)

V7.0

V7.0

New configuration file systems, with V7.0 configuration created based on the existing node

configuration used as input

Where the MMT plays a role -- the customization of the migration utility jobs

that perform the migration

Version 5.1, 6.0 or 6.1

Migration is simply the act of taking an existing V5.1, V6.0 or V6.1 node and transforming the

configuration definitions so it creates a V7 equivalent of that environment. It’s a node by node

process. The key here is that the migration does not modify the existing configuration … it copies it

and transforms it while writing it into a new file system.

The MMT is what generates the batch jobs to perform the migration. The batch jobs are more than

just JCL; they are rather complex programs that understand the requirements of V7 and transform

existing configuration elements to the new formats.




Details of Migration using MMT Spelled Out in White Paper

A “Migrating to V7.0” white paper has been written by the Washington Systems Center that spells out the field-by-field details of migration

ibm.com/support/techdocs

WP101329

That will be the source of

information on how to use the MMT to perform a migration

This document will give you the overview of it

This “Introduction to WCT” document is not intended to go into all the details of creating the

migration jobs. Another Techdoc will do that. That’s the one shown on this chart.




Selecting the Type of Migration to be Customized

Three choices are presented … they are the three types of nodes that exist for Version 5.1, 6.0 and 6.1 (the supported “from” versions):

CR SR

AppServer

CR

Node Agent

CR

Daemon

CR SR

DMGR

CR SR

AppServerNode

CR SR

AppServer

CR

Daemon

Again, node-by-node, so …

• A Standalone server (one node) consists of one MMT definition and one set of generated jobs

• A Network Deployment (ND) cell would consist of one MMT definition for the DMGR and one MMT definition for each of the federated nodes.

The MMT offers three choices for customizing migration jobs -- a DMGR node, a standalone server

node or a federated node. Those are the three basic forms of nodes.




A Flowchart View of Creating a Migration Definition

Somewhat similar to what the PMT uses, but has fewer steps:

Definition Name and Response File

Target Data Set HLQ

System Proclib and V7 Product Location

“To” Configuration File System Allocation and Mount Point Information

“From” Configuration File System Information

Migration Options

JOB Card

Fewer steps than PMT because migration does not involve

creation of a node environment, but the copying/tranforming

(migration) of the node

Similar to PMT in that you have location, definition and the jobs

that are generated by the process

Migration is performed when the jobs are uploaded to z/OS and

executed

The process is like the PMT, but shorter. The reason it is shorter is because customizing the

migration jobs do not require nearly as much information as is required to build an environment in

the first place. At its heart it is a specification of the “from” path and the naming of the “to” location.

There’s a bit more than that, of course, but the “from/to” equation is the heart.




The Jobs Created by the MMT

Up to five jobs, but only one is the real “migration” job; others are housekeeping jobs -- allocating file system, copying JCL, etc.:

Optional

Main migration job is the “MG3” job

This is a summary chart of the jobs that are created by the MMT in support of migration. The jobs

are dependent on the type of node being migrated. For instance, the DMGR node does not have the

MG1 and MG2 jobs because the function of those two jobs does not apply to a DMGR node, but they

do to a Federated or Standalone node. Those two jobs are optional in any event, as they are used to

clear XA logs and those are only present if you have XA connectors installed.

The point here is that the jobs are generated based on the type of node migration being defined.

And the last job … the “MG3” job … is the main job that does the migration.

There is another way to perform the MG3 job … by running three smaller jobs in sequence. We see

that next.




More Granular Migration

An alternative is to run three jobs that, when combined, do the same thing as the main MG3 migration job:

BBOW*PRO Creates the product directories and skeleton profile in the target

BBOW*PRE Copies existing configuration into a backup location in temporary space

BBOW*POS Performs the migration

Advantages -- less time for each job, and a more granular failure/recovery/cleanup process

Particularly suited to very large configurations that normally take hours to migrate

The MMT will also generate three other jobs -- PRO, PRE and POS -- that when run in sequence

provide the exact same thing as the MG3 job, but it does it in a more granular fashion. The

advantage to this is duration of any single job, and a more granular cleanup process.

But there’s really no magic to this … the original MG3 was comprised of the 12 steps you see in the

picture above. The three separate jobs is really just a repackaging of that. The separation is not

quite as clean as the picture above suggests, as a few of the early steps are housekeeping chores

and duplicated in the PRO, PRE and POS jobs. But the picture above illustrates the key point of the

one big job (MG3) being split into three smaller jobs.




MMT has Summary, Instructions and Response File as Well

Like the PMT, the MMT has tabbed “views” that provide a summary, instructions and a response file:

Instructions -- provide information on preparing the system and submitting the jobs. Instructions also in hlq.CNTL(BBOM*INS)

Reponse file -- can easily be copy/pasted into an e-mail or text file. Also included in the hlq.DATA(ZMMT*) member.

Summary InstructionsResponse

FileDefinitions

The MMT is like the PMT in that when a migration definition is created the tool will display several

“views” -- summary, instructions and response file.




The “Process” Button -- Just like PMT

Two options: “Upload” and “Export.” Upload will FTP to the specified z/OS system. Export will put the CNTL/DATA members to external folders.

Upload Export

Uploads customization members to z/OS system

Places customization members to the named

external file system

And the MMT’s “Process” button does the exact same thing as the PMT’s process button.




Document Change Activity and Credits

The WebSphere Application Server for z/OS support team at the Washington Systems Center consists of: John Hutchinson, Mike Kearney, Mike Loos, Louis Wilen, Lee-Win Tai, Steve Matulevich, and Don Bagwell.

Mike Cox, Distinguished Engineer, serves as technical consultant and advisor.

Brian Pierce and Dennis MacDonald provide invaluable system programming support to the team.

Many thanks to Harvey McGee, Jeff Mierzejewski, Dana Duffield, Mark Luchini, Alex Guo, and Mickey Scott for their helpful contributions to the content of this document.

Special thanks to John Cowel for his continuing update and support of the “Planning Spreadsheet”

For questions or comments regarding this document, e-mail Don Bagwell at [email protected]

September 26, 2008 Original document

September 29, 2008 Added Techdoc number and corrected incorrect references to what WCT stood for. The acronym is “WebSphere Customization Tools,” not “Configuration”. Also provided URL for download site where the WCT can be acquired.

Change log and credits.

End of Document

PRS3357 - Introducing the WCT for zOS - IBM · PRS3357 - Introducing the WCT for WebSphere z/OS...

Documents

Transcript of PRS3357 - Introducing the WCT for zOS - IBM · PRS3357 - Introducing the WCT for WebSphere z/OS...