Availability Guide For CHG MGMT - 125506

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
125506
Published
December 1996
Release ID
G01.00
Document History
Part Number 103394 119224 125506 Product Version N.A. N.A. N.A. Published December 1994 December 1995 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 SoftwareRestricted 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 FARSUP 18-52227-79 (April1985) Commercial Computer SoftwareRestricted Rights (April1985). If the contract contains the Clause at 18-52227-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 Management125506 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:
Sections Affected Sections 1, 3, and 6
Sections 4, 5, and 6
Sections 3 and 7
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.
Availability Guide for Change Management125506 iv
Contents
New and Changed Information About This Manual xi Notation Conventions xv iii
1. Introduction to Change Management

Overview 1-1 What Causes Change? 1-1 Change and the Cost of Downtime 1-1 Increasing Availability by Effectively Managing Change 1-2 What Is Change Management? 1-2 Anticipating and Planning for Change 1-2 Controlling the Introduction of Change 1-3 Installing and Implementing Changes 1-3 Meeting the Goals of Change Management 1-5 Making Changes Online 1-5 Reducing the Time Required for Planned Outages 1-6 Measuring Outages 1-6 Measuring Outages by Outage Minutes 1-7 Measuring User Outage Minutes in a Client/Server Environment 1-7 Alternate Ways of Measuring Outages 1-7 Change Management and the OM Model 1-8
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 1Definition and Documentation 2-3 Phase 2Change Planning 2-6 Phase 3Implementation 2-9 Phase 4Verification 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 Installing a New Operating System Release
3-2
Availability Guide for Change Management125506 v
Contents
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 Overview of Communications Products 5-3
Availability Guide for Change Management125506 vi
Contents
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 TSM EMS Event Viewer 7-9
Availability Guide for Change Management125506 vii
Contents
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. Figure 2-2. Figure 4-1. Figure 4-2. Figure 4-3. Figure 4-4. Figure 4-5. Figure 4-6. Figure 5-1. Figure 7-1. Figure 7-2. Figure 7-3. Figure 7-4. Planned Outage Request Form 2-5 Change-Control Process Flow 2-11 The Tandem Application Environment 4-3 A Traditional NonStop SQL/MP Database System 4-10 NonStop SQL/MP in the Client/Server Environment 4-11 The TMF Subsystem in a Traditional Transaction-Processing Environment 4-17 NonStop TUXEDO Transaction-Processing Environment 4-23 Pathway Transaction-Processing Environment 4-26 User Process Communicates With I/O Process 5-2 How SCF Works 7-2 How the Pathway Management Interfaces Work 7-11 How SQLCI Works 7-13 TMFCOM and Management Application Program Interfaces 7-15
Tables
Availability Guide for Change Management125506 viii
Contents
Table 1-1. Table 3-1. Table 3-2. Table 4-1. Table 4-2. Table 4-3. Table 4-4. Table 4-5. Table 4-6. Table 4-7. Table 4-8. Table 5-1. Table 6-1. Table 6-2. Table 6-3. Table 7-1.
Outage Minutes per Year (24-Hour by 7-Day by Year-Round Clock) 7 Where to Find System-Specific Installation and Configuration Information 3-8 Where to Find Additional Configuration Information 3-8 PATHMON Object Changes 4-7 Summary of NonStop TS/MP Changes 4-8 Audit-Trail Configuration Changes 4-18 Data-Volume Configuration Changes 4-19 Autoabort Configuration Changes 4-19 Audit-Dump Configuration Changes 4-20 TMF Catalog Configuration and Entry Changes 4-20 Summary of TMF Changes 4-21 Summary of SCF-Supported Communications Subsystems 5-5 Performance-Management Tasks 6-2 Tools for Evaluating System Performance and Growth 6-2 Where to Find Information About Online Change 6-4 SCF Online Reconfiguration Commands 7-2
1-
Availability Guide for Change Management125506 ix
Contents
Availability Guide for Change Management125506 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 Management125506 xi
About This Manual
Whats in This Manual?
Whats 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 Management125506 xii
About This Manual
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 transactionprocessing (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 Management125506 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 Management125506 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 Management125506 xv
Notation Conventions
Syntax Notation
Availability Guide for Change Management125506 xvi
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 avoidedit 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 customernot the businessdetermines 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 Management125506 1 -1
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 airlines 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-aday, 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
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
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.
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 reduceor 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.
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-users 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 outagesand how to predict, prevent, and prepare for themare 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 changesas 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-users 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 users
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 changessuch as installing a new operating system releaseobviously 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 Outage Minutes/Year* User Impact* 90% 50,000 35 days 99% 5,000 3.5 days 99.9% 500 8.3 hours 99.99% 50 50 minutes 99.999% 5 5 minutes 100% 0 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
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 is one of the operations-management disciplines defined in Tandems 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 managementincludes the day-to-day tasks performed by operations personnel who operate and manage the production environment Problem managementincludes the tasks required to manage and administer the problem environment Configuration managementincludes the tasks required to manage and administer the configuration of system software and hardware, application subsystems, communications subsystems, and application software Security managementincludes the security features necessary to implement a secure, audited, operations environment Performance managementincludes 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.
The Availability Guide for Performance Management describes how to manage the performance of your NonStop system.
Availability Guide for Change Management125506 1- 10
Change Control
Overview
Making changes to your system and application environment can increase the effectiveness of your operationsor 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 systems security at risk. If there are no controls, frequent changes and changes by unauthorized personnel may damage the stability of your system.
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 1Definition 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 2Change 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 3Implementation. In this phase, the person or group responsible for change control implements the change according to the change plan created during the changeplanning phase (phase 2).
Change Control
Phase 1Definition and Documentation
Phase 4Verification. 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 Tandems Web page at: http://www.tandem.com/MENU_PGS/ALLIANCE/ALL_SSD.HTM.

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.
Change Control
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.
Change Control
Figure 2-1. Planned Outage Request Form

Planned Outage Request Form
REQUESTED BY DATE REQUEST FORM SUBMITTED DATE OF OUTAGE TRACKING NUMBER
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
BRIEFLY DESCRIBE THE REASON FOR THE OUTAGE:
Maximum (Minutes) 60
Requested (Minutes)
Actual (Minutes)
30 30 60 30 30
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
Change Control
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.
Change Control
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?
Change Control
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.
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 3Implementation
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 4Verification
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. 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.
If a problem occurs during verification, perform the following tasks:
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.

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.
Change Control
Figure 2-2. Change-Control Process Flow

Change Plan: - Sequence of events - Schedule - Contingency or recovery plan - Test and verification plans
Start sequence of events Implement step
Next step
"No Go" "Go/No Go" decision points
Last step
Contingency or recovery plan
Test and verification
Not "OK"
"OK" Stable system - change implemented Stable system change not implemented
Perform postmortem, continuous improvement
Change Control
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 reduceor even eliminateplanned 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 stepby-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.
SCF is Tandems 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.

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.
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.
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 softwareconfiguration 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 Online on 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.
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 systemspecific. 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.
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. Firmware is a type of microcodethat 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.
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
Online Firmware Update Procedure

Updating firmware online consists of three steps: 1. Checking the firmware status 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-todate 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.

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
Table 3-2 lists manuals that contain additional configuration information.

Table 3-2. Where to Find Additional Configuration Information

Manual DSM/SCM Users Guide Subsystem Control Facility (SCF) Reference Manual for G-Series Releases SCF Reference Manual for the Storage Subsystem System Generation Manual for G-Series 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.
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 transactionprocessing 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 highperformance, 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 transactionprocessing applications A choice of transaction-processing application environments
Transaction-Processing Core Services

The core services include the following software products:
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, Tandems 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.
Client/Server Computing and the Tandem Application Environment
Figure 4-1. The Tandem Application Environment

User Applications
NonStop TUXEDO Middleware NonStop TS/MP
PTP NonStop TM/MP
Pathway NonStop SQL/MP
TP Monitor Choices
Core Services Operating System Open System Services (OSS) Environment Tandem NonStop Kernel
003
Guardian Environment
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

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 requester refers 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 client refers 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.
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 Tandems 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, orin the client/server environmentPC, 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.
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 transactionprocessing 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:
PATHCOMA command interpreter used to communicate interactively with PATHMON to configure and manage the NonStop TS/MP core service. NonStop TS/MP management programming interfaceA set of programmatic commands that allows a management application to communicate directly with PATHMON. You typically write management applications to automate operator functions.
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 transactionprocessing 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.
Table 4-1. PATHMON Object Changes

Object must be stopped? Type of change Changing backup processors and dump files Exchanging primary and backup processors Deleting objects Object PATHMON TCP* PATHMON TCP* TCP* TERM* PROGRAM* SERVER TCP* TERM* PROGRAM* SERVER X X X X X X X X Yes No X X X X
Altering object attributes
* 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.
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 Adding or replacing hardware Adding or deleting objects controlled by PATHMON Altering attributes of objects controlled by PATHMON Increasing the maximum number of objects controlled by PATHMON Changing the owner and security attributes NonStop system Available Available Available Application Available. Available. May affect availability if the object must be stopped before it is altered. You must shut down your PATHMON environment. You must shut down your PATHMON environment.
Available Available

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 Manual NonStop TS/MP and Pathway Management Programming Commands 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.
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 easilyyou 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. For a more complete overview of NonStop SQL, see the Introduction to NonStop SQL/MP.
Overview of NonStop SQL/MP

NonStop SQL/MP is a relational-database-management system that uses the ANSIstandard 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, lineoriented, 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 statementsSQL statements can be entered directly from a terminal.

Overview of NonStop SQL/MP
SQLCI commandsSQLCI commands enable you to set and display the SQLCI environment. Report WriterA full-function report-writing facility that formats custom reports. UtilitiesA full set of utilities that provide quick access to information about the database, the data dictionary, and the application programs.
Programmatic SQLThe 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 SQL Statements Business Professional Commands Report Writer Utilities Database Administrator Programmatic SQL Application Programmer Data Dictionary Database
Data Dictionary
Business Data
OLTP Applications Application User
Business Data
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) Client (PC, Macintosh, or workstation)
Client A SQL statements Data
ODBC
Database driver
NonStop SQL/MP DAL
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
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 partitiona partition that contains no data and that you never movefor 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 PLANSThis 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 PLANSThis 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
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:
REGISTERONLYThis 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. NOREGISTERThis 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.
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.

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 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
NonStop SQL/MP Version Management Guide
The following manuals contain additional information about NonStop SQL/MP databases:
Manual Introduction to NonStop SQL/MP NonStop SQL/MP Query Guide 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
NonStop SQL/MP Report Writer Manual NonStop SQL/MP Messages Manual
NonStop SQL/MP programming manuals for C, COBOL85, TAL, and Pascal
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. For a more complete overview of NonStop TM/MP, see the Introduction to NonStop Transaction Manager/MP (TM/MP).
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.
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:
TMFCOMthe TMF interactive command interface. TMFCOM allows commands to be entered and responses to be received through a terminal keyboard and monitor. TMFSERVEthe 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 transactionprocessing environment. Figure 4-4. The TMF Subsystem in a Traditional Transaction-Processing Environment
Tandem NonStop System
Transaction Entry
OLTP Software
Database
User terminals
TMF Subsystem
Log of Transaction Records (Audit trail)
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
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.

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 Adding or deleting an active audit volume Adding or deleting an overflow audit volume Adding or deleting a restore audit volume Adding or deleting an entire audit trail Increasing or decreasing the number of files that reside on each active audit volume Increasing or decreasing the overflow threshold Increasing or decreasing the begintransaction-disable threshold Setting or resetting audit-trail file size NonStop system Available Available Available Available Application Available Available Available Requires the TMF subsystem to be stopped and the TMF configuration to be deleted Available
Available
Available Available Available
Available Available Requires the TMF subsystem to be stopped and the TMF configuration to be deleted
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 Adding or deleting a data volume Resetting the recovery mode Renaming a data volume NonStop system Available Available Available Application Available. 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). Application access to the data volume may need to be stopped.
Moving a data volume to another system
Available
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 Increasing or decreasing the autoabort threshold Resetting the autoabort value NonStop system Available Available Application 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.
Table 4-6. Audit-Dump Configuration Changes

Impact on Availability Type of change Altering the block size for tape dumps Altering the number of tape copies Altering the tape verification value Changing the method used for making multiple tape copies Changing the system on which audit-trail files are dumped Changing the disk media used for audit-trail file dumps NonStop system Available Available Available Available Available Available Application Available Available Available Available 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 Adding or deleting tape media from the TMF catalog Adding or removing online dumps or audit dumps from the TMF catalog Changing TMF catalog attributes Changing the state of an existing online dump or audit dump Changing the status of an existing tape volume in the TMF catalog NonStop system Available Available Available Available Available Application Available Available Requires the TMF subsystem to be stopped Available Available
Summary of TMF Changes

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

