WebSphere Application Server for z/OS Version 8 and ... - IBM · WebSphere Application Server for...

WebSphere Application Server for z/OS Version 8 and 8.5, including Liberty Profile z/OS

Test, Production, andMaintenance

Designing flexibility and isolation into your WAS z/OS topology

Version Date: January 12, 2015

See "Document Change History" on page 26 for a descriptionof the changes in this version of the document

WP100396 atibm.com/support/techdocs

© IBM Corporation 2015

WP100396 – WAS z/OS Test, Production and Maintenance V8 and V8.5

This document was written by Don Bagwell of the IBMGaithersburg zGrowth WebSphere team.

Many thanks to Jeff Mierzejewski of the WAS z/OSdevelopment organization for his help with Installation

Manager and other WAS z/OS installation issues.

© 2015, IBM CorporationAmericas Advanced Technical Skills - 2 -

WP100396 at ibm.com/support/techdocsVersion Date: Monday, January 12, 2015


Table of ContentsOverview...........................................................................................................................................................4Key: isolating portions of the runtime...................................................................................................................... 4Key: understanding when server stop and restarts are necessary..........................................................................4How this document is constructed........................................................................................................................... 4

Full-Profile WAS z/OS......................................................................................................................................5Full-profile WAS z/OS concepts and terminology....................................................................................................5What IBM Installation Manager creates as part of an installation............................................................................6Overview of Installation Manager........................................................................................................................... 6Concept of a “service” zone................................................................................................................................... 7Update target file system or create new for each release?....................................................................................8

The use of symbolic links and “intermediate symbolic links”...................................................................................8Example of intermediate symbolic link structure in a cell.......................................................................................10General rules and good practices about introducing new code to the server runtime...........................................11Applying maintenance – the “post-installer” function.............................................................................................12The difference between applying maintenance and migrating to a new version....................................................13Isolation within a functional environment...............................................................................................................13Isolation between functional environments – test and production.........................................................................15The Daemon.......................................................................................................................................................... 15Summary............................................................................................................................................................... 17

Liberty Profile z/OS........................................................................................................................................18Overview of Liberty Profile z/OS............................................................................................................................ 18Installing Liberty Profile z/OS................................................................................................................................ 18Relationship of configuration to product file system..............................................................................................18Multiple servers under the same user directory.....................................................................................................19Different levels of product when servers under the same user directory...............................................................20What happens if JCL start procedure is changed while servers are running?.......................................................20Isolation between functional environments – test and production.........................................................................21Collectives and clustering...................................................................................................................................... 21The Angel Process................................................................................................................................................ 23

Other Information...........................................................................................................................................24Creating intermediate symbolic links at time of cell creation.................................................................................24Changing a configuration to use intermediate symlinks after initial construction...................................................25Other sources of information................................................................................................................................. 25

Document Change History............................................................................................................................26




OverviewThis document is a companion piece to the original WP100396 white paper. That paper focused onWAS z/OS V6.1. This paper focuses on WAS z/OS V8.0 and above, including Liberty Profile z/OS.

In truth, the same principles apply. Creating a separate paper for V8.0 and above provides us an opportunity to eliminate things no longer part of the product1 and focus in on things that have come along starting with V8.02.

Key: isolating portions of the runtime

The one key principle to understand is how WAS z/OS configurations can be designed so updates to one part of the topology do not impact other parts of the topology. That's what allows isolating test environments from production environments. That's what allows maintenance to be “rolled” through a production environment to maintain availability.

In picture form:

Key: understanding when server stop and restarts are necessary

In a perfect world maintenance and new function could be introduced without any need to stop and restart the servers. That is possible under some circumstances3, but not all.

In general, product maintenance and new product versions are going to require a stop and restart of the servers. The degree of isolation designed into the runtime topology will indicate how granular the server stop and restarts may be.

Note: Full-profile WAS z/OS has a different operational model from Liberty Profile z/OS, which is why this document has a section dedicated to each.

How this document is constructed

This document is designed around two sections – one for full-profile WAS z/OS, and one for Liberty Profile z/OS:

Full-Profile WAS z/OS Page 5

Liberty Profile z/OS Page 18

Each section will have sub-sections on the various topics related to isolation for purposes of test, production and maintenance.

1 Such as PDSE library data sets that back in V6.1 were STEPLIB'd on the JCL start procedures.2 Such as the use of IBM Installation Manager (IM) to do the install of the product and the install of maintenance.3 Liberty Profile has the ability to dynamically introduce certain change to the running server. But other changes require a stop and restart.




