You are on page 1of 134

Availability Guide for Change Management

Abstract

This manual explains how to maximize system and application availability while successfully implementing changes to your NonStop system. It describes typical changes and their causes, explains how to change your NonStop system while it is still operational, and shows you how to reduce the time required for planned outages.

Product Version N.A.

Supported Releases

This manual supports G01.00 and all subsequent G-series releases until otherwise indicated in a new edition.

Part Number

Published

Release ID

125506 December 1996

G01.00

Document History

Part Number

Product Version

Published

103394

N.A.

December 1994

119224

N.A.

December 1995

125506

N.A.

December 1996

New editions incorporate any updates issued since the previous edition. A plus sign (+) after a release ID indicates that this manual describes function added to the base release, either by an interim product modification (IPM) or by a new product version on a .99 site update tape (SUT).

Ordering Information

For manual ordering information: domestic U.S. customers, call 1-800-243-6886; international customers, contact your local sales representative.

Document Disclaimer

Information contained in a manual is subject to change without notice. Please check with your authorized Tandem representative to make sure you have the most recent information.

Export Statement

Export of the information contained in this manual may require authorization from the U.S. Department of Commerce.

Examples

Examples and sample programs are for illustration only and may not be suited for your particular purpose. Tandem does not warrant, guarantee, or make any representations regarding the use or the results of the use of any examples or sample programs in any documentation. You should verify the applicability of any example or sample program before placing the software into productive use.

U.S. Government Customers

FOR U.S. GOVERNMENT CUSTOMERS REGARDING THIS DOCUMENTATION AND THE ASSOCIATED SOFTWARE:

These notices shall be marked on any reproduction of this data, in whole or in part. NOTICE: Notwithstanding any other lease or license that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Section 52.227-19 of the FARS Computer Software—Restricted Rights clause. RESTRICTED RIGHTS NOTICE: Use, duplication, or disclosure by the Government is subject to the restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.227-7013. RESTRICTED RIGHTS LEGEND: Use, duplication or disclosure by the Government is subject to restrictions as set forth in paragraphþ(b)(3)(B) of the rights in Technical Data and Computer Software clause in DAR 7-104.9(a). This computer software is submitted with “restricted rights.” Use, duplication or disclosure is subject to the restrictions as set forth in NASA FARþSUP 18-52þ227-79 (Aprilþ1985) “Commercial Computer Software—Restricted Rights (Aprilþ1985).” If the contract contains the Clause at 18-52þ227-74 “Rights in Data General” then the “Alternate III” clause applies. U.S. Government Users Restricted Rights — Use, duplication or disclosure restricted by GSA ADP Schedule Contract. Unpublished — All rights reserved under the Copyright Laws of the United States.

New and Changed Information

The Availability Guide for Change Management manual has been revised to reflect changes for G01:

Product/Feature/Enhancement

CMI and CMP are replaced by SCF on G-series systems:

Where CMI and CMP are described, replace with SCF descriptions.

Where CMI and CMP examples are shown, replace with SCF examples.

Remove CMI and CMP from list of change management tools.

COUP is replaced by SCF on G-series systems:

Where COUP is described, replace with SCF descriptions.

Where COUP examples are shown, replace with SCF examples.

Remove COUP from list of change management tools.

PUP and DSC are replaced by SCF on G-series systems:

Where PUP and DSC are described, replace with SCF descriptions.

Where PUP and DSC examples are shown, replace with SCF examples.

Enhance description of SCF in the change management tools list to describe the new functionality for G-series systems, remove PUP and DSC.

Sections Affected

Sections 3, 5, and 7

Sections 3, 5, and 7

Sections 1, 3, 5, and 7

Availability Guide for Change Management–125506

iii

New and Changed Information

Product/Feature/Enhancement

Install is replaced by DSM/SCM (Delphi) on G-series:

Where Install is described, replace with DSM/SCM.

Where Install examples are shown, replace with DSM/SCM.

Add DSM/SCM to the list of change management tools, and remove Install.

NonStop Net/Master and RDF will not be in G01:

Where NonStop Net/Master and RDF are described, remove references.

Where NonStop Net/Master and RDF examples are shown, remove references.

Remove from list of change management tools.

TMDS replaced by TSM on G-series:

Where TMDS is described, replace with TSM.

Where TMDS examples are shown, replace with TSM.

Add TSM to the list of change management tools, and remove TMDS.

Sections Affected

Sections 1, 3, and 6

Sections 4, 5, and 6

Sections 3 and 7

Availability Guide for Change Management–125506

iv

Contents

New and Changed Information

About This Manual

Notation Conventions

xi

xv

iii

1. Introduction to Change Management

Overview 1-1 What Causes Change?

1-1

Change and the Cost of Downtime

Increasing Availability by Effectively Managing Change

1-1

What Is Change Management?

Anticipating and Planning for Change Controlling the Introduction of Change Installing and Implementing Changes

Meeting the Goals of Change Management

1-2

1-2

1-3

1-3

1-5

Making Changes Online

Reducing the Time Required for Planned Outages

1-5

Measuring Outages

1-6

Measuring Outages by Outage Minutes

1-7

1-6

1-2

Measuring User Outage Minutes in a Client/Server Environment

Alternate Ways of Measuring Outages Change Management and the OM Model

1-7

1-8

2. Change Control

Overview 2-1 What Is Change Control?

Implementing Change Control Successfully

The Change-Control Process

2-1

2-2

Phase 1—Definition and Documentation

Phase 2—Change Planning Phase 3—Implementation

2-6

2-9

Phase 4—Verification Process Flow Diagram

Phase 4—Verification Process Flow Diagram

2-9

2-10

2-2

2-3

1-7

3. Making System Software and Hardware Changes Online

Overview 3-1 System Software Changes

3-1

Software Configuration Changes

Installing a New Operating System Release

3-1

3-2

Availability Guide for Change Management–125506

v

Contents

4.

Making Application Subsystem Changes Online

Installing an IPM Hardware Changes

Performing Common Hardware Changes Online

3-2

3-2

3-2

Online Changes That Require Tandem Assistance

3-3

Adding and Upgrading Processors Online

3-3

Adding and Upgrading Processor Memory Online

3-4

ServerNet Adapters

Adding, Upgrading, and Moving Disk Drives Online

3-4

Updating Firmware Online Where to Find More Information

3-6

3-7

3-5

4. Making Application Subsystem Changes Online

Overview 4-1 Overview of the Tandem Application Environment

4-1

Transaction-Processing Core Services

The Transaction-Processing Application Environments

Client/Server Computing and the Tandem Application Environment

4-1

4-2

Making Changes to NonStop TS/MP Online

Overview of NonStop TS/MP

4-5

4-5

4-3

NonStop TS/MP Changes You Can Perform Online

4-6

Where to Find More Information

4-8

Making Changes to NonStop SQL/MP Online

4-9

 

Overview of NonStop SQL/MP

4-9

NonStop SQL/MP in the Client/Server Environment

4-11

NonStop SQL/MP Changes You Can Perform Online

4-12

Where to Find More Information

4-15

Making Changes to NonStop TM/MP Online

Overview of NonStop TM/MP

4-16

4-16

NonStop TM/MP in the Client/Server Environment

4-17

TMF Subsystem Changes You Can Perform Online

4-18

Where to Find More Information

4-21

Making Changes to Transaction-Processing Monitoring Environments Online

The NonStop TUXEDO Environment

The Pathway Environment

4-25

4-22

4-22

5. Making Communications Subsystem Changes Online

Overview 5-1 Overview of Communications Subsystems

I/O Processes

5-1

5-1

Overview of Communications Products

5-3

Availability Guide for Change Management–125506

vi

Contents

6.

Reducing the Time Required for Planned Outages

Expand 5-3 Device-Specific Connections SNA Network Connections OSI Network Connections

LAN Connections

TCP/IP Network Connections

5-3

5-3

5-3

5-4

5-4

Common Communications Subsystem Changes

5-4

Changes You Can Perform Online Communications Subsystem Tool

Changes You Can Perform Online Communications Subsystem Tool

5-4

5-4

Communications Subsystems Summary

Where to Find More Information

5-7

5-5

6. Reducing the Time Required for Planned Outages

Overview 6-1 Minimizing the Frequency of Planned Outages

Anticipating and Planning for Change Can the Change Be Performed Online?

Reducing System and Application Startup and Shutdown Time Writing Efficient Startup and Shutdown Command Files

6-1

6-1

6-4

Using Parallel Processing

Product-Specific Techniques

6-6

6-7

Reducing Downtime When Installing a New Operating System

Testing Your Plans

6-8

Reducing Application Downtime With DSM/SCM

6-10

6-9

7. Tools for Online Change

Overview 7-1 Subsystem Control Facility (SCF)

SCF Interface

How SCF Works

7-1

7-2

7-1

6-4

6-4

6-8

SCF Subsystems for G-Series Releases

7-3

Considerations and Limitations of SCF

7-4

SCF Command Example

7-5

Where to Find More Information

7-5

Tandem Service Management (TSM)

7-5

TSM Interface

TSM Components Incident Reports

TSM EMS Event Viewer

7-6

7-6

7-8

7-9

Availability Guide for Change Management–125506

vii

Contents

Where to Find More Information NonStop TS/MP Management Tools

Where to Find More Information NonStop TS/MP Management Tools

7-9

7-9

NonStop TS/MP Management Interfaces

How the NonStop TS/MP Management Interfaces Work

Considerations and Limitations of the NonStop TS/MP and Pathway/TS

7-10

7-10

7-11

PATHCOM Command Example Where to Find More Information NonStop SQL/MP Management Tools

Management Interfaces

7-11

7-12

7-12

Glossary

NonStop SQL/MP Management Interfaces

7-12

How SQLCI Works

7-12

Considerations and Limitations of SQLCI

7-13

SQLCI Example

7-13

 

Where to Find More Information

7-13

NonStop TM/MP Management Tools

7-14

TMF Subsystem Management Interfaces

7-14

How the TMF Subsystem Management Interfaces Work

Considerations and Limitations of the TMF Management Interfaces

TMFCOM Command Example Where to Find More Information

7-14

7-15

7-15

Glossary

Index

Figures

7-15

Figure 2-1.

Planned Outage Request Form

2-5

Figure 2-2.

Change-Control Process Flow

2-11

Figure 4-1.

The Tandem Application Environment

4-3

 

Figure 4-2.

A Traditional NonStop SQL/MP Database System

4-10

Figure 4-3.

NonStop SQL/MP in the Client/Server Environment

4-11

Figure 4-4.

The TMF Subsystem in a Traditional Transaction-Processing

4-23

Figure 4-5.

Environment 4-17 NonStop TUXEDO Transaction-Processing Environment

Figure 4-6.

Pathway Transaction-Processing Environment

4-26

Figure 5-1.

User Process Communicates With I/O Process

5-2

Figure 7-1.

How SCF Works

7-2

Figure 7-2.

How the Pathway Management Interfaces Work

7-11

 

Figure 7-3.

How SQLCI Works

7-13

Figure 7-4.

TMFCOM and Management Application Program Interfaces

7-15

Tables

Availability Guide for Change Management–125506

viii

Contents

Table 1-1.

Outage Minutes per Year (24-Hour by 7-Day by Year-Round Clock)

1-

7

Table 3-1.

Where to Find System-Specific Installation and Configuration Information 3-8

 

Table 3-2.

Where to Find Additional Configuration Information

3-8

Table 4-1.

PATHMON Object Changes

4-7

Table 4-2.

Summary of NonStop TS/MP Changes

4-8

 

Table 4-3.

Audit-Trail Configuration Changes

4-18

4-19

Table 4-4.

Data-Volume Configuration Changes

Table 4-5.

Autoabort Configuration Changes

4-19

Table 4-6.

Audit-Dump Configuration Changes

4-20

 

Table 4-7.

TMF Catalog Configuration and Entry Changes

4-20

 

Table 4-8.

Summary of TMF Changes

4-21

Table 5-1.

Summary of SCF-Supported Communications Subsystems

5-5

Table 6-1.

Performance-Management Tasks

6-2

Table 6-2.

Tools for Evaluating System Performance and Growth

6-2

Table 6-3.

Where to Find Information About Online Change

6-4

Table 7-1.

SCF Online Reconfiguration Commands

7-2

 

Availability Guide for Change Management–125506

ix

Contents

Availability Guide for Change Management–125506

x

About This Manual

