[z/OS]

Applying maintenance to the Feature Pack for OSGi Applications and Java Persistence API 2.0 on z/OS systems

Maintenance for the WebSphere Application Server optional materials is similar to that for the base WebSphere Application Server for z/OS product. Maintenance is applied using the System Modification Program / Extended (SMP/E), and then it is moved into production. The optional materials include feature packs and other interim deliverables.

Before you begin

Some feature-pack maintenance levels for WebSphere Application Server Version 7.0 are closely linked to specific base WebSphere Application Server maintenance levels. On distributed operating systems, feature-pack maintenance is applied automatically when base maintenance is installed. On z/OS systems, customers are responsible for upgrading feature-pack levels when this requirement is indicated in the installation materials for base service levels. Similarly, some feature pack service levels require a minimum base service level. These requirements generally are indicated in ACTION HOLD statements in the service level PTFs. If the WebSphere Application Server base service level is not appropriate for use with a specific feature-pack service level, feature-pack enabled servers do not start.

The WebSphere Application Server for z/OS service support Web site provides program temporary fix (PTF) lists for the base WebSphere Application Server for z/OS product and for each feature pack or other interim deliverable.

What to do next: Decide on the base WebSphere Application Server for z/OS maintenance level to which you will be upgrading and on which feature packs or other interim deliverables you need to upgrade.

Contact the IBM Software Support Center or consult the WebSphere Application Server for z/OS service support Web site to determine the PTFs for the required feature pack or interim deliverable maintenance levels, and order or download these PTFs.

Procedure

  1. Make copies of both the WebSphere Application Server for z/OS datasets (including the product file system) and the WebSphere Application Server for z/OS optional-materials datasets, including the optional-materials file systems.
  2. Mount the WebSphere Application Server and optional-materials file systems at your usual service mount point. Be sure to mount the product-specific optional-materials file systems at the appropriate mount points inside the optional-materials file system.
  3. Apply base WebSphere Application Server for z/OS maintenance using SMP/E.
  4. Apply the required feature pack or other interim deliverable service using SMP/E.

    The base product and the optional materials can be applied using either a single APPLY command in SMP/E or separate APPLY commands.

  5. Unmount the WebSphere Application Server and optional-materials file systems from the service mount points, and remount them on your production systems.
  6. Follow your accustomed maintenance procedures to move your WebSphere Application Server for z/OS runtime environments to the new service level.

    When the post-installer runs for each node, it makes any necessary configuration file system changes for both the base WebSphere Application Server product and any feature packs enabled on the node. The applyPTF.sh command output will contain a log of all changes made.

What to do next

The WebSphere Application Server for z/OS nodes that are upgraded to the new service level are now running with compatible WebSphere Application Server for z/OS and optional-materials maintenance.

Restarting a WebSphere Application Server for z/OS node at a previous service level normally involves simply switching the runtime to use the previous level of code (datasets and product file system); the post-installer checks that any configuration changes made since the old level are backwards compatible.

New service levels that are not backwards compatible have this fact flagged in an ACTION HOLD statement for the service PTFs; customers who need to restart at the earlier service level will need to run the backoutPTF.sh command, which is located in the WAS_HOME/bin directory. To back out configuration changes for feature packs or other optional materials, specify the feature-pack identifier (rather than "WebSphere") in the backoutPTF.sh command. For example:
backoutPTF.sh JPA target_service_level
backoutPTF.sh Aries target_service_level
Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Jun 12, 2013 3:32:32 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v700osgijpa&product=was-nd-mp&topic=tins_maint_osgi_jpa2_zos
File name: tins_maint_osgi_jpa2_zos.html