Impact on Availability Type of change Changing the audit-trail configuration NonStop system Available Application 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. Renaming or moving a data volume may require application access to the data volume to be stopped; other changes do not affect availability. Available. Available. Changing TMF catalog attributes requires the TMF subsystem to be stopped; other changes do not affect availability.
Changing the data-volume configuration
Available
Changing the autoabort configuration Changing the audit-dump configuration Changing TMF catalog attributes
Available Available Available

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
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 Provides an overview of each of the TP monitoring environments Describes the changes you can make to each of the TP monitoring environments online
This subsection:
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 Tandems implementation of Novell, Inc.s TUXEDO enterprise-transactionprocessing (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.
Figure 4-5. NonStop TUXEDO Transaction-Processing Environment

Tandem NonStop Series/RISC (TNS/R) System OSS Environment Core Services Guardian Environment
NonStop Transaction Services/MP (NonStop TS/MP) Server Class Workstation Clients NonStop TUXEDO Transaction Monitor (System/T) NonStop SQL/MP
NonStop TUXEDO Server
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.
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.
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 oneand only oneinstance of the NonStop TM/MP product, which is used by many subsystems.)

The Pathway environment provides a client/server model for both terminal-based and workstation-based applications and the benefits of the Tandem fundamentals. Transactions can be initiated by workstations, terminals, intelligent devices, and general devices. The Pathway environment always includes the NonStop TS/MP core service product (the PATHMON process, the LINKMON process, and the PATHCOM interface). Depending on your configuration, a Pathway environment might also include the following components, as shown in Figure 4-6:
The Remote Server Call (RSC) product for workstation-based applications The Pathsend API for process-to-process communication The GDSX facility for general devices The Pathway/Transaction Services (Pathway/TS) product for terminal-based applications
Figure 4-6. Pathway Transaction-Processing Environment

RSC Tandem NonStop System Guardian Environment
Personal Computers
RSC
Workstations Pathsend Remote System Pathsend Requesters
NonStop TS/MP
LINKMON
Server Class
Server GDSX PATHMON GDSX
Database
General Devices Pathway /TS
TCP Terminals
IDS TCP Automated Teller Machines
CDT 008
RSC
The RSC product enables PC, Macintosh, or workstation applications to access Pathway servers and other Tandem NonStop servers on the Tandem host system. RSC resides in both the client and server environments. The workstation is the client; the Tandem host system, with its Pathway transaction-processing software, is the server. The client environment contains the client program, which includes RSC procedure calls, and communications subsystems that handle the tasks involved in sending requests and receiving replies. Communications subsystems support asynchronous, X.25, TCP/IP, NetBIOS, and IPX/SPX links. The primary RSC component in the server environment is the Transaction Delivery Process (TDP), a multithreaded gateway process that handles message routing within the Pathway environment in conjunction with the Pathsend API or the Pathway/TS terminal control process (TCP). The TDP communicates with the workstation through the RSC communications subsystem (RSC CSS) on the workstation. The TDP translates RSC procedure calls from the client program into the same interprocess communication (IPC) message format used between Pathway requesters and servers in the NonStop system environment.
Pathsend
The Pathsend API is a set of procedure calls for communicating with servers on a Tandem NonStop system. Applications residing on a remote system can access Pathway servers on a Tandem NonStop system by communicating with Pathsend requesters. Pathsend requesters can also access NonStop TUXEDO servers.
GDSX Facility
The Extended General Device Support (GDSX) communications subsystem product simplifies the development of front-end processes and back-end processes for communication with I/O devices. These devices can be of any type, including workstations, terminals, ATMs, point-of-sale (POS) devices, and industrial robots.
Pathway/TS
Pathway/TS is a product that supports the client/server model for terminal-based applications. Pathway/TS consists of the following components:
SCREEN COBOL compilerThe procedural language compiler used by application programmers to develop SCREEN COBOL requester programs. SCREEN COBOL Utility Program (SCUP) The utility program used by SCREEN COBOL programmers to access and manage the screen program object libraries. Terminal Control Process (TCP)The process that interprets and executes SCREEN COBOL requester programs and controls the I/O devices and processes on which the transaction-processing applications run. These functions are performed by a LINKMON process if the requester program is written in C, COBOL85, Pascal, pTAL, or TAL.
Intelligent Device Support (IDS) FacilityA facility that increases the number of device types that can be handled by the TCP, thereby extending access to Pathway server classes to a wide range of intelligent devices. IDS is part of the TCP.
Pathway Environment Changes You Can Perform Online

Although the administrative environments for each of the client and requester environments differ, there is only one administrative environment for Pathway servers. Pathway administrators can configure and control the Pathway server environment in one of two ways:
Interactively by entering PATHCOM commands at a terminal Programmatically by writing a management application that uses a management programmatic interface
Both of these methods enable administrators to send commands and instructions to PATHMON, the process that monitors the Pathway server and Pathway/TS requester environments and directs their activities. The PATHCOM Interactive Interface The PATHCOM interactive interface provides a rich set of commands for defining and managing the Pathway server environment. Using PATHCOM, administrators can:
Configure server objects Start and stop server objects Obtain status information Request performance statistics
The PATHCOM interface also provides a full set of commands for managing the Pathway/TS requester environment. Using PATHCOM, administrators can: Configure and manage TCPs Configure and manage terminals Obtain statistics about TCP and terminal resources
For example, you might want to add a TERM (a PATHMON object that defines a dedicated input/output device) to a specific TCP, add another TCP, or add an external TCP to ease PATHMONs workload. For more information about managing the Pathway environment using the PATHCOM interactive interface, see the following manuals:
NonStop TS/MP and Pathway System Management Guide NonStop TS/MP and Pathway Management Reference Manual
The Management Programming Interface The Pathway management programming interface is a set of Subsystem Programmatic Interface (SPI) procedures that allows a management application to communicate directly with the PATHMON process to manage both the Pathway server and Pathway/TS requester environments.
For more information about managing the Pathway environment using the management programming interface, see the following manuals:
NonStop TS/MP and Pathway Management Programming Commands Manual NonStop TS/MP and Pathway Management Programming Messages Manual
RSC Changes You Can Perform Online Administrators configure and control the TDP and the RSC environment by using the Remote Server Call command interface (RSCCOM). All dynamic modifications to the TDP are temporary. When the TDP is stopped and restarted, TDP object attributes are reset to the system defaults. To retain modifications, you must place values in a configuration file that can be reexecuted at each startup using the STARTRSC OBEY file. For more information on managing RSC objects, see the Remote Server Call (RSC) Installation and Management Guide. GDSX Requester Changes You Can Perform Online Administrators can use the Subsystem Control Facility (SCF) to configure and manage a GDSX communications subsystem. Administrators can also use the SPI to write management programming applications that automate various system management and error-handling tasks. For information on using SCF to manage GDSX, see the SCF Reference Manual for GDSX. For information about using SPI to write management applications to manage GDSX, see the GDS Management Programming Manual.
Making Communications Subsystem Changes Online

Overview
In the Tandem environment, a software product that provides users with access to a set of communications services is called a communications subsystem. Because connectivity is an important part of online transaction processing (OLTP), Tandem offers a variety of communications products. These products extend the OLTP power of your NonStop system by supporting a wide range of application and networking configurations. 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 attributes. This section provides information to help you reduce or eliminate planned outages by:
Identifying common communications subsystem changes that you can perform online. An 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. Describing the tools you can use to make communications subsystems changes online. Telling you which manuals contain communications subsystem change information.
Overview of Communications Subsystems

Communications subsystems vary in the functions they provide and in the resources they manage. Many subsystems allow applications to communicate with specialized devices; a few subsystems exist to perform management services or to provide management interfaces to other communications subsystems. The part of a Tandem communications subsystem that runs in the NonStop system is implemented as one or more processes. A communications subsystem usually consists of system and user processes provided by Tandem. The system processes that make up a communications subsystem are called input/output (I/O) processes. To understand how changes are made to communications subsystems, you first need to understand how Tandem I/O processes work.
I/O Processes
I/O processes manage communication with I/O devices, such as disks, printers, orin the case of communications subsystemscommunications lines. An I/O process pair logically owns one or more I/O devices or communications lines. The devices or lines are physically connected to the system through a ServerNet addressible controller (SAC); the I/O process pair runs in the pair of processors to which the SAC is attached.
I/O Processes
To use any device or communications line, other processes send requests to the I/O process that owns the device or line. The I/O process, in turn, calls its own procedures to handle the protocols of the devices or lines it controls and to achieve the physical transfer of data. Figure 5-1 illustrates how calls are passed from a user process to an I/O process, and then to physical devices or communications lines: 1. The user process obtains access to subsystem resources by issuing operating system procedure calls to the file system, identifying the resource and the action to be performed. 2. The file system determines the location of the resource and passes the request to the message system, which in turn passes it to the appropriate I/O process. 3. The I/O process manipulates the data communications resource on behalf of the user process, using a ServerNet addressible controller. Figure 5-1. User Process Communicates With I/O Process
1
User Process
File System
2
Message System
I/O Process
ServerNet Addressable Controller
Device or Network
CDT 009
Overview of Communications Products
Overview of Communications Products

The communications products provided by Tandem can be organized in the following categories:
The Expand network Device-specific connections SNA network connections OSI network connections (including X.25) Local area network (LAN) connections TCP/IP network connections
Note. If you are already familiar with Tandems communications products, you may want to skip the following information and proceed to Common Communications Subsystem Changes on page 5-4.
Expand
The Expand subsystem is the Tandem network software used to connect NonStop systems. It extends the operation of the Tandem NonStop Kernel to dispersed nodes. The Expand subsystem can logically connect as many as 255 geographically distributed NonStop systemsup to a total of 4,080 processorsinto an integrated network. One important feature of an Expand network is its availability. The Expand subsystem is designed to support applications requiring 24-hour-a-day, 7-day-a-week, 365-day-ayear operations. If a communications line fails, communications are rerouted automatically; there is no need for operator or application intervention.
Device-Specific Connections
Device-specific connections include communications software that permits communication between Tandem applications and a variety of devices. The devices can range from workstations to automatic teller machines, factory robots, gasoline pumps, and hand-held devices.
SNA Network Connections

SNA network connections include products and facilities that allow Tandem systems and networks to communicate with IBM SNA systems and networks. These interfaces include batch and interactive SNA device emulation and distributed OLTP. The Tandem SNAX product family is the group of products that enables Tandem OLTP applications to be incorporated into an existing SNA network.
OSI Network Connections

Open Systems Interconnection (OSI) network connections include products that implement the standards of the OSI architecture, including the ITU-T recommendation for packet-switching networks (X.25). These products enable Tandem networks to integrate with systems and devices of other vendors providing OSI and X.25 implementations.
LAN Connections
LAN Connections
LAN connections include products that allow NonStop systems, workstations, and other systems and devices to communicate across LANs. Tandem offers LAN interface products based on standard and de facto standard LAN protocols. Tandem LAN connectivity allows NonStop systems and Expand networks to be integrated with existing LANs.
TCP/IP Network Connections

Tandems TCP/IP products can be used to integrate NonStop systems with UNIX systems, multivendor host networks, and workstations using the TCP or related User Datagram Protocol (UDP) and IP.
Common Communications Subsystem Changes

Because Tandem provides so many communications subsystems, it is not possible in this section to describe all of the potential changes to every subsystem. However, the types of changes you want to make, and how you make changes, are often common to multiple subsystems. This subsection describes the types of changes and tools that are common to most communications subsystems.
Changes You Can Perform Online

Making changes to a communications subsystem does not require the NonStop system to be shut down, anddepending on network and application design considerations changes may be made without affecting application availability. The following are common communications subsystem changes that can be performed online:
Adding communications lines, devices, and subdevices Deleting communications lines, devices, and subdevices Altering the characteristics of communications lines, devices, and subdevices
The following subsection describes the tool you can use to make these changes online.
Communications Subsystem Tool

Many of the operational attributes of communications subsystems can be changed online using the Subsystem Control Facility (SCF).
SCF
SCF is a management application within the Distributed Systems Management (DSM) architecture. You can use SCF to make changes to most communications subsystems without having to take your NonStop system down. Table 5-1 on page 5-5 lists the communications subsystems that can be changed with SCF. SCF provides a series of commands that operate on objects belonging to each communications subsystem. Each communications subsystem has its own set of object types relevant to the subsystems configuration and implementation.
Communications Subsystems Summary
Depending on the communications subsystem, you may be able to use SCF commands to perform the following changes online:
Add communications lines, devices, and subdevices Delete communications lines, devices, and subdevices Alter the characteristics of communications lines, devices, and subdevices
SCF cannot modify I/O processes while they are runningthe I/O process must be stopped, altered, and then restarted. Stopping an I/O process may affect application availability. For more information about SCF, refer to Section 7, Tools for Online Change.