The Availability Guide for Change Management explains how to maximize system and application availability while successfully implementing changes to your NonStop system. This manual will:

Describe and recommend a process for managing change in the Tandem environment

Identify typical changes and their causes and show you how to implement these changes in the Tandem environment

Describe system software, hardware, application subsystem, and communications subsystem changes that you can perform without shutting down your NonStop system

Describe ways you can reduce the time needed to make changes that require your NonStop system to be shut down

Identify the tools provided by Tandem that enable you to make changes to your NonStop system while it is still running

Who Should Read This Manual?

The intended audience for this manual is anyone responsible for planning and supporting the management of NonStop systems. The following table identifies some typical readers and the kind of information they may look for in this manual.

These kind of readers

Operations managers

Configuration planners, support planners, and installers

Look for this kind of information

Types of products offered by Tandem for change management How the various products “fit together”

System and application startup and shutdown procedures System installation planning Change control process management New hardware and software implementation planning New operating system release installation planning Hardware and software evaluation and selection Configuration changes that can be performed online

This manual assumes that the reader has worked with NonStop systems before and is familiar with operations management and the system generation process.

Availability Guide for Change Management–125506

xi

About This Manual

What’s in This Manual?

What’s in This Manual?

This manual is organized in seven sections and a glossary. The glossary defines technical terms and acronyms.

Section 1, “Introduction to Change Management,” describes the factors that cause change, defines change management in the Tandem environment, describes the goals of change management, explains how Tandem measures outages, and shows how change management relates to the operations management (OM) model.

Section 2, “Change Control,” defines change control, shows how change control affects system and application availability, describes the requirements for successfully implementing a change control process, and outlines the phases of the change control process.

Section 3, “Making System Software and Hardware Changes Online,” describes the online reconfiguration capabilities of Subsystem Control Facility (SCF), explains how you can configure your system to accommodate future growth, identifies hardware changes that can be performed without taking your NonStop system down, and shows you how to install interim product modifications (IPMs) for certain products without performing a system load.

Section 4, “Making Application Subsystem Changes Online,” identifies the changes you can perform to NonStop Transaction Services/Massively Parallel (TS/MP), NonStop Structured Query Language/Massively Parallel (SQL/MP), and NonStop Transaction Manager/MP (TM/MP) without taking your NonStop system down. It also discusses making online changes to the NonStop TUXEDO, and Pathway transaction monitor environments these core services support.

Section 5, “Making Communications Subsystem Changes Online,” identifies common communications subsystem changes and the tools you use to perform those changes without taking your NonStop system down.

Section 6, “Reducing the Time Required for Planned Outages,” shows you how to minimize the frequency of planned outages, describes techniques you can use to reduce system and application startup and shutdown time, and explains how you can reduce the time required to install a new version of the operating system.

Section 7, “Tools for Online Change,” describes the features and capabilities of SCF, Tandem Service Management (TSM), and the NonStop TS/MP, NonStop SQL/MP, and NonStop TM/MP management tools.

Availability Guide for Change Management–125506

xii

About This Manual

Where to Find More Information

Where to Find More Information

The following manuals contain information that may also be of interest to readers of this manual:

The Introduction to NonStop Operations Management introduces managers to NonStop system operations. It provides guidelines, suggestions, and ideas on the following topics: staffing, operations and support areas, operations documentation, production management, problem management, change management, configuration management, performance management, security management, application management, automating and centralizing operations, and improving operations management processes. This manual is a prerequisite for reading other Tandem operations manuals.

The Introduction to Tandem NonStop Systems introduces you to the computing environment of Tandem NonStop systems. It describes the online transaction- processing (OLTP) requirements that the NonStop system was designed to meet and shows how the three layers of the NonStop system (the application environment, architecture, and networking) provide a unique and comprehensive solution to the challenges of OLTP.

The Introduction to Tandem Networking and Data Communications provides an overview of Tandem networking and data communications concepts, tasks, products, and manuals and discusses ways to connect Tandem systems to various devices and networks.

The Availability Guide for Problem Management provides information to help you implement a problem management process and use Tandem tools to eliminate or reduce unplanned outages.

The Availability Guide for Performance Management explains how to measure system performance, analyze system performance information, and optimize the performance of Tandem NonStop systems.

The Availability Guide for Application Design provides an overview of application availability options available to designers and developers.

The Security Management Guide provides information to help you manage system security issues such as identification of users, proper access to data and system resources, encryption of data, and administration of the security process.

Other related documents are referred to in various sections throughout this manual.

Availability Guide for Change Management–125506

xiii

About This Manual

Your Comments Invited

Your Comments Invited

After using this manual, please take a moment to send us your comments. You can do this by returning a Reader Comment Card or by sending an Internet mail message.

A Reader Comment Card is located at the back of printed manuals and as a separate file

on the Tandem User Documentation disc of the Tandem Information Manager (TIM) product. You can either FAX or mail the card to us. The FAX number and mailing

address are provided on the card.

Also provided on the Reader Comment Card is an Internet mail address. When you send an Internet mail message to us, we immediately acknowledge receipt of your message. A detailed response to your message is sent as soon as possible. Be sure to

include your name, company name, address, and phone number in your message. If your comments are specific to a particular manual, also include the part number and title

of the manual.

Many of the improvements you see in Tandem manuals are a result of suggestions from our customers. Please take this opportunity to help us improve future manuals.

Availability Guide for Change Management–125506

xiv

Notation Conventions

General Notation

Boldface type is used to set off definitions of technical terms and acronyms.

Syntax Notation

The following list summarizes the notation conventions for syntax presentation in this manual.

UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example:

MAXATTACH

lowercase italic letters. Lowercase italic letters indicate variable items that you supply. Items not enclosed in brackets are required. For example:

file-name

Availability Guide for Change Management–125506

xv

Notation Conventions

Syntax Notation

Availability Guide for Change Management–125506

xvi

1

Introduction to Change

Management

Overview

Businesses today are facing an ever-increasing rate of change worldwide. To succeed in this rapidly changing environment, businesses must develop a risk-driven strategy where change is assessed, mastered, controlled, and used to improve the competitiveness of the business. Change should no longer be viewed as something that should be minimized or avoided—it should be seen as a process that can be used to succeed.

This section:

Describes the factors that cause change

Defines change management in the Tandem environment

Describes the goals of change management

Explains how Tandem measures outages

Shows how change management relates to the operations-management (OM) model

What Causes Change?

In almost every industry, businesses have to deal with changing market conditions, increased competition, and new technological opportunities. The following situations illustrate some common causes of change:

Business growth or downsizing causes an increase or decrease in demand over or under existing capacity.

New applications and functions result in increased processing demand.

Existing technology becomes obsolete and must be replaced with new technology.

Existing systems must be integrated with new systems, workstations, or networks.

Existing software or hardware must be replaced to reduce costs.

Product fixes or upgrades become available.

Change and the Cost of Downtime

Customer service, while always important to business success, has become a competitive differentiator in industries where pricing and quality differences are minimal. In companies where customer service reigns, the customer—not the business—determines when, where, and how services should be provided. Customers want the freedom to conduct business when it is convenient, from wherever they happen to be, using whichever tools are available.

Availability Guide for Change Management–125506

1-1

Introduction to Change Management

Increasing Availability by Effectively Managing Change

Offering services around the clock requires computer and network services that are available all the time. The cost of downtime, even a few minutes, can be dramatic in lost revenue, lost consumer confidence, and lost productivity. The following are some examples of lost revenue caused by computer downtime:

When an airline’s reservation system went down, thousands of travel agents had to book flights manually. The estimated revenue impact from lost reservations (or reservations made with other airlines) amounted to $36,000 per minute.

After a bomb exploded in the New York World Trade Center in 1993, one of the Japanese banks in the building estimated lost revenues of $20,000,000 per day, or $2,500 per minute.

Lost consumer confidence, while more difficult to assess than lost revenue during a specific outage, can also cause revenue reductions over time because of damage to reputation. Finally, lost productivity, management dissatisfaction, and overtime costs can be even more costly than lost revenue.

Increasing Availability by Effectively Managing Change

As businesses attempt to provide services around the clock, being able to change systems and applications with minimal or no impact on end-user availability is becoming increasingly important. The following subsection explains how you can maximize system and application availability by effectively managing change.

What Is Change Management?

Change management is the process of managing the maintenance and growth of your NonStop system. Change management involves managing all hardware, software, and procedural changes and includes all of the tasks required to properly manage change within the operations environment.

Major change-management tasks include:

Anticipating and planning for change

Controlling the introduction of change

Installing and implementing changes to system software and hardware, application subsystems, communications subsystems, and application software

Anticipating and Planning for Change

Anticipating and planning for change is a key requirement for maintaining 24-hour-a- day, 7-day-a-week, 365-day-a-year operations. You can anticipate and plan for change by:

Evaluating system performance and growth

Providing adequate computer room resources

Configuring your system with change in mind

Availability Guide for Change Management–125506

1-2

Introduction to Change Management

Controlling the Introduction of Change

Evaluating System Performance and Growth

Evaluating system performance and growth involves tracking and anticipating growth and then establishing plans to accommodate that growth. Tandem provides a wide variety of tools that provide data useful for your growth forecasts. These tools, and performance-management tasks, are described in the Introduction to NonStop Operations Management.

Providing Adequate Computer Room Resources

Some changes, such as adding new hardware, can require more power and air conditioning. You can avoid unnecessary downtime by providing adequate physical space and ensuring that you have enough power and cooling capacity for additional equipment. Assessing resource requirements is described in Section 2, “Change Control.”

Configuring Your System With Change in Mind

Some changes can be performed online only if you have designed your system configuration to accommodate them ahead of time. Section 3, “Making System Software and Hardware Changes Online,” describes how you can avoid taking your system down to add new hardware. Anticipating and planning for change are discussed in Section 6, “Reducing the Time Required for Planned Outages.”

Controlling the Introduction of Change

Regardless of the type of change you need to make, you should establish and use a formal change-control process to ensure that changes proceed smoothly and with minimal impact on system and application availability.

Change control is a process for proposing, planning, implementing, and testing change and is a key requirement for minimizing the impact of change on system and application availability. Change control is also an important part of maintaining the security of your system and applications.

Section 2, “Change Control,” describes and recommends a four-phase change-control process to help you ensure that changes are implemented successfully and with minimal impact on system and application availability.

Installing and Implementing Changes

Installing and implementing changes to your NonStop system can involve:

Installing a new operating system release

Installing an Interim Product Modification (IPM)

Adding, removing, and reconfiguring hardware

Installing and reconfiguring application subsystems

Installing and reconfiguring communications subsystems

Installing and reconfiguring applications

Availability Guide for Change Management–125506

1-3

Introduction to Change Management

Installing and Implementing Changes

Installing a New Operating System Release

Tandem currently requires that you shut down your NonStop system to install any major operating system release. You use the Distributed Systems Management/ Software Configuration Manager (DSM/SCM) program to install a new version of the operating system.

Section 6, “Reducing the Time Required for Planned Outages,” describes several techniques you can use to reduce the time required to install a new operating system and thus minimize the impact of this type of change on application availability.

Installing an IPM

An IPM may contain code that adds function to a Tandem software product, or, it may include one or more fixes to Tandem code. IPM installation may have a minimal impact on system and application availability, or it may require you to shut down your system. You use the DSM/SCM product to install IPMs.

How much impact IPM installation will have on availability depends on the particular IPM being installed. Section 3, “Making System Software and Hardware Changes Online,” describes techniques you can use to reduce the impact of IPM installation on system and application availability.

Adding, Removing, and Reconfiguring Hardware

Changing your system hardware can involve expanding your system to include a new system component, upgrading a system component to take advantage of a new technology, or simply moving an existing system component. Many hardware changes can be performed while your NonStop system is still operational.

Section 3, “Making System Software and Hardware Changes Online,” identifies the hardware changes you can perform without having to shut down your system and identifies changes you can make online using SCF.

Installing and Reconfiguring Application Subsystems

The Tandem application environment consists of application subsystems that enable you to develop and run high-performance, high-volume, and highly available OLTP applications. The application subsystems that make up the Tandem application environment include NonStop TS/MP, NonStop SQL/MP, and NonStop TM/MP.

Making changes in your application environment can involve adding new requester and server programs to handle new types of transactions, reorganizing a database to accommodate business growth, or reconfiguring certain configuration attributes. Because Tandem designed its application environment to expand easily as OLTP operations evolve and business needs change, application subsystem changes do not require your NonStop system to be shut down, and most changes can be made without affecting application availability.

