ISPW Troubleshooting

This section describes potential problems that can be avoided, as well as ongoing support issues. According to past experiences with various sites running ISPW, a number of situations have been found. They should be either avoided or monitored to reduce the potential number of support problems. The following situations are described in this section.

• • ISPW Support Versus ISPF Support
  • ISPW Support Versus Other Program Products
  • Upgrades to Compile Procs
  • ISPW and Migrated Datasets
  • Multiple Component Types Using the Same Libraries
  • Maintenance Guidelines
  • Abends in ISPF Client
  • Searching tasks by WORK REQ No.

ISPW Support Versus ISPF Support

Because ISPW is closely linked with ISPF, any changes to ISPF could affect ISPW. If the same person or group is not supporting both products, there are potential problems if ISPF is upgraded without the corresponding changes to ISPW.

Things to Watch Out For

Changes to the ISPF primary option menu or the Printoff or Script invocations. You may need to change:

• The ISPW primary menu to pick up the new ISPF invocations.
• M.ER options for the Printoff (3.6) calls.
• The Z functions list on the main menu, if you are using that option, via M.CZ or M.CO.

Recommendation

ISPW should either be supported by the systems programming group, or the ISPW support staff should be party to regular change control meetings to anticipate any impacts.

ISPW Support Versus Other Program Products

Further to the point above, ISPW interfaces to many technologies at any site, which undergo regular upgrades.

Things to Watch Out For

Changes to any of these products that are under the ISPW umbrella. Most of the time, these changes are transparent to ISPW, but you should check with us if unsure of the impacts. See the ISPW Interfaces Guide chapter on new versions and their implications.

Recommendation

ISPWshould either be supported by the systems programming group, or the ISPW support staff should be party to regular change control meetings to anticipate any impacts.

Upgrades to Compile Procs

In the planning phase, we discussed how the compiles are going to be installed and supported, and the “Skels only” approach versus the “Procs and Skels” approach.

If you have chosen to keep the Compile Procs separate from the Skels, there are potential synchronization problems.

Things to Watch Out For

Watch out for changes to the Compile Procs that may affect theISPWSkeletons. It is possible that the skeleton itself will need to be changed.

Recommendation

ISPW should either be supported by the group responsible for the compiler interfaces, or the ISPW support staff should be party to regular change control meetings to anticipate any impacts.

ISPW and Migrated Datasets

Data sets used by ISPW may be migrated based on a site’s storage management policies. ISPW is unaware of the status of these data sets. ISPW uses a variety of functions that may cause a migrated data set to be recalled. The expectation is that this occurs synchronously in the background.

Things to Watch Out For

There are several products that perform storage management. These products can be configured in various ways. This may include manual intervention for recalled data sets. BMC Compuware FDR performs storage management functions. If you are using FDR and have it configured for foreground recall of migrated data sets, the JCL for ISPW started tasks will need updating.

Recommendation

You will need to add the following DD statement to the SX, RX, and FX procedures. Refer to the FDR User documentation for complete information. Search for ABRSYNCH to find the details.

Multiple Component Types Using the Same Libraries

Generally, one set of libraries can be used for many Component Types if they all have the same dataset format (for example, 80 bytes, fixed). This works well for such types as COB, JOB, COPY, etc. If this is the case, Component Domains should be set up to prevent these different component types from using the same name. A component name has to be unique across component types because they are sharing the same libraries. See Maintenance-Functions for more information on setting up Component Domains.

ISPW base software is delivered and maintained using standard z/OS product installation processes (SMP/E).

Upgrading an ISPW environment involves additional considerations compared to typical z/OS products. To meet the specific requirements of each customer, ISPW supports extensive configuration and customization. There will also be multiple ISPW environments: at a minimum, one “test” and one “production” environment.

The SITE application is provided as the default mechanism for maintaining local customizations. New major versions of ISPW, as well as any single PTF, may contain changes to components that have been placed and/or updated in the SITE application.