Full-Profile WAS z/OSFull-profile WAS z/OS Version 8.0 and above has two things different from what was spelled out in the original WP100396 white paper based on V6.1:

1. There is no longer a PDSE library data set to hold the native modules4. Instead, the modules are held in the UNIX Systems Services (USS) file system for the product install.

2. The installation of product is no longer done with SMP/E. Starting with WAS z/OS V8.0 the installation of the product and installation of product maintenance is done using IBM Installation Manager (IM).

Of the two, the first is the most significant change from the original WP100396 white paper. Back when the product involved both PDSE modules and a USS file system, rolling change into an environment involved making sure both PDSE modules and USS file sysems were changed and kept in synch for the server runtime. To complicate matters further, the native modules could be made accessible via LINKLST or STEPLIB, and it was necessary to be really clear in one's mind where the modules were coming from. Starting with WAS z/OS V7, the native modules moved to the USS file system.

When it comes to SMP/E and Installation Manager, in general, both do the same thing – manage the update of installed products. How they do it is quite different5. With respect to isolation of the runtime components and introducing change in a granular fashion, both IM and SMP/E share the same considerations. We will focus on IM in this document because that's what WAS z/OS V8.0 and above uses.

Full-profile WAS z/OS concepts and terminology

The following picture and notes that follow illustrate the key concepts related to this topic:

4 This change was made in V7, and has carried forward into V8 and V8.5.5 A separate debate is whether IM should be used. But we will not get into that debate in this document. The use of IM for install of WAS

z/OS is what it is.




Notes:

1. An application server. For WAS z/OS this is comprised of several address spaces, with a minimum of one control region (CR) and one servant region (SR). The CR and SR are logically grouped to represent an “application server.”

2. A node. A node is a collection of application servers on a z/OS LPAR.

3. A node's configuration file system. This holds information about the configuration.

4. The Deployment Manager, its node, and its configuration file system, which is often referred to asthe master configuration. The Deployment Manager (DMGR) is an application server that runs the IBM administrative application.

5. A Node Agent. As the name implies, this serves as an agent process on behalf of the node. It is what the DMGR communicates with to synchronize change made out to the affected nodes.

6. A cluster of application servers. Clusters are used to duplicate an application server environmentfor the purposes of availability.

7. The cell. A cell is a logical collection a Deployment Manager and the nodes it manages. The cellrepresents the extent of management control a given DMGR has. Cells are important when discussion isolation by function – that is, test and production.

8. The product file system. This contains the files and modules delivered by IBM. This file system is populated using IBM Installation Manager (IM).

9. The relationship between the configuration file system and the product file system. This is how a node understands what level of product code it runs with. This is where the discussion of symbolic links comes into play, and where isolation of design is introduced. We discuss this in more detailed under “The use of symbolic links and “intermediate symbolic links”” on page 8.

10. The Daemon. This serves to support key z/OS-specific functions on the LPAR. The rule of thumb is this – one Daemon per LPAR per cell. The picture above shows a cell that spans two LPARs; thus there are two Daemons. This enters the conversation when we discuss the stoppingand restarting of servers when new code is introduced. See “The Daemon” on page 15.

Those notes offer only a brief overview of the functions and operations of WAS z/OS. They serve as a way to level-set what is discussed next.

What IBM Installation Manager creates as part of an installation

IBM Installation Manager (IM) is used to create the product file system, which was in the picture illustration above. IM is not used to create the configuration file system. The WebSphere Customization Tool (WCT) is used to create that.

Overview of Installation Manager

IBM Installation Manager (IM) is software that constructs a product install image at a specificversion and level, based on the parameters IM reads in when invoked. At a very high level, it looks like this:

The four pieces of this picture are:




• Installation Manager – this is the code that runs that does the installation. On z/OS itruns as a UNIX process, and can be wrappered with JCL to run as a submitted job.

• IBM Product Repository – this is where IM gets the product code to perform the install. This could be either:

1. “In the cloud” – that is, at an IBM server site accessible via the Internet, or

2. Local – that is, the repository is downloaded and is available to IM as a locallymounted file system

Notes: From the purposes of this document the two are essentially the same. When using IM the two imply different input parameters. But for the purposes of discussion isolation and maintenance updates to the WAS z/OS configuration, we can ignore this distinction and consider the two as the same thing6.

By the way, it is possible to use SMP/E to install this IM product repository. If you here people talk about SMP/E with respect to WAS z/OS V8 and above, this is what they're referring to.

• Target of the install – this is where IM will build the product file system ( from the illustration earlier) and write the output.