Section 4, “Making Application Subsystem Changes Online,” identifies the changes you can perform to application subsystems while your NonStop system is still operational, and describes the impact of those changes on application availability.

Availability Guide for Change Management–125506

1-4

Introduction to Change Management

Meeting the Goals of Change Management

Installing and Reconfiguring Communications Subsystems

In the Tandem environment, a software product that provides users with access to a set of communications services is called a communications subsystem. Making changes to a communications subsystem can involve adding new communications lines or devices to accommodate business growth, connecting new systems to the network, or reconfiguring certain configuration attributes.

Section 5, “Making Communications Subsystem Changes Online,” identifies common communications subsystem changes and describes the tools you can use to perform those changes while your NonStop system remains operational.

Installing and Reconfiguring Applications

This manual does not discuss how to make changes to customer applications.

Meeting the Goals of Change Management

The main goal of change management is to minimize the impact of change on system and application availability while successfully migrating your system or application from one stable configuration to another. Successful change management also ensures that system and application security is maintained during the change process.

You can meet the goals of change management by:

Performing changes online

Reducing the time required for planned outages

Making Changes Online

Being able to make changes online is one way you can reduce—or even eliminate— system and application downtime caused by change. Online change is any change that can be performed while your NonStop system is still operational.

The following sections describe how to make changes online:

Section 3, “Making System Software and Hardware Changes Online,” explains how to make changes to your system software and hardware online.

Section 4, “Making Application Subsystem Changes Online,” explains how to make changes to NonStop TS/MP, NonStop SQL/MP, and NonStop TM/MP online.

Section 5, “Making Communications Subsystem Changes Online,” explains how to make changes to communications subsystems online.

In some situations, online changes may temporarily affect application availability. For example, altering the characteristics of a communications line may temporarily affect applications that use that communications line. Sections 3, 4, and 5 describe online changes that affect application availability and how you can reduce the impact of these changes on application availability.

Availability Guide for Change Management–125506

1-5

Introduction to Change Management

Reducing the Time Required for Planned Outages

Reducing the Time Required for Planned Outages

An outage is time during which your NonStop system is not capable of doing useful work. From the end-user’s perspective, an outage is any time an application is not available.

Outage Classes

Outages fall into the following classes:

Physical

Design

Operations

Environmental

Reconfiguration

Unplanned Outages

The first four industry-standard outage classes describe unplanned outages. An unplanned outage is system or application downtime caused by a problem such as faulty hardware, operator error, disaster, and so forth. Unplanned outages—and how to predict, prevent, and prepare for them—are described in the Availability Guide for Problem Management.

Planned or Reconfiguration Outages

The reconfiguration outage class includes all planned outages. A planned outage is system or application downtime that is planned or scheduled.

A reconfiguration outage might occur for an incremental reconfiguration, such as adding a disk or a communication line, or for massive reconfiguration, such as migrating from a complex instruction set computing (CISC) system to a reduced instruction set computing (RISC) system, from a C-series operating system release to the D-series, or from one version of an application to another.

Your NonStop system is designed so that most changes can be performed while the system and applications are still operational. However, certain changes must be done offline. Offline change is any change that requires your NonStop system to be shut down. Offline changes—as well as online changes that affect application availability— are the typical causes of planned outages.

Section 2, “Change Control,” explains how you can ensure that planned outages proceed smoothly by establishing a formal change-control process. Section 6, “Reducing the Time Required for Planned Outages,” describes several techniques you can use to reduce the time required for planned outages.

Measuring Outages

Tandem believes that the measurement of availability should be from the end-user’s perspective. For example, it is not enough simply to record that a certain hardware or software component has gone down; you must also take into consideration the user’s

Availability Guide for Change Management–125506

1-6

Introduction to Change Management

Measuring Outages by Outage Minutes

ability to access the service, the quality of the service provided, and the acceptability of the response time to the user.

While major changes—such as installing a new operating system release—obviously affect availability, the effect of other types of changes may be less apparent but can also affect end-user availability. For example, changing the characteristics of a communications line could cause response time to become unacceptable to an end-user who is trying to access a file on a remote system at the same time that the change is being performed.

Measuring Outages by Outage Minutes

While the computer industry has typically measured availability in percentages, Tandem recommends measuring availability by outage minutes, assuming a 24-hour by 7-day by year-round clock. Using an outage-minutes-per-year measurement is easy to understand and provides more meaningful data than percentile numbers such as “95 percent available.”

Table 1-1 compares percentages with equivalent outage minutes and the resulting user impact.

Table 1-1. Outage Minutes per Year (24-Hour by 7-Day by Year-Round Clock)

Percent

Availability

90%

99%

99.9%

99.99%

99.999%

100%

Outage

Minutes/Year*

50,000

5,000

500

50

5

0

User Impact*

35 days

3.5 days

8.3 hours

50 minutes

5 minutes

0 minutes

*Outage minutes per year and user impact days are approximations.

Measuring User Outage Minutes in a Client/Server Environment

For client/server types of applications, it is useful to express downtime as the number of user outage minutes. A failure in the client part of the application might affect only one user; but to that user, the application is down. A failure in part of the network could affect several users. A failure in the server, however, could affect thousands of users. It is therefore important that an outage in the server be weighted over an outage in the client.

In a client/server environment, it therefore makes sense to measure downtime as the number of minutes the application is unavailable multiplied by the number of affected users. A one-minute outage in the workstation equals one minute of downtime. An outage of one minute in the server, however, equals one minute times the number of users accessing the server.

Alternate Ways of Measuring Outages

Depending on specific business needs, downtime may be measured in ways other than user outage minutes. For example, a site might be obligated to pay a penalty for each transaction that does not get processed while an application is down. Such a site might

Availability Guide for Change Management–125506

1-7

Introduction to Change Management

Change Management and the OM Model

supplement its measure of downtime by keeping records of the number of transactions it normally processes by minute and by day of the week. If an outage occurs, for example, at 10 a.m. on Tuesday morning and lasts for 15 minutes, the site can calculate the average number of transactions that would normally be processed during that period. Subsequently, the site pays a corresponding penalty to its customer.

Using this method leads to significantly different outage costs depending on the time of day and the day of the week. An hour-long outage at 2 a.m. on Monday morning might carry a negligible penalty when compared with a 15-minute outage at 5 p.m. on a Friday.

Change Management and the OM Model

Change management is one of the operations-management “disciplines” defined in Tandem’s OM model. The OM model categorizes functions of the operations environment into six industry-standard disciplines. In addition to change management, the OM model consists of the following disciplines:

Production management—includes the day-to-day tasks performed by operations personnel who operate and manage the production environment

Problem management—includes the tasks required to manage and administer the problem environment

Configuration management—includes the tasks required to manage and administer the configuration of system software and hardware, application subsystems, communications subsystems, and application software

Security management—includes the security features necessary to implement a secure, audited, operations environment

Performance management—includes the tasks involved with measuring system performance, analyzing system-performance information, and optimizing the performance of your NonStop system

Change management and configuration management are interrelated functions. Configuration management includes the tasks required to manage and administrate the configuration of system software and hardware, application subsystems, communications subsystems, and application software. Configuration-management functions include inventory control, version control, software distribution, and name management.

The following manuals describe various aspects of the OM model:

The Introduction to NonStop Operations Management describes the OM model and provides an overview of each of the OM disciplines.

The Availability Guide for Problem Management describes unplanned outages and how to predict, prevent, prepare for, and recover from them.

The Availability Guide for Change Management (this manual) describes how to manage the maintenance and growth of your NonStop system.

The Security Management Guide describes the security-performance discipline in detail.

Availability Guide for Change Management–125506

1-8

Introduction to Change Management

Change Management and the OM Model

The Availability Guide for Performance Management describes how to manage the performance of your NonStop system.

Availability Guide for Change Management–125506

1-9

Introduction to Change Management

Change Management and the OM Model

Availability Guide for Change Management–125506

1-10

2

Change Control

Overview

Making changes to your system and application environment can increase the effectiveness of your operations—or can result in confusion and problems. The difference between success and failure depends on how well your organization manages change. By establishing a formal change-control process, you can ensure that change proceeds smoothly and with minimal impact on system and application availability.

This section provides information to help you ensure that changes are implemented successfully. Topics described in this section include:

How Tandem defines change control

How change control affects system and application availability

The requirements for successfully implementing a change-control process

The phases of the change-control process

What Is Change Control?

Change control is the process for proposing, planning, implementing, and testing change and is a key requirement for minimizing the duration of planned outages (system or application downtime that is planned or scheduled). Change control ensures the successful migration of a system or application from one stable configuration to another by:

Ensuring that the scope and ramifications of the change are fully understood.

Thoroughly assessing the impact of change, determining what resources will be required to implement the change, and creating a plan for the change can help minimize planned outage time.

Providing a recovery plan.

A recovery plan with written instructions should be developed in case the change

does not work. Providing a recovery plan reduces planned outage time by ensuring that system operation can be quickly resumed if the change cannot be implemented successfully.

Ensuring that problems and errors are anticipated and reacted to appropriately.

A change plan should include a detailed sequence of events including “go/no go”

criteria and contingency plans at each step in case problems or errors occur.

Maintaining the security of your system and applications.

Controlling change is an important part of maintaining the security of your system and applications. If you do not control who makes changes and when, you may put your system’s security at risk. If there are no controls, frequent changes and changes by unauthorized personnel may damage the stability of your system.

Availability Guide for Change Management–125506

2-1

Change Control

Implementing Change Control Successfully

Implementing Change Control Successfully

Change control is most effective when the following prerequisites are met:

A single point of control exists in the form of a person or group with overall authority to implement change. Making a person or group responsible for change control prevents unauthorized personnel from accessing and changing the system.

The person or group responsible for implementing the change has received the proper training. Change-control personnel are most effective when they:

Know how to evaluate software quality assurance test results

Are able to negotiate with people

Are able to solve problems

Understand how changes may affect all parts of the system and operating procedures

All organizations necessary to support the change are committed to the plan and clearly understand the change process.

Continual process improvement is an integral part of the change-control process. Continual process improvement means applying what you have learned during one cycle of change to the next cycle of change and making improvements to the process accordingly. Some ways to make continual process improvement part of the change-control process include:

Taking baseline measurements of your system and application environments before you make changes, then measuring the impact of the change against your baseline measurements after you have implemented the change

Keeping track of how long it takes to implement changes

Knowing the common changes in your environment and the reasons for them

The Change-Control Process

This subsection describes and recommends a four-phase change-control process. The four phases are:

Phase 1—Definition and documentation. In this phase, the person or group responsible for change control formally defines the proposed change, makes sure that all requirements have been met, and documents the results of the change.

Phase 2—Change planning. In this phase, the person or group responsible for change control assesses the impact of the change, creates a plan to implement the change, and develops a recovery plan in case the change does not work.

Phase 3—Implementation. In this phase, the person or group responsible for change control implements the change according to the change plan created during the change- planning phase (phase 2).

Availability Guide for Change Management–125506

2-2

Change Control

Phase 1—Definition and Documentation

Phase 4—Verification. In this phase, the person or group responsible for change control makes sure that the system is running correctly and reviews the change-control process to make any necessary improvements.

The following paragraphs provide guidelines for accomplishing each phase of the change-control process. If you need tools for use in change control, your Tandem representative can direct you to the Tandem Alliance Program companies that offer change-control tools. Third-party change-control tools are also listed in the Alliance Solutions & Services Directory, which can be found on Tandem’s Web page at:

http://www.tandem.com/MENU_PGS/ALLIANCE/ALL_SSD.HTM.

Phase 1—Definition and Documentation

The first phase of the change-control process consists of determining what is to be changed and then formally defining the proposed change. Change can come from a variety of sources and can be caused by a variety of factors. Some of the items that can be changed in any production environment include hardware, communications lines, firmware, operating system code, application subsystems, application software code, and recovery and backup procedures. Section 1, “Introduction to Change Management,” describes common changes and their causes.

During the definition and documentation phase, you should collect the following information about the proposed change:

A detailed description of the proposed change

The deadline for the change

A list of files and documentation that must be changed

Why the proposed change is necessary

Some organizations use change-request forms to help define and document changes. Change-request forms are standardized online or hard-copy forms filled out by people requesting changes and presented to the person or group in charge of change control.

Using a Planned Outage Request Form

The impact of change on system and application availability can be nonexistent or can require your system or application to be shut down. For changes that affect system or application availability, a planned outage request form can be used to gather information about the change.