Table 5-1 lists the communications subsystems that can be controlled by SCF, followed by a description. The information in Table 5-1 is current as of the publication date of this manual. Products that do not support SCF are being modified over time to support these interfaces. Consult the Subsystem Control Facility (SCF) Reference Manual for GSeries Releases for the most up-to-date list of supported subsystems. Table 5-1. Summary of SCF-Supported Communications Subsystems (page 1 of 2)
Communications Product ATP6100 CP6100 ENVOYACX EXPAND GDS IPXSPX OSIAPLMG Description Asynchronous Transfer Protocol Communications Process subsystem Bit-synchronous communications data linklevel interface (EnvoyACP/XF) Expand line handler General Device Support Internet Packet Exchange Sequenced Packet Exchange Tandem Open Systems Interconnection/Application Manager (OSI/APLMGR) Tandem Open Systems Interconnection/Application Services (OSI/AS) Tandem Open Systems Interconnection/Common Management Information Protocol (OSI/CMIP) Tandem Open Systems Interconnection/File Transfer, Access and Management (OSI/FTAM) Tandem Open Systems Interconnection/Message Handling System (OSI/MHS)
OSIAS OSICMIP
OSIFTAM
OSIMHS
Table 5-1. Summary of SCF-Supported Communications Subsystems (page 2 of 2)

Communications Product OSITS OSS QIO SCP SCS SNAX Description Tandem Open Systems Interconnection/Transport Services (OSI/TS) Open System Services Tandem Queued I/O product Subsystem Control Point SQL Communication Subsystem Tandem SNAX/Extended Facility (SNAX/XF) and Tandem SNAX/Advanced Peer Networking (SNAX/APN) Tandem SNAX/Advanced Program Communication (SNAX/APC) Tandem SNAX/Creator-2 (SNAX/CRE) Tandem SNAX/High-Level Support Simple Network Management Protocol Agent Tandem Transmission Control Protocol/Internet Protocol (TCP/IP) Tandem Telserv product Tandem X.25 Access Method
SNAXAPC SNAXCRE SNAXHLS SNMP TCPIP TELSERV X25AM

The following table lists the manuals that describe the commands and procedures used to perform the online changes described in this section.
For information on this topic Making changes with SCF Read these manuals Subsystem Configuration Facility (SCF) Reference Manual for G-Series Releases Each communications subsystem that can be changed with SCF also has its own SCF manual. For example, the Expand subsystem is described in the SCF Reference Manual for Expand. Reconfiguration procedures are usually described in the configuration, operations and management, or reference manual for the particular communications subsystem. For example, the Expand Network Management Guide explains how to reconfigure the Expand subsystem.
Reconfiguring your communications subsystem (general procedures)

Overview
Your NonStop system is designed so that most changes can be performed while the system is 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 are usually performed during a planned outage. A planned outage is system or application downtime that is planned or scheduled. This section describes ways to help you reduce the time required for planned outages by:
Showing you how to minimize the frequency of planned outages Describing techniques you can use to reduce system and application startup and shutdown time Explaining how you can reduce the time required to install a new version of the operating system
Minimizing the Frequency of Planned Outages

You can minimize the frequency of planned outages by:
Anticipating and planning for change Determining whether the change you want to make can be done online rather than offline

Anticipating and planning for change is a key requirement for maintaining 24-hour-aday, 7-day-a-week, 365-day-a-year operations. By taking the time to anticipate and plan for changes, you can avoid taking your NonStop system down for unnecessary planned outages. The following are areas in which you can take action now in order to prevent planned outages in the future:
Evaluating system performance and growth Providing adequate computer room resources Configuring your system with change in mind
Evaluating System Performance and Growth

Evaluating system performance and growth involves tracking and anticipating growth, then establishing plans to accommodate that growth. Table 6-1 describes some common performance-management tasks and how each task can help you plan for growth.
Table 6-1. Performance-Management Tasks

Task Application sizing What it involves Forecasting the effects of new applications on your system through the use of models to determine how well new applications will handle their intended workloads. Application sizing helps you plan for growth in system workloads caused by new applications. Forecasting future capacity needs based on performance trends and the growth in users, applications, and your companys business. Capacity planning helps you plan for growth in system workloads based on business growth. Measuring system performance and acting on the results of the measurements in order to improve system performance and availability. Tracking the use of system resources for accounting purposes. Usage accounting helps you plan for system growth if user activity is known in sufficient detail.
Capacity planning
Performance analysis and tuning
Usage accounting
Tandem provides a wide variety of tools that provide data useful for your growth forecasts. These tools can help you determine future resource needs by providing information on percentage growth in disk utilization, processor utilization, and I/O. Table 6-2 lists some of the tools available to help you forecast growth. Table 6-2. Tools for Evaluating System Performance and Growth
Tool Measure Tandem Network Statistics Extended (NSX) Guardian Performance Analyzer (GPA) Tandem Capacity Model (TCM) What it does Collects and displays resource usage statistics for the local system Collects and displays resource usage statistics from multiple network nodes to one or more locations in a network Analyzes system performance data gathered by the Measure product and makes recommendations for improving overall performance of the system Collects resource usage information and converts it to transaction-oriented data that can be used for capacity planning
The Availability Guide for Performance Management describes all of Tandems performance-management tools and provides guidelines for performance-management tasks.
Note. Tandem alliance partners also offer performance-management products and services. For more information about the Alliance program, contact your Tandem representative.
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.
Configuring Your System With Change in Mind

Some changes can be performed online only if you have designed your system configuration to accommodate them. One example of this kind of change is adding new processors to your system. To add a new processor without having to take your system down, the processor must be in the operating system image (OSIMAGE) loaded on your system. Another example of configuring your system with change in mind is to select limits that allow some space for growth. For example, you can avoid shutting down your online transaction-processing environment to increase the maximum number of objects controlled by PATHMON by configuring enough objects for anticipated growth. Section 3, Making System Software and Hardware Changes Online, discusses some techniques you can use to configure your system with change in mind.
Can the Change Be Performed Online?
Can the Change Be Performed Online?

You can perform many changes to your NonStop system online. Online change is any change that can be performed while your NonStop system is still operational. Sections 4, 5, and 6 of this manual are designed to help you determine whether the changes you want to make can be performed online. Table 6-3 describes the contents of these sections. Table 6-3. Where to Find Information About Online Change
Section Number 3 Section Title Making System Software and Hardware Changes Online Making Application Subsystem Changes Online What it contains Identifies the hardware changes you can perform online. Identifies the changes you can perform online to the three key products that make up the Tandem application environmentNonStop TS/MP, NonStop SQL/MP, and NonStop TM/MP. Identifies common communications subsystem changes and the tools you can use to perform those changes online.
In some situations, online changes can affect application availability. These types of online changes require the application to become temporarily unavailable and can result in planned outages. The information in Sections 3, 4, and 5 identifies the types of online changes that can affect application availability.
Reducing System and Application Startup and Shutdown Time

An important component of many outages is the time required to start and stop your system and application. The following general techniques can help you reduce the time required to start up and shut down your system and applications:
Writing efficient startup and shutdown command files Using parallel processing to distribute startup and shutdown processes across multiple processors
Writing Efficient Startup and Shutdown Command Files

The best way to start and stop your system and applications is by using command files. A command file is a file that contains a series of commands. When the file is executed, the commands within the file are automatically executed. Command files are supported by the Tandem Advanced Command Language (TACL) and many Tandem subsystems.
Writing Efficient Startup and Shutdown Command Files
You can improve the efficiency of your startup and shutdown command files by applying the following simple techniques:
Use command file syntax that executes quickly. Make sure that command files execute without manual intervention. Set up command files to execute in parallel.
Command File Syntax

The syntax used in command files affects the time it takes for them to execute. To make sure that your command files execute quickly:
Avoid using wild-card characters. Use single-line commands instead of multiple-line commands whenever possible.
A wild card is a characterusually an asterisk (*) or a question mark (?)used to match any character or a series of characters. When you use wild-card characters in your command files, execution time is increased because the system must look up names in a table. By using explicit names instead of wild-card characters, you can shorten execution time and allow for commands to execute in parallel. The following PATHCOM START command uses a wild-card character to start all of the TERMs defined in the PATHMON configuration file:
= START TERM *
The next PATHCOM START command uses explicit names to start all of the TERMs defined in the PATHMON configuration file:
= START TERM (TERM1, TERM2, TERM3, TERM4, TERM5, TERM6)
Note. When using explicit names, you must remember to revise your command files whenever a configuration change occurs.
When multiple-line commands are used in a command file, they increase execution time. By using single-line commands, you can reduce the time required to execute the command file. The following PATHCOM command example uses multiple lines:
= = = = RESET SERVER SET SERVER NUMSTATIC 2 SET SERVER MAXSERVERS 3 ADD SERVER XYZ
The next PATHCOM command example produces the same results as the multiple-line example shown earlier, but with a single command:
= ADD SERVER XYZ, NUMSTATIC 2, MAXSERVERS 3
Using Parallel Processing
Avoiding Manual Intervention

Write your startup and shutdown files so that they execute correctly without requiring manual intervention. Any time an operator must intervene, startup and shutdown time is lengthened. In addition, operator intervention increases the possibility of introducing unwanted errors that could further delay startup or shutdown.
Using Parallel Processing

Using parallel processing can shorten the time required to start up or shut down your system or application because startup and shutdown processes are distributed throughout the processors in your system. The following examples show how parallel processing can be used to start communications lines and a transaction-processing application in a PATHMON environment.
Example 1: Starting Communications Lines

The following command file uses parallel processing in four processors to start several communications lines. This command file also uses a special technique to handle the case of a processor that is out-of-serviceit attempts to start each SCF process in two processors. (SCF is a utility that is used to control certain communications subsystems; the files START0, START1, START2, and START3 contain the actual commands that start the communications lines.) If one of the processors is down, the command file continues to the next processor. If the processor is up, the command file still continues to the next processor but fails because the process name ($Sn) is now in use by the process that was successfully started. The result of this technique is that one process is started in the first listed processor that is up.
SCF /IN START0, NOWAIT, CPU 0, NAME $S0/ SCF /IN START0, NOWAIT, CPU 2, NAME $S0/ SCF /IN START1, NOWAIT, CPU 1, NAME $S1/ SCF /IN START1, NOWAIT, CPU 3, NAME $S1/ SCF /IN START2, NOWAIT, CPU 2, NAME $S2/ SCF /IN START2, NOWAIT, CPU 0, NAME $S2/ SCF /IN START3, NOWAIT, CPU 3, NAME $S3/ SCF /IN START3, NOWAIT, CPU 1, NAME $S3/
When using the technique shown in this command file, make sure that you spread the process workload across all available processors. If there are too many processes to start in processors 0 and 1, queueing and memory-contention problems can result. If two processors are not available, this technique may fail.
Product-Specific Techniques
Example 2: Starting a Transaction-Processing Application in a PATHMON Environment

You can reduce the time required to start a transaction-processing application in a PATHMON environment by using multiple startup command files in different processors. To implement this technique, you must divide your PATHMON configuration into convenient and related units. An example of a unit would be a terminal control process (TCP) and its terminals. Once you have divided your PATHMON configuration into units, you can divide the entire startup process into multiple startup files, one for each unit. Processing can then be distributed among the available processors in your system. The number of discrete startup units is not constrained by the number of processors you can run multiple startup processes concurrently in the same processor by invoking a TACL process with the NOWAIT option to execute the command file. However, the PATHWAY MAXPATHCOMS attribute must be set to accommodate the maximum number of PATHCOM processes that can run simultaneously within a PATHMON environment. When using this technique, make sure that you consider other processes or applications that may be using the system at the same time as the transaction-processing application. For example, if the transaction-processing application is started from a completely quiesced system, full parallel processing can be implemented. However, if the application is started while other user processes or applications are active, processor utilization of parallel processing may cause degradation of response time.
Product-Specific Techniques
The startup and shutdown techniques described in this subsection do not represent all the possible ways you can reduce startup and shutdown time. Certain products provide commands, options, or techniques that can help you reduce the time required to start up and shut down your applications. For example, NonStop TS/MP provides the cool start option and the SHUTDOWN2 command to reduce startup and shutdown, respectively. You should use the cool start option rather than the cold start option to restart an existing transaction-processing system, because it is usually much faster. The SHUTDOWN2 command provides a faster, more reliable shutdown operation than the SHUTDOWN command. Both of these techniquesand guidelines for when you should use themare described in the NonStop TS/MP System Management Manual. For information about startup and shutdown techniques for a particular product, refer to the operations and management manual for that product.
Reducing Downtime When Installing a New Operating System
Reducing Downtime When Installing a New Operating System