• Install Paramters – this is what is passed to IM to tell IM where the repository is, whatthe output target is, and what to install.

Our focus is on the target file system … what we call the “product file system” and was labeled in the earlier illustration. It is the relationship ( from earlier picture) between the configuration file systems () and this product file system that is the key to isolation.

Concept of a “service” zone

With IM it is quite possible to employ a “service zone” for the initial IM install, then copying the file system out for use by the WAS z/OS runtime enviornments:

This is the same concept as that used by SMP/E adminstrators for many years. It can be used by IM as well. It is seen as a good practice because it allows greater control over the install images produced by IM.

Another advantage is it allows install operations to be performed independent from the runtime. This is important because, as you'll see, moving new maintenance into an environment means stopping the servers. Having a separate service zone providers greaterflexibility to when the install processing can be performed.

6 Of the two, using the “cloud” repository is easier simply because you point IM at the repository and perform the install. The local option is sometimes necessary when the z/OS LPAR on which IM operates does not have access to the Internet.




Update target file system or create new for each release?

With Installation Manager you may designate an existing file system as the target and update the contents, or you may designate a new file system and create a new and separate file system for a new release:

Which you use is a matter of personal preference, but that preference may be influenced by whether you use the “service zone” process or not.

With a service zone in use, updates to an existing product file system do not affect the server runtime, because they're operating with a copy of the file system. You may then copyout with a new name to introduce new maintenance into your environment.

Note: If you do not use a service zone, and you use IM to update the in-use product file system, then understand that implies changing code under the running servers. Three key points: (1)stop the servers before making the changes; (2) set the product file system back to READ ONLY after IM has made its changes; (3) understand that with only one copy of the product file system then by definition every node points to the same thing … changing that file system means all nodes are updated to that level, and you really don't have any isolation.

This author's preference is to use a service zone and maintain separate copies for each level used in the environments. When things roll off and are no longer used they can be deleted to free space for new release.

The use of symbolic links and “intermediate symbolic links”

We are now ready to get to the heart of the matter – the relationship between the configuration file system ( from the illustration earlier) and the product file system ( from earlier).

The configuration file system is separate from the product file system7. Therefore, some form ofpointer must exist between the configuration file system and the product file system. That pointer is a set of symbolic links created in the configuration file system:

This is the default configuration setup for WAS z/OS – references to product files in the configuration structure are resolved via a symbolic links to the actual mount point of the product file system. Those symlinks are created when the configuration file system is created.

7 This is true for WAS z/OS. It is not true for WAS on other platforms … for instance, Windows.




Is this an issue? Consider the picture from earlier, with each node in the cell with symlinks pointing to the same product file system mount point:

That has two very limiting aspects to it:

1. Any change to the product file system will impact all three nodes at the same time.

2. To umount the product file system to replace it with a new level of the product file systemmeans shutting down the servers in all three nodes so the unmount command can work.

What's needed is an additional point of re-direction so each node can be easily moved to a new level of code. That is accomplished with “intermediate symbolic links”:

There's nothing particularly special about this … they are simply another symbolic link created inside each node's configuration. The WCT tool will do this for you if you select the checkbox tohave it create the intermediate symlinks8. The intermediate symlink creates a single point of re-direction that can be used to “swing” (change) an individual node to point to a new product file

8 See “Creating intermediate symbolic links at time of cell creation” on page 24.




system at a new level of code:

And that is the key … that is what allows isolation on a node-by-node basis. All it takes is changing that one intermediate symbolic link9 and the whole node is pointed to a new level of product code.

Isolation on a node-by-node basis is important because that is the level of granularity at which maintenance is applied, and that is the level of granularity at which new version migration takes place.

Note: Ideally you create the intermediate symobolic link at the time the cell is created. But if you have a cell that does not have intermediate symoblic links, they can be added after the fact.

The PRS1558 Techdoc at ibm.com/support/techdocs describes a utility that will sweep through a configuration file system and change symlinks so they point to a newly created intermediate symlink. This is a way to “retro-fit” a cell to use intermediate symlinks:http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1558

Example of intermediate symbolic link structure in a cell

For the WAS z/OS workshops we run we have a pre-built cell called the “Z9CELL.” It is a relatively simple cell that looks like this:

9 Deleting the intermediate symlink and recreating it with the pointer to the new level of code.



http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1558


The file systems for each node have intermediate symbolic links that look like this:

Each node has an intermediate symbolic link called /wasInstall that points to the mount point of the product file system, which has a name indicating V8R55 at Fixpack 2. Both nodes operate at level 8.5.5.2.