A planned outage request form helps set expectations and enables managers to understand the reasons for planned outages. A planned outage request form also provides historical data that can be used for trend analysis, which in turn can be used to determine where improvement opportunities exist. Trend analysis can help managers evaluate the effectiveness and accuracy of change plans, recovery plans, and downtime estimates.

A planned outage request form should include the following types of information:

The date and time of the planned outage.

Availability Guide for Change Management–125506

2-3

Change Control

Phase 1—Definition and Documentation

The estimated duration of the outage. (Tandem recommends that you measure outages in minutes. Section 1, “Introduction to Change Management,” describes how to measure outages in minutes.)

The reason for the outage.

The name of the person or group requesting the outage.

Applications affected by the outage.

Figure 2-1 shows an example of a planned outage request form.

Note. The maximum times on the following form are only examples. Times will vary from installation to installation and can depend on a number of factors, including the size of the configuration. You should modify this form based on your own needs and experience.

Availability Guide for Change Management–125506

2-4

Change Control

Phase 1—Definition and Documentation

Figure 2-1. Planned Outage Request Form

Planned Outage Request Form REQUESTED BY DATE REQUEST FORM SUBMITTED DATE OF OUTAGE TRACKING NUMBER
Planned Outage Request Form
REQUESTED BY
DATE REQUEST FORM SUBMITTED
DATE OF OUTAGE
TRACKING NUMBER
Maximum
Requested
Actual
(Minutes)
(Minutes)
(Minutes)
60
Application/system shutdown
Downtime work (move files, add
hardware, SQL compiles, etc.)
30
System load
30
System and subsystem startup
Application startup
60
cold start
30
warm start
Test application before
turning over to production
30
BRIEFLY DESCRIBE THE REASON FOR THE OUTAGE:
LIST APPLICATIONS THAT ARE AFFECTED:
LIST HARDWARE DEVICES THAT ARE AFFECTED:
IF THE PLANNED OUTAGE INVOLVES A COMPLEX CHANGE, DESCRIBE THE FALLBACK AND BACKOUT PROCEDURES.
INCLUDE STRICT "GO/ NO GO" CRITIERIA:

CDT 001

Availability Guide for Change Management–125506

2-5

Change Control

Phase 2—Change Planning

Phase 2Change Planning

One of the most difficult tasks in change control is determining how the change affects your system and application availability. If the change affects availability, you also need to determine how to minimize system or application downtime when implementing the change. Thoroughly assessing the impact of change, determining what resources are required to implement the change, and creating a plan for the change help minimize planned outage time.

The change planning phase involves the following tasks:

Assessing the impact of the proposed change

Identifying the resources required to implement the proposed change

Determining when to make the proposed change

Creating a change plan

Testing the change plan before implementing the change

Assessing the Impact of the Proposed Change

Assessing the impact of the proposed change involves the following tasks:

Determining what will be affected by the change and identifying dependencies. For example, application changes not only affect applications, but they also can have an affect on configuration files and command files.

Determining the scope of the proposed change. Does the same change need to be made on other systems in the network?

Identifying users, devices, and applications that may be affected by the change. You should contact all affected groups to inform them of the proposed change.

Identifying possible training requirements for staff and end users.

Ensuring that service level agreements are still met after the proposed change is implemented.

Determining what activities can be done online versus offline to minimize downtime.

Determining outage versus non-outage activities. For example, can you minimize downtime by performing certain activities before taking the system down?

Identifying resources required to manage and support the change once it is implemented. For example, the proposed change may require new run book procedures, operator messages, and so forth.

Identifying all contingency and backup requirements for the proposed change.

Availability Guide for Change Management125506

2-6

Change Control

Phase 2Change Planning

If the change was requested by another person or group (other than the person or group responsible for change control), the person or group responsible for change control should perform the following tasks:

Verify that the information provided about the proposed change is correct.

Submit a list of requirements to the person or group that requested the change. Requirements usually include the following:

All application changes should be tested on a development system to ensure that the changes work as described and do not disrupt the system. Determine who should test the changes (developers, a separate testing group, or operations staff) and ensure that some type of quality-control policy is established and adhered to.

All changes should pass user-acceptance testing.

All test results should be handed over to change control.

All affected documentation should be changed and given to change control for approval. Documentation includes new or changed error messages, new or changed procedures, updates to internal operator guides, and the names of changed or added files and the location of those files.

Users should verify and formally approve all data changes to ensure the integrity of production data.

All naming conventions and other company standards should be followed.

A recovery plan with written instructions should be developed in case the change does not work.

The requesting group should provide installation instructions if special procedures are needed.

After submitting a list of requirements to the requesting group, the person or group responsible for change control should make sure that the requirements are fulfilled before implementing the change.

Identifying Resources

Determining the answers to the following questions can help you identify the resources required to implement a proposed change:

Who are the user project team members and who is the team leader?

Who are the Tandem project team members and who is the team leader?

What is the availability of each of the team members?

What is the skill set required by each team member to perform the required tasks?

Is support required from Tandem or another vendor?

What tools are required to implement the change?

What level of commitment is needed to implement the change?

Do team members require any special training to implement the change?

Availability Guide for Change Management125506

2-7

Change Control

Phase 2Change Planning

Determining When to Make the Proposed Change

You can use the following check list to determine when to schedule the proposed change:

Can you, or should you, combine the proposed change with other planned outages to minimize planned downtime?

Which days of the week or time periods are or are not available for planned downtime? Are there certain days in the month that must be avoided?

What are the resource availability constraints and deadlines?

When is the time of least impact on system and application availability?

If this is a major change, can it be done in stages? For example, by separating major database changes and major functional changes to the system, the risk of damage to the database is minimized, and the ability to recover is simplified.

If the change must be made to multiple systems, should the systems be changed sequentially or simultaneously?

What are the time-dependent milestones? For example:

Are there lead times for equipment ordering, delivery, and installation that must be considered?

Is site preparation necessary for additional power, air conditioning, and communications lines?

Creating a Change Plan

A change plan is a detailed plan describing how the change will be implemented. A change plan should include the following:

A sequence of events, including “go/no go” criteria

A schedule for implementing the change

A contingency or recovery plan with written instructions in case the change does not work

Test and verification plans

Once the change plan is created, the person or group responsible for change control should solicit feedback and obtain management approval (with signatures) from all affected groups.

Availability Guide for Change Management125506

2-8

Change Control

Phase 3Implementation

Testing the Change Plan

All procedures should be tested before the change plan is implemented. Make sure that time is allowed to modify the plan based on the test results. Test activities should include:

Testing the plan on a “crash and burn” system (ideal), or walking through the plan with the implementation staff (next best alternative).

Testing outage minute estimates. This will help to ensure that the system downtime estimates conveyed to users are accurate.

Testing contingency and recovery plans.

Phase 3—Implementation

The change plan created during the change planning phase (phase 2) is implemented during the implementation phase. When implementing the change plan, make sure to consider the following guidelines:

Observe the “go/no go” criteria outlined in the change plan.

When using a team approach, ensure that all tasks are clearly assigned.

Ensure that each task is completed successfully.

Phase 4—Verification

The main goal of the verification phase is to ensure that the change was implemented successfully. The verification phase includes the following tasks:

Verify that the system is operating correctly. For example:

Run diagnostics and tests as required.

Ensure that hardware and software are functioning properly.

Make sure that all required processes are running.

Check response times and performance levels.

Monitor system status.

Distribute configuration change documentation to all functional groups.

Ensure that change dependencies are integrated into affected areas.

Verify that each functional group has tested and verified its area of responsibility (for example, all subsystem control files are updated and operational).

Ensure that all verified changes are reflected in your configuration documentation or configuration documentation database.

If a problem occurs during verification, perform the following tasks:

Determine the extent of the problem and the time needed to correct it.

If “go/no go” criteria are compromised, initiate the recovery plan created during the change planning phase (phase 2).

Collect problem information.

Availability Guide for Change Management125506

2-9

Change Control

Process Flow Diagram

After the change is successfully implemented and tested, the person or group responsible for change control should maintain records of the changes that took place, including all forms and signatures, and should document the results of the change.

Process Flow Diagram

Figure 2-2 is a high-level process flow diagram of how a change plan is implemented. The diagram assumes that the following two conditions are met:

There is a single point of control in the form of a person or group with overall authority to implement change.

All organizations necessary to support the change are committed to the plan.

Availability Guide for Change Management125506

2-10

Change Control

Process Flow Diagram

Figure 2-2. Change-Control Process Flow

Change Plan: - Sequence of events - Schedule - Contingency or recovery plan - Test
Change Plan:
- Sequence of events
- Schedule
- Contingency or recovery plan
- Test and verification plans
Start sequence
of events
Implement step
"No Go"
"Go/No Go"
Next step
decision points
Last step
Test and verification "OK"
Test and
verification
"OK"
points Last step Test and verification "OK" Not "OK" Contingency or recovery plan Stable

Not "OK"

Contingency or

recovery plan

"OK" Not "OK" Contingency or recovery plan Stable system - change implemented Stable system - change
Stable system - change implemented Stable system - change not implemented Perform postmortem, continuous improvement
Stable system - change
implemented
Stable system -
change not implemented
Perform postmortem,
continuous improvement

Availability Guide for Change Management125506

2-11

Change Control

Process Flow Diagram

Availability Guide for Change Management125506

2-12

3

Making System Software and

Hardware Changes Online

Overview

Being able to make changes to your system software and hardware online is one way you can reduce—or even eliminate—planned outages. Changing your system software and hardware can involve installing a new operating system release, expanding your system to include a new system component, upgrading a system component to take advantage of a new technology, or simply moving an existing system component.

This section provides information to help you reduce or eliminate planned outages by:

Explaining how you can configure your system to accommodate future growth.

Identifying system software changes that you can perform online. Online change is any change that can be performed while your NonStop system is still operational. In some situations, online changes may temporarily affect application availability.

Identifying the hardware changes that you can perform online and describing step- by-step procedures for making common hardware changes online.

Telling you which manuals contain more information about the changes described in this section.

System Software Changes

System software changes are changes to the operating system image that do not involve changes to the hardware. Types of system software changes include:

Software-configuration changes made in the configuration file. These types of changes include changing logical device names and configuration attributes.

Installing a new operating system release.

Installing an interim product modification (IPM).

Software Configuration Changes

You use the Subsystem Control Facility (SCF) on G-series systems to configure, control, and display information about configured objects within SCF subsystems. When you install a G-series release on a Himalaya S-series server, the $SYSTEM disk and a few other initial system-load processes are preconfigured and SYSGENR uses the CONFTEXT file to establish some system attributes for all processors. Then you finish the system configuration by using SCF.

SYSGENR configures a newly installed system or updates the system configuration when you install a new operating system release. Changes performed with SYSGENR are offline changes. SYSGENR is documented in the System Generation Manual for G-Series Releases.

Availability Guide for Change Management125506

3-1

Making System Software and Hardware Changes Online

Installing a New Operating System Release

SCF is Tandem’s online configuration and management tool used for configuring system objects or monitoring their status. Making changes to communications subsystems is discussed in Section 5, “Making Communications Subsystem Changes Online.” SCF is also described in Section 7, “Tools for Online Change.”

Installing a New Operating System Release

Tandem currently requires that you shut down your NonStop system to install any major operating system release. You use the Distributed Systems Management/Software Configuration Manager (DSM/SCM) product to install a new operating system release. Section 6, “Reducing the Time Required for Planned Outages,” explains techniques you can use to reduce the time required to install a new operating system release.

Installing an IPM

An IPM may contain code that adds new function to a Tandem software product or may include one or more fixes to Tandem code. You generally receive an IPM on a BACKUP tape or on your disk through a network connection. The IPM consists of the updated program and documentation files in one or more distribution subvolumes (DSVs). You use the DSM/SCM product to install IPMs.

Depending on the installation instructions listed in the IPM softdoc, IPM installation may have a minimal impact on availability, or it may require you to shut down your system and perform a system load.

Hardware Changes

Many hardware changes can be performed while your Tandem NonStop system is still operational. Although you can perform most of these changes without assistance from Tandem, some changes must be performed by a Tandem-trained customer engineer (CE) or system engineer (SE).

Performing Common Hardware Changes Online

You can usually perform the following hardware changes online without Tandem assistance:

Adding and upgrading processors

Adding and upgrading processor memory

Adding, upgrading, and moving controllers