Tandem currently requires that you shut down your NonStop system to install any major operating system release and some critical IPMs. Using DSM/SCM minimizes your system down time in the following ways:
By requiring you to stop only applications being updated. Although the safest practice is to stop all applications, this may be unnecessary in cases where only a few files have changed. Stopping only the changed applications minimizes down time.
By placing files under fabricated names. When you apply software to a target system, DSM/SCM places the product files in their destination target subvolumes (TSVs) with fabricated file names, that is, file names that are not the actual product file names used on the target system. DSM/SCM uses fabricated file names so that the files it has just placed do not conflict with the file names of currently running programs on the target system. After stopping the affected applications, you run the DSM/SCM utility, ZPHIRNM, to rename the files to their real names.
By requiring a system load only if necessary. DSM/SCM determines whether a system load is necessary.
Testing Your Plans

Testing should include recovery procedures in case problems occur with the new version. These tests also provide a good opportunity to evaluate various ways to reduce startup and shutdown time. Section 2, Change Control, describes a change-control process that includes how to create recovery procedures. A change-control process is a process for proposing, planning, and implementing change. An efficient change-control process ensures the successful migration of a system or an application environment from one stable configuration to another. The Introduction to NonStop Operations Management includes information about recovery planning that can help you develop testing procedures.
Reducing Application Downtime With DSM/SCM
Reducing Application Downtime With DSM/SCM

DSM/SCM is a Windows-based graphical user interface product that simplifies the process of installing, configuring, and managing software for a single NonStop server or a network of NonStop servers. With DSM/SCM, most installation and management tasks can be performed without disrupting other activities on the server. DSM/SCM accepts software inputs from site update tapes (SUTs), IPMs, and customer-written and third-party applications. DSM/SCM reduces application downtime during the installation process. Installation functions are normally associated with planned outages. The objective of DSM/SCM is to reduce the number of minutes an application must be down while software is being installed. DSM/SCM achieves this by:
Simplifying the installation process and reducing the chance for error by providing point-and-click menus for easy operation and building of target configurations. Performing the maximum number of software installation tasks without affecting application availability. These tasks include copying and moving files to the appropriate subvolumes. Once files have reached their destination, application availability is affected only during a quick rename process. Dealing only with files that have changed since the last release was installed. DSM/SCM compares the new configuration with the existing configuration and automatically records those files that have changed since the last installation. DSM/SCM works with only the subset of files that has changed and eliminates the need to install the entire SUT each time you upgrade to a new operating system release. Simplifying the management of IPMs and all software revisions by providing up-todate information on current software so that you can easily determine the IPMs that are installed on any system in a distributed network of NonStop servers.
Note. DSM/SCM is not a replacement for SYSGENR. DSM/SCM determines when SYSGENR is necessary and will not run SYSGENR if SCF can be used instead.
DSM/SCM is described in the DSM/SCM Users Guide. Tandems Professional Services offers a DSM/SCM Change Management Availability Service that can assist in installing, configuring, optimizing, and making the best possible use of DSM/SCM for maximum performance and minimum downtime.
Tools for Online Change
Overview
Tandem provides a variety of tools to enable you to make changes to your hardware and software 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. This section describes the features and capabilities of the online change tools referred to in previous sections of this manual. It does not describe tools provided by companies other than Tandem. The Software and Services Directory describes third-party products. You can obtain a copy of the Software and Services Directory from your Tandem representative.
Note. The system-generation program (SYSGENR) is not discussed in this section because it is an offline tool (it requires the NonStop system to be stopped). SYSGENR is discussed in Section 6, Reducing the Time Required for Planned Outages.
Subsystem Control Facility (SCF)

SCF is a management application within the Distributed Systems Management (DSM) architecture. You can use SCF to make changes to your system configuration without having to take down your system. In the Tandem environment, SCF subsystem is the name used for software products that provide users with access to a set of communication services. The communications subsystems that can be changed with SCF are listed on page 7-3.
SCF Interface
SCF provides a series of commands that operate on objects belonging to each communications subsystem. Each communications subsystem has its own set of object types relevant to the subsystems configuration and implementation. Some examples of objects are LINE, PATH, PROCESS, and SU (subdevice). Using SCF commands, you can:
Add, alter, or delete objects (such as devices, I/O processes, and generic processes) Obtain configured or current information about objects
Table 7-1 shows the SCF commands that can be used for online reconfiguration. (Table 7-1 lists only those commands that are related to online reconfiguration; it does not list all the SCF commands.)
How SCF Works
Table 7-1. SCF Online Reconfiguration Commands

Command ADD ALTER DELETE START STOP What it does Adds an object to a communications subsystem. Changes the value of one or more attributes of a communications subsystem object. Removes an object from a communications subsystem. Starts the operation of an object after it has been added or altered. Stops the operation of an object. Usually an object must be stopped before it can be altered or deleted.
How SCF Works

SCF provides an interactive interface to an intermediate process called the Subsystem Control Point (SCP). SCP interfaces to various I/O processes performing data communications operations and services. An I/O process pair logically owns one or more I/O devices or communications lines. The devices or lines are physically connected to the system through a controller; the I/O process pair runs in the pair of processors to which the controller is attached. SCP can also be used programmatically. The programmatic interface to SCP is controlled by the SPI, which builds and retrieves information from command, response, and event-message buffers. Figure 7-1 illustrates how SCF relates to the SCP and I/O processes. Figure 7-1. How SCF Works
Management Application Process I/O Process
User Terminal
SCF
SCP
I/O Process
Command File
I/O Process
SCF Subsystems for G-Series Releases
SCF Subsystems for G-Series Releases

The following subsystems are supported by SCF for G-Series releases. Of these subsystems, the KERNEL, SLSA, STORAGE, and WAN subsystems are controlled by generic process management processes that support persistent configuration that survives a system load. Generic processes are described in the SCF Reference Manual for the Kernel Subsystem. The remaining SCF subsystems have the limitations described below under "Considerations and Limitations of SCF."
ATP6100 CP6100 ENVOYACX EXPAND GDS NonStop IPX/SPX KERNEL* OSS QIO SCP SCS SLSA* SNAX/APC SNAX/APN SNAX/CRE SNAX/XF SNAX/HLS SNMP STORAGE* Tandem OSI/APLMGR Tandem OSI/AS Tandem OSI/MHS Tandem OSI/CMIP Tandem OSI/TS Tandem TCP/IP
Considerations and Limitations of SCF
Tandem TELSERV WAN* X25AM

persistent configuration, which can survive a system load. Generic processes are described in the SCF Reference Manual for the Kernel Subsystem.
* This subsystem is controlled by a generic process management process that supports
Note. Not all the objects described in this manual are available with the current release of the operating system. Ask your local Tandem representative about the availability dates for these objects.
Considerations and Limitations of SCF

SCF cannot modify an I/O process while the I/O process is still running. To alter an I/O process, you must first stop it, alter it, and then restart it. Stopping an I/O process may affect application availability. The following subsections describe additional considerations you should be aware of when using SCF to make changes online.
Considerations for Adding, Deleting, and Altering Objects

The following considerations and limitations apply to adding, deleting, and altering objects using SCF:
Not all SCF commands are supported by every communications subsystem. The objects and attributes that can be altered, added, or deleted with SCF vary depending on the communications subsystem. SCF does not allow you to change all of the attributes that SYSGENR provides. SCF cannot be used to delete objects that were originally configured with SYSGENR.
Preserving Changes Made With SCF

The new SCF subsystems (KERNEL, SLSA, STORAGE, and WAN) created for Gseries systems differ from the SCF subsystems that exist on D-series systems in the following ways: The processes created in the new SCF subsystems are persistent. If the system comes down, these processes are automatically restarted as soon as the system is loaded. In contrast, devices and subdevices configured by older SCF subsystems must be reconfigured after a system load. If you are managing a D-series system from G-series system, you can use the old SCF commands and subsystems. The new commands and subsystems, however, have no meaning on a D-series system.
SCF Command Example
Changes made with older SCF subsystems do not survive a system load or a reload of a processor pair. You can bypass this limitation of SCF by setting up a command file that contains all of your SCF changes. Invoke this command file when the system is loaded (or have the command file execute from a system startup file) so that SCF changes are reentered.
SCF Command Example

The following example shows how you would use SCF to alter the attributes of an Expand line (LINE object). Step 1: Stop the Expand Line Use the STOP command to stop the appropriate LINE object. The following STOP command stops an Expand LINE object named $LINEX:
SCF> STOP LINE $LINEX
Step 2: Alter the Expand Line Use the ALTER command to alter the value of the attribute. The following ALTER command changes the value of the L2TIMEOUT attribute for the Expand LINE object named $LINEX:
SCF> ALTER LINE $LINEX, L2TIMEOUT 10.00
Step 3: Restart the Expand Line Use the START command to restart the appropriate LINE object. The following START command starts the Expand LINE object named $LINEX:
SCF> START LINE $LINEX

The Subsystem Control Facility (SCF) Reference Manual for G-Series Releases provides a general description of SCF, its features, and commands. Each product that has an SCF interface has its own SCF reference manual. For example, for information about using SCF with the Expand subsystem, you would read the SCF Reference Manual for Expand.
Tandem Service Management (TSM)

The Tandem Service Management (TSM) package is a client/server application that provides troubleshooting, maintenance, and service tools for your Himalaya S-series server. TSM combines and replaces many of the system maintenance functions previously provided by the Sysheath toolkit, the Tandem Maintenance and Diagnostic Subsystem (TMDS), and the Remote Maintenance Interface (RMI) product, all of which are unavailable on S-series Tandem Servers.
TSM Interface
TSM Interface
TSM consists of software components that run on your Himalaya S-series server and on a PC-compatible workstation. The TSM software on the workstation features an easyto-use GUI that contains extensive online help. Some of the tasks that can be performed using TSM include:
Starting up the system Identifying system components and configurations Displaying physical and logical views of the system configuration Displaying the current status of system components Performing maintenance actions on specified CRUs Sending problem and configuration information to a service provider Loading new system configurations Browsing event logs Monitoring system resources Implementing remote monitoring and maintenance functions
TSM Components
TSM software components run on a PC-compatible workstation (the client) and on a Himalaya S-series server (the server).
TSM Components on the Server

Certain software and hardware components on the Himalaya S-series server help to provide TSM functions by communicating with the TSM client software on the workstation. These components include the following:
TSM server software Master service processors (MSPs) and related software TSM EMS Event Viewer Server Manager and related processes
TSM Server Software The TSM server software is the major component of TSM that resides on the Himalaya S-series server. When the NonStop Kernel operating system is running, the workstation communicates with the TSM server software on the Himalaya S-series server. Master Service Processors (MSPs) When the NonStop Kernel operating system is not running, the workstation can still communicate with the Himalaya S-series server through its connection to the master
TSM Components
service processors (MSPs). (The workstation can also communicate directly with the MSPs on the Himalaya S-series server when the NonStop Kernel operating system is running.) A service processor (SP) is a physical component of the Himalaya S-series server that controls environmental and maintenance functions. The MSPs provide basic service processor functions as well as a TSM workstation port, the modem port for remote support functions, and system-load control. The enclosure containing processors 0 and 1 contains the MSP pair. Event Viewer Server Manager The Event Viewer Server Manager on the Himalaya S-series server is a persistent process that routes messages between the TSM EMS Event Viewer on the workstation and event server and summary server processes on the Himalaya S-series server. Event server processes retrieve events. A summary server is a persistent process that maintains a summary of all the events in a specified event log.
TSM Components on the Workstation