If we wanted to bring 8.5.5.3 (the next fixpack) into the picture starting with the DMGR node, we would simply stop the DMGR and change the intermediate symlink10 for the DMGR like this:

When the DMGR is restarted it will detect the new level of code, run the post-installer process (see page 12) and come up at the new level. The application server node (Z9NODEA) remains at the previous level of code. Changes to the DMGR node are isolated from the application server node by each node having its own intermediate symbolic link to the product file system.

This was a simple example – one cell, one LPAR, two nodes. Imagine a more complex environment with several cells (test, QA, production), and the production cell having nodes that span across multiple LPARs in a Parallel Sysplex. If each node has an intermediate symlink pointing to a product file system, then each node can be independently moved from one level of code to another. That provides the isolation we need to maintain flexibility of update.

General rules and good practices about introducing new code to the server runtime

Here are some things to keep in mind when introducing udpates to your environment:

• Make a backup of your entire cell environment before you introduce a new level of code

Changes are made to the configuration file system when a new level of code is detected (see “Applying maintenance – the “post-installer” function” on page 12). If you need to fall back to the previous level, that can be done with a shell script … but it's easier to simply restore to the backup point.

• Higher-level code is introduced first to the DMGR node, then the managed nodes

The DMGR can manage “downhill” to lower levels of code, but not “uphill” to higher.

10 By deleting the symlink and re-creating it with the new product file system mount point specified.




• Servers using an intermediate symbolic link must be stopped before the symlink can be deleted and re-created

z/OS USS won't allow the symlink to be deleted if it sees something using it. Since the servers will need to be stopped and restarted to pick up the new code, stopping the servers to change theintermediate symlink can be considered part of that process.

• The first server in a node to start after new code is introduced will run the post-installer

The post-installer function makes changes to the node's configuration based on requirements it sees spelled out by the new code (see “Applying maintenance – the “post-installer” function” on page 12). This is why taking a backup of your environment is important.

After the first server started completes initialization, other servers in the node will start without running the post-installer.

• The DMGR is alerted when a managed node is updated to a new level

This is a subtle but important point to understand – when a managed node is updated to a new level of code, it communicates with the DMGR to let it know the new level it is running at. The DMGR then records that information in its configuration.

This is why you can't restore a managed node back to a lower level without restoring the DMGR back as well. If you restore a managed node file system back to level n, and the DMGR thinks the node should be at n+1, there will be issues.

This is why we recommend a backup of the entire cell environment prior to introducing new code.

• Maintenance and migration are not the same thing

Introducing a new level of maintenance is something different from moving the configuration to a new version. The node's configuration is updated for maintenance using the post-installer function (see page 12). Migration requires a more involved process to transform the configurationfile system to be compatible with the new version of the product. See “The difference between applying maintenance and migrating to a new version” on page 13 for more on this.

Applying maintenance – the “post-installer” function

It is often the case that new maintenance will require some change to the configuration file system for the node. To handle this, WAS z/OS will run a “post-installer” function when the first server in a node is restarted after the newer code-level product file system is introduced. The post-installer function will make the required configuration changes.

There are two post-installer scripts – applyPTF.sh and runConfigAction.sh. Before V8.0 only applyPTF.sh existed, but with V8.0 and above both exist. Here's the distinction:

• applyPTF.sh – the original post-installer, this evolved over time to support updates to the configuration file system for WAS z/OS and any augmented stack products11 that were installed. That's the key to understanding why applyPTF.sh is still around – it is there to handle cases where an augmented stack product is part of the configuration.

• runConfigAction.sh – this was introduced in V8.0 and runs to update the configuration file system to support any changes required by the new code.

For the purposes of this document it's not necessary to understand all the details of these post-installer functions. The important things for this document are:

• Know that they exist and run when a new level of code is introduced

• Know that they modify the configuration file system, which is why having a backup is a good thing.

11 Stack products are those that pre-req WAS z/OS and install “on top” a WAS z/OS runtime configuration. Examples include: IBM WebSphere Compute Grid and IBM Virtual Enterprise. Those stack products required the product to be “augmented” into the WAS z/OS runtime configuration. Starting with V8.0 and above, IBM Installation Manager provided the mechanism for incorporating WAS z/OS and these higher-function products into the same install image, and “augmentation” was no longer necessary.




The difference between applying maintenance and migrating to a new version

Going from V8.0.0.0 to V8.0.0.1 is an example of applying maintenance.

Going from V7.0.0.24 to V8.5.5.2 is an example of migrating to a new version.