Adding, upgrading, and moving disk drives

Adding peripheral devices such as terminals, printers, and tape devices

Updating firmware

For a complete list of customer-replaceable units (CRUs), refer to the installation and support documentation for your system. CRUs are designed to be installed and removed by Tandem customers while the system is operating. Installation and support manuals are listed in Table 3-1 on page 3-8.

Availability Guide for Change Management125506

3-2

Making System Software and Hardware Changes Online

Online Changes That Require Tandem Assistance

Online Changes That Require Tandem Assistance

With the proper planning, your Tandem CE or SE may be able to help you perform the following hardware changes online:

Adding, upgrading, and moving I/O expansion cabinets

Adding, upgrading, and moving system cabinets

Adding, upgrading, and moving external cabinets

If you would like more information on performing these types of hardware changes, contact your Tandem representative.

Note. System components that are installed in multichannel (MC-32) I/O cabinets on Himalaya servers must be removed and replaced only by system engineers trained by Tandem.

Adding and Upgrading Processors Online

Adding or upgrading a new processor online involves the following steps:

1. Ensuring that the operating system image loaded on your NonStop system includes the new processor

2. Physically installing the new processor and any related hardware

Ensuring That the Processor Is in the OSIMAGE

Before you can physically add a new processor online, the processor must be included in the operating system image (OSIMAGE) currently running on your NonStop system.

If the processor is not included in the OSIMAGE loaded on your NonStop system, the processor cannot be added online.

Installing the Processor and Any Related Hardware

Adding or upgrading a processor requires physical installation of a processor board and, in some situations and for certain NonStop systems, requires replacement of memory boards as well as other hardware installation tasks. Table 3-1 on page 3-8 lists the manuals that describe the hardware installation procedures for adding a processor.

Considerations for Adding and Upgrading Processors

The following list describes considerations and limitations you should be aware of when adding or upgrading processors online:

You cannot add a processor online if the cabinet that will contain the processor also needs to be added to the system. Your Tandem SE or CE may be able to help you add a system cabinet online.

You cannot upgrade your system from complex instruction set computing (CISC) processors to reduced instruction set computing (RISC) processors online. It is necessary to build a new operating system image when upgrading to RISC processors.

Availability Guide for Change Management125506

3-3

Making System Software and Hardware Changes Online

Adding and Upgrading Processor Memory Online

If you are upgrading processors 0 and 1 in the base cabinet, you must shut down the system.

Adding and Upgrading Processor Memory Online

To add or upgrade processor memory online, you install either a memory board or a processor board, depending on the type of NonStop system that you have. No software- configuration changes are necessary.

Actual hardware installation steps are system-specific. Table 3-1 on page 3-8 lists the manuals that describe the hardware installation procedures for adding and upgrading memory online.

Considerations for Adding and Upgrading Processor Memory

The following list describes considerations and limitations you should be aware of when adding or upgrading memory online:

All applications and system software running on the processor being changed must be stopped.

You must shut down the processor for which memory is being changed.

You must shut down single-processor systems.

Note. If adding or upgrading memory requires that you install a processor board, additional considerations may apply. See Adding and Upgrading Processors Onlineon page 3-3 for more information.

ServerNet Adapters

For the G01.00 release of the NonStop Kernel Operating System, I/O controllers are replaced by ServerNet adapters. A ServerNet adapter provides the interface between the ServerNEt SAN and a particular I/O bus, such as Ethernet or SCSI. A ServerNet adapter conains a ServerNet bus interface (SBI) and one or more ServerNet addressable controllers (SACS). Although ServerNet adapters can be customer-replaceable units (CRUs), they can also be integrated into other types of CRUs. For example, the PMF CRU includes a ServerNet adapter called the multifunction I/O board (MFIOB).

ServerNet Bus Interface (SBI)

The SBI is an application-specific integrated circuit (ASIC) on the ServerNet adapter that provides the interface between the ServerNet SAN and a different industry-standard bus, such as the Motorola 68030 bus, to which SACs are attached.

ServerNet Addressable Controllers (SACs)

SACs provide the controller functions for ServerNet adapters. These controllers provide the interface to buses such as SCSI, which connect to perpheral devices.

Availability Guide for Change Management125506

3-4

Making System Software and Hardware Changes Online

Adding, Upgrading, and Moving Disk Drives Online

Adding, Upgrading, and Moving Disk Drives Online

Adding, upgrading, or moving a disk drive online involves the following steps:

1. Using SCF to add a disk

2. Physically installing the disk drive

3. Preparing the new disk drive after installation

Using SCF To Add a Disk

You use the SCF command to add disks to the system configuration database. Before you use the ADD DISK command, be sure you know what cabinet (group), module, and slot the new drive is in.

Example

To add a nonmirrored disk to the system configuration that is in group 1, module 1, slot 1, using the name $data01, enter:

ADD DISK $DATA01, PRIMARYLOCATION (1,1,1)

To add a mirrored volume named $DATA02 (disks in slots 3 and 4), enter:

ADD DISK $DATA02, PRIMARYLOCATION (1,1,3), & &MIRRORLOCATION

(1,1,4)

Configuring Phantom Disk Drives

You can also add demountable disk drives online by configuring phantom disk drives as described in “System Software Changes” on page 3-1.

Installing the Disk Drive

To install the disk drive, you physically attach it to the controller (or controllers) indicated in the configuration file. Actual hardware installation steps are system- specific. Table 3-1 on page 3-8 lists the manuals that describe hardware installation procedures for adding, upgrading, and moving disk drives online.

Preparing the Disk Drive

After you have physically installed the disk drive on the system, you must prepare it for use. Disk preparation may include one or more of the following tasks:

Formatting the disk drive

Renaming the disk drive

Bringing the disk drive online

These tasks can be performed using SCF, which is described in the SCF Reference Manual for the Storage Subsystem.

Availability Guide for Change Management125506

3-5

Making System Software and Hardware Changes Online

Updating Firmware Online

Considerations for Adding, Upgrading, and Moving Disk Drives

The following list describes considerations and limitations you should be aware of when adding, upgrading, and moving disk drives online:

The $SYSTEM disk and any alternate system volume must be configured by SYSGENR. You cannot make changes to the system disk online.

When upgrading a disk volume from one drive (or drive type) to another, you must back up or otherwise copy the data from the original drive and restore it to the new drive after the upgrade is complete.

When moving or upgrading an existing disk drive, you must stop all affected processes that use the disk drive (or redirect them to another disk drive), take down all paths to the disk drive, and put the disk drive in the hard down state.

Updating Firmware Online

Many circuit boards and devices in NonStop systems contain firmware.

type of microcode—that is, program instructions residing in nonvolatile storage media

such as EEPROM (electronically erasable programmable read-only memory) or NVRAM (nonvolatile random access memory). Microcode can be downloaded or updated from disk. The two principal types of microcode are:

Firmware or bootstrap code, sometimes called “boot PROM code.” Boot code for a device starts or “boots” the device and may also contain power-on diagnostics.

Operational microcode for “downloadable” controllers. During a system load or while the controller is being loaded, the operational microcode is downloaded from storage into volatile memory.

Firmware is a

When You Need to Update Firmware

Firmware updates are required for processor boards, power supplies, control panels, and many I/O controller boards and interprocessor communication devices. In general, you should check the status of firmware and update any firmware that is out-of-date whenever new hardware or software is installed on your system. Check firmware status after installing any of the following:

New hardware products that contain firmware, such as processor boards or I/O controllers

New operating system releases

Interim product modifications (IPMs)

Any replacement component that contains firmware

Availability Guide for Change Management125506

3-6

Making System Software and Hardware Changes Online

Online Firmware Update Procedure

Updating firmware online consists of three steps:

1. Checking the firmware status

Where to Find More Information

2. Updating any firmware that is out-of-date

3. Checking the firmware status again to make sure that all of the firmware is up-to- date

You can perform all three steps using TSM, which is described in the TSM Configuration and Management Guide. An overview of TSM is provided in Section 7, “Tools for Online Change.”

Considerations for Updating Firmware

The following list describes considerations and limitations you should be aware of when updating firmware online:

You should update firmware only when the system is relatively quiet and it is highly unlikely that the update operation might be interrupted. (Interruptions can be caused by a loss of power, a channel kill, a reset, and so forth.) An unsuccessful update operation may leave a checksum error in the boot code, making the controller or device inoperable and requiring a board replacement.

When updating controller firmware, you may need to take down all paths to the controller before performing the update operation.

When updating processor firmware, read the product softdoc to determine if any of the included microcode and millicode files have changed. If any of the files included with the firmware have changed, you must reload the processor.

Where to Find More Information

Table 3-1 lists the manuals that contain system-specific configuration and installation procedures for the system software and hardware changes described in this section.

Table 3-1. Where to Find System-Specific Installation and Configuration Information

NonStop Systems

Himalaya S7000/

S70000

Manuals

Himalaya S-Series Planning and Configuration Guide Himalaya S-Series Installation Guide Himalaya S-Series Operations Guide Himalaya S-Series Support Guide Himalaya S-Series Workstation Installation Guide

Making System Software and Hardware Changes Online

Where to Find More Information

Table 3-2. Where to Find Additional Configuration Information

Manual

DSM/SCM User’s Guide

Subsystem Control Facility (SCF)

Reference Manual for G-Series

SCF Reference Manual for the Storage Subsystem

System Generation Manual for G-Series Releases

Releases

What it explains

How to plan for, manage, and install software on distributed Tandem systems.

How to alter the configuration of communications subsystems online.

How to configure, control, and inquire about storage devices on a Himalaya S-series server.

How to configure a newly installed system or update your system configuration after installing a new operating system release.

Availability Guide for Change Management125506

3-8

4

Making Application Subsystem

Changes Online

Overview

The Tandem application environment enables you to develop and run high-performance, high-volume, and highly available online transaction-processing (OLTP) applications. Making changes in your application environment can involve adding requester and server programs to handle new types of transactions, reorganizing a database to accommodate business growth, or simply reconfiguring certain configuration attributes.

This section provides information to help you reduce or eliminate planned outages by:

Identifying the changes you can perform online to three core service products that lie between the operating system platform and the transaction-processing applications:

NonStop Transaction Services/MP (NonStop TS/MP)

NonStop SQL/MP

NonStop Transaction Manager/MP (NonStop TM/MP)

Identifying the changes you can perform online to the following transaction- processing monitoring environments supported by Tandem:

The NonStop TUXEDO environment

The Pathway environment

Telling you which manuals contain application subsystem change information.

Online change is any change that can be performed while your NonStop system is still operational. In some situations, online changes may temporarily affect application availability.

Overview of the Tandem Application Environment

The Tandem application environment enables users to develop and run high- performance, high-volume, OLTP applications on NonStop systems. The system software that makes up the Tandem application environment falls into two broad categories, as shown in Figure 4-1 on page 4-3:

A set of core services that provide the underlying infrastructure for your transaction- processing applications

A choice of transaction-processing application environments

Transaction-Processing Core Services

The core services include the following software products:

Availability Guide for Change Management125506

4-1

Making Application Subsystem Changes Online

The Transaction-Processing Application Environments

The Tandem NonStop Kernel, the operating system that provides low-level functions such as interprocess message management, file management, memory management, and so on. The operating system provides two operating environments:

Open System Services (OSS) environment

Guardian environment

A device and transaction control system that supports complex applications in a network environment. This function is performed by the NonStop TS/MP product, which provides services such as process management and link management for transaction-processing applications.

A relational-database-management system that supports high-speed access and updates to distributed data. This function is performed by the NonStop SQL/MP database-management system.

A transaction-management facility that preserves the integrity of data during the multiple, concurrent transactions that change the data. This function is performed by NonStop TM/MP.

The Transaction-Processing Application Environments

An application can run in one of the following environments:

The NonStop TUXEDO environment, Tandem’s implementation of Novell, Inc.’s TUXEDO enterprise transaction-processing (ETP) system, a transaction monitor for open client/server applications.

The Pathway transaction-processing environment, an implementation of the client/server model for terminal-based and workstation-based applications.

Availability Guide for Change Management125506

4-2

Making Application Subsystem Changes Online

Client/Server Computing and the Tandem Application Environment

Figure 4-1. The Tandem Application Environment User Applications TP NonStop TUXEDO PTP Pathway Monitor Middleware
Figure 4-1. The Tandem Application Environment
User Applications
TP
NonStop TUXEDO
PTP
Pathway
Monitor
Middleware
Choices
NonStop TS/MP
NonStop TM/MP
NonStop SQL/MP
Core
Services
Open System Services (OSS) Environment
Guardian Environment
Operating
System
Tandem NonStop Kernel
003