The TSM client software resides on the workstation, and comes installed on all TSM workstations provided by Tandem. The TSM client software consists of the following applications:
TSM application TSM Notification Director TSM Event Management Service (EMS) Event Viewer
TSM Application You use the TSM application to establish a connection with a Himalaya S-series server, even when the NonStop Kernel operating system is not running. When the NonStop Kernel operating system is running, you will usually communicate with the Himalaya S-series server using a service connection. A service connection provides a comprehensive service and maintenance picture of the server and is used to perform most service management tasks. When the NonStop Kernel operating system is not running, communication takes place over a low-level link. This link is used for system installation, system startup, and certain recovery operations. You can also communicate with a Himalaya S-series server over a low-level link when the operating system is running. TSM Notification Director The TSM Notification Director receives notifications and incident reports from the Himalaya S-series server, displays them, and allows you to take action or forward the incident reports to your service provider for resolution. The TSM Notification Director runs on the TSM workstation at all times, even when the TSM application is not being used.
Incident Reports
Notifications
Notifications are messages that indicate the state of resources on the Himalaya S-series server. There are two types of notifications:
TSM application notifications Service processor (SP) event messages
TSM Application Notifications TSM application notifications are generated by the TSM server software on the Himalaya S-series server. This type of notification is sent to the TSM Notification Director when something occurs that might affect the performance of a resource managed by TSM. The TSM Notification Director passes TSM application notifications to the TSM application where they are used to display up-to-date resource information. TSM application notifications are sent to all TSM workstations recognized by the Himalaya S-series server. If a single TSM workstation is configured to manage multiple Himalaya S-series servers, it will receive notifications from all of these servers. SP Event Messages SP event messages are EMS event messages that are generated by the MSPs on the Himalaya S-series server. The TSM Notification Director can gather SP event messages directly from the MSPs, allowing SP messages to be received when the NonStop Kernel operating is not running. The TSM Notification Director receives SP event messages only when the TSM application is running and a low-level link is active. The system down message is a special type of SP event message that is generated by the MSPs when all processors on the Himalaya S-series server have halted or the server has been powered off. The system down message is sent to all TSM workstations recognized by the Himalaya S-series server.
Incident Reports
The TSM server software generates two types of incident reports:
Problem incident reports Periodic incident reports
Problem Incident Reports

When critical changes occur on the Himalaya S-series serverchanges that could directly affect the availability of system resourcesthe TSM server software generates a problem incident report. You can configure the TSM Notification Director to forward (dial out) problem incident reports to a service provider. Problem incident reports refer to attachments. An attachment contains information that augments the information in the problem incident report. Every problem incident report has at least one attachmentthe dynamic configuration file (DCF). The DCF contains a description of the current system configuration on the server.
TSM EMS Event Viewer
Text and alarm attachments can also be included with a problem incident report. A text attachment is a file that you add to the incident report; it could include special information that you want to give to your service provider. An alarm attachment is a log of the alarms related to the problem being reported. Problem incident reports are forwarded only to the TSM Notification Director running on the TSM workstation configured as the primary dial-out point. If delivery to the primary dial-out point fails, problem incident reports are forwarded to the TSM Notification Director running on the TSM workstation configured as the backup dial-out point.
Periodic Incident Reports

Periodic incident reports are generated by the TSM server software at configured intervals to send current system information to your TSM workstation and to your service provider. Periodic incident reports do not include information about problems in the system. Any problem occurring when a periodic incident report is generated is noted in a problem incident report.
TSM EMS Event Viewer

The TSM EMS Event Viewer assists you in performing many of the tasks associated with viewing and monitoring various event logs. Some of the features provided by the TSM EMS Event Viewer include
Serial, summary, expanded, and detailed views of events Multiple event sources, including merged and imported logs Flexible event selection capabilities (including by subsystem, device, priority, as well as an exclusion function) Flexible event display (single line, full detail, token selection, color/emphasis encoding) Filter manipulation functions to refine and focus a view of the events Ability to define and save views
The TSM EMS Event Viewer is launched from within the TSM application.

The Tandem Service Management (TSM) Planning and Configuration Guide provides a general description of TSM, its features, and commands.
NonStop TS/MP Management Tools

Tandems application environment is a collection of software tools and files designed to facilitate the development and management of OLTP applications. NonStop TS/MP is one of the key transaction-processing core services that make up the Tandem application environment
The NonStop TS/MP product provides a central control process, PATHMON, and interfaces to this process that manage both the NonStop TS/MP core service and the optional Pathway/TS software for terminal requesters. Together, these products are referred to as the Pathway environment.

Tandem provides two ways to make changes to a Pathway environment:
Interactively using the PATHCOM command-line user interface. Programmatically, by writing a management application program that uses a set of macros to communicate directly with the PATHMON process.
These management interfaces are provided with the NonStop TS/MP product.
PATHCOM
PATHCOM consists of a set of commands that operate on objects controlled by PATHMON. An object controlled by PATHMON is an entity that can be referred to and controlled independently. Each object type performs a specific function within the system. Some examples of objects controlled by PATHMON include servers, terminals, and SCREEN COBOL requester programs. PATHCOM allows you to enter commands interactively through a terminal or from a command file or TACL script.
NonStop TS/MP and Pathway/TS Management Programming Interface

The NonStop TS/MP and Pathway/TS management programming interface is a tokenoriented interface based on SPI. SPI is part of the DSM product line.
How the NonStop TS/MP Management Interfaces Work

PATHCOM and the NonStop TS/MP and Pathway/TS management programming interface both allow you to send commands and instructions to PATHMON, the process that monitors the Pathway environment and directs its activities. PATHCOM provides an interactive interface to PATHMON. The NonStop TS/MP and Pathway/TS management programming interface acts as the interface between a management application processa SPI requester that you writeand PATHMON, which acts as the server for management purposes.
Considerations and Limitations of the NonStop TS/MP and Pathway/TS Management Interfaces
Figure 7-2 shows how PATHCOM and the NonStop TS/MP and Pathway/TS management programming interface send commands and instructions to PATHMON. Figure 7-2. How the Pathway Management Interfaces Work
PATHMON
PATHCOM
NonStop TS/MP and Pathway/TS Management Programming Interface
Command terminal
Management Application Process
CDT 011
Considerations and Limitations of the NonStop TS/MP and Pathway/TS Management Interfaces
Section 4, Making Application Subsystem Changes Online, describes the changes you can make to your Pathway environment online, including which types of changes can affect system and application availability.
PATHCOM Command Example

The following simplified example shows how you would use PATHCOM to delete a server class from a transaction-processing system. Step 1: Freeze and Stop the Server Before deleting a server, you must first freeze and then stop the server. Use the FREEZE SERVER command to stop requests from being sent to the server class. Use the STOP SERVER command to stop all server processes in the server class. The following commands freeze and stop the server class named SALES:
= FREEZE SERVER SALES = STOP SERVER SALES
Step 2: Delete the Server Once all the servers in the server class are stopped, you can delete the server class with the DELETE SERVER command. The following DELETE command deletes the server class named SALES:
= DELETE SERVER SALES

The PATHCOM interface is described in the NonStop TS/MP and Pathway Management Reference Manual. The NonStop TS/MP and Pathway Management Programming Commands Manual describes the token-oriented management programming interface to NonStop TS/MP and Pathway/TS.
NonStop SQL/MP Management Tools

NonStop SQL/MP is a relational-database-management system that supports high-speed access and updates to distributed data. NonStop SQL/MP uses SQL to create relational databases and to describe and manipulate data. NonStop SQL/MP is one of the core services that make up the Tandem application environment.
NonStop SQL/MP Management Interfaces

Tandem provides two ways to make changes to NonStop SQL/MP:
Interactively using the NonStop SQL/MP conversational interface (SQLCI) Programmatically, by embedding SQL statements in host language programs
These interfaces are provided with the NonStop SQL/MP product.
SQLCI
SQLCI is the primary interface through which database administrators create and change structures to manage data. SQLCI provides SQL DDL statements to define the database, SQL data manipulation language (DML) statements to query and modify database tables, installation commands to install NonStop SQL, a set of database management utilities, and a report-writer facility. SQL statements operate on database objects. A database object is an entity that is created, manipulated, and dropped by SQL statements. Examples of SQL objects include tables, indexes, views, constraints, and collations.
Programmatic SQL
The application programming interface to NonStop SQL/MP enables you to use SQL statements in C, COBOL85, Pascal, pTAL, and TAL host language programs to access NonStop SQL/MP databases and to control database processing.
How SQLCI Works

Figure 7-3 shows how the various components of SQLCI relate to a NonStop SQL/MP database.
Considerations and Limitations of SQLCI
Figure 7-3. How SQLCI Works

SQLCI SQL Statements Command Terminal Commands Database Host Language Program Utilities Report Writer
CDT 012
Considerations and Limitations of SQLCI

Section 4, Making Application Subsystem Changes Online, describes the changes you can make to NonStop SQL/MP online, including which types of changes can affect system and application availability.
SQLCI Example
The following example shows how you would add a catalog to an existing data dictionary using SQLCI. (A data dictionary is the collection of all catalogs and associated file labels that describe all the NonStop SQL/MP objects and programs that make up the database.) Use the CREATE CATALOG statement to add a catalog. The following command creates a catalog named PERSNL on the \SYS1 system and $VOL1 volume:
>> CREATE CATALOG \SYS1.$VOL1.PERSNL;

The NonStop SQL/MP Reference Manual describes SQLCI and the syntax of SQL statement.
NonStop TM/MP Management Tools
NonStop TM/MP Management Tools

The NonStop TM/MP product protects databases in OLTP environments using its main functional component, the TMF subsystem. The TMF subsystem manages database transactions, keeps track of database activity through audit trails, and provides database recovery methods. The NonStop TM/MP product is one of the core services that make up the Tandem application environment.
TMF Subsystem Management Interfaces

The NonStop TM/MP product provides the following ways to make changes to the TMF subsystem:
Interactively using the TMFCOM command-line user interface Programmatically, by writing a management application program that uses the NonStop TM/MP programmatic interface, TMFSERVE
TMFCOM
TMFCOM allows commands to be entered and responses to be received through a terminal keyboard or monitor.
Management Application Programs

The TMFSERVE process provides programmatic access to SPI, making it possible to construct management application programs that monitor and control the NonStop TM/MP environment. TMFSERVE enables you to programmatically request the same operations available through TMFCOM. SPI is a token-oriented message interface that is part of the DSM product line.
How the TMF Subsystem Management Interfaces Work

TMFCOM and management application programs send commands and instructions to TMP, the TMF management process pair. TMP is in charge of operations that require a single point of control in a system, such as starting and stopping the TMF subsystem, initiating the recovery processes, and implementing configuration changes. Figure 7-4 shows how TMFCOM and a management application program communicate with TMP through TMFSERVE processes.
Considerations and Limitations of the TMF Management Interfaces
Figure 7-4. TMFCOM and Management Application Program Interfaces

TMFCOM Command terminal Management Application Process
TMFSERVE
TMFSERVE
TMP
Considerations and Limitations of the TMF Management Interfaces

Section 4, Making Application Subsystem Changes Online, describes the changes you can make to NonStop TM/MP online, including which types of changes can affect system and application availability.
TMFCOM Command Example

The following example shows how you would use TMFCOM to alter the configured attribute values of an audit trail. Use the TMFCOM ALTER command to alter audit-trail attributes. The following command adds an active audit volume and increases the number of files for the volume to 6 for the AUX02 audit trail:
~ALTER AUDITTRAIL AUX02, ADDACTIVEVOL $AUDIT2, & ~ FILESPERVOLUME 6