The two processes are not the same; in fact, they are quite different. Applying maintenance is amatter of introducing a new product file system with the new code and restarting the servers so the post-installer function can run. The node is then updated to the new level.

Migration from one version to another is a more involved process. It makes use of a migration utility to read in the configuration file system, transform it to the format required by the new version, and writing it out as a new configuration file system:

Depending on the change you're seeking to introduce12, it will either be a maintenance change or a migration change.

Interestingly, the two are similar in several ways:

• Both benefit from having the runtime have designed-in isolation via intermediate symbolic links.

• Both involve stopping and restarting servers to pick up the new code, so the concept of “rolling” the updates through an environment to maintain availability applies.

• Both involve updating the DMGR first, then the managed nodes

For this document we will not go into detail on how to use the migration utility.

Key Points: Keep in mind the difference between maintenance and migration, and understand which applies to the move you are seeking to make. Understand that the concept of isolation via intermediate symlinks applies to both maintenance and migration. Node-by-node isolation is a very good thing.

Isolation within a functional environment

By “functional environment” we mean WAS z/OS runtime cells devoted to a specific purpose – for example, development, test, QA, production.

The key to isolation within a cell is understanding the node is the lowest level of granularity possible for applying updates. Maintenance and migration is done on a node-by-node basis, not a server-by-server basis. That is why being able to move a node from one level to another independent of other nodes is so important, and why the intermediate symbolic link concept is so central to this discussion.

12 As the example indicated, a move from 8.0.0.1 to 8.0.0.2, or 8.5.5.0 to 8.5.5.3 is maintenance. A move from V7 to V8 is migration. It's notalways obvious … for example, the move from 8.0 to 8.5 was considered a maintenance move. The same for 8.5.0 to 8.5.5. When the highest order number changes – V7 to V8 for example – that usually implies migration.




When availability is a concern, then it suggests a WAS z/OS environment with duplicated resources … with servers clustered across LPARs most likely. That's our picture from earlier, with the cluster highlighted:

The point is that such a configuration involves multiple nodes. We know we can use intermediate symlinks to isolate each node for product file system updates. That's this picture from earlier:

Which means we can “roll” maintenance across an environment by updating the stopping the servers and updating the intermediate symlink one node at a time. That allows part of the cluster to remain up and running (providing availability) while the other is down for maintenance.

Note: A WAS z/OS cluster may operate with different levels of code in the nodes involved. A cluster can also operate with different versions of code. As a general rule you would not want to run that way for too long. But running that way for the time it takes to roll the update through the environment is a common practice – a few hours, a few days … a week, etc.




Isolation between functional environments – test and production

The common practice is to isolate those at the cell level; that is, create a cell environment for development, another for test, and so on. The advantage of this is security access can be controlled very easily at the cell level. Developers would have access to the development cell, but no others; testers the test cell, but no others:

That picture also illustrates the points made earlier about the how isolating each node using intermediate symlinks provides flexibility to point to the product file system for the environment. The exact same principles that apply for isolation and rolling of updates within a multi-node functional environment apply to rolling updates across functional environments.

The Daemon

The WAS z/OS Daemon is a bit of an oddity in that it does not belong to any nodes13. Daemonsserve two purposes in a WAS z/OS cell – they provide a place to run the “location service” function14; and to control access to z/OS authorized services, such as cross-memory services. The second purpose is the key for this discussion, because when a Daemon is stopped, all the servers supported by that Daemon are stopped. The question is then: what servers are associated with a Daemon instance?

The rule is there is a Daemon “per LPAR per cell” – for example, if a cell spans three LPARs, there will be three Daemons for that cell:

13 It is a member of the “Node Group,” which for most cells is the “Default Node Group.”14 Which is used when a remote Java client attempts a remote lookup of an object in the WAS z/OS cell.




However, if there are multiple cells spanning those three LPARs, then each cell will have one Daemon per LPAR:

In this case there are five Daemons – three for the first cell that spans three LPARs, and two for the second cell that spans only two LPARs.

Stop one of those Daemons and the servers in the managed node for that cell on that LPAR arestopped. Servers for the cell on another LPAR are unaffected; servers in another cell on the same LPAR are unaffected.

We have seen that rolling updates through a cell is done no an node-by-node basis, and we have seen that it involves stopping the servers in the node while the update is performed. Stopping and restarting the Daemon is part of that process.

Imagine a three-node cell such as the following. Read the numbered notes that follow to see how rolling updates through this cell would be accomplished:

Notes:

1. Start with the DMGR node first because the Deployment Manager must be at equal or higher level than the nodes it manages. The post-processor function will update both the DMGR node and the Daemon configuration. Therefore, to update the DMGR node do the following – stop the Daemon, which will bring down all the servers for this cell on this LPAR; change the intermediate symlink for the DMGR node to point to the new service level mount point; then restart the Deployment Manager, which will automatically restart the Daemon at the new level and do the post-processor work. Your DMGR node and Daemon is at the new level.




2. The servers in this managed node will have been stopped when the Daemon for this LPAR was stopped. At this point you may either go ahead and change the intermediate symlink for this node to the new service level and restart the servers, or defer update to a later time and start the servers at the existing level.

3. Repeat the process – stop the Daemon, change the intermediate symlink, then restart the servers. The post-processor will update the node and start the Daemon at the new level.

4. This is the same as .

Summary

The key to this was the ability to isolate one node's configuration from another with respect to the product file system they point to. The use of intermediate symbolic links is what provides the flexibility.

The basic concepts of this are unchanged from the early days of WAS z/OS. The difference between then and now is two-fold – (1) we no longer have PDSE module libraries to consider, and (2) IBM Installation Manager (IM) is now used rather than SMP/E.




Liberty Profile z/OSLiberty Profile z/OS is part of the WAS z/OS product, but it is quite different from the “full profile” WAS z/OS we described in the first section. We'll cover isolation for Liberty Profile z/OS in this section.

Overview of Liberty Profile z/OS

Liberty Profile is IBM's latest application server runtime environment. It is based on several design principles:

• Dynamic operations – much of the Liberty Profile framework can be updated dynamically, which means fewer server restarts.

• Composable features – to make the server runtime as lightweight as possible, many of the features of Liberty Profile can be configured. This allows you to have Liberty Profile load in only those features you need for the applications you intend to run.

A very high-level comparison of full-profile WAS z/OS and Liberty Profile z/OS yields some key differences:

• Liberty Profile servers are single JVM. There is no CR/SR structure with Liberty

• There is no concept of cells and nodes with Liberty Profile

• The Liberty Profile configuration file structure is much smaller and simpler.

• The relationship between the configuration and the product file system operates differently than it does with full-profile WAS z/OS.

We'll explain some of these differences with illustrations in the following sections.

Installing Liberty Profile z/OS

Liberty Profile z/OS is installed using IBM Installation Manager, just like full-profile WAS z/OS is.What results is a file system at a mount point, though the file system for Liberty Profile is much smaller than that for full-profile WAS z/OS.

Earlier we spoke of using a “service zone” for installing full-profile WAS z/OS. The same concept can be applied to installing Liberty Profile z/OS:

Relationship of configuration to product file system

Unlike full-profile WAS z/OS, which knows about the product file system via symbolic links that point to the mount point location, Liberty Profile z/OS understands where the product file is by a UNIX environment variable that's set in JCL start procedure15:

15 Liberty Profile z/OS can be started as a UNIX process, in which case the product file system used is determined by where the server shell script to start the server is invoked. For this document we'll focus on the z/OS started task scenario.




//*------------------------------------// SET INSTDIR='/u/MSTONE1/wlp' // SET USERDIR='/u/MSTONE1/wlp/usr' //*------------------------------------

When that JCL start procedure16 is used to start a Liberty Profile z/OS server, it will read the SET INSTDIR= value and go to that location for the product file system. The SET USERDIR= value determines where the configuration is to be found.

Graphically, that can be illustrated like this:

Multiple servers under the same user directory

But there's a twist … the SET USERDIR= pointer, which is used to point to the location of the configuration, is really a pointer to the top of a tree that may have one or many server configurations in it:

This means the same JCL start procedure could be used to start many instances of Liberty

16 That's from the BBGZSRV proc supplied with Liberty Profile z/OS.




Profile under that configuration tree. For example:

S BBGZSRV,PARMS='server1'



All of those START commands would use the BBGZSRV start procedure to start separate instances of Liberty Profile z/OS, all at the same level of Liberty Profile since SET INSTDIR= value in the JCL points to a single location.

Different levels of product when servers under the same user directory

But that does not mean all servers under a user directory must run the same level of Liberty Profile z/OS. The solution is quite simple: create unique JCL start procedures for each server tobe started:

Server1 //BBGSRV1 PROC PARMS='server1' //*--------------------------------------------------------// SET INSTDIR='/shared/zWebSphere/Liberty/V8R55FP02' // SET USERDIR='/Liberty/configs' //*--------------------------------------------------------

And start with /S BBGSRV1 … the server starts at V8.5.5 Fixpack 2