Middleware products provide services to application programs while "hiding" the underlying operating system platform.

TP monitor products provide transaction routing, resource allocation and monitoring, APIs, development tools, and administrative tools.

The core services provide the Tandem fundamentals: Parallelism, Scalability, Availability, and Manageability.

CDT 003

Client/Server Computing and the Tandem Application Environment

The Tandem application environment is a collection of processes and files designed to facilitate the development and management of OLTP applications. The Tandem transaction-processing services provide programs and an operating environment to help you develop and run reliable, manageable, and cost-effective OLTP applications.

The transaction-processing environment consists of two types of programs: requester or client programs and server programs.

Note. Generally, the term requesterrefers to that part of an application that runs on a Tandem NonStop system and makes requests of a server process. While a requester process is conceptually the same as a client process, the term requester is retained for historical reasons. The term clientrefers to the part of an application that runs on some other vendors hardwaresuch as a PC, Macintosh, UNIX workstation, or mainframe computer systemand makes requests of a server process. Client programs running on numerous hardware platforms can make requests of server processes residing on Tandems massively parallel server systems.

In the client/server computing environment, programs are divided between a client program, which resides on a personal computer (PC), Macintosh, or workstation, and server programs, which reside on a host system such as a Tandem NonStop system.

Availability Guide for Change Management125506

4-3

Making Application Subsystem Changes Online

Client/Server Computing and the Tandem Application Environment

Users typically request information from server programs through an easy-to-use graphical user interface (GUI) provided by the client program. The client/server architecture is usually linked together by a local area network (LAN).

You can design client/server implementations of Tandem’s application environment using products provided by Tandem. The Tandem client/server products, and how they can be used with NonStop TS/MP, NonStop SQL/MP, and NonStop TM/MP, are described later in this section.

Requester or Client Programs

Requester, or client, programs in a transaction-processing environment perform specific tasks such as:

Handling input devices (for example, displaying a data entry screen, accepting input data, and checking for input errors)

Sending input data in a special message format to the appropriate server

Processing the reply message returned by the server

Requesters are developed by application programmers as SCREEN COBOL programs, Guardian programs, or—in the client/server environment—PC, Macintosh, or workstation applications. (SCREEN COBOL is a programming language developed by Tandem.)

Server Programs

Requester or client programs communicate with server programs. Servers perform the following tasks:

Receive request messages from requesters

Perform the selected operations, such as database inquiries or updates

Return reply messages to requesters

A collection of replicated server processes is called a server class. A server class is a group of server processes that perform a specific type of work. All server processes within a server class run copies of the same server program. The replication of server functions allows you to distribute the transaction workload across multiple processors.

Availability Guide for Change Management125506

4-4

Making Application Subsystem Changes Online

Making Changes to NonStop TS/MP Online

Making Changes to NonStop TS/MP Online

You may need to change your transaction-processing environment to accommodate new application requirements or new users or to satisfy new transaction throughput and response time requirements. Tandem designed its transaction-processing services to expand easily as OLTP operations evolve and business needs change.

This subsection:

Provides a brief overview of NonStop TS/MP

Describes the changes you can perform to NonStop TS/MP online

Note. For a complete overview of NonStop TS/MP, see the Introduction to NonStop Transaction Processing.

Overview of NonStop TS/MP

The NonStop TS/MP product consists of a set of processes that give enhanced transaction-processing functions to client/server, terminal-based, and mixed-computing environments.

NonStop TS/MP supports products and processes that run in either the Guardian environment or the OSS environment; however, all NonStop TS/MP product processes run as Guardian processes.

NonStop TS/MP Components

NonStop TS/MP supports server processes through monitoring, load balancing, and providing linkage with requesters. The major components of NonStop TS/MP are:

PATHMON (Process manager)—The central control process for the transaction- processing core service. The process-management tasks performed by PATHMON include all the tasks related to the starting, monitoring, and stopping of server processes and other processes specific to a transaction-processing environment.

LINKMON (Link manager)—The process that requests links to server processes and provides link access after the link is granted. LINKMON processes support access to server classes from client and requester programs in the NonStop TUXEDO, and Pathway environments.

NonStop TS/MP Management Interfaces

The NonStop TS/MP product provides the following interfaces:

PATHCOM—A command interpreter used to communicate interactively with PATHMON to configure and manage the NonStop TS/MP core service.

NonStop TS/MP management programming interface—A set of programmatic commands that allows a management application to communicate directly with PATHMON. You typically write management applications to automate operator functions.

Availability Guide for Change Management125506

4-5

Making Application Subsystem Changes Online

NonStop TS/MP Changes You Can Perform Online

NonStop TS/MP Changes You Can Perform Online

Making changes to NonStop TS/MP does not require the NonStop system to be shut down, and most changes can be made without affecting the availability of the transaction-processing application. The following subsections describe common transaction-processing environment changes.

Adding Hardware

You can attach more terminals, disk drives, peripheral devices, and processors to your NonStop system without having to recode your transaction-processing application. After the new hardware is physically installed, you identify the hardware to PATHMON using PATHCOM commands (see “Adding and Deleting Objects Controlled by PATHMON”).

Note. See Section 3, Making System Software and Hardware Changes Online,for information about adding hardware online.

Adding and Deleting Objects Controlled by PATHMON

As your transaction-processing system grows to meet changing business requirements, you may need to add additional objects to handle new types of transactions or processing functions, or delete existing objects. For example, you might want to add a SERVER (an object controlled by PATHMON that defines a server class) to distribute the transaction workload.

To add an object to your PATHMON environment, you use PATHCOM commands to define the attributes of the object and then identify the new object to the transaction- processing system. Deleting an object may involve stopping the object (this depends on the type of object you want to delete), and then removing the object definition from the PATHMON configuration file. You can perform these changes while your application is still active and processing transactions. Table 4-1 lists the object types that must be stopped before they can be deleted.

Altering Objects Controlled by PATHMON

Business growth may also require you to change the attributes of existing PATHMON objects. For example, you can reconfigure requesters and servers to run in different processors within the same system or on different nodes of an Expand network.

Certain objects controlled by PATHMON must be stopped before their attributes can be altered. Table 4-1 summarizes the types of changes you can make to PATHMON objects and whether they require that the object be stopped. Stopping an object controlled by PATHMON may affect application availability.

Availability Guide for Change Management125506

4-6

Making Application Subsystem Changes Online

NonStop TS/MP Changes You Can Perform Online

Table 4-1. PATHMON Object Changes

Object must be stopped?

Type of change

Object

Yes

No

Changing backup processors and dump files

PATHMON

X

TCP*

X

Exchanging primary and backup processors

PATHMON

X

TCP*

X

Deleting objects

TCP*

X

TERM*

X

PROGRAM*

X

SERVER

X

Altering object attributes

TCP*

X

TERM*

X

PROGRAM*

X

SERVER

X

* TCP, TERM, and PROGRAM are Pathway/TS objects managed by the PATHMON process. Pathway/TS is discussed in “The Pathway Environment” subsection starting on page 4-25.

Increasing the Maximum Number of Objects Controlled by PATHMON

Increasing the maximum number of objects controlled by PATHMON requires that you shut down your transaction-processing application, make the necessary changes, then cold start your PATHMON environment. You can avoid having to increase the number of objects controlled by PATHMON by making sure that you select limits that allow space for growth. For example, if you are not certain whether you might need an extra TCP or server class, leave room for one or two more of these objects than you currently need. However, be careful not to set unreasonably large limits because you may cause PATHMON to waste disk space.

Changing the Owner and Security Attributes

Changing the owner and security attributes of your PATHMON environment requires that you shut down your PATHMON environment, make the necessary changes, then cold start your PATHMON environment.

Availability Guide for Change Management125506

4-7

Making Application Subsystem Changes Online

Where to Find More Information

Summary of NonStop TS/MP Changes

Table 4-2 summarizes the NonStop TS/MP changes described in this subsection.

Table 4-2. Summary of NonStop TS/MP Changes

Impact on Availability

Type of change

NonStop system

Application

Adding or replacing hardware

Available

Available.

Adding or deleting objects controlled by PATHMON

Available

Available.

Altering attributes of objects controlled by PATHMON

Available

May affect availability if the object must be stopped before it is altered.

Increasing the maximum number of objects controlled by PATHMON

Available

You must shut down your PATHMON environment.

Changing the owner and security attributes

Available

You must shut down your PATHMON environment.

Where to Find More Information

Refer to the following manuals for more information about NonStop TS/MP.

Manual

Introduction to NonStop Transaction Processing

NonStop TS/MP System Management Manual

NonStop TS/MP and Pathway

Management Reference

NonStop TS/MP and Pathway Management Programming Commands Manual

Manual

What it contains

Provides a detailed overview of NonStop TS/MP, including its features and capabilities.

Describes how to perform all the NonStop TS/MP changes described in this section.

Describes the syntax and semantics of the PATHCOM commands.

Describes the token-oriented programmatic interface to NonStop TS/MP.

Availability Guide for Change Management125506

4-8

Making Application Subsystem Changes Online

Making Changes to NonStop SQL/MP Online

Making Changes to NonStop SQL/MP Online

You may need to change your NonStop SQL/MP database to accommodate business growth or to add new capabilities. Tandem designed NonStop SQL/MP to accommodate growth easily—you can change data definitions as your database changes and grows. NonStop SQL/MP includes utilities that make database growth possible and easy.

This subsection:

Provides a brief overview of NonStop SQL/MP

Describes the changes you can perform to NonStop SQL/MP online

Note.

SQL/MP.

For a more complete overview of NonStop SQL, see the Introduction to NonStop

Overview of NonStop SQL/MP

NonStop SQL/MP is a relational-database-management system that uses the ANSI- standard and ISO-standard Structured Query Language (SQL) to create relational databases and to describe and manipulate data. NonStop SQL/MP databases can be fully distributed so that you can store the data where it is used most frequently and yet read and update the data from anywhere in the network. In addition to online transaction processing, NonStop SQL/MP is used for decision-support systems (DSS), scalable electronic commerce applications, and other business applications.

NonStop SQL/MP supports products and applications that run in either the Guardian environment or the OSS environment; however, all NonStop SQL/MP product processes run as Guardian processes.

NonStop SQL/MP Components

NonStop SQL/MP consists of the following components:

The SQL compiler compiles host-language object programs, transforms embedded SQL statement into executable query plans, and creates an object program file.

The SQL optimizer evaluates the query and determines the most efficient plan for retrieving data from the database.

The SQL executor, a set of system library procedures, executes compiled SQL statements against database tables, views, or database catalogs.

NonStop SQL/MP Interfaces

NonStop SQL/MP consists of the following major interfaces:

The NonStop SQL/MP conversational interface (SQLCI)—An interactive, line- oriented, terminal interface that is used by business professionals, database administrators, and application programmers to perform a variety of tasks. SQLCI provides the following features:

SQL statements—SQL statements can be entered directly from a terminal.

Availability Guide for Change Management125506

4-9

Making Application Subsystem Changes Online

Overview of NonStop SQL/MP

SQLCI commands—SQLCI commands enable you to set and display the SQLCI environment.

Report Writer—A full-function report-writing facility that formats custom reports.

Utilities—A full set of utilities that provide quick access to information about the database, the data dictionary, and the application programs.

Programmatic SQL—The NonStop SQL/MP application programming interface. Programmatic SQL enables programmers to code SQL statements in C, COBOL85, Pascal, and TAL host language programs.

When using NonStop SQL/MP, you access database objects. A database object is an entity that is created, manipulated, or dropped by SQL statements. Database objects include tables, indexes, views, constraints, and collations.

Figure 4-2 is a simplified drawing of a traditional NonStop SQL/MP database system.

Figure 4-2. A Traditional NonStop SQL/MP Database System

Tandem NonStop System

NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities

NonStop SQL/MP

SQLCI

Database

NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
NonStop SQL/MP SQLCI Database SQL Statements Commands Report Writer Data Dictionary Utilities
SQL Statements Commands
SQL
Statements
Commands

Report Writer

SQL Statements Commands Report Writer Data Dictionary
SQL Statements Commands Report Writer Data Dictionary
Data Dictionary
Data
Dictionary
Utilities
Utilities
Utilities Business Data

BusinessUtilities Data

Data

Programmatic