The NonStop TM/MP Reference Manual describes the syntax and semantics of all TMFCOM commands. Programmatic management of the TMF subsystem is described in the NonStop TM/MP Management Programming Manual.
Glossary
This glossary includes a selection of terms used in this manual. Definitions of application and communications subsystem terms are brief and not very detailed; they are intended only to make this manual more meaningful than it would otherwise be to readers unfamiliar with Tandems application and communications subsystems. active audit trail. The set of audit-trail files that reside on an active audit volume. active audit volume. The disk volume configured to contain audit-trail files. alternate key. See index. API. See application programming interface (API). application programming interface (API). The means by which a program within an application gains access to a set of services. For example, an API might consist of a set of procedure calls that provide a workstation application with a standard interface for communicating with a Tandem NonStop system. application subsystem. A Tandem product that provides users with application services. NonStop Transaction Services/MP (NonStop TS/MP), NonStop SQL/MP, and NonStop Transaction Manager/MP (NonStop TM/MP) are application subsystems. audit dump. A copy of an audit-trail file written to a tape or disk volume by an audit-dump process. audit record. A before-image, after-image, or TMF control record stored in an audit-trail file. audit trail. A series of audit-trail files containing audit records. audit-trail file. A disk file containing audit records. audited file. A database file flagged for auditing by the TMF subsystem. audited volume. A disk volume on which audited database files can reside. autoabort function. A NonStop Transaction Manager/MP operation that automatically aborts transactions if they run longer than the autoabort threshold. autoabort threshold. The time limit used by NonStop Transaction Manager/MP to identify long transactions. When a transaction runs longer than the threshold, the TMF subsystem aborts it. automatic recompilation. An SQL compilation that NonStop SQL/MP performs at run time when an SQL object program is flagged as invalid. Automatic recompilation occurs, for example, when an SQL statement refers to a table or includes a DEFINE that has changed since the last explicit compilation of the program.
Availability Guide for Change Management125506 Glossary -1
Glossary
auxiliary audit trail
auxiliary audit trail. An audit trail configured in addition to the master audit trail. availability. Tandem is using this term to describe end-user availability. End-user availability is the amount of time an application running on a Tandem system can be used effectively by the user of that application. catalog. A set of tables containing the descriptions of SQL objects such as tables, columns, indexes, views, files, and partitions. change control. The process for proposing, planning, implementing, and testing change. Change control is a key requirement for minimizing the duration of planned and unplanned outages. Change control ensures the successful migration of a system or application from one stable configuration another. Change control is also an important part of maintaining the security of your system and applications. change-control process. A process for implementing change control. Tandem recommends a four-phase change-control process. The four phases are as follows: definition and documentation, change planning, implementation, and verification. change management. 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. One of the operational disciplines in the operationsmanagement model. client/server computing environment. An environment in which 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. 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). column. A vertical component of a table; the relational representation of a field in a record. A column contains one data value for reach row of the table. command file. A file that contains a series of commands. When the file is executed, the commands within the file are automatically executed. Command files are supported by the Tandem Advanced Command Language (TACL) and many Tandem subsystems. communications controller. A hardware component that manages communications lines or devices. communications subsystem. A Tandem product that provides users with access to a set of communications services. Examples of communications subsystems include Expand and Tandem TCP/IP. configuration management. The process of configuring the production system hardware and software to adapt to changes. One of the operational disciplines in the operationsmanagement model.
Glossary
CONFTEXT file
CONFTEXT file. An EDIT file containing a series of statements that define the hardware and software components of your NonStop system. The CONFTEXT file is an input file to the SYSGEN program. CRU. See customer-replaceable unit (CRU). customer-replaceable unit (CRU). A term used to describe certain system components that can be installed and removed by Tandem customers while the NonStop system is operating. data definition language (DDL). The set of definition statements within the SQL language. Data definition statements are used to define, delete, or modify the catalog definition of a table, column, index, view, constraint, or partition or to change the authorization. data volume. A disk volume configured to contain audited database files, and thus to generate audit records to be placed in an audit trail. database. A collection of tables containing data, all objects that depend on the tables, and all catalogs in which the tables and objects are registered. DDL. See data definition language (DDL). design outage class. An outage class that includes bugs in design and design failures in hardware and software. For example, an application change that introduces unexpected problems could cause a design outage. distributed database. A database whose objects reside on more than one node in a network and whose objects can be accessed from any node in the network. Distributed Systems Management (DSM) products. A set of software tools that facilitate management of NonStop systems and networks. These tools include the Distributed Name Service (DNS), the Event Management Service (EMS), the Subsystem Control Facility (SCF) for communications subsystems, the Subsystem Programmatic Interface (SPI), and the ViewPoint console application. Distributed Systems Management/Software Configuration Manager (DSM/SCM). A product for installing and managing software configurations on distributed target systems. At the central site, DSM/SCM receives, archives, configures, and packages software for the target sites. On the target sites, DSM/SCM loads new software received from the central site. downtime. Time during which the NonStop system is not capable of doing useful work because of a planned or unplanned outage. From the end users perspective, downtime is any time the application is not available. The cost of downtime can be dramatic in lost revenue, lost consumer confidence, and lost productivity. DSM. See Distributed Systems Management (DSM). DSM/SCM. See Distributed Systems Management/Software Configuration Manager (DSM/SCM).
Glossary
entry-sequenced file
entry-sequenced file. A file in which each new record is stored at the end of the file in chronological sequence and whose primary key is a system-generated record address. environmental outage class. An outage class that includes failures in power, cooling, network connections, natural disasters (earthquake, flood), terrorism, and accidents. Expand. Tandems NonStop network that extends the concept of fault-tolerant operation to networks of geographically distributed NonStop systems. If the network is properly designed, communications paths are constantly available, even in the event of a single line or component failure. fault tolerance. The ability of a Tandem NonStop system to continue processing despite the failure of any single software or hardware component within the system. file. A logical construct subject to operations such as reading and writing. The term file is most commonly used to refer to data stored on a disk, but on the NonStop system, processes, devices, and various other entities are also defined as files. file system. A set of system procedures that run as part of a users process and send messages to other processes, such as input/output (I/O) processes. File Utility Program (FUP). A Tandem product that allows users to create, copy, purge, and otherwise manipulate disk files interactively. firmware. A type of microcode that resides on certain circuit boards and devices. The two principle types of microcode are firmware or bootstrap code, sometimes called boot PROM code, and operational microcode for downloadable controllers. Boot code for a device starts or boots the device and may also contain power-on diagnostics. During a system load or while a controller is being loaded, operational microcode is downloaded from storage into volatile memory. graphical user interface (GUI). A type of screen interface that typically includes pull-down menus, icons, dialog boxes, and online help. host language. Any programming language whose statements can be combined with SQL statements in the same source program. host program. A source program that contains both host language statements and embedded SQL statements. index. An alternate access path to a table that differs from the inherent access path (or primary key) defined for the table at creation time. An SQL index, stored in a file, includes columns for the primary key and the alternate key. input/output (I/O) process. A system process that manages communications with I/O devices (such as disks and printers) and communications lines. An I/O process pair logically owns one or more I/O devices or communications lines. I/O processes are the system processes that make up a communications subsystem.
Glossary
interim product modification (IPM)
interim product modification (IPM). An interim software release that may include one or more fixes to Tandem code or may contain code that adds function to a Tandem software product. You receive an IPM on a BACKUP tape that contains the updated program and documentation files in one or more distribution subvolumes (DSVs). invalid object. A table, view, or index that is unusable because its file label is not consistent with its catalog entries, or because it contains data that is inconsistent with a related object or that does not satisfy constraints on the object. invalid program. A program that requires recompilation before it can be run due to a change made to the program or to the database. IPM. See interim product modification (IPM). key-sequenced file. A file in which each new record is stored in sequence by primary-key value and whose primary key is defined by the user, by the system, or by the user and the system together. LAN. See local area network (LAN). LINKMON process. An operating system process that supports access to transactionprocessing server classes from requester programs written in C, COBOL85, PASCAL, pTAL, or TAL. LINKMON processes, which act as link managers, are used by the Pathsend procedures. local area network (LAN). A set of computers, word processors, and other electronic devices linked to create an interoffice or inter-site network. management applications. User-written applications that automate configuration and control tasks. For example, a management application can request from the NonStop TS/MP PATHMON process the same kinds of services that system managers can request interactively using the NonStop TS/MP PATHCOM interface. master audit trail (MAT). The audit trail that contains TMF control information and information describing the logical ordering of audit information in all audit trails in the system. The MAT can also store audit information generated by a set of data volumes. MAT. See master audit trail (MAT). node. A system or device that follows the protocols of a specific network and that other systems or devices in that network can address. Nomadic Disk Subsystem. A set of products that enables remote mirroring of NonStop Kernel databases and the physical and logical switching of the databases between Tandem systems. Nomadic Disk technology reduces downtime during planned system outages and provides fast recovery from unplanned system outages. NonStop ODBC Server. See NonStop Open Database Connectivity (ODBC) Server.
Glossary
NonStop Open Database Connectivity (ODBC) Server
NonStop Open Database Connectivity (ODBC) Server. A client/server product that 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. NonStop SQL/MP. The Tandem relational-database-management system that promotes efficient online access to large distributed databases. NonStop SQL/MP is the Tandem implementation of the Structured Query Language (SQL). NonStop TM/MP. See NonStop Transaction Manager/MP (NonStop TM/MP). NonStop Transaction Manager/MP (NonStop TM/MP). A data-management product that maintains the consistency of a database and provides the tools for database recovery. NonStop Transaction Services/MP (NonStop TS/MP). A Tandem product that provides process-management and link-management functions for OLTP applications. NonStop TS/MP. See NonStop Transaction Services/MP (NonStop TS/MP). NonStop TS/MP and Pathway/TS management programming interface. A set of programmatic commands that allow you to write management application programs that communicate directly with the NonStop TS/MP central control process (PATHMON) for configuration and control operations. This interface is based on the Subsystem Programmatic Interface (SPI) portion of Distributed Systems Management (DSM). object. Any entity subject to independent reference or control by one or more subsystems. Examples of objects are devices, communications lines, processes, and files. In Distributed Systems Management (DSM), every object has a name and type. offline. Used to describe tasks that require the NonStop system to be shut down. offline change. Any change that requires your NonStop system to be shut down. Offline changes are usually performed during a planned outage. OM model. See operations-management (OM) model. online. Used to describe tasks that can be performed while the NonStop system is operational. online change. Any change that can be performed while your NonStop system is still operational. 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. online dump. A copy of an audited database file written to tape or disk. The TMF subsystem can restore the online-dump files to disk and apply the audit-trail images to reconstruct the files on the volume.
Glossary
online transaction processing (OLTP)
online transaction processing (OLTP). A method of processing transactions in which entered transactions are immediately applied to the database. The information within the database is readily available to all users through online screens and printed reports. online transaction-processing application. A set of programs that perform online transaction-processing (OLTP) tasks on behalf of the user. With an OLTP application, many terminal users can update data simultaneously, recording the changes in the database as they are entered. OLTP applications generally display, check, and accept input data, manipulate the input data, and perform some type of data output activity. Open System Services (OSS). An open system environment available for interactive or programmatic use with the Tandem NonStop Kernel. Processes that run in the OSS environment use the OSS application program interface; interactive users of the OSS environment use the OSS shell for their command interpreter. operations management (OM). The operation and management of systems and networks in support of your business. Planning for operations management includes establishing and fulfilling service-level agreements, defining and understanding the OM model, and optimizing the features of Tandem systems and software. operations-management (OM) model. A model for managing NonStop systems that categorizes operations-management functions into the following disciplines: production management, problem management, change management, configuration management, security management, and performance management. operations outage class. An outage class that includes errors caused by operations personnel due to accidents, inexperience, or malice. OSCONFIG file. A file that contains Software Problem Isolation and Fix Facility (SPIFF) and Software ID (SWID) records. OSIMAGE file. A file that contains a complete image of the operating system. The OSIMAGE file is created by SYSGEN. OSS. See Open System Services (OSS). outage. Time during which the NonStop system is not capable of doing useful work because of a planned or unplanned outage. From the end users perspective, an outage is any time the application is not available. outage class. A concept developed by Tandem to categorize the causes of outages. There are five outage classes: physical, design, operations, environmental, and reconfiguration. The first four categories describe unplanned outages. The reconfiguration outage class includes all planned outages. outage minutes. A metric recommended by Tandem for measuring outages that translates percentages into minutes of downtime per year. overflow audit volume. A disk volume on the local system used to store audit-trail files when the active audit trail becomes too full.
Glossary
partial SYSGEN phase
partial SYSGEN phase. A procedure that may be able to help you to reduce the impact of interim product modification (IPM) installation on system and application availability. The partial SYSGEN phase does not require a system load and may also eliminate the need to stop your applications. partition. The portion of a table or index that resides on a particular disk volume. PATHCOM. The interactive administrative interface to the NonStop Transaction Services/MP core service and the optional Pathway/TS software. See also NonStop Transaction Services/MP. PATHCTL file. The PATHMON configuration file. The NonStop TS/MP central control process (PATHMON) stores the definitions and status information for each object controlled by PATHMON in the PATHCTL file. PATHMON process. The central control process for the NonStop TS/MP transactionprocessing core service and the optional Pathway/TS software, which together form the Pathway environment. The PATHMON process controls all processes and devices in the Pathway environment and provides the means to configure, manage, monitor, and change the configuration of the Pathway environment. PATHMON-controlled objects. Entities that are subject to independent reference or control by the PATHMON process. The objects controlled by PATHMON are PATHMON, PATHWAY, TCP, SERVER, PROGRAM, and TERM. Pathsend procedures. A set of operating system procedure calls that provide general access to Pathway server classes from any process on a NonStop system. Pathway environment. The programs and operating environment required for developing and running online transaction-processing (OLTP) applications. This group of tools is packaged as two separate products: NonStop TS/MP and the optional Pathway/TS software. See also NonStop Transaction Services/MP (NonStop TS/MP) and Pathway/TS. Pathway/TS. A Tandem product that provides tools for developing and interpreting screen programs to support OLTP applications in the Guardian operating environment. See also NonStop Transaction Services/MP (NonStop TS/MP) and Pathway environment. Pathway Open Environment Toolkit (POET). A client/server product that works with the Remote Sever Call (RSC) product to enable you to create and run client/server applications where the client is a Microsoft Windows program. POET streamlines the development of Microsoft Windows clients for use with Pathway servers by providing a higher-level interface to RSC. performance management. Activities that manage the performance of the production system and network environment to ensure that the systems meet the business needs defined by operations service-level agreements. One of the operations disciplines in the operationsmanagement model.
Glossary
phantom device
phantom device. A device that is configured but that is not physically present. You can make a phantom device operational without having to bring your NonStop system down. Configuring phantom devices is one way you can plan for future growth. physical outage class. An outage class that includes physical faults or failure in the hardware. Any type of hardware component failure belongs in this category. planned outage. Time during which the system is not capable of doing useful work because of a planned interruption. A planned outage can be time when the system is brought down to allow for servicing, upgrades, backup, or general maintenance. planned outage request form. A form that is used to gather information about 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. POET. See Pathway Open Environment Toolkit (POET). problem management. Activities that provide support for resolving problems in a production environment. One of the operations disciplines in the operationsmanagement model. process. A unique execution of a program. production management. The set of regularly scheduled activities that keeps the applications on a system or network of systems running smoothly. These activities include administering storage media such as disks and tapes, managing space in processors and disks, and starting or stopping system components. One of the operations disciplines in the operations-management model. programmatic SQL. The set of SQL statements that can be embedded in a host language program; the application programming interface for NonStop SQL/MP. reconfiguration outage class. An outage class that includes all planned outages. Examples include downtime required for planned maintenance (such as software upgrades) and configuration changes (such as adding a new disk or restructuring a database). relational database. A database in which data is represented as relational tables. release. The means by which Tandem provides new versions of software products. Refers to a set of software containing one version of each software product. A software release is distributed on a site update tape (SUT) and is identified by a release ID; for example, D30.02. The release ID is often different from the base versions of the specific products issued under that release. Remote Server Call (RSC). A Tandem product that facilitates client/server computing, allowing personal computer (PC), Macintosh, or workstation applications to access Pathway servers. Transactions are transmitted from the PC, Macintosh, or workstation
Glossary
report writer
(the client) to a Pathway application running on a NonStop system (the server) using a supported communications protocol. report writer. The SQLCI component used to produce specially formatted reports from queries. requester server approach. An approach to application design that divides the tasks of data input, data manipulation, and data output between two basic processes, requesters and servers. requesters. The programs that coordinate the data input function for an online transactionprocessing application (by displaying, checking, and accepting data), send input to server programs, and process reply messages from servers. SCREEN COBOL. A procedural language developed by Tandem and based on COBOL that is used to define and control terminal displays. SCREEN COBOL compiler. A SCREEN COBOL language compiler provided with Pathway/TS. You use the compiler to read a user-written SCREEN COBOL source file and create a SCREEN COBOL library directory and a SCREEN COBOL library code file. SCREEN COBOL Utility Program (SCUP). A utility, provided with Pathway/TS, that allows control and manipulation of SCREEN COBOL object files. SCUP. See SCREEN COBOL Utility Program (SCUP). security management. Activities that provide support for establishing and maintaining system security. One of the operations disciplines in the operations-management model. server class. A grouping of duplicate copies of a single server program, all of which execute the same object program. servers. The programs that receive messages from requesters, perform specified operations (for example, database inquiries, database updates, or numerical calculations), and return reply messages to requesters. site update tape (SUT). One or more tapes that contain each target systems site-specific subvolume and various products. Each product contains a softdoc and a complete set of files. A full SUT contains the current release of the operating system and all product software that has been ordered with it, including release documentation. A partial SUT contains a subset of products for the current release of the operating system. SNA. See Systems Network Architecture (SNA); IBMs networking architecture. SNAX product family. The product family that consists of those Tandem software products that provide access to IBM Systems Network Architecture (SNA) networks. SQL. See Structured Query Language (SQL).
Glossary
SQL object
SQL object. A NonStop SQL/MP database entity that is created, manipulated, or dropped by SQL statements and that is described in an SQL catalog. Tables, views, indexes, collations, and constraints are SQL objects. SQLCI (NonStop SQL/MP conversational interface. A line-oriented terminal interface that provides interactive SQL statements, SQLCI commands, a report-writing facility, and a full set of utilities that provide quick access to information about the database, the data dictionary, and the application programs. Structured Query Language (SQL). A relational database language used to define, manipulate, and control databases. subdevice. A recipient of requests within a subsystem. A subdevice often corresponds to a real external entity. Subsystem Control Facility (SCF). A management application within the Distributed Systems Management (DSM) architecture. SCF can be used to change the characteristics of communications lines, devices, and subdevices for most communications products without having to take your NonStop system down. Subsystem Control Point (SCP). The management process for certain communications subsystems. Subsystem Programmatic Interface (SPI). A set of procedures for building and decoding commands, responses, and event messages. SYSGENR. A utility program used by DSM/SCM to generate a Tandem NonStop Series/RISC (TNS/R) operating-system image for a given hardware and software configuration on Tandem RISC systems. Systems Network Architecture (SNA). The prevalent IBM communications model. table. A logical representation of data in a database in which a set of records is represented as a sequence of rows, and the set of fields common to all the records is represented as a series of columns. As a NonStop SQL/MP object, a table represents data in columns and specifies the physical characteristics of the table for the file system. TACL. See Tandem Advanced Command Language (TACL). TACL macro. A sequence of Tandem Advanced Command Language (TACL) commands and built-in functions that can contain dummy arguments, thus providing a means for simple argument substitution. When the macro name is given to TACL, TACL substitutes the command sequences for the macro name and replaces any dummy arguments with parameter values supplied to TACL. Macros are used to automate operations tasks. Tandem Advanced Command Language (TACL). A powerful, extended command interpreter for the Tandem NonStop Kernel operating system that enables you to perform work on NonStop systems.
Glossary
Tandem application environment
Tandem application environment. An environment that enables you to develop and run high-performance, high-volume, online transaction-processing (OLTP) applications on NonStop systems. NonStop Transaction Services/MP (NonStop TS/MP), NonStop SQL/MP, and NonStop Transaction Manager/MP (NonStop TM/MP) are the three key products that make up the Tandem application environment. Tandem DAL Server. See Tandem Data Access Language (DAL) Server. Tandem Data Access Language (DAL) Server. A client/server product that provides NonStop SQL/MP database access for client applications compatible with DAL. DAL is a connectivity language and a standard for database access. Tandem Service Management (TSM). A client/server application that provides troubleshooting, maintenance, and service tools for your Himalaya S-series server. TSM combines many of the system maintenance functions previously provided by the Syshealth toolkit, the Tandem Maintenance and Diagnostic Subsystem (TMDS), and the Remote Maintenance Interface (RMI) product. TCP. See Terminal control process (TCP). Terminal control process (TCP). A multithreaded process supplied with Pathway/TS that interprets and executes screen program instructions for each input/output (I/O) device or process the TCP is configured to handle. The TCP coordinates communication between screen programs and their I/O devices or processes and, with the help of the PATHMON process, establishes links between screen programs and Pathway server processes. TMF catalog. The database that specifies where all dumped files reside and which dump media are available for reuse. TMF subsystem. The Transaction Management Facility, which is the major component of the NonStop Transaction Manager/MP product. The TMF subsystem manages database transactions, keeps track of database activity through audit trails, and provides database recovery methods. TMFCOM. The NonStop Transaction Manager/MP interactive interface. TMFCOM allows operators to enter commands and receive responses through a terminal keyboard and monitor. TMFSERVE process. The process that provides access to the TMF subsystem through the Subsystem Programmatic Interface (SPI), making it possible to construct management applications that monitor and control the TMF environment. TMFSERVE also receives and acts upon commands entered through TMFCOM. transaction. An explicitly delimited operation or set of related operations that alters the content of a database. TSM. See Tandem Service Management (TSM).
Glossary
unplanned outage
unplanned outage. Time during which the system is not capable of doing useful work because of an unplanned interruption. Unplanned interruptions can include failures caused by faulty hardware, operator error, or disaster. view. A table derived by projecting a subset of the columns, restricting a subset of the rows, or both, from one or more other tables and views. A view has a logical definition and a file label but contains no actual data separate from the data in the table or tables it is derived from. wild-card character. A character, usually an asterisk (*) or a question mark (?), that is used to match any character or a series of characters.
Glossary
wild-card character
Index
A
Active audit trail 4-16 Active audit volumes 4-16 Adding communications lines and devices 5-5 disk controllers 3-5 disk drives 3-5 hardware 1-4, 4-6 memory 3-4 PATHMON-controlled objects 4-6 processors 3-3 Air conditioning capacity 6-3 Altering input/output processes 5-5 PATHMON environment owner and security attributes 4-7 PATHMON owner attribute 4-7 PATHMON-controlled objects 4-6 Anchor partition 4-14 Application subsystems, reconfiguring See NonStop SQL/MP, NonStop Transaction Manager/MP, NonStop Transaction Services/MP Applications automating startup and shutdown of 6-6 installing 1-5 reconfiguring 1-5 Attachments 7-9 Audit dumps 4-16 Audit trails, TMF 4-16 Audit volumes 4-16 Audit-dump configuration 4-19 Audit-trail configuration 4-18 Autoabort 4-19 Automating startup and shutdown 6-6 Auxiliary audit trail 4-16 Availability 1-6
C
Change See Adding, Altering, Deleting, Moving, Reconfiguring Change control continual process improvement as part of 2-2 definition of 1-3, 2-1 importance of 1-3, 2-1 prerequisites of 2-2 system security as part of 2-1 tools for 2-3 Change management 1-8 definition of 1-2 goals of 1-5 tasks of 1-2 Change plan 2-8 Change-control process change-planning phase of 2-6/2-9 definition and documentation phase of 2-3/2-4 implementation phase of 2-9 verification phase of 2-9 Change-control tools 2-3 Change-request form 2-3 Changing hardware disk drives 3-5 memory 3-4 processors 3-3 CHECK option 4-13 Client programs 4-4 Client software, TSM 7-7/7-9 Client/server computing definition of 4-3 NonStop Open Database Connectivity Server 4-11 NonStop SQL/MP 4-11
Availability Guide for Change Management125506 Index- 1
Index
Remote Server Call 4-27 Tandem Data Access Language Server 4-11 Command files 6-4/6-6 Communications lines, starting 6-6 Communications Management Interface communications products supported by 5-5 definition 3-1 Communications products 5-3/5-4 Communications subsystems changes you can make online to 5-4/5-5 definition of 5-1 device-specific connections 5-3 Expand 5-3 functions of 5-1 Local area networks 5-4 manuals for 5-7 Open Systems Interconnections (OSI) network 5-3 products 5-3 reconfiguring 1-5 SNA network connections 5-3 supported by CMI 5-5 supported by SCF 7-3 TCP/IP 5-4 using SCF to make online changes to 54 using the Subsystem Control Facility to make changes to 5-4, 7-1 COMPILE option 4-13 COMPILE options, NonStop SQL/MP CHECK INOPERABLE PLANS 4-13 COMPILE INOPERABLE PLANS 413 Computer room resources 6-3 Configuration management 1-8 Configuring phantom processors 3-3, 6-3 CONFTEXT configuration file
phantom processors in 6-3 Contingency plans 2-8 Continual process improvement 2-2 Controllers installing 3-5 Cool start option, NonStop TS/MP 6-7 Cost of downtime 1-2 CRUs See customer-replaceable units Customer-replaceable units 3-3
D
DAL server See Tandem Data Access Language Server Data definition language operations 4-13, 712 Data manipulation language statements 712 Data volume configuration 4-19 Data volumes 4-17 Database protection 4-16 See also NonStop SQL/MP Database reorganization 4-12 See also NonStop SQL/MP DDL operations See Data definition language operations Deleting communications lines and devices 5-5 PATHMON-controlled objects 4-6 Design outage class 1-6 Device and transaction control 4-1 Device-specific connections 5-3 Disk controllers, adding with DSC 3-5 Disk drives adding 3-5 installing 3-5 moving 3-5 preparing 3-6
Index
upgrading 3-5 Disk utilization 6-1 Distributed Systems Management 5-4, 7-10, 7-14 Distributed Systems Management/Software Configuration Manager 1-4, 3-2, 6-9 DML statements See Data manipulation language statements Downtime, cost of 1-2 DSM/SCM See Distributed Systems Management/Software Configuration Manager Dynamic System Configuration adding controllers with 3-5 communications subsystems supported by 5-5 definition 3-1
Graphical user interfaces 4-3 Growth forecasts 6-1 Guardian Performance Analyzer 6-2 Guardian programs 4-4 GUIs See Graphical user interfaces
H
Hardware changes See Changing hardware
I
IDS See Intelligent Device Support (IDS) Facility Incident reports 7-8 Input/output processes 5-1/5-2, 7-2 Installing applications 1-5 controllers 3-5 disk drives 3-5 Interim Product Modifications 1-4 new operating system 1-4, 6-8 processors 3-3 Intelligent Device Support (IDS) Facility 428 Interim product modifications, installing 14 Invalid programs 4-13 IPMs See Interim product modifications I/O processes See input/output processes
E
End-user availability 1-6 Environmental outage class 1-6 Event Viewer Server Manager 7-7 Expand subsystem 5-3 Extended General Device Support (GDSX) 4-27, 4-29
F
File Utility Program RELOAD command 4-13 Firmware updating online with TMDS 3-6/3-7 when to update 3-6
G
GDSX See Extended General Device Support GPA See Guardian Performance Analyzer
L
LAN connections See Local area networks LINKMON process 4-5, 4-27 Local area networks 4-3, 5-4
Index
M
Master audit trail, TMF 4-16 Master service processors (MSPs) definition of 7-6 MAT See Master audit trail Measure 6-2 Measuring outages 1-6, 1-7 Memory, adding 3-4 MODIFY DICTIONARY (NonStop SQL/MP) 4-14 Moving disk drives 3-5 MSPs See Master service processors (MSPs)
N
Networking See Communications subsystems, products NonStop NET/MASTER Management Services 5-3 NonStop ODBC See NonStop Open Database Connectivity Server NonStop Open Database Connectivity (ODBC) server 4-11 NonStop SQL/MP changes you can make online to 4-12/415 CHECK option 4-13 client/server computing 4-11 COMPILE option 4-13 components of 4-9 Data Definition Language operations 413 database reorganization 4-12 definition 4-2 features of 4-9 invalid programs 4-13
management interfaces to 4-9 manuals for 7-13 MODIFY DICTIONARY 4-14 node name/number changes 4-14 NOREGISTER option 4-14 objects 7-12 programmatic interface to 7-12 recompiling SQL statements 4-13 REGISTERONLY option 4-14 reorganizing a database 4-12 SQLCI interface 7-12 WITH SHARED ACCESS option 4-12 NonStop SQL/MP conversational interface See SQLCI NonStop TM/MP See NonStop Transaction Manager/MP NonStop Transaction Manager/MP 4-16 audit information 4-16 audit trails 4-16 Audit-dump configuration 4-19 audit-trail configuration 4-18 autoabort function 4-19 changes you can make online to 4-18/420 components of 4-16 data-volume configuration 4-19 definition 4-2 features of 4-16 management tools 7-14/7-15 manuals for 7-15 overview 4-16 reconfiguring 4-18/4-20 TMF catalog 4-20 TMFCOM 4-17 TMFSERVE 4-17 transactions 4-16 NonStop Transaction Services/MP changes you can make online to 4-5/4-8 components of 4-5
Index
definition 4-2 management tools 7-9/7-12 manuals for 7-12 PATHCOM interface to 7-10 SPI interface to 7-10 NonStop TS/MP See NonStop Transaction Services/MP NonStop TUXEDO environment changes you can make online to 4-23 definition 4-2 dynamic reconfiguration 4-24 overview 4-22 tmadmin 4-24 tmconfig 4-24 NOREGISTER option 4-14 Notifications 7-8 NSX See Tandem Network Statistics Extended
Operating system, installing 1-4, 3-2, 6-8 Operations outage class 1-6 Operations-management model 1-8 OSI See Open Systems Interconnections OSIMAGE 3-3 Outage classes 1-6 Outage minutes 1-7 Outages, measuring 1-7 Overflow audit volumes 4-16
P
Packet-switching networks 5-3 Parallel processing 6-6 Partition, anchor 4-14 PATHCOM 7-10 part of NonStop TS/MP product 4-5, 710 Pathway environment 4-28 PATHMON changing owner and security attributes 4-7 definition 4-5 interaction with NonStop TS/MP management interfaces 7-10 objects 4-6 PATHMON environment 6-7 PathSend API 4-27 Pathway environment changes you can make online to 4-28 components of 4-25 definition 4-2 GDSX 4-27 objects controlled by PATHMON 4-6, 7-10 PATHCOM interface 4-28 PathSend API 4-27 Pathway/TS 4-27 reconfiguring 4-6/4-8 Remote Server Call 4-27
O
Objects NonStop SQL/MP 7-12 PATHMON-controlled 4-6, 7-10 Subsystem Control Facility 7-1 ODBC See NonStop Open Database Connectivity (ODBC) server Offline change, definition of 1-6 OLTP See Online transaction processing OM model See Operations-management model Online change 1-5, 3-1 Online dumps 4-17 Online reconfiguration See Reconfiguring 3-1 Online transaction processing 4-1 Open Systems Interconnections (OSI) 5-3
Index
Pathway/TS 4-27 Performance management 6-1 Performance measurement 6-2 Periodic incident reports definition of 7-9 Phantom devices 6-3 Phantom disk drives 3-5 Phantom processors 3-3 Physical outage class 1-6 Planned outage request form 2-3 Planned outages anticipating and planning for 6-1 definition of 1-6, 6-1 minimizing the frequency of 6-1 request form for 2-3 Power capacity 6-3 Problem incident reports 7-8 Problem management 1-8 Processors adding 3-3 configuring phantom 3-3 installing 3-3 upgrading 3-4 utilization of 6-1 Production management 1-8 Programmatic interfaces NonStop SQL/MP 7-12 NonStop Transaction Manager/MP 417, 7-14 NonStop Transaction Services/MP 7-10 Programmatic SQL 4-9 Programming languages See individual programming languages
Reconfiguration, online 3-1 Reconfiguring applications 1-5 communications lines and devices 5-5 communications subsystems 1-5 hardware 1-4 See also Changing hardware NonStop SQL/MP 1-4 NonStop Transaction Manager/MP 1-4, 4-18/4-20 NonStop Transaction Services/MP 1-4, 4-6/4-8 software 3-1 Recovery plans 2-8 Reducing system and application startup and shutdown time 6-4/6-7 REGISTERONLY option 4-14 Relational database management See NonStop SQL/MP RELOAD command (FUP) 4-13 Remote Duplicate Database Facility (RDF) 4-16 Remote Server Call (RSC) changes you can perform online to 4-29 description 4-27 Reorganizing a database See NonStop SQL/MP Requester programs 4-4 RSC See Remote Server Call
S
SCF See Subsystem Control Facility SCP See Subsystem Control Point SCREEN COBOL compiler 4-27 SCREEN COBOL programs 4-4 SCREEN COBOL Utility Program (SCUP) 4-27
R
RDF See Remote Duplicate Database Facility Recompiling SQL statements 4-13 Reconfiguration outage class 1-6
Index
SCUP See SCREEN COBOL Utility Program Security management 1-8, 2-1 Server class 4-4 Server programs 4-4 Server software, TSM 7-6 Service processors (SPs) 7-7 Shutdown processes, distributing 6-6 SHUTDOWN2 command 6-7 Shutdown, system 6-6 SNA network connections 5-3 SNAX product family 5-3 Software and Services Directory 2-3, 7-1 Software components, TSM ??/7-9 SP event messages 7-8 SPI See Subsystem Programmatic Interface SQL statements 4-9, 4-10 SQLCI features of 4-9, 7-12 limitations of 7-13 Starting communications lines 6-6 Starting transaction-processing applications 6-7 Startup processes, distributing 6-6 Startup, system 6-6 Stopping input/output processes 5-5 Stopping objects controlled by PATHMON 4-6 Structured Query Language See SQL statements Subsystem Control Facility 5-4 altering input/output processes with 5-5, 7-2 commands 7-1 communications subsystems supported by 5-5, 7-3 features of 7-1 limitations of 7-4 manuals for 7-5
objects 7-1 preserving changes made with 7-4 reconfiguring communications lines and devices with 5-5, 7-1 Subsystem Control Point 7-2 Subsystem Programmatic Interface and TMFSERVE 7-14 to PATHMON 4-28 to Subsystem Control Point 7-2 SYSGENR program 3-2 and $SYSTEM disk 3-6 definition 3-1, 3-2 System down message description of 7-8 System performance, evaluating 6-1/6-3 System security 2-1 System startup and shutdown, automating 6-6
T
Tandem Alliance Program 2-3 Tandem Capacity Model 6-2 Tandem DAL Server See Tandem Data Access Language Server Tandem Data Access Language Server 4-11 Tandem Maintenance and Diagnostic System 3-5 Tandem Network Statistics Extended 6-2 TCM See Tandem Capacity Model TCP See Terminal Control Process TCP/IP See Transmission Control Protocol/Internet Protocol TDP See Transaction Delivery Process Terminal Control Process (TCP) 4-27 Test and verification plans 2-8, 6-8
Index
Third-party tools 2-3 tmadmin, NonStop TUXEDO environment 4-24 tmconfig, NonStop TUXEDO environment 4-24 TMF catalog 4-20 TMF subsystem 4-16, 7-14 See also NonStop Transaction Manager/MP TMFCOM 4-17, 7-14 TMFSERVE 4-17, 7-14 TMP 7-14 Tools Communications Management Interface 3-1 Dynamic System Configuration 3-1 Guardian Performance Analyzer 6-2 Measure 6-2 NonStop SQL/MP management 4-9, 712 NonStop Transaction Manager/MP management 7-14 NonStop Transaction Services/MP management 4-5 performance measurement 6-2 Subsystem Control Facility 3-1, 7-1 Tandem Capacity Model 6-2 Tandem Maintenance and Diagnostic System 3-5 Tandem Network Statistics Extended 62 third-party 2-3 TP monitor See Transaction-processing monitor Transaction Delivery Process 4-27 Transaction Delivery Process (TDP) 4-27 Transaction monitoring 4-1 Transaction processing core services 4-1 used by NonStop TUXEDO environment 4-24
used by Pathway environment 4-25 environment, features of 4-3 NonStop TUXEDO environment 4-22 Pathway environment 4-25 Transactions, TMF 4-16 Transaction-processing monitor description 4-22 See also NonStop TUXEDO environment, PTP for the CICS API environment, Pathway environment Transmission Control Protocol/Internet Protocol 5-4 TSM application 7-7 TSM application notifications 7-8 TSM client software components of 7-7/7-9 TSM EMS Event Viewer features of 7-9 TSM Notification Director features of 7-7 TSM server software 7-6
U
UDP See User Datagram Protocol UNIX systems 5-4 Unplanned outages 1-6 Updating firmware 3-6, 3-7 Upgrading hardware 3-4/3-6 User Datagram Protocol 5-4
W
Wild-card characters, in command files 6-5
X
X.25 5-3
Special Character
Index
Special Character
$SYSTEM disk, and SYSGENR 3-6
Index
Special Character
Availability Guide for Change Management125506 Index -10

Availability Guide For CHG MGMT - 125506

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Availability Guide For CHG MGMT - 125506

Uploaded by

Copyright:

Available Formats

Availability Guide for Change Management

U.S. Government Customers

New and Changed Information

Availability Guide for Change Management125506 iii

New and Changed Information

Sections Affected Sections 1, 3, and 6

Availability Guide for Change Management125506 iv

1. Introduction to Change Management

3. Making System Software and Hardware Changes Online

Availability Guide for Change Management125506 v

4. Making Application Subsystem Changes Online

4. Making Application Subsystem Changes Online

5. Making Communications Subsystem Changes Online

6. Reducing the Time Required for Planned Outages

6. Reducing the Time Required for Planned Outages

7. Tools for Online Change

Glossary Index Figures

Availability Guide for Change Management125506 ix

Availability Guide for Change Management125506 x

About This Manual

Who Should Read This Manual?

Availability Guide for Change Management125506 xi

About This Manual

Whats in This Manual?

Whats in This Manual?

Availability Guide for Change Management125506 xii

About This Manual

Where to Find More Information

Where to Find More Information

Availability Guide for Change Management125506 xiii

About This Manual

Your Comments Invited

Your Comments Invited

Availability Guide for Change Management125506 xiv

Availability Guide for Change Management125506 xv

Availability Guide for Change Management125506 xvi

Introduction to Change Management

What Causes Change?

Change and the Cost of Downtime

Availability Guide for Change Management125506 1 -1

Introduction to Change Management

Increasing Availability by Effectively Managing Change

Increasing Availability by Effectively Managing Change

What Is Change Management?

Anticipating and Planning for Change

Availability Guide for Change Management125506 1 -2

Introduction to Change Management

Controlling the Introduction of Change

Evaluating System Performance and Growth

Providing Adequate Computer Room Resources

Configuring Your System With Change in Mind

Controlling the Introduction of Change

Installing and Implementing Changes

Availability Guide for Change Management125506 1 -3

Introduction to Change Management

Installing and Implementing Changes

Installing a New Operating System Release

Adding, Removing, and Reconfiguring Hardware

Installing and Reconfiguring Application Subsystems

Introduction to Change Management

Meeting the Goals of Change Management

Installing and Reconfiguring Communications Subsystems