Server2 //BBGSRV2 PROC PARMS='server2' //*--------------------------------------------------------// SET INSTDIR='/shared/zWebSphere/Liberty/V8R55FP03' // SET USERDIR='/Liberty/configs' //*--------------------------------------------------------

And start with /S BBGSRV2 … the server starts at V8.5.5 Fixpack 3

Or you could create JCL start procedures for the level of Liberty Profile z/OS you want to start:

8.5.5.2 //BBG8552 PROC PARMS='defaultServer' //*--------------------------------------------------------// SET INSTDIR='/shared/zWebSphere/Liberty/V8R55FP02' // SET USERDIR='/Liberty/configs' //*--------------------------------------------------------

And then start whatever server under that USERDIR= by passing in PARMS=

S BBG8552,PARMS='server1'


8.5.5.3 //BBG8553 PROC PARMS='defaultServer' //*--------------------------------------------------------// SET INSTDIR='/shared/zWebSphere/Liberty/V8R55FP03' // SET USERDIR='/Liberty/configs' //*--------------------------------------------------------

And then start whatever server under that USERDIR= by passing in PARMS=



You have some flexibility. The key is understanding that the level of Liberty Profile z/OS that will be used is based on the SET INSTDIR= in the JCL that's invoked.

What happens if JCL start procedure is changed while servers are running?

When a server is started using the JCL start procedure, the SET INSTDIR= value is cached and the running instance of Liberty Profile z/OS will go that location as long as the server stays up. It does not go back to the JCL each time it needs to access the product file system.




You could change the SET INSTDIR= value in the JCL start procedure and start a different server, and that server would start at the new level of code specified. The original server would continue to operate with the previous level it started with.

However, if you stop and restart that original server it will start using whatever level is specified in the JCL for SET INSTDIR= at the time the JCL is invoked.

This would be a means by which you could “roll an update” through a set of servers under a user directory location where one JCL start procedure is used for all the servers.

Isolation between functional environments – test and production

As the previous few sections have shown, you have some flexibility how JCL start procedures can be created to have different levels of Liberty Profile z/OS in use. There is nothing that says you must put all the servers under the same user directory, or different user directories.

That said, for isolation between functional environments like test and production, you may wish to consider having the Liberty Profile servers for each under different user directories. That gives you the ability to have one JCL start procedure for test, and a different JCL start procedure for production, and have a nice clean line of separation between the two.

Collectives and clustering

Liberty Profile (all platforms) has an emerging management model called “collectives.” The ideaof a collective is that there is a “collective controller” (a management interface point) and “collective members” (servers under some degree of management by the controller).

Please Note: This document will provide an understanding of the concepts of collectives, but not the specifics of how to configure and operate a collective. The objective of this document is to convey a sense for how to isolate environments from each other for the purposes of granular update.

Notes:

1. A Liberty Profile server instance is designated as a “controller.” This is done by updating the server.xml to indicate this server's new role as a controller.

2. Other servers can be designated as backup controllers. The model provides for a backup controller to take over controller duties if the active controller is lost. Designation of backup controller is also done through updates to the server.xml file.




3. Other servers are designated as “controller members” by updating the server.xml of each to indicate which controller it reports to. Further, controller members can be organized into clusters by updates to the server.xml to indicate the server is a member of a cluster. That's what this picture is showing for servers 3, 4 and 5.

4. Still other servers can be made members of the collective even though they are not clustered.

5. The “collective” – the set of servers for a given defined collective that are either controllers or members reporting to the controllers.

You may define multiple collectives:

To illustrate even more flexibility in this design, a collective member can “detach” from one collective and become a member of another collective by updating the server.xml of the member. It will then communicate with its new collective controller and dynamically become a member of the new collective. The old collective will detect the absence of the member and update its view of its collective.

What does all this mean in terms of isolation for the purposes of test, production and maintenance? We're in the early stages of adoption of this design, so the “best practices” for this are still evolving. That said, a few points, which are simply the opinion of the author:

• It makes some sense to organize collectives around functional environment – that is, a collective for test, a different collective for production. Access security can be made granular to the collective. The production collective can be made off-limits to those not authorized to the production collective.

• It makes some sense to create servers for a given functional environment under the same user directory. But as we saw, it's not a technical requirement. There is flexibility in rolling updates to Liberty Profile z/OS servers, whether they are under the same user directory or different user directories.

• Generally speaking, collective controllers should be updated before collective members are updated. File that under “the manager should be at equal or higher level of code from that which it manages.”




The Angel Process

The Angel Process is an element of Liberty Profile that is unique to z/OS. The purpose of the Angel Process is to provide an anchor point for controlling access to z/OS authorized services by Liberty Profile z/OS servers.