SQL

Programmatic SQL Data Dictionary

Data

Dictionary

OLTP

Applications

OLTP Applications Business Data

BusinessOLTP Applications Data

Data

Data Dictionary OLTP Applications Business Data Business Professional Database Administrator Application

Business

Professional

OLTP Applications Business Data Business Professional Database Administrator Application Programmer Application

Database

Administrator

Business Data Business Professional Database Administrator Application Programmer Application User Availability Guide

Application

Programmer

Professional Database Administrator Application Programmer Application User Availability Guide for Change Management

Application

User

Availability Guide for Change Management125506

4-10

Making Application Subsystem Changes Online

NonStop SQL/MP in the Client/Server Environment

NonStop SQL/MP in the Client/Server Environment

In the client/server environment, the client (a PC, Macintosh, or workstation) accesses NonStop SQL/MP by sending SQL statements to Tandem gateway software. The gateway software retrieves information from the NonStop SQL/MP database, which resides on the server (a NonStop system). End users on the client system can use local workstation tools to format the retrieved data into usable information.

Tandem provides two gateway products that allow clients to access NonStop SQL/MP databases:

NonStop Open Database Connectivity (ODBC) Server

Tandem Data Access Language (DAL) Server

NonStop ODBC Server

The NonStop ODBC Server allows client applications that use either the ODBC interface or the SQL Server interface to access NonStop SQL/MP databases. ODBC is a database connectivity standard developed by the SQL Access Group (SAG). SQL Server is a de facto standard.

Tandem DAL Server

The Tandem DAL Server software provides NonStop SQL/MP database access for DAL-compatible client applications. DAL is a data connectivity language and a standard for database access.

Figure 4-3 shows a client/server implementation of NonStop SQL/MP.

Figure 4-3. NonStop SQL/MP in the Client/Server Environment

Server (Tandem NonStop System)

ODBC NonStop SQL/MP DAL
ODBC
NonStop
SQL/MP
DAL

Client (PC, Macintosh, or workstation)

Client A Database driver
Client A
Database
driver

SQL

statements

Data

Making Application Subsystem Changes Online

NonStop SQL/MP Changes You Can Perform Online

NonStop SQL/MP Changes You Can Perform Online

When you make changes to a NonStop SQL/MP database, you do not need to shut down the NonStop system, and most changes can be made without affecting NonStop SQL/MP application availability. This flexibility is because of a number of underlying factors:

The relational structure of the NonStop SQL/MP database provides database independence, which ensures that objects can be added or altered in the database with little or no effect on existing applications.

The NonStop SQL/MP database structure is described in an active data dictionary. NonStop SQL/MP automatically updates the dictionary when database objects are created, altered, or dropped.

NonStop SQL/MP versioning lets you maintain distributed nodes at different release levels. You can migrate to new release levels without moving data or recompiling SQL programs.

The NonStop TM/MP product protects the database and keeps track of database activity. The NonStop TM/MP product is described later in this section.

The following subsections describe common NonStop SQL/MP changes.

Adding, Dropping, and Altering Objects

Because the NonStop SQL/MP database structure is described in an active data dictionary, the operation of existing applications can usually continue regardless of database changes. You can typically add, alter, or drop database objects, including tables, indexes, views, constraints, and collations, without interrupting your applications.

Note. A CREATE INDEX operation that uses the WITH SHARED ACCESS option increases availability. If the WITH SHARED ACCESS option is not specified, only read access on the base table is allowed. A CREATE INDEX operation with the WITH SHARED ACCESS option has the same brief downtime as is associated with reorganization.

Reorganizing a Database

Reorganizing a NonStop SQL/MP database can involve reloading data, adding partitions to a table or index, splitting or moving all or part of a partition to access additional space or improve I/O performance, or compacting a file to improve disk usage.

Any change you make to your database organization will have some impact on application availability. Under some conditions, availability will be very high; under other conditions, availability will be lower. Using the WITH SHARED ACCESS option with certain SQL statements can help you reduce the impact of database reorganization on application availability:

The WITH SHARED ACCESS option maximizes application availability by allowing read and write access to data during certain data definition language (DDL) operations for all but a relatively brief period at the end of the operation. SQL statements that support the WITH SHARED ACCESS option include CREATE INDEX and the move partition form of the ALTER INDEX and ALTER TABLE statements. For example, you

Availability Guide for Change Management125506

4-12

Making Application Subsystem Changes Online

NonStop SQL/MP Changes You Can Perform Online

can move all or part of a partition to other disk volumes while allowing full update access to the data in the partition.

Reducing the Frequency of Database Reorganizations

Another way you can reduce the impact of database reorganizations on application availability is to reduce their frequency. The following guidelines can help you avoid reorganizing your database:

Consider partitioning tables for future growth. Partitioning allows the index structure to be spread across more media, thereby reducing the number of index blocks and possibly the index levels required to support the data.

Review the value of the table BLOCKSIZE attribute. Increasing the block size also reduces the number of index blocks and index levels.

Specify an appropriate amount of slack space when reloading a table to ensure adequate growth capabilities without the immediate need for block splits.

If data is badly fragmented, the BACKUP and RESTORE activities can help make more extents contiguous, but only if the volume has large enough free extents to accomodate the file.

Use an anchor partition—a partition that contains no data and that you never move—for partitioned SQL tables to provide better flexibility when moving partitions. By creating an anchor partition and using it in your queue, you can more easily move partitions containing data and thus obtain better availability.

Recompiling SQL Statements

Although many database operations can be completed with no disruption to the application, other operations require recompilation of SQL statements to achieve maximum performance. For example, data definition language (DDL) operations on SQL objects can invalidate programs that access the object. An invalid program must be either statically recompiled or autorecompiled before it is executed. Static recompilation requires the application to be unavailable; autorecompilation of a program can cause a deterioration in the response time of the program because it recompiles the program each time the program is executed.

In certain situations, you can reduce recompilation time caused by invalidated programs by using the following compiler options:

COMPILE INOPERABLE PLANS—This option directs the SQL compiler to perform similarity checks during explicit SQL compilation in order to explicitly compile only statements with inoperable plans. Using the COMPILE INOPERABLE PLANS option may be preferable when a program contains only a few query plans that are invalid and need to be recompiled.

CHECK INOPERABLE PLANS—This option directs the SQL executor to perform similarity checks at run time in order to automatically recompile only statements with inoperable plans. The CHECK INOPERABLE PLANS option can also prevent certain DDL operations performed on SQL objects from invalidating SQL programs

Availability Guide for Change Management125506

4-13

Making Application Subsystem Changes Online

NonStop SQL/MP Changes You Can Perform Online

that reference the objects, providing the SQL object has its SIMILARITY CHECK option set to ENABLE.

Two objects are considered to be similar if the same execution plan can be used to access either object. An operable plan is semantically correct and can execute correctly without SQL recompilation (although it might not be optimal) while an inoperable plan must be recompiled to execute correctly.

Moving a Database or Database Program

You might need to move a database or database objects when new equipment is added, when a database and application programs are moved from one system to another, or to enhance performance.

Changing the location of your database will have some impact on application availability. For certain databases, availability will be very high; for other databases, it will be lower.

When you move a database program, it might need to be recompiled. Recompilation may be necessary even if the program was previously compiled on a different system. In certain situations, you can avoid recompiling moved programs and the associated impact on application availability by using the following compiler options:

REGISTERONLY—This option directs the SQL compiler to register a previously compiled program in a specific catalog without recompiling any SQL statements in the program. You can use this option to install a program in a catalog after you have compiled the program with the SQL compiler and moved the program. The REGISTERONLY is much faster than explicitly recompiling the entire program.

NOREGISTER—This option directs the SQL compiler to compile a program without registering the program in a catalog. You can then move the program using a SQLCI DUP command or the BACKUP and RESTORE programs. After the move, you can run the program without recompiling or registering it in a catalog.

The COMPILE and CHECK compiler options can be used to selectively recompile plans in a program and reduce the time of recompilations. Refer to “Reorganizing a Database” for information about these options.

Changing the Node Name or Node Number

The following types of operations cause the node name or number to be changed but do not automatically update the NonStop SQL/MP catalogs and file information:

Cold loading the node with a different node name or number

Restoring a volume-mode backup on a different node

Physically moving disks from one node to another

To update the node number or node name, use the NonStop SQL/MP MODIFY [DICTIONARY] commands. Note, however, that these commands do not update node names or numbers that are stored as data in the database; they only affect node names in the SQL catalog or node numbers in file labels of SQL objects and object programs.

Availability Guide for Change Management125506

4-14

Making Application Subsystem Changes Online

Where to Find More Information

Summary of NonStop SQL/MP Changes

Each of the changes described in this subsection can have some impact on application availability. Determining the impact of a specific change on application availability requires a thorough understanding of NonStop SQL/MP database management as well as the customer application. None of the changes described in this subsection affect system availability.

Where to Find More Information

Refer to the following manuals for more information about changing a NonStop SQL/MP database.

Manual

NonStop SQL/MP Installation and Management Guide

NonStop SQL/MP Reference Manual

NonStop SQL/MP Version Management Guide

What it contains

Describes how to perform all the NonStop SQL/MP changes described in this section

Describes SQL, including the syntax of SQL statements, functions, search conditions, data types and literals, SQLCI, and the NonStop SQL/MP utilities

Describes the rules governing version management for the NonStop SQL/MP software, catalogs, objects, messages, programs, and data structures

The following manuals contain additional information about NonStop SQL/MP databases:

Manual

Introduction to NonStop SQL/MP

NonStop SQL/MP Query Guide

NonStop SQL/MP Report Writer Manual

NonStop SQL/MP Messages Manual

NonStop SQL/MP programming manuals for C, COBOL85, TAL, and Pascal

What it contains

Provides a detailed overview of NonStop SQL/MP, including its features and capabilities

Describes how to write NonStop SQL/MP queries and how to optimize queries for enhanced performance

Describes how to use report-writer commands and SQLCI options to design and produce reports

Describes the messages issued by NonStop SQL/MP software, as well as file-system and other related messages

Describe the programmatic interface for host languages

Availability Guide for Change Management125506

4-15

Making Application Subsystem Changes Online

Making Changes to NonStop TM/MP Online

Making Changes to NonStop TM/MP Online

You may need to change your NonStop TM/MP configuration to accommodate business growth or to respond to changing business factors requiring an increased or decreased level of protection for your database.

This subsection:

Provides a brief overview of NonStop TM/MP

Describes the changes you can make to NonStop TM/MP online

Note.

Transaction Manager/MP (TM/MP).

For a more complete overview of NonStop TM/MP, see the Introduction to NonStop

Overview of NonStop TM/MP

The NonStop TM/MP product protects databases in OLTP environments using its main functional component, the Transaction Management Facility (TMF) subsystem. The TMF subsystem manages database transactions, keeps track of database activity through audit trails, and provides database recovery methods.

NonStop TM/MP is required by NonStop SQL/MP. The NonStop TM/MP subsystem also supports the NonStop TS/MP product by recording information about transactions. NonStop SQL/MP and NonStop TS/MP are described earlier in this section.

Transactions

The fundamental component of the TMF subsystem is a programmatic construct called a transaction. A transaction is an explicitly delimited operation or set of related operations that alters the content of a database. If an error occurs while a transaction is in progress, the TMF subsystem backs out whatever partial changes were made to the database, leaving the database in a consistent state.

Audit Trails

Before a transaction permanently commits its changes to the database, information about the affected database rows or records is written to the audit trail. An audit trail is a series of files containing audit records and TMF control records. An audit trail can span up to 16 volumes.

There is one master audit trail (MAT) in each TMF subsystem. In addition, each TMF subsystem can have up to 15 auxiliary audit trails. These audit trails contain audit records in addition to those in the MAT.

When you configure the MAT, you specify the names of the disk volumes that will receive audit information. These disk volumes are called active audit volumes. The set of audit-trail files on an active audit volume are collectively referred to as the active audit trail. You can also specify disk volumes to use if all audit-trail files become filled. These are called overflow audit volumes.

Audit dumps preserve copies of audit-trail files for file recovery. Audit-dump processes copy audit-trail files from active or overflow audit volumes to tape or disk.

Availability Guide for Change Management125506

4-16

Making Application Subsystem Changes Online

NonStop TM/MP in the Client/Server Environment

Database Tables and Files

When configuring your NonStop TM/MP environment, you must identify all disk volumes that will be protected by the TMF subsystem. These disk volumes are called data volumes.