As part of any ISPW implementation, the process by which product changes are applied to each ISPW environment should be established. The ISPW Administrator plays an important role in this process. They will need to verify whether any PTF or new version of the base software requires updates to the SITE application. The ISPW Administrator and the z/OS product installer will need to coordinate their respective tasks in order to make those product changes active in each ISPW environment.

A major upgrade may require going through the product installation process. The process to check for changes required to the SITE application is similar, whether it’s a completely new set of base software or a single PTF.

General Guidelines for Applying Product Updates

Local procedures for managing ISPW updates should have been established as part of the initial ISPW implementation. The training given to new ISPW Administrators should cover their role and required activities when implementing ISPW product updates. This will vary according to the established local procedures. The information in this section is intended only as a general guide. It is important that any ISPW maintenance activity adhere to locally-established procedures.

The group or service provider responsible for the ISPW z/OS product installation will receive and apply the base software updates. Typically, the base software datasets managed by SMP/E will not be used directly by your ISPW environments. This will depend on the process adopted for managing ISPW base software updates.

For each new version or PTF, the ISPW Administrator will need to follow a process that includes:

• Checking for the existence of any SITE versions
• Resolving change impacts for SITE versions
• Implementing the new SITE versions
• Keeping code in sync.

Check for Existence of Any SITE Versions

For smaller upgrades, this can be accomplished by comparing the list of components delivered to the list of components in the SITE application. For larger upgrades or new releases, it may be necessary to compare the new base datasets with the previous version, along with the SITE application datasets. Identify where any base components have changed that also exist in the SITE application.

Note that there are different ways that customization may have been done:

• Components customized from the ISPW base software datasets (REXX/CLIST, ISPF panels/skeletons/messages). Some components in these base datasets are expected to have local customization. They are copied to the SITE application for the customization to be made, then implemented using the SITE application lifecycle. If such components are in the SITE application, they will contain some local change—otherwise they would not be required in the SITE datasets.
• Components implemented/customized from samples in the ISPW base SAMPLIB dataset. Many product features are provided with samples (REXX, ISPF panels/skeletons/messages, and JCL). Those samples would be imported to the SITE application and, in some cases, may not require any local changes. They would just need to be in the SITE datasets to be available to the ISPW runtime environment. Depending on the ISPW implementation at your site, the names used in the SITE application may also be different from the supplied samples.

Resolve Change Impacts for SITE Versions

If your SITE application has a version of a base component or sample received in an update, the update changes will need to be reviewed and incorporated into the SITE application version as part of the maintenance process. This could be done by a three-way compare of the previous base version, the new base version, and the current SITE version. It could also be done by comparing the SITE version to the current base, in conjunction with comparing the current and previous base versions.

If a new sample is simply copied to the SITE datasets without any changes (to quickly make it available, for instance), the new version can just be imported into the SITE application. If the SITE version contained changes, it might be easier—depending on the scale of the differences—to import the new version and reapply the local changes, or to check out the version in the SITE application and apply the new base version changes. Compuware’s Topaz Workbench, with its compare/merge capabilities, can make this process simpler. You may also utilize the merge feature in the ISPF PDF editor.

Implementing the New SITE Versions

After any impacts in the SITE application have been identified (and if necessary resolved by adding new SITE versions), the SITE application lifecycle can be used to promote those SITE changes to production. How the SITE application is used and made available in any given ISPW environment will depend on the local procedures established as part of the ISPWimplementation. It is very important that any base software changes being made active for a given ISPW environment occur in careful coordination with any required SITE changes.

Keeping Code in Sync

Not every PTF will be essential for every installation. Applying those PTFs might still be necessary, however, because they can include updates to components that are generally used. If such a PTF isn’t applied, and a later PTF also updates the same component, SMP/E will prompt you to apply the previous PTF. Also, the PTF may update (for example) a REXX program. If that program is in the SITE application and the updates aren’t applied, subsequent updates to that program will be more difficult to apply. There will be more source code differences because the latest maintenance will include all the updated code, and the local version may be missing updates.