Availability Guide for Change Management

(1)

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

(2)

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.

Document History

Part Number Product Version Published

103394 N.A. December 1994

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).

(3)

Availability Guide for Change Management–125506

iii

New and Changed Information

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

Product/Feature/Enhancement Sections Affected

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.

Sections 3, 5, and 7

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.

(4)

New and Changed Information

iv

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 3 and 7

(5)

v

2. Change Control

Overview 2-1

What Is Change Control? 2-1

Implementing Change Control Successfully 2-2 The Change-Control Process 2-2

Phase 1—Definition and Documentation 2-3 Phase 2—Change Planning 2-6

Phase 3—Implementation 2-9 Phase 4—Verification 2-9 Process Flow Diagram 2-10

3. Making System Software and Hardware Changes Online

Overview 3-1

System Software Changes 3-1

Software Configuration Changes 3-1

(6)

Contents

vi

4. Making Application Subsystem Changes Online

Installing an IPM 3-2 Hardware Changes 3-2

Performing Common Hardware Changes Online 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 3-4

Adding, Upgrading, and Moving Disk Drives Online 3-5 Updating Firmware Online 3-6

Where to Find More Information 3-7

4. Making Application Subsystem Changes Online

Overview 4-1

Overview of the Tandem Application Environment 4-1 Transaction-Processing Core Services 4-1

The Transaction-Processing Application Environments 4-2

Client/Server Computing and the Tandem Application Environment 4-3 Making Changes to NonStop TS/MP Online 4-5

Overview of NonStop TS/MP 4-5

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 4-16 Overview of NonStop TM/MP 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 4-22 The NonStop TUXEDO Environment 4-22

The Pathway Environment 4-25

5. Making Communications Subsystem Changes Online

Overview 5-1

Overview of Communications Subsystems 5-1 I/O Processes 5-1

(7)

Contents

vii

6. Reducing the Time Required for Planned Outages Expand 5-3

Device-Specific Connections 5-3 SNA Network Connections 5-3 OSI Network Connections 5-3 LAN Connections 5-4

TCP/IP Network Connections 5-4

Common Communications Subsystem Changes 5-4 Changes You Can Perform Online 5-4

Communications Subsystem Tool 5-4 Communications Subsystems Summary 5-5 Where to Find More Information 5-7

6. Reducing the Time Required for Planned Outages

Overview 6-1

Minimizing the Frequency of Planned Outages 6-1 Anticipating and Planning for Change 6-1 Can the Change Be Performed Online? 6-4

Reducing System and Application Startup and Shutdown Time 6-4 Writing Efficient Startup and Shutdown Command Files 6-4 Using Parallel Processing 6-6

Product-Specific Techniques 6-7

Reducing Downtime When Installing a New Operating System 6-8 Testing Your Plans 6-8

Reducing Application Downtime With DSM/SCM 6-9 6-10

7. Tools for Online Change

Overview 7-1

Subsystem Control Facility (SCF) 7-1 SCF Interface 7-1

How SCF Works 7-2

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 7-6 TSM Components 7-6 Incident Reports 7-8

(8)

Contents

viii

Glossary

Where to Find More Information 7-9 NonStop TS/MP Management Tools 7-9

NonStop TS/MP Management Interfaces 7-10

How the NonStop TS/MP Management Interfaces Work 7-10

Considerations and Limitations of the NonStop TS/MP and Pathway/TS Management Interfaces 7-11

PATHCOM Command Example 7-11 Where to Find More Information 7-12 NonStop SQL/MP Management Tools 7-12

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 7-14

Considerations and Limitations of the TMF Management Interfaces 7-15 TMFCOM Command Example 7-15

Where to Find More Information 7-15

Glossary

Index

Figures

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

Environment 4-17

Figure 4-5. NonStop TUXEDO Transaction-Processing Environment 4-23 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

(9)

Contents

ix

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 Table 4-4. Data-Volume Configuration Changes 4-19 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

(10)

Contents

(11)

xi

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.

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

These kind of readers... Look for this kind of information...

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

Configuration planners, support planners, and installers

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

(12)

About This Manual

xii

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.

(13)

About This Manual

xiii

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.

(14)

About This Manual

xiv

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.

(15)

xv

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:

(16)

Notation Conventions

xvi

(17)

1 -1

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.

(18)

Introduction to Change Management

1 -2

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

(19)

1 -3

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

(20)

1 -4

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.

(21)

1 -5

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.

(22)

1 -6

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

(23)

1 -7

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.

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

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

(24)

1 -8

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.

(25)

1 -9

Change Management and the OM Model

•

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

(26)

1- 10

(27)

2 -1

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

(28)

Change Control

2 -2

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).

(29)

Change Control

2 -3

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:

(30)

Change Control

2 -4

•

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.

(31)

Change Control

2 -5

Figure 2-1. Planned Outage Request Form

CDT 001

Planned Outage Request Form

REQUESTED BY

DATE REQUEST FORM SUBMITTED DATE OF OUTAGE TRACKING NUMBER Maximum (Minutes) 60 Requested (Minutes) Actual (Minutes) 30 60 Application/system shutdown

Downtime work (move files, add hardware, SQL compiles, etc.)

System load

System and subsystem startup

Application startup cold start

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:

(32)

Change Control

2 -6

Phase 2—Change 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.

(33)

Change Control

2 -7

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?

(34)

Change Control

2 -8

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.

(35)

Change Control

2 -9

Phase 3—Implementation

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).

(36)

Change Control

2- 10

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.

(37)

Change Control

2- 11

Process Flow Diagram

Figure 2-2. Change-Control Process Flow Change Plan:

- Sequence of events - Schedule

- Contingency or recovery plan - Test and verification plans

"Go/No Go" decision points

Contingency or recovery plan

Stable system - change implemented

Stable system -change not implemented

Perform postmortem, continuous improvement Implement step "No Go" Last step Next step Start sequence of events Test and verification "OK" Not "OK"

(38)

Change Control

2- 12

(39)

3 -1

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

(40)

Making System Software and Hardware Changes Online

3 -2

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.

(41)

Making System Software and Hardware Changes Online

3 -3

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.

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.

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