Online dumps are copies of audited files residing on data volumes. If the database is damaged, the TMF subsystem can restore the online dump files to disk and apply the audit-trail images to reconstruct the files.

TMF Subsystem Management Interfaces

The TMF subsystem has the following management interfaces:

TMFCOM—the TMF interactive command interface. TMFCOM allows commands to be entered and responses to be received through a terminal keyboard and monitor.

TMFSERVE—the TMF management programming interface. TMFSERVE provides programmatic access to the Subsystem Programmatic Interface (SPI), making it possible to construct management applications that monitor and control the TMF environment.

Figure 4-4 shows the role of the TMF subsystem in the traditional Tandem transaction- processing environment.

Figure 4-4. The TMF Subsystem in a Traditional Transaction-Processing Environment

Tandem NonStop System OLTP Software Database TMF Log of Subsystem Transaction Records
Tandem NonStop System
OLTP
Software
Database
TMF
Log of
Subsystem
Transaction
Records
(Audit trail)

(Audit trail)

Transaction

Entry

Transaction Records (Audit trail) Transaction Entry User terminals NonStop TM/MP in the Client/Server

User

terminals

Records (Audit trail) Transaction Entry User terminals NonStop TM/MP in the Client/Server Environment In the

NonStop TM/MP in the Client/Server Environment

In the client/server environment, the TMF subsystem protects databases, keeps track of database activity, and provides database recovery methods in exactly the same way as it does in the traditional Tandem transaction environment. NonStop SQL/MP databases

Availability Guide for Change Management125506

4-17

Making Application Subsystem Changes Online

TMF Subsystem Changes You Can Perform Online

can be fully protected by NonStop TM/MP regardless of whether transactions are initiated by a client (a PC, Macintosh, or workstation) or by a requester on a NonStop system.

TMF Subsystem Changes You Can Perform Online

Making changes to the TMF subsystem does not require the NonStop system to be shut down, and most changes can be made without affecting the availability of applications that use the TMF subsystem. The following subsections describe common TMF subsystem changes.

Changing the Audit-Trail Configuration

Audit-trail configuration changes affect the size and capacity of audit trails. You can perform most audit-trail configuration changes while the TMF subsystem is running.

Some audit-trail configuration changes require the TMF subsystem to be stopped. Stopping the TMF subsystem stops transaction processing. This action may cause your transaction-processing applications to fail, so you may have to stop your applications before stopping the TMF subsystem. If you must stop the TMF subsystem, choose a time when the interruption will affect application users the least.

Table 4-3 summarizes the audit-trail configuration changes.

Table 4-3. Audit-Trail Configuration Changes

Impact on Availability

Type of change

NonStop system

Application

Adding or deleting an active audit volume

Available

Available

Adding or deleting an overflow audit volume

Available

Available

Adding or deleting a restore audit volume

Available

Available

Adding or deleting an entire audit trail

Available

Requires the TMF subsystem to be stopped and the TMF configuration to be deleted

Increasing or decreasing the number of files that reside on each active audit volume

Available

Available

Increasing or decreasing the overflow threshold

Available

Available

Increasing or decreasing the begin- transaction-disable threshold

Available

Available

Setting or resetting audit-trail file size

Available

Requires the TMF subsystem to be stopped and the TMF configuration to be deleted

Availability Guide for Change Management125506

4-18

Making Application Subsystem Changes Online

TMF Subsystem Changes You Can Perform Online

Changing the Data-Volume Configuration

Data-volume configuration changes can have various effects on the TMF subsystem. For example, adding a data volume can potentially increase the number of audit records generated. You can perform data-volume configuration changes while the TMF subsystem is running. Depending on your application, some changes may require application access to the data volume to be stopped.

Table 4-4 summarizes the data-volume configuration changes.

Table 4-4. Data-Volume Configuration Changes

Impact on Availability

Type of change

NonStop system

Application

Adding or deleting a data volume

Available

Available.

Resetting the recovery mode

Available

Available.

Renaming a data volume

Available

Application access to the data volume may need to be stopped (renaming a data volume is accomplished by deleting the data volume and re-adding it with the new name).

Moving a data volume to another system

Available

Application access to the data volume may need to be stopped.

Changing the Autoabort Configuration

The TMF autoabort function automatically aborts transactions if they run longer than a set amount of time. The time limit used to identify long-running transactions is known as the autoabort threshold. This threshold specifies the length of time that a transaction can run before the TMF subsystem automatically aborts it. You can change the autoabort configuration attributes while the TMF subsystem is running.

Table 4-5 summarizes the autoabort configuration changes.

Table 4-5. Autoabort Configuration Changes

Impact on Availability

Type of change

NonStop system

Application

Increasing or decreasing the autoabort threshold

Available

Available

Resetting the autoabort value

Available

Available

Changing the Audit-Dump Configuration

Audit-dump configuration attributes can be changed while the TMF subsystem is running. Audit dumps preserve copies of audit-trail files for file recovery.

Table 4-6 summarizes the audit-dump configuration attribute changes.

Availability Guide for Change Management125506

4-19

Making Application Subsystem Changes Online

TMF Subsystem Changes You Can Perform Online

Table 4-6. Audit-Dump Configuration Changes

Impact on Availability

Type of change

NonStop system

Application

Altering the block size for tape dumps

Available

Available

Altering the number of tape copies

Available

Available

Altering the tape verification value

Available

Available

Changing the method used for making multiple tape copies

Available

Available

Changing the system on which audit-trail files are dumped

Available

Available

Changing the disk media used for audit-trail file dumps

Available

Available

Changing the TMF Catalog

You can change many aspects of the TMF catalog while the TMF subsystem is running. The TMF catalog maintains entries for audit dumps, online dumps, and tape media.

Table 4-7 summarizes the TMF catalog changes.

Table 4-7. TMF Catalog Configuration and Entry Changes

Impact on Availability

Type of change

NonStop system

Application

Adding or deleting tape media from the TMF catalog

Available

Available

Adding or removing online dumps or audit dumps from the TMF catalog

Available

Available

Changing TMF catalog attributes

Available

Requires the TMF subsystem to be stopped

Changing the state of an existing online dump or audit dump

Available

Available

Changing the status of an existing tape volume in the TMF catalog

Available

Available

Summary of TMF Changes

Table 4-8 summarizes the TMF changes described in this section.

Availability Guide for Change Management125506

4-20

Making Application Subsystem Changes Online

Where to Find More Information

Table 4-8. Summary of TMF Changes

Impact on Availability

Type of change

NonStop system

Application

Changing the audit-trail configuration

Available

Adding an entire audit trail or resetting the audit-trail file size requires the TMF subsystem to be stopped and the TMF configuration to be deleted; other changes do not affect availability.

Changing the data-volume configuration

Available

Renaming or moving a data volume may require application access to the data volume to be stopped; other changes do not affect availability.

Changing the autoabort configuration

Available

Available.

Changing the audit-dump configuration

Available

Available.

Changing TMF catalog attributes

Available

Changing TMF catalog attributes requires the TMF subsystem to be stopped; other changes do not affect availability.

Where to Find More Information

Refer to the following manuals for more information about NonStop TM/MP.

Manual

Introduction to NonStop Transaction Manager/MP (TM/MP)

NonStop TM/MP Configuration and Planning Guide NonStop TM/MP Operations and Recovery Guide

NonStop TM/MP Reference Manual

NonStop TM/MP Management Programming Manual

What it contains

Provides a detailed overview of the NonStop TM/MP, including its features and capabilities

Together these manuals describe how to perform all the NonStop SQL/MP changes described in this section

Describes the syntax and semantics of the TMFCOM commands

Describes the token-oriented programmatic interface to NonStop TM/MP

Availability Guide for Change Management125506

4-21

Making Application Subsystem Changes Online

Making Changes to Transaction-Processing Monitoring Environments Online

Making Changes to Transaction-Processing Monitoring Environments Online

Although originally developed to optimize the performance and availability of OLTP applications running on mainframe systems, transaction-processing (TP) monitors perform the same functions for client/server OLTP applications. A TP monitor can include services for screen presentation and management, data management and conversion, network access, authorization and security, and restart and recovery for the applications and resources under its control.

TP monitors also serve to optimize database performance. The TP monitor routes the client request for services to the appropriate server process. The server process acts as a “client” to the database on behalf of the clients it is servicing. By supporting a distinct application service layer independent of the database, the TP monitor enables the database to focus on data shipping, data integrity, and data management.

Tandem supports the following TP monitoring environments:

The NonStop TUXEDO environment

The Pathway environment

This subsection:

Provides an overview of each of the TP monitoring environments

Describes the changes you can make to each of the TP monitoring environments online

Note. For a more complete description of the TP monitoring environments, read the Introduction to NonStop Transaction Processing.

The NonStop TUXEDO Environment

The NonStop TUXEDO environment provides a client/server model for open applications and the benefits of the Tandem fundamentals. The NonStop TUXEDO product is Tandem’s implementation of Novell, Inc.’s TUXEDO enterprise-transaction- processing (ETP) system, a transaction monitor for open client/server applications. The NonStop TUXEDO system provides the System/T transaction-monitor functions, the API familiar to all TUXEDO application developers, and the administrative interface familiar to all TUXEDO system administrators. Figure 4-5 provides an overview of a NonStop TUXEDO transaction-processing environment.

Availability Guide for Change Management125506

4-22

Making Application Subsystem Changes Online

The NonStop TUXEDO Environment

Figure 4-5. NonStop TUXEDO Transaction-Processing Environment

Tandem NonStop Series/RISC (TNS/R) System OSS Environment Core Services Guardian Environment NonStop Transaction
Tandem NonStop Series/RISC (TNS/R) System
OSS Environment
Core Services
Guardian Environment
NonStop Transaction
Services/MP
(NonStop TS/MP)
Server Class
NonStop TUXEDO
Workstation
Transaction
Clients
Monitor
NonStop
(System/T)
TUXEDO
Server
NonStop SQL/MP
Database
NonStop Transaction
Manager/MP
(NonStop TM/MP)
Transaction
Log

CDT 007

NonStop TUXEDO Environment Changes You Can Perform Online

The NonStop TUXEDO system provides a complete set of administrative programs and tools that are required for production OLTP applications. You use these tools to:

Configure the application

Start and stop the application

Monitor and maintain the application

Most of these tasks are performed using the administrative programs and tools familiar to all TUXEDO users.

Availability Guide for Change Management125506

4-23

Making Application Subsystem Changes Online

The NonStop TUXEDO Environment

Because the NonStop TUXEDO system uses the Tandem core services, however, there are administrative tasks that are unique to the NonStop TUXEDO system. These tasks are described later in the subsection “Administration of the Core Services.”

This section and the subsections following provide an overview of the NonStop TUXEDO administrative environment. For more detailed information, see the NonStop TUXEDO System Administration Guide.

Dynamic Reconfiguration

NonStop TUXEDO administrators can alter key application definitions without bringing the application down. For example:

New machines, servers, and services can be added to the configuration without taking the application out of service.

Services can be made available on a selective basis.

Various parameters, such as timeout intervals and priorities, can be changed dynamically.

To make online configuration changes, administrators use the tmconfig program, an interactive tool that guides the administrator through the reconfiguration process.

Online Service Management

Administrators can manage services for a running application by using the tmadmin program. This program provides commands that enable administrators to:

Query the state of the application

Add (advertise) or remove (unadvertise) services from the bulletin board

Change the load for a service

Change the transaction timeout value for a service

These commands change the information in the current bulletin board structure, but they do not make permanent changes to the configuration file.

Administration of the Core Services

The NonStop TUXEDO system uses the Tandem core transaction-processing services as follows:

NonStop TS/MP for process management and link management (which enables communication between clients and servers)

NonStop TM/MP for transaction management

The NonStop TS/MP infrastructure is virtually transparent to the NonStop TUXEDO administrator. For example, when the administrator starts a NonStop TUXEDO application, the underlying NonStop TS/MP processes are automatically started and maintained. The administrator will notice a few added parameters in the configuration file, however, and might want to use PATHCOM to check the status of the underlying service.

Availability Guide for Change Management125506

4-24

Making Application Subsystem Changes Online

The Pathway Environment

The NonStop TM/MP core service must be started, monitored, and maintained as a separate subsystem. Usually, the Tandem system administrator performs these tasks. (Each NonStop system includes one—and only one—instance of the NonStop TM/MP product, which is used by many subsystems.)

The Pathway Environment