Examples of z/OS authorized services that requires the Angel Process – JDBC Type 2 cross-memory access to DB2 z/OS using RRS; z/OS MODIFY command to process SVC or Java transaction dumps; and WebSphere Optimized Local Adapter.

The key points to understand about the Angel Process are:

• It is only required if you have Liberty Profile z/OS servers that wish to use authorized services. Otherwise, it is not required.

• If needed, only one per LPAR is required17. That is regardless of how many Liberty Profile server instances are on the LPAR, whether they are part of a collective, or regardless of which collective they belong to.

• The Angel has no configuration file, consumes no TCP ports, and once started uses virtually no CPU.

• Access to z/OS authorized services is controlled by SAF SERVER profiles for each service. If you want a serve to use WOLA, for example, you grant that server's ID READ to the SERVER profile for WOLA access18.

• The Angel Process is started with a different JCL start procedure from that used for the servers. The default Angel proc is BBGZANGL, the default server proc is BBGZSRV.

• The Angel Process is designed to start and leave up “forever”. It is designed to not require an update to the Angel with each maintenance release. It is designed to not require the Angel to be at a level equal or higher than the servers it supports.

Note: With the release of the WOLA support in 8.5.5.2 an update to the Angel was required. That was an exception to the otherwise general rule that the Angel is designed to be started and remain up, regardless of the level of code Liberty Profile z/OS servers are running at.

• If you stop an Angel Process all servers associated with that Angel will be stopped. But again, stopping the Angel is not something you should do very often.

We mention the Angel to complete the story of Liberty Profile z/OS. With respect to isolation between Test and Production and the general principle of isolation, it really does not apply. All Liberty Profile z/OS servers on an LPAR that require access to z/OS authorized services will use the same Angel Process, regardless of the server's designation as “test” or “production.”

17 In fact, only one per LPAR is possible … if you attempt to start a second it will fail to initialize.18 There's more than one SERVER profile needed for WOLA. But the key concept applies – access to z/OS authorized services is granted

through server ID READ to the necessary SERVER profiles for the function.




Other InformationCreating intermediate symbolic links at time of cell creation

When a new cell environment is created, you have the opportunity to tell the tooling to create the intermediate symlinks when it builds the node. In the WCT tool that panel looks like this:

That will result in the intermediate symlink of wasInstall being created at the designated locationwith a pointer to the “Product file system” named in the first field. All the references to the product file system in the configuration will point to the intermediate symlink, which then points to the product file system. That's the isolation we spoke of earlier; that's what allows updates to be rolled in on a node-by-node basis.

If you use the “Configuration Planning Spreadsheet” tool19, that has the ability to designate the use of intermediate symbolic links:

That will pass into the WCT tool the name/value pair so the WCT tool will know to create the intermediate symlink to the product file directory indicated.

19 PRS4944 on ibm.com/support/techdocs for the V8.5 level of WAS z/OS. Spreadsheets for other levels found on Techdocs under different numbers. Search for “Configuration Spreadsheets.”




Changing a configuration to use intermediate symlinks after initial construction

Let's say you have a cell that does not have intermediate symbolic links. You want it to have symbolic links, but you don't want to rebuild the cell. Is there a solution? Yes.

A utility was written that will sweep through a configuration file system looking for all references to the product file system mount point and change them so they point to the intermediate symbolic link location. That utility is documented here:

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1558

That Techdoc describes the utility and provides the usage documentation, but to get the utility itself you must request it from the author20. The author's e-mail is provided in the Techdoc.

Other sources of information

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100396

The location for this Techdoc. Two PDFs are provided there: the copy for Version 6.1, and this copy for Version 8.0 and above. (This copy can be used for Version 7 because the same principles apply. The difference is Version 7 still used SMP/E to install while Version 8is where use of IM started.)


This is a “cookbook” document that describes Installation Manager and how to use it.


A collection of documentation on Liberty Profile z/OS.


A guide to other documentation for WAS z/OS.

20 If not used properly, the utility could damage a runtime configuration. Rather than making it widely available, we decided to restrict available to those who specifically ask. It's a simple test to insure those who are asking for it are prepared to use it with good intent.







http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1558


Document Change HistoryCheck the date in the footer of the document for the version of the document.

January 12, 2015 Original document

End of WP100396



WebSphere Application Server for z/OS Version 8 and ... - IBM · WebSphere Application Server for...

Documents

Transcript of WebSphere Application Server for z/OS Version 8 and ... - IBM · WebSphere Application Server for...