DSM/SCM User's Guide - h20628. · DSM/SCM User’s Guide. Abstract. This guide describes the...

DSM/SCM User’s Guide

Abstract

This guide describes the Distributed Systems Management/Software Configuration Manager (DSM/SCM) and explains how to configure DSM/SCM and use it to manage and configure the software on your system.

Product VersionDSM/SCM G02DSM/SCM H02

Supported Release Version Updates (RVUs)

This guide supports J06.03 and all subsequent J-series RVUs, H06.03 and all subsequent H-series RVUs, and G06 and all subsequent G-series RVUs, until otherwise indicated by its replacement publications.

Part Number Published

529846-014 June 2014

Document History Part Number Product Version Published

529846-008 DSM/SCM G02 (ABU)/H02 February 2007

529846-009 DSM/SCM G02 and H02 May 2008

529846-010 DSM/SCM G02 and H02 August 2009

529846-011 DSM/SCM G02 and H02 February 2011

529846-012 DSM/SCM G02 and H02 September 2011


529846-014 DSM/SCM G02 and H02 June 2014

Legal Notices Copyright 2007, 2014 Hewlett-Packard Development Company L.P.

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

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

Microsoft, Windows, Windows NT, Windows 95, Windows Version 3.11, Windows XP, Windows Vista, and Windows - 7 (32 Bit) are U.S. registered trademarks of Microsoft Corporation.

Intel, Itanium, Pentium, and Celeron are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Motif, OSF/1, UNIX, X/Open, and the "X" device are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the U.S. and other countries.

Open Software Foundation, OSF, the OSF logo, OSF/1, OSF/Motif, and Motif are trademarks of the Open Software Foundation, Inc.

OSF MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THE OSF MATERIAL PROVIDED HEREIN, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

OSF shall not be liable for errors contained herein or for incidental consequential damages in connection with the furnishing, performance, or use of this material.

© 1990, 1991, 1992, 1993 Open Software Foundation, Inc. This documentation and the software to which it relates are derived in part from materials supplied by the following:

© 1987, 1988, 1989 Carnegie-Mellon University. © 1989, 1990, 1991 Digital Equipment Corporation. © 1985, 1988, 1989, 1990 Encore Computer Corporation. © 1988 Free Software Foundation, Inc. © 1987, 1988, 1989, 1990, 1991 Hewlett-Packard Company. © 1985, 1987, 1988, 1989, 1990, 1991, 1992 International Business Machines Corporation. © 1988, 1989 Massachusetts Institute of Technology. © 1988, 1989, 1990 Mentat Inc. © 1988 Microsoft Corporation. © 1987, 1988, 1989, 1990, 1991, 1992 SecureWare, Inc. © 1990, 1991 Siemens Nixdorf Informationssysteme AG. © 1986, 1989, 1996, 1997 Sun Microsystems, Inc. © 1989, 1990, 1991 Transarc Corporation.

This software and documentation are based in part on the Fourth Berkeley Software Distribution under license from The Regents of the University of California. OSF acknowledges the following individuals and institutions for their role in its development: Kenneth C.R.C. Arnold, Gregory S. Couch, Conrad C. Huang, Ed James, Symmetric Computer Systems, Robert Elz. © 1980, 1981, 1982, 1983, 1985, 1986, 1987, 1988, 1989 Regents of the University of California.

Java is a registered trademark of Oracle and/or its affiliates.

Printed in the U.S.

Hewlett-Packard Company — 529846-014i

DSM/SCM User’s Guide

Glossary Index Examples Figures Tables

Legal Notices

What’s New in This Manual xv

Manual Information xv

New and Changed Information xv

About This Guide xix

DSM/SCM xix

Who Should Use This Guide xix

What’s in This Guide xx

Notation Conventions xxiv

Part I. DSM/SCM Overview

1. Introduction to DSM/SCMMajor DSM/SCM Features 1-2

Configuring DSM/SCM 1-3

DSM/SCM Environment 1-3

DSM/SCM Archive 1-5

Host and Target Databases 1-5

DSM/SCM Security 1-6

Installing and Configuring Software 1-7

Managing the SYSnn Subvolumes 1-9

File Types Supported 1-9

Guardian File Types Supported 1-9

OSS File Types Supported 1-9

Comparing DSM/SCM to COPYOSS/PINSTALL/PCleanup 1-10

2. DSM/SCM Interfaces and ToolsStarting and Stopping DSM/SCM 2-2

Starting DSM/SCM 2-2

Stopping DSM/SCM 2-3

Stopping All Applications 2-3

mmad

Sticky Note

Rejected set by mmad

Contents 3. Hardware and Software Requirements

Using the DSM/SCM Interfaces 2-4

Planner Interface 2-4

Maintenance Interfaces 2-6

Target Interface 2-11

Using Tools for DSM/SCM Procedures 2-15

ZPHIRNM Tool 2-15

INITENV Tool 2-15

CLEANOSS Tool 2-17

SPRCHECK Tool 2-17

CLONE Utility 2-17

Using Online Help 2-18

Help for the Graphical User Interfaces 2-18

3. Hardware and Software RequirementsRequired Hardware 3-2

Required Software 3-2

DSM/SCM 3-2

Expand 3-2

SQL/MP 3-3

TMF 3-3

Pathway 3-3

Software Identification (SWID) 3-3

TCP/IP 3-4

DSM/SCM Interaction Between Integrity NonStop and NonStop S-Series Systems 3-4

Part II. DSM/SCM Configuration

4. Planning the DSM/SCM System Environment and User SecurityTask 1: Planning the DSM/SCM Environment 4-2

Single System 4-2

Multiple Systems 4-2

Multiple Logical Targets 4-3

System Environment Examples 4-4

Task 2: Install the Planner Interface on the PC 4-7

Task 2.1: Ensure TCPIP and LISTNER Are Installed and Running 4-8

Task 2.2: Transfer DSM/SCM PC Files From the SUT to the PC 4-8

Task 2.3: Ensure Winsock Is Installed 4-8

DSM/SCM User’s Guide — 529846-014ii

Contents 5. Configuring DSM/SCM

Task 2.4: Run SETUP.EXE 4-8

Task 3: Planning DSM/SCM Users and Security 4-9

Guidelines for Assigning DSM/SCM Security Settings 4-10

Database Administrator Tasks 4-13

Planner Tasks 4-14

Operator Tasks 4-16

5. Configuring DSM/SCMConfiguring a Host or Target System 5-2

Preparing to Configure DSM/SCM 5-2

Task 1: Changing Default Settings Using INITENV 5-3

Task 2: Configure the Host Database 5-5

Task 3: Configure the Target Database 5-7

Task 4: Initialize the Logical Target 5-7

Setting DSM/SCM Security 5-8

Remapping an Alias to a Different Guardian User ID 5-8

Setting the DSM/SCM User ID 5-8

Setting Security for Planners 5-8

Setting Security for Database Administrators 5-11

Setting Security for Operators 5-13

Managing the DSM/SCM Configuration 5-15

Changing DSM/SCM Default Parameters 5-15

Managing Logical Targets 5-17

Creating an Alternate System Disk 5-22

Configuring a Backup Host System 5-23

Reinitializing DSM/SCM 5-30

Part III. Software Installation and Management

6. Managing Software With DSM/SCMManaging Software to Avoid a System Load 6-2

Receiving New Software Into the Archive 6-2

Creating a Software Revision 6-3

Building and Applying the New Configuration Revision 6-4

Applying the Configuration Revision 6-4

Transferring and Receiving the Snapshot Into the Host Database 6-5

Activating the New Software on the Target System 6-5

DSM/SCM User’s Guide — 529846-014iii

Contents 7. Receiving and Managing Software Inputs

7. Receiving and Managing Software InputsPreparing to Receive Software 7-2

Receiving Software Into the Archive 7-3

Specifying the Location of the Software Input Source 7-6

Scheduling a Time to Run a Request 7-7

Checking the Status of the Request 7-8

Managing Software Inputs 7-9

Changing the Software Input Description 7-9

Limiting the Software Inputs to Display 7-10

Managing Software Input Groups or Product Groups 7-11

8. Creating and Managing Software RevisionsChecking Product Information 8-2

Checking the Contents of Distribution Subvolumes 8-2

Checking for Recommended Software Product Revisions (SPRs) 8-2

Listing Products and Product Files 8-6

Checking the Product Version Details 8-8

Checking Softdocs and Release Documents 8-10

Checking the Revision History of a Software Configuration 8-13

Creating Software Revisions 8-15

Task 1: Create a New Software Revision 8-16

Task 2: Copy Products to the New Software Revision 8-18

Task 3: Check the Product Version Details of the New Revision 8-21

Task 4: Edit the Software Revision Notes 8-21

Managing Software Revisions 8-22

Saving a New Software Revision 8-22

Closing a New Software Revision Window 8-22

Canceling a New Software Revision 8-22

Modifying the New Revision 8-23

Deleting a New Software Revision 8-24

Deleting Products From a New Software Revision 8-24

Deleting Old Software Revisions 8-24

Sharing Software Revisions 8-25

9. Building and Applying a New ConfigurationBuild Types 9-2

Normal Build/Apply 9-2

Initialization Build/Apply 9-2

FRABIBAB 9-3

DSM/SCM User’s Guide — 529846-014iv

Contents 10. Activating New Software on a Target System

File Locations 9-3

Creating a Configuration Revision 9-4

Preparing for a Build and Apply Request 9-4

1. Check If Additional Disk Space Is Required 9-5

2. Check That the Spooler Is Active 9-5

3. Collect the Information Needed for the Build 9-5

4. Specify PARAMs as Needed 9-6

5. Assemble the Planner Instructions to the Operator 9-6

Task 1: Initiate the Build/Apply Request 9-8

Initiating the Normal Build and Apply 9-8

Initiating an Initialization Build and Apply 9-8

Build/Apply Request Dialog Box 9-8

Task 2: Indicate a Build/Apply or Build Request 9-10

Task 3: Specify the SYSnn Subvolume 9-11

Task 4: Set the Options for the Build and Apply Request 9-12

Setting Target Subvolume Locations 9-12

Setting Output Options 9-14

Setting System Generation Options 9-18

Setting File Placement Options 9-19

Task 5: Schedule the Request 9-22

Task 6: Edit the Instructions 9-23

Task 7: Submit the Request 9-24

Task 8: Apply Software to the Target System 9-25

Task 9: Transfer and Receive the Snapshot Into the Host Database 9-27

Transferring the Snapshot to the Host System 9-28

Receiving the Snapshot From Disk or Tape 9-28

10. Activating New Software on a Target SystemSummary of Activating the Software 10-2

Print the Instructions for Activating the Software 10-3

Example: Planner Instructions to Operator 10-3

11. Renaming Product Files Using ZPHIRNMRun ZPHIRNM in Preview Mode 11-2

Prepare to Run ZPHIRNM 11-3

Run ZPHIRNM 11-4

Error Handling 11-6

12. Loading the SystemRenaming the Managed SYSnn (Optional) 12-2

DSM/SCM User’s Guide — 529846-014v

Contents 13. Troubleshooting

Stopping the System by Halting the Processors 12-3

Loading the System 12-3

Running PATHCOLD 12-4

Part IV. Troubleshooting and Recovery Procedures

13. TroubleshootingChecking History 13-2

Checking the Revision History 13-2

Checking Requests 13-2

Checking Error Messages 13-2

Checking EMS Messages for the Current Request 13-2

Checking EMS Messages Not Related to the Current Request 13-3

Printing EMS Messages 13-4

Checking System Generation Errors 13-4

Checking Workstation Error Log Files 13-4

Checking Pathway Errors 13-4

Volume Management Troubleshooting 13-5

Alternate System Volume Troubleshooting 13-5

Database Management Troubleshooting 13-8

Network Troubleshooting 13-9

Space Management Troubleshooting 13-9

DSM/SCM Configuration Troubleshooting 13-10

Software Configuration Troubleshooting 13-11

Migration Troubleshooting 13-11

Build/Apply Troubleshooting 13-13

Discrepancy Troubleshooting 13-17

Request Troubleshooting 13-18

Interface Troubleshooting 13-20

Planner Interface Troubleshooting 13-20

Maintenance Interface Troubleshooting 13-21

ZPHITI Troubleshooting 13-22

CNFGINFO Troubleshooting 13-23

Recovery Operations 13-24

Cleaning Target Work Files for OSS 13-24

14. Special Troubleshooting and Recovery ProceduresRunning Traces 14-2

DSM/SCM User’s Guide — 529846-014vi

Contents 15. Backing Out a Revision

Enabling Traces 14-3

Disabling Traces 14-5

Filtering Traces 14-6

Trace Levels 14-6

Recovering Installed Products Using SIT2SCM 14-14

Task 1: Boot the System From a SIT 14-14

Task 2: Start All Processors 14-15

Task 3: Start the ZSERVER Process 14-15

Task 4: Configure and Start Required Disk and Tape Drives 14-15

Task 5: Create Input Files 14-16

Task 6: Use the RESTORE and FUP Input Files 14-16

Task 7: Rename the Template Files 14-16

Task 8: Start Required Processes 14-17

Task 9: Start the E4SA 14-17

Task 10: Configure and Start TCP/IP 14-17

Task 11: License SQL/MP Files 14-18

Task 12: Configure and Start TMF 14-18

Task 13: Create the System Catalog 14-19

Task 14: Create a SPLCONF File and Start the Spooler 14-19

Task 15: Set Up DSM/SCM Profiles and Environment 14-19

15. Backing Out a RevisionBacking Out If DSM/SCM Is Running 15-2

Task 1: Start DSM/SCM 15-2

Task 2: Start and Log On to the ZPHITI 15-2

Task 3: Perform Backout Activities 15-3

Task 4: Monitor the Backout Process 15-4

Task 5: Stop All Applications 15-5

Task 6: Run ZPHIRNM in Preview Mode 15-5

Task 7: Rename Software Files Using ZPHIRNM 15-5

Task 8: Stop and Load the System 15-5

Task 9: Start TMF and Your Applications 15-6

Backing Out in Special Circumstances 15-6

Previous Configuration Does Not Exist or DSM/SCM Does Not Run 15-6

After Renaming the SYSnn 15-7

Backing Out to an Older Configuration 15-9

Fallback Considerations 15-9

Guardian User IDs 15-9

Removing OSS Management Information From the DSM/SCM Databases 15-10

DSM/SCM User’s Guide — 529846-014vii

Contents 16. Managing Requests

Part V. Supplemental Procedures

16. Managing RequestsSubmitting a Request 16-2

Types of DSM/SCM Requests 16-2

Scheduling a Request 16-2

Checking Requests 16-3

Displaying the Request Window 16-3

Restricting the Requests Displayed 16-4

Checking the Status of a Request 16-4

Restarting a Request 16-7

Canceling a Request 16-8

Deleting a Request (ZPHIHMI or ZPHITMI) 16-8

17. Managing DSM/SCMUpdating DSM/SCM Profile Information 17-2

Configuration Manager Profile 17-2

System Profile 17-4

Target Profile 17-6

Managing Volumes Used by DSM/SCM 17-11

Updating the Volume Usage 17-11

Moving the ZDSMSCM Subvolume to Another Volume 17-13

Renaming a Volume Managed by DSM/SCM 17-14

Deleting a SYSnn Subvolume 17-15

Managing DSM/SCM Databases 17-16

Canceling the Check-Out of a Database Object 17-16

Moving a DSM/SCM Database (ZPHIHMI or ZPHTMI) 17-17

Updating DSM/SCM Databases 17-18

Creating an Independent Snapshot of the Target System 17-19

Managing the DSM/SCM Archive 17-21

Managing Files (Software Inputs) in the Archive 17-21

Exporting Files From the Archive 17-24

Bringing an Exported File Back Into the Archive After the File Has Been Modified 17-26

Moving the DSM/SCM Archive (ZPHIHMI) 17-27

18. Generating DSM/SCM ReportsDSM/SCM Reports 18-2

Custom Reports 18-2

DSM/SCM User’s Guide — 529846-014viii

Contents 19. Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning)

Standard Reports 18-2

Viewing and Printing DSM/SCM Reports 18-7

Preparing a Report for Printing or Viewing 18-7

Viewing a Report Online 18-9

Creating Reports 18-10

Modifying Standard Reports 18-10

Creating Custom Reports 18-12

Creating a System Report 18-13

Creating a Discrepancy Report for a Clone 18-14

Adding and Deleting Reports 18-15

Adding a Report to DSM/SCM (Planner Interface) 18-15

Deleting a Report From DSM/SCM 18-15

Shorthand Views of the DSM/SCM Database 18-16

Activity Control View 18-16

Activity Code Descriptions 18-17

Status Code Descriptions 18-17

Activity Param View 18-18

Configuration Manager View 18-19

Configuration Product Version Files View 18-19

Configuration Products Versions View 18-20

Configuration View 18-21

EMS View 18-22

Logical Target Profile View 18-22

Snapshot Files View 18-24

Software Input Files View 18-25

Software Input Products View 18-26

System View 18-27

Tape Drives View 18-27

TSV View 18-28

Volumes View 18-28

19. Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning)Cloning Requirements 19-1

Creating a Clone Group 19-2

Task 1: Define a Master Target 19-2

Task 2: Define Clone Targets 19-2

Examples: Clone Groups 19-3

Applying a Software Configuration to a Clone Group 19-5

DSM/SCM User’s Guide — 529846-014ix

Contents 20. Installation of Web Interfaces (H-Series and J-Series Only)

Creating a Clone Group Software Configuration 19-5

Building and Applying a Clone Group Configuration Revision 19-5

Renaming Product Files for a Clone Group 19-6

Creating a Noncloning Configuration on a Master or Clone 19-7

Removing a System From a Clone Group 19-8

Removing a Master From a Clone Group 19-8

Removing a Clone From a Clone Group 19-8

20. Installation of Web Interfaces (H-Series and J-Series Only)Web Interfaces Requirements 20-1

Installation Procedure for DSM/SCM Web Interfaces 20-2

Starting the Application 20-2

A. DSM/SCM Architecture and EnvironmentArchitecture Overview A-2

$YPHI Pathway Servers A-5

Schedule Manager (SM) A-5

Input Supervisor (IS) A-5

Configuration Builder (CB) A-5

Target Activator (TA) A-5

Utility Server (US) A-6

Interface Servers A-6

B. DSM/SCM DifferencesComparing DSM/SCM Product Versions B-2

Comparing T6031G02 to H01 B-2

Comparing T6031H01 to D46 B-2

Upgrading to DSM/SCM T6031G02 B-3

Task 1: Install the DSM/SCM G02/H02 Planner Interface B-3

Task 2: Start TMF and DSM/SCM B-4

Task 3: Log On to DSM/SCM B-4

Task 4: Receive DSM/SCM T6031G02 Into the Archive B-4

Task 5: Upgrade Your Host and Target Systems to T6031G02 B-4

C. Running CNFGINFO Preparing to Run CNFGINFO C-2

Entering CNFGINFO C-3

Exiting CNFGINFO C-3

CONFIGINFO Summary C-4

Task 1: Start and Log On to CNFGINFO C-4

DSM/SCM User’s Guide — 529846-014x

Contents D. Required Processes and Files

Task 2: Open or Create an A0CINFO File C-5

Task 3: Specifying Product or File Information C-6

Specifying Product Attributes C-6

Specifying Product Dependencies C-8

Specifying File Information C-9

Task 4: Log Off C-16

D. Required Processes and FilesRequired Processes D-2

Required Volumes D-2

System Load Volume D-2

DSM/SCM Application and Database Volume D-5

Archive and Audit Volume D-7

Scratch Volume D-8

Required Files D-9

DSM/SCM Server Files D-9

ZPHIRNM Rename Work Files D-9

E. ASSIGNs and PARAMsAssigning and Activating Tools E-2

Removing PARAMs or ASSIGN Statements From the List E-2

Adding ASSIGN Statements for Tools E-2

Specifying a PARAM From the Planner Interface E-5

Specifying a PARAM From PATHCOM E-5

PARAM Summary E-6

IGNORE-SAFEGUARD-PROTECTION Param E-11

KEEP-OBSOLETE-SYSNN Param E-12

OVERRIDE-SYSNN and OVERRIDE-SYSNN-DIFFERENT-OS Params E-13

Glossary

Index

ExamplesExample 5-1. Discrepancy Report 5-38

Example 14-1. Example TRACEINI File 14-7

FiguresFigure 1-1. Typical DSM/SCM Environment 1-3

Figure 1-2. Software Configuration Management Overview 1-8

Figure 2-1. Planner Interface Main Window 2-5

DSM/SCM User’s Guide — 529846-014xi

Contents Tables

Figures (continued)Figure 2-2. Maintenance Interface Logon Screen 2-8

Figure 2-3. Maintenance Interface Target System Main Menu 2-9

Figure 2-4. Maintenance Interface Screen Example 2-10

Figure 2-5. ZPHITI Logon Screen 2-12

Figure 2-6. ZPHITI Main Menu 2-13

Figure 2-7. ZPHITI Screen Example 2-14

Figure 4-1. How Host Systems, Target Systems, and Logical Targets Relate 4-3

Figure 4-2. Typical DSM/SCM Environment 4-5

Figure 4-3. Host and Target Databases 4-6

Figure 4-4. DSM/SCM Role Assignment Example 4-12

Figure 8-1. Non-SUT Products Dialog Box 8-19

Figure 8-2. Heap Manager Selection Dialog Box 8-20

Figure 9-1. Build/Apply Request Window 9-9

Figure 15-1. Backing Out a Revision 15-1

Figure 16-1. Request Scheduling Options Dialog Box 16-3

Figure 17-1. Files in the Archive 17-21

Figure 19-1. Clones Displayed in Configuration Revisions Window 19-4

Figure A-1. DSM/SCM Architecture Overview A-2

Figure A-2. DSM/SCM Host System Environment A-3

Figure A-3. DSM/SCM Target System Environment A-4

TablesTable i. Summary of Contents xx

Table 4-1. Installing Planner Interface Checklist 4-7

Table 4-2. Suggested Assignments for Different Work Environments 4-10

Table 5-1. Changing Default Settings Checklist 5-4

Table 5-2. Changing DSM/SCM Default Parameters 5-15

Table 5-3. Reinitialization Checklist 5-31

Table 7-1. Receive Software Request 7-5

Table 14-1. Search String Examples 14-8

Table 17-1. Configuration Profile Information 17-3

Table 17-2. System Profile Information 17-5

Table 17-3. Output Defaults 17-7

Table 17-4. System Generation Information 17-10

Table 18-1. Standard DSM/SCM Reports 18-2

Table C-1. System Generation Options C-14

Table E-1. ASSIGNs E-3

DSM/SCM User’s Guide — 529846-014xii

Contents

DSM/SCM User’s Guide — 529846-014xiii

What’s New in This Manual

Manual InformationDSM/SCM User’s Guide

Abstract

This guide describes the Distributed Systems Management/Software Configuration Manager (DSM/SCM) and explains how to configure DSM/SCM and use it to manage and configure the software on your system.

Product Version

DSM/SCM G02

DSM/SCM H02

Supported Release Version Updates (RVUs)

This guide supports J06.03 and all subsequent J-series RVUs, H06.03 and all subsequent H-series RVUs, and G06 and all subsequent G-series RVUs, until otherwise indicated by its replacement publications.

Document History

New and Changed Information

Changes to the 529846-014 manual:

Added a point and note in the section, Run ZPHIRNM on page 11-4.

Removed TSM references in the document.

Updated note in the section, Who Should Use This Guide on page -xix.

Part Number Published

529846-014 June 2014

Part Number Product Version Published

529846-008 DSM/SCM G02 (ABU)/H02 February 2007

529846-009 DSM/SCM G02 and H02 May 2008

529846-010 DSM/SCM G02 and H02 August 2009

529846-011 DSM/SCM G02 and H02 February 2011



529846-014 DSM/SCM G02 and H02 June 2014

DSM/SCM User’s Guide — 529846-014xv

What’s New in This Manual Changes to the 529846-013 manual:


Added a note in the section, Who Should Use This Guide, on page -xix.


Added a note under the Loading the System section on page 12-3.

Added Enabling Object Manager Tracing heading under the Enabling Traces section on page 14-5.

Added Disabling Object Manager Tracing heading under the Disabling Traces section on page 14-6.


Added a note about the IPSetup to Installing and Configuring Software section on page 1-7.

Added a note about multiple logical targets to these sections:

Running ZPHIRNM on page 11-2.

Run ZPHIRNM in Preview Mode on page 11-3.

Prepare to Run ZPHIRNM on page 11-4.

Run ZPHIRNM on page 11-5.

Updated Estimating Freed Disk Space (ZPHIHMI) section with a workaround on page 17-22.

Updated the graphical user interface feature in Major DSM/SCM Features on page 1-2.

Updated the Task 2: Install the Planner Interface on the PC section on page 4-7.

Changes in the H06.19/J06.08 manual:

Added a caution about $SYSTEM backups under Recovering Installed Products Using SIT2SCM on page 14-14 and under Configuring a Backup Host System on page 5-23.

Changes in the H06.14/J06.03 manual:

Updated the description on File Types Supported by DSM/SCM on page 1-9.

Updated the graphical user interface feature in Major DSM/SCM Features on page 1-2.

Updated the description on the planner interface in Task 2: Install the Planner Interface on the PC on page 4-7.

DSM/SCM User’s Guide — 529846-014xvi

What’s New in This Manual Changes to the H06.09 Manual

Added a step in Task 1: Changing Default Settings Using INITENV on page 5-3.

Added a checkpoint in the table Changing Default Settings Checklist on page 5-4.

Added an interface and its function in the table Changing DSM/SCM Default Parameters on page 5-15.

Added a checkpoint in the table Reinitialization Checklist on page 5-31.

Removed the text “port” from Starting the Application on page 20-2.

References to Release Version Updates (RVUs) throughout this manual have been updated to include references to J-series RVUs, where appropriate.

Changes to the H06.09 Manual

Added a note on DSM/SCM initialization activities on page 5-5.

Removed the text “(G-Series Only)” from the heading of Section 19, Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning) as cloning is also supported on H-series RVUs.

Added Section 20, Installation of Web Interfaces (H-Series and J-Series Only)

DSM/SCM User’s Guide — 529846-014xvii

What’s New in This Manual Changes to the H06.09 Manual

DSM/SCM User’s Guide — 529846-014xviii

About This GuideThis guide provides task-oriented instructions for using the DSM/SCM interfaces to perform the activities associated with installing and managing software revisions.

This guide documents DSM/SCM T6031G02 for G-series RVUs and T6031H02 for H-series and J-series RVUs.

DSM/SCMThe Distributed Systems Management/Software Configuration Manager (DSM/SCM) is a tool for managing and configuring software installation on distributed target systems.

Who Should Use This GuideReaders must be familiar with the fundamentals of the HP NonStop operating system and have a general understanding of NonStop operating system installation concepts.

In addition, readers should have experience in one or more of these areas, depending on their role as DSM/SCM users:

Software configuration planning

Computer systems operations

Database administration

Security administration

DSM/SCM User’s Guide — 529846-014xix

About This Guide Who Should Use This Guide

Note. The DSM/SCM User’s Guide is applicable if you are using DSM/SCM Planner Interface. The go forward solution for NonStop software management is NonStop Software Essentials, which replaces the DSM/SCM Planner Interface in addition to certain Host Maintenance Interface functions. NonStop Software Essentials works with DSM/SCM server, providing a web-based interface that is more secure, easier to use, and overcomes other shortcomings of DSM/SCM.

HP recommends that you migrate to NonStop Software Essentials. It is required on 64-bit consoles (which includes NonStop system consoles running Windows Server 2008), where the DSM/SCM Planner Interface is not supported. For information on migrating to and using NonStop Software Essentials, see:

NonStop Software Essentials Installation and Quick Start Guide – Helps you prepare for, install, and get started with NonStop Software Essentials.

NonStop Software Essentials User’s Guide – Provides the equivalent of the DSM/SCM User’s Guide for anyone using NonStop Software Essentials instead of the DSM/SCM Planner Interface, including all of the DSM/SCM server-related information necessary when using NonStop Software Essentials.

HP SIM for NonStop Manageability – HP recommends installing HP SIM and plug-ins, such as NonStop Software Essentials on a separate Central Management Server (CMS) rather than on the NonStop system consoles (although they are supported on NonStop system consoles as well). This document provides the rules and guidelines for setting up the appropriate console configuration for your environment.

DSM/SCM User’s Guide — 529846-014xx

About This Guide What’s in This Guide

What’s in This Guide

Table i. Summary of Contents (page 1 of 3)

Section Title This section . . .

PART I DSM/SCM Overview

1 Introduction to DSM/SCM Provides an overview of the functions and capabilities of DSM/SCM and defines the terms and concepts needed to understand DSM/SCM.

2 DSM/SCM Interfaces and Tools Provides an overview of the DSM/SCM interfaces and tools.

3 Hardware and Software Requirements

Provides an overview of the hardware and software required to run DSM/SCM on NonStop systems. This section also describes the DSM/SCM preinstalled configuration and information about essential files that you cannot purge or alter.

PART II DSM/SCM Configuration

4 Planning the DSM/SCM System Environment and User Security

Describes host and target systems, logical targets, and databases, and provides guidelines for defining your systems. Describes DSM/SCM tasks and provides guidelines for assigning them.

5 Configuring DSM/SCM Gives step-by-step instructions for configuring DSM/SCM and setting up the supporting environment on the host and target systems.

PART III

Software Installation and Management

6 Managing Software With DSM/SCM

Describes DSM/SCM use and the planning of software management on your systems. Provides an overview of the procedures detailed in Sections 7 through 12.

7 Receiving and Managing Software Inputs

Provides step-by-step procedures for receiving and managing software inputs, and for managing input and product groups.

8 Creating and Managing Software Revisions

Provides step-by-step procedures for creating software revisions in preparation for software installation or updating. This section also provides information on managing and sharing software revisions.

9 Building and Applying a New Configuration

Provides step-by-step procedures for building and applying new configurations for target systems.

DSM/SCM User’s Guide — 529846-014xxi


10 Activating New Software on a Target System

Provides an overview of procedures to activate software on a target system.

11 Renaming Product Files Using ZPHIRNM

Provides step-by-step procedures for running ZPHIRNM.

12 Loading the System Provides procedure to perform a system load.

PART IV

Troubleshooting and Recovery Operations

13 Troubleshooting Provides troubleshooting information for various situations that can arise while running DSM/SCM.

14 Special Troubleshooting and Recovery Procedures

This section provides troubleshooting and recovery procedures that should only be used under the direction of HP support personnel.

15 Backing Out a Revision Provides step-by-step procedures for backing a system out to its previous configuration.

PART V Supplemental Procedures

16 Managing Requests Describes how to submit and review DSM/SCM requests

17 Managing DSM/SCM Describes maintenance tasks provided through DSM/SCM, their procedures, and when you might need to use them.

18 Generating DSM/SCM Reports Describes the packaged reports available through DSM/SCM and explains how to create custom reports. This section also includes the shorthand views of the DSM/SCM database, which help you select information to appear in DSM/SCM reports.

19 Section 19, Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning)

Describes a simplified process for using DSM/SCM to install and manage identical software configurations on multiple NonStop servers.

20 Section 20, Installation of Web Interfaces (H-Series and J-Series Only)

Describes requirements and procedure for installing DSM/SCM web interfaces

Appendixes

A DSM/SCM Architecture and Environment

Provides an overview of the internal component architecture of DSM/SCM.

B DSM/SCM Differences Describes differences between Install and DSM/SCM and between using DSM/SCM on different HP NonStop systems. It also describes DSM/SCM updates you should be aware of.



DSM/SCM User’s Guide — 529846-014xxii


This guide also contains a glossary of technical terms and acronyms used throughout the text.

C Running CNFGINFO Provides information about using CNFGINFO to create a configuration information file for software.

D Appendix D, Required Processes and Files

Describes the preconfigured subsystem contents for DSM/SCM.

E Appendix E, ASSIGNs and PARAMs

Describes how to use ASSIGNs and PARAMs related to DSM/SCM.



DSM/SCM User’s Guide — 529846-014xxiii

About This Guide Using This Guide

Using This Guide

The sections you should read depend on the tasks you perform using DSM/SCM:

Other DSM/SCM Information Sources

The DSM/SCM online help provides context-sensitive information about using the interfaces. Online help is available for the Planner Interface (Planner Interface),

If you are... Read these sections

A first-time DSM/SCM user Section 1, Introduction to DSM/SCM

Section 2, DSM/SCM Interfaces and Tools

Appendix A, DSM/SCM Architecture and Environment

All users Appendix B, DSM/SCM Differences

Configuring or reconfiguring DSM/SCM

Section 4, Planning the DSM/SCM System Environment and User Security

Section 5, Configuring DSM/SCM

Managing software on systems using DSM/SCM

Section 6, Managing Software With DSM/SCM

Section 7, Receiving and Managing Software Inputs

Section 8, Creating and Managing Software Revisions

Section 9, Building and Applying a New Configuration

Section 10, Activating New Software on a Target System

Section 11, Renaming Product Files Using ZPHIRNM

Section 12, Loading the System

Troubleshooting DSM/SCM Section 13, Troubleshooting

Section 14, Special Troubleshooting and Recovery Procedures

Section 15, Backing Out a Revision

Managing DSM/SCM Section 16, Managing Requests

Section 17, Managing DSM/SCM

Section 18, Generating DSM/SCM Reports

Creating configuration information files for third-party or customer-created software,

Section C, Running CNFGINFO

DSM/SCM User’s Guide — 529846-014xxiv

About This Guide Notation Conventions

the Maintenance Interfaces (ZPHIHMI and ZPHITMI), the Target Interface (ZPHITI), and CNFGINFO.

The DSM/SCM Messages Manual provides detailed cause, effect, and recovery information for messages that you might encounter while using DSM/SCM.

The DSM/SCM Quick Reference Guide provides concise procedures for common DSM/SCM tasks. It is intended only for expert DSM/SCM users.

The DSM/SCM Event Management Programming Manual provides information about the token-oriented event messages from the programmatic interface to DSM/SCM. It is a reference manual for DSM/SCM event message token information and for programmers writing applications and filters to select DSM/SCM event messages.

Notation Conventions

Hypertext Links

Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example:

This requirement is described under Backup DAM Volumes and Physical Disk Drives on page 3-2.

General Syntax Notation

This list summarizes the notation conventions for syntax presentation in this guide.

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

computer type. Computer type letters within text indicate C and Open System Services (OSS) keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example:

myfile.c

italic computer type. Italic computer type letters within text indicate C and Open System Services (OSS) variable items that you supply. Items not enclosed in brackets are required. For example:

pathname

DSM/SCM User’s Guide — 529846-014xxv

About This Guide General Syntax Notation

[ ] Brackets. Brackets enclose optional syntax items. For example:

TERM [\system-name.]$terminal-name

INT[ERRUPTS]

A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list may be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example:

FC [ num ] [ -num ] [ text ]

K [ X | D ] address-1

{ } Braces. A group of items enclosed in braces is a list from which you are required to choose one item. The items in the list may be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example:

LISTOPENS PROCESS { $appl-mgr-name } { $process-name }

ALLOWSU { ON | OFF }

| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example:

INSPECT { OFF | ON | SAVEABEND }

… Ellipsis. An ellipsis immediately following a pair of brackets or braces indicates that you can repeat the enclosed sequence of syntax items any number of times. For example:

M address-1 [ , new-value ]...

[ - ] {0|1|2|3|4|5|6|7|8|9}...

An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times. For example:

"s-char..."

Punctuation. Parentheses, commas, semicolons, and other symbols not previously described must be entered as shown. For example:

error := NEXTFILENAME ( file-name ) ;

LISTOPENS SU $process-name.#su-name

Quotation marks around a symbol such as a bracket or brace indicate the symbol is a required character that you must enter as shown. For example:

"[" repetition-constant-list "]"

DSM/SCM User’s Guide — 529846-014xxvi

About This Guide Notation for Messages

Item Spacing. Spaces shown between items are required unless one of the items is a punctuation symbol such as a parenthesis or a comma. For example:

CALL STEPMOM ( process-id ) ;

If there is no space between two items, spaces are not permitted. In this example, there are no spaces permitted between the period and any other items:

$process-name.#su-name

Line Spacing. If the syntax of a command is too long to fit on a single line, each continuation line is indented three spaces and is separated from the preceding line by a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections. For example:

ALTER [ / OUT file-spec / ] LINE [ , attribute-spec ]…

Notation for Messages

This list summarizes the notation conventions for the presentation of displayed messages in this guide.

Bold Text. Bold text in an example indicates user input entered at the terminal. For example:

ENTER RUN CODE

?123

CODE RECEIVED: 123.00

The user must press the Return key after typing the input.

Nonitalic text. Nonitalic letters, numbers, and punctuation indicate text that is displayed or returned exactly as shown. For example:

Backup Up.

lowercase italic letters. Lowercase italic letters indicate variable items whose values are displayed or returned. For example:

p-register

process-name

[ ] Brackets. Brackets enclose items that are sometimes, but not always, displayed. For example:

Event number = number [ Subject = first-subject-value ]

A group of items enclosed in brackets is a list of all possible items that can be displayed, of which one or none might actually be displayed. The items in the list might be arranged either vertically, with aligned brackets on each side of the list, or

DSM/SCM User’s Guide — 529846-014xxvii

About This Guide Change Bar Notation

horizontally, enclosed in a pair of brackets and separated by vertical lines. For example:

proc-name trapped [ in SQL | in SQL file system ]

{ } Braces. A group of items enclosed in braces is a list of all possible items that can be displayed, of which one is actually displayed. The items in the list might be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example:

obj-type obj-name state changed to state, caused by{ Object | Operator | Service }

process-name State changed from old-objstate to objstate{ Operator Request. }{ Unknown. }

| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example:

Transfer status: { OK | Failed }

% Percent Sign. A percent sign precedes a number that is not in decimal notation. The % notation precedes an octal number. The %B notation precedes a binary number. The %H notation precedes a hexadecimal number. For example:

%005400

P=%p-register E=%e-register

Change Bar Notation

Change bars are used to indicate substantive differences between this revision of the manual and the preceding revision. Change bars are vertical rules placed in the right margin of changed portions of text, figures, tables, examples, and so on. Change bars highlight new or revised information. For example:

The message types specified in the REPORT clause are different in the COBOL environment and the Common Run-Time Environment (CRE).

The CRE has many new message types and some new message type codes forold message types. In the CRE, the message type SYSTEM includes all messages except LOGICAL-CLOSE and LOGICAL-OPEN.

HP Encourages Your CommentsHP encourages your comments concerning this document. We are committed to providing documentation that meets your needs. Send any errors found, suggestions for improvement, or compliments to [email protected].

Include the document title, part number, and any comment, error found, or suggestion for improvement you have concerning this document.

DSM/SCM User’s Guide — 529846-014xxviii


This part of the guide describes DSM/SCM, its interfaces, and its software and hardware requirements:

Section 1, Introduction to DSM/SCM

Introduces DSM/SCM and its functions

Section 2, DSM/SCM Interfaces and Tools

Describes the basic functions of each DSM/SCM interface and tool

Describes how to enter, exit, and navigate each DSM/SCM interface and tool

Section 3, Hardware and Software Requirements

Describes the hardware and software requirements for DSM/SCM

DSM/SCM User’s Guide — 529846-014

1 Introduction to DSM/SCM

The Distributed Systems Management/Software Configuration Manager (DSM/SCM) provides centralized planning, management, and installation of software on distributed (target) NonStop systems. This section introduces the basic concepts of DSM/SCM and indicates where they are addressed in detail later in this guide:

Major DSM/SCM Features on page 1-2

Configuring DSM/SCM on page 1-3

DSM/SCM Environment on page 1-3

DSM/SCM Security on page 1-6

Installing and Configuring Software on page 1-7

Managing the SYSnn Subvolumes on page 1-9

File Types Supported on page 1-9

Comparing DSM/SCM to COPYOSS/PINSTALL/PCleanup on page 1-10

DSM/SCM User’s Guide — 529846-0141 - 1

Introduction to DSM/SCM Major DSM/SCM Features

Major DSM/SCM FeaturesDSM/SCM offers many features that enable you to better manage software configuration on your systems, including:

Feature Description

Centralized control A planner at a central site (host system) can manage software on multiple remote target systems.

Graphical user interface

To access DSM/SCM, you primarily use the Planner Interface, a graphical user interface that runs on any PC running Microsoft Windows 2000, Windows NT, Windows 95, Windows Version 3.11, Windows XP, Windows Vista, Windows - 7 (32 Bit).

Softdoc and release document browsing

The planner can find dependencies for a given software product revision (SPR) or scan any release document on the site update tape (SUT).

Minimal downtime Wherever possible, new software configurations can be activated with minimal interruption of running applications.

Management of all software

DSM/SCM manages customer and third-party software and updates in addition to RVUs and updates (SPRs) from HP.

Multiple logical targets

Defining multiple logical targets lets you run multiple software configurations on a single system. This is useful for sites that run development (test) software configurations separate from production configurations. To switch the system from one sofware configuration to another, perform a system load from alternate system disks.

Flexibility in planning new software configurations

The planner can easily select specific products from software stored in the DSM/SCM archive to create a new software configuration based on a previous configuration, in which changed products are replaced by the new product versions.

Batch scheduling You can schedule DSM/SCM activities, such as receiving software, generating reports, and building configurations, to run as batch processes at a specified time, such as after normal working hours.

Extensive reporting DSM/SCM can produce preformatted SQLCI reports providing detailed information about the software configurations in the DSM/SCM environment. You can modify these reports and create new reports tailored to your site specifications.

Predefined operator instructions

Provided with every software configuration placed on target systems, the planner edits these instructions with site-specific information.

System profiles Profiles provide defaults for options and information required by DSM/SCM tasks. These defaults greatly reduce the amount of information you must supply when using DSM/SCM.


Introduction to DSM/SCM Configuring DSM/SCM

Configuring DSM/SCM To plan the organization of systems managed by DSM/SCM, see Task 1: Planning the DSM/SCM Environment on page 4-2. For the procedures for configuring or reconfiguring the DSM/SCM environment, see Section 5, Configuring DSM/SCM.

DSM/SCM Environment You can use DSM/SCM from a central host system to manage software on distributed target systems. This overview describes concepts you need to understand before you set up the DSM/SCM environment. In Figure 1-1, DSM/SCM manages three targets from a central host system.

For guidelines on defining hosts and targets, and for establishing their means of communication, see Task 1: Planning the DSM/SCM Environment on page 4-2.

Figure 1-1. Typical DSM/SCM Environment

Host\A

system

Target1

Expandconnection

\Bsystem

Target3

\Csystem

DSM/SCMArchive

\CTarget

Database

tape

HostDatabase

\A

TargetDatabase

Target2

User Interface

\BTarget

Database

Stand-alone targetsystem uses tape to

communicate with host

VST001.vsd

User Interface User Interface

Block-modeinterface

Block-modeinterface

Winsockconnection


Introduction to DSM/SCM DSM/SCM Environment

Host System

From a host system, use the Planner Interface on the host system to perform these tasks:

Transfer software files to target systems

Receive software into the DSM/SCM environment

Archive the software

Plan and create software revisions

Package and initiate the placement of software on distributed target systems

One host system can centrally control the configurations of many target systems or several host systems can manage different systems in one site. If you maintain separate development and production systems, you could use one host system for the development systems and another host system for the production systems.

Target Systems

DSM/SCM also runs on each target system, where it places (applies) the software received from the host system. Any system managed by DSM/SCM that is not a host system is a target system. The host system includes its own target because the host activates and manages the system software on itself.

Host and Target System Communication

A host system can be connected to a target system in one of three ways:

Network connected using Expand

Network connected without Expand (Transfer the files using either file transfer tools or disk.)

Not network connected (Transfer the files to the remote system using magnetic tape.)

When configuring the network connection between a host system and a target system, use the REMOTEPASSWORD command to run the RPASSWRD program with which you can establish passwords for the target system as needed. For more information, see the Guardian User’s Guide.

Physical Targets

A physical target system (often referred to as target system) is any system managed by DSM/SCM that is not the host system and to the physical target system on the host system. A physical target system is defined with one or more logical targets.


Introduction to DSM/SCM DSM/SCM Archive

Logical Targets

A logical target is a specific software configuration on a target system. Every system, including the host system, contains at least one logical target. The host activates and manages its own software as it does for any of its target systems.

To manage different software configurations independently can manage different software configurations independently on a single system, use multiple logical targets. Provide a unique name for each logical target on the system. Each logical target requires its own separate $SYSTEM volume. The same host system must manage all the logical targets on a system.

DSM/SCM Archive

The DSM/SCM archive on the host system provides storage for software received into DSM/SCM. The DSM/SCM archive stores:

All the software input into DSM/SCM from release version updates (RVUs), software product revisions (SPRs), and third-party products. The configuration revisions use the archived files when the software is configured.

The system generation output for configurations, including the OSIMAGE file.

The archive is located on one or more volumes of the host system. The planner specifies the archive volumes when configuring DSM/SCM and can add or change volumes using the Host Maintenance Interface (ZPHIHMI).

The software remains in the archive. You can copy software from the archive to update the software configuration of a system.

Host and Target Databases

Each DSM/SCM system has one or more SQL databases for storing configuration information. Each database must be located on a volume that is audited by HP NonStop Transaction Management Facility (TMF) and has sufficient free space. The volume name, including the dollar sign, cannot exceed seven characters. To ensure the volume name does not change, do not place the host or target database on an alternate system disk.

Host Database

The host database must reside on the host system and contains information about requests, software, snapshots, configurations, and profiles. This information is essential to the operation of the Planner Interface.


Introduction to DSM/SCM DSM/SCM Security

Target Database

Each target database contains information about the files in a logical target, including file names, attributes, and fingerprints (checksum-type file identifiers).

The target database for the host system is typically kept on the host system in the same volume as the host database. Target databases should reside on their respective target systems. However, the target databases also can reside on a different system if it has an Expand connection to that target system. Moving a target database from one system to another requires running INITENV to reinitialize the system whose database you are moving. For guidelines on where you should locate target databases, see Multiple Systems on page 4-2.

DSM/SCM Security There are three roles for DSM/SCM:

For more information on DSM/SCM tasks that each role has permission to perform and on assigning DSM/SCM security settings, see Task 3: Planning DSM/SCM Users and Security on page 4-9.

Planner Plans, builds, and applies software configurations. Assumes primary responsibility for the installation of software using DSM/SCM. The planner must have detailed knowledge and understanding of installation procedures and DSM/SCM operations, as well as software dependencies, softdocs, and the Software Installation and Upgrade Guide.

Operator Initiates activities on target systems, usually under the direction of the planner. Acts on instructions from the planner to initiate activities on the target systems. The operator needs only minimal understanding and experience with software installation procedures and DSM/SCM operation.

Database administrator

Maintains the DSM/SCM databases and archive. Maintains security of the DSM/SCM installation files and files on target systems. Establishes user access permissions for target systems. Often installs or updates the configuration of DSM/SCM on all systems. This person must have an understanding of DSM/SCM concepts and SQL database administration concepts and procedures.


Introduction to DSM/SCM Installing and Configuring Software

Installing and Configuring Software Use DSM/SCM to install and manage new and revised software products from HP or third-party vendors. HP delivers release version updates (RVUs) on a site update tape (SUT) on one or more tapes. SPRs are usually delivered on a backup tape or through a network connection.

You can choose when DSM/SCM requests are executed, but you must perform all requests in the specified order.

Receive the software into the DSM/SCM archive on your host system. DSM/SCM receives SPRs independently into the archive, then rolls up the SPRs when you use Copy to or Copy matches. This procedure allows DSM/SCM to be able to show exactly which files changed in which SPRs and allows you greater flexibility in managing configurations. To create a list of the products to be installed called a new software revision, you select software stored in the archive.

A Build request readies the software to be placed on the target system by an Apply request. The Build creates a new configuration revision that contains the product versions, an operating system image, and relevant DSM/SCM profile items such as the location of the target subvolume.

An Apply request places the configuration revision on the target system using temporary file names. Guardian files for a target system are placed in a TSV. OSS files are placed in a target directory location (TDL). A snapshot of the target’s new configuration is received into the host database to update the host’s record of the target’s software configuration.

From there the software is renamed, put in its proper functioning location, and then activated. You must run ZPHIRNM before performing a system load if one is required. You use ZPHIRNM to change the temporary file names to their real names. ZPHIRNM deletes the temporary files and overwrites any existing files with the same names that need to be replaced. ZPHIRNM also renames all the currently running files to temporary file names. You can use these files later if you need to back out a revision. ZPHIRNM is run independently of all other processes, so you can minimize application downtime and schedule it for a time most convenient for your work environment.

Caution. Inputs to the archive must be received as delivered from HP. Do not overlay SPRs into product distribution subvolumes (DSVs) before receiving the software into the archive.

Note. For H/J series systems where SUT is delivered through CD/DVD, the IPSetup User's Guide needs to be followed to place the files on the NonStop Systems. IPSetup starts the $ZRVU process and thus helps the Planner Interface to perform Receive Software activity.

Note. When a Gxx SUT that contains both the heap manager products (T8431 and T1269) is copied to the new software revision, the Heap Manager Selection dialog box is displayed. This feature is supported only on systems running G06.29 and later G-series RVUs. After selecting the desired heap manager product, click the Continue button to copy the SUT to the new software revision. To cancel the Copy to operation, click the Cancel button.


Introduction to DSM/SCM Installing and Configuring Software

The temporary file naming allows files to be applied while the system is running without interfering with the existing files on the running system. If the system needs to be backed out to the previous revision, ZPHIRNM is run during the Backout process to give the actual file names back to the files from the previous revision. The renaming process reduces application downtime and allows for a quick backout by rerunning ZPHIRNM and specifying the previous SYSnn.

Figure 1-2 is an overview of the software configuration management process in a typical DSM/SCM usage pattern, applied to networked and non-networked systems.

For detailed procedures, see Part III, Software Installation and Management.

Figure 1-2. Software Configuration Management Overview

1. Receive software inputs into the Archive (on host):

RVUsSPRs

Third-party software Customer software

2. Create a new software revision (on host): Review softdocs. Create new revision from an existing revision.

3. Build a configuration revision (on host): DSM/SCM builds SRLs or DLLs. DSM/SCM packages software into activation package on disk or tape.

4. Apply the configuration revision (on target):

DSM/SCM puts new software into TSVsor TDLs. DSM/SCM creates snapshot toupdate host database.

5. Activate the software on the target system:

Operator follows planner instructions.

\A Host system

\B Target system

\C Target system

TargetInterface

TargetInterface

TapePlannerInterface

Tape

Expand

\A

Targetdatabase

Hostdatabase

Archive

VST003.vsd

\B

Targetdatabase

Receive target snapshot into hostdatabase (on host):Automatic during Apply if target isconnected through Expand.

\C

Targetdatabase


Introduction to DSM/SCM Managing the SYSnn Subvolumes

Managing the SYSnn Subvolumes DSM/SCM creates a new operating system image, if needed during the Build request. For software updates that do not require system generation, you can use the current SYSnn. When system generation is required for an RVU or SPR, you must specify a new SYSnn. However, you should minimize the number of SYSnn subvolumes on each target. DSM/SCM requires only one SYSnn in order to operate. If you need to back out to a previous revision, you need the previous SYSnn if the previous revision was not on the current SYSnn.

File Types SupportedDSM/SCM supports both Guardian and OSS file types along with the format 2 files < 2GB.

Guardian File Types Supported

All Guardian files are always accessible to all logical targets.

OSS File Types Supported

DSM/SCM supports the management of these OSS file types:

Directories

Hard and symbolic links

Regular files (disk files)

FIFOs

You can configure DSM/SCM to manage OSS files. DSM/SCM requires that all OSS products contain an A7CINFO file. If you do not configure DSM/SCM to manage OSS files, you must use COPYOSS and PINSTALL. Use COPYOSS and PINSTALL only if some OSS products are not DSM/SCM-enabled. You must use COPYOSS for those files, but you can use DSM/SCM to manage everything else.

For DSM/SCM, a physical target system might have more than one OSS hierarchy, but only one OSS hierarchy can run and be accessible at a time. An OSS hierarchy must be running for DSM/SCM to manage the OSS files in it. For an OSS hierarchy to run, the $SYSTEM volume on which ZXOSSMON exists must be the system load volume that is currently running.

Caution. Do not use COPYOSS to install OSS files that DSM/SCM manages. Doing so replaces the DSM/SCM-managed files, which can make it difficult to determine whether OSS files are managed by DSM/SCM. This confusion can cause problems in managing OSS files with DSM/SCM.


Introduction to DSM/SCM Comparing DSM/SCM to COPYOSS/PINSTALL/PCleanup

Comparing DSM/SCM to COPYOSS/PINSTALL/PCleanup

PCleanup removes only old files that OSS products specify to remove. DSM/SCM removes all files that are not still in the configuration.

COPYOSS only installs software. DSM/SCM installs and manages the software in parallel with your Guardian products.

COPYOSS installs every file every time, overwriting existing files. DSM/SCM installs only files that need to be installed, reducing downtime.

Using DSM/SCM, you can back out your OSS files to the previous configuration.

DSM/SCM provides separate placement and activation processes to minimize application downtime.

COPYOSS is somewhat simpler to use, but DSM/SCM activation is faster.

DSM/SCM can install OSS files to remote systems.

When DSM/SCM places a new file, the security and ownership attributes are adopted from the pre-existing file, if any exist. If the file does not exist, the security attributes are designated by the pax archive file, and the ownership is the DSM/SCM user ID.


2 DSM/SCM Interfaces and Tools

This section contains descriptions of the DSM/SCM interfaces and tools and provides information on basic use, logging on and exiting, and using the menu functions (if any) available at startup. The online help in each interface provides detailed technical information for interface commands and functions.

Topics discussed in this section include:

Starting and Stopping DSM/SCM on page 2-2

Using the DSM/SCM Interfaces on page 2-4

Using Tools for DSM/SCM Procedures on page 2-15

Using Online Help on page 2-18


DSM/SCM Interfaces and Tools Starting and Stopping DSM/SCM

Starting and Stopping DSM/SCMYou start and stop DSM/SCM from an HP Tandem Advanced Command Language (TACL) prompt. The STARTSCM and STOPSCM files are startup and shutdown programs located in the ZDSMSCM subvolume. Normally, you start DSM/SCM only when you need to use it and shut it down when finished. However, you can include commands to run STARTSCM and STOPSCM in your system load and shutdown files.

STARTSCM

The STARTSCM startup program:

Starts all the processes that DSM/SCM requires except the TMF subsystem’s TMP process (the TMF management process pair that coordinates distributed transactions and the TMF configuration).

Checks for a running transaction management process (TMP). If none is running, a message is issued, and you must start TMP. If TMP was already in use on your system, you can use your existing TMP procedures.

STOPSCM

The STOPSCM program stops DSM/SCM:

Starting DSM/SCM

Before using any of the DSM/SCM interfaces or CNFGINFO:

1. Check that you are logged on using the super ID (255,255) or the DSM/SCM user ID.

2. Check that ZDSMSCM is the current subvolume.

> VOLUME $volume.ZDSMSCM

$volume

is the volume where the ZDSMSCM subvolume is located.

Note. You must be a member of a super-user group to start TMF.

Note. If you are using multiple logical targets on a system, always start DSM/SCM from the first ZDSMSCM subvolume installed on the target system, from which INITENV was run, to ensure that the correct installation files are used. You can also run STOPSCM from the same ZDSMSCM subvolume if DSM/SCM has finished processing all of its tasks.


DSM/SCM Interfaces and Tools Stopping DSM/SCM

3. If a TMF process is not running, start it:

> TMFCOM START TMF

4. Run STARTSCM:

> RUN STARTSCM

Stopping DSM/SCM

You must stop DSM/SCM before:

Running INITENV

Moving a DSM/SCM database

Running ZPHIRNM

To stop DSM/SCM:

1. If the Planner Interface is running, a connection error might appear after you stop DSM/SCM. To avoid this error, log off the Planner Interface before stopping DSM/SCM.

2. Check that you are logged on as the super ID (255,255) or the DSM/SCM user ID.

3. Check that ZDSMSCM is the current subvolume. At a TACL prompt, enter:


4. Run STOPSCM:

> RUN STOPSCM

Stopping All Applications

Before running ZPHIRNM or stopping the system, you must stop all applications, including DSM/SCM and TMF:

1. Stop DSM/SCM:

> VOLUME $volume.ZDSMSCM> RUN STOPSCM

2. Stop all other applications.

Note. For Steps 2 and 3, if you are unsure if TMF or DSM/SCM is running, enter the provided commands. If they are already running, they continue to run unaffected.

Note. If ZPHIRNM in PREVIEW mode displays a message that TMF must be running, do not stop TMF. In some cases, TMF must be running to rename certain files.

For some software revisions, you must leave certain applications running, such as TMF or Safeguard. If you are backing out to a previous RVU, consult the instructions for the RVU you are backing out to for any special instructions to leave certain applications running.


DSM/SCM Interfaces and Tools Using the DSM/SCM Interfaces

3. Stop the TMF process:

> TMFCOM STOP TMF

Using the DSM/SCM InterfacesDSM/SCM includes these interfaces:

Planner Interface on page 2-4

Maintenance Interfaces on page 2-6

Target Interface on page 2-11

Planner Interface

The Planner Interface is a PC-based graphical user interface to DSM/SCM that communicates with the host system. You can use it to receive software into the DSM/SCM archive and to build and package new software configurations for target systems. It contains Maintenance and Target Interface (ZPHITI) functions and can usually be used instead of them. You can perform most DSM/SCM activities using the Planner Interface, including:

Receive software into the archive

Create a software revision

Build and apply a configuration revision

Receive a target snapshot into the host database

Set up target systems, including creating profiles for each target

Produce detailed reports about defined configurations

Organize related software into groups for easier management

Maintain host system and volume

Maintain profile information for host and target systems

Monitor submitted requests that initiate DSM/SCM activities

Installing the Planner Interface

To install the Planner Interface, see Task 2: Install the Planner Interface on the PC on page 4-7.

Entering the Planner Interface

To use the Planner Interface:

1. Check that DSM/SCM is running on your host system. See Starting DSM/SCM on page 2-2.


DSM/SCM Interfaces and Tools Planner Interface

2. On your PC desktop, select Start>Programs>Dsm_scm>DSMSCM. DSM/SCM displays the Logon dialog box.

3. Enter your host user name and password. (DSM/SCM passwords are case-sensitive.)

4. Click OK. DSM/SCM displays the Planner Interface main window (Figure 2-1). You can begin the Planner Interface activities.

Navigating the Planner Interface

The Planner Interface main window consists of two windows:

Software in Archive window

This window lists all the software currently in the DSM/SCM archive. For information on viewing and grouping software inputs and products in the archive, see Managing Software Input Groups or Product Groups on page 7-11.

Configuration Revisions window

This window lists the current configuration for each target managed by this DSM/SCM host system. The online help describes each footnote and field in this window. For information on planner groups and sharing software revisions, see Sharing Software Revisions on page 8-25.

Figure 2-1. Planner Interface Main Window

VST111.vsd


DSM/SCM Interfaces and Tools Maintenance Interfaces

Below these windows is an area called the parking lot. After submitting a request, you can minimize its status window. The icon for the minimized status window appears in the parking lot. You can restore the status window to check the status of a request at any time during the session. For more information on managing requests, see Section 16, Managing Requests.

At the top of the window is the Planner Interface menu bar. Select commands from the menus to perform most tasks in the Planner Interface.

Exiting the Planner Interface

To exit the Planner Interface:

1. Select File>Exit.

For each open window containing unsaved changes, DSM/SCM displays a dialog box warning that unsaved changes will be discarded if you exit. For example, if you open a new software revision and change the product list but do not save the changes, those changes are lost.

2. In the warning dialog box, click one of these buttons:

3. If you have no further DSM/SCM activities to perform, stop DSM/SCM. See Stopping DSM/SCM on page 2-3.

Maintenance Interfaces

DSM/SCM has two Maintenance Interfaces to manage the archive and databases. Both interfaces are similar block-mode interfaces and do not require a PC. They can run on any NonStop character-based terminal or terminal emulator that supports block-mode display. By default, DSM/SCM and the internal HP NonStop Pathway/TS components it requires are set up such that the ZPHIHMI must run on the host system and the ZPHITMI must run on the target systems. However, you can change the PATHMON configuration to remove this restriction.

The Host Maintenance Interface (ZPHIHMI) manages the archive and the host database. You can perform these tasks only from the ZPHIHMI (and not from the ZPHITMI):

Maintain configuration manager profiles

Maintain planner security

Register a physical target system

Manage software input checkout

Manage the archive

Yes To discard any changes

No To save the changes

Cancel To cancel the exit



The Target Maintenance Interface (ZPHITMI) manages target system databases. Use the ZPHITMI to manage the target database for the logical target on the host system. You can perform operator security maintenance only from the ZPHITMI (and not from the ZPHIHMI).

From either Maintenance Interface, you can:

Add new target systems to DSM/SCM

Manage the DSM/SCM archive, databases, profiles, and target systems.

Bring new systems into the DSM/SCM environment:

View, modify, and list system profiles

Manage volumes for DSM/SCM use on a target system

Perform database administration to ensure the efficient operation of the DSM/SCM database:

Cancel exclusive access to certain DSM/SCM database items for users or requests that have checked out software inputs, configuration revisions, the configuration manager profile, or a system profile

Move a DSM/SCM database from one volume to another

Delete DSM/SCM requests

Entering the Maintenance Interface

To begin a Maintenance Interface session on either the host or a target system:

1. Check that DSM/SCM is already started. See Starting DSM/SCM on page 2-2.

2. Check that you are in the ZDSMSCM volume:

> VOLUME $vol.ZDSMSCM

where vol is the volume containing the DSM/SCM TSV.

3. At a TACL prompt, enter one of:

DSM/SCM displays the Maintenance Interface Logon screen. See Figure 2-2 on page 2-8.

Note. If you are using multiple logical targets on a system, always run DSM/SCM from the first ZDSMSCM subvolume installed on the target system, from which INITENV was run, to ensure that the correct installation files are used. You can also run STOPSCM from the same ZDSMSCM subvolume if DSM/SCM has finished processing all of its tasks.

ZPHIHMI To run the host system Maintenance Interface

ZPHITMI To run the target system Maintenance Interface



4. On the Logon screen, enter this initial User ID and Password, and press F1. (Maintenance Interface passwords are case-sensitive.)

DSM/SCM initializes the Maintenance Interface with all database administration functions set to the user ID you established with INITENV. Therefore, that ID must be the first ID to log on to the Maintenance Interface. Before they can perform Maintenance Interface functions, users must be added as database administrators on the system they will use.

DSM/SCM displays the Maintenance Interface main menu, which lists the Maintenance Interface tasks you can perform and is the screen from which you initiate all Maintenance Interface activities. To begin an activity, enter a number in the Selection number field and press F1.

The main menus differ for the ZPHIHMI and ZPHITMI. Figure 2-3 shows the target main menu. The host main menu is similar but contains different options for the functions available only in the ZPHIHMI.

Figure 2-2. Maintenance Interface Logon Screen

VST022.vsd



Navigating the Maintenance Interface

The Maintenance Interface screen consists of three main areas:

The upper area displays data fields in which you enter information. Use the tab key to move from field to field.

The middle area provides instructions for performing tasks from the screen.

The lower area shows the function keys that are active on the screen. Function keys provide navigation and common Maintenance Interface functions. Most key functions are consistent across all Maintenance Interface screens. However, not all function keys are active on every screen, and the function of certain keys differs depending on the screen.

The last line of every screen displays Maintenance Interface error and advisory messages. To navigate through the Maintenance Interfaces, use the function keys on your keyboard.

Figure 2-3. Maintenance Interface Target System Main Menu

VST023.vsd



To use the Maintenance Interface:

1. Start the Maintenance Interface. DSM/SCM displays the Logon screen.

2. Log on to the Maintenance Interface. DSM/SCM displays the main menu.

3. From the main menu, select a task, then press F1. DSM/SCM displays the requested screen.

4. Perform maintenance tasks using the data fields in the interface.

Exiting the Maintenance Interface

To end a Maintenance Interface session and leave DSM/SCM, press Shift-F16 from any Maintenance Interface screen. If you have no further DSM/SCM activities to perform, you can stop DSM/SCM. See Stopping DSM/SCM on page 2-3.

Figure 2-4. Maintenance Interface Screen Example

Data Entry

Instructions

Function

AdvisoryKeys

Messages

VST024.vsd


DSM/SCM Interfaces and Tools Target Interface

Target Interface

The Target Interface (ZPHITI) is a menu-driven, block-mode interface to DSM/SCM that runs on each target system. ZPHITI does not require a PC. It can run on any NonStop character-based terminal or terminal emulator that supports block-mode display. You can use ZPHITI on a target system to:

Review operator instructions sent with the activation package.

Apply software from an activation package to the target system.

Back out to a previously applied activation package.

Audit the target system to update the DSM/SCM database to reflect the files currently on the target system.

Verify the DSM/SCM database to correct the location of target subvolumes.

Request an independent snapshot of the current target system database information to send to the host system.

Create a system report listing the logical targets on the target system managed by DSM/SCM and all software managed by DSM/SCM on a particular target.

Enable or disable DSM/SCM trace on a target system.

Check EMS messages generated during a request. You can view messages associated with the request as well as DSM/SCM messages that are not related to a request. Use the PgUp and PgDn keys to scroll through the EMS messages.

Entering the ZPHITI

To begin a ZPHITI session:

1. Check that DSM/SCM is already started and that you are in the ZDSMSCM volume. See Starting DSM/SCM on page 2-2.

2. Run the ZPHITI:

> ZPHITI

DSM/SCM displays the ZPHITI logon screen (Figure 2-5).

3. In the User ID and Password fields, enter a valid operator user ID or alias and password, and press F1. (DSM/SCM passwords are case-sensitive.)



After a successful logon, DSM/SCM displays the ZPHITI Main Menu (Figure 2-6).

To begin all ZPHITI activities from the main menu:

1. Entering a number in the Selection number field.

2. Press F1.

To check EMS messages generated by a currently running request, press F4. If no request is being processed, DSM/SCM displays the EMS messages for the last completed request.

Figure 2-5. ZPHITI Logon Screen

VST055.vsd



Navigating the ZPHITI

The ZPHITI screen consists of four main areas:

The upper area displays data fields in which you enter information. Use the tab key to move from field to field.

The second area provides instructions for performing tasks from the screen.

The third area provides messages or menu list items.

The lower area shows the function keys that are active on the screen.

Function keys provide navigation and common ZPHITI functions. The last line displays ZPHITI error and advisory messages.

Use the function keys on your keyboard to navigate through the ZPHITI. The ZPHITI functions are designed to be consistent across all ZPHITI screens. However, not all function keys are active on every screen.

Figure 2-6. ZPHITI Main Menu

VST026.vsd



To use the ZPHITI:

1. Start the ZPHITI. DSM/SCM displays the Logon screen.

2. Log on to the ZPHITI. DSM/SCM displays the main menu.

3. From the main menu, select a task and then press F1. DSM/SCM displays the requested screen.

4. Perform your target tasks using the data fields in the interface.

Exiting the ZPHITI

To end a ZPHITI session and leave DSM/SCM, press Shift-F16 from any ZPHITI screen.

If you have no further DSM/SCM activities to perform, you can stop DSM/SCM. See Starting and Stopping DSM/SCM on page 2-2.

Figure 2-7. ZPHITI Screen Example

Data Entry

Instructions

Menu or

Advisory

Messages

Messages

List Items

FunctionKeys

VST027.vsd


DSM/SCM Interfaces and Tools Using Tools for DSM/SCM Procedures

Using Tools for DSM/SCM ProceduresIn addition to the DSM/SCM interfaces, you use these tools during certain DSM/SCM procedures.

ZPHIRNM Tool

Before you can use new software after you apply a new configuration to a target system, you must run ZPHIRNM to activate the software. When you apply software to a target system, DSM/SCM places Guardian files in their destination target subvolumes (TSVs) with temporary file names; that is, file names that are not the actual (distribution) product file names used on the target system. The temporary file names of the new files do not conflict with the file names of currently running programs that they might replace. ZPHIRNM renames the currently running files to fabricated names and renames the new files to their real names. ZPHIRNM is a command-line tool that runs outside the DSM/SCM Pathway environment. For detailed information on using ZPHIRNM, see Section 11, Renaming Product Files Using ZPHIRNM.

INITENV Tool

When you receive a new NonStop S-series system or Integrity NonStop system, HP has already initialized DSM/SCM and set up a default configuration. You can use INITENV to change some DSM/SCM configuration settings or to reinitialize DSM/SCM because of a corrupted database.

You must be super ID (255,255) to run INITENV. If you try to perform an INITENV task that you do not have permission to perform, INITENV stops, and you must restart INITENV using an appropriate user ID.

When you receive a new system, you run INITENV with the change option to change a few DSM/SCM configuration settings. See Task 1: Changing Default Settings Using INITENV on page 5-3.

To use INITENV to reinitialize DSM/SCM because of a corrupted database or other problems, see Reinitializing DSM/SCM on page 5-30.

Starting INITENV

1. Check that DSM/SCM is not running. See Stopping DSM/SCM on page 2-3.



vol is the volume containing the DSM/SCM TSV.



DSM/SCM Interfaces and Tools INITENV Tool

3. Run the INITENV tool:

> RUN INITENV

To use INITENV to change only the host name for a target system:

> RUN INITENV CHANGE-HOST new-host

new-host

is the name of the new host name for the target system.

Configuration Verification

As its last step, INITENV automatically runs STARTSCM (which is required by VERIFYI), then runs VERIFYI to verify the configuration update. VERIFYI

Checks the INITSTAT file to verify that all setup functions completed successfully

Confirms that all processes required by DSM/SCM are currently running

Reminds you to run the ZPHIHMI and ZPHITMI to initialize the DSM/SCM host and target databases

If VERIFYI detects INITENV errors, a message is displayed for any step not completed, and INITENV terminates. For more information on corrective action, see the message or the INITENV messages in the DSM/SCM Messages Manual.

Although you can run manually to VERIFYI any time after INITENV finishes, it is usually not necessary. INITENV always runs VERIFYI as it’s last step. To run VERIFYI manually:

1. Start DSM/SCM. For more information, refer to Starting and Stopping DSM/SCM on page 2-2.

2. Run VERIFYI. For example:

> RUN VERIFYI

Exiting INITENV

INITENV automatically stops itself after its processing is complete. INITENV does not perform any actions until you finish its dialog. Therefore, to leave your system unchanged, press Ctrl-Y to leave INITENV at any time during the INITENV dialog.

Navigating INITENV

INITENV is a command-line interface that prompts you with a series of configuration questions. The questions vary depending on your responses. Your responses supply INITENV with the information it needs to perform its configuration tasks. After you answer all questions, INITENV updates DSM/SCM accordingly. INITENV displays its progress as it searches for and purges files.


DSM/SCM Interfaces and Tools CLEANOSS Tool

CLEANOSS Tool

Use the CLEANOSS tool before your next Apply if INITENV informs you that it is required. If DSM/SCM tries to manage an OSS hierarchy containing old DSM/SCM work files, your next Apply fails. CLEANOSS removes these files.

SPRCHECK Tool

Use the SPRCHECK command line tool to confirm whether the recommended SPRs for your current configuration are installed on the system. SPRCHECK checks the DSM/SCM history file (syshnnnn) and compares it to a Support Note for your RVU. For detailed information, see Creating Software Revisions on page 8-15.

CLONE Utility

Use the CLONE utility to automatically handle processing tasks for all the systems in a Clone Group. For example, use CLONE to run ZPHIRNM to rename the product files on every target in the Clone Group at once. For detailed information, see Renaming Product Files for a Clone Group on page 19-6.


DSM/SCM Interfaces and Tools Using Online Help

Using Online HelpThe DSM/SCM online help systems supplement the information in this guide by providing detailed technical information about the use of each interface.

Help for the Graphical User Interfaces

DSM/SCM provides help for a window or dialog box, menu commands, buttons, and data fields. A list of help topics, index of keywords, and glossary are also available.

Searching for a Topic

To search for a topic using a keyword:

1. In any interface window, select Help>This window, or click Help in a dialog box. The DSM/SCM Help window appears.

2. Click Search.

3. Enter the keyword; then click Show Topics.

4. Select a topic in the list; then click Go To.

Viewing the Glossary

1. In any interface window, select Help>This window, or click Help in a dialog box. The DSM/SCM Help window appears.

2. Click Glossary.

Help for the Block-Mode Interfaces

A help screen is available for each interface screen in the block-mode interfaces. The help screen explains the actions of each function key, and provides the data formats and restrictions for each data field on the screen and for any messages that appear. To

For help on a: You must:

Window Select Help>This window.

Dialog box Click Help.

Menu topic Press the Alt key, and use the right and left arrow keys to position the cursor on the topic; then press F1.

Menu command

Use tab or arrow keys to position the cursor on the command; press F1.

Button Use the tab key to highlight the button; press F1.

Data field Click anywhere in the field; press F1.

Glossary term Click a term that is underlined with dashes.


DSM/SCM Interfaces and Tools Help for the Graphical User Interfaces

display help information for a screen, press F15 while the screen is active. To return to the interface from the help screen, press F16.


DSM/SCM Interfaces and Tools Help for the Graphical User Interfaces


3Hardware and Software Requirements

This section describes the hardware and software required to run DSM/SCM:

Required Hardware on page 3-2

Required Software on page 3-2

DSM/SCM Interaction Between Integrity NonStop and NonStop S-Series Systems on page 3-4


Hardware and Software Requirements Required Hardware

Required HardwareAll Integrity NonStop systems and NonStop S-series systems include all the memory and disk space required to run DSM/SCM. For DSM/SCM, you need a network connection to:

Connect to a host from the Planner Interface (located on the PC).

Manage a remote target over an Expand network. You can also use a tape to communicate between the host and the target. If there is no network configuration, the target database must reside on the target system.

Required SoftwareHP uses DSM/SCM to install customer-ordered software on NonStop S-series servers and Integrity NonStop servers:

The product DSVs have been copied from the SUT to the DSM/SCM archive ($AUDIT.ZPHI*).

The software configuration has been built, applied, and activated in the target subvolumes ($SYSTEM.Z*).

For all types of NonStop systems that support DSM/SCM, these software products are required.

DSM/SCM

All Integrity NonStop systems and NonStop S-series systems are shipped with DSM/SCM installed.

Server-Based Software

You must be running the DSM/SCM T6031G01^ABP or a later product version to manage an Integrity NonStop system from a NonStop S-series host system.

Client-Based Software

All Integrity NonStop and NonStop S-series systems come with the DSM/SCM client already installed. To install a newer version, download the DSM/SCM client from the site update tape (SUT).

Expand

To use an Expand network connection, Expand is required on both the target and host systems. If you have a host or target system that will use only tape for communication, Expand is optional and must be specifically licensed.


Hardware and Software Requirements SQL/MP

SQL/MP

DSM/SCM uses an SQL database to manage software. A version of HP NonStop SQL/MP is installed automatically with DSM/SCM. Standard SQL-related products include:

TMF

The DSM/SCM database must be audited by TMF, so TMF must be installed on your host system. A version of NonStop SQL/MP is installed automatically with DSM/SCM. Standard TMF-related products include:

Pathway

Many DSM/SCM functions are based on the Pathway environment and must be installed on all host and target systems. A version of NonStop SQL/MP is installed automatically with DSM/SCM.

Software Identification (SWID)

SWID provides unique identification of all NonStop system files distributed by HP. This unique identifier is known as the fingerprint of the file and is used to perform software inventory, version analysis, and delivery. Each product version of DSM/SCM requires a specific product version of SWID.

Product Number Product Name

T0246 SQL/MP COMPILER AGENT

T8669 TSQLAUD

T9095 TSQL COMPILER

T9191 TSQLCI

T9193 TSQLEXE

T9194 TSQCAT

T9195 TSQLUTIL

T9196 TSQFIL

T9197 TSQLMSG

T9198 TSQLCI2

Product Number Product Name

T8652 TMF TMFCOM

T8694 TMF TMFSERVE

T8695 TMF TMFDR

T8698 TMF TMFMON2


Hardware and Software Requirements TCP/IP

TCP/IP

The Planner Interface connects to its host system using TCP/IP. A version of TCP/IP is installed automatically with DSM/SCM.

DSM/SCM Interaction Between Integrity NonStop and NonStop S-Series Systems

A NonStop S-series host system can be used to manage Integrity NonStop target systems running, if the NonStop S-series system is running:

G06.27 or later RVUs

G06.21 through G06.26 RVUs if T6031G01 ABP is obtained from Scout and installed on the NonStop S-series system

An Integrity NonStop host system can be used to manage NonStop S-series target systems running:

G06.28 or later RVUs

G06.24 through G06.27 RVUs if these products are obtained from Scout and installed on the NonStop S-series system:

T5838G05 AAJ (NSKCOM)

T9023G08 AEH (SCUTIL)

T6017D45 ABD (NLD)

T8304D45 ABD (NMCGEN)

T9248D44 AAM (PTAL)



This part of the guide describes how to configure DSM/SCM to run on all your systems and how to determine who should perform the various tasks involved with DSM/SCM operations:

Section 4, Planning the DSM/SCM System Environment and User Security

Describes host and target systems, logical targets, and the DSM/SCM database, and provides guidelines for defining your systems

Describes the three types of DSM/SCM users and provides guidelines for assigning their responsibilities in your work environment

Section 5, Configuring DSM/SCM

Provides detailed procedures for configuring and initializing DSM/SCM on host or target systems


4Planning the DSM/SCM System Environment and User Security

Before you configure DSM/SCM, you need to plan:

Which systems should serve as DSM/SCM host systems or target systems

Whether to create multiple logical targets on a system

Where to locate the database for each system and the DSM/SCM archive

Which DSM/SCM users to designate as planners, operators, or database administrators


Task 1: Planning the DSM/SCM Environment on page 4-2

Task 2: Install the Planner Interface on the PC on page 4-7

Task 3: Planning DSM/SCM Users and Security on page 4-9


Planning the DSM/SCM System Environment and User Security

Task 1: Planning the DSM/SCM Environment

Task 1: Planning the DSM/SCM EnvironmentYou must configure a system managed by DSM/SCM as either a host system or a target system. Each host manages one or more logical targets. At lease one host system is required, and every system must have at least one logical target on it – including the host system. The location of databases can vary based on convenience, network connections, and available disk space.

To plan the configuration for a system in the DSM/SCM environment, you should determine:

Is it a host system or target system?

Do any of the systems have multiple logical targets?

What is the system name and number of each host system and target system?

Which targets are managed by each host system?

Are the hosts and targets network connected?

Are the systems NonStop S-series systems or Integrity NonStop systems?

Which systems will contain the archive and each database?

Single System

A single system must:

Be configured as a host system

Contain at least one logical target

Contain both the host and target databases on a TMF audited disk

Contain the DSM/SCM archive. To avoid performance degradation, do not place the archive and the databases on the same disk.

Multiple Systems

For network-connected systems, the basic configuration includes:

One host system with a logical target and host database on it

One logical target on every target system because they all serve as physical target systems

One target database located on each target system.

You can also configure multiple host systems, each of which would manage separate targets. For example, you can configure one host system for several development systems and another host system for production systems.



Multiple Logical Targets

Generally, the host system contains the host database and a target database, and each target system contains a target database. However, you can put the target databases on the host system if it is network connected, or put several target databases on one target. A remote target system is not network connected to the host system. In that case, the target database must reside on the target system, and it must be running SQL/MP.

In a multiple system environment.

A NonStop S-series host system running the DSM/SCM T6031G02 or a superceding RVU can manage any NonStop S-series systems running any earlier DSM/SCM product versions and Integrity NonStop systems.

An Integrity NonStop host system running the DSM/SCM H01 product version can manage only Integrity NonStop systems. It cannot manage a NonStop S-series system.

Multiple Logical Targets

You can configure multiple logical targets on each system. For example, to have separate development and production disks on a system, you would have two logical targets on that system. You might also have a separate logical target for two different RVUs.

Figure 4-1. How Host Systems, Target Systems, and Logical Targets Relate

Host

\SYSB \SYSC \SYSD

\SYSA

Target Target Target

Physical Target Systems

Host System

TARGA LogicalTarget

TARGB1TARGC TARGD

TARGB2LogicalTargets

Logical Targets

VST041.vsd



System Environment Examples

In this example:

\SYSA is a host system with one logical target, TARGA.

\SYSB is a physical target system with two logical targets: TARGB1, TARGB2.

\SYSC is a physical target system with one logical target, TARGC.

\SYSD is a physical target system with one logical target, TARGD.


In a typical DSM/SCM system environment in Figure 4-2, Typical DSM/SCM Environment, on page 4-5, DSM/SCM manages three target systems, each containing one logical target, from a central host system. The DSM/SCM archive must always be on the host system. In this example:

The planner accesses DSM/SCM on the host system \A through a PC running the Planner Interface and connected to the host using Winsock.

The DSM/SCM archive stores software that has been input to DSM/SCM.

There are four databases: one for the host and one for each target. There is a target database on the host system for its logical target, separate from the host database.

Target 1 is defined as the logical target on the host system. The host database and the target database for Target 1 (system \A) are on the host system.

Target 2 is defined on system \B. System \B is connected to the host using Expand. The database for Target 2 is on the Target 2 system (system \B).

Target 3 is defined on system \C. System \C is a stand-alone system, not network connected. Information between the host and Target 3 is passed on magnetic tape. The database for Target 3 is on the Target 3 system (system \C).




Figure 4-3 shows the locations of databases for a host and three target systems. There are four logical targets: one on each system, including the host. In this example:

Each database is on its default volume ($DSMSCM).

The host database and the database for the logical target on the host system (\SYSA) are maintained on the host system.

The database for Target 2 is on the Target 2 system (system \TARGB).

The database for Target 4 is on the Target 4 system (system \TARGD), as required for all target systems that are not network connected to the host system.

Figure 4-2. Typical DSM/SCM Environment

Host

\A system

Target 1

tape

DSM/SCMArchive

HostDatabase

\A TargetDatabase

\B system

Target 2

\C system

Target 3\C TargetDatabase

Stand-alone targetsystem uses tape to

communicate with host

Block-modeinterface

Block-modeinterface

\B TargetDatabase

Winsockor RSC

connection

UserInterface

UserInterface

UserInterface

VST042.vsd




Figure 4-3. Host and Target Databases

Tape

\SYSAHost

Target 1

\TARGC

Target 3

\TARGB

Target 2

\TARGD

Target 4

$DSMSCM

\TARGDDatabase

$DSMSCM

\TARGBDatabase

$DSMSCM

\TARGCDatabase

$DSMSCM

HostDatabase

\SYSADatabase

Expand

VST008.vsd



Task 2: Install the Planner Interface on the PC

Task 2: Install the Planner Interface on the PCThe Planner Interface installed is installed on system consoles shipped with new NonStop S-series servers and Integrity NonStop servers. To install the Planner Interface on another PC or to install a newer product version, copy the Planner Interface from the SUT to the PC. The Planner Interface runs on Windows 3.11, Windows 95, Windows NT, Windows 2000, Windows XP, Windows Vista or Windows - 7 (32 Bit). The PC workstation must have at least 6 megabytes of free disk space to load the Planner Interface. The Planner Interface runs on the workstation and must communicate with the host system using TCP/IP.

If the Planner Interface is already installed and configured on the PC, proceed to Task 3: Planning DSM/SCM Users and Security on page 4-9.

Table 4-1. Installing Planner Interface Checklist

___ Ensure that the TCPIP file and its LISTNER program are installed in the current host system SYSnn subvolume. To learn what SYSnn is running, on the host system: > sysinfo

SYS00

___ On the host system:> Volume $DSMSCM.ZDSMSCM

___ Copy the ZDSMEXE file (transfer as a binary file) from the host to a subdirectory called DSMSCM on the PC.

___ Rename DSMSCM to ZDSM.EXE.

___ Double-click the ZDSM.EXE file to decompress the DSM/SCM files you just transferred.

___ Ensure Winsock is installed on the PC and WINSOCK.DLL is in the \WIN, \WINDOWS, or other directory.

C:\WINNT\SYSTEM32

___ Double-click the SETUP.EXE file in the DSMSCM directory.

___ Enter the Object Manager server class name. OM-001

___ Enter the Software Product Group type (Shared or Private). To share software input or product groups across multiple clients, enter Shared.

Private

___ Enter the CNFGINFO process name. $ZPHC

___ Indicate to use a Winsock or RSC interface. Winsock

___ Enter the full path name of the WINSOCK.DLL file. C:\WINNT\SYSTEM32

___ Enter the NonStop host system IP address. If you do not know the IP address, contact your system manager.

___ Enter the IP port number. 1089

___ Enter the NonStop host system name. \hostname

___ When setup is complete, do not run DSM/SCM. No



Task 2.1: Ensure TCPIP and LISTNER Are Installed and Running

Task 2.1: Ensure TCPIP and LISTNER Are Installed and Running

Check that the TCPIP file and its LISTNER program are installed in the current host system SYSnn subvolume. To learn what SYSnn is running, on the host system:

> sysinfo

Task 2.2: Transfer DSM/SCM PC Files From the SUT to the PC

Load the Planner Interface from the subvolume on the host system where DSM/SCM will be placed:

1. On the host system, make ZDSMSCM the current subvolume:


2. Using IXF or a similar method, perform a binary copy of the ZDSMEXE file from the ZDSMSCM subvolume on the host to a subdirectory called \DSMSCM on the PC. The subdirectory can be on any drive with sufficient space.

3. On your PC, rename the PC file to ZDSM.EXE.

4. Double-click the ZDSM.EXE file to decompress the DSM/SCM files you just transferred to your PC.

Task 2.3: Ensure Winsock Is Installed

Ensure Winsock is installed on the PC and that WINSOCK.DLL is in the \WIN, \WINDOWS, or another directory.

Task 2.4: Run SETUP.EXE

To initialize the Planner Interface on the PC:

1. Double-click the SETUP.EXE file in the DSMSCM directory. DSM/SCM displays the Setup Logon screen followed by licensing information, and then opens a series of dialog boxes.

2. Enter the Object Manager server class name (optional); then click OK. The Object Manager, a host static server class, is the interface server to DSM/SCM for the Planner Interface and for the remote target system.

3. Enter the Software Product Group type (Shared or Private); then click OK.

Shared lets you share software input and product groups across multiple clients. Sharing groups permits other planners use the software groups you create. To share groups, you must indicate it now.

Private ensures that only the planner who creates a group can use it.

Note. After you run ZDSM.EXE, you can delete it to save space. All other files are required for proper DSM/SCM operation.



Task 3: Planning DSM/SCM Users and Security

For more information on software inputs and product groups, see Managing Software Input Groups or Product Groups on page 7-11.

4. Enter the CNFGINFO process name (optional); then click OK. SETUP asks if you will use RSC or Winsock.

5. Select Winsock:

a. Click the Winsock button; then click OK. SETUP asks for the full path name of the WINSOCK.DLL file.

b. Enter the name or IP address of the host system you will enter in INITENV; then click OK.

c. Enter the IP port number that you will enter in INITENV for the DSM/SCM Winsock service.

d. Click OK.

6. Enter the host system name; then click OK. SETUP updates your DSMSCM.INI file with the information you entered. A dialog box appears indicating that SETUP is finished and asking if you want to start the Planner Interface. If you are performing a full configuration of DSM/SCM, indicate No. You can launch the Planner Interface later when you need it.

7. After SETUP finishes, a program group called DSM/SCM appears, containing:

The DSMSCM icon, which launches the Planner Interface

The CNFGINFO icon, which launches the Configuration Information tool

The DSM/SCM and CNFGINFO softdoc files in text format

To access these items, select Start>Program>DSM/SCM on your PC desktop.

Task 3: Planning DSM/SCM Users and SecuritySetting security for different DSM/SCM users (planners, database administrators, and operators) determines what tasks they have permission to perform:

Planners have permission to plan, build, and apply software configurations. For more information, see Planner Tasks on page 4-14.

Operators have permission to initiate tasks on an assigned target system, usually as directed by a planner. For more information, see Operator Tasks on page 4-16

Database administrators have permission to:

Maintain the DSM/SCM database

Manage security of the DSM/SCM installation files and files on target systems

Establish user access permissions for target systems

Often installs or updates the configuration of DSM/SCM on all systems



Guidelines for Assigning DSM/SCM Security Settings

For more information, see Database Administrator Tasks on page 4-13.

Training Site Personnel

If DSM/SCM users at your site have not previously used the HP NonStop SQL/MP or HP NonStop Transaction Management Facility (TMF) products, they will need training in those areas. For information about courses that HP offers, contact your HP representative.


The number of people assuming the roles of planner, operator, and database administrator depends on the particular site. At least one planner is required. At a smaller site, you can configure a single user ID as the planner, database administrator, and operator. For a larger site, especially one with several remote target systems, you might need one planner, one database administrator, and a separate operator for each target system. Consider assigning a backup to fill these roles if the regular personnel are unavailable.

Table 4-2 on page 4-10 summarizes the guidelines for assigning these roles as best suits your work environment.

Table 4-2. Suggested Assignments for Different Work Environments

Work environment Role assignments

Single system 1 planner/operator/database administrator

Multiple network-connected development and production systems with a single host system

1 planner

1 database administrator

1 operator for development systems, 1 operator for production systems

Multiple network-connected development and production systems with multiple host systems

Same as for a multiple system site with a single host, or:

1 planner for each host system

1 database administrator for each host system

1 operator for development systems under each host system

1 operator for production systems under each host system

Multiple systems that are not network connected with a single host system

1 planner

1 database administrator

1 operator for each site with systems that are not network connectedor1 operator for each system that is not network connected

* The suggestions in this table do not include backups for each role, which you should assign as needed.




Small Work Environments

In small work environments—those where DSM/SCM manages only one or two systems—one person can perform the tasks of the planner, database administrator, and operator. If the planner has time constraints, or if preferable, a separate person can assume the duties of the operator.

Large Work Environments

In large work environments—those where DSM/SCM manages more than two systems —several people might need to assume the different DSM/SCM roles. The nature of these assignments can vary depending on the situation. Generally each host system should have one planner and one database administrator. The number of operators can depend on several factors, including available personnel, time constraints, and whether systems are remote or local.

Large Sites With Networked Systems

In a work environment where DSM/SCM manages multiple systems in the same location, you ideally assign DSM/SCM roles to separate people. Performing upgrades can be time-consuming for one person to maintain too many systems at once. You might not need DSM/SCM for weeks at a time, depending on your upgrade schedule.

Planners

You should need only one planner to plan and oversee the configuration of all systems under a host system. This eliminates any potential confusion of having multiple planners carrying out tasks on the same systems. However, you can configure multiple planners if multiple host systems exist in a single work environment. Each planner can independently maintain different DSM/SCM systems.

Database administrators

The database administrator should be a separate individual from the planner. The planner can still oversee the maintenance of security, databases, and the archive that the database administrator carries out, but without expending time on the actual duties. You probably need only one database administrator to cover all systems in a large networked site. However, you can configure multiple database administrators if the site has multiple host systems.

Operators

The number of operators depends on the personnel you have available. With a large number of systems, you probably need several operators to carry out updates in a timely manner. If you have separate systems for development and production, it is advantageous to have separate operators for each. If you have a large number of development systems and a large number of production systems, you can configure several operators for each. For example, if you have six




production systems and six development systems, you can configure two production operators and two development operators.

Large Sites With Remote Systems

As at large sites with network-connected systems, having one planner helps maintain an overall picture of the configuration planning for the entire work environment, and having one database administrator is efficient.

You can configure a separate operator for each remote system or have an operator travel to each remote site as needed. If you have multiple remote systems at a remote site, you could have either one operator for each system or one for all systems at that site.

For a mixture of remote and local systems in one work environment, you can combine the suggested assignments as fits your situation. For example, if you have separate development and production systems, some local and some remote, each under one host system, your assignments might look like Figure 4-4.

Figure 4-4. DSM/SCM Role Assignment Example

Production Systems

Tape

\SYSAHost

Target 1

\TARGC

Target 3

\TARGB

Target 2

\TARGD

Target 4

1 planner

1 operator

1 database admin.

1 operator

1 database admin

Tape

\SYSAHost

Target 1

\TARGC

Target 3

\TARGB

Target 2

\TARGD

Target 4

1 planner

1 operator

1 database admin.

1 operator

1 database admin

Development Systems

VST108.vsd



Database Administrator Tasks

In this example:

The assigned roles for the development systems and production systems are distributed identically although they can be different people for each set of systems.

One planner is assigned to each host system, \SYSA.

One operator is assigned to all local targets, including the logical targets on \TARGB, \TARGC, and the logical target on \SYSA.

One database administrator is assigned to all the local systems: \TARGB, \TARGC, and \SYSA.

One operator and one database administrator are assigned to the remote target system, \TARGD.

The operators and database administrators could be separate people, or one person could hold both responsibilities, as your personnel availability allows.

Database Administrator Tasks

The database administrator uses the ZPHIHMI, ZPHITMI and the Planner Interface to maintain the DSM/SCM databases and other management tasks. Maintaining the DSM/SCM databases requires an understanding of DSM/SCM concepts and SQL database administration concepts and procedures. The database administrator often initially installs DSM/SCM on systems and updates its configuration. Database administrator tasks include:

Adding, moving, renaming, or deleting archive volumes

Backing up and restoring archive subvolumes on tape

Viewing, modifying, and listing system profiles

Managing volumes for DSM/SCM use on a target system

Managing the check-out of database items

Adding users to DSM/SCM and establishing what tasks they can perform

Resolving problems with the DSM/SCM database

These tasks include database maintenance tasks using the Maintenance Interfaces. DSM/SCM is usually configured by the initial database administrator. By default, each database administrator has full permission to access the ZPHIHMI. You can apply restrictions by setting the appropriate flags on the Database Administrator Security screen. You can give permission to a database administrator to perform these functions:



Planner Tasks

Planner Tasks

The planner has primary responsibility for installing software, but might also oversee the DSM/SCM responsibilities assigned to others. The planner must thoroughly know and understand installation procedures and DSM/SCM operations. Most planner-specific tasks are performed using the Planner Interface. The planner also has permission to use all DSM/SCM interfaces. You can establish planners without any permissions, giving them read-only access to a subset of DSM/SCM functions. These planners can view items such as configurations and inputs but cannot make changes.

In a typical software update, the planner:

Determines the needed product version update (PVU) for all software on a given target. For example, the planner decides whether the Safeguard T9750 product on a target should be upgraded to support new functions.

Activity Definition

Maintenance for Systems Perform system profile maintenance.

Maintenance for Volumes Specify how DSM/SCM is to use volumes on the system.

Maintenance for CM Profile

Make changes to configuration manager profiles.

Check-out Cancellation of:

Systems

Configs

CM Profile

Inputs

Cancel database check-outs related to:

Systems (target systems managed by DSM/SCM)

Configuration revisions

Configuration Manager profile

Software inputs

Security Maintenance for:

Planners

Operators

DB Admins

Set security for:

Planners on the host system

The operator on a target system

Other DSM/SCM database administrators on either the host or the target system

Archive Maintenance Delete a configuration or a software input from the DSM/SCM database and archive; back up and restore an archived software input.

Request Deletion Delete requests that are stopped in a nonrestartable state and cannot be canceled.

Register System Register a target system on the host system.

Archive Relocation Move archive subvolumes from one volume to another.

Database Relocation Move the host database from one volume to another.

Enable Trace Trace the execution of the Maintenance Interface on the system.



Planner Tasks

Determines the dependency relationships in planned changes. For example, the planner would determine that the product T9545AAA requires including the products T6556AAI and T9544G01 in the new software revision.

Builds a configuration revision containing new software for a target system.

Resolves discrepancies between target and host file information.

Initiates and monitors the applying of configuration revisions on target systems if the host and target systems are connected using Expand.

Investigates and resolves DSM/SCM processing errors.

Receives a snapshot from a target system onto the host system if the host and target systems are not network connected.

Other planner tasks can include:

Initiating a backout on a target system to the previously applied software revision

Initiating an audit function to start the Inventory Collector, thus updating the target database with the fingerprints of files in a specified target subvolume list

Using CNFGINFO to prepare customer or third-party software for use in the DSM/SCM environment

Performing any other tasks the planner assumes that are usually associated with the operator or database administrator

You can give permission to a planner to perform these functions:

Activity Definition

Build Build an activation package.

Build/Apply Build and apply an activation package. (The planner must have Build permission in order to have Build/Apply permission.)

Maintain Reports Add or change SQL reports.

Enable/Disable Tool Assign

Enable assigns for tools used by DSM/SCM and a system generation program. Perform Tool Assign only at the direction of HP support personnel to help troubleshoot certain situations. It is not required in normal procedures.

Prepare Reports Prepare SQL reports.

Enable Trace Enable a DSM/SCM trace.

Prepare Release Documents

Prepare the release documents that are on the SUT.

Create New Software Revision

Create a new software revision for a target system.

Prepare Softdocs Prepare softdocs.

Maintain Targets Maintain logical target profiles.

Receive Snapshot Receive a snapshot.



Operator Tasks

Operator Tasks

An operator can perform tasks only on the assigned target systems. An operator primarily uses the ZPHITI and might use ZPHIRNM in certain situations. An operator for a remote system might have more tasks to perform than an operator for a network-connected system. Acting on instructions received from the planner, the operator initiates tasks on the target system. Therefore, the operator needs only a minimal understanding of and experience with software installation procedures and DSM/SCM operation.

Operator tasks include:

Initiating the application of the activation package received from the host on tape if the host and target systems are not connected using Expand

Activating the software in the activation package (including running OSM or SCF) and, if necessary, running ZPHIRNM and performing a system load

Mounting tapes when instructed by EMS messages, TAPECOM, or the ZPHITI status screen

Monitoring the status of target system tasks

Requesting an independent snapshot of the target system, to send target system information to the host database if the host and target systems are not connected using Expand

You can give permission to an operator to perform these functions:

Export Files Export files.

Receive Software Receive software inputs.

Maintain Groups Create and maintain groups.

Activity Definition

Apply an Activation Package

Apply an activation package.

Backout a Configuration Back out a configuration. (The default is to deny permission.)

Request a Snapshot Request a snapshot of the system.

Request an Audit Request an audit of the system. (The default is to deny permission.)

Request a System Report Request a system report.

Verify the Database Request a verification of the DSM/SCM database.

Enable Trace Enable a DSM/SCM trace.

Activity Definition


5 Configuring DSM/SCM

This section describes the initial configuration and initialization of DSM/SCM host and target systems or a subsequent adjustment. DSM/SCM is configured with default values when you receive a new NonStop S-series system or Integrity NonStop system.

The first time you use the Planner Interface on a NonStop S-series system or Integrity NonStop system, software is already received into the archive and one target system, DEFAULT, already exists in the Configuration Revisions window.

During DSM/SCM configuration, use the corrective actions described in the DSM/SCM Messages Manual to recover from any warning or error messages that might occur.


Configuring a Host or Target System on page 5-2

Setting DSM/SCM Security on page 5-8

Managing the DSM/SCM Configuration on page 5-15


Configuring DSM/SCM Configuring a Host or Target System

Configuring a Host or Target SystemHP sets up a DEFAULT configuration on NonStop S-series systems and Integrity NonStop systems. Use this procedure to check the default settings. As needed, update the DSM/SCM profiles, user security, and device defaults. Make any changes to the configuration on the DSM/SCM host system and the physical and logical targets on the host system before using DSM/SCM to manage software.

After you make any needed changes to the configuration on the host system including its logical target, you can:

Add additional logical targets to the host system. See Adding a Logical Target.

Configure target systems

Configure a Backup Host system. See Creating an Alternate System Disk on page 5-22.

Modify DSM/SCM default parameters. See Changing DSM/SCM Default Parameters on page 5-15.

After DSM/SCM is configured on a host or target system, you can use DSM/SCM to manage the software configurations on that system. See Section 6, Managing Software With DSM/SCM.

Preparing to Configure DSM/SCM

Understanding DSM/SCM Operation and Capabilities

If you are unfamiliar with DSM/SCM, read Section 1, Introduction to DSM/SCM.

Confirm Required Software and Hardware

DSM/SCM has basic software and hardware requirements to install and manage software on your host and target systems. For more information, see Hardware and Software Requirements on page 3-1.

Changing the System Name and Number

When you receive a new NonStop S-series system or Integrity NonStop system, change the system name and number to be unique before you use DSM/SCM. Changing the system name or number after you use DSM/SCM takes substantially longer to update because the databases grows during use.

After you rename a host system, you must initialize any targets that host manages to update them for the new host name before performing any DSM/SCM tasks.


Configuring DSM/SCM Task 1: Changing Default Settings Using INITENV

For information on how to change the system name and number:

Checking the Site ID

HP assigns the site ID.

To identify the site ID for this system:

> fup copy $volume.SYSnn.rlseid

volume

is the name of the volume

SYSnn

is the SYSnn subvolume.

For example:

> fup copy $system.sys00.rlseid Q08 020097 D48.00

The site ID in this example is 020097.

Task 1: Changing Default Settings Using INITENV Use this procedure for both host systems and target systems. You can use the change option to:

Inform DSM/SCM of a change to the system name or number. For more information, refer to Changing the System Name and Number on page 5-2. Then use INITENV change option to configure DSM/SCM to recognize the new name and number. After you rename a host system, you must reinitialize all the targets it manages to update them for the new host name before performing any DSM/SCM tasks on them.

Change a host system to a target system.

Change the host system for a target system.

Change the DSM/SCM user ID.

System Manual

Integrity NonStop system SCF Reference Manual for the Kernel Subsystem

NonStop NS-Series Hardware Installation Guide

NonStop S-series system SCF Reference Manual for the Kernel Subsystem

NonStop S-Series Hardware Installation and FastPath Guide


Configuring DSM/SCM Task 1: Changing Default Settings Using INITENV

Change the DSM/SCM hometerm.

Change the DSM/SCM server priority.

To change the default settings:

1. Make sure that you have a unique system name and number. See Changing the System Name and Number on page 5-2.

2. Log on to your system as the super ID (255,255) or as the DSM/SCM user ID.

> logon 255.255

password:

3. Make ZDSMSCM the current subvolume:


4. Check that TMF is running:

> TMFCOM START TMF

5. Check that DSM/SCM is not running:

> RUN STOPSCM

For more information, refer to Starting and Stopping DSM/SCM on page 2-2.

6. Run INITENV and select the change option:

> RUN INITENV

Use Table 5-1 as a quick guide to configure a host or physical target system. The right column provides common entries. For this procedure, make sure that you select C when INITENV asks if you are initializing or changing the system.

Table 5-1. Changing Default Settings Checklist (page 1 of 2)

Question Enter

___ Would you like to read the introduction? Y or N

___ Is this the name and number you want for this system?

If the displayed system name and number are correct, no change is necessary.

If the displayed system name and number are not correct, break out of INITENV (CTRL-Y), and see Changing the System Name and Number on page 5-2.

Y or N

___ Are you changing or initializing the system? C

___ Host or physical target system? Host or Target

___ Want to change host system for this target system?

This is displayed only if the system is a target system.

Y or N


Configuring DSM/SCM Task 2: Configure the Host Database

INITENV automatically runs STARTSCM and VERIFYI as its last step to verify the DSM/SCM system environment configuration. DSM/SCM must be running for the verification procedure.

Task 2: Configure the Host Database

The Planner Interface and ZPHIHMI are used to perform routine maintenance on the host database. Only host systems contain a host database:

For a target system, proceed to Task 3: Configure the Target Database on page 5-7.

For a host system, check the defaults for the host or target system information in the host database. As needed, update the configuration for aspects of DSM/SCM operations such as user security, file transfer, and scheduling options.

1. Set the DSM/SCM user ID. See Setting the DSM/SCM User ID on page 5-8.

2. Add a planner ID or change the tasks a planner can perform on this system. See Setting Security for Planners on page 5-8.

3. Use the ZPHIHMI to configure the system profile for this system. See Updating the System Profile Information (ZPHIHMI or ZPHITMI) on page 17-4.

___ What is the host system name for this target system?

This is displayed only if the system is a target system.

\host-name

___ DSM/SCM user ID. The default DSM/SCM user ID is the super ID (255,255).

dsmscm-user-id

___ Hometerm for use by DSM/SCM Pathway servers and other processes. The default is $ZHOME, a virtual terminal that always runs in the paused state. This prevents DSM/SCM from stopping even if the system console is not in the paused state. If you do not use $ZHOME, you must use a terminal that can be paused while DSM/SCM is running.

$ZHOME

___ The DSM/SCM servers can consume a lot of CPU time to perform few tasks. Set the priority on which the DSM/SCM Pathway servers and other processes must run. The priority must be below the priority of your production applications such that the DSM/SCM servers do not slow down your production applications. The default priority of DSM/SCM servers is 50.

priority

Note. DSM/SCM initialization activities like INITENV, STARTSCM, STOPSCM, and IPM6031 are more non super ID tolerable.

Table 5-1. Changing Default Settings Checklist (page 2 of 2)


Configuring DSM/SCM Task 2: Configure the Host Database

4. Designate the archive volume and scratch volumes for this system. See Updating the Volume Usage on page 17-11.

5. Set security for database administrators for this host system. See Setting Security for Database Administrators on page 5-11.

6. Update the Configuration Manager Profile. See Configuration Manager Profile on page 17-2.

All target information that you update in the host database must also be updated in the target database. See Task 3: Configure the Target Database on page 5-7.


Configuring DSM/SCM Task 3: Configure the Target Database

Task 3: Configure the Target Database

Both host systems and target systems contain a target database. Use ZPHITMI to check the defaults for the DSM/SCM target database information and update it as necessary:

1. Configure the target system profile. For more information, see Updating theTarget Profile (Planner Interface) on page 17-6.

2. Designate scratch volumes for this target system. For more information, see Updating Target Volume Usage (ZPHITMI and ZPHIHMI) on page 17-12.

3. Set security for operators and database administrators of this target system. See Setting Security for Target Database Administrators (ZPHITMI) on page 5-12 and Setting Security for Operators on page 5-13.

Task 4: Initialize the Logical Target

See Initializing a Logical Target on page 5-18.


Configuring DSM/SCM Setting DSM/SCM Security

Setting DSM/SCM Security The security settings for planners, database administrators, and operators specify what tasks they can perform. The database administrator usually sets and maintains security for all users in the DSM/SCM environment, including:

Check the current security information for a DSM/SCM user

Adding users to DSM/SCM and setting their security access

Changing security information for a user

Listing all DSM/SCM users

Deleting a user from DSM/SCM

Remapping an Alias to a Different Guardian User ID

Before you reconfigure an alias through SAFECOM, use the Maintenance Interface or Planner Interface to check if the alias exists as a Planner, Database Administrator, or Operator.

If the alias exists, delete the alias through the Maintenance Interface or Planner Interface. Then you can reconfigure the alias.

If the alias does not exist, you can remap the alias to a different user or deleted through SAFECOM.

Setting the DSM/SCM User ID

The default DSM/SCM user ID is the super ID (255,255). The DSM/SCM user ID is the initial database administrator, responsible for specifying which users are allowed to use DSM/SCM and what tasks they are permitted to perform.

The DSM/SCM user ID must have remote passwords to target systems to which it is Expand connected.

To perform a First Real Apply Build, Initial Build Apply Bypass (FRABIBAB), the DSM/SCM user ID must be the super ID (255,255). Otherwise, you might not be able to start DSM/SCM after the system load.

To change the default DSM/SCM user ID, use INITENV with the change option.

Setting Security for Planners

For information about the tasks planners can perform, see Planner Tasks on page 4-14. Security information for planners is stored in the host database. Users configured as planners can have control characters in their passwords as long as those control characters reside in a standard set available from many 6530 emulators.


Configuring DSM/SCM Setting Security for Planners

After you run INITENV with the initialization option on a host system, you must use the ZPHIHMI. See Setting Planner Security (ZPHIHMI) on page 5-9. Otherwise, you can use either the Planner Interface or ZPHIHMI to set security for planners.

Setting Planner Security (Planner Interface)

1. Log on to the Planner Interface (see Entering the Planner Interface on page 2-4) using the DSM/SCM user ID.

The Planner Interface Window (Figure 2-1 on page 2-5) displays the Software in Archive and Configuration Revisions windows. The Software in Archive window lists the software currently in the DSM/SCM archive.

2. Select Maintain>Security Maintenance>Planner list. DSM/SCM displays the Planner Security Profile window.

3. In the Planner List dialog box, do one of:

To add a planner:

a. Click the Add button.

b. Add user IDs or aliases.

To change planner security information:

a. In the Planner List dialog box, select the name of a planner in the list.

b. Click Modify.

To remove a planner:

a. In the Planner List dialog box, click the name of a planner in the list.

b. Click Delete. Skip ahead to Step 4.

4. Click OK; then click OK in the Planner List dialog box.

Setting Planner Security (ZPHIHMI)

1. From the host system, check that ZDSMSCM is the current subvolume; then run the ZPHIHMI:

> VOLUME $volume.ZDSMSCM> RUN ZPHIHMI

2. Log on to the ZPHIHMI using the DSM/SCM user ID. DSM/SCM displays the Maintenance Interface main menu.

Note. All tasks are initially set to allow access (each check box has an X) for planners. To deny access to a task, click its check box to remove the X.


Configuring DSM/SCM Setting Security for Planners

:

3. Select 3 (Security Maintenance); then press F1. DSM/SCM displays the Security Maintenance menu.

4. Select 1 (Planner Security Maintenance); then press F1. DSM/SCM displays the Planner Security Maintenance screen:

5. Press Shift-F4. DSM/SCM displays a list of all the planners for this host system.

VST061.vsd

VST064.vsd


Configuring DSM/SCM Setting Security for Database Administrators

To page through the list, use the PgUp and PgDn keys. Press F16 to return to the Planner Security Maintenance screen.

6. To check the security information for a planner, enter the planner’s user ID; then press F2. To check information about the next planner in the list, press F3.

7. Add or change security permissions for a planner:

a. Enter the planner’s user ID or alias; then press F2 to check information about the planner.

b. Make the changes by entering a Y in a data field to grant the permission or entering an N in a data field to deny the permission.

c. After you set all permissions, press Shift-F2 if you are updating an existing planner or F7 if you are adding a planner.

d. If more than one page of planners exists, be sure to make any changes before pressing F3 to check additional planners.

8. After you add all planners, press F16 twice to return to the main menu.

Setting Security for Database Administrators

By default, the user ID for the host database administrator and target database administrator is the super ID (255,255). You must have at least one backup database administrator. In general, database administrators have the most knowledge of DSM/SCM and supporting products. For guidelines to help in planning security for database administrators, see Database Administrator Tasks on page 4-13.

To establish security for a database administrator:

Use the Planner Interface or the ZPHIHMI for a host database

Use the Planner Interface or the ZPHITMI for a target database

Setting Security for Host Database Administrators (Planner Interface)

From the Planner Interface:

1. In the Configuration Revisions window, select the system you are configuring.

2. Select Maintain>Security Maintenance>DB Administrator list. The Planner Interface displays the DB Administrator List window.

3. In the DB Administrator List dialog box, do one of:

To add a database administrator:

a. Click Add.

b. Add user IDs or aliases.


Configuring DSM/SCM Setting Security for Database Administrators

c. In the DB Administrator Security Profile dialog box, select the tasks the administrator is permitted to perform.

d. Click OK to exit.

To check a database administrator’s profile:

a. In the DB Administrator List dialog box, double-click a database user ID or alias from the list.

b. After you finish checking the database administrator list, close the window.

To modify a database administrator’s profile:

a. In the DB Administrator List dialog box, double-click a database user ID or alias from the list.

b. Click Modify.

c. In the DB Administrator Security Profile dialog box, select the tasks the administrator is permitted to perform.

d. Click OK to exit.

To delete a database administrator:

a. In the DB Administrator List dialog box, select the name of a database administrator in the list.

b. Click the Delete button.

c. In the DB Administrator List dialog box, click OK.

4. Click OK on the DB Administrator List dialog box.

Setting Security for Target Database Administrators (ZPHITMI)

1. From the ZPHITMI, select 3 (Security Maintenance); then press F1. DSM/SCM displays the Security Maintenance menu.

2. From the Security Maintenance menu, select 2 (Database Administrator Security Maintenance); then press F1. DSM/SCM displays the Database Administrator Security Maintenance screen.

3. From the Database Administrator Security Maintenance screen, press Shift-F4. DSM/SCM displays a list of all DSM/SCM target database administrators. To page through the list, use the PgUp and PgDn keys. To return to the Database Administrator Security Maintenance screen, press F16.

To check the security information for a database administrator, enter the database administrator’s user ID or alias; then press F2. To check information about the next database administrator in the list, press F3.

To add or change security permissions for a database administrator:


Configuring DSM/SCM Setting Security for Operators

a. Enter the database administrator’s user ID or alias and press F2 to check the user’s permissions.

b. To grant a permission, enter Y in its data field. To deny a permission, enter N in its data field.

DSM/SCM is usually configured by the initial database administrator. By default, each database administrator has full permission to access the ZPHITMI. To apply restrictions, set the appropriate flags on the Database Administrator Security screen.

c. When all permissions are set, press Shift-F2 if you are updating an existing operator or F7 if you are adding a database administrator.

If more than one page of database administrators exists, make any changes before pressing F3 to check additional administrators.

a. After you add all database administrators, press Shift-F16 to return to the main menu.

b. Press Shift-F16 to exit the ZPHITMI.

Setting Security for Operators

The operator initiates tasks on a target system, usually as directed by the planner. For information about the tasks operators can perform, see Operator Tasks on page 4-16. You can establish operators without any permissions, giving them read-only access to a subset of DSM/SCM functions. They can view items such as configurations and inputs but cannot make changes.

Use the ZPHITMI to establish and maintain system security for target system operators. Security information for operators is stored in the target system database.

Adding or Deleting an Operator (ZPHITMI)

1. From the ZPHITMI, select 3 (Security Maintenance menu); then press F1. DSM/SCM displays the Security Maintenance menu.

2. From the Security Maintenance menu, select 1 (Operator Security Maintenance); then press F1. DSM/SCM displays the Operator Security Maintenance screen.

3. From the Operator Security Maintenance screen, press Shift-F4. DSM/SCM displays a list of all operators for this target system.

You can page through the list by using the PgUp and PgDn keys. Press F16 to return to the Operator Security Maintenance screen.

To add an operator or change security permissions for an operator:

a. Enter the operator’s user ID or alias; then press F2 to check information about the operator. To grant a permission, enter Y in its data field. To deny a permission, enter N in its data field.


Configuring DSM/SCM Setting Security for Operators

By default, each operator has full permission for ZPHITI access. To apply restrictions, set the appropriate flags on the Operator Security screen.

b. When all permissions are set, press Shift-F2 if you are updating an existing operator or F7 if you are adding an operator.

To check the security information for an operator, enter the operator’s user ID or alias; then press F2. To check information about the next operator in the list, press F3. If more than one page of operators exists, make any changes before pressing F3 to check additional operators.

To delete the operator, enter the operator’s user ID or alias; then press F6. DSM/SCM removes the operator from DSM/SCM.

4. After you have finished, press F16 twice to return to the main menu.


Configuring DSM/SCM Managing the DSM/SCM Configuration

Managing the DSM/SCM Configuration Changing DSM/SCM Default Parameters on page 5-15

Managing Logical Targets on page 5-17

Adding a Logical Target on page 5-17

Initializing a Logical Target on page 5-18

Deleting a Logical Target on page 5-21

Creating an Alternate System Disk on page 5-22

Reinitializing DSM/SCM on page 5-30

Changing DSM/SCM Default Parameters

You can use the various DSM/SCM interfaces to change the default values. Table 5-2 lists the interface and function to use to change a particular value.

Table 5-2. Changing DSM/SCM Default Parameters (page 1 of 3)

To change... Interface By updating the...

Software inputs in the archive: compress or uncompress .

Planner Interface Configuration Manager Profile

Tape drive for activation packages and snapshots.


Retention period for requests. Planner Interface Configuration Manager Profile

Volume to use for exported archive files.


Disk output location for reports. Planner Interface Configuration Manager Profile

Spooler output location for reports.


Planner user ID Planner Interface Planner Security Profile

Planner: DSM/SCM tasks they are allowed to perform.

Planner Interface Planner Security Profile

Host system database administrator user ID

Planner Interface DB Admin Security Profile

Database administrator: DSM/SCM tasks they are allowed to perform.

Planner Interface DB Admin Security Profile

Target system site ID. Planner Interface System Maintenance Profile


Configuring DSM/SCM Changing DSM/SCM Default Parameters

Processor type (TNS, TNSR, TNSE).

Planner Interface System Maintenance Profile

Whether the target should use a network connection to the host.


If Safeguard is required to be running.


Tapes: Unload tapes after use? Planner Interface System Maintenance Profile

Host system scratch and archive volumes.

Planner Interface Volume Maintenance

Output location for target reports.

Planner Interface Target Output Defaults

Volume on which an activation package or snapshot is placed.


Target volume for new subvolumes.


Ownership for new files. Planner Interface Target Output Defaults

Security for new files. Planner Interface Target Output Defaults

CONFTEXT file location. Planner Interface Target SYSGEN Defaults

CONFTEXT file: Expand DEFINE statements?

Planner Interface Target SYSGEN Defaults

System generation work files: How are the work files managed?


Spooler location for system generation report output.


System Image Tape (SIT): Should SIT be created? (G-series only).


Move an archive from one volume to another.

Host Maintenance Interface

Archive Relocation

Move the host system database from one volume to another.

Host Maintenance Interface

Database Relocation

Target system volume usage. Target Maintenance Interface

Volume Maintenance

Location of the target system database volume.

Target Maintenance Interface

Database Relocation

Target system operator user ID Target Maintenance Interface

Operator Security Maintenance



Configuring DSM/SCM Managing Logical Targets

Managing Logical Targets

You can add, initialize, or remove logical targets.

Adding a Logical Target

You can add multiple logical targets to existing DSM/SCM host or target systems. Initialize a new logical target for a target system with an existing profile and the configuration associated with that profile. Then change the profile information and product list as needed. When adding more logical targets:

You cannot maintain more than six logical targets on a single system.

Each logical target requires its own $SYSTEM volume and a unique alternate volume name. The primary volume name for each logical target must be $SYSTEM, and the alternate volume name for each logical target must be different to differentiate between the disks.

To switch from one logical target to another, you must perform a system load.

DSM/SCM tasks the operators can perform.


Operator Security Maintenance

Target system database administrator user ID


DB Admin Security Maintenance

DSM/SCM tasks a database administrator can perform


DB Admin Security Maintenance

Host system that manages a target system

INITENV Change option

Hometerm name INITENV Change option

Priority for DSM/SCM processes

INITENV Change option

PROGID of the DSM/SCM server processes

FUP (File Utility Program)

Object Manager server class name

Edit DSMSCM.INI file

CNFGINFO process name Edit DSMSCM.INI file

Host system IP address or name


IP port number to be used for Winsock





You cannot perform an initialization Build/Apply if it was previously performed on any other logical target created on that particular physical target system.

To add a logical target:

1. In the Configuration Revisions window, select the system to which you are adding the new logical target.

2. Select Maintain>Target maintenance>Add....

3. In the New Target dialog box, enter a name for the new logical target in the Target name field. When creating multiple logical targets, distinguish targets by giving meaningful names.

4. Select another logical target from which to copy profile data in the Copy profile data from list.

5. Click Setup. DSM/SCM displays the Target Information dialog box.

6. From the Target Information dialog box:

a. Check the defaults and update as needed. (Target Profile on page 17-6)

b. Click OK.

The new logical target is defined to DSM/SCM, and its name appears in the Configuration Revisions window with a revision number of 1.

7. Modify the product list as necessary, then build and apply the initial revision for this logical target. See Section 8, Creating and Managing Software Revisions.

Initializing a Logical Target

Initialize the logical target on the host system after these procedures

Adding a logical target to a system. See Adding a Logical Target on page 5-17. You cannot perform an initialization Build/Apply if it was previously performed on any other logical target created on that particular physical target system.

Using INITENV with the initialization option

To initialize the target:

1. Log on to the Planner Interface.

2. In the Configuration Revisions window, select the configuration name for the target. For a new target, the name has the form:

\system_name DEFAULT

Note. If you use multiple logical targets on a system, always run DSM/SCM from the first ZDSMSCM subvolume installed on the target system. To ensure the correct installation files are used, this ZDSMSCM subvolume must also be the one from which INITENV was run.



3. Select Maintain>Target maintenance>Initialize target system.

4. Click Profile. DSM/SCM Displays the Naming the Target dialog box.

5. From the Naming the Target dialog box:

a. Enter a descriptive target name.

b. Click OK. DSM/SCM displays the target Information dialog box.

6. From the target Information dialog box, configure the target profile as needed. (DSM/SCM displays the Target Information dialog box. on page 17-6). Enable or disable OSS file management as needed.

7. Load the SUT onto the tape drive.

8. Click the Software in Archive window.


10. Receive the RVU software into the archive. For descriptions of each option, Receiving and Managing Software Inputs on page 7-1.

11. After you receive software into the archive, select the target from the Configuration Revisions window.


13. From the Initialize target system dialog box, click Software. DSM/SCM displays a new software revision window containing the product list.

14. From the Software in Archive window:

a. Select the RVU you just copied to the archive.

b. Click Copy to. DSM/SCM copies the contents of the RVU to the new revision.

15. If a warning appears, choose to continue or cancel.


17. From the Initialize target system dialog box, click Build/Apply. DSM/SCM saves the new software revision, then displays the Indicate Type of Build dialog box.

18. Indicate the type of Build to send.

HP strongly recommends that you build an initialization Build/Apply. After reinitializing a system, you must do perform an initialization build/apply before you




perform a normal Build/Apply of an RVU, SPR, or other software on any host or target system on which DSM/SCM has been newly configured.

19. From the Build/Apply Request window:

a. Select a build request or build, apply, and snapshot request. See Task 2: Indicate a Build/Apply or Build Request on page 9-10.

b. Specify a different SYSnn. subvolume. See Task 3: Specify the SYSnn Subvolume on page 9-11.

c. To use the default output or system generation options, you can skip this task. To change the values for these options, see Task 4: Set the Options for the Build and Apply Request on page 9-12.

d. To run this task immediately, you can skip this task. To schedule the task for another time, see Task 5: Schedule the Request on page 9-22.

e. Click Edit Instructions and enter necessary information for planner. Task 6: Edit the Instructions on page 9-23

In item 4, replace nn with the SYSnn you specified.

f. From the Planner Instruction window, click OK.

g. Click TSV Location....

Verify volumes. Move the ZDSMSCM subvolume to the $DSMSCM volume so that the database is always accessible no matter which alternate system disk you perform a system load from.

20. Submit the Build request. See Task 7: Submit the Request on page 9-24.

21. Click OK to verify OSS file management (if Manage OSS Files is checked).

22. If DSM/SCM is configured to send a snapshot to the host system automatically, proceed to Task 8: Accepting Discrepancies on page 5-37. If the snapshot is not sent automatically:

a. Select Maintain>Target maintenance>Initialize target system.

b. From the Initialize Target System dialog box, click Snapshot.

23. Click Yes to mark the system as initialized. DSM/SCM displays the Initialized Target dialog box.

24. Click OK. Initialization is complete.

25. Select File>Exit to exit the Planner Interface. Configuration of the system and its logical target is complete.



Deleting a Logical Target

To remove a logical target, its profile information, and all its associated software revisions from DSM/SCM:

1. Delete the logical target from the host, using the Planner Interface:

a. From the Configuration Revisions window, select a configuration revision.

b. Select Maintain>Target maintenance>Delete....

Although the logical target no longer appears in the Configuration Revisions window at this point, the logical target is not yet deleted from the target system itself.

2. Delete the logical target from the target system:

a. Check that ZDSMSCM is the current subvolume, then run the ZPHITI:

> VOLUME $volume.ZDSMSCM> RUN ZPHITI

b. Log on to the ZPHITI.

c. Select 3 (Perform target activities); then press F1.

d. Select a target; then press F1.

e. Note the SYSnn displayed at the top of the screen.

f. Press Shift-F16 to exit the ZPHITI.

g. Purge the entire SYSnn or purge only the ZPHI6030 file in this SYSnn.

h. Run Verify Database from the ZPHITI. See Verifying the Target System Database (ZPHITI) on page 17-18.

Note. A physical target system must have at least one logical target. Therefore, you cannot delete the last logical target using the Planner Interface. To remove an entire target system, use the System Maintenance option in the Maintenance Interface.

If you delete a logical target through the Maintenance Interface, the target still appears in the Configuration Revisions window but has a revision level of 1 and an empty product list.

Note. If you purge only the ZPHI6030 file from a currently running SYSnn and Verify Database is run, files in the SYSnn are not purged. All TSVs remain but are not managed by DSM/SCM.


Configuring DSM/SCM Creating an Alternate System Disk

Creating an Alternate System Disk

1. Prepare and rename the volume using the subsystem control facility (SCF). See these manuals:


NonStop S-Series Hardware Installation and Fast Path Guide

2. Run Verify Database from the ZPHITI. See Verifying the Target System Database (ZPHITI) on page 17-18.

If the volume was a scratch volume, Verify Database will stop in restartable mode, issuing an EMS message that no scratch volumes are configured on the target system. Define at least one scratch volume using the ZPHITMI. Then restart the Verify Database activity. After successful completion of Verify Database, update the volume usage information using the ZPHIHMI.

If the volume was an archive volume, update the volume usage information using the ZPHITMI and ZPHIHMI after successful completion of Verify Database. See Updating the Volume Usage on page 17-11

3. Create an independent snapshot. See Creating an Independent Snapshot of the Target System on page 17-19.

4. Add a logical target for the alternate system disk, including performing a Build/Apply to the new logical target. See Adding a Logical Target on page 5-17.

5. For the remaining steps, return to these manuals:


NonStop S-Series Hardware Installation and Fast Path Guide


Configuring DSM/SCM Configuring a Backup Host System

Configuring a Backup Host System

For disaster recovery, you can configure a backup DSM/SCM host system to function as the primary host system if your primary host system fails. You cannot manage the same target from more than one host. To manage a target systems using a different host system, you must use INITENV to reinitialize the target and specify the new host system. The software revision histories for the target maintained on the old host system are lost. To circumvent this, you can maintain a backup host system with certain volumes and configurations identical to your primary host system. If necessary, the backup system can relatively easily assume the identity and function of the primary host.

In this procedure, one NonStop S-series system is configured as the primary host system, and another as the backup host system. Only the primary host is active in the DSM/SCM environment and used for all DSM/SCM operations. Use the backup host only in a non-business critical environment such as for development.

To ensure you always have a backup record of the current state of the DSM/SCM environment, routinely back up the primary host. For a smooth transfer of DSM/SCM operations from the primary host to the backup host, the backup must be current. If you do not backup the primary host after every DSM/SCM operation, problems might arise from discrepancies between the backup record and the actual state of the DSM/SCM environment.

If the primary host fails:

1. Bring down the backup system.

2. Bring up the backup system as the primary host, using the primary host’s system name and number and IP address.

3. Restore the backup tape from the primary host onto the backup host.

Caution. One or both of these steps ensure you always have a backup of your system information:

Running your system with a mirror of $SYSTEM

Creating a backup disk image of $SYSTEM and storing it in a safe place so you can physically install and boot the backup disk if needed

Caution. Applications previously running on the backup host can be adversely affected by this procedure because there are no provisions for recovery of any applications other than DSM/SCM. For this reason, the backup host should be a noncritical system.



Selecting Primary and Backup Systems

Selecting which system to use as the primary host for this setup is the same as selecting a host system in any environment. See Task 1: Planning the DSM/SCM Environment on page 4-2. Because your backup host needs to fully perform as the primary if needed, consider the same guidelines in choosing it as for the primary host.

In setting up your backup system, check that it has:

Disk volumes associated with DSM/SCM (for the archive, files, and databases) configured the same way as on the primary host. That is, these volumes need the same primary and alternate volume names on both systems.

The same software revision as the primary host to avoid incompatibilities with software products when the backup host becomes the primary host.

An Expand connection to all the target systems that the primary host is similarly connected to, including REMOTEPASSWORDS. The TACL macros used to start Expand between the primary host and the targets are copied from the primary host to the backup host and are used by the backup host if it becomes the primary host.

User accounts and passwords for the planner, operators, and database administrators identical to the primary host.

If the backup host system becomes the primary host system, it continues to serve as the primary host for future DSM/SCM operations. Therefore, it should have sufficient system resources to serve as such.

Creating the Backup Host Environment

To prepare your DSM/SCM environment for the possibility of your host system failing:

1. Gather this information about your primary and backup host systems:

Ethernet addresses:

>SCF->INFO SUBNET $ZTC*.*->EXIT

System name and number:

>SCF->ASSUME SUBSYS $ZZKRN->INFO->EXIT

Remote passwords:

> REMOTES

Location of startup command (OBEY) file

Location of Expand startup macros



Location of TCP/IP startup macros

Location of DSM/SCM SQL databases (usually same volume as ZDSMSCM subvolume)

Location of CONFTEXT file

Location of ZDSMSCM subvolume (must be same on both systems)

2. Initialize the primary host system if needed. This is the normal initialization when you configure your host system. You do not need to change anything for this procedure. The primary host does not need to be connected using Expand to its target or backup host systems.

3. Initialize the backup host system. Initialize the system as a target system, managed by the primary host. Check that the necessary aspects of the backup host’s configuration are identical to those of the primary host system.

4. Initialize the target systems. Use INITENV to initialize your other target systems as needed.

5. Build/Apply the target systems, the backup host system, and any logical targets on the host system. Update the software configurations on all your systems as needed.

6. Back up the primary host DSM/SCM environment. After any DSM/SCM operation, back up all DSM/SCM-related volumes and subvolumes on your primary host. This ensures that integrity of the current DSM/SCM environment is preserved if the backup host must become the primary:

a. Create an INPUT file for the BACKUP utility that includes:

$TAPE0, ($SYSTEM.*.*, $volume.REPORT.*, $*.ZPHI*.*, $volume.ZDSMSCM.*, $volume.XCHINOOK.*, $volume.XPHIHDB.*, $volume.PATHSCM.*, $volume.SQL.*), not ($SYSTEM.STARTUP.*, $SYSTEM.ZSYSCONF.*, $SYSTEM.EXPAND.*, $SYSTEM.KMSSWAP.*, $SYSTEM.LAN4PORT.*, $SYSTEM.ZTMFCONF.*, $SYSTEM.SAFE.*, $SYSTEM.SAVECONF.*, $SYSTEM.SCFBASE.*, $SYSTEM.ZOSM.*, $SYSTEM.SCFIN.*, $SYSTEM.SCFTOOLS.*,$SYSTEM.SPOOLER.*, $SYSTEM.TAPEIOP.*, $SYSTEM.SDISK.*,$SYSTEM.ZSERVICE.*, $SYSTEM.ZLOG00.*, $SYSTEM.ZLINKMON.*,$SYSTEM.SYS*.* ), audited, SQLCATALOGS, open, LISTALL

b. Run BACKUP using this INPUT file:

> BACKUP/in input-filename/

7. Move necessary startup files from the primary host to the backup host. Startup files include those that start up processes such as Expand lines, the TCP/IP process, and so on. You can more easily copy and modify the startup files from the primary host to the backup host than create startup files for the backup host from scratch. Because required startup files vary for different system environments, this is only an example:

a. Create a working subvolume on $SYSTEM to hold the startup files.



b. Copy the startup files for starting Expand lines, if any, from the primary host to the working subvolume on the backup host.

c. Copy the TCP/IP configuration file TCP00 from the $SYSTEM.LAN4PORT subvolume on the primary host to the working subvolume on the backup host.

d. Because some of the processes such as Spooler and TACL might be different on the backup host, add them to the copied files.

Because these startup files are not used until the backup system is converted into the primary host, modify them in a temporary subvolume until needed.

Converting the Backup Host Into the Primary Host

If your primary host system fails, convert your backup system to serve as the primary host:

1. Check that the backup host has no SQL databases, including the system catalog. (The databases will be reinitialized with data from the primary host).

a. If the backup host has DSM/SCM host or target databases:

1. Go to the volume and subvolume containing the DSM/SCM files (usually $DSMSCM.ZDSMSCM).

2. Determine if a host database exists:

>FUP SUBVOLS

If subvolume XPHIHDB exists, a host database exists. If not, go to Step 8.

3. Check that the ADDHDEFS file reflects the proper system:

a. Check the system name in the file to see if it lists your backup host or your old primary host. Check ADD DEFINE lines such as:

ADD DEFINE =PHIHDB, SUBVOL \sysname.$DSMSCM.XPHIHDB

b. If the listed system name lists the old primary host instead of the backup host, use EDITOR to update the file (it is case-sensitive):

> EDIT ADDHDEFS

C/old-system-name/new-system-name/A

4. Run the ADDHDEFS file:

>OBEY $DSMSCM.ZDSMSCM.ADDHDEFS

5. Run the file HDBREL2 to drop most host database tables:

>SQLCI OBEY HDBREL2; EXIT;

Caution. After you drop a database, all of its data is lost. Check that you can safely delete the additional databases before continuing.



6. Drop the host database manager program file PHIHDBMG:

>SQLCI DROP PROGRAM $DSMSCM.XPHIHDB.PHIHDBMG; EXIT;

7. Drop the host database catalog:

>SQLCI DROP CATALOG $DSMSCM.XPHIHDB; EXIT;

8. Check that the ADDTDEFS file reflects the proper system:

a. Check the system name in the file to see if it lists your backup host or your old primary host. Check ADD DEFINE lines such as:

ADD DEFINE =PHITDB, SUBVOL \sysname.$DSMSCM.Xsystem

b. If the listed system name lists the old primary host instead of the backup host, use EDITOR to update the file (it is case-sensitive):

> EDIT ADDTDEFS

C/old-system-name/new-system-name/A

9. Run the ADDTDEFS file:

>OBEY $DSMSCM.ZDSMSCM.ADDTDEFS

10. Run the file TDBREL2 to drop most target database tables:

>SQLCI OBEY TDBREL2; EXIT;

11. Drop the program file PHITDBMG (sysname is the target system name):

>SQLCI DROP PROGRAM $DSMSCM.Xsysname.PHITDBMG; EXIT;

12. Drop the target database catalog (sysname is the target system name):

>SQLCI DROP CATALOG $DSMSCM.Xsysname; EXIT;

13. Check that no more databases remain on the backup host system:

>VOLUME $DSMSCM.SQL>SQLCI>> SELECT * FROM CATALOGS;>> EXIT;

Any remaining databases and the system catalog (usually SQL) are displayed.

b. If the backup host has non-DSM/SCM databases:

1. To delete existing databases and catalogs, see the SQL/MP Reference Manual.

2. Delete the system catalog.

c. Drop the system catalog:

> SQLCI DROP SYSTEM CATALOG $DSMSCM.SQL; EXIT;



2. Rename and renumber the backup host system to the system name and number of the primary host system:

a. Check that the primary host system is down.

b. On the backup host system:

> SCF-> ASSUME SUBSYS $ZZKRN-> ALTER, SYSTEM_NAME\primary-host-name-> ALTER, SYSTEM_NUMBER\primary-host-number-> EXIT

3. Edit the startup file to start necessary processes.

4. Restart the backup host system:

a. On the system console connected to the backup host system, log on to OSM Low-Level Link.

b. From the File menu, select Start Terminal Emulator>For Startup TACL and Start Terminal Emulator>For Event Streams.

c. On the Low-Level Link toolbar, click Processor Status.

d. Select all of the running processors.

e. Select Reset and click Perform Action.

f. After all Reset actions have been completed, select all processors except the primary processor.

g. Select Prime For Reload and click Perform Action.

h. Select the primary processor.

i. Select Load and click Perform Action.

5. Create the necessary SQL catalogs: system catalog, system database, DSM/SCM host and target databases. In this example, all databases are on the volume $DSMSCM, and the system catalog is in the subvolume SQL:

> FUP DUP $SYSTEM.SYSTEM.ZZSQLCI2,$SYSTEM.SYSTEM.ZZSQLCIX,& > SAVEALL, PURGE> SQLCI>> CREATE SYSTEM CATALOG $DSMSCM.catalog-subvolume;>> INITIALIZE SQL;>> CREATE CATALOG $DSMSCM.XPHIHDB;>> CREATE CATALOG $DSMSCM.Xtarget-name;>> CREATE CATALOG $DSMSCM.Xtarget-name;>> EXIT> FUP DUP $SYSTEM.SYSTEM.ZZSQLCIX,$SYSTEM.SYSTEM.ZZSQLCI2, SAVEALL, PURGE

6. Restore the DSM/SCM environment to the backup host system. This populates the host and target databases with information from the primary host.



a. Load the backup tape you made from the primary host.

b. Restore the backed up files:

> RESTORE/OUT $S.#LOG/ $tapedrive-name,*.*.*, open, audited, listall, nounload

Because you are not restoring the SQL catalog tables, you receive errors.

c. Check the out file for errors other than SQL catalog tables not being restored.

7. Restart the backup host system. See Step 4.

8. Bring up the network.

If your modified network startup files have not run, run them. Check that the TCP/IP subsystem and any Expand lines have successfully started.

9. Restart the DSM/SCM environment.

a. Start TMF.

b. Change the volume to $DSMSCM.ZDSMSCM.

c. Run IPM6031.

d. Run STARTSCM. For more information, refer to Starting and Stopping DSM/SCM on page 2-2.

e. Connect a workstation to be used for the Planner Interface. This workstation should have DSM/SCM settings identical to the workstation for the original primary host system.

f. Start the Planner Interface to ensure that it starts up and displays the DSM/SCM environment correctly.

10. Synchronize the host and target databases by performing Verify Database on the new (formerly backup) host system:

a. Change the volume to $DSMSCM.ZDSMSCM.

b. Start the ZPHITI:

> RUN ZPHITI

For more information, refer to Entering the ZPHITI on page 2-11.

c. Perform Verify Database on the backup host.

d. Create an independent snapshot to update the host database.

e. Repeat Steps a through d for each target system this host manages.

11. Build a new software revision for the target systems.

12. Build a new software revision for the host system:


Configuring DSM/SCM Reinitializing DSM/SCM

Check that the Planner Interface is pointing to the CONFTEXT file for the backup host system, not for the original primary host.

Purge the ZMP99999 file from $SYSTEM.SYSTEM.

The backup host system is successfully converted to serve as the primary host system. Treat it as the primary host system for future DSM/SCM operations.

Reinitializing DSM/SCM

Reinitializing erases all information in the host database, target database, and archive. It does not affect the installed software unless you choose a full activation package instead of an initialization package. When you reinitialize DSM/SCM, INITENV purges old DSM/SCM files to clean up the system.

Task 1: Run INITENV to Reinitialize

1. Log on to your system as the DSM/SCM user ID. For example:

> logon 255.255

password:

2. Make ZDSMSCM the current subvolume:


3. Check that TMF is running:

> TMFCOM START TMF

4. Check that DSM/SCM is not running:

> RUN STOPSCM

For more information, see Starting and Stopping DSM/SCM on page 2-2.

5. Run INITENV:

> RUN INITENV

Use this checklist as a quick guide to reinitialize a host or physical target system. The right column provides common entries and actions to perform for a NonStop system that is network connected, uses Winsock, and has the ZDSMSCM subvolume located on $DSMSCM. For more information, see Configuring a Host or Target System on page 5-2.

Note. After you reinitialize a host that has associated physical targets, you also need to separately reinitialize each target system.



Table 5-3. Reinitialization Checklist (page 1 of 2)

___ Would you like to read the introduction? Yes or No

___ Are you changing or initializing the system?

Choose to reinitialize to:

Change a target system to a host system

Change the TMF volume or the SQL system catalog volume

Initialize after reinstalling DSM/SCM because of an operational error.

I

___ Database will be destroyed, continue?

Destroying the host database, target database, and archive is necessary to reinitialize, so confirm it.

Y

___ Host or physical target system?

The default is to configure the system as a host.

Host or Target

If initializing a host system:

___ Winsock or RSC?

Winsock is the default. Use the default. INITENV then asks you to provide this information:

Volume for SERVICES and PORTCONF files

Host Database Volume

The default volume is $DSMSCM. Use the default or specify the name of the volume that contains the host database. The volume must be audited by TMF.

IP Port Number

Winsock

___ Configure Winsock server? Yes

___ Database volume? This volume must be audited by TMF. $DSMSCM

___ Volume for SERVICES and PORTCONF files? Enter, to accept default

___ IP Port Number?

The default IP port is 1089. The location of the Winsock SERVICES and PORTCONF files, and the IP port number to use. If you do not use the default, you must use an unused number between 1025 and 65535.

Enter the same IP port number used for the Planner Interface on the PC. See Task 2: Install the Planner Interface on the PC on page 4-7.

1089



INITENV automatically runs STARTSCM and VERIFYI as its last step to verify the DSM/SCM system environment configuration. DSM/SCM must be running for the verification procedure.

___ Compress files? If disk space is limited, enter yes.

The default is to not compress archive files because it improves I/O time as compared to compressing the files. Compressing archive files reduces their size about fifty percent and reduces transmit time to remote systems over Expand if space is more important at your site. However, compressing and decompressing files adds to processing time for tasks involving archive files, such as receiving software into the archive, creating software revisions, building configuration revisions, and others.

No

If initializing a physical target system:

___ Host system name for this target?

Enter the name of the host system that will manage this target system. After changing a host system’s name, you must update the host system name on all target systems before you can perform any DSM/SCM tasks on them.

\hostname

___ Database volume?

$DSMSCM is the default volume for the target database on the host. The volume must be audited by TMF.

$DSMSCM

___ DSM/SCM user ID.

The default DSM/SCM user ID is the super ID (255,255).

dsmscm-user-id

___ Hometerm for use by DSM/SCM Pathway servers and other processes. $ZHOME is the default. This virtual terminal is always running in the paused state. This prevents DSM/SCM from stopping even if the system console is not in the paused state. If you do not use $ZHOME, you must use a terminal that can be paused while DSM/SCM is running.

$ZHOME

___ The DSM/SCM servers can consume a lot of CPU time to perform few tasks. Set the priority on which the DSM/SCM Pathway servers and other processes must run. The priority must be below the priority of your production applications such that the DSM/SCM servers do not slow down your production applications. The default priority of DSM/SCM servers is 50.

priority

Table 5-3. Reinitialization Checklist (page 2 of 2)



Task 2: Reconfigure the Host Database

Only a host system contains a host database. If you reinitialized a target system, proceed to Task 3: Reconfigure the Target Database on page 5-34.

Reinitializing a host system removes all the default host and target system information in the host database. You must reconfigure the host database to set the defaults for DSM/SCM operations such as user security, file transfer, and scheduling options. All target information that you update in the host database must also be updated in the target database.

1. Add a planner ID. For more information, see Setting Security for Planners on page 5-8.

2. Use the ZPHIHMI to configure the system profile for this system. For more information, see Updating the System Profile Information (ZPHIHMI or ZPHITMI) on page 17-4.

3. Designate the volumes to use for the archive or scratch space on this system. For more information, see Updating the Volume Usage on page 17-11.

4. Add database administrators for this host system. For more information, see Setting Security for Database Administrators on page 5-11.

5. Update the Configuration Manager Profile. For more information, see Configuration Manager Profile on page 17-2.

Task 2: Configure the Host Database on page 5-5

Task 2.1: Set Planner Security

___ Run the ZPHIHMI on the host system:

> Volume $DSMSCM.ZDSMSCM> RUN STARTSCM> RUN ZPHIHMI

___ Log on to the ZPHIHMI. Enter the dsmscm-user-id, password, and press F1

___ Select Security Maintenance. Enter 3 and press F1

___ Select Planner Security Maintenance. Enter 1 and press F1

___ Type a planner user ID or alias to add. planner-user

or alias123

___ Set the DSM/SCM tasks the planner can perform. All set to yes

___ Add planner. F7

___ After all planners are added, return to main HMI menu. Shift-F16

___ Exit the ZPHIHMI. Shift-F16

Task 2.3: Update System Volume Usage

___ Select Maintain>Volume Maintenance.



Task 3: Reconfigure the Target Database

Reinitializing a host system or target system removes all the default target system information in the target database. You must reconfigure the target database to set the defaults for DSM/SCM operations such as user security, file transfer, and scheduling options. Use the ZPHITMI to configure DSM/SCM target database information:

1. Configure the target system profile. See Target Profile on page 17-6.

To change volume usage:

___ Select the volume name to change usage for.

___ Click the Change Usage button.

___ Click OK to submit the changes.

___ Click OK to exit.

Task 2.4: Set Host Database Administrator Security

___ Select Maintain>Security Maintainence>DB Administrator List.

To modify a database administrator:

___ From the list, select a database user ID or alias.

___ Click the Modify button.

___ Set tasks the database administrator can perform. All tasks checked.

___ Click OK.

To add a database administrator:

___ Click the Add button.

___ Type a database administrator user ID or alias to add.

authorized-DSM-user

or alias123

___ Set tasks the database administrator can perform. All tasks checked.


Task 2.5: Update the Configuration Manager Profile

___ Select Maintain>Configuration Manager.

___ Default tape drive. $TAPE

___ Retention period for requests. 14 days

___ Volume to use for exported archive files. $AUDIT

___ Default spooler or file output location for reports. $AUDIT.REPORTS

___ Default spooler output location for reports. $S.#REPORT

___ Set the Compress Software in Archive flag to indicate whether to compress software when stored in the archive.

No (unchecked). If disk space is limited, enter yes.




2. Designate volumes to be used as scratch on this target system. See Updating Target Volume Usage (ZPHITMI and ZPHIHMI) on page 17-12.

3. Add operators and database administrators for this target system. See Setting Security for Target Database Administrators (ZPHITMI) on page 5-12.

Task 3: Configure the Target Database on page 5-7

Task 3.1: Update the Target System Profile

___ Run the ZPHITMI:

> Volume $DSMSCM.ZDSMSCM> RUN STARTSCM> RUN ZPHITMI

___ Log on to the ZPHITMI. Enter dsmscm-user-id, password, and press F1

___ Select System Maintenance. 1 and press F1

___ If physical target system, enter target System Name.If host system, enter host System Name.

\targetname or \hostname

___ Enter Target System Site ID. To identify the site ID, see Checking the Site ID on page 5-3.

Set by HP.

___ Enter CPU Type:

TNSE = Intel Itanium

TNSR = RISC

TNS = CISC

TNSR

___ If physical target system, enter the host system that manages this target.

\host name

___ Tape Unload Flag set? Indicate whether DSM/SCM should unload tapes when finished.

Yes

___ Safeguard Required Flag set? Indicate whether Safeguard must be running whenever DSM/SCM places files.

No, leave unchecked.

___ Use network connection? Yes

___ Submit changes. Shift-F2

___ Return to main TMI menu. F16

Task 3.2: Update Target Volume Usage

___ Select Volume Maintenance. 2 and press F1

___ Enter one or more scratch volume names. $DSMSCM

___ Submit changes. Shift-F2

___ Return to main ZPHITMI menu. F16

Task 3.3: Set Operator Security

___ Select Security Maintenance. 3 and press F1

___ Select Operator Security Maintenance. 1 and press F1



Task 4: Modify Profile Information for the Logical Target

For more information, refer to Setting the Target Output Defaults on page 17-7.

Task 5: Initialize the Logical Target on the Host System

Initialize the logical target on the host system after running INITENV with the Initialization option. See Initializing a Logical Target on page 5-18.

Task 6: Receive Software

Receiving software comprises reading software and placing it in the archive. HP highly recommends that you use the same RVU and related SPRs that were used to build the current operating system. To receive the software into the archive, see Receiving Software Into the Archive on page 7-3.

If you received the same software as your current configuration, synchronize the new DSM/SCM configuration against the current configuration by performing an Initialization Build/Apply.

At this point, DSM/SCM does not recognize the SYSnn currently running on your system. Perform an Initialization Build/Apply to synchronize the databases and to get a snapshot of the system before the software is actually placed in the TSVs.

If you received new software and it does not matter what was on your current operating system, perform a full Build/Apply.

___ Enter an operator user ID or alias to add. authorized-DSM-user

or alias123

___ Set the DSM/SCM tasks the operator can perform. All set to yes

___ Add operator. F7

___ After all operators are added, return to main TMI menu. Shift-F16

Task 3.4: Set Target Database Administrator Security

___ Select Security Maintenance. 3 and press F1

___ Select Database Administrator Security Maintenance. 2 and press F1

___ Enter a target database administrator user ID or alias to add.

authorized-DSM-user

or alias123

___ Set the DSM/SCM tasks the target database administrator can perform.

All set to yes

___ Add target database administrator. F7

___ After all administrators are added, return to main TMI menu.

F16

___ Exit TMI. Shift-F16



HP recommends that you perform an initialization Build/Apply before you perform the full Build/Apply. A full Build/Apply builds a new SYSnn and places the new software in the TSVs.

Task 7: Activate the New Software on the Target System

After the software is placed in the appropriate TSVs, you need to activate the new software. Run ZPHIRNM to rename the old software files to fabricated names while the new software is renamed to the appropriate real name. See Section 10, Activating New Software on a Target System.

Task 8: Accepting Discrepancies

Discrepancies are differences between the configuration of a target as it is known to DSM/SCM and the actual configuration on that target. After an Initialization Build/Apply, you must accept any discrepancies. Resolving discrepancies that arise minimizes the chances that they will affect your system. You can resolve discrepancies at any time after applying an initialization package to a target.

Causes of Discrepancies

Discrepancies can occur if you:

Apply an SPR to a product on the target system outside DSM/SCM.

Move a TSV outside DSM/SCM.

Duplicate TSVs. If you find duplicate TSVs, you need to perform a new Build/Apply. To avoid duplicate TSVs, identify TSV locations correctly at the time of the initialization Build/Apply. See Discrepancy Troubleshooting on page 13-17.

Move or delete files.

Change data files. Discrepancies are often caused by data files (such as edit files and structured files) that changed in the course of normal operation.

For example, a data file discrepancy can occur if an SPR is on the target system but was not included in the initial configuration revision. As a result, this data file is not sent to the target system until a new version of the file containing a different original fingerprint is included in a configuration revision. The discrepancy is not a problem if the data file on the target is the correct one, and it has just been changed on the system.

Note. You are not required to resolve discrepancies to continue. You only need to be aware of the differences and understand what they mean when the next configuration is applied. You must accept the discrepancies before you can proceed.



However, a discrepancy might result because an incorrect SPR is in the initial configuration, and the data file is different from the one in the configuration. Even if the correct SPR is copied to the configuration, this file is not sent to the target again until a new version of the file with a different original fingerprint is added to the configuration.

Because a user or running software might change data files, DSM/SCM does not enforce its normal rules about changed files. Instead, it records the original fingerprint found for the file when the initial Build/Apply is performed. If a version of the file is later included in a configuration revision, and its fingerprint is different from the original fingerprint in the initial configuration, the file is considered changed.

Accepting discrepancies indicates to DSM/SCM that the data files’ original fingerprints are what they should be. If discrepancies exist for data files, and a data file in the configuration is the wrong one, DSM/SCM assumes that the data file on the target is a modified version of the one in the initial configuration.

Discrepancy Report

A discrepancy report is a standard DSM/SCM report that details any differences between what a snapshot indicates is on a specified target system and what is actually in the configuration most recently applied to the target. To help you isolate data file discrepancies, the discrepancy report lists discrepancies for nondata files in a product followed by discrepancies for all of its data files. If you use DSM/SCM to manage OSS files, OSS discrepancies are listed in a separate section after Guardian file discrepancies.

Note. A fingerprint discrepancy is the only type of discrepancy that applies to OSS files. Because TDLs cannot move, the discrepancies that apply to TSVs do not apply to OSS.

Example 5-1. Discrepancy Report

Expected TSV Location: Expected TSV ~ File Name ~ Actual TSV Location Actual TSV

---------------------- ------------ ~ --------- ~ ------------------- ----------

Product Name:DUPLICATE TSV INFO

Product Number:

Product Version:

$SYSTEM ZTMF ~ ~ $ARCHIVE ZTMF

$SYSTEM ZTMF ~ ~ $DATA ZTMF

$SYSTEM ZTMF ~ ~ $SYSTEM ZTMF

Product Name:DSM/SCM - TARGET COM

Product Number:T6031

Product Version:D46

$SYSTEM ZDSMSCM ~ HELPSRVO ~ $DATA ZDSMSCM

$SYSTEM ZDSMSCM ~ OSECUREL ~ $DATA ZDSMSCM

BEGIN DATA ~ FILES

$SYSTEM ZDSMSCM ~ INITENV ~ $DATA ZDSMSCM

$SYSTEM ZDSMSCM ~ VERIFYI ~ $DATA ZDSMSCM



1. Create a discrepancy report:

If you are running an initializing a target:

From the Initialize Target System dialog box, click Discrepancies.

If you are running a normal build/apply:

a. From the Planner Interface, select Requests>Prepare Reports.

b. Click Report request.

DSM/SCM displays the Prepare Report Request dialog box. For more information about generating DSM/SCM reports, see Section 18, Generating DSM/SCM Reports.

2. From the Prepare Report Request dialog box, select Discrepancy from the Reports list; then click Continue. DSM/SCM displays the Prepare Discrepancy Request dialog box.

3. From the Prepare Discrepancy Request dialog, select a SQLCI parameter from the list; then click Modify parameter. DSM/SCM displays the Modify Parameter Value dialog box.

a. From the Modify Parameter Value dialog box, enter the name of the configuration to be modified in the Value field. The name is case-sensitive.

For example, if the System name is \OAK, the Target name is DEFAULT, and Software Revision is 1 in the Configuration Revisions screen, enter this the configuration name:

\OAK DEFAULT 1

b. Click OK to return to the Prepare Discrepancy Request dialog box.

c. Prepare the report for printing or online viewing; then click OK to submit the Prepare Report request.

If there are no discrepancies, DSM/SCM displays the No Software Discrepancies dialog box.

If there are discrepancies, DSM/SCM displays the Software Discrepancies Found dialog box.



Resolving Discrepancies

Resolve the discrepancies.

1. Change the product list so that it matches the software on the target system. Include SPRs and other software you have installed on the target system. (Any software you add to the list must have already been received into the archive.)

2. Rerun the discrepancy report to see if all discrepancies are either resolved or considered acceptable.

3. Repeat Steps 1 through 3 until no discrepancies remain.

4. Perform another Build/Apply of the modified software revision.



This part of the guide provides an overview of installing and managing software on your system and describes the procedure in detail.

Section 6, Managing Software With DSM/SCM

Provides an overview of the four procedures in the process of updating a system’s software configuration using DSM/SCM

Discusses how to plan your system configuration activities

Section 7, Receiving and Managing Software Inputs

Provides step-by-step procedures for receiving and managing software inputs and for managing input and product groups

Section 8, Creating and Managing Software Revisions

Provides step-by-step procedures for creating software revisions in preparation for software installation or updating. This section also provides information on managing and sharing software revisions

Section 9, Building and Applying a New Configuration

Provides step-by-step procedures for building and applying new configurations for target systems

Section 10, Activating New Software on a Target System

Provides an overview of activating software so it can be used on a target system

Section 11, Renaming Product Files Using ZPHIRNM

Provides step-by-step procedures for running ZPHIRNM

Section 12, Loading the System

Provides and example of loading the system


6Managing Software With DSM/SCM

HP periodically issues new and revised software products. Use DSM/SCM to install, plan, and manage the new software on your local and distributed systems. From your host system, you can control the installation and configuration of the software on all your systems, local or remote, network connected or not.


Managing Software to Avoid a System Load on page 6-2

Receiving New Software Into the Archive on page 6-2

Creating a Software Revision on page 6-3

Building and Applying the New Configuration Revision on page 6-4

Applying the Configuration Revision on page 6-4

Transferring and Receiving the Snapshot Into the Host Database on page 6-5

Activating the New Software on the Target System on page 6-5

This section is an overview. For detailed instruction for each part of the process, see Sections 7 through 11.

Installing and managing software includes:

1. Receive Software Inputs Into the Archive—Copy the software inputs from their tape or disk subvolumes into the archive on the host system, thus adding the product distribution files to the archive.

2. Create a New Software Revision—On the host system, plan and create a new software revision – a list of the products to be installed on a target system.

3. Build a New Configuration Revision—Create a new configuration revision from the products listed in the new software revision. The distribution files are merged into executable formats. If necessary, DSM/SCM manufactures new files from the distribution files.

4. Apply the New Configuration Revision—Place the merged files on the target system. A snapshot of the target is created, transferred to the host system, and received into the host database.

5. Activate the New Software on the Target System—The new software is renamed as needed, and the system is readied to run the new software.

To install and manage software on multiple NonStop systems with identical configurations, see Section 19, Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning).


Managing Software With DSM/SCM Managing Software to Avoid a System Load

Managing Software to Avoid a System LoadDSM/SCM requires a system load whenever the OSIMAGE changes. However, to avoid system downtime, you can reinitialize DSM/SCM without performing a system load when:

For some SPRs, DSM/SCM assumes the OSIMAGE changed when it is unchanged.

You modify the CONFTEXT file for comments only.

You perform a backout to a previous configuration and use an identical configuration for a Build/Apply.

Receiving New Software Into the Archive Products received into DSM/SCM are stored as software inputs in the DSM/SCM archive. You use the software inputs later to update the software configuration of your system.

To bring the new software into the DSM/SCM archive, you can receive SPRs, Initial PVUs, and IPs from disk or tape:

For the complete procedure for receiving software into the archive, see Section 7, Receiving and Managing Software Inputs.

Note. Before you can receive customer and third-party software into the archive, you must use CNFINGO add the necessary configuration information. See Appendix C, Running CNFGINFO.

RVUs Full release version update. Contains an ordered combination of compatible software. A full RVU includes all the files, support information, and softdocs for each product.

SPRs Software product revision. An update to a software product. For NonStop products, a softdoc describing the changes is included. An SPR can include some or all files for a product.

Initial PVUs

Initial product version update. A NonStop product that contains new functions. Also, customer and third-party software can be brought into the archive as Initial PVUs.

IPs Independent Product. A NonStop product released independently of the regular HP release schedule.


Managing Software With DSM/SCM Creating a Software Revision

Creating a Software Revision A software revision is a list of products in the archive that updates the system’s software configuration. Use the Planner Interface to create a software revision:

Check the product softdocs and release documents to determine if any conflicts might arise. The softdocs describe new features, corrected problems, remaining known problems, dependencies on other software, and other product information.

From the software in the DSM/SCM archive, decide which software products to include in the new software revision. DSM/SCM determines the initial contents of a software revision from the target system’s RVU. Open the current revision of the software, then modify it by copying new product versions or SPRs from any software inputs in the archive. You can also delete products, add products from other sources, or replace products with different versions of the same product.

Create a product dependencies report

Copy products from an input or previous revision

Select a target system

Specify which products from the existing software inputs to install on the target

A new software revision is required to perform a Build/Apply, even if there are no changes to the software in the current configuration. To create a new configuration revision from an old configuration revision:

1. Create a new software revision.

2. Select the corresponding old software revision from the revision history.

3. Copy the information from the old software revision to the new software revision.

For the complete procedure for creating new software revisions, see Section 8, Creating and Managing Software Revisions.



Managing Software With DSM/SCM Building and Applying the New Configuration Revision

Building and Applying the New Configuration Revision

The planner builds a configuration on the host system. DSM/SCM builds a new configuration revision to:

Transfer the products listed in a software revision from the archive to the target system.

Merge the distribution files into executable or usable formats.

Create the activation package. If necessary, DSM/SCM includes a new operating system image produced by a system generation program.

The planner builds a configuration revision for new software revision. Perform a Build and provide DSM/SCM with the information needed to build the configuration revision and activate the software.

After the build finishes, DSM/SCM updates the Build activity record as completed. The status window shows the Build as complete and the remaining three activities (Apply, Create Snapshot, Input Snapshot) as Status Unavailable: Use ZPHITI.

For more details on building and applying a configuration revision, see Section 9, Building and Applying a New Configuration

Applying the Configuration RevisionDuring an Apply, the new configuration revision is placed on the target system, and the new software in the revision is readied for activation. DSM/SCM determines which files specified in the activation package to place in the designated target subvolumes. The product files are loaded onto the TSVs and TDLs. All files (except a new SYSnn) are placed on the target system under temporary names to avoid file name conflicts with existing files. This reduces application downtime by letting applications continue to run while new files are applied. To monitor the Apply request, use the ZPHITI.

Often, for convenience, DSM/SCM can automatically execute the Build and Apply together from one user request. In some cases, the Apply must be performed separate from the Build. If you selected:

A Build only, the target operator must submit a separate Apply request to apply the activation package to the target system after the Build is finished. After the Build finishes, perform an Apply to place the activation package on the target system.


Managing Software With DSM/SCM Transferring and Receiving the Snapshot Into the Host Database

A Build/Apply, and the activation package location is set to disk, the file transfer, apply, and snapshot are executed automatically after the Build finishes.

For the complete procedure for applying a configuration revision, see Task 8: Apply Software to the Target System on page 9-25.

Transferring and Receiving the Snapshot Into the Host Database

A snapshot is required to update the host database with information about existing and newly configured software on the target system. DSM/SCM can often generate a snapshot and receive it into the host database automatically as part of the Apply process if your systems use an Expand connection.

If the snapshot is not automatically sent to the host database, you must send a snapshot of the target system back to the host database. You can generate a snapshot at any time, independent of the Build and Apply processes. Receive the snapshot into the host database as soon as it is transferred so it is immediately available if you prepare another revision, back out a revision, or perform other maintenance tasks.See Task 9: Transfer and Receive the Snapshot Into the Host Database on page 9-27.

Activating the New Software on the Target System

DSM/SCM provides standard instructions for activating software. As needed, you can modify these instructions when planning the configuration by adding simple notes or copying information from softdocs or other documents. To activate new software on a target system, read the instructions delivered with the activation package.

The activation procedure varies depending on the system and products involved. In a varying order depending on the situation, activating software includes:

Printing the operator instructions.

Renaming the placed files to their actual names by running ZPHIRNM. When product files are first applied to (placed on) a target system, they are given

Host/Target Connection Activation Package Transfer to the Target System

Apply Request Initiator

Expand network

Across the Expand network. If the connection is not fast, tape transfer might be faster. See Comparing DSM/SCM Product Versions on page B-2.

Automatically started by Build/Apply

Network other than Expand

Write it to tape and manually deliver it, or write it to disk and transfer it using a file-transfer facility. All activation package files are unstructured, so FTP transfer is simple.

Operator starts on target system

None Write it to tape and manually deliver it. Operator starts on target system


Managing Software With DSM/SCM Activating the New Software on the Target System

temporary file names so they do not interfere with any existing versions of the software. This helps minimize downtime for your applications.

Activating the new software on the target system. This can involve a variety of steps including updating firmware, performing a system load, and starting and stopping applications at certain times.

After you follow the operator instructions, your new software is configured and ready to run on the target system. For more information about activating software, see Section 10, Activating New Software on a Target System.


7Receiving and Managing Software Inputs

This section describes how to receive the software (input) into the DSM/SCM archive. A software input consists of one or more products from HP, customer, or third-party software on either disk or tape. When software is received, the files from each product are stored in the archive, and the file attributes are stored in the database.


Preparing to Receive Software on page 7-2

Receiving Software Into the Archive on page 7-3

Managing Software Inputs on page 7-9

After you receive the software, proceed to Section 8, Creating and Managing Software Revisions.


Receiving and Managing Software Inputs Preparing to Receive Software

Preparing to Receive Software

Define Product Attributes for Third-Party Products

For a third-party product with no A0CINFO file, you must use the CNFGINFO tool to create one before receiving the product into the DSM/SCM archive. For more information on using CNFGINFO, see Appendix C, Running CNFGINFO.

Determine the Current SYSnn

1. From a TACL prompt, determine the current SYSnn :

> status 0,0

2. Note the SYSnn. You need it if you back out a revision.

Save the Existing Configuration Database

HP highly recommends that you save the existing configuration database before each time you use DSM/SCM to receive software. You need the saved configuration if you later need to back out to a previous revision.

From the host:

1. At the TACL prompt:

a. List the saved configuration files:

> FUP INFO $SYSTEM.ZSYSCONF.CONF*

b. Run SCF

> SCF

2. Save the current configuration:

-> SAVE CONFIGURATION xx.yy

Define xx and yy as you like. One option is for xx to reflect a major configuration change and yy to reflect a minor configuration change.

This message appears:

The configuration file $SYSTEM.ZSYSCONF.CONFxxyy has been created.

If you specify an existing configuration file, SCF asks if you want to replace it. If you do not want to replace it, you must repeat the Save procedure with a new file name.

3. Exit SCF.

Note. All received software files must have an associated A0CINFO file. HP always includes an A0CINFO file with its software, but third-party software might not.


Receiving and Managing Software Inputs Receiving Software Into the Archive

Log On to DSM/SCM

1. Log on to DSM/SCM using the DSM/SCM user ID. For more information, see Starting and Stopping DSM/SCM on page 2-2.

2. On your host PC, start the Planner Interface.

3. Log on to the Planner Interface using the super ID (255, 255) or a planner ID. The Planner Interface displays the Software in Archive and Configuration Revisions windows. The Software in Archive window lists the software currently in the DSM/SCM archive.

Receiving Software Into the ArchiveThe planner performs these steps to receive the product files into the DSM/SCM archive on the host system. Repeat these steps for all the software inputs being received. Inputs that you receive remain in the archive until you explicitly delete them or back them up; see Backing Up a Software Input (ZPHIHMI) on page 17-22 and Deleting a Software Input (ZPHIHMI) on page 17-23.

To receive software into the archive:

1. Determine the tape or disk location of the software input to be received. If you do not use the default location specified in the configuration profile, you need this information later to specify the input source. For example:

$TAPE1

\OAK.$TREE.ACORN

2. In the Planner Interface, click the Software in Archive window to make sure it is the active window.

The Software in Archive window lists the software inputs currently in the DSM/SCM archive. For each software input, the display shows the name, date of entry into the archive, and the names of any software input groups you defined. If an SPR on a tape is received into the archive, DSM/SCM uses the name of the first SPR as the default.

If the software inputs list is initially empty, select Window>Refresh to update the list to include all inputs received into the archive.

To restrict the list or change the order of inputs in the list, see Limiting the Software Inputs to Display on page 7-10.



3. From the Software in Archive window, click Receive software. DSM/SCM displays the Receive Software Request dialog box:

4. From the Receive Software Request window:

a. Enter the information as needed. See Table 7-1, Receive Software Request, on page 7-5.

b. Click OK.

VST082.vsd



5. Check the status of the request. See Checking the Status of the Request on page 7-8. The time required for the software to be received depends on how many files are copied. When the software input is received successfully (indicated in the

Table 7-1. Receive Software Request

Parameter Action

Request description

Enter a description of the software input. For example:

\CHINOOK TARGET1 2000-02-28:15:03 G06.07, YG

\host_name targetname date, RVU, planner initials

This description appears in the Request Status window whenever you check the status of this request.

Software name

Select either one:

Determine from incoming data to accept the default name that DSM/SCM assigns. For example, DSM/SCM determines the SUT name from information on the tape. For multiple SPRs, DSM/SCM uses the name of the first selected SPR.

Provided by planner to enter a name that reminds you what is in the input.

If you are installing third-party products or prefer to provide your own name for the software input, specify the name of the software input by clicking Provided by planner and enter the input name in the box.

Receive Options

You can choose to receive only changed files or all files. HP recommends that you choose to receive only changed files. Select either one:

Receive only changed files to receive only files in the software input that are new or have been modified.

Receive all files to receive all files from the software input into the host archive. Any identical files received from earlier inputs are overwritten. Old archive files that are being replaced are not purged until after the new files are archived. Therefore, you need enough archive disk space to hold all the files in the input.

Receive all files can take a considerable amount of time. Use it only if:

You suspect a problem with the files currently in the archive

You are replacing compressed files with uncompressed files (or vice versa)

You are recovering archive files that were accidentally deleted

Options Click Input source to indicate that the software is being received from a different location than the tape drive listed in the Configuration Manager profile. To use a different tape drive or disk drive, see Specifying the Location of the Software Input Source on page 7-6.

Depending on the number of software changes, the request might take several hours. If you do not specify a time, the request runs immediately by default. Click Scheduling to change the time when the request is scheduled to run. See Scheduling a Time to Run a Request on page 7-7.


Receiving and Managing Software Inputs Specifying the Location of the Software Input Source

EMS Events or Status windows), close the window. The Software in Archive window shows the newly received software products.

6. If you are installing third-party products, delete the distribution subvolume because the software it contains is in the archive.

After the software has been received into the archive:

Manage the software in the archive. See Managing Software Inputs on page 7-9.

Proceed to Section 8, Creating and Managing Software Revisions, to create a new software revision.

Specifying the Location of the Software Input Source

To indicate that the software is being received from a location other than the default specified in the configuration manager:

1. Click Input source.

DSM/SCM displays the Request Source Options dialog box. Tape drive is the default.

:

VST083.vsd


Receiving and Managing Software Inputs Scheduling a Time to Run a Request

Specifying a Tape Location as the Input Source

If the software is on tape:

1. In the Request Source Options dialog box, click Tape drive if it is not already selected.

2. To override the default tape drive, enter the tape drive name in the Tape drive field or select a drive from the scrollable list of host tape drives.

3. If the tape has an external physical label, enter the ID in the Optional external tape ID field. This is not a standard tape label written to the tape. It is an optional handwritten label for visually identifying a tape.

4. Click OK.

Specifying a Disk Location as the Input Source

Distribution subvolumes (DSVs) are subvolumes used as input sources. Each DSV must contain an A0CINFO file that describes the files in the subvolume. See A0CINFO Files on page D-7. If the software is on disk:

1. In the Request Source Options dialog box, click Volume.subvolume.

2. Enter the names of all subvolumes containing the input. To update the list, use the Add and Remove buttons. Use the ? and * wild-card characters to signify a single or multiple characters, respectively. For example:

\OAK.$TREE.?EAF could get \OAK.$TREE.LEAF

\OAK.$TREE.AC* could get \OAK.$TREE.ACORN

3. Click OK.

Scheduling a Time to Run a Request

If you are installing a SUT, the Receive Software request might take several hours to complete depending on the options you chose in the Receive Options field, the number of files being received, and the type of system you are running.

To schedule a request:

1. Click Scheduling. DSM/SCM displays the Request Scheduling Options dialog box.

2. Schedule the request:

To run the request immediately, the default option:

a. In the Request Scheduling Options dialog box, click Now if it is not already selected. (Now is the default selection.)

b. Click OK.

To schedule the request to run later:


Receiving and Managing Software Inputs Checking the Status of the Request

a. In the Request Scheduling Options dialog box, click Later.

b. In the appropriate fields, enter the date and time for the request to start.

c. Click OK.

To view other options, see Checking Requests on page 16-3.

Checking the Status of the Request

1. Check the status of the request in the status window DSM/SCM displays.

If you close the status window, you can reopen it later by selecting Requests> Requests list... and double-clicking the request. Processing is not interrupted.

2. To check the EMS messages, click the Show EMS Events. DSM/SCM displays the EMS Events window:

If you are installing a SUT, check the EMS messages to see if a new cartridge on a nonautoloading drive of the RVU needs to be mounted.

VST084.vsd

VST057.vsd


Receiving and Managing Software Inputs Managing Software Inputs

The number in quotes is the EMS message number. If you receive an error, see the DSM/SCM Messages Manual for cause, effect, and recovery information. For troubleshooting, see Software Configuration Troubleshooting on page 13-11.

3. After the status display indicates that the request is complete, select Window> Refresh.

4. Close the status window after you finish checking the request status.

Managing Software InputsTo manage your software inputs in the archive, you can perform these tasks:

Changing the Software Input Description on page 7-9

Managing Software Input Groups or Product Groups on page 7-11

Exporting Files From the Archive on page 17-24

Listing Products in a Software Input on page 8-6

Listing the Product Files in a Product on page 8-7

Changing the Software Input Description

To help track and manage your software inputs, you can change the name and description of any software input in the archive:

1. Select an input name in the Software in Archive window.

2. Select File>Show software input description. DSM/SCM displays the Software Input Description dialog box:

VST087.vsd


Receiving and Managing Software Inputs Limiting the Software Inputs to Display

3. Make changes as needed:

To change the software input name, enter a new name in the Software name field.

To change the software description, enter up to three lines of text in the Description field.

4. Click OK.

Limiting the Software Inputs to Display

The list of software inputs in the Software in Archive window might become extensive. You can limit which software inputs are displayed in the Software in Archive window to make them easier to locate and maintain. For example, you can restrict the display to inputs received in a particular date range or from a particular vendor.

To limit the software inputs displayed in the Software in Archive Window:

1. In the Software in Archive window, select View>View software by.

DSM/SCM displays the View Software in Archive By dialog box::

2. Select the check box for one or more of these items and enter or select the specific information:

Inputs received within a specific date range

A specific software input type

Inputs for a specific vendor

Inputs received by a specific planner

3. Click OK.

After you select a combination of inputs, DSM/SCM displays a summary of your input choices at the top of the Software in Archive window.

VST086.vsd


Receiving and Managing Software Inputs Managing Software Input Groups or Product Groups

Managing Software Input Groups or Product Groups

You can group archived software inputs or products before building a software revision. Grouping lets you work with a single, named entity instead of separately manipulating several inputs or products. Groups are useful for bundling:

Related inputs, such as a product and all of its SPRs

Requisite products, ensuring that when you copy the product to a software revision, all required products are copied with it

Related products, such as all SQL or all communications products

Related SPRs (that is, SPRs that are requisites of one another)

You can create a group containing either software inputs or products, but not both. Because you create them, groups do not necessarily represent any software grouping in a configuration. Products and inputs can belong to more than one group. To share groups with other planners, you must indicate Shared for Software Product Group type when you install the Planner Interface. See Task 2: Install the Planner Interface on the PC on page 4-7.

Creating a Software Input Group

To create a new group containing selected software inputs or products:

1. In the Software in Archive window, click Show inputs by group. The button name (and function) changes to Show by inputs.

2. Select one or more software input names by doing any of:

Click software inputs in the list while holding down the Control key.

Use the Find command to search for the first software input containing your search string, regardless of whether it is already selected.

Use the Find-Next command to search for the next available input after the last found using a previous Find or Find-Next command.

3. Select Groups>Form group....

4. Enter the name of the new group in the New group name field.

5. Click OK.

Note. Planners can see only the groups they have defined because group information is stored in the SWINPUTS.DAT and PRODUCTS.DAT files on the PC of the planner who created them. To share groups among planners, define the groups on one PC, then copy both files to the PCs of the other planners. After the Shared option has been selected, the definition of software groups and the adding of members to those groups is stored in table PHIH90B in the Host database so that all users of the Planner Interface have a shared view of these groups



Creating a Product Group

To create a new group containing selected products:

1. Display a list of products by doing one of:

In the Software in Archive window, double-click an input.

In the Software in Archive window, select an input; then select Products>List products....

In the Configurations Revisions window, double-click a revision to open it.

In the Configuration Revisions window, select a revision and click New software revision....

2. Click Show products by group. The button name (and function) changes to Show by products. (It might already be changed.)

3. Select one or more products.

4. Select Groups>Form group....

5. Enter the name of the new group in the New group name field.

6. Click OK.

Checking Existing Groups

You can check all software input or product groups you defined:

Groups are listed alphabetically.

Groups are listed together on top of the list.

Inputs in a group are listed in descending order of date received. For example:

G06.00+SPRs SPR T9050 G03 AAA 1999-11-04 RVU G03.00 1999-10-31

T6002 SPRs SPR T6002 G03 AAC 1999-12-12 SPR T6002 G03 AAB 1999-11-25 SPR T6002 G03 AAA 1999-10-15

The order of input groups might change each time you add a new member to a group.

Products displayed by name are listed in the order specified in the View Products By dialog box. For more information, see View Product By Dialog Box on page 8-7.

Inputs that do not belong in a group are listed from the most recent software received on top to the oldest software received.



When only certain inputs (such as SPRs) are displayed, some input groups that actually have members might appear empty if they do not contain any of the selected input types, and others might appear to be missing members. You specify the inputs to display from the View Software By dialog box. See Limiting the Software Inputs to Display on page 7-10.

In the Input Group List and Product Group List dialog boxes:

Product group members are listed in alphanumeric order by product name.

Input group members are listed in descending order of date received.

To select a group, click the group name to select all the members of that group. You can open the group and select or deselect single items in the group.

Checking Groups

The text in the Planner Interface buttons depends on the type of group: input or product. To view all software input or product groups you defined and, when a group is open, all products that are members of that group:

1. In the Software in Archive window, click Show inputs/products by group. The display changes to include, in alphabetical order, the names of any groups you have defined, with group members indented under the group name.

The Show inputs/products by group is a toggle. Clicking Show inputs/products by group, changes the name to Show by inputs/products. Clicking Show by inputs/products returns the display to Show inputs/products by group.

2. Select Groups>Input/Products groups list.... DSM/SCM displays the Input/Product Group List dialog box, which lists the input or product groups you have defined. To show:

The members of a group, select one or more groups; then click Expand groups.

Only the group name, select one or more groups; then click Collapse groups.

A plus sign (+) preceding a group name indicates that the group has members. A minus sign (-) indicates that the group is expanded to show its members.



Managing Group Members

You can add and remove inputs or products from groups and control how group members are displayed.

Displaying and Hiding Members of a Group

To list all the members of an input or product group in the Software in Archive window or any other window that lists software inputs or products:

1. Click Show inputs by group or Show products by group. DSM/SCM displays the group names. (If the button reads Show by inputs or Show by products, it is already toggled.)

2. Select one or more group names.

3. Select Groups>Expand groups.

To hide group members so only group names are shown, select Groups>Collapse groups.

Adding Members to a Group

To add software inputs or products to a previously defined group:

1. In the Software in Archive window or any window that lists product groups, click Show inputs by group or Show products by group. This button might already be toggled.

2. Select one or more inputs or products.

3. Select Groups>Add member to group. DSM/SCM displays the Add Member to Group dialog box:

4. From the list of group names, select the group.

5. Click OK.

VST089.vsd



Removing Members From a Group

You can remove software inputs or products from the group containing them. You can remove the same member from several groups, different members from one group, or different members from several groups:

1. In the Software in Archive window or any window that lists products, click Show inputs by group or Show products by group to toggle it to Show by inputs or Show by products. (This button might already be toggled.)

2. If the group containing the member to be removed is unopened, double-click the group to open it. The window displays the group members.

3. Select the group member to be removed.

4. Select Groups>Remove member from group.

Disbanding a Group

You can disband any group you have formed, thereby removing all of its members, deleting the group name, and returning the members to their appropriate sequence in the list of inputs or products:

1. In the Software in Archive window or any window that lists products, click Show inputs by group or Show products by group to toggle it to Show by inputs or Show by products. This button might already be toggled.

2. Select one or more group names.

3. Select Groups>Ungroup.

Note. After you remove a member from a group, it returns to the list of members and groups in the appropriate sequence. However, if it belongs to another group, it is listed only in that group.

Note. After you disband a group, members are returned to the list of members and groups in the appropriate sequence. However, if the member belongs to another group, it is listed only in that group.


8Creating and Managing Software Revisions

A software revision is a list of products stored in the archive that together are built into a configuration revision. After you receive all required inputs in the DSM/SCM archive, plan and create a new software revision for the target system.


Checking Product Information on page 8-2

Creating Software Revisions on page 8-15

Managing Software Revisions on page 8-22

After you create a new software revision, proceed to Section 9, Building and Applying a New Configuration.


Creating and Managing Software Revisions Checking Product Information

Checking Product InformationBefore creating a software revision, check that all products you plan to include are compatible with each other and that all requisite SPRs are accounted for.

Checking the Contents of Distribution Subvolumes

For a DSV received into the DSM/SCM archive, you can use the Planner Interface to view:

Release Read Me files

Softdocs

Software in the archive

Information about target software configurations

You cannot use the standard Guardian utilities or the file system to view or move files stored in the archive. The files are given unique internal file names and might be reformatted and compressed to conserve disk space.

Checking for Recommended Software Product Revisions (SPRs)

Use the SPRCHECK command line tool to confirm whether the recommended SPRs for your current configuration are installed on the system. SPRCHECK checks the DSM/SCM history file (syshnnnn) and compares it to a Support Note for your RVU.

To download a Support Note to your NonStop server, locate it using Scout for NonStop Servers. To access Scout through NonStop Onepoint, go to https://onepoint.nonstop.compaq.com/buildpage.asp. For more information, see Support Note S02077.

When a new Support Note is released for your current RVU in Scout, run SPRCHECK against that Support Note to learn if there are any new recommended SPRs or SPRs for special consideration for the software in your configuration:

SPRCHECK provides information about SPRs on your system that were installed and are managed using DSM/SCM.

SPRCHECK does not provide information on any SUT-based software, Independent Products, or other software installed without DSM/SCM.

To run SPRCHECK, the Support Note must be in text format in either the old Support Note format or the new format introduced in October, 2001.


Creating and Managing Software Revisions Checking for Recommended Software Product Revisions (SPRs)

Running SPRCHECK



volume

is the volume containing the DSM/SCM TSV.

2. Run the SPRCHECK macro:

> RUN SPRCHECK [ OUT /out-file/ ] supnote sysh-file

out-file

is the printer, spooler, or file location to send the SPRCHECK output to. If omitted, SPRCHECK output appears on your screen.

supnote

is the Support Note for the RVU you are running. SPRCHECK uses this Support Note as the source for the list of recommended SPRs or SPRs for special consideration for which to check your system.

sysh-file

is the DSM/SCM history file (syshnnnn) on your system.

The organization of the SPRCHECK output depends on the version of Support Note being checked against. In both output formats:

Indentation of products is the same as in the Support Note.

The SPR listed is the requisite SPR for the RVU for which you are running SPRCHECK.

The SPRs are categorized based on critical need or potential significant benefits. The newer output separates SUT-based products and Independent Products.



When used with newer Support Notes, SPRCHECK output is similar to:

$DSMSCM ZDSMSCM 10> run sprcheck sprtest.S0108TXT sysh0001SPRCHECK v2.3 (2001-11-12)

Configuration Name: \NSSD2 DEFAULTConfiguration Revision: 2 Software Release: G06.15 Apply Date: 2001-12-06:02:59:51 Site Id: 000003 System Name: \NSSD2 Logical Target Name: DEFAULT

Prod Prod BASE UPDT

A. SPRs for SUT-based Products

1. Install to avoid potential critical problems

T0017G03 AAF A WAN ENVASCT0018G03 AAH A WAN ENVBSC (HS:AAG HS02668)T0051G02 AAC A CSSLAPB-X21 DRIVER (OPN:AAB HS02663)T0470G06 AAI A TCP/IP MONITOR PROCESS T0468G06 AAG A TCP/IP MANAGER PROCESS T0469G06 AAI A TCP/IP SRL

2. Install for potential significant benefit

T8343D42 ABO A PATHWAY/TST8472G04 ACA A SMLOGVOL T0063G04 ACA A SMINTRFCE T8465G04 ACA A SMMASTR T8466G04 ACA A SMPOOLT8626G05 ABD A OSSUTIL - OSS UTILITIEST8932D48 ABC A FASTPTCP

B. SPRs for Independent Products

1. Install to avoid potential critical problems

T7981V61 AAN A RSC/MP WIN32T8996V40 ABD A ITP WEBSERVER T8996V40 ABD A ITP WEBSERVERT9711V61 ACE A RSC/MP HOST (OPN HS02560)

2. Install for potential significant benefit

T8996V40 ABD A ITP WEBSERVER T8996V40 ABD A ITP WEBSERVERT8353D44 AAC A NS TUXEDO /T DOMAINS GATEWAY



When used with older Support Notes, SPRCHECK output is similar to:

$DSMSCM ZDSMSCM 9> run sprcheck sprtest.S9908TXT sysh0001SPRCHECK v2.3 (2001-11-12)

Configuration Name: \NSSD2 DEFAULTConfiguration Revision: 2 Software Release: G06.15 Apply Date: 2001-12-06:02:59:51 Site Id: 000003 System Name: \NSSD2 Logical Target Name: DEFAULT

Prod Prod BASE UPDT

Section 1.0 - Consider installing to avoid potential critical problems

T0021G05 AAP A TAPEPROCESS (OPN, HS02518/2539) T8306G00 AAQ A OSS SOCKETS) T8375F40 AAU A QIOLIBT0229G06 AAE A TITANIUMT1089G05 AAY A S-SERIES SP FWT1097G01 AAB A WANEXPLAPB T9057G06 AER A EXPAND

Section 2.0 - Consider installing for potential significant benefit

T0010G02 AAD A LDSTT0039G03 AAC A WAN 3270 T9371G03 ABW C AM3270-610XT0040G03 AAB A WAN 3271

Section 3.0 - Consider installing for maximum benefit

T9640G03 ABD A VIEWPOINTT9752G05 ABB A SPI T0063G04 ABV A SMINTRFCE T2076D46 ADJ A NS TM/MP UTILITIES


Creating and Managing Software Revisions Listing Products and Product Files

Listing Products and Product Files

Check all information provided about the products in existing revisions and in new inputs. You can list:

The products in a software input or in a revision

The product files in a software input or in a specific product

Listing Products in a Software Input

To list the products in a software input :

1. From the Software in Archive window, do one of:

Double-click a software input name.

Select a software input name and select Products>List products.

2. Optionally, you can:

Change the display order or limit the processor types displayed of products in the software input. Select View>View products by. DSM/SCM displays the View Product By dialog box. See View Product By Dialog Box on page 8-7.

Check the product files. See Listing Product Files in a Software Input on page 8-7.

Listing Products in a Revision

List the products in an existing revision:

1. From the Configuration Revisions window, do one of:

Double-click a configuration

Select a configuration and click List products.

DSM/SCM displays the list of products in the configuration, which includes each product’s name, number, base version, RVU release ID or base SPR number, and applied SPRs.

2. Optionally, you can change the display order of the products in the revision. See View Product By Dialog Box on page 8-7.


Creating and Managing Software Revisions Listing Products and Product Files

View Product By Dialog Box

You can list products by processor type, product name, or product number.

1. Select View>View products by. DSM/SCM displays the View Products By dialog box.

2. Select the processor type and sort order:

To display products by processor type, select TNS for CISC processors, TNS/R for RISC processors, TNS/E for Intel Itanium® processors, or ALL for all processors.

To display products in name order, click Product name.

To display products in number order, click Product number.

3. Click OK.

Listing Product Files in a Software Input

1. To list the product files, do one of:

Double-click the product name in the product list.

Select a product name in the product list, then select Products>List files.

2. Optionally, you can change the display order of the product. See View Product By Dialog Box on page 8-7.

3. Click OK.

Listing the Product Files in a Product

To list the product files in a revision:

1. Select a product in the software revision.

2. Select Products>List files. DSM/SCM displays the Files dialog box. See Files Dialog Box on page 8-7.

Files Dialog Box

The Files dialog box displays the product number, product version, type of software, processor category, filename, and fingerprint.


Creating and Managing Software Revisions Checking the Product Version Details

To export files from the product version, select files to export, click Export. See Exporting Files From the Archive on page 17-24.

Checking the Product Version Details

The version details include the base version of a product in a specific software revision and all SPRs applied to it.

To check the version details of a product.

1. Select a product in the software revision.

2. Select Products>List version details.

DSM/SCM displays the Version Detail dialog box.

VST091.vsd


Creating and Managing Software Revisions Checking the Product Version Details

Product number and base version ID

Base release—RVU ID (if the base product was received on a SUT) and the last SPR applied (if any) to the product

Base SPR

Archive source—Name of the software input on which the base product was received

Each SPR applied to the product and the name of the input (archive source) containing the SPR

Listing the Files in an SPR

From the Version Detail dialog box:

1. Select an SPR.

2. Click List files.

Checking the Software Revision Notes for an Existing Revision

Revision notes document site-related information about a revision, such as problems the revision solved or reasons an SPR was applied. The planner enters revision notes when creating the software revision. Each time a new revision is created from the current one, the planner should add to the notes, creating a history of the software revision.

1. In the Configuration Revisions window, select a configuration revision.

2. Select File>Show revision notes....

VST092.vsd


Creating and Managing Software Revisions Checking Softdocs and Release Documents

Checking Softdocs and Release Documents

Check the product changes and dependencies to learn of any issues that might affect your software configuration.

The softdoc for each NonStop product describes new features, corrected problems, and remaining known problems. It also gives the product name and number; the required hardware, firmware, and software; and the names of product manuals. You can view and print softdocs one of two ways:

Use the HP NonStop Technical Library (NTL) before installing the software.

Use the Planner Interface to view or print softdocs included with the software you are installing.

Release documents on the SUT include product dependencies and maintenance levels, performance information, and a list of SPRs applied to products in an RVU.

Use the Planner Interface to view release documents located on the SUT.

Use the HP NonStop Technical Library (NTL) to view release documents that are not located on the SUT such as the Interactive Upgrade Guide 2, the Gxx.xx Software Installation and Upgrade Guide, and the Hxx.xx Software Installation and Upgrade Guide.

For information about reports generated by DSM/SCM, see Section 18, Generating DSM/SCM Reports.

Viewing a Softdoc

1. Select an SPR. See Checking the Product Version Details on page 8-8. From the Version Detail dialog box, select an SPR.

2. Prepare the softdoc for either printing or online viewing.

Preparing Softdocs

To prepare a softdoc for online viewing or printing:

1. Select products in one of these ways:

Select a software input in the Software in Archive window.

List the products in a software input or software revision; then select one or more products.

Select a product in a software revision; then select Products>List version details.

2. Select Requests>Prepare softdocs.

DSM/SCM displays the Prepare Softdoc Request dialog box.

3. To format the selected softdocs for printing:



a. Check the Print formatted output location check box if it is not already checked.

b. To print the documents to a location other than the default, enter a different spooler name in the output location field.

4. Checking the Revision History of a Software Configuration on page 8-13

Checking Softdocs for Products Changes

To check all the softdocs for products that changed between two configuration revisions:

1. From the Configuration Revisions window, open an existing target by double-clicking its name.

A window for the revision lists the existing software.

2. From the Software in Archive window, open the new software input by double-clicking its name.

A window for the input opens listing the software in the input.

3. From the window of the software input, select Select changes.

DSM/SCM highlights differences between the software input and the existing revision.

4. See Checking the Revision History of a Software Configuration on page 8-13.

Preparing Release Documents

Prepare release documents for either printing or online viewing:

1. In the Software in Archive window, select the input name of an RVU.

2. Select Requests>Prepare release documents.

DSM/SCM displays the Prepare Release Documents Request dialog box.



3. By default, all documents are selected. To clear any documents you do not want to print or view, Ctrl-click them. If needed, Ctrl-click the documents again to reselect them.

4. Prepare the release documents for either printing or online viewing:

To prepare the release document for viewing online:

a. Check the Viewable formatted file subvolume location check box.

b. To write the documents to a location other than the default, enter the subvolume name in the subvolume location field.

To prepare the release document for printing:

a. Check the Print formatted output location check box.

b. To print the documents to a location other than the default, enter a different spooler name in the output location field.

5. Schedule the request as needed. The default is for the request to run immediately. To change the default scheduling, see Submitting a Request on page 16-2.

6. Click OK.

DSM/SCM prepares and formats the document for printing or online viewing as scheduled and adds it to the list of prepared documents.

VST093.vsd


Creating and Managing Software Revisions Checking the Revision History of a Software Configuration

Checking the Release Documents

1. Format the selected documents for printing:

2. Checking the Revision History of a Software Configuration on page 8-13

Viewing the Document Online

To view the document online:

1. Select File>View prepared documents.

DSM/SCM displays a list of documents prepared for online viewing.

2. Select the release document from the list; then click View.

DSM/SCM displays the selected document.

3. Locate specific sections in the softdoc using the Find options in the View menu.

You can minimize a window displaying a document, which lets you quickly access the report at any time while decreasing the number of open windows.

Checking the Revision History of a Software Configuration

Before using an existing software configuration as the basis of a new software revision, check its revision history:

1. In the Configuration Revisions window, select a configuration revision.

2. Select File>Show revision history.

DSM/SCM displays the Revision History window.

Note. Documents formatted for viewing online are deleted from the list of viewable prepared documents at the end of the request retention period specified in the Configuration Manager profile. However, they remain in the subvolume they were written to. You must manually purge them from the subvolume.


Creating and Managing Software Revisions Checking the Revision History of a Software Configuration

Revision History Window:

1. From the Revision History window, select a revision.

2. Select Products>List products.

DSM/SCM lists the products in the software revision.

3. Click Show revision notes to display the notes describing the revision.

VST094.vsd


Creating and Managing Software Revisions Creating Software Revisions

Creating Software RevisionsOn the host system, the planner creates a new software revision identifying the products to install on the logical target.

1. From the Configuration Revisions window:

a. Select the logical target for which you are creating a new revision.

b. Click New software revision to copy the product list from the most recent revision to the new software revision.

2. From the Software in Archive window:

a. Select a software input containing the new software that was just received into the archive.

b. Click Copy to to copy all new and changed products in the software input.

DSM/SCM displays the Confirmation dialog box.

c. From the Confirmation dialog box, click Continue.

DSM/SCM displays the NonSUT Products dialog box so that you can retain independent products and third-party products that are not on the SUT.

3. From the NonSUT Products dialog box:

a. Click Select All to copy all products in the list from your current configuration to the new revision.

b. Click Continue.

If the Gxx SUT, which is being copied to, has both the heap manager products (T8431 and T1269), DSM/SCM displays the Heap Manager Selection dialog box.

4. From the Heap Manager Selection dialog box:

a. Select the desired heap manager (T8431 or T1269) that must be installed on to the target system.

b. Click Continue to copy the SUT (with the selected heap manager) to the new software revision.

c. Click Cancel to cancel the Copy to operation.

Note. The Heap Manager Selection feature is supported only on systems running G06.29 and later G-series RVUs.


Creating and Managing Software Revisions Task 1: Create a New Software Revision

Task 1: Create a New Software Revision

In most cases, you should create a new software revision based on the most recent revision. However, you can also create a new software revision based on an older revision on the same target system or another target system.

NonStop S-series systems and Integrity NonStop systems are shipped with an initial software revision that contains the RVU you ordered. When receiving a new system, use this initial revision as the basis of your first new software revision unless you use an existing revision from another target system.

1. From the Configuration Revisions window, select the logical target for which you are creating a new revision. The new revision is based on this configuration.

To use the most recent revision, click New software revision to copy the product list from an existing revision to the new software revision. See New Software Revisions Window on page 8-17.

To use an older revision on the same target:


2. In the Revision History dialog box, select a revision from the list.

3. Select File>New software revision.

DSM/SCM opens a New Software Revision window. New Software Revisions Window on page 8-17.

To use a revision on a different target:

1. Click New software revision.

DSM/SCM opens a New Software Revision window listing the products in the last software revision built for that particular target. See New Software Revisions Window on page 8-17.

2. In the Configuration Revisions window, select a configuration revision belonging to a different target.


DSM/SCM displays a list of the previous revisions for the selected configuration.

4. Select a revision from the list.

5. Click Copy to.

DSM/SCM deletes the contents of the new revision, then copies all products in the selected revision to it.


Creating and Managing Software Revisions Task 1: Create a New Software Revision

6. Click Copy to to copy the products to the new software revision if it is open.

New Software Revisions Window

After you select a revision, the New Software Revision window lists the products copied from the revision you selected. It might take several minutes for the products list to appear.


Note. The New Software Revision window indicates the new revision number. However, in the Configuration Revisions window, the revision number does not change until the new revision is built and applied. This revision is denoted with an asterisk in the Configuration Revisions window.

VST095.vsd


Creating and Managing Software Revisions Task 2: Copy Products to the New Software Revision

Task 2: Copy Products to the New Software Revision

You can modify the contents of a new software revision by copying products from a software input, revision, or group on any target to the New Software Revision window. DSM/SCM highlights products in the source when you select them. You can also delete products from the new software revision or copy:

All products from a particular source item

An entire software input from the archive

Individual products

Only products that changed in the source

Only products in the source but not the new revision

Products in both the source and the new revision

Products, including SPRs, from selected software inputs

Products from other software revisions

To copy products to the new software revision:

1. Check that a New Software Revision window is open.

2. Copy the products to the new revision:

a. From the Software in Archive window, select a software input containing the new software that you just received.

To copy all new and changed products, click Copy to.

Select Copy to when you are installing a SUT.

DSM/SCM selects the products in the RVU that are licensed for your configuration and copies them to the new revision, replacing all products already in the revision.

To copy only matching products that changed, select Edit>Copy matches to.

DSM/SCM displays the Confirmation dialog box.

b. Click Continue.

DSM/SCM displays the NonSUT Products dialog box.



c. To retain independent products and third-party products from your current configuration in the new revision:

Click Select All to include all products.

Select one or more products individually.

d. Click Continue.

If the Gxx SUT, which is being copied to, has both the heap manager products (T8431 and T1269), DSM/SCM displays the Heap Manager Selection dialog box.

Figure 8-1. Non-SUT Products Dialog Box

VST510.vsd



e. Select the desired heap manager (T8431 or T1269) that must be installed on to the target system.

Click Continue to copy the SUT (with the selected heap manager) to the new software revision.

Click Cancel to cancel the Copy to operation.

f. Select any other product, SPR, or product group to include in the new revision from the archive, software input, or revision. To select individual products:

From the Configuration Revisions window or the Revision History window, open a configuration revision.

From the Software in Archive window, open a software input.

g. Click Copy to for each item.

Figure 8-2. Heap Manager Selection Dialog Box

Note. The Heap Manager Selection feature is supported only on systems running G06.29 and later G-series RVUs.

Note. Periodically some product numbers are consolidated into fewer product numbers. Release documentation identifies these products when the consolidation occurs. Include only the consolidated product numbers in your configuration revision, not the obsolete numbers.

VST002.vsd


Creating and Managing Software Revisions Task 3: Check the Product Version Details of the New Revision

Task 3: Check the Product Version Details of the New Revision

From the New Software Revision window:

1. List the product files. See Listing Products in a Revision on page 8-6

2. Check the product version details (applied SPRs). Checking the Product Version Details on page 8-8.

Task 4: Edit the Software Revision Notes

To create revision notes for a new revision, DSM/SCM copies the notes from the configuration on which the new software revision is based. Edit these notes to reflect changes in the new software revision. Adding text to the existing notes creates a history of revisions to the software. To edit the revision notes:

1. In the New Software Revision window, click Edit revision notes. DSM/SCM displays a Revision Notes dialog box. The dialog box shows the notes previously entered for the revision on which the new one is based.

2. Add a description of the changes to the existing text.

3. Click OK.

After you update the software revision notes, proceed to Section 9, Building and Applying a New Configuration.


Creating and Managing Software Revisions Managing Software Revisions

Managing Software RevisionsAlthough not part of the normal procedure, you might otherwise need to save, close, cancel, or delete a new software revision, or delete a past software revision.

Saving a New Software Revision

If you leave the Planner Interface before building and applying the new revision, you must save any changes you make to the new revision. If you build and apply the new revision immediately, you do not need to save changes. Submitting a Build/Apply request automatically saves changes.

To save the changes you make to the new revision, click Save or select File>Save Revision.

The save operation can take several minutes, depending on the number of changed products.

Closing a New Software Revision Window

To close a new software revision window:

1. Select File>Close revision. DSM/SCM displays a dialog box asking if you want to save any changes.

2. To save changes before closing the revision, click Save.

The save operation can take several minutes, depending on the number of changed products.

Canceling a New Software Revision

For the currently open new software revision, you can cancel all changes made since the last time it was saved.

When you cancel a new revision, DSM/SCM closes the New Software Revision window and leaves the new software revision unchanged. All record of changes you made since the revision was last saved until you canceled is lost and cannot be recovered.

To cancel a new software revision:

1. In the New Software Revision window, click Cancel revision.

DSM/SCM displays a dialog box warning that unsaved changes will be discarded.

2. Click one of these buttons:

Continue To cancel the revision

Cancel To cancel the cancellation (and continue with the revision)


Creating and Managing Software Revisions Modifying the New Revision

Modifying the New Revision

You can modify the new software revision by adding or deleting new products or inputs, individually or by group. These changes update that product’s display. SPRs are added to the product. A new base version replaces the product.

For example, if you add two SPRs, ADD and ADG, to a software revision originally containing the product PROD1 received on a G05.00 RVU, the display shows the base version plus the applied SPRs:

PROD1 T9000G01 G05.00()+ADD+ADG

DSM/SCM cannot break out SPRs rolled into a new base component. In this example, if the PROD1 SPRs were rolled into the next RVU for PROD1 (G05.01) and the planner makes a new revision of the software by including this new PROD1 version, DSM/SCM displays only the last SPR (base SPR) rolled into that version:

PROD1 T9000G01 G05.01(ADG)

To modify the new software revision, use these options in the Edit menu:

Select option Action

Select all Selects all products in the open input or revision.

Select matches Selects products in the software input or revision with matching products in the new software revision.

Select changes Selects products in the software input or revision with matching products in the new software revision, if the products changed.

Copy matches to

Selects products in the software input or revision with matching products in the new revision, then copy any changed matching products to the new revision.

Select additions Selects products in the software input or revision that are not in the new software revision.

Copy to Copies all selected products in the source revision or software input to the new revision:

Products in both the source and new revision are copied from the source to the new revision.

Products only in the source are added to the new revision.

If you use this option for a full RVU, DSM/SCM assumes you are migrating to a new RVU and warns you that the current contents of the new revision will be deleted and that all products listed in the target system’s CUSTFILE will be copied to the new revision. You must retain any products not on the SUT (such as third-party or customer software or SPRs) to the new revision. If the SUT, which is being copied to, has both the heap manager products (T8431 and T1269), DSM/SCM also displays the Heap Manager Selection dialog box. This feature is supported only on systems running G06.29 and later G-series RVUs.


Creating and Managing Software Revisions Deleting a New Software Revision

Deleting a New Software Revision

After you delete a new software revision from DSM/SCM, you cannot recover it. To delete a new software revision:

1. In the Configuration Revisions window, select a configuration revision for which a new software revision exists (indicated by an asterisk [*] next to the configuration name).

2. Select File>Delete revision.DSM/SCM displays a dialog box asking you to continue with or cancel the deletion.

3. Click Continue. DSM/SCM deletes the new software revision.

Deleting Products From a New Software Revision

1. In the New Software Revision window, select one or more products.

2. Select Products>Delete product, or press the Delete key.

Deleting Old Software Revisions

You can delete individual software inputs only if a configuration revision is not using them. To delete any software input, you must delete all software revisions that link to it. Delete a software revision only if you are certain that you will never need that specific software revision again.

You cannot delete a current revision or previous software revision:

A current revision is the last configuration whose state is applied.

A previous revision is the second to last configuration whose state is applied.

To delete an entire software configuration, which removes all of its revisions, see Deleting a Software Configuration (ZPHIHMI) on page 17-23.

You cannot delete any configuration more recent than the two revisions. For example, in this Revision History window, you cannot delete software revisions 17 through 19.


Creating and Managing Software Revisions Sharing Software Revisions

To delete an old software revision:

1. In the Configuration Revisions window, select the logical target containing the software revision to delete.

2. Select File>Show Revision History. DSM/SCM displays the Revision History window.

3. Select the revision to delete.

4. Select File>Delete revision. DSM/SCM displays a dialog box asking you to continue with or cancel the deletion.

5. Click Continue. DSM/SCM deletes the software revision.

Sharing Software Revisions

You can share software revisions among planners in the same planner group. Planners can submit a Build/Apply request for new shared software revisions created by any planner belonging to the same planner group.

VST096.vsd



This Configuration Revisions window shows various configuration revisions for each target:

The asterisk (*) indicates that a new software revision you created was defined for the target and is waiting for you to build it. The @ symbol indicates that a new software revision created by a planner in the same planner group as you was defined for the target but is not built. Because you belong to the same planner group, you can submit a Build/Apply request for any revision preceded with @.

If Clone Groups exist, a Clone Group column is inserted in the Configuration Revisions view. For detailed information, see Display of Masters and Clones on page 19-4.

Creating a Planner Group

1. Select Maintain>Security Maintenance>Planner List....

2. In the Planner List, select a planner user ID to be included in the new group.

3. Select Group>Form Group....

4. Enter the new planner group name, up to 20 alphanumeric characters and spaces.

5. Click OK.

Note. You cannot see new software revisions created by planners outside your planner group.

VST112.vsd



Adding Members to a Planner Group


2. From the Planner List, select a planner user ID to add to an existing planner group.

3. Select Group>Add member to group....

4. Scroll through the list of group names and select the one to add a member to.

5. Click OK.

Removing Members From a Planner Group


2. From the Planner List, select a planner user ID to remove from a planner group.

3. Select Group>Remove member from group.

Deleting a Planner Group


2. From the Planner List, select the planner group to delete.

3. Select Group>Ungroup.


9Building and Applying a New Configuration

After creating a new software revision, build a new configuration revision. You create a package containing information about all the products listed in your new software revision and transfer it to the target system where the software is placed during the Apply process.


Build Types on page 9-2

File Locations on page 9-3

Creating a Configuration Revision on page 9-4

Preparing for a Build and Apply Request on page 9-4

Task 1: Initiate the Build/Apply Request on page 9-8

Task 2: Indicate a Build/Apply or Build Request on page 9-10

Task 3: Specify the SYSnn Subvolume on page 9-11

Task 4: Set the Options for the Build and Apply Request on page 9-12

Task 5: Schedule the Request on page 9-22

Task 6: Edit the Instructions on page 9-23

Task 7: Submit the Request on page 9-24

Task 8: Apply Software to the Target System on page 9-25

Task 9: Transfer and Receive the Snapshot Into the Host Database on page 9-27

If you are building and applying a new configuration for a Clone Group, see Building and Applying a Clone Group Configuration Revision on page 19-5.

After completing this section, proceed to Section 10, Activating New Software on a Target System.


Building and Applying a New Configuration Build Types

Build Types Normal Build/Apply on page 9-2

Initialization Build/Apply on page 9-2

FRABIBAB on page 9-3

Normal Build/Apply

In most cases, you perform a normal build and apply. This is required to migrate to a new RVU.

Initialization Build/Apply

When you initiate the Build/Apply from the Initialize target system dialog box, DSM/SCM displays the Indicate Type of Build window instead of the Build/Apply Request window.

Full Activation Package

DSM/SCM applies all the software in the activation package on the system regardless of what is already there. A normal Build/Apply applies only files that are different from the existing software configuration. Consequently, a full activation package is large and takes a long time to configure.

However, if the full activation package contains a configuration similar to the existing configuration on the target, the time might be greatly reduced by file adoption. Any existing files that match new files are adopted, rather than reinstalled, reducing installation time.

Existing files that are not adopted are renamed and available only if you back out. DSM/SCM manages only the files in this full activation package. It does not manage any existing files that were not adopted. Also, if the new and existing configurations are not similar, check that enough disk space is available on the system to place what is effectively a second complete software configuration on your system.

Initialization Package

You cannot migrate to a new RVU using an initialization package.

An initialization package synchronizes the host database with what is actually on a target system. DSM/SCM compares the currently existing software on the system with the software configuration you created. It does not modify the software configuration on the target system. No activation package files are applied to the target system.

A discrepancy report shows the differences between the currently running software and the software just configured. Evaluate the report and determine which discrepancies are acceptable and which need to be resolved. After you are satisfied that the discrepancies will not cause operational problems, you can perform a full


Building and Applying a New Configuration FRABIBAB

Build/Apply. You do not need to resolve all discrepancies before accepting them, but you will have a record of the differences in the software configuration in case of problems. Before accepting the discrepancies, you can add SPRs or additional software as needed.

Use the activation package files only to compare against target file names to determine if discrepancies exist between what is listed in the software revision and what is actually on the target system. This lets DSM/SCM establish a baseline of what files are on the system so that it can send only changes on subsequent Applies.

On the first Build/Apply after applying an initialization package, DSM/SCM always runs the system generation program to ensure the host system has an OSIMAGE that corresponds to what is on the target system.

You can run an Initialization Build/Apply only once on a physical target system. To run another, you must delete all logical targets or initialize DSM/SCM.

To see which files are different when you start managing OSS files, you must perform a regular Build/Apply and run ZPHIRNM in Preview mode. If you are starting to manage OSS files with DSM/SCM, an Initialization Build/Apply is not necessary. You cannot run an Initialization Build/Apply when you start managing OSS files on a target that is managed by DSM/SCM.

FRABIBAB

First Real Apply Build, Initial Build Apply Bypass (FRABIBAB) bypasses the initialization Build/Apply and performs a normal Build/Apply on the target. The procedure is no different from a normal Build/Apply except that it carries implications on your system configuration such as this file ownership issue. To perform FRABIBAB, the DSM/SCM user ID must be the super ID (255,255). Otherwise, you might not be able to start DSM/SCM after the system load.

File LocationsDSM/SCM places files during an apply in a target subvolume (TSV) or target directory location (TDL).

Target Subvolume (TSV)

When DSM/SCM places Guardian files during an Apply, and a different version of the file already exists in the TSV, the file is placed under a temporary name of the form ZFBccncc. Do not purge these ZFB* files. They are deleted in normal DSM/SCM processing.

Multiple copies of changed files might be in the TSV at a given time. TSVs might contain Guardian files under both their actual names and their temporary names, requiring more disk space for software on target systems. Do not purge these files. DSM/SCM deletes them when possible.


Building and Applying a New Configuration Creating a Configuration Revision

Because only changed files are sent in most Apply requests, the number of temporary files is representative of the number of changes made to the TSV in the last Apply.

Target Directory Location (TDL)

DSM/SCM places packaged OSS files that it manages in a TDL on a logical target. Unlike a TSV, a TDL specifies an absolute path. You cannot control the location of a TDL. For example, you cannot copy or move a TDL to another location. DSM/SCM manages OSS files in a TDL only.

Creating a Configuration RevisionThe Build creates a new configuration revision that includes:

The product versions named in the new software revision

A new operating system image if required. DSM/SCM runs system generation accordingly.

New SRL files or DLL files

Profile information, including the TSVs (for Guardian files) and TDLs (for OSS files) for the product files

An activation package, which includes:

Pointers (if the systems are connected using Expand) to the product files in the archive for the software to be installed. If the package is placed on tape or disk, the product files themselves are included in the package.

For the options of which files you can include in the package, see Task 3: Specify the SYSnn Subvolume on page 9-11. If you include all files and have the activation package written to disk, a very large amount of disk space is needed to hold the entire RVU.

The operator instructions, which the planner edited during the creation of the new software revision.

Information needed by DSM/SCM to install the new software on the target system, including the TSVs and TDLs where the software will be placed.

Preparing for a Build and Apply RequestYou can submit the Build and Apply requests together or separately, depending on the connection between your host and target systems. This section covers both procedures because they are often executed in a single request. If the Build and Apply are submitted in a single request and the target system is connected to the host system using Expand, the activation package is automatically applied to the target system.


Building and Applying a New Configuration 1. Check If Additional Disk Space Is Required

1. Check If Additional Disk Space Is Required

Before performing a Build/Apply, check the amount of additional disk space you might need on the volume for new and changed files. For example, if your past configurations normally take about 1500 megabytes of disk space and your new configuration has few changes, you might need only 20 megabytes of additional free disk space (total disk space of 1520 megabytes) to process that Apply.

2. Check That the Spooler Is Active

Check that the spooler is active if you are installing a SUT.

3. Collect the Information Needed for the Build

During the Build request, you must provide DSM/SCM with the information needed to build the configuration revision and activate the software:

The new SYSnn if required

Planner instructions to the operator at the target system

Defaults are provided for all scheduling, output and TSV locations, system generation, and file placement options. However, you can specify different values for these options as needed for this Build/Apply. You cannot change the TDL locations of OSS files.

Determine the Required SYSnn Subvolume

If system generation is required, you must specify a SYSnn subvolume that is not currently running (active). Otherwise, you can specify the current SYSnn. subvolume.

System Generation Is Required

If DSM/SCM indicates that system generation is required, you must specify a different SYSnn than the current SYSnn. Specify a subvolume that is not in use (not on the list) and use it when you apply the new configuration.

System Generation Is Not Required

You can specify either the same SYSnn or a different SYSnn. However, specifying a different SYSnn subvolume when system generation is not required might require a system load that would otherwise be unnecessary.

Caution. Selecting the same SYSnn when system generation is required will cause the Apply to stop with errors. To load your system from the same SYSnn, enter a different SYSnn and then change the SYSnn name after the Apply. See Renaming the Managed SYSnn (Optional) on page 12-2.


Building and Applying a New Configuration 4. Specify PARAMs as Needed

4. Specify PARAMs as Needed

If needed, you can specify PARAMs before performing the Build/Apply. In most cases, you can use the defaults. See PARAM Summary on page E-6.

Using Guardian File Security Instead of Safeguard

If Safeguard is running on the target system, you can choose to protect the files in your new configuration with Guardian security instead of Safeguard. See IGNORE-SAFEGUARD-PROTECTION Param on page E-11. You must perform this procedure before the Apply. If you plan to issue the build and apply in one request, perform this procedure before the Build/Apply.

Preventing the Creation of the Software Configuration Dial-out Report

A software configuration report is created during a Build of a configuration. The report is placed in the $volume.SYSnn.SWCONFIG file on the target system. After sucessful completion, ZPHIRNM copies the report to a new location to update the date and time of activation. The copy of the report at the target displays both the Apply date and the Activation date. After sucessfully updating the dial-out report, ZPHIRNM generates an EMS event to indicate that the dial-out report is to be sent and the location of the modified dial-out report.

Use the NO-ACTIVATION-DIALOUT-REPORT PARAM to prevent the creation of this report. See PARAM Summary on page E-6.

5. Assemble the Planner Instructions to the Operator

To copy text from a document, such as a softdoc, and paste it in the Planner Instructions to Operator dialog box, use the Windows copy and paste functions:

1. Check that the documents you are copying information from are prepared for online viewing. See Checking Softdocs and Release Documents on page 8-10.

2. Select File>View prepared documents. DSM/SCM opens the View Prepared Documents window.

To copy a block of text from a single document, copy text from the document and paste directly in the Planner Instructions to Operator dialog box:

a. Double-click the document you are copying information from to open it.

b. Select the text to copy. Press Ctrl-C to copy the text to the clipboard (or right-click and select Copy).

To copy text from multiple documents, assemble the information in Notepad, then paste it all in the Planner Instructions to Operator dialog box at once.

Note. You must assemble all instructions before opening the Build/Apply Request window.


Building and Applying a New Configuration 5. Assemble the Planner Instructions to the Operator

Thus you avoid repeatedly opening and closing the dialog box for each copy and paste. To use Notepad to assemble planner instructions from multiple documents:

a. Double-click the document you are copying information from to open it.

b. Select the text to be copied; then press Ctrl-C (or right-click and select Copy) to copy it to the clipboard.

c. In Notepad, position the cursor where you want to insert text and press Ctrl-V (or right-click and select Paste) to paste the information.

d. In Notepad, select Edit>Select All; then press Ctrl-C to copy all the instructions to the clipboard.

3. Open the New Revision window; then click the Build/Apply request as described in Task 1: Initiate the Build/Apply Request on page 9-8. You will paste the text later as described in Task 6: Edit the Instructions on page 9-23.


Building and Applying a New Configuration Task 1: Initiate the Build/Apply Request

Task 1: Initiate the Build/Apply RequestTypically, you initiate a Build/Apply request as described in Initiating the Normal Build and Apply on page 9-8. However, additional steps are required the first time after you initialize a target system.

Initiating the Normal Build and Apply

1. From the New Software Revision window in the Planner Interface, click Build/Apply. It might take DSM/SCM several minutes to assemble the Build information. DSM/SCM then displays the Build/Apply Request dialog box (Figure 9-1).

2. Continue to Task 2: Indicate a Build/Apply or Build Request on page 9-10.

Initiating an Initialization Build and Apply

After you reinitialize a system, you must perform an initialization build/apply before you perform a normal Build/Apply of an RVU, SPR, or other software on any host or target system on which DSM/SCM has been newly configured.

1. From the Initialize target system dialog box, click Build/Apply.

DSM/SCM saves the new software revision, then displays the Indicate Type of Build dialog box.

2. Indicate the type of build. Select an initialization package or a full activation package.

Initialization package. See Initialization Package on page 9-2 for more information.

Full activation package. See Full Activation Package on page 9-2

3. Click OK.

DSM/SCM displays the Build/Apply Request dialog box. Continue to Task 2: Indicate a Build/Apply or Build Request on page 9-10.

Build/Apply Request Dialog Box

DSM/SCM assigns a name to the Build/Apply request. If you did not save the new software revision, it might take two to three minutes for the window to appear, depending on the number of changed products.

In the Build/Apply Request window, DSM/SCM displays these messages.

If DSM/SCM manages OSS files for this logical target, OSS files will be installed If this message does not appear, DSM/SCM is not set to manage OSS files. If you plan to use OSS but this message is not displayed, confirm that the Manage OSS Files check box for this logical target is checked.


Building and Applying a New Configuration Build/Apply Request Dialog Box

DSM/SCM indicates whether system generation and a system load (cold load) are required. However, DSM/SCM is not always able to determine if a new configuration can be applied to a running SYSnn subvolume accurately until after the Apply. For more information, see the DSM/SCM Help.

If the changes require a new operating system image, the Build/Apply Request dialog box displays this message. DSM/SCM will run a system generation program to generate the new system image:

SYSGEN is required for this configuration.

If the change does not affect the operating system, system generation is not required. DSM/SCM displays the message:

SYSGEN is not required for this configuration.

Figure 9-1. Build/Apply Request Window


Building and Applying a New Configuration Task 2: Indicate a Build/Apply or Build Request

Task 2: Indicate a Build/Apply or Build Request

From the Build/Apply Request dialog box:

1. Enter a description of the software input; for example:

\CHINO TARGET1 2000-02-28:15:03 G06.07, YG

\host_name targetname date, RVU, planner initials

2. Select either a Build, apply & process snapshot request or a Build request.

You can select Build, apply & process snapshot for host and target systems that are connected using Expand. This option initiates both the Build and Apply requests from the host.

The Build and Apply process owners might need remote passwords set to access the files.

The activation package is automatically sent to or accessed by the target system across the Expand connection.

When the Apply finishes, the target system generates a snapshot and returns it to the host system, where it is received into the host database.

Use the Target Interface to monitor the Apply even if you submitted the Build/Apply request from the Planner Interface.

You must select a Build request for host and target systems that are not connected using Expand.

1. Submit a Build request on the host. See Setting Output Options on page 9-14.

If the systems are connected by a network other than Expand, instruct DSM/SCM to write the activation package to disk, where you can transfer it to the target system using a file-transfer utility.

If the systems are not network connected, instruct DSM/SCM to write the activation package to tape (specified through the Output options), which you must transport to the target system.

2. Perform the Apply on the target system through the Target Interface.

If the systems are connected by a network other than Expand, instruct DSM/SCM to write the snapshot to disk, where you can transfer it to the host.

If the systems are not network connected, instruct the DSM/SCM to write the snapshot to tape, which you must carry to the host.

Note. You can also submit a Build-only request. If your Expand connection is not high speed, sending the activation package on tape might be faster and ensures that the Apply does not use up the Expand bandwidth.


Building and Applying a New Configuration Task 3: Specify the SYSnn Subvolume

3. Submit a Receive Snapshot request on the host to receive the snapshot into the host database.

Task 3: Specify the SYSnn SubvolumeTo specify a SYSnn subvolume:

1. Check the current SYSnn subvolume:

To use TACL, see Determine the Current SYSnn on page 7-2.

To use DSM/SCM:

On the Build/Apply Request window, click List SYSnn.

DSM/SCM displays a list of the SYSnn subvolumes currently in use. DSM/SCM lists the last SYSnn subvolume defined for each logical target on the system as recorded by the last snapshot. The date the snapshot was received appears at the top of the window.

If the Applied field contains a date, the SYSnn is the one used when the configuration was applied on the target.

If the field indicates Pending because a snapshot was not received at the host, the SYSnn is the one specified in the last Build for the target.

If an Apply was cancelled, the displayed last SYSnn applied is the SYSnn from the cancelled Apply, not the last successful Apply.

2. Select a SYSnn subvolume. If you are installing an SPR, you can specify the same SYSnn subvolume name. If installing a SUT, choose a different SYSnn subvolume name. See Determine the Required SYSnn Subvolume on page 9-5. To change or enter the SYSnn, enter an octal number in the Activation SYSnn field; for example:

SYS01

3. Click OK.

When you are finished, proceed to Task 4: Set the Options for the Build and Apply Request on page 9-12.


Building and Applying a New Configuration Task 4: Set the Options for the Build and Apply Request

Task 4: Set the Options for the Build and Apply Request

Use the defaults for these options or change the values as needed:

Setting Target Subvolume Locations on page 9-12

Setting Output Options on page 9-14

Setting System Generation Options on page 9-18

Setting File Placement Options on page 9-19

Setting Target Subvolume Locations

DSM/SCM places Guardian files when they are applied to a target system in subvolumes called TSVs. To manage disk space and avoid naming conflicts, you can add, move, or remove TSVs.

Checking the Location of a TSV

1. In the Build/Apply Request window, click TSV Location.

DSM/SCM displays the TSV Locations dialog box.

2. Check the target subvolume (TSV) locations. The TSV Locations dialog box shows information for each TSV for the currently open configuration, including:

Target subvolume name. An asterisk (*) indicates the TSV is new to the configuration.

Primary and alternate names of the volume on which the TSV currently resides. DSM/SCM displays the alternate name only if it is different from the primary name.

Note. A TDL is the location on a logical target where DSM/SCM places managed OSS files. Unlike a TSV, a TDL specifies an absolute path. You cannot control where a TDL is located, and you cannot copy or move a TDL to another location.


Building and Applying a New Configuration Setting Target Subvolume Locations

3. Change the target subvolume (TSV) locations as necessary. See Changing the Location of a TSV on page 9-13.

4. If you are not making any changes, click OK.

Changing the Location of a TSV

Note. Before making any changes, note that:

To avoid discrepancies, identify TSV locations correctly during the initialization Build/Apply.

Moving a SYSnn TSV from its original volume might require a system load that is otherwise unnecessary.

If you manually copy or move a TSV on the target system or perform a volume operation on the target (such as adding, deleting or renaming any volume), the changes are not shown in the TSV Locations dialog box until after you perform a Verify Database and an independent snapshot.

Changing the TSV location affects all future Build/Apply requests for a logical target.

Different logical targets cannot share the same TSV.

Each logical target must maintain its own set of TSVs on separate volumes.

Every TSV must have at least one location (volume). You cannot remove the last one.

To disregard TSV changes you enter, click Cancel in the TSV Locations dialog box.

VST105.vsd


Building and Applying a New Configuration Setting Output Options

To change the TSV locations from the TSV Locations dialog box:

1. Select one or more TSV names

To remove a volume, click Remove from volume.

To place a copy of the TSV on another volume:

a. Click Add to volume.

b. DSM/SCM displays a list of volumes. From the volumes list, select the volume to add or move the TSVs to, or enter the primary and alternate names of the volume. (If an alternate name exists, you must specify it and the primary name.)

To move the TSV to another volume:

a. Click Move to volume

b. DSM/SCM displays a list of volumes. From the volumes list, select the volume to add or move the TSVs to, or enter the primary and alternate names of the volume. (If an alternate name exists, you must specify it and the primary name.)

a. Click OK.

Setting Output Options

The target profile provides the Build/Apply default output options. Check the output options and change as needed for this Build/Apply. Changing the values for this Build/Apply request does not change the defaults in the target profile. To change the output options for this build/apply request:

1. In the Build/Apply Request window, click Output.



DSM/SCM displays the Output Options dialog box:

2. Change these output options as needed:

Activation Package/Snapshot Location on page 9-15 (tape or disk).

Output Location for Target Reports on page 9-17

Target Volume for New Subvolumes on page 9-17. Primary and alternate names of the target system volume where new TSVs are placed when DSM/SCM applies new software.

Guardian Default for New Files on page 9-17. Ownership and security for new files placed on the target system (You cannot use DSM/SCM to change the security of existing files.)

Adding Files to the Activation Package on page 9-17. You can indicate whether certain template and declaration files are included in the activation package

3. When you have finished making all changes, click OK.

Activation Package/Snapshot Location

The location (disk or tape) you choose depends on how the host and target systems are connected. To change the output location for the activation package and snapshot:

1. From the Output Options dialog box, select a tape drive or disk drive.

WARNING. Clearing an option removes the existing files from the system.

VST094.vsd



For host systems and target systems that are connected by a network other than Expand, write the activation package and snapshot to disk when submitting the Apply request. For example:

$DSMSCM

For host and target systems that are not network-connected, write the activation package to tape. When you select a tape drive, these options become available:

The optional External Tape ID (Handwritten) is handwritten on the tape. Select this option to use this label in the EMS events displayed to operators when this request is processing. You can enter up to six alphanumeric characters.

Labeled Tape Volume ID (Electronic)

A labeled tape contains a record at the beginning of the tape identifying the tape volume and the files it contains. Select this option to put the activation package on a BACKUP labeled tape. This option does not create a labeled tape.

1. Select an existing tape initialized as a BACKUP labeled tape using MEDIACOM.

2. Enter the name of the labeled tape volume ID (maximum five alphanumeric characters). Do not enter the number or letter suffix you assigned when you created the tape. If the activation package spans multiple volumes, DSM/SCM automatically reads the tapes in sequence.

When you select labeled tape, the tape drive list might contain:

For more information on the BACKUP utility, see the Guardian Disk and Tape Utilities Reference Manual. For more information on labeled tapes, see the DSM/Tape Catalog Operator Interface (MEDIACOM) Manual.

If the host and target systems are not network-connected, instruct the ZPHITI to write the snapshot to tape, which you must carry to the host.

Note. This option is valid only for the activation package (not the snapshot location) and BACKUP labeled tapes. You must use RESTORE to restore the activation package to disk on the target system before it can be applied. For more information on RESTORE, see the Guardian Disk and Tape Utilities Reference Manual.

Nothing The tape server automatically finds the local drive where you loaded the tape.

\system The tape server uses the specified system and finds the remote drive where the tape is located.

\system.$drive The specified system and drive are used.

$drive The specified drive on the local system is used.



Output Location for Target Reports

The subvolume location for reports to be viewed online. When you request a report, you can override the default location you specify here. From the Output Options dialog box, type the name of the volume. For example:

$S.#TARG.OUTPUT

Target Volume for New Subvolumes

New subvolumes created during DSM/SCM processing are placed in the target volume. The default is $SYSTEM. From the Output Options dialog box, you can select a different volume for this build/apply request. For example:

$SYSTEM

$altvolume

Guardian Default for New Files

Default ownership for new files

The default owner for all new files on the logical target is the DSM/SCM user ID. The DSM/SCM user ID is the super ID (255.255) by default. Files that replace existing files assume the same ownership as the old file. You can specify the DSM/SCM user ID or alias123.

Default security for new files

Files that replace existing files assume the same security as the old file. The default security settings for all new files on the logical target is NCNC. You can change the security. For example:

NUNU

Adding Files to the Activation Package

The default is to not include EMS template source files, SPI definition files, or privileged declaration files in the activation package.

If you leave the boxes unchecked, the default is used.

You can use these options to include them. From the create subvolume(s) field in the Output options dialog box, check the type of files you would like to include.


Building and Applying a New Configuration Setting System Generation Options

Setting System Generation Options

The target profile provides the default system generation options for all Build/Apply requests. Check the system generation options and change as needed for this Build/Apply. This procedure changes these values for an individual Build/Apply request only. The defaults in the target profile are not changed. To change the system generation options for this Build/Apply:

1. In the Build/Apply Request window, click SYSGEN.

DSM/SCM displays the SYSGEN Options dialog box.

2. From the SYSGEN Options dialog box, change the information in the dialog box as needed. Options you can change include:

CONFTEXT file location. See Changing the Location of the CONFTEXT File on page 9-18.

CONFTEXT DEFINE statements. See Expanding CONFTEXT DEFINE Statements on page 9-18

System generation work file options. See Specifying a Subvolume for System Generation Work Files on page 9-19

Spooler Location. See Specifying a Spooler Location for System Generation Reports on page 9-19

SIT options. See Creating a System Image Tape (SIT) on page 9-19. You can create one or more (up to nine) SITs on NonStop S-series systems. This option is not available for Integrity NonStop systems.

3. After you finish all system generation option changes, click OK.

Changing the Location of the CONFTEXT File

By default, the CONFTEXT file is located at $SYSTEM.SYS00.CONFTEXT. You can specify another file name to change the default location where DSM/SCM puts the configuration file during this build.

Expanding CONFTEXT DEFINE Statements

By default, the CONFTEXT DEFINE statements are not expanded. You can use this option to uncompress the DEFINE statements and set up string variables in the CONFTEXT file. Expanding them makes the CONFTEXT file much larger but could

Note. If system generation is required, check that the spooler is active before executing the Build/Apply request.

Note. Requesting a SIT does not require a system generation unless the files needed to create the SIT are not in the archive. To force a system generation, add a blank line to the CONFTEXT file for the target being built.


Building and Applying a New Configuration Setting File Placement Options

speed system generation processing. For G-series, H-series, and J-series RVUs, the DEFINE statements are optional in the CONFTEXT file.

Specifying a Subvolume for System Generation Work Files

By default, the work files are temporary and managed by a system generation program. You can use this option to specify whether system generation work files are temporary or permanent, or managed by a system generation program. These work files are created when a system generation program and BINDER are processing. If you do not use the default, you must specify a location.

Specifying a Spooler Location for System Generation Reports

By default, the spooler location is $S.#SYSGEN. The spooler must allow for 132-column formatted output. When you request a report, you can override the default you specify here. If a Build requires system generation, you must check that the spooler is running.

Creating a System Image Tape (SIT)

A SIT is not created by default and is not needed for normal DSM/SCM installation functions. As a precaution for disaster recovery, you can create a SIT for NonStop S-series systems. If you create a SIT, specify the tape drive and number of SITs to create. $TAPE is the default tape drive. Optionally, you can also specify the external tape ID. You can create up to nine SITs in one build. System generation is required only if the files to create the SIT are not in the DSM/SCM archive. If a system generation is needed for multiple SITs, it is run only for creating the first SIT.

Setting File Placement Options

DSM/SCM adopts certain unmanaged files – those that DSM/SCM has no record of – that it finds on a target system as the file that should be placed if the file has the correct EOF and modification time or the correct fingerprint. This approach results in many fewer ZPGnnnnn files cluttering a target system. You can use the file placement options to specify whether a file is adopted by the EOF and modification time or by the correct fingerprint.

From the given options, indicate where to retrieve files from, which files to replace, and which files to transfer to the target. You cannot set these options for an initialization Build/Apply.

1. In the Options field in the Build/Apply Request window, click File Placement.

Note. You cannot create a SIT for Integrity NonStop systems.



DSM/SCM displays the File Placement Options window:

2. Select which files to place and where to retrieve the files from:

3. Click OK.

DSM/SCM returns you to the Build/Apply Request window.

Performing Extra Verification

By default, DSM/SCM adopts files with the same EOF and modification time. To fingerprint nondata target files and determine whether they need to be replaced, check the Perform extra verification in the File Placement Options dialog box. If there is a fingerprint mismatch and the required file is not accessible, the Apply completes with errors. The Build/Apply takes longer if this option is selected.

Specifying Which Files to Place

By default, DSM/SCM places only changed Guardian files using target files when possible. Otherwise, host files are used.

Place only changed files using target files

If you select or default to this option , DSM/SCM checks if an identical file managed by DSM/SCM exists on the target system. If it exists, this target file is copied. If not, the file is taken from the activation package or exported directly from the archive.

Note. OSS files are always placed using host files, regardless of which option you select.

VST102.vsd



Place all files using host files

If you select this option, all files are copied. This requires a lot of time and disk space. The Apply and ZPHIRNM take much longer. After the Apply completes, two sets of every file (one for the current configuration, one for the previous) are on the target system, thus taking up more disk space. Only the next Build that does not use this option frees the disk space.

If you also select the Export necessary files during Apply option, the Build does not take longer.

If you also select the Include all files in activation package option, the activation package requires a considerable amount of disk space. For example, a full G06.06 RVU with compression ON requires 1.1 gigabytes.

Place only changed files using only host files

If you select this option, target files are not copied. DSM/SCM places new files whether or not they already exist on the target. Use this option when you no longer want certain attributes, such as user libraries, previously assigned to the existing target file.

If you select the Include changed files in AP during build option, the activation package subvolume contains more files, thus requiring more disk space because target files cannot be used.

Making Host Files Accessible for File Placement

You can use these options to specify which files to include in the activation package and whether DSM/SCM exports necessary files during the Apply. You can choose to:

Include all files in activation package during build

If the Build/Apply is not configured to use an Expand connection between the host and target systems -AND- you select the Place all files using host files option, this option is required.

Include changed files in activation package during build

Export necessary files during apply

If the Build/Apply is not configured to use an Expand connection between the host and target systems, this option is not available.

Note. These options apply only to Guardian files. OSS files are not individually packaged.


Building and Applying a New Configuration Task 5: Schedule the Request

Task 5: Schedule the RequestBy default, the Build/Apply request runs immediately. To avoid disrupting other system activities if you are installing a SUT, you can schedule the Build to run at night (based on host system time) and the Apply to run immediately after the Build. Available scheduling options are based on the type of request you indicated in Task 2: Indicate a Build/Apply or Build Request on page 9-10.

To schedule a Build/Apply or Build request to run later:

1. In the Build/Apply Request window, click Scheduling.

DSM/SCM displays the Request Scheduling Options dialog box. See Figure 16-1, Request Scheduling Options Dialog Box, on page 16-3.

2. In the Build portion of the dialog box, the default Now is already selected. To change the time, click Later and enter a date and time using the format shown in the data fields.

3. For Build only requests, the Apply portion of the dialog box is unavailable. For a Build/Apply request, the default As soon as possible is already selected for the Apply. To change the time, click Later and enter a date and time in the data fields using the formats shown.

When setting the date and time:

Schedule the Apply later than the Build, so the Build has enough time to finish. Otherwise, the Apply runs as soon as the Build finishes.

Account for different time zones. If a target system has an earlier system time than the host and you specify ASAP for the Apply, the Apply starts when the target system time catches up to the time the Build started on the host. The current time on the host when the Build is submitted is the start time for the Apply.

4. Click OK to return to the Build/Apply Request screen.


Building and Applying a New Configuration Task 6: Edit the Instructions

Task 6: Edit the Instructions DSM/SCM generates a basic set of instructions for applying new software on the target system. You can edit them to include instructions specific to your software installation. For example, you can provide product-specific installation notes from a softdoc, indicate which startup files to run, when to perform the system load, and whether to stop applications such as TMF or Safeguard during activation on the target system.

To edit the instructions:

1. If you are cutting and pasting text into the instructions, you must have assembled the text to be pasted as described in Task 7: Submit the Request on page 9-24 before you opened the Build/Apply request window.

2. In the Build/Apply Request window, click Edit instructions.

DSM/SCM displays the Planner Instructions dialog box:

3. Add instructions as needed. Change the existing text or enter new text in the space provided:

You can type the text directly in the box.

You can paste the text you assembled before you opened the Build/Apply Request window.

Put the cursor at the end of the text in the Planner Instructions dialog box; then press Ctrl-V to paste the assembled text from Notepad in the Planner Instructions.

Position the cursor where you want to insert the text from the document; then press Ctrl-V (or right-click and select Paste) to paste the text in the dialog box.

4. Click OK to return to the Build/Apply Request window.

VST103.vsd


Building and Applying a New Configuration Task 7: Submit the Request

Task 7: Submit the RequestDSM/SCM processes the request as scheduled and begins the appropriate processes. Depending on the number of software changes, this could take several hours. For information on managing requests, such as canceling or restarting a request, see Section 16, Managing Requests.

For Build/Apply/Snapshot requests, DSM/SCM creates the activation package and places the new software on the system’s subvolumes. When the Apply request is completed, a snapshot is automatically created, returned to the host system, and received into the host database.

1. From the Build/Apply Request window, click OK to submit the request.

If Manage OSS Files is checked for this logical target, DSM/SCM displays a message that it will manage OSS files on this logical target. If you are not managing OSS files on this logical target, click Cancel to cancel the request submittal, clear the Manage OSS Files check box for this logical target in its profile, and resubmit the Build/Apply request.

2. Click OK.

3. Check the status of the request.

A status window opens that is updated at regular intervals, indicating the request status. If you close the Status window, you can reopen it by selecting Requests menu>Requests list and double-clicking the request.

Click the Show EMS Events button.

DSM/SCM displays the EMS Events window:

VST057.vsd


Building and Applying a New Configuration Task 8: Apply Software to the Target System

The number in quotes is the EMS message number. For error cause, effect, and recovery information, see the DSM/SCM Messages Manual. For troubleshooting hints, see Software Configuration Troubleshooting on page 13-11.

If any OSS products in the configuration being built are not DSM/SCM-enabled, a “Completed Successful” message is generated.

4. When the request completes successfully (indicated in the EMS Events or Status windows), close the window.

Task 8: Apply Software to the Target SystemIf you ran a Build/Apply request, DSM/SCM automatically applies the software as scheduled. generates a snapshot on the target system, sends the snapshot to the host system, and receives it into the host system database. Proceed to Activating New Software on a Target System on page 10-1.

If you selected Build only or if an Apply request stopped and must be restarted, apply the activation package to the target system after the Build finishes. The operator instructions include procedures for the Apply and generating a snapshot.

To apply the software from the target system:

1. Wait until the build finishes.

2. Transfer the activation package to the target system. You can use a file-transfer utility if the systems are network connected or tape if they are not connected. If the activation package is on tape, check that a tape is mounted on a tape drive.

3. Log on to the ZPHITI on the target system. For more information, see Entering the ZPHITI on page 2-11.

4. At the Target Menu - Select Action screen, select Perform/Review Apply request.

5. Select the logical target and activation package for the Apply request:

a. At the ZPHITI main menu, enter 3 (Perform target activities) in the Selection number field, and press F1.

DSM/SCM displays the Target Menu - Select Target screen.

b. Find the number corresponding to the logical target on which you are applying software. If this is the first Apply for the target, choose number 1 (NEW CONFIG). After the software is applied, the target name is added to the list.

Enter this number in the Selection number field and press F1.

DSM/SCM displays the Target Menu - Select Action screen.

c. Enter 1 (Perform/Review Apply request) in the Selection number field and press F1.

DSM/SCM displays the S/W Apply - Get Operator Instructions screen.


Building and Applying a New Configuration Task 8: Apply Software to the Target System

d. At the S/W Apply - Get Operator Instructions screen:

1. Enter the location of the activation package:

If the activation package is on tape, mount the tape if it isn’t mounted already, enter the tape drive name in the From field, and press F1.

If the activation package is on disk, enter the system, volume, and subvolume location in the From field and press F1. (The planner put this location in the operator instructions.)

2. Press F1 to submit the request.

6. Check the status of the request.

DSM/SCM retrieves the operator instructions from the activation package and displays the S/W Apply - Getting Instructions screen which shows status messages for the request.

DSM/SCM updates the screen with current status information approximately every 15 seconds.

To check current EMS messages related to the request while waiting for it to finish, press F4.

7. When the request finishes, DSM/SCM displays Get Preview Completed. DSM/SCM then processes for a minute, then displays the S/W Apply - Submit Apply screen, which contains a description of the Apply request and the instructions to activate the software after the Apply finishes.

Check that all data fields on the S/W Apply - Submit Apply screen are correct. If necessary, change their values. The data fields have these values:

8. Monitor the status of the Apply in the S/W Apply - Processing Apply screen:

DSM/SCM updates the screen with current status information approximately every 15 seconds.

Data Field Value

Apply S/W location SYSnn where software is to be applied. (Use an octal number for the SYSnn subvolume name.) If the Apply requires a system load, you must select a SYSnn other than the one that is running. The initial value is the one chosen by the planner.

Snapshot location \system.$volume or \system.$tape

Print operator instructions on

\system.$volume.subvolume.filename or \system.$s.#printer.extension


Building and Applying a New Configuration Task 9: Transfer and Receive the Snapshot Into the Host Database

To check current EMS messages related to the request while waiting for it to finish, press F4.

DSM/SCM displays the S/W Apply - Complete Apply screen, which contains the same operator instructions displayed earlier. If you designated a print location, the instructions are printed for you to use when activating the software. To page through the instructions on the screen, use the PgUp and PgDn keys.

Task 9: Transfer and Receive the Snapshot Into the Host Database

If you ran a Build/Apply request, DSM/SCM automatically generates a snapshot on the target system after the software is applied, sends the snapshot to the host system, and receives it into the host system database. The snapshot provides the host database with current information about the software configurations on the target system. The snapshot is then available if you need to prepare another revision, back out a revision, or perform other maintenance tasks. The snapshot can help you to avoid problems in future updates caused by discrepancies between the database information and the actual configuration.

During an Independent Snapshot request on the target system, the snapshot is automatically received into the host database if all these conditions are true:

The host and target are Expand connected.

The setting of the Use Network Connection flag on the target system is Y.

You must submit a Receive Snapshot request from the host system after the snapshot is transferred to the host system if you created an independent snapshot and the value of the Use Network Connection flag is N on the target.

Note. To check the status of an Apply as it is processing, you must use the ZPHITI. The Planner Interface can display only the status of host activities. The ZPHITI can display only the status of target activities. This is true for all logical targets, including the logical target on the host system.

Host/Target Connection Snapshot Transfer to the Host System

Snapshot Initiator

Expand network

Across the Expand network as part of the Apply process. Automatic with Build/Apply

Network other than Expand

Write it to tape and manually delivery it, or write it to disk and transfer it using a file-transfer facility.

Operator starts on target system

None Write it to tape and manually deliver it. Operator starts on target system


Building and Applying a New Configuration Transferring the Snapshot to the Host System

After the snapshot has been received into the host database, you can proceed to Activating New Software on a Target System on page 10-1.

Transferring the Snapshot to the Host System

To transfer the snapshot to the host system:

For networked systems not using an Expand connection, the snapshot is written to a disk volume on the target system. To transfer it to the host system disk volume, use a file-transfer program.

For non-networked systems, the snapshot is written to a magnetic tape. Manually transport the tape to the host system. The operator transports the snapshot written to tape to the planner.

Receiving the Snapshot From Disk or Tape

On the host system, receive the snapshot into the host database and check the EMS messages for the Apply request to confirm that the request completed successfully.

1. In the Configuration Revisions window, select the target for which you are receiving the snapshot. (The configuration revision does not matter.)

2. Select Requests>Receive snapshot.

DSM/SCM displays the Receive Snapshot Request dialog box:

3. Select Requests>Receive snapshot.

DSM/SCM displays the Receive Snapshot Request dialog box.

4. Click OK to submit the Receive Snapshot request.

5. To check the EMS messages for the Apply request after receiving the snapshot into the host database, select Requests>Requests list.

Note. For systems not connected using Expand, you can transfer the snapshot before or after you activate the new software, but HP recommends that you do it before.

VST109.vsd


Building and Applying a New Configuration Receiving the Snapshot From Disk or Tape

DSM/SCM displays a list of DSM/SCM requests. In this window:

a. Select the name of the original Build request and click Status details. DSM/SCM displays the status of the request.

b. Click Show EMS events to check any EMS messages generated during the Apply. (See the DSM/SCM Messages Manual.)

c. Check the status of the request in the status window DSM/SCM displays.

6. Receive the snapshot into the host database:

To receive the snapshot from disk:

a. From the Receive Snapshot Request dialog box, click File. The default volume name, taken from the target profile, appears in the adjacent field.

b. Add the subvolume and file names to the volume name. If necessary, you can override the volume name. (The target operator can provide you with the correct snapshot file name. It appears in an EMS message when the Apply finishes.)

To receive the snapshot from tape:

a. Mount the tape for the snapshot.

b. Click Tape.

c. You can use the default tape drive or scroll through the list of host tape drives and select the one to use.

d. If the tape has an external label, enter the number in the Optional external tape ID text box. The label is an optional 6-character tape identifier you enter. (It is not a standard tape label written on the tape itself. It is an optional handwritten identifier for convenience.)

7. From the Receive Snapshot Request dialog box, click OK.


Building and Applying a New Configuration Receiving the Snapshot From Disk or Tape


10Activating New Software on a Target System

Activating the new software involves preparing the system for the new software and starting the new software. After an activation package is applied to a target system, you must activate the software before it can be used.

Use the target interface (ZPHITI) to see the operator instructions for activating software. The operator instructions included with the activation package vary depending on the software being installed. Also, the planner might have edited the instructions to include site-specific tasks earlier in the configuration process. Only the instructions required for the particular installation are included in the activation package.

This section provides an example of generated operator instructions. Make sure to use the instructions that DSM/SCM generates for you because instructions vary for different products and for any site-specific instructions the planner might add.


Summary of Activating the Software on page 10-2

Print the Instructions for Activating the Software on page 10-3

Example: Planner Instructions to Operator on page 10-3


Activating New Software on a Target System Summary of Activating the Software

Summary of Activating the SoftwareThe operator instructions are transferred to the target system in the activation package. Most activities performed outside of DSM/SCM that are mentioned in your operator instructions are not documented in detail here because these procedures can change for different RVUs. For more information, you are referred to other manuals as appropriate.

1. Some major updates require additional migration steps, so first check the release documentation for each RVU you install. (Interactive Upgrade Guide 2, Gxx.xx Software Installation and Upgrade Guide, and Hxx.xx Software Installation and Upgrade Guide.)

2. Review the operator instructions for activating the new software on the target system. If you performed the Apply separate from the Build, you should already have the operator instructions. If not, proceed to Print the Instructions for Activating the Software on page 10-3.

3. Perform the operator instructions.

Activate Software on the Target

___ Run the ZPHITI. > RUN ZPHITI

___ Log on to the ZPHITI. Enter an authorized user and password, press F1

___ Select Perform target activities. Enter 3, press F1

___ Find and enter the number corresponding to the logical target on which to apply the software.

Enter target number, press F1

___ View operator instructions and follow them. Enter 3, press F1

___ Exit the ZPHITI. Shift-F16

___ Run ZPHRNM in PREVIEW mode:

> RUN ZPHRNM SYSnn , PREVIEW

nn is the number of the SYSnn you just created.

___ Do you want to use a log file? Yes

___ Enter a file name. For example: $system.target.rnmlog1 $system.subvol.file

___ When finished, correct errors and run ZPHIRNM:

> RUN ZPHRNM SYSnn

SYS01

___ After ZPHIRNM successfully completes, boot up from the new SYSnn using OSM.

SYS01


Activating New Software on a Target System Print the Instructions for Activating the Software

Print the Instructions for Activating the Software

To print the operator instructions:

1. Log on to the ZPHITI.

2. At the ZPHITI main menu, enter 3 (Perform target activities) in the Selection number field, and press F1. DSM/SCM displays the Target Menu - Select Target screen.

3. From the list of targets in the Target Menu - Select Target screen, enter the number for the target on which the new software was applied; then press F1. If this is the first Apply for the target, choose number 1 (NEW CONFIG). After the software is applied, NEW CONFIG is replaced with the actual target name.

DSM/SCM displays the Target Menu - Select Action screen.

4. From the Target Menu - Select Action screen, enter 3 (Review operator instructions for the last apply completed) in the Selection number field and press F1. DSM/SCM displays the operator instructions. Use the PgUp and PgDn keys to page through the operator instructions.

5. Print the instructions. Verify the output location; then press F9. The instructions are printed at the location shown in the Print operator instructions on field.

6. Press Shift-F16 to exit the ZPHITI.

Example: Planner Instructions to Operator

Activation instructions for \configuration-name

DSM/SCM generates its general instructions based on configuration attributes. For detailed information on migrating to this software configuration, see the release documentation and softdocs. Note any site-specific tasks added by the planner.

1. Stop all applications. Keep OSS running.

Before activating new software, you must stop all running applications (except the OSS environment) on the target system that contain or depend on files that are being changed. The safest practice is to stop all applications, but there are exceptions to this standard, depending on the software being configured:

If software that is audited by TMF or protected by Safeguard is being updated, you need to leave those programs running. The planner should specify this in the instructions. Running ZPHIRNM in PREVIEW mode displays a message if TMF must be running to rename certain files.

Caution. This is an example. You must follow the exact instructions that you receive because they are customized to your particular revision by DSM/SCM, and to your particular site or system by the planner.


Activating New Software on a Target System Example: Planner Instructions to Operator

If only a few files are being changed, stopping only the changed applications minimizes down time. In this case, the planner might specify in the instructions only certain applications to be stopped.

To stop all applications before running ZPHIRNM or stopping the system:

1. Stop DSM/SCM:


2. Stop all other applications.

3. Stop TMF:

> TMFCOM STOP TMF

2. SCF CONTROL DISK $<SYSnn-volume-name>, REPLACEBOOT $<SYSnn-volume-name>.SYSnn.SYSDISC

This step is required only for NonStop S-series systems with major operating system or hardware changes. Integrity NonStop systems do not contain a bootstrap program on the system disk, so this step is not applicable.

REPLACEBOOT converts a work file (SYSDISC) containing the new disk bootstrap loader and controller microcode to a special format and writes it to space reserved for bootstrap microcode on the system disk (usually $SYSTEM).

For more information on running REPLACEBOOT, see the SCF Reference Manual for the Storage Subsystem.

3. Update FIRMWARE.Run OSM to check firmware and perform firmware updates.product-number product-name includes firmware changes.

This step is necessary for products with firmware changes. Some products contain firmware that is automatically updated when the device is restarted or when the system is loaded. If needed, use OSM to update the new firmware. The instructions include a list of the products with firmware changes.

If the host has not yet received a snapshot from the target system, DSM/SCM cannot determine if any products have firmware changes, and this message appears:

Firmware changes cannot be determined; a snapshot has not been received.

For more information on using OSM, see the online help available within each application.

4. RUN ZDSMSCM.ZPHIRNM SYSnn

Note. Because the procedure for updating firmware varies for different RVUs, refer to the release documentation for your RVU for the exact procedure if a firmware update is necessary.



Run ZPHIRNM to change the temporary names of the new product files to their actual names, as explained in Section 11, Renaming Product Files Using ZPHIRNM.

5. Run merge_whatis if ZPHIRNM indicates it is needed.

If this configuration includes OSS files that DSM/SCM manages and ZPHIRNM indicates that you need to run merge_whatis after ZPHIRNM finishes, see the merge_whatis(8) reference page either online or in the Open System Services Shell and Utilities Reference Manual.

6. Check for $0 EMS messages.Correct any errors indicated in the $0 EMS messages.Do not proceed until this step has been successfully completed.

Check the EMS message log to ensure that all DSM/SCM functions on the target system finished successfully.

7. If you are not currently running target then a cold load will be required. orCold load is required.

If the target for which new software is being installed is not the currently running target, load the system from the SYSnn subvolume for that target in order to run the new software. The second instruction is included if a system load is required even though the target is already running.

If you are installing a SUT or other software that required system generation, load the new operating system. If you made any changes to the CONFTEXT file, DSM/SCM has run system generation and you must perform system load even if the software you are installing does not require it.

Note. If you used an OVERRIDE-SYSNN param, you do not need to perform a system load. See Managing Software to Avoid a System Load on page 6-2.



8. RUN INSTALL^TEMPLATES to update EMS template files.

EMS templates format EMS messages. The Run INSTALL^TEMPLATE instruction is generated only on the basis of product files present in the software configuration. If you change the software configuration to include products that force system generation, DSM/SCM directs a system generation program to run TEMPLI, ensuring installation of the user template specified in the CONFTEXT file.

To run the INSTALL^TEMPLATES program to install the EMS templates in their proper locations:

a. Set the volume and subvolume to $SYSTEM.ZINSAIDS.

b. Load the TACLMACS file.

c. Enter the command INSTALL^TEMPLATES.

9. DOWN/STOP any DEVICE/LINE using filename.Use SCF to STOP these DEVICES/LINES, and then to start them again.product number product name includes IOP OBJECT code changes.

If one or more input/output processes (IOP) files change in this configuration revision but does not require system generation and one or more (IOPs) have changed, use SCF to:

a. Stop all devices and lines that use the IOP file.

b. Restart the devices and lines to put the new IOP file into effect. For more information, refer to the SCF Reference Manual for G-Series RVUs or SCF Reference Manual for J and H-Series RVU.

10.Restart all applications.Use the TI to complete any necessary DSM/SCM activities.

The last step in activating the new software is to restart all the applications you stopped in Step 1.

Note. DSM/SCM decides whether a system generation program should run TEMPLI based on the product files in the software configuration on which Build/Apply is performed. If you add the user template to the CONFTEXT file but keep the same configuration, DSM/SCM does not run TEMPLI through system generation or generate the operator instruction Run INSTALL^TEMPLATE. As a result, the user template is not installed.


11Renaming Product Files Using ZPHIRNM

When you apply software to a target system, DSM/SCM places the product files in their destination TSVs with temporary file names so the new files do not conflict with the file names of currently running programs on the target system. Before you can use the new software you applied, run ZPHIRNM to rename the files that currently have actual file names. These files are renamed to the fabricated names and become available only in the case of a backout. ZPHIRNM also renames the new files from the fabricated names to their actual names. The ZPHIRNM log file is an edit file. Statistical information appears at the end of a ZPHIRNM run.


Run ZPHIRNM in Preview Mode on page 11-2

Prepare to Run ZPHIRNM on page 11-3

Run ZPHIRNM on page 11-4

Error Handling on page 11-6

To rename product files for a Clone Group, use the CLONE utility to run ZPHIRNM. See Renaming Product Files for a Clone Group on page 19-6.

Running ZPHIRNM

1. Run ZPHIRNM in preview mode to see all the renaming activities and any possible errors without affecting the actual files. See Run ZPHIRNM in Preview Mode on page 11-2.

2. Check that DSM/SCM is not running. See Stopping DSM/SCM on page 2-3.

3. From a TACL prompt, check that you are in the ZDSMSCM volume:


vol


4. Run ZPHIRNM:

> RUN ZPHIRNM [[$vol.]SYSnn [, option]...]



Renaming Product Files Using ZPHIRNM Run ZPHIRNM in Preview Mode

where [$vol.] SYSnn is the subvolume that you just applied software to or backed out to.

Run ZPHIRNM in Preview ModeRun ZPHIRNM in PREVIEW mode to simulate the ZPHIRNM process without updating files or activating the configuration. You can evaluate, correct, and interactively test errors detected while using PREVIEW mode without affecting your system.

HP highly recommends running ZPHIRNM in preview mode before running ZPHIRNM to actually change the file names. This approach saves time and ensures a successful configuration activation.

1. Log on to the target system. In PREVIEW mode, you can log on as any super-group user that has read access to all the files being renamed.

2. Make sure that you are in the ZDSMSCM subvolume:


vol


3. Run ZPHIRNM in PREVIEW mode:

> RUN ZPHIRNM [$vol.]SYSnn , FROM [$vol.]SYSnn, PREVIEW [STRICT] [,option]...

If no arguments are entered, help text appears:

[$vol.]SYSnn

Required; specifies the SYSnn subvolume that you just applied software to or are backing out to. The default for $vol is the current system load volume, usually $SYSTEM.

The particular SYSnn to specify for this parameter should be in the operator instructions included with the activation package. (The system number is entered by the planner in the operator instructions template.)

STRICT

Optional; warns you about expected files that do not exist and do not present a problem.

Note. If you are using multiple logical targets on a system with alternate system disks, and are performing ZPHIRNM on a SYSnn created after BUILD/APPLY on an alternate logical target system, the ZPHIRNM will skip the execution of ZMODGP script. Otherwise, ZMODGP may change the environment of the current target system.


Renaming Product Files Using ZPHIRNM Prepare to Run ZPHIRNM

option is one of:

This prompt appears:

Do you want to use a log file with this session? (Y/N)

4. Enter Y and press Enter. This prompt appears:

You may use any file for logging. If you request to use a disk file that doesn’t exist, it is created as an edit file.

Please enter a filename:

5. Enter a disk file name. This message appears:

Log file is open, ZPHIRNM will now begin processing.

6. Check that ZPHIRNM ran successfully by reviewing the specified log file. If you need to address errors, see the DSM/SCM Messages Manual for cause, effect, and recovery information.

7. If the process generates errors, correct them and run ZPHIRNM in PREVIEW mode again. If no errors occur, proceed to Prepare to Run ZPHIRNM.

Prepare to Run ZPHIRNM1. Log on to the target system as the super ID (255,255) or any user who has rename

(purge) access to all files being renamed.

2. Make sure any software that is being replaced, or that uses files being replaced, is not active. (The operator instructions should tell you to stop all applications before

TSV tsv-subvol Specifies a single TSV to be tested in PREVIEW mode. tsv-subvol is an 8-character subvolume name.

TDL directory Specifies a single directory to be tested in PREVIEW mode. Only the specified directory is processed.

DETAIL-TO-SCREEN or DET or DTS

Lists all files that are being renamed to the screen.

FROM [$vol.]SYSnn Forces ZPHIRNM to rename files back to the file names of the previous configuration when the ZPHITI Backout command cannot be used. This parameter is the location of the current configuration, and the first SYSnn specified in this command is the location of the previous configuration. Use FROM only for problem resolution when you need to back out to the previous configuration.



Renaming Product Files Using ZPHIRNM Run ZPHIRNM

running ZPHIRNM.) To avoid any possibility of conflict, stop all applications currently running on the target system until after ZPHIRNM finishes.

3. Check that you are in the ZDSMSCM subvolume:


where vol is the volume containing the DSM/SCM TSV.

4. Stop DSM/SCM on the target system. For more information, see Stopping DSM/SCM on page 2-3.

Run ZPHIRNMYou enter a single TACL command with different parameters that depend on the situation.

1. Run ZPHIRNM with the appropriate parameters:

> RUN ZPHIRNM [$vol.]SYSnn [, option,]...

[$vol.]SYSnn

The default for $vol is the current system load volume, usually $SYSTEM. The SYSnn subvolume is required. Specify the SYSnn subvolume that you just applied software to or backed out to. The particular SYSnn to specify for this

Note. For some software revisions, you must leave certain applications running, such as TMF or Safeguard. ZPHIRNM in PREVIEW mode displays a message if TMF must be running to rename certain files.




Renaming Product Files Using ZPHIRNM Run ZPHIRNM

parameter is given in the operator instructions which is included in the activation package.

option is one of:

If no parameters are entered, help text appears.

ZPHIRNM displays this prompt:

Do you want to use a log file with this session? (Y/N)

2. Type Y, and press Enter. ZPHIRNM displays this prompt:

You may use any file for logging. If you request to use a disk file that doesn’t exist, it will be created as an edit file.

Please enter a filename:

3. Enter a disk file name. ZPHIRNM displays this message:

Log file is open, ZPHIRNM will now begin processing.

For logical targets that manage OSS files, ZPHIRNM processes the OSS files before the Guardian files. ZPHIRNM then renames the applied files.

If ZPHIRNM notifies you of any errors, you can resolve the problem interactively. For more information, see Error Handling on page 11-6.

4. Run merge_whatis if ZPHIRNM indicates it is needed. For more information, see Error Handling on page 11-6.

5. After completing this task, load the new operating system.

DEFAULTS Suppresses all prompts and uses default values. You cannot run ZPHIRNM interactively with this option set.

DETAIL-TO-SCREEN or DET or DTS

Lists on screen all files that are being renamed.

FROM [$vol.]SYSnn Forces ZPHIRNM to rename files back to the file names of the previous configuration when the ZPHITI Backout command cannot be used. This parameter is the location of the current configuration, and the first SYSnn specified in this command is the location of the previous configuration. Use FROM only to resolve problems when you need to back out to the previous configuration.


Renaming Product Files Using ZPHIRNM Error Handling

6. If the activating SYSnn is the running cold load SYSnn, the following note is displayed after ZMODGP and ZPHIRNM run successfully:

Error HandlingZPHIRNM issues an EMS message when it successfully completes. During rename processing, ZPHIRNM issues error and warning messages as appropriate. When an error occurs, ZPHIRNM displays the error and prompts you to select from several available options. For a complete list of ZPHIRNM messages, including causes and corrective actions, see the ZPHIRNM messages in the DSM/SCM Messages Manual.

You must correct the errors and run ZPHIRNM again. (ZPHIRNM skips any subvolumes it has already processed.) You can resolve most errors in the PREVIEW mode of ZPHIRNM. ZPHIRNM must run without errors to complete the software activation.

Note. If the system is not cold loading, start the generic processes manually. If generic processes that ZMODGP added are not started and those altered are stopped (aborted), then check the ZMODGP output. The output must be checked on screen or in log file to identify added or altered generic processes. Start the generic processes manually using the following command:

SCF START PROCESS $ZZKRN.#< name>



12 Loading the System

When activating software that required system generation and a new operating system image, you must perform a system load.


Renaming the Managed SYSnn (Optional) on page 12-2

Stopping the System by Halting the Processors on page 12-3

Loading the System on page 12-3

Running PATHCOLD on page 12-3


Loading the System Renaming the Managed SYSnn (Optional)

Renaming the Managed SYSnn (Optional)If you prefer to load your system from the same SYSnn subvolume such as SYS00:

You can configure the update on the current SYSnn without problems if the software update does not require system generation.

If system generation is required, configuring the update on the current SYSnn would cause the Apply request to stop with errors. Configure the update on a different SYSnn and then rename that SYSnn to the one you plan to load the system from.

For example, to always load your system from SYS00, configure your update on SYS01 and then rename SYS01 to SYS00:

1. Perform an Apply on the new SYSnn (in this example, SYS01).

2. Run ZPHIRNM on the new SYSnn (SYS01).

3. Rename the running SYSnn (SYS00) to another unused SYSnn (SYS20).

4. Rename the running CSSnn (CSS00) to another unused CSSnn (CSS20).

5. Rename the new SYSnn (SYS01) applied by DSM/SCM to your usual SYSnn (SYS00).

6. Rename the new CSSnn (CSS01) applied by DSM/SCM to your usual CSSnn (CSS00).

7. Perform a system load on your usual SYSnn (SYS00), which now contains the updated software configuration.

8. Restart DSM/SCM.

9. Update the DSM/SCM database with the new SYSnn subvolumes. (You do not need to do this immediately, but do it as soon as possible in case you ever need to back out to the previous revision.)

a. Before the next Apply to the system, run Verify Database so that DSM/SCM can resolve the current names of the SYSnn subvolumes. See Verifying the Target System Database (ZPHITI) on page 17-18.

b. Create an independent snapshot of the target. See Creating an Independent Snapshot of the Target System on page 17-19.

c. On the host system, receive the independent snapshot you just created into the host database. See Task 9: Transfer and Receive the Snapshot Into the Host Database on page 9-27.

You can back out to the previous revision if you used this procedure to rename the managed SYSnn. (See After Renaming the SYSnn on page 15-7.)


Loading the System Stopping the System by Halting the Processors

Stopping the System by Halting the Processors

The method you use to halt the processors varies depending on the type of system. For more information, refer to the OSM online help.

This example describes halting the processors on a NonStop system:

1. Check that DSM/SCM, all other user applications, TMF, and all other subsystems are stopped, and that the spooler is drained.

2. Log on to OSM Low-Level Link.

3. On the Low-Level Link toolbar, click Processor Status.

4. Shift-click to select all of the running processors.

5. From the Processor Actions list, select Halt.

6. Click Perform Action.

7. Click OK to dismiss the confirmation dialog box and initiate the action.

Loading the SystemThe method you use to load the system varies depending on the type of system. For more information, refer to the OSM online help.

Normally, you would load the system from the current system configuration file. When backing out a revision on an Integrity NonStop system or NonStop S-series system, you should load the system from a saved system configuration file.

Running PATHCOLDIf Pathway requires a cold start of PATHMONs after you migrate to a new RVU, STARTSCM fails when you bring up DSM/SCM on the new RVU. You get a Pathway error indicating a cold start is required. In this case, run STOPSCM, PATHCOLD, and STARTSCM from the ZDSMSCM subvolume.

If you must cold start PATHMON when migrating from one RVU to another:

1. If the target database is on another system, check that the line handler to that system is up and accessible first.

2. Run PATHCOLD from the original ZDSMSCM subvolume.

Note. If you perform a DSM/SCM Build/Apply activity that uses an OSBUILD without a PUBLIC DLL build (DSM/SCM builds the public DLL only if it is needed), timestamp mismatch warnings are displayed during Cold load. You may ignore these warning messages. If desired, you can perform a new Build/Apply activity with FORCE-PUBLIC-DLL-BUILD parameter.


Loading the System Running PATHCOLD

3. Re-enter all ALTER commands to the $YPHI PATHMON.

4. Run STARTSCM from the same subvolume to restart DSM/SCM the next time it is needed.



This part of the guide provides troubleshooting information and information for backing out of an update in case of problems.

Section 13, Troubleshooting

Provides troubleshooting information in case you encounter problems while using DSM/SCM

Section 14, Special Troubleshooting and Recovery Procedures

Provides special troubleshooting and recovery operations for severe problems. Use extreme caution and do not use these procedures unless advised to do so by HP support personnel.

Section 15, Backing Out a Revision

Provides detailed steps for returning to the previous software configuration on a system if problems occur during an update


13 Troubleshooting

This section provides helpful hints and troubleshooting information for problems that might arise while you use DSM/SCM. For other helpful information, see Required Processes and Files on page D-1.


Checking History on page 13-2

Checking Error Messages on page 13-2

Volume Management Troubleshooting on page 13-5

Database Management Troubleshooting on page 13-8

Network Troubleshooting on page 13-9

Space Management Troubleshooting on page 13-9

DSM/SCM Configuration Troubleshooting on page 13-10

Software Configuration Troubleshooting on page 13-11

Request Troubleshooting on page 13-18

Interface Troubleshooting on page 13-20

Recovery Operations on page 13-24


Troubleshooting Checking History

Checking HistoryWhen a problem arises, check the revision history and the status of requests to find the last successful activity completed.

Checking the Revision History

1. From the Planner Interface, select the software revision you were working on in the Configuration Revisions window.

2. Select File>Show revision history. Review past revisions and their current state.

Checking Requests

1. From the Planner Interface, select the software revision you were working on in the Configuration Revisions window.

2. Select Requests>Requests list. Look for failed or incomplete activities. If any requests are outstanding, cancel, delete, or complete them. For more information on restarting, canceling, deleting, or reviewing the status of requests, see Section 16, Managing Requests.

Checking Error MessagesError messages provide valuable information about the cause of a DSM/SCM problem. You can access error messages from several sources. You can use the planner interface or ZPHITMI to check error messages. Remote target activity does not appear in the planner interface but can be accessed through the ZPHITMI.

1. Check for errors.

2. Review and address all associated errors.

3. After identifying an error, see these manuals for cause, effect, and recovery information:

DSM/SCM Messages Manual for DSM/SCM errors. Advanced DSM/SCM users can also review the $ZPHI log files.

SQL/MP Message Manual for SQL errors.

TS/MP Pathsend and Server Programming Manual and the TS/MP System Management Manual for Pathway errors.

Checking EMS Messages for the Current Request

You can display any EMS messages generated during the processing of a request. These messages provide additional detail on events that occurred during request processing and can help you determine the cause of errors.


Troubleshooting Checking EMS Messages Not Related to the Current Request

Checking EMS Messages for the Current Request (Planner Interface)


2. Select Requests>Requests list....

3. To display the EMS Events dialog box, do one of:

Select a request name; then select Requests>Show request EMS events....

Select a request name, click Status details...; then click Show EMS events.

4. If a request is still running when you display its EMS messages, additional messages might be generated. To update the DSM/SCM Server Events dialog box with current information, click Refresh.

Checking EMS Messages for the Current Request (ZPHITI)

1. Log on to the ZPHITI.

2. Press F4 (Show messages). DSM/SCM displays the Show EMS Messages screen, which lists the EMS messages related to the current request.

Checking Error Messages Using ZPHITMI

1. From the target system, check that ZDSMSCM is the current subvolume; then run the ZPHITMI:

> VOLUME $volume.ZDSMSCM> RUN ZPHITMI

2. Log on to ZPHITMI using the DSM/SCM user ID. DSM/SCM displays the ZPHITMI main menu.

3. Select F4-Show Messages.

DSM/SCM displays the messages for the most recent activity. To scroll through all messages for the activity, use the Page Up and Page Down keys. If the problem relates to an earlier activity, select F4-Show non-request related events from the Show EMS Events screen to display messages for other requests.

Checking EMS Messages Not Related to the Current Request

If conditions occur in a DSM/SCM session that the status and EMS messages related to the current request cannot explain, you can check DSM/SCM EMS event messages that are not related to the processing of a specific request.

To display EMS Messages not related to the current request from the Planner Interface:



Troubleshooting Printing EMS Messages

2. Select Requests>Show other EMS events. DSM/SCM opens the DSM/SCM Server Events dialog box, which displays the EMS events.

3. To update this dialog box with current information, click Refresh.

To display EMS Messages not related to the current request from ZPHITI:

1. Log on to the ZPHITI

2. From the Show EMS Messages screen, press F4 (Show nonrequest-related errors). DSM/SCM displays the Show Non-Request-Related Errors screen.

Printing EMS Messages

From the Show EMS Messages or Show Non-Request-Related Errors screen, enter a disk location or spooler name in the Message text location field, and press F9. For a disk location, use the format:

\system.$volume.subvolume.filename

For a spooler location, use the format:

\system.$collector.#location

For a description of EMS messages related to DSM/SCM, see the DSM/SCM Messages Manual.

Checking System Generation Errors

If a problem occurs during system generation, the errors are written to the system generation output file. The location of this file for each target is designated in the system generation defaults. (See Setting the Target System Generation Defaults on page 17-9.)

Checking Workstation Error Log Files

You can check the error log files that reside in the same directory as ZDSM.EXE (or ZDSMSCM.EXE):

PIERROR.LOG is the error log file for the Planner Interface. CIERROR.LOG is the error log file for CONFGINFO.

Checking Pathway Errors

Check for PATHWAY errors that are logged but not displayed to the screen. The $YPHI process logs Pathway messages to $vol.PATHSCM.PATHLOG, on the volume where ZDSMSCM resides.

To examine the log, use the FUP COPY command to copy the file to another file or spooler location with the SHARE option if $YPHI is still running. For more information on the FUP COPY command, see the File Utility Program (FUP) Reference Manual.


Troubleshooting Volume Management Troubleshooting

Volume Management Troubleshooting

Alternate System Volume Troubleshooting

When you create multiple logical targets, or when you are running out of space on the current $SYSTEM, you can create an alternate system volume for new SYSnn subvolumes. When you create an alternate system volume:

$SYSTEM must be the permanent name, not the alternate name, for the alternate volume to be loadable.

If you load the system that is currently running on a disk whose primary and alternate volume names are the same (that is, $SYSTEM) on a disk having different primary and alternate volume names (that is, $SYSTEM and $ALTNAME respectively), you cannot see the $SYSTEM ($SYSTEM) disk. Instead, change the alternate name of the $SYSTEM disk from $SYSTEM to something else. and load the system on $SYSTEM ($ALTNAME). Then the disk comes up as its alternate name.

To perform a system load from alternate system volumes (that is, use multiple logical targets), the ZDSMSCM subvolume must be located on a volume other than $SYSTEM or any alternate system volume.

After you rename a primary or alternate volume:

1. Verify the database.

2. Receive the snapshot before carrying out any other DSM/SCM activity.

After you rename an archive volume or a scratch volume:

1. Verify the database.

2. Update the volume usage information using the ZPHITMI and ZPHIHMI (See Updating Target Volume Usage (ZPHITMI and ZPHIHMI) on page 17-12.)

The HELPSRVO file in ZDSMSCM is from the Pathmaker product.

A HELPSRVO file from PATHMAKR is distributed with DSM/SCM into the ZDSMSCM TSV for Help services in the Pathway Requestors. This file has the VPROC of the level of Pathmaker used to generate the DSM/SCM Requestors, and must not be used to infer the level of Pathmaker actually installed on your system.


Troubleshooting Alternate System Volume Troubleshooting

Problem Recovery (page 1 of 2)

DSM/SCM stops and issues an EMS message stating that a conflict exists between volume/alternate volume name pairs.

Volume and alternate volume name pairs must be unique. (For example, $DATA $SYSTEM and $SYSTEM $DATA are not allowed.) Because a volume might be active under either its volume name or its alternate volume name, it is not possible to uniquely determine a volume for placing software if two active volumes are up that have reversed volume/alternate volume names.

Use SCF to rename one of the volumes.

When you perform a target activity, an EMS message states that no scratch volumes are configured on the target system.

Either you did not run the ZPHITMI on the target system after running INITENV, or you changed the primary or alternate name of a scratch volume.

1. Run ZPHITMI.

2. Define at least one scratch volume using the Volume Maintenance screen.

3. Define at least one operator for running the ZPHITI using the Operator Security Maintenance screen.

The host database cannot locate volumes after their names were changed outside DSM/SCM.

Request an independent snapshot from the ZPHITI to update the host database with the new volume names.

The ZPHIHMI or ZPHITMI does not display a certain disk volume on its Volume Maintenance screen.

The disk volume might have a duplicate set of primary and alternate names. DSM/SCM ignores these volumes and does not display them.

For a volume pair that is not physically present in the system, DSM/SCM stops and issues a message stating that a TSV volume volume- name alternate-volume -name is not online.

You renamed or deleted a volume and another down volume exists, with the same name as the original primary or alternate name of the renamed or deleted disk.

For example, you renamed $A ($B) disk to $P ($Q). However, if a down volume already has the name $B, DSM/SCM issues the error message, “TSV volume $A $B not online.”

Bring up the down volume or delete the down volume entry from the configuration, run Verify Database, and perform the Independent Snapshot activity.


Troubleshooting Alternate System Volume Troubleshooting

SPI Definition, EMS Template and Privileged Declaration files are missing after a BUILD/APPLY is performed.

In the DSM/SCM output options dialog box, you cleared or did not select the options under Create Subvolume(s) for.

Create a new software revision with the options selected:


2. Create a new software revision.

3. Select Requests>BUILD & APPLY, or click Build/Apply in the revision window.

4. Select OUTPUT from the BUILD/APPLY dialog box.

5. In the Output dialog box, select the desired files under Create Subvolume(s) for.

6. Click OK.

7. Continue with the BUILD/APPLY as usual.

Export the files from the DSM/SCM archive:


2. Select the desired SUT or SPR from the Software Archive.

3. Select Requests>Request Export Files.

4. In the Export Request dialog box, select all options applicable in the Export developer files group box to export the files for the selected products.

5. From the Destination volume menu, select the desired destination volume on which to place the subvolume/files.

6. Click OK.



Troubleshooting Database Management Troubleshooting

Database Management TroubleshootingProblem Recovery

Performance slows during actions that reference the database.

On certain backward migrations, the Database Managers need SQLCOMP run to be compatible with the SQL PVU. If performance slows, the SQL statistics might be out of date for the tables. In either case, run SQLCOMP for the Database Manager.

Enter:

> VOLUME $volume.ZDSMSCM> RUN UPDATES

UPDATES is installed only on the host system. To run UPDATES on a target system, copy UPDATES from the host system to $volume.ZDSMSCM on the target system. Then run it as described here.

UPDATES takes from five to twenty minutes to run, depending on the system on which you are running it.

After you back out a revision, the Database Managers are not compatible with the SQL PVU.

If SQLCOMP is performed on the database manager or managers on a newer RVU (by INITENV on that RVU, or manually), and you fall back to an earlier RVU, you might need to perform SQLCOMP for the database managers on the earlier RVU.

If you fall back to an earlier SQL/MP PVU, you might also need to downgrade the SQL catalog for DSM/SCM (for example, falling back to D20 from D30):

1. Change the volume to XPHIHDB (host database catalog) or Xtarget-system-name (target database catalog).

2. SQLCI DOWNGRADE CATALOG TO n (where n is the SQL/MP PVU; for example, 2 for SQL Release 2 [D20]).

An OM Database Constraint Error from the Planner Interface, or an Internal Error 279 from ZPHIHMI, occurs while you are logging on.

This might indicate an SQL error with PHIHDBMG. The OM DB Constraint Error is misleading. The error could be any of several SQL errors encountered by the host database manager. Check for TMF and SQL errors, such as a database volume not being audited or TMF at the MAXFILES limit.

Otherwise, the error condition might be recoverable by running SQLCOMP on PHIHDBMG:

1. Enter:

> VOLUME $volume.ZDSMSCM> OBEY ADDHDEFS> SQLCOMP /IN PHIHDBMG, OUT ZPHICOMP/ CATALOG $vol.XPHIHDB

2. Check ZPHICOMP for successful SQLCOMP.

These SQL restrictions might be relaxed in certain PVUs. Other SQL restrictions most likely exist as well.


Troubleshooting Network Troubleshooting

Network Troubleshooting

Space Management Troubleshooting

Problem Recovery

The Build, Apply, Process Snapshot option in the Build/Apply dialog box is not available when you are working on the host system.

The Use network connection flag indicates whether to perform Apply requests automatically or write the activation package to tape or disk.

Use the ZPHIHMI to set the host system profile to Use network connection.

An Apply is started from the host but does not start on the target.

STARTSCM has not yet run on the target:

1. Run STARTSCM.

2. Use the ZPHITI to submit the Apply on the target using the activation package location indicated in the EMS message on the host.

Files on a network-connected system are not accessible.

Be sure to use network-accessible security when performing installation activities for DSM/SCM.

Securities for certain activities must be set so files can be accessed over a network because DSM/SCM is usually used as a network-based application.

A target database stored on the host system is not updating.

The SQL system catalog on the host system is not allowing update access to the target system.

Be sure to use network-accessible security when performing installation activities for DSM/SCM.

Problem Recovery

A file-system error 43 occurs on the ZDSMSCM volume during file placement.

Not enough disk space was provided:

1. Correct the problem using this PATHCOM command:

ALTER SERVER TA-001 PROCESS $process-name (GUARDIAN-SWAP $new-volume)

2. Restart the ZPHITI.

On a Database Relocation or INITENV, the SQLCOMP of the database manager fails.

Not enough space is available on $SYSTEM for swap space because DSM/SCM Database Manager files are very large.

Make additional space available on $SYSTEM and try again.


Troubleshooting DSM/SCM Configuration Troubleshooting

DSM/SCM Configuration Troubleshooting INITENV does not change a site’s existing TMF configuration and does not detect

whether the audit trail is big enough. However, the configuration in use might not be adequate. INITENV creates audit trails large enough for 118 megabytes of audit.

When applying DSM/SCM to DSM/SCM, always use the original TSV.

If you configured INITENV to use a direct Winsock interface between the system and the Planner Interface on your PC, INITENV looks for the LISTNER program on the current SYSnn subvolume. If INITENV cannot find LISTNER, it prompts you to:

Use Winsock.

Either install TCP/IP, or press Ctrl-Y to exit INITENV. After installing TCP/IP, rerun INITENV and specify that you will use a Winsock connection.

Continue even though the LISTNER program is not on the system.

INITENV asks if it can modify the DSM/SCM Winsock service by modifying the SERVICES and PORTCONF files:

If you answer no, INITENV displays the steps you must manually perform and skips the Winsock setup.

If you answer yes, INITENV prompts for the location of the SERVICES and PORTCONF files. INITENV then prompts for the IP port for the DSM/SCM Winsock service. You must specify the same port when you later run SETUP.

Before running STARTSCM, INITENV checks if a TCP/IP process is running:

INITENV then checks to see if a LISTNER process is running:

Processes Running INITENV Response

More than one

Warns you to stop and restart the LISTNER process that corresponds to the IP address and port number specified during SETUP on the PC

None Prompts you to either start TCP/IP now or start it and its LISTNER process before using the Planner Interface

Processes Running

LISTNER is in SYSnn, and super ID (255,255) is running INITENV INITENV Response

More than one

Yes Warns you to stop and restart the LISTNER process that corresponds to the IP address and port number specified during SETUP on the PC

None Yes Tries to start the LISTNER process

None No Prompts you to have the super ID start the LISTNER process now or after DSM/SCM starts.


Troubleshooting Software Configuration Troubleshooting

INITENV then runs STARTSCM. If TCP/IP and its LISTNER process are not running, STARTSCM indicates that you must start TCP/IP and its LISTNER process before using the Planner Interface.

Software Configuration Troubleshooting

Migration Troubleshooting

Problem Recovery

A No Software for Target warning window appears.

The site ID in the target profile might not match the site ID on the RVU.

1. Check the site ID. (Checking the Site ID on page 5-3)

2. Check that the correct site ID is in the target system profile.

A failure occurs in STARTSCM when you try to run DSM/SCM from a TSV other than the original ZDSMSCM TSV.

The startup program cannot locate INITSTAT. If you send the TSV to another disk, information created in the ZDSMSCM subvolume by INITENV is not available.

Always run DSM/SCM from the original ZDSMSCM TSV from which INITENV was run.

Problem Recovery

After you migrate between RVUs, STARTSCM gives a Pathway error that a cold start is required.

Between certain RVUs, PATHMON requires a cold start of the Pathway configurations:

1. Stop the $YPHI process.

2. Run PATHCOLD from the ZDSMSCM TSV

3. After PATHCOLD completes, run STARTSCM.

After you migrate, an SQL IVARS error occurs when you attempt to start DSM/SCM on the host for the first time.

Before running STARTSCM, initialize SQL and run PATHCOLD from the ZDSMSCM subvolume.

1. Before initializing SQL, save a copy of $SYSTEM.SYSTEM.ZZSQLCI2.

2. Initialize SQL:

> SQLCI INITIALIZE SQL;EXIT

3. After SQL is initialized, rename the copy back to $SYSTEM.SYSTEM.ZZSQLCI2 to ensure that DSM/SCM recognizes it.

For more information, see the appropriate SQL installation guide.


Troubleshooting Migration Troubleshooting

To upgrade to a new RVU, you must select Copy to of the new RVU from the Software in Archive window (not from List Products of the contents of the RVU).

When upgrading to a new RVU, you must select one of:

The RVU from the Software in Archive window; then click Copy to.

The T6032 product for the site ID from the RVU in the Software in Archive window; then click Copy to.

The Planner Interface passes the RVU for the configuration revision. Selecting the RVU from the Software in Archive window:

Makes DSM/SCM filter the product set that gets copied to the configuration revision so only products specified in the CUSTFILE for the system get copied.

Causes the configuration revision to be rebased to this RVU, which deletes all of the prior revision’s contents because they might not be compatible with the new RVU. You need to retain or recopy any SPRs, third-party products, or your own applications by picking the appropriate versions to go with this RVU. If the SUT, which is being copied to, has both the heap manager products (T8431 and T1269), DSM/SCM also displays the Heap Manager Selection dialog box. This feature is supported only on systems running G06.29 and later G-series RVUs.

If you choose products from the product list, DSM/SCM assumes you are not upgrading to a new RVU but just choosing changes or additions for this configuration revision. If you list the products in an RVU in the Software in Archive window and then select products from the product list, DSM/SCM does not filter the products based on the CUSTFILE, and it only replaces the selected entries into the configuration revision.

You can use the Planner Interface to remove unwanted products from the configuration revision after the Copy to from the RVU. Without any CUSTFILE modifications, you can prepare additional products such as customer applications and third-party products with CNFGINFO, receive them into the archive, and copy them to the configuration revision.

Note. If you only select and copy products from the RVU, no indication is sent as to the proper RVU level.


Troubleshooting Build/Apply Troubleshooting

Build/Apply Troubleshooting Problem Recovery

A Build error occurs indicating unprocessed A7CINFO files.

OSS software was received into the Archive with a pre-D46 DSM/SCM PVU, resulting in unprocessed A7CINFO files.

Receive the OSS software into the Archive again with the Receive All Files option, using a D46 or later DSM/SCM PVU.

An Apply request stops in a restartable state with a message that an expected fingerprint was not found or with an error 179.

Apply looks for files belonging to the previous configuration revision before placing files for a new configuration revision if the files have not changed between revisions.

Although the Apply can be restarted if you find the right version of the file and put it in the right place, the more usual recovery is to:

Cancel the Apply from the ZPHITI.

Perform a Verify Database.

Create an Independent Snapshot.

Verify that the snapshot is received on the host using the Planner Interface.

Create a new revision based on the current configuration revision (with no changes), and resubmit the Build/Apply.

DSM/SCM requires that two revisions of the configuration be on the target system. DSM/SCM refers to these two revisions as Saved Previous and Current. Because DSM/SCM sends only changed files to the target system as the default, it depends on the correct files for these two revisions being on the target. Each time an Apply is initiated, DSM/SCM checks to ensure that the files it did not send (because they did not change) still exist. (This check is not done for data files.) Because a file might be under its actual name or its temporary name, DSM/SCM checks the existence and attributes of the actual file name and the corresponding ZFBnnnnn name.



You might get error 5025 during an Apply if:

Any time a Build completes successfully, system generation was unnecessarily performed:

Modifying comments in the CONFTEXT file forces system generation. When the fingerprint of the CONFTEXT file indicates that the file changed but the system generation instructions in the file did not change.

For example: Configuration DEFAULT 7 was applied to SYS00. A new configuration DEFAULT 8 that requires system generation is built. Once the DEFAULT 8 Build completes successfully, you cannot use SYS00. That is, if you create DEFAULT 9 identical to DEFAULT 7, system generation is required, and you cannot send the configuration to SYS00, regardless of whether DEFAULT 8 was applied, or applied and backed out.

INITENV. When you reinitialize, DSM/SCM does not let you send your first real Apply to the current SYSnn, even when the OSIMAGE files are identical. INITENV equates to a system load.

See the DSM/SCM Messages Manual.

A configuration revision still shows Pending for the application date even though the snapshot for the Build/Apply has already been received.

When the snapshot for a Build/Apply is received, the Planner Interface screens might not be automatically updated. Select Window>Refresh before the date that the Apply occurred (Application Date) is updated and before the next Build/Apply for that target is initiated.



During a Build, an Object Manager error communicating with SWID occurs.

The specified CONFTEXT file has either been deleted, renamed, or secured so that DSM/SCM cannot read it.

When a Build/Apply dialog box is opened, DSM/SCM runs SWID to determine whether the CONFTEXT file has changed and a system generation is therefore required.

This error might also indicate a SWID error such as unresolved externals.

During a Build request, a message indicates that the release is not supported, or that the RVU is not supported.

The software revision was not based initially on an RVU.

Create a new revision, then do one of:

Select an RVU to copy to the configuration revision.

Select the T6032 product for the site ID to copy. The Planner Interface shows the RVU selected.

The RVU of a configuration revision is needed in order to choose the correct tools for building the configuration (the correct system generation program and correct version of tools a system generation program runs). This release level is obtained when an RVU is selected from the Software in Archive window and a Copy to a revision is performed. This RVU is not changed if you select List Products on Software in Archive inputs and then select products to copy to the new revision.



When you perform a Build only, without an Apply, including all files and creating the activation package on a disk on the host, an error 43 occurs.

Not enough disk space is available on the host disk where you are creating the activation package.

When creating an activation package that includes all files, use a disk with at least 1 gigabyte of space.

The default for a Build/Apply is to send only changed files. Activation packages are usually created to tape or transferred over the network.

The Build, Apply, and Process Snapshot (auto Build/Apply) option does not have this problem because its activation package contains only headers that describe the changed files, not the files themselves. The actual files are retrieved over the network from the archive as needed.

A Build-only (manual Build/Apply) activation package, created on tape or disk, contains the files themselves because the user transports the files to the target system manually, either by carrying the tape or by using a file transfer of the activation package files on the disk.

A Build request, performed at the same time as an archive relocation, fails.

The Build cannot find an archive location needed to perform the Build because the archive is being moved while the Build is running. Do not relocate the archive during Build or Build/Apply requests.

Cancel the failed request and then resubmit the Build request.

An Apply request fails after a configuration was built and an archive relocation was started.

The Apply cannot find an archive location that the Build references because the archive is being moved while the Build/Apply is running. Do not relocate the archive during Build or Build/Apply requests.

Cancel the failed request and then resubmit the Build/Apply request.


Troubleshooting Discrepancy Troubleshooting

Discrepancy Troubleshooting


TSV Discrepancies

The first part of the discrepancy report lists TSVs under the heading DUPLICATE TSV INFO.

DSM/SCM assumes that if it finds at least one file in a TSV that is also in the configuration, that TSV is a candidate for management by DSM/SCM. However, if DSM/SCM also finds the TSV on more than one volume, it cannot determine the correct volume to use.

DSM/SCM therefore lists the volumes in the snapshot it sends to the host but does not mark any of them for management by DSM/SCM. If a TSV is listed only once, it is on more than one volume. But in one of the volumes, no files in the TSV match any of those in the configuration.

When you accept these duplicate TSVs, they appear in the TSV list as new TSVs flagged by an asterisk (*). You must decide which TSV is correct. Try matching files that have the same expected and actual fingerprints. If the fingerprints match, the discrepancy is not a problem. However, you should decide if the target volume is correct because it is not the one indicated in the configuration.

You need to perform a new Build/Apply to address duplicate TSVs.

File Discrepancies

File discrepancies appear in a discrepancy report.

An SPR might be missing, or an old version of the file might be in the configuration. Try placing the correct version of the file into the configuration.

SRLs appear as discrepancies in a discrepancy report.

NSKCOM produces SRLs during a DSM/SCM Build. Therefore, they always turn up as discrepancies. These discrepancies are not a problem, so you can accept them.

An SPR is in the configuration that is not on the target.

DSM/SCM does not replace the files:

1. Delete or rename the files with discrepancies from the target system (only if they are not needed for operation).

2. From the ZPHITI, run the Verify Database and Independent Snapshot requests.

3. Receive the snapshot into the host (automatic if you specify that the host has a network connection to the target when you run ZPHIHMI).

4. Run the discrepancy report again. Missing files show a discrepancy of Not Found, and the versions in the new revision are sent on the next Apply.


Troubleshooting Request Troubleshooting

Request Troubleshooting

The discrepancy report shows many products not found on the system although they are there, or the report shows many products found on the system although they are not there.

For the Initialization Build/Apply, you used an RVU other than the RVU actually installed on the target.

Use the RVU you installed on the target when you submit an Initialization Build/Apply request.

An SPR was not included in the configuration.

Place the correct SPR into the configuration.

Discrepancies appear in HOSTS (TCP/IP), SERVICES (TCP/IP), or edit files that you customize (such as SxxxTMPL files).

These files can be accepted as discrepancies because they were changed by normal system operations.


You receive file-system error 5001 during a request such as receiving software or an Apply.

The DSM/SCM File Manager cannot access files on virtual disks managed by the Storage Management Foundation (SMF).

Retry your request without using files stored on SMF-managed virtual disks.

A Create Snapshot, Apply, Backout, retrieve operator instructions, or Verify Database request stops before it finishes.

1. Check any status messages appearing on the screen.

2. Display any EMS messages (press F4).

3. If a message appears indicating that the request is restartable, correct the problem and restart the request (press F3).

A Receive Software request completes, or configuration changes are made with the ZPHIHMI, but the status is not changed in the Planner Interface.

The Planner Interface does not poll for all windows, so it is not automatically updated. Select Refresh>Windows.

Also, if a request window is minimized, it does not show when it finishes. Maximize the window to see the current status.

A message appeared indicating that a request has stopped in a nonrestartable state.

Check the related EMS messages, collect as much information as possible about the problem, then contact your HP representative. After the problem is diagnosed, cancel the request. If the cancel also stops nonrestartable, use the ZPHITMI to delete the request.



Troubleshooting Request Troubleshooting

The Planner Interface does not allow the restart or cancellation of a target activity.

To restart or cancel a target activity, you must use the ZPHITI.

A snapshot request from the target system stops in a restartable state.

You cannot restart it from the ZPHITI. If the Snapshot request appears in the Planner Interface, you can restart it there. Otherwise, to receive the snapshot, use the Planner Interface Receive Snapshot command and specify the snapshot location provided in the EMS messages from the Apply request at the target system.

A request that stops in a restartable state is not accepting cancellation.

If you cannot correct an error that causes a request to stop in its final stages, you might not be able to cancel the request even though it is restartable. For instance, an error occurs on interfacing to BACKUP when creating a snapshot package to tape, and the problem is considered restartable by DSM/SCM. To correct the situation, delete the request using the ZPHITMI.

A request was cancelled, but the cancel seems to have no effect.

When you cancel a request, there is usually a point in the processing of the request beyond which the cancel has no effect. Canceling a request sets a database flag that you can look at later.



Troubleshooting Interface Troubleshooting

Interface Troubleshooting

Planner Interface Troubleshooting

Problem Recovery

Performance of the Planner Interface slows significantly, or a loss of available memory occurs.

Exit the Planner Interface and restart it.

A general protection fault (GPF) occurs.

Exit Windows on the PC and restart it before restarting the Planner Interface. Otherwise, memory corruption might lead to more failures.

No EMS messages are being displayed in the Planner Interface or ZPHITI.

DSM/SCM EMS messages displayed in the Planner Interface and ZPHITI come from the DSM/SCM databases. As events are sent to the alternate collector, the Schedule Manager (SMEXE) extracts the messages and puts them into the target or host database. The Schedule Manager might be having difficulty running a distributor or interfacing with the database manager.

1. Restart the DSM/SCM Schedule Manager using PATHCOM $YPHI and FREEZE, STOP, THAW, START SM-001 (SM-T-001 for a target).

2. If restarting does not help, check the alternate collector with another utility for viewing EMS messages, or monitor the modification timestamps of the log files to see how rapidly they are changing. The alternate collector might be flooding such that the Schedule Manager cannot keep up with extracting the messages to put them into the database where the Object Manager can retrieve them to return to the Planner Interface.

3. If checking the alternate collector does not help, check for problems with the database manager, such as the Schedule Manager being unable to communicate with it.

The Save New Revision or View Prepared Document commands do not seem to be doing anything.

The Save command, which is also implicit in the Build command if a Save has not already been done, can take a few minutes to send the new configuration back from the PC and update the database.

The View Prepared Document command can also take several minutes because the document is read and sent one buffer at a time from the host system to the PC. The document becomes visible immediately, and you can start viewing what has been received so far. However, the full document and the ability to search from the View menu are not available until the entire document is received.


Troubleshooting Maintenance Interface Troubleshooting

Maintenance Interface Troubleshooting

Problem Recovery

The New Revision Window or Build/Apply dialog box does not appear.

The New Revision window can take a while to appear as the data on the configuration is retrieved and sent to the PC.

The Build dialog box also takes several minutes to appear because many activities are going on to get the information that is displayed to the user:

1. SWID is run on CONFTEXT to see if changes imply that a system generation must be done.

2. The previous snapshot and the current revision are compared to determine what files have changed in the new revision.

3. Based on file changes since the last snapshot, DSM/SCM determines whether it needs to run system generation, OSM (because of firmware changes), SCF (because of bootstrap changes), or INSTALL^TEMPLATES for EMS templates or SCF for IOP changes (if system generation was not required).

4. The TSV locations for the configuration are determined and returned to the Planner Interface, along with other miscellaneous information.


ZPHIHMI or ZPHITMI logons do not seem to be doing anything.

If MISERVER is not running, and if a database manager needs to be started, the logons might seem to take a long time while the database manager process starts. The KBD LOCK indicator appears on the requestor screen while this occurs. Also, the ZPHIHMI functions of archive and database maintenance take long periods of time during which the requestor displays KBD LOCK.

The Relocate Database function does not seem to be doing anything.

The database relocate function might also take several minutes because the database manager for the catalog must also be copied to the new location and SQLCOMP must be run there.

The Archive Maintenance and Delete System does not seem to be doing anything.

Because files are only put in the archive once even if they exist in multiple software inputs, deleting or backing up software in the archive must update many database entries. Files in the input being backed up or deleted remain on the system if they are also referenced by another software input.

A Database Relocate fails with an internal error 507.

A TMF error or a SQL/MP error occurred during the operation. For more information on the error, view the DBRELOUT file in the ZDSMSCM subvolume.


Troubleshooting ZPHITI Troubleshooting

ZPHITI Troubleshooting

A profile is overwritten by a snapshot.

The Target maintenance>Modify... item of the Maintain menu entry was used to change the profile values for a logical target, and a snapshot was received from the target before another Build/Apply to that system.

A Build/Apply dialog box stated that the default volume for TSVs is invalid, and the user changed the default in the profile after submitting that Build/Apply but before receiving the snapshot.

Internal error messages occur in ZPHIHMI or ZPHITMI.

Check file securities, existence, and so on in the source and destination locations. The SCOBOL Requestors have internal error messages followed by an internal error number. However, these errors are often unexpected file-system errors, especially for operations such as Archive Maintenance and Database Relocation, which perform extensive file system operations.

A link-denied error occurs in ZPHIHMI or ZPHITMI.

The Pathway hometerm is not accessible.

The hometerm for Pathway specified in INITENV must remain available after the servers are started. If the hometerm is specified on a network-connected system, make sure the Expand connection is up.


ZPHTI logon does not seem to be doing anything.

If TISERVER is not running, and if a database manager needs to be started, the logon might seem to take a long time while the database manager process starts. The KBD LOCK indicator appears on the requestor screen while this occurs.

A link-denied error occurs in ZPHITI.

The Pathway hometerm is not accessible.

The hometerm for Pathway specified in INITENV must remain available after the servers are started. If the hometerm is specified on a network-connected system, check that the Expand connection is up.



Troubleshooting CNFGINFO Troubleshooting

CNFGINFO Troubleshooting

An Initiate Audit request stops before it finishes.

Check any error messages appearing on the screen, and take corrective action. You can restart the audit (press F3) or cancel it (press F6).

The Audit function does not seem to be doing anything.

The Audit function in the ZPHITI might take a long time because SWID is run on the files for all subvolumes specified. This fingerprinting is time consuming.

The Audit function fails without producing errors or EMS messages.

Audit does not produce error output or EMS messages. Most likely, the failure is caused by a file that SWID cannot fingerprint.

Audits are performed by the COLLECT program in the SWIC product. The file ZPHIICIN is the input file passed to COLLECT.

1. Check the ZPHIICIN file for which subvolumes are being fingerprinted.

2. Look for files on the subvolumes with security settings such that the Pathway owner cannot read them or for files with old timestamps that might indicate their file formats are a type that SWID cannot process.

COLLECT is not a DSM/SCM server and does not produce DSM/SCM EMS messages or an out file when run from DSM/SCM.

Problem Recovery

A message indicates that no A0CINFO file is in the DSV.

This might indicate an old SPR or RVU that you can reobtain from HP. You can also correct the DSV using CNFGINFO if you know the proper attributes for the files.

If you have old SPRs or RVUs, they might not contain A0CINFO files. You might receive an EMS message that one or more DSVs were skipped because no A0CINFO file exists. The input is still received if there are DSVs with A0CINFO files in them, but the skipped DSVs must be corrected, received as separate inputs, and used whenever you use the input they came with originally.

The DSV location has been entered and accepted, but CNFGINFO is not displaying the product information screen.

CNFGINFO can take several minutes to display the product information screen after the DSV location is entered and accepted because the CNFGINFO Tool server (CNFGINFO running as $ZPHC usually) is running SWID against all files in the DSV to get fingerprints to put in the A0CINFO file.



Troubleshooting Recovery Operations

Recovery Operations

Cleaning Target Work Files for OSS

if you ran INITENV when OSS was not running, use the CLEANOSS macro when OSS becomes available to remove certain DSM/SCM target work files from the currently running OSS hierarchy. Otherwise, old DSM/SCM target work files remain that will cause your next Apply to fail.

Excluding the /G and /E directories, CLEANOSS removes:

Any user can run CLEANOSS, but errors are generated if you do not have permission to remove these files. Several files require the super ID (255,255).

1. Check that the OSS hierarchy is running.

2. Use the LISTONLY option to preview which files CLEANOSS will remove without actually removing the files:

> CLEANOSS LISTONLY

3. Run CLEANOSS to remove the work files:

> CLEANOSS

4. CLEANOSS issues this prompt to confirm you want to remove these files. Enter Y to continue.

CLEANOSS is about to remove all the DSM/SCM target work files from the OSS environment. This will not affect the current set of installed files. If you are unsure, you can run CLEANOSS with the LISTONLY option to list the files that will be removed.Are you sure you want to continue (Y/N)?

CLEANOSS lists each file as it removes them. If CLEANOSS cannot remove a file, it displays an error and continues processing. When finished, CLEANOSS displays:

Total MAP files removed.................. nnnTotal Fabricated files removed........... nnnTotal ZPGnnnnn files removed............. nnnTotal Directory ID files removed......... nnn

Total files that could not be removed ... nnnTotal files removed ..................... nnn

zzDSMSCM.Managed .dsmscm.ZPHIFI .dsmscm.ZPGnnnnn

.dsmscm.ZMPccncc .dsmscm.ZFBccncc


14Special Troubleshooting and Recovery Procedures

This section provides troubleshooting and recovery procedures that should only be used under the direction of HP support personnel.


Running Traces on page 14-2

Recovering Installed Products Using SIT2SCM on page 14-14


Special Troubleshooting and Recovery Procedures Running Traces

Running Traces

You can start a trace for any DSM/SCM component on the host system or on any target system that is network connected to the host. The Planner and Maintenance Interfaces provide trace functions to trace the execution of their requests. Traces can help diagnose problems in DSM/SCM. These DSM/SCM components can be traced from the specified DSM/SCM interfaces:

When you enable tracing for:

The Schedule Manager or Object Manager, tracing begins immediately and lasts until you disable trace or end the DSM/SCM session.

The Host Database Managers, tracing begins when any Host Database Manager receives a request.

Any other DSM/SCM component, tracing begins when a request that uses the component starts processing. If you disable trace while an enabled component is running, tracing for that component is not disabled until the request finishes. If you do not disable trace, tracing continues until you end the session.

Note. The trace function slows DSM/SCM processing and uses significant disk space. It should be enabled only under the direction of HP support personnel.

DSM/SCM Component DSM/SCM Interface

Configuration Builder Planner Interface

Host Database Host Maintenance Interface

Host Database Manager (TACL)

Host Input Supervisor Target Interface

Input Supervisor Planner Interface

Object Manager Planner Interface

Planner Interface Planner Interface

Schedule Manager Planner Interface

Target Activator Target Interface

Target Database Target Maintenance Interface

Target Object Manager Target Interface

Target Schedule Manager Target Interface

Utility Server Planner Interface


Special Troubleshooting and Recovery Procedures Enabling Traces

Enabling Traces

Enabling Component Tracing (Planner Interface) on page 14-3

Enabling Tracing of All Planner Interface Activities (Planner Interface) on page 14-4

Enabling Component Tracing (ZPHIHMI or ZPHITMI) on page 14-4

Enabling Component Tracing (ZPHITI) on page 14-4

Enabling Host Database Manager Tracing on page 14-4

Enabling Object Manager Tracing on page 14-5

Enabling Component Tracing (Planner Interface)

1. Select Tandem>Support info>Server Trace. DSM/SCM displays the Server Trace dialog box:

2. In the text box, enter a subvolume location for the trace output on the host system, the target system, or both.

3. Select the check box of each component to trace.

4. Click OK.

If you select the Schedule Manager or Object Manager, DSM/SCM displays the trace output file name. If you select any other DSM/SCM component, the trace output file name is shown in an EMS message for the request that uses the component.

Note. If you enable trace for the Object Manager component and enter a subvolume location for the trace file, trace files for any other host components you enable at that time are written to the same subvolume. You cannot specify a different subvolume.

VST113.vsd


Special Troubleshooting and Recovery Procedures Enabling Traces

Enabling Tracing of All Planner Interface Activities (Planner Interface)

Select Tandem>Support info>Planner Interface trace. The menu item is selected, and tracing starts. Trace information is written to the file PITRACE.LOG.

Enabling Component Tracing (ZPHIHMI or ZPHITMI)

1. On the main menu, enter 99 (Trace) in the Selection Number field; then press F1. DSM/SCM displays the Trace screen.

2. Enter 1 in the Selection Number field.

3. In the displayed format, enter a disk location for the trace output.

4. Press F1.

Enabling Component Tracing (ZPHITI)

1. At the ZPHITI main menu, enter 9 (Enable trace) in the Selection number field; then press F1.DSM/SCM displays the Enable Trace screen.

2. Select the DSM/SCM component to be traced, and enter the corresponding number in the Selection Number field.

3. Enter a trace output location in the format (DSM/SCM supplies the file name):

\system.$volume.subvolume

If you selected number 1, 2, or 3, enter a target system location in the Target trace output location field.

If you selected number 4, enter a host system location in the Host trace output location field.

If you selected number 9, enter host and target system trace output locations in the Host trace output location field and the Target trace output location field, respectively.

4. Press F1.

DSM/SCM begins tracing the execution of the selected component and sends the trace output to the specified file.

Enabling Host Database Manager Tracing

Create a TRACEHDB file in the ZDSMSCM subvolume:

> CREATE [[$volume.]ZDSMSCM.]TRACEHDB

Note. Be sure to specify a trace output location that already exists.


Special Troubleshooting and Recovery Procedures Disabling Traces

Host database managers check for this file each time they start up or receive a request, so the trace file is not created until a host database manager receives a request. Trace files are named ZZDHnnnn and stored in the ZDSMSCM subvolume.

Only limited tracing is available for host database managers, mainly to track database queries regarding whether a system generation is required for Build/Apply procedures.

Enabling Object Manager Tracing

To enable the Object Manager Tracing:

1. Run STOPSCM.

2. Create files with names TRACECHK and TRACEOM at location $DSMSCM.ZDSMSCM.

3. Run STARTSCM.

Disabling Traces

Disabling Component Tracing (Planner Interface) on page 14-5

Disabling Tracing Of All Planner Interface Activities (Planner Interface) on page 14-5

Disabling Component Tracing (ZPHIHMI or ZPHITMI) on page 14-6

Disabling Component Tracing (ZPHITI) on page 14-6

Disabling Host Database Manager Tracing on page 14-6

Disabling Object Manager Tracing on page 14-6

Disabling Component Tracing (Planner Interface)

You cannot disable tracing for a server component that is active. If a request is using one of these components, you must either cancel the request or wait until it completes to disable the trace.

1. Select Tandem>Support info>Server trace. DSM/SCM displays the Server Trace dialog box.

2. Clear the check box of the component.

3. Click OK to disable tracing of that component.

Disabling Tracing Of All Planner Interface Activities (Planner Interface)

Select Tandem>Support info>Planner Interface trace. Tracing stops.

Note. Trace files will be created at location $SYSTEM.ZDSMSCMT.


Special Troubleshooting and Recovery Procedures Filtering Traces

Disabling Component Tracing (ZPHIHMI or ZPHITMI)

1. On the main menu, enter 99 (Trace) in Selection Number field; then press F1. DSM/SCM displays the Trace screen.

2. Enter 2 in the Selection Number field; then press F1. Trace is disabled.

Disabling Component Tracing (ZPHITI)

1. On the main menu, enter 9 (Enable trace) in the Selection number field; then press F1. DSM/SCM displays the Enable Trace screen.

2. Select the DSM/SCM component to disable tracing for, and enter the corresponding number in the Selection Number field.

3. Press F6.

Disabling Host Database Manager Tracing

Delete the TRACEHDB file in the ZDSMSCM subvolume:

> PURGE [[$volume.]ZDSMSCM.]TRACEHDB

Because host database managers interact with the TRACEHDB file only when one receives a request, the trace file does not close until a host database manager receives a request.

Disabling Object Manager Tracing

To disable the Object Manager Tracing:

1. Run STOPSCM.

2. Delete files TRACECHK and TRACEOM from the location $DSMSCM.ZDSMSCM.

3. Run STARTSCM.

Filtering Traces

You can filter what is traced to reduce the disk space consumed by a trace and to improve a trace record’s readability. Without filtering, trace files can quickly take up exceedingly large amounts of disk space when tracing DSM/SCM activities.

To filter traces, create a TRACEINI file in the ZDSMSCM subvolume. DSM/SCM executes tracing as follows:

1. When a DSM/SCM component starts up, it checks if tracing is enabled.

2. If tracing is enabled, the component next searches for a TRACEINI file.

3. If the file exists, the component searches the file for filtering instructions for that component. If no file exists, tracing is not filtered for any components.


Special Troubleshooting and Recovery Procedures Trace Levels

4. If instructions exist, they are followed. If no instructions exist, the trace for that component is not filtered.

Trace Levels

You can select from five levels of tracing detail for a DSM/SCM trace. Level 5 contains the most detailed information. Level 1 contains only the high-level tasks (stages) being executed. Levels 2 through 4 successively increase the amount of detail. A higher trace level uses more disk space and processor time but provides more detail.

For each trace level, you can do any of:

The basic format of a TRACEINI file contains these elements:

Example 14-1 demonstrates how you can create a TRACEINI file to filter your tracing.

In this example:

Disable No trace information at this level is put in the trace file.

Enable All trace information at this level is put in the trace file.

Selective Trace all information at this level that matches a specified key string.

[executable-name] The name of the executable file being traced. For example, if you have enabled trace for the Configuration Builder, it opens the TRACEINI file and searches for [CBEXE].

Level-n { ON ["key-string"] | OFF }

The indicator for tracing at each level. n is the level number. key-string is any specific characters to be filtered for at the specified level. Values within double quotes ("") are case-sensitive. You can use the asterisk (*) as a wild card. The default is ON, which enables tracing of all records at a level. For a list of search strings, see Table 14-1 on page 14-8.

Example 14-1. Example TRACEINI File

[CBEXE]

Level-1 OnLevel-2 OnLevel-3 OnLevel-4 On

[ISEXE]

Level-1 On “*INPUT*”Level-2 On “*”Level-3 On “*”Level-4 On “*”Level-5 On “*”

[TAEXE]

Level-1 On “*210*”Level-2 OnLevel-3 OffLevel-4 OffLevel-5 Off



All tracing is enabled for the Configuration Builder. (Level 5 is on by default.)

All tracing is enabled for the Input Supervisor for any information matching the indicated strings.

For the Target Activator, tracing is enabled for levels 1 and 2, and level 1 has a selective requirement of including 210.

Table 14-1 shows search string examples that can be used.

Activity Search String

[CBEXE] STG_CB_*

[ISEXE] STAGE_SNAPSHOT_*

[OMEXE]

[SMEXE]

[TAEXE] STG_AP_*

STG_BK_*

STG_IA_*

STG_VD_*

STG_GP_*

Table 14-1. Search String Examples (page 1 of 6)

Activity Stage 1 Stage 2 Stage 3

CB_STAGE_1

"STG_CB_DECIDE_FOR_SRLS(10)"

"STG_CB_RETRIEVE_SRL_BLD_TOOLS(20)"

"STG_CB_RETRIEVE_SRL_BLD_RELOCS(27)"

"STG_CB_RETRIEVE_SRL_ZTILT_SOURCE(34)"

"STG_CB_BUILD_NSKCOM_INPUT_FILE(41)"

"STG_CB_RUN_SRL_BUILD(48)"

"STG_CB_STORE_SRL_INFO(55)"

"STG_CB_DECIDE_FOR_SYSG(62)"

"STG_CB_RETRIEVE_TOOLS_FOR_SYSG(69)"

"STG_CB_RETRIEVE_SYSG_FILES(76)"

"STG_CB_PREP_SYSG_SUBVOL(83)"

"STG_CB_RUN_SYSG(90)"

"STG_CB_SPOOL_CONFLIST(95)"

"STG_CB_PROC_PREV_SYSG_INFO(100)"

"STG_CB__DLL_IS_BUILD_REQUIRED(101)"

"STG_CB__DLL_RETRIEVE_BUILD_TOOLS(102)"



"STG_CB__DLL_RETRIEVE_INPUT_FILES(103)"

"STG_CB__DLL_RUN_BUILD(104)"

"STG_CB__DLL_PROC_PREV_DLL_INFO(105)"

"STG_CB__SIT_DLL_OUTPUT_FILES(109)"

"STG_CB_SIT_SYSG_INPUT_FILES(110)"

"STG_CB_SIT_SYSG_OUTPUT_FILES(120)"

"STG_CB_CREATE_SIT(130)"

"STG_CB_SYSGEN_FOR_SITS(140)"

"STG_CB_PREP_TACL_INFO(150)"

"STG_CB_PREP_SWCONFIG_FILE(152)"

"STG_CB_SIT_COPY_FILES(160)"

"STG_CB_STORE_SYSG_INFO(170)"

"STG_CB_PERF_AP_INIT(180)"

"STG_CB_PROC_PROFILE_TBLS(190)"

"STG_CB_PROC_MIGRATION_TOOLS(200)"

"STG_CB_PROC_TACLSEGF_FILES(210)"

"STG_CB_PROC_MISSING_FILES(220)"

"STG_CB_PROC_DATA_FILES(230)"

"STG_CB_PROC_PRODUCTS(240)"

"STG_CB_PROC_ACTIVITY_RECS(250)"

"STG_CB_PROC_EMS_INFO(260)"

“STG_CB_PROC_OSS_FILES_INFO(265)"

"STG_CB_PREP_ARCH_DIR_FILE(270)"

"STG_CB_GIVE_ARCH_SECURITY(280)"

"STG_CB_PREP_AP_TAPE(290)"

"STG_CB_PERF_CLEANUP_ACTS(300)"

"STG_CB_PERF_DB_WINDUP(310)"

"STG_CB_TERMINATE_PROCESSING(320)"

SNAPSHOT_STAGE_1

"STAGE_SNAPSHOT_INPUT(10)"

"Write DB"

"Restart"

SNAPSHOT_STAGE_1 "Initialize Verify"

"Read File Snapshot"

"Read Tape Snapshot"

"STAGE_SNAPSHOT_DISCREP(15)"





"Write DB DB_rollup_pvl"

"Read DB DB_tsv_obj"

"Read DB DB_ss_files_obj"

"Read DB DB_retr_cnfg_prods_for_pkg"

"Read DB DB_tsv_obj"

"Read DB PHIH_ACT_CNTRL_TABLE"

"Read DB PHIH_DELF_CONFIG_TABLE"

"Read DB DB_retr_cnfg_prods_for_pkg"

"Write DB DB_t_disc_rep_gen"

"Determine Discrepancies"

"STAGE_SNAPSHOT_CHECKIN(20)"

"STAGE_SNAPSHOT_REPORT(23)"

"STAGE_SNAPSHOT_DIALOUT(26)"

"STAGE_SNAPSHOT_CLEANUP(30)"

"STAGE_SOFTWARE_LOCK_SUBVOLS(40)"

"Restart"

"Find & Lock Scratch Subvolumes"

"STAGE_SOFTWARE_CHECKOUT(50)"

"Check if specified software input name already exists"

"DB Start Transaction"

"DB Versioned Update Software input object"

"DB Checkout Software input object"

"DB Add a record to the activity restart table"

"DB End Transaction"

"STAGE_SOFTWARE_INPUT(60)"

"Disk Software Input"

"<dsv>" !currently valid on disk only!

Sample: "R6030AAR"

"Tape Software Input"

"Begin Restart Processing"

"End Restart Processing"

SNAPSHOT_STAGE_1





"STAGE_SOFTWARE_DBINFO(70)"

"STAGE_SOFTWARE_SITEID(75)"

"STAGE_SOFTWARE_SETMODE(80)"

"STAGE_SOFTWARE_CHECKIN(90)"

"STAGE_SOFTWARE_CLEANUP(100)"

APPLY_STAGE_1

"STG_AP_INITIALIZATION(201)"

"STG_AP_PROC_APHDR_FILES(202)"

"STG_AP_TOOL_FILES_PLACEMENT(203)"

"STG_AP_TOOL_FILES_LICENSING(204)"

"STG_AP_OPR_TOOL_FILES_PLACEMENT(205)"

"STG_AP_PLACEMENT_INITIALIZATION(206)"

"STG_AP_CONFIG_VALIDATION(207)"

"Validation Initialization"

"Validate apply TSVs are not shared by other LTs"

"Validate curr exec SYSnn or current config SYSnn is"

"Validate placement info -TACL SEG FILES"

" Validate placement info - Missing Files"

" Validate placement info - Date Files"

" Validate placement info - Config (non-Date) Files"

"Validate sufficient disk space for apply"

"Validate termination"

"Process file renames for placement"

"Process file placement for disk"

"STG_AP_TACLSEGF_FILES_PLACEMENT(208)"

"STG_AP_MISSING_FILES_PLACEMENT(209)"

"STG_AP_CONFIG_FILES_PLACEMENT(210)"

"STG_AP_OSS_FILES_PLACEMENT(211)"

"STG_AP_BUILD_TACLSEGF_FILE(212)"

"STG_AP_PREP_TARGET_WRKFILES(213)"

"STG_AP_SS_FILES_UPDT(214)"

"STG_AP_ZPG_FILE_CLEANUP(215)"

"STG_AP_PREV_CONFIG_CLEANUP(216)"

"STG_AP_REMOVE_OSS_MANAGEMENT(217)"





"STG_AP_DB_WINDUP(218)"

APPLY_STAGE_1

"FUP DUPing File: source file -> destination file"

"STG_AP_UPDATE_RNM_WRK_FLS(219)"

"STG_AP_TERM_CLEANUP(220)"

"STG_AP_TERM_DUMMY(221)"

BACKOUT_STAGE_1

"STG_BK_INITIALIZATION (301)"

"STG_BK_FIRST_RENAME(302)"

"STG_BK_SECOND_RENAME(303)"

"STG_BK_CMPLT_DB_UPDT_ZSSLIST(304)"

"STG_BK_COMPLETE(306)"

INITIAL_IA_STAGE_1

"STG_IA_INITIALIZATION(601)"


"Validate placement info -Date Files"

"Validate placement info -Config (non-Date) Files"

"STG_IA_PROC_APHDR_FILES(602)"

"STG_IA_PLACEMENT_INITIALIZATION(603)"

"STG_IA_CONFIG_VALIDATION(604)"


"Validate placement info -Date Files"

"Validate placement info -Config (non-Date) Files"

"STG_IA_CNFG_PSEUDO_PLACEMENT(605)"

"Process file renames for placement"

"Process file placement for tape"

"Process file placement for disk -Init Apply"

"STG_IA_SS_FILES_UPDT(606)"

"STG_IA_PREP_CONFIG_VERIFY(607)"

"STG_IA_CONFIG_VERIFICATION(608)"

"STG_IA_PREP_TARGET_WRKFILES(609)"

"STG_IA_DB_WINDUP(610)"





INITIAL_IA_STAGE_1

"STG_IA_UPDATE_RNM_WRK_FLS(611)"

"STG_IA_TERM_CLEANUP(612)"

"STG_IA_TERM_DUMMY(613)"

VERIFY_DATABASE_STAGE_1

"STG_VD_INITIALIZATION(500)"

"STG_VD_CAN_LT_BE_VRFD(501)"

"STG_VD_VERIFY_LT_INFO(502)"

"STG_VD_UPDT_SYS_LT_INFO(503)"

"STG_VD_UPDT_DB_LT_INFO(504)"

"STG_VD_LT_UPDT_TERM_CLNP(505)"

"STG_VD_LT_DUMMY(506)"

"STG_VD_VERIFY_NON_TSV_SV(507)"

"STG_VD_WINDUP(508)"

GET_PREVIEW_STAGE_1

"STG_GP_PROC_PREVIEW_DATA(101)"




Special Troubleshooting and Recovery Procedures Recovering Installed Products Using SIT2SCM

Recovering Installed Products Using SIT2SCM

If you are trying to recover from a disaster on a NonStop S-series system that has a backup tape and on which the Operating System Image on $SYSTEM has been damaged, you can boot from a SIT tape and use the SIT2SCM macro to install the products that DSM/SCM requires from an RVU. SIT2SCM is located in the $SYSTEM.SYSnn subvolume on your system.

To use SIT2SCM:

If you use a home terminal other than the $ZHOME process, you must pause that home terminal for this procedure.

You must have Super-user ID (255,255) access to the system.

This procedure assumes:

DSM/SCM files are on $DSMSCM.

TMF audit trails are on the $AUDIT disk volume.

The system tape drive is $TAPE0.

You might need to modify some commands in this procedure to fit your system configuration.

Task 1: Boot the System From a SIT

To get your system running again, use OSM to boot from a SIT tape:

1. Log on to system through OSM Low-Level Link.

2. Select File>Start Terminal Emulator>For Startup TACL and Start Terminal Emulator>For Event Streams.

3. On the Low-Level Link toolbar, click Processor Status.

4. Select a processor to start.

5. From the Processor Actions list, select SIT Load.

6. Click Perform Action.

7. In the Load SIT Using Processor-n dialog box:

Caution. You cannot use this procedure for Integrity NonStop systems.

One or both of these steps ensure you always have a backup of your system information:

Running your system with a mirror of $SYSTEM

Creating a backup disk image of $SYSTEM and storing it in a safe place so you can physically install and boot the backup disk if needed


Special Troubleshooting and Recovery Procedures Task 2: Start All Processors

a. Under External SCSI Controller, enter the appropriate Group, Module, and Slot.

b. Under Options, check that the CIIN Disabled box is selected.

8. Click Load.

9. Repeat Steps 4 through 8 for other processors if necessary.

Task 2: Start All Processors

Start all processors that will execute system resources. These might only be processors 0 and 1, depending on how you distribute system resources.

At the Startup TACL, start the processors:

> RELOAD (n),PRIME

where n is the processor number.

Task 3: Start the ZSERVER Process

At the Startup TACL from the system console:

> ZSERVER/NAME $ZSVR, NOWAIT, PRI 170,TERM $ZHOME, CPU 0/1

Task 4: Configure and Start Required Disk and Tape Drives

Although you could perform a Tape Boot from OSM, the drive is not ready for system use.

1. Using SCF:

-> ASSUME SENDTO STORAGE-> ADD DISK $DSMSCM, PRIMARYLOCATION (1,1,3), MIRRORLOCATION (1,1,4)-> ADD DISK $AUDIT, PRIMARYLOCATION (1,1,7), MIRRORLOCATION (1,1,8)-> START $DSMSCM-> START $AUDIT-> ADD TAPE $TAPE0, LOCATION (1,1,50), DEVICEID 5-> START $TAPE0-> EXIT

2. Using MEDIACOM:

> ALTER TAPEDRIVE *, NLCHECK OFF> EXIT

If you have backup tapes of your system, you can now restore them.


Special Troubleshooting and Recovery Procedures Task 5: Create Input Files

Task 5: Create Input Files

Run SIT2SCM to create input files for the RESTORE and FUP utilities. The file for RESTORE restores all files needed for running DSM/SCM and places them in the correct subvolume. The file for FUP licenses and sets the PROGIDs for the files. Mount the SUT on tape drive $TAPE0.

> RUN $SYSTEM.SYS00.SIT2SCM $TAPE0 $SYSTEM.subvol.CUSTFILE RESTIN FUPIN

subvol is the subvolume that contains the CUSTFILE.

RESTIN is the name of the input file for RESTORE.

FUPIN is the name of the input file for FUP.

Task 6: Use the RESTORE and FUP Input Files

Use the input files you just created to restore the required files from the SUT, mounted on $TAPE0, to their appropriate subvolumes and to license and set the PROGID for them as needed:

> RESTORE /IN RESTIN/> FUP /IN FUPIN/

Task 7: Rename the Template Files

The TCP/IP configuration files have some template files with temporary file names on the SUT to ensure the working files are not overwritten by DSM/SCM during the Apply. If you do not have a backup of your customized versions of the working files (that is, HOSTS, NETWORKS, PORTCONF, PROTOCOL, RESCONF and SERVICES), rename these temporary files to the real names and then modify them for your environment. To rename these files:

> VOLUME $SYSTEM.ZTCPIP> FUP RENAME $SYSTEM.ZTCPIP.SMPLHOST, HOSTS> FUP RENAME $SYSTEM.ZTCPIP.SMPLNETW, NETWORKS> FUP RENAME $SYSTEM.ZTCPIP.SMPLPORT, PORTCONF> FUP RENAME $SYSTEM.ZTCPIP.SMPLPROT, PROTOCOL> FUP RENAME $SYSTEM.ZTCPIP.SMPLRESC, RESCONF> FUP RENAME $SYSTEM.ZTCPIP.SMPLSERV, SERVICES

If you have a backup of your customized versions of these files, restore the backup files to $SYSTEM.ZTCPIP.

For more information on these files, see the TCP/IPv6 Configuration and Management Manual or the TCP/IP Configuration and Management Manual.


Special Troubleshooting and Recovery Procedures Task 8: Start Required Processes

Task 8: Start Required Processes

Use SCF to configure and start the QIOMON, ZZLAN, and SCP processes before you can start the 4PORT LAN card and the network:

-> ASSUME PROCESS $ZZKRN-> ADD PROCESS #QIOMON, AUTORESTART 10, CPU ALL, DEFAULTVOL $SYSTEM.SYSTEM, HOMETERM $ZHOME, OUTFILE $ZHOME, NAME $ZM, PRIORITY 199, PROGRAM $SYSTEM.SYSTEM.QIOMON, STARTMODE KERNEL-> ADD PROCESS #ZZLAN, AUTORESTART 10, PRIMARYCPU 0, BACKUPCPU 1, DEFAULTVOL $SYSTEM.SYSTEM, HOMETERM $ZHOME, OUTFILE $ZHOME, NAME $ZZLAN, PRIORITY 180, PROGRAM $SYSTEM.SYSTEM.LANMAN, STARTMODE KERNEL, STARTUPMSG "backup-cpu"-> ADD PROCESS #SCP, NAME $ZNET, PRIORITY 175, AUTORESTART 10, PROGRAM $SYSTEM.SYSTEM.SCP, PRIMARYCPU 0, BACKUPCPU 1, TYPE OTHER, STARTMODE SYSTEM, HOMETERM $ZHOME, OUTFILE $ZHOME, STARTUPMSG "backup-cpu; AUTOSTOP -1"-> START #QIOMON-> START #ZZLAN-> START #SCP-> EXIT

Task 9: Start the E4SA

Use SCF to configure and start the E4SA and its subsystems:

-> ASSUME PROCESS $ZZLAN-> ADD ADAPTER E4SA0, LOCATION (1,1,53), TYPE E4SA, ACCESSLIST (00,01)-> START ADAPTER E4SA0, SUB ALL-> ADD LIF LAN00, PIF E4SA0.0.A-> ADD LIF LAN01, PIF E4SA0.0.B-> ADD LIF LAN02, PIF E4SA0.1.A-> ADD LIF LAN03, PIF E4SA0.1.B-> START LIF LAN00-> START LIF LAN01-> START LIF LAN02-> START LIF LAN03-> EXIT

Task 10: Configure and Start TCP/IP

Configure and start TCP/IP and its associated processes:

1. From a TACL prompt:

> RUN $SYSTEM.SYS00.TCPIP/NAME $ZTC00, TERM $ZHOME, NOWAIT, PRI 180, CPU 0/1> ADD DEFINE = TCPIP^PROCESS^NAME, FILE $ZTC00> PARAM TCPIP^PROCESS^NAME $ZTC00> PARAM ZTNT^TRANSPORT^PROCESS^NAME $ZTC00


Special Troubleshooting and Recovery Procedures Task 11: License SQL/MP Files

2. In SCF:

-> ASSUME PROCESS $ZTC00-> ALTER, HOSTNAME "CHINOOK_LAN00.TANDEM.COM"-> ADD SUBNET #SN1, TYPE ETHERNET, IPADDRESS 172.17.22.128, DEVICENAME LAN00-> ALTER SUBNET #SN1, SUBNETMASK %Hffffff00-> ALTER SUBNET #LOOP0, IPADDRESS 127.1-> START SUBNET *-> ADD ROUTE #GW, DESTINATION 0, GATEWAY 172.17.22.1, DESTTYPE BROADCAST-> START ROUTE *-> EXIT

3. From a TACL prompt:

> RUN $SYSTEM.SYS00.LISTNER/NAME $ZPT00, IN $ZHOME, OUT $ZHOME, TERM $ZHOME, NOWAIT, PRI 160, CPU 0/$SYSTEM.ZTCPIP.PORTCONF> RUN $SYSTEM.SYS00.TELSERV/NAME $ZTN00, TERM $ZHOME, NOWAIT, PRI 160, CPU 0/1> RUN $SYSTEM.ZRPC.PORTMAP/NAME $ZPM00, IN $ZHOME, OUT $ZHOME, INSPECT SAVEABEND, PRI 146, NOWAIT, CPU 0/TCPIP $ZTC00

Task 11: License SQL/MP Files

License certain SQL/MP files before DSM/SCM can run:

> VOLUME $SYSTEM.SYSTEM> FUP LICENSE SQLCAT> FUP LICENSE SQLUTIL> FUP LICENSE SQLCOMP

Task 12: Configure and Start TMF

Use TMFCOM to configure and start TMF to all transactions to the SQL databases before DSM/SCM can run:

~ DELETE TMF~ SET AUDITTRAIL AUDITDUMP OFF~ SET AUDITTRAIL FILESPERVOLUME 6~ SET AUDITTRAIL FILESIZE 128~ SET AUDITTRAIL ACTIVEVOLS ($AUDIT)~ SET AUDITTRAIL MAT~ START TMF~ ADD DATAVOLS $DSMSCM, IGNOREPREVIOUSCONFIG~ EXIT


Special Troubleshooting and Recovery Procedures Task 13: Create the System Catalog

Task 13: Create the System Catalog

Use SQLCI to create and initialize the system catalog before you can use DSM/SCM:

>> CREATE SYSTEM CATALOG $DSMSCM.SQL;>> INITIALIZE SQL;>> EXIT

Task 14: Create a SPLCONF File and Start the Spooler

Create a SPLCONF file to start the spooler, which you must start before DSM/SCM can run (you must customize the information in this example for your system):

> VOLUME $SYSTEM.STARTUP> EDIT SPLCONF

ACOLLECT $S, FILE $SYSTEM.SYSTEM.CSPOOLCOLLECT $S, DATA $SYSTEM.SPOOLER.DATAFILE, UNIT 16COLLECT $S, CPU 00,BACKUP 01,PRI 160PRINT $SPLP, FILE $SYSTEM.SYSTEM.PSPOOL, CPU 0,BACKUP 1,PRI 140DEV $LP, PROCESS $SPLP, SPEED 600LOC #LP, DEV $LPSPOOLER, STARTEXIT

> VOLUME $SYSTEM.SPOOLER> FUP CREATE DATAFILE, EXT (1024,1024)> FUP SECURE DATAFILE,”NCCC”> SPOOL/IN SPL, OUT $0,NAME $SPLS, PRI 165,NOWAIT,CPU 1/0,1000,10,10,10> SPOOLCOM/IN $SYSTEM.STARTUP.SPLCONF/

The system and DSM/SCM environment are now restored enough that you can run DSM/SCM.

Task 15: Set Up DSM/SCM Profiles and Environment

1. Check that you are in the DSM/SCM subvolume:

> VOLUME $DSMSCM.ZDSMSCM

2. Run INITENV to initialize the DSM/SCM environment.

3. Run the ZPHIHMI to set up the DSM/SCM host environment.

4. Run the ZPHITMI to set up the DSM/SCM target environment.

5. Run the Planner Interface.

6. Modify the initial settings in Maintain>Target Maintenance.

7. Receive software from the SUT, build and apply a software revision, and activate the software on the system’s logical target.


Special Troubleshooting and Recovery Procedures Task 15: Set Up DSM/SCM Profiles and Environment


15 Backing Out a Revision

If problems arise with the current revision of software on a target system, you can submit a DSM/SCM request to return to the previous revision applied to that logical target. DSM/SCM makes the current revision inaccessible, reapplies the previous revision, and displays the instructions for activating the previous revision.

The backout only restores the software to the previous revision. Depending on the actions performed by the operator to activate that software, additional steps might be needed to fall back to the previous revision. For additional backout procedures for specific products, see the Gxx.xx Software Installation and Upgrade Guide or Hxx.xx Software Installation and Upgrade Guide for the RVU.


Backing Out If DSM/SCM Is Running on page 15-2

Backing Out in Special Circumstances on page 15-6

Fallback Considerations on page 15-9

Notes. You can back out only to the previous revision of software. The software revision you backed out is not deleted from the Configuration Revisions window. To reinstall an earlier revision, use the Planner Interface (Planner Interface) to rebuild the revision from the revision history, then reapply it. For the procedure for creating a new software revision from an earlier revision, see Section 8, Creating and Managing Software Revisions.

Figure 15-1. Backing Out a Revision

Target Pathway Env. $YPHI

TCP-T

TISERVER SM-T-001 TA-001

TDB Mgr

TargetInterface

SYSnn.ZSSLIST

$SYSTEM

TargetDatabase

ActivityRecords

PreviousRevision

becomesthe Current

Revision

CurrentRevision

becomesthe

"backed out"Revision

VST083.vst


Backing Out a Revision Backing Out If DSM/SCM Is Running

Backing Out If DSM/SCM Is RunningTo back out a revision only if DSM/SCM is correctly running on your system:

Task 1: Start DSM/SCM

Task 2: Start and Log On to the ZPHITI

Task 3: Perform Backout Activities

Task 4: Monitor the Backout Process

Task 5: Stop All Applications

Task 6: Run ZPHIRNM in Preview Mode

Task 8: Stop and Load the System

Task 9: Start TMF and Your Applications

Task 1: Start DSM/SCM

1. Start TMF if it is not already running:

> TMFCOM START TMF

2. Start DSM/SCM if it is not already running:

> VOLUME $volume.ZDSMSCM> RUN STARTSCM

Task 2: Start and Log On to the ZPHITI

1. Start the ZPHITI:

> RUN ZPHITI

DSM/SCM displays the ZPHITI Logon Menu.

2. Enter your password and press F1. DSM/SCM displays the ZPHITI Main Menu.

Note. You should not need to fall back to previous firmware versions. However, you should confirm this in your release documentation.


Backing Out a Revision Task 3: Perform Backout Activities

Task 3: Perform Backout Activities

1. Enter 3 (Perform target activities) in the Selection number field, and press F1. DSM/SCM displays the Target Menu - Select Target Screen.

2. On the Target Menu - Select Target Screen, enter the number corresponding to the name of the target system, and press F1.

3. On the Target Menu - Select Action screen, enter 2 (Perform backout to S/W) in the Selection number field, and press F1.

The ZPHITI requires that you provide the location of the snapshot (\system.$volume) before it begins processing the backout.

DSM/SCM displays the Backout - Verify Request screen, which contains:

The SYSnn, date, and timestamp of the current software revision and of the previous revision, which becomes the current revision after the backout request finishes

The location where DSM/SCM will place the snapshot

A warning that the request will make the last software applied on this target inaccessible

4. Press F1 to submit the ZPHITI Backout request.

DSM/SCM updates the target database to make the previous software revision the current revision. An activity record is posted, the current revision is made an inaccessible backed-out revision, and the rename work directory file in the SYSnn subvolume is updated.

While the backout request is processing, DSM/SCM displays the Backout-Processing Backout screen, which gives a description of the request, its processing status, and the location of the previous SYSnn software affected by the request.

Note. If selection 2 (Perform backout to S/W) is not available, you have either performed a backout, or a previous configuration does not exist. In the latter case, see Previous Configuration Does Not Exist or DSM/SCM Does Not Run on page 15-6.

Note. Do not delete the SYSnn that was backed out until one more SYSnn has been applied. DSM/SCM relies on these files being present until the next SYSnn is applied, after which it automatically deletes them.

Although the backed-out revision continues to exist until a new revision is applied, DSM/SCM no longer manages it. Thus, it is effectively removed. To reinstall the backed-out revision, use the Planner Interface to rebuild and reapply it.


Backing Out a Revision Task 4: Monitor the Backout Process

The screen is updated with current status information approximately every 15 seconds.

While waiting for the request to finish, you can press F4 to view current EMS messages related to the request.

If a message appears indicating that the request is awaiting a tape mount, press F4 to view the EMS messages for tape and tape drive information; then mount the tape. DSM/SCM resumes processing.

5. Transfer the snapshot to the host system if your host and target systems are not connected using Expand. After the software is reapplied, DSM/SCM creates a snapshot of the target system.

If you created the snapshot on disk, use a file transfer mechanism to transmit the snapshot to a volume on the host. If you created it on tape, carry it to the host.

If your systems are connected using Expand, proceed to Step 7.

6. Receive the snapshot into the host database if your host and target systems are not connected using Expand. For the full procedure, see Task 9: Transfer and Receive the Snapshot Into the Host Database on page 9-27.

After the software backout finishes, DSM/SCM displays the Backout - Complete Backout screen, which gives the SYSnn, name, date, and timestamp of the activation package that has been reapplied to the system. This screen also contains the operator instructions originally sent for activating the current revision. These are not necessarily the instructions to use to back out to a previous configuration. For detailed fallback procedures for changed products, consult the release documents.

7. Choose a printer to receive the instructions.

8. Press Shift-F16 to exit the ZPHITI.

Task 4: Monitor the Backout Process

1. On your PC, start the Planner Interface.

2. Log on to the Planner Interface using the super ID (255,255). DSM/SCM displays the Planner Interface main screen.

3. Select Requests>Request list. DSM/SCM displays the Requests list screen, showing type of activity and current status.

4. Double-click to select the backout activity, which should be at the top of the Request list.

5. Select Status details.

Caution. Do not stop DSM/SCM until the backout is complete.


Backing Out a Revision Task 5: Stop All Applications

6. DSM/SCM displays the Request Activity Summary screen. Monitor the backout processing by watching the timestamp in the upper-right corner of the screen. Select Show EMS events to obtain an update at any time.

7. When the backout is complete, exit the Planner Interface.

Task 5: Stop All Applications

Before running ZPHIRNM, you must stop all applications, including DSM/SCM and TMF. For more information, refer to Stopping All Applications on page 2-3.


Running ZPHIRNM in PREVIEW mode simulates the ZPHIRNM process without updating files or activating the configuration. For more information, refer to Run ZPHIRNM in Preview Mode on page 11-2.

If the process generates errors, correct them and run ZPHIRNM in PREVIEW mode again. If no errors occur, continue with Task 7: Rename Software Files Using ZPHIRNM.

Task 7: Rename Software Files Using ZPHIRNM

Running ZPHIRNM renames the files in the previous revision from their saved file names to their actual file names.

Enter this command using the SYSnn for the configuration you are backing out to:

> RUN ZPHIRNM [$vol.]SYSnn , [ option,]...

For more details, see Run ZPHIRNM on page 11-4.

ZPHIRNM must run without errors to complete the software activation. ZPHIRNM issues an EMS message when it has successfully finished. If the new revision does not require a system generation or system load, proceed to Task 9: Start TMF and Your Applications on page 15-6.

Task 8: Stop and Load the System

1. Stop the system by halting the processors. The method you use varies depending on the type of system. For more information, refer to Stopping the System by Halting the Processors on page 12-3.

Note. For some software revisions, you must leave certain applications running, such as TMF or Safeguard. Running ZPHIRNM in PREVIEW mode displays a message if TMF must be running to rename certain files. Consult the instructions for the RVU you are backing out to for any special instructions to leave certain applications running.

Caution. If you decide to delete a logical target after performing a backout, check that the entire backout process finishes, including receiving the snapshot at the host system.


Backing Out a Revision Task 9: Start TMF and Your Applications

2. Load the system. The method you use varies depending on the type of system. For more information, refer to Loading the System on page 12-3. For NonStop S-series systems and Integrity NonStop system, load the system using a saved system configuration.

Task 9: Start TMF and Your Applications

After you are back to your previous software configuration and system configuration, you can start your applications, including TMF.

Backing Out in Special CircumstancesIn these circumstances, backing out requires a different procedure:

Previous Configuration Does Not Exist or DSM/SCM Does Not Run on page 15-6

After Renaming the SYSnn on page 15-7

Backing Out to an Older Configuration on page 15-9

Previous Configuration Does Not Exist or DSM/SCM Does Not Run

Use this procedure to:

Back out to the previous revision if you can not get DSM/SCM to run on your system. After this procedure, you should be able to access the ZPHITI and perform the normal backout procedure.

Undo the activation of the last Apply if a previous configuration does not exist, such as after the first Apply to a logical target is performed.


Running ZPHIRNM in PREVIEW mode simulates the ZPHIRNM process without updating files or activating the configuration. For more information, refer to Run ZPHIRNM in Preview Mode on page 11-2. If the process generates errors, correct them and run ZPHIRNM in PREVIEW mode again. Repeat this task until no errors remain. If no errors occur, continue with Task 2: Prepare to Run ZPHIRNM.

Task 2: Prepare to Run ZPHIRNM

For more information, see Prepare to Run ZPHIRNM on page 11-3.


Backing Out a Revision After Renaming the SYSnn

Task 3: Run ZPHIRNM

Running ZPHIRNM now renames the files in the previous revision from their saved file names to their actual file names. Enter this command:

> RUN ZPHIRNM [$vol.]SYSnn , FROM [$vol.]SYSnn

SYSnn is the same number for both in this command.

For example, if you first used DSM/SCM to apply SYS01 to a system running SYS00 (not applied by DSM/SCM), you need to back out to SYS00:

> RUN ZPHIRNM [$vol.]SYS01 , FROM [$vol.]SYS01

For more information about running ZPHIRNM, refer to Run ZPHIRNM on page 11-4. ZPHIRNM must run without errors to complete the software activation. ZPHIRNM issues an EMS message when it successfully completes.

Task 4: Stop the System by Halting the Processors

For more information, refer to Stopping the System by Halting the Processors on page 12-3.

Task 5: Load the System

The method you use for system load varies depending on the type of system. For more information, refer to Loading the System on page 12-3. For NonStop S-series systems and Integrity NonStop systems, load the system from a saved configuration.

Task 6: Run ZPHIRNM

If you could not run ZPHIRNM successfully in Task 1, run it again now. For more information, see Run ZPHIRNM on page 11-4.

Task 7: Back Out to the Previous Revision

You can now back out to the previous revision as described in Backing Out If DSM/SCM Is Running on page 15-2.

After Renaming the SYSnn

Backing out after renaming the SYSnn subvolume varies slightly, depending on whether you can successfully restart DSM/SCM after the system load.

For the procedure on renaming the SYSnn, see Renaming a Volume Managed by DSM/SCM on page 17-14.

System Load and DSM/SCM Restart Succeed

1. Run ZPHITI to perform a backout (tasks 1 through 5 of Backing Out If DSM/SCM Is Running on page 15-2).


Backing Out a Revision After Renaming the SYSnn

2. Run ZPHIRNM on the previous SYSnn (in this example, SYS20). For more information, refer to Run ZPHIRNM on page 11-4. The previous SYSnn is the software configuration that was running before the current software configuration.

3. Rename the current SYSnn (SYS00) and CSSnn (CSS00) to an unused SYSnn (SYS01) and CSSnn (CSS01), respectively. For example:

> FUP RENAME $SYSTEM.SYS00.*, $SYSTEM.SYS01.*> FUP RENAME $SYSTEM.CSS00.*, $SYSTEM.CSS01.*

4. Rename the previous SYSnn to the name it had at the completion of the Apply. For example:

> FUP> RENAME $SYSTEM.SYS20.*, $SYSTEM.SYS00.*> RENAME $SYSTEM.CSS20.*, $SYSTEM.CSS00.*

5. Perform a system load on your usual SYSnn (SYS00), which now contains the revision before the last update.

6. Restart DSM/SCM.

7. Update the DSM/SCM database with the new SYSnn subvolumes. (You do not need to do this immediately, but do it as soon as possible in case you need to back out to the previous revision.)

a. Before the next Apply to the system, run a Verify Database so that DSM/SCM can resolve the current names of the SYSnn subvolumes.

b. Create an independent snapshot of the target.

c. Receive the independent snapshot into the host database.

System Load Fails or DSM/SCM Does Not Run Correctly

1. Perform a system load from the previously working SYSnn (renamed to SYS20).

2. Rename the current SYSnn (SYS00) and CSSnn (CSS00) back to the last built SYSnn (SYS01) and CSSnn (CSS01), respectively. For example:

> FUP RENAME $SYSTEM.SYS00.*, $SYSTEM.SYS01.*> FUP RENAME $SYSTEM.CSS00.*, $SYSTEM.CSS01.*

3. Rename the previous SYSnn to the name it had at the completion of the Apply. For example:

> FUP

> RENAME $SYSTEM.SYS20.*, $SYSTEM.SYS00.*> RENAME $SYSTEM.CSS20.*, $SYSTEM.CSS00.*

4. Run ZPHIRNM to reverse the ZPHIRNM done before the SYSnn subvolume was renamed. For more information, refer to Run ZPHIRNM on page 11-4. For example:

> RUN ZPHIRNM $volume.SYS00, FROM $volume.SYS01


Backing Out a Revision Backing Out to an Older Configuration

5. Perform a system load from the newly renamed working SYSnn (now renamed to SYS00).

6. Start DSM/SCM.

7. Run ZPHITI to perform the backout step (Tasks 2 through 4 of Backing Out If DSM/SCM Is Running on page 15-2) to back out to SYS00.

Backing Out to an Older Configuration

In this procedure, you are applying a new configuration, but want to be able to back out to a previous configuration if needed instead backing out to the configuration currently running on your system. A previous configuration is the configuration that was executing on the target system just before the current configuration.

In this example, G06.25 is currently running on your system. The previous configuration was G06.24. To run G06.26, but keep G06.24 as the configuration to back out to instead of G06.25:

1. Back out from G06.26 to G06.24.

Follow the appropriate procedure in Backing Out If DSM/SCM Is Running on page 15-2 or Previous Configuration Does Not Exist or DSM/SCM Does Not Run on page 15-6.

2. After the backout is complete, build and apply a new revision for G06.26. For details, see Section 8, Creating and Managing Software Revisions.

Do not be alarmed when the Configuration Revisions window appears and still lists the products from the last applied configuration (in this example, G06.25). G06.24 is the configuration you can back out to even though the G06.25 information is displayed in the Revision History window.

Fallback Considerations

Guardian User IDs

After you migrate back to a product version update prior to T6031ABK on a NonStop S-series system, the user IDs will be exactly as they were before installing T6031ABK. Any changes made to the Guardian user IDs while on T6031ABK or later are not carried backward.

There are two possible scenarios:

You performed a backward migration from T6031ABK or later to pre-ABK but post-D46.

In this case, FALLBACK removes Safeguard alias security profile information from the DSM/SCM databases. Any security profile changes that you made to Planners, Database Administrators, or Operators while on ABK are not be carried backward. The security profile information is exactly as it was before you installed T6031ABK.


Backing Out a Revision Removing OSS Management Information From the DSM/SCM Databases

You performed a backward migration from T6031ABK or later to pre-D46. In this case, in addition to the new security tables, FALLBACK also removes OSS management information from the DSM/SCM databases. (For details, see Removing OSS Management Information From the DSM/SCM Databases.)

The FALLBACK macro is run in the same manner as explained on page 12-2.

Removing OSS Management Information From the DSM/SCM Databases

Backing out to the previous configuration is the same when OSS files are managed as when only Guardian files are managed, with one exception: the current configuration manages OSS files, but the previous configuration did not.

The backout and activation processes are normal, and OSS files are returned to the state they were in before the current configuration was applied. However, this backout puts DSM/SCM in a unique state where the newly current configuration does not manage OSS files but the newly previous configuration does. There are three possible results:

If the next Build/Apply is for this logical target and does not manage OSS files, OSS management is removed.

If the next Build/Apply is for this logical target and manages OSS files, the build stops restartable:

1. Cancel the Apply.

2. Run CLEANOSS to remove all DSM/SCM files from the OSS environment.

3. Run Verify Database to remove OSS management from the logical target in the target database.

4. Restart the Apply.

If you back out from a configuration managed by a D46 or later DSM/SCM PVU to one managed by a pre-D46 PVU, you must revert your DSM/SCM host and target databases to their pre-OSS management setup.

To revert the databases for use by pre-D46 DSM/SCM PVUs, use the FALLBACK macro:

1. Find the FALLBACK macro.

The macro was first released with T6031D46 in the ZDSMSCM subvolume. If you have already reverted to a pre-D46 DSM/SCM PVU, it is likely not in the ZDSMSCM subvolume. You can retrieve the macro from the T6031D46 DSV in any G06.18 or later RVU. If such an RVU is in the DSM/SCM archive, you can export it directly from the archive.

2. Check that DSM/SCM is stopped.



3. Run the FALLBACK macro immediately after you back out to a pre-D46 PVU but before you run STARTSCM.

You need to run the macro separately for the host and target systems, but only for whichever systems have been backed out. For example, if your target system is still running the D46 PVU, do not run the macro on the target system.

The FALLBACK macro must be run from the ZDSMSCM subvolume by the DSM/SCM user ID or the super ID (255,255) only.

4. Address any errors returned by the FALLBACK macro.

5. If there are no errors, when FALLBACK prompts you to continue, enter Yes.

The FALLBACK macro begins processing. Though the macro does not remove OSS files, it removes all OSS management information from the DSM/SCM databases. Therefore, you must always use the COPYOSS procedures to install OSS software until you re-enable DSM/SCM to manage OSS files.

6. After the FALLBACK macro indicates it is running IPM6031, which is its final step, you can run STARTSCM.

To later manage OSS files again, you must migrate to the DSM/SCM D46 or later PVU and receive the software into the archive again to properly process the DSM/SCM-enabled OSS software.



This part of the guide provides details about working with DSM/SCM requests, generating reports, managing DSM/SCM, and installing web interfaces:

Section 16, Managing Requests

Describes how to submit and review DSM/SCM requests

Section 17, Managing DSM/SCM

Describes managing DSM/SCM security, databases, and archives, usually performed by the database administrator

Describes shorthand views of the database to help select data to include in DSM/SCM reports


Describes procedures for generating the many reports available through DSM/SCM

Section 19, Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning)

Describes a simplified process for using DSM/SCM to install and manage an identical software configuration on multiple NonStop servers

Section 20, Installation of Web Interfaces (H-Series and J-Series Only)

Describes requirements and procedure for installing DSM/SCM web interfaces


16 Managing Requests

This section describes managing requests. Topics discussed in this section include:

Submitting a Request on page 16-2

Types of DSM/SCM Requests on page 16-2

Scheduling a Request on page 16-2

Checking Requests on page 16-3

Restarting a Request on page 16-7

Canceling a Request on page 16-8

Deleting a Request (ZPHIHMI or ZPHITMI) on page 16-8


Managing Requests Submitting a Request

Submitting a RequestTo initiate any task in DSM/SCM, submit a request. You initiate requests from dialog boxes in the Planner Interface (Planner Interface) or menu commands in the Target Interface (ZPHITI), from which you set up, schedule, and submit a batch process.

You can run multiple requests concurrently and check the status of requests. If you exit DSM/SCM while a request is running, the request continues to run. You can reenter DSM/SCM while the request is running or after it finishes. When you are logged on to DSM/SCM, it displays status messages for requests.

Types of DSM/SCM RequestsThe types of DSM/SCM requests are:

Scheduling a RequestFor your convenience, you can schedule requests to run at any time:

1. From the dialog box on which you are preparing the request, click Scheduling. DSM/SCM displays the Request Scheduling Options dialog box (Figure 16-1). This dialog box presents two scheduling options: Now and Later.

Request Function For more information, see...

Receive Software

Receive software from RVUs, SPRs, or third-party distribution subvolumes into the DSM/SCM archive.

Section 7, Receiving and Managing Software Inputs.

Build orBuild/Apply

Build or Build/Apply a configuration revision for a target system and receive a snapshot of the new software from the target system.

Section 9, Building and Applying a New Configuration.

Receive Snapshot

Receive current status of DSM/SCM-managed files from a target system into the host database. Requested on a host system when systems do not have an Expand connection or when an independent snapshot is requested on a target system.

Task 9: Transfer and Receive the Snapshot Into the Host Database on page 9-27.

Prepare Reports and Documents

Format reports from the DSM/SCM database, and format softdocs and release documentation for printing or viewing online.

Checking Softdocs and Release Documents on page 8-10


Export Product Files

Copy and convert files DSM/SCM stored in internal archive format to standard system files.

Exporting Files From the Archive on page 17-24


Managing Requests Checking Requests

2. Schedule the request. To run the request immediately, by default no action is necessary. To schedule a later time for the request to run, click Later and enter a time and date using the format shown in the date and time fields.

3. Click OK. The request is submitted to run at the scheduled time.

Checking RequestsIn the Planner Interface, you can display a list of all requests for which a record currently exists in the database. These requests can be running, stopped prematurely, or finished. The last request submitted is first in the list.

Displaying the Request Window

The Requests window lists the request name, status, and ID of the planner who submitted the request for each request known to DSM/SCM. To display the Requests window:

1. From the Planner Interface, select a software input or configuration revision.

2. Select Requests>Requests list.

Note. The default time is immediately for all requests except the Apply request on systems connected to the host by Expand, where the default is to run immediately after the Build request finishes.

Figure 16-1. Request Scheduling Options Dialog Box

VST107.vsd


Managing Requests Restricting the Requests Displayed

Restricting the Requests Displayed

To restrict the request list:

1. From the Requests window, select View>View requests for. DSM/SCM displays the View Requests For dialog box, at the top of which is a summary of the choices.

2. Select the check boxes of the request types to be displayed:

3. To display requests for a specific planner:

a. Select the Show requests for planner check box.

b. From the list of planners, select the planner. (The default is to show requests for all planners.)

4. Select one or more check boxes to display requests with a specific status:

Any status not listed here is always displayed in the requests list.

5. Click OK.

Checking the Status of a Request

You can check the status of requests in the Planner Interface at two levels of detail:

For a status summary and current activity status details, open a request status window.

For detailed information, view EMS messages.

To check detailed status of a request:

1. From the Planner Interface, select Requests>Requests list.

Request Type Selects...

Inputs/Snapshots Receive Software and Receive Snapshot requests

Reports Prepare Softdocs, Prepare Release Documents, Prepare Reports, and Export Files requests

Configurations Build and Build/Apply requests.

All systems Build/Apply requests for all systems.

System Build/Apply requests for a specific system. Select a system from the list of systems.

Status Action

Processing Selects only requests that are still being processed.

Action required

Selects only requests that have stopped because they are restartable, nonrestartable, or awaiting a tape mount.

Completed Selects only requests that have finished processing (successfully or with errors).


Managing Requests Checking the Status of a Request

2. To open the Request Status window, use either of these methods:

Double-click a request name

Check the status details

a. Select a request name.

b. Click Status details.

The status display includes summary information for each stage of the request. You can minimize request status windows and later restore them for a quick status check. Status for the entire window is updated approximately every 90 seconds. The Request Status display includes:

The request description

The activity summary

For information on most messages that might appear in the activity summary, see Request Status Messages on page 16-6.

VST073.vsd


Managing Requests Checking the Status of a Request

The current activity status detail displays the current stage of the active request.

3. Click Show EMS events to check the messages issued by the request:

To check additional messages, click Refresh.

If necessary, exit the Planner Interface to correct any errors that occurred. Otherwise, click Close to return to the Request Status window.

Request Status Messages

The status messages that might appear in the request activity summary in the Request Status window are:

Message Meaning

Awaiting completion of activity

The request starts when a previous activity is done.

Awaiting receive snapshot Current status is not known until the snapshot is received. This message is issued by activities that are initiated on the host but performed on a target system.

Awaiting specified time to start The request is waiting for the scheduled start time.

Awaiting start The request is waiting for an internal DSM/SCM component to begin processing.

Cancelled The planner canceled the request.

Complete or Completed Successfully

The request finished successfully.

Performing cancel processing The planner canceled the request, and the cancel activities are in progress.

Processing The request is running.

To be scheduled The activity is not yet initiated. This message is issued by subordinate activities of requests consisting of multiple activities.

activity was cancelled The planner canceled the request that initiated the activity. This message is issued by subordinate activities of requests consisting of multiple activities.

Use ZPHITI to get Target status

The Planner Interface cannot get information about target activities. To check the status, log on to the ZPHITI.


Managing Requests Restarting a Request

These messages indicate that an error occurred, user intervention is required, or both:

For more information about the status message for a particular request, check the EMS messages generated while the request was running. For a description of EMS messages related to DSM/SCM, see the DSM/SCM Messages Manual.

Restarting a RequestYou can restart DSM/SCM requests that the planner cancels or that stop in a restartable state. A restartable request is indicated by the message:

Processing stopped in a restartable state

To check the status of a request and restart it:

1. Check the status of the request. See Checking the Status of a Request on page 16-4.

Message Meaning

Awaiting operator tape mount

The request resumes when the tape is mounted.

Cancel processing stopped in restartable state

You canceled the request, but the cancel activity stopped before it could complete restoring DSM/SCM to a consistent state. After taking corrective action, you can restart the cancel. You must correct the problem before attempting further DSM/SCM activities.

Cancel processing stopped in nonrestartable state

You canceled the request, but the cancel activity stopped before it could complete restoring DSM/SCM to a consistent state. An internal error probably occurred, which might require assistance from HP support. You must correct the problem before attempting further DSM/SCM activities.

After diagnosing the problem, use the Maintenance Interface to delete the request.

Complete with warnings

The request completed successfully, but conditions occurred that might affect the results.

Complete with errors

The request completed, but conditions occurred that require attention.

Processing stopped in restartable state

The request stopped before it completed. Take corrective action and then restart the request.

Processing stopped in nonrestartable state

The request stopped before it completed. An internal error probably occurred, which might require assistance from HP support. Correcting the error might require Maintenance Interface activities.

After diagnosing the problem, cancel the request. If the cancel fails, use the Maintenance Interface to delete the request.

Note. If you must use the Maintenance Interface to correct an error, first close all open Planner Interface windows (except the main window).


Managing Requests Canceling a Request

2. To restart the request, select Requests>Restart request.... You do not need to reenter any data required by the request. If the request is stopped in a restartable state, DSM/SCM determines the last stage of the request that completed successfully, cleans up any partial processing of the failed stage, and continues processing at the beginning of the previously failed stage. If the request was cancelled, processing starts over.

Canceling a RequestYou can cancel most requests any time after they start. DSM/SCM executes the cancel request when it finishes its current processing and undoes all completed processing, returning DSM/SCM to its state before the request was submitted. If a request is scheduled to start later, the cancel takes effect at the later start time. If a request must complete processing at the current stage before it can be canceled, a delay might occur before the cancel takes effect. To cancel a request:

1. Select Requests>Requests list....

2. Double-click a request name to open the Request Status window.

3. Select Requests>Cancel request....

After DSM/SCM detects the cancel request, it stops all current processing, purges all files created by the activity, and rolls back all database changes caused by the activity. An EMS message is issued containing the planner or operator ID who initiated the cancel request. The request terminates with a status of canceled (restartable).

Deleting a Request (ZPHIHMI or ZPHITMI)To delete a request, use the ZPHIHMI or ZPHITMI. Requests that are in process (including those being cancelled or awaiting a tape mount or restart) cannot be deleted. All other requests can be deleted.

Deleting a request should be the last resort in resolving the problem that caused the request to stop. If you diagnosed the problem and tried canceling the request, delete it:

1. In the Planner Interface, close the request’s status window.

Because you can only delete requests from the Maintenance Interface, the Planner Interface might display an error message if you delete a request that it is examining. Closing the request’s status window prevents display of this message.

2. Log on to the ZPHIHMI or ZPHITMI.

Note. You cannot restart target system activities (such as an Apply) from the Planner Interface. You must use the ZPHITI and choose selection number 3 (Perform target activities). Also see Task 8: Apply Software to the Target System on page 9-25.

Note. You cannot cancel target system activities (such as an Apply) from the Planner Interface. You must use the ZPHITI.


Managing Requests Deleting a Request (ZPHIHMI or ZPHITMI)

3. On the main menu, enter 5 (Request Deletion) in the Selection Number field, and press F1.

4. DSM/SCM displays the Request Deletion screen, which lists all deletable requests.

5. To delete one or more requests, enter any character in the Selection field of the requests to delete, and press F6.

Side effects might result from deleting a problematic request. For example, if a Build/Apply request is deleted on the host system after the Build is complete, the Apply continues. The request is added back to the host system if the receive snapshot activity for this request is processed.


Managing Requests Deleting a Request (ZPHIHMI or ZPHITMI)


17 Managing DSM/SCM

You can perform management tasks in DSM/SCM using the Planner Interface, Maintenance Interface (ZPHIHMI or ZPHITMI), or Target Interface (TI), depending on the task. Whenever possible, use the Planner Interface because of its ease of use. It incorporates most functions of the other interfaces in one application.


Updating DSM/SCM Profile Information on page 17-2

Managing Volumes Used by DSM/SCM on page 17-11

Managing DSM/SCM Databases on page 17-16

Managing the DSM/SCM Archive on page 17-21


Managing DSM/SCM Updating DSM/SCM Profile Information

Updating DSM/SCM Profile InformationDSM/SCM profiles contain default information that DSM/SCM uses when processing requests. These defaults reduce the amount of information the planner must enter when using DSM/SCM. To update the defaults in the profiles, see:

Configuration Manager Profile on page 17-2

System Profile on page 17-4

Target Profile on page 17-6

Configuration Manager Profile

To process requests, the Planner Interface uses information in the Configuration Manager profile such as the default tape drive and a default disk drive for exporting files. The Configuration Manager profile is kept in the host database. You can use either the Planner Interface or the ZPHIHMI to modify the Configuration Manager profile.

Updating the Configuration Profile (Planner Interface)

1. From the Configuration Revisions window, select the system you are configuring.

2. Select Maintain>Configuration manager. DSM/SCM displays the Configuration Manager Profile dialog box.

3. From the Configuration Manager Profile dialog box, update the configuration profile. See Configuration Profile Information on page 17-3

4. Click OK to exit.


Managing DSM/SCM Configuration Manager Profile

Table 17-1. Configuration Profile Information

Parameter Description

Default tape drive Select a tape drive name from the list or enter a tape drive name. Specifying the node name is optional. The default is the host system node.

You must specify a drive that is compatible with your SUTs and with the other systems in your network. For example, if a host system uses a cartridge tape drive, its target systems must also use cartridge drives.

By default, DSM/SCM uses this tape drive on the host for any task that requires a tape. For example, DSM/SCM uses this tape drive for software received on tape and for any activation packages and snapshots written to tape. You can override the default when you submit a DSM/SCM request.

Number of days to retain request

This parameter specifies the number of days that completed or canceled requests are kept in the DSM/SCM database. These requests are deleted at the end of the retention period. Typically, three to five days is sufficient. (Your site might dictate a particular period to satisfy specific auditing requirements.) The default is 14 days.

Default output location for files exported from the archive

Select a name from the list or enter a volume name. Specifying the node name is optional. The default is the host system name.

Default file output location for reports and softdocs

DSM/SCM sends reports and softdocs formatted for online viewing to this location. You must enter the volume and subvolume. Specifying the node name is optional. The default is the host system node.

Spooler or file name

Default spooler output location to which DSM/SCM sends reports and softdocs prepared for printing

Specifying the node name is optional. The default is the host system. If you simply enter a location of [\node.]$device, DSM/SCM appends #DEFAULT to the location name.

Set the Compress Software in Archive flag

Specify whether to compress software stored in the archive. Make sure your entry matches what you specified in INITENV.


Managing DSM/SCM System Profile

System Profile

Whether you maintain system profiles from the host or target systems depends on whether your site practices centralized or local system management.

You can update system profile information from either:

The Planner Interface or ZPHIHMI on a host system.

After changing a target or system profile on a host system, send the updated information to the target system in an activation package to synchronize the target database.

The ZPHITMI on a target system.

After changing a profile on a target system, generate an independent snapshot containing the new profile information and transfer the snapshot, either manually or automatically, to the host system to update the host database.

Updating the System Profile Information (Planner Interface)

1. Log on to the planner interface using the DSM/SCM user ID.

2. From the Configuration Revisions window, select a new configuration.

3. Select Maintain>System maintenance.

4. Select Add, Modify, or Delete:

To add system profile information, select Add.

To change system profile information, select Modify.

To delete system profile information, select Delete.

DSM/SCM displays the System Maintenance Profile window.

5. From the System Maintenance Profile window, click OK to return to the Configuration Revisions window.

Updating the System Profile Information (ZPHIHMI or ZPHITMI)

1. Log on to the ZPHITMI or ZPHIHMI using the DSM/SCM user ID. See Maintenance Interfaces on page 2-6. DSM/SCM displays the ZPHITMI or ZPHIHMI main menu.

2. Select 1 (System Maintenance); then press F1. DSM/SCM displays the System Maintenance screen.

3. From the System Maintenance screen, enter the name of the system (including the backslash); then press F2. DSM/SCM displays the profile information for the system.


Managing DSM/SCM System Profile

To update the default values, review the system profile information and change as needed. See Table 17-2, System Profile Information, on page 17-5.

To delete a system from DSM/SCM, press F6

To view the profile for the next system in the list, press F3.

4. For host systems, press Shift-F4 to list all the target systems managed by DSM/SCM. Use PgUp and PgDn to page through the list.

5. Press Shift-F2 to enter any changes.

6. Press F16 to return to the main menu.

Table 17-2. System Profile Information

Parameter DescriptionPlanner Interface

Maintenance Interface

Host or physical target system name

Name including \ backslash for this system.

Default for this system is displayed.

System Site ID A unique 6-digit number that identifies this system. If you do not know the system site ID, see Checking the Site ID on page 5-3.


CPU Type One of these processor types:

TNSE for Intel Itanium processors TNSR for RISC processors TNS for CISC processors


Use network connection

Use this option to write the activation package and snapshot to disk. You must select this option for a logical target on a host system. You can select this option for a target system if it has an Expand connection available for DSM/SCM to use. If you do not select this option, the activation package and snapshot are written to tape.

Select or clear the check box.

Y or N

Safeguard is required to be running/Safeguard required flag

Use this option to require that Safeguard must be running whenever DSM/SCM places files. This option is usually not checked.


Y or N

Host system that manages this target.

This parameter is displayed for physical target systems only


Tape unload flag DSM/SCM functions that perform tape processing are to unload their tape when finished processing


Y or N


Managing DSM/SCM Target Profile

Target Profile

Updating theTarget Profile (Planner Interface)

To update the profile information for a logical target:


2. From the Configuration Revisions window, select the target configuration. For a new target, the name has the form:

\system_name DEFAULT

3. Select Maintain>Target maintenance>

To add system profile information, select Add.

To change system profile information, including to activate or deactivate OSS file management, select Modify.

To delete system profile information, select Delete.

DSM/SCM displays the Target Information dialog box.

4. Add or change the description of the target as needed. A brief description of the logical target helps users distinguish it from other logical targets. There is no default description.

5. To enable or disable DSM/SCM management of OSS files, select or clear the Manage OSS Files check box.

6. Change the output and target system generation defaults as necessary:

Setting the Target Output Defaults on page 17-7

Setting the Target System Generation Defaults on page 17-9.

VST058.vsd



7. When you have finished making all changes, click OK in the Target Information dialog box to return to the Configuration Revisions window.

8. After changing a target profile on a host system, send the updated information to the target system in an activation package to synchronize the target database.

Setting the Target Output Defaults

After you run INITENV with the initialize option, you must specify the output values. Otherwise, you can review the defaults and change as necessary.

1. From the Target Information dialog box, click Output. DSM/SCM displays the Output Defaults dialog box.

2. From the Target Output Defaults dialog box:

a. Enter values in the data fields as needed (Output Defaults on page 17-7).

b. When finished, click OK to return to the Target Information dialog box.

Table 17-3. Output Defaults (page 1 of 2)


Output location for target reports

The subvolume location for reports to be viewed online. When you request a report, you can override this default.

Volume for activation package/snapshot

The location for activation packages transferred from the host system and snapshots. The default is $DSMSCM.

VST610.vsd



Target volume for new subvolumes

The volume in the logical target where new subvolumes created during DSM/SCM processing are placed. The default is $SYSTEM.

Guardian defaults for new files

The DSM/SCM user ID is the default owner for all new files on the logical target. Files that replace existing files assume the same ownership as the old file. For information the default for the DSM/SCM user ID, see Setting the DSM/SCM User ID on page 5-8.

Security is the default security settings for all new files on the logical target. The default is NCNC. Files that replace existing files assume the same security as the old files.

Include in activation package

By default activation packages do not include EMS template source files, SPI definition files, or privileged declaration files. To include any of these types of files, choose these options:

Include EMS template source files in activation package

Include SPI definition files in activation package

Include privileged declaration files in activation package

Table 17-3. Output Defaults (page 2 of 2)




Setting the Target System Generation Defaults

After you run INITENV with the initialize option, you must specify the output values. Otherwise, you can review the defaults and change as necessary.

1. From the Target Information dialog box, click SYSGEN. DSM/SCM displays the SYSGEN Defaults dialog box:

2. From the SYSGEN Defaults dialog box:

a. Enter values in the data fields as needed (Table 17-4, System Generation Information, on page 17-10).

b. From the SYSGEN Defaults dialog box, click OK to return to the Target Information dialog box.

VST611.vsd



Table 17-4. System Generation Information


CONFTEXT file name

The default location where the configuration (CONFTEXT) file is placed during a Build. The default is $SYSTEM.SYS00.CONFTEXT. For example:

$SYSTEM.subvolume.CONFTEXT

Expand CONFTEXT DEFINE statements

For G-series, H-series, and J-series RVUs, the DEFINE statements are optional in the CONFTEXT file. DEFINE statements set up string variables. The default is to not expand them. Expanding could speed processing time during system generation but makes the CONFTEXT file significantly larger. To uncompress the DEFINE statements in the CONFTEXT file, select the check box for this option. In most cases, you should leave the check box for this option cleared.

SYSGEN work file locations

Use this option to change the default for system generation work files.

None specified

Temporary

Permanent

The work files are created when a system generation program and BINDER are processing. By default, a system generation program manages the temporary work files it uses. If you do not use the default, you must specify a location. For example:

None specified

System generation report location

A spooler location for reports to be printed. The spooler must allow for 132-column formatted output. The default is $S.#SYSGEN. If system generation is required for a Build, check that the spooler is running. You can override the default locations you specify here when you request a report. For example:

$S.#SYSGEN

Create optional system image tape

For Integrity NonStop systems, this option is not available, and you cannot create a SIT.

For NonStop S-series systems, a SIT is not needed in normal DSM/SCM system installation functions. You can create an optional SIT as a precaution for disaster recovery, but it is not essential in most cases. The default is to not create a SIT. In most cases, you can leave this option unchecked.


Managing DSM/SCM Managing Volumes Used by DSM/SCM

Managing Volumes Used by DSM/SCMTo address space or organizational issues on your system, you can manage the volumes used by DSM/SCM on your system:

For information about the preinstalled DSM/SCM configuration, see Required Processes and Files on page D-1, which specifies the subvolumes and files DSM/SCM uses that must not be purged or altered under any circumstances.

Updating the Volume Usage

You can update which volumes DSM/SCM uses for the archive or as scratch volumes:

Scratch volumes

The default scratch volume is $DSMSCM. You can use any volume with sufficient free space. DSM/SCM cleans up and reuses the temporary space during each session.

Archive volume

The default archive volume is $AUDIT. You must allow an entire volume for archive storage. The DSM/SCM archive and databases must be on volumes with names of no more than seven characters ($xxxxxx) because DSM/SCM supports multiple RVUs. The archive volumes must be network accessible to the system.

To update the system volume usage information:

Use the Planner Interface or ZPHIHMI for disk volumes on a host system. A host system volume can be a scratch volume, archive volume, or both.

Use the Planner Interface or ZPHITMI for disk volumes on a target system. A target system volume can only be a scratch volume.

Procedure Page

Updating the Volume Usage 17-11

Moving the ZDSMSCM Subvolume to Another Volume 17-13

Renaming a Volume Managed by DSM/SCM 17-14

Deleting a SYSnn Subvolume 17-15

Note. To improve system performance on NonStop S-series systems and Integrity NonStop systems, configure each volume used for the archive for free-space table (FST) caching. For information about specifying the FSTCACHING modifier, see the SCF Reference Manual for the Storage Subsystem.

Note. To improve system performance, configure free-space table (FST) caching for each archive volume. For information about specifying the FSTCACHING modifier, see the SCF Reference Manual for the Storage Subsystem.


Managing DSM/SCM Updating the Volume Usage

Updating the Volume Usage (Planner Interface)

To change volume usage information


2. From the Configuration Revisions window, select the system you are configuring.

3. Select Maintain>Volume maintenance. DSM/SCM displays the Volume Usage dialog box, listing host system DSM/SCM volumes, including whether the volume is a scratch volume, archive volume, or both.

4. From the Volume Usage dialog box, review the host system volume usage.

5. Change the volume usage as needed:

a. From the Volume Usage dialog box, select a volume name.

b. Click Change Usage.

c. From the Volume Usage Flag dialog box, click the appropriate usage check box. You can check archive, scratch, both, or neither.

d. From the Volume Usage Flag dialog box, click OK to submit the changes.

e. From the Volume Usage dialog box, click OK to exit.

Updating Target Volume Usage (ZPHITMI and ZPHIHMI)

Review the target volume usage; update if you need to set up the scratch volumes to be different from the default values.

1. Select 2 (Volume Maintenance); then press F1. DSM/SCM displays the Volume Maintenance screen, listing the volumes accessible on the system.

2. Specify the volume usage (scratch or not used by DSM/SCM).

3. Press Shift-F2 to enter the data.


Note. Although you can use a disk volume with a duplicate set of primary and alternate names run on the system, DSM/SCM ignores the volume and excludes it from the list of volumes displayed by the ZPHITMI.


Managing DSM/SCM Moving the ZDSMSCM Subvolume to Another Volume

Moving the ZDSMSCM Subvolume to Another Volume

You should normally use the first ZDSMSCM subvolume installed on the system, regardless of how many subvolumes are created by subsequent additions of targets. However, you can run DSM/SCM from a volume other than the one on which INITENV was run. You can create ZDSMSCM subvolumes on other volumes, but the subvolume name cannot change.

Creating a New ZDSMSCM Subvolume

To change ZDSMSCM subvolumes:

1. Copy the existing ZDSMSCM subvolume to a new volume:

> FUP DUP $oldvol.ZDSMSCM.*, $newvol.*.*,saveall

2. Edit the PATHCOOL file to point to the $newvol.PATHSCM and the \system.$newvol.ZDSMSCM.PATHMAIN.

3. Replace all occurrences of $oldvol.ZDSMSCM with $newvol.ZDSMSCM in the PATHTARG or PATHHOST file.

4. Run PATHCOLD from $newvol.ZDSMSCM to create $newvol.PATHSCM.*.

5. Run STARTSCM from $newvol.ZDSMSCM.

6. Update Winsock with the new volume name:

a. Edit the $vol.ZTCPIP.PORTCONF file to point to $newvol.ZDSMSCM.

b. Cycle the TCP/IP LISTNER process. For more information, see the TCP/IP documentation.

7. Run Verify Database. (See Verifying the Target System Database (ZPHITI) on page 17-18.)

8. Create an independent snapshot. (See Creating an Independent Snapshot of the Target System on page 17-19.)

9. Receive the snapshot into the host database. (See Task 9: Transfer and Receive the Snapshot Into the Host Database on page 9-27.)

To purge $oldvol.ZDSMSCM.* after you have confirmed that DSM/SCM is running properly, use the new ZDSMSCM subvolume. After purging an old ZDSMSCM subvolume, repeat Steps 7 through 9.


Managing DSM/SCM Renaming a Volume Managed by DSM/SCM

Switching From One ZDSMSCM Subvolume to Another

To switch from one ZDSMSCM subvolume to another:

1. Check that both ZDSMSCM subvolumes (the one you are using and the one you will switch to) contain the same version of DSM/SCM.

2. Copy the INITSTAT, PATHCOOL, and PATHTARG (or PATHHOST if this is the host system) files from the $oldvol.ZDSMSCM subvolume to the $newvol.ZDSMSCM subvolume you are switching to.

3. Place these files with proper security under the proper owner.

4. Edit the PATHCOOL file to point to the $newvol.PATHSCM and the \system.$newvol.ZDSMSCM.PATHMAIN.

5. Replace all occurrences of $oldvol.ZDSMSCM with $newvol.ZDSMSCM in the PATHTARG or PATHHOST file.

6. Run PATHCOLD from $newvol.ZDSMSCM. This creates $newvol.PATHSCM.*.

7. Run STARTSCM from $newvol.ZDSMSCM.

8. Use the FUP GIVE command to give ownership of the CBEXE program to the super ID (255,255).

9. Set the PROGID of the CBEXE program to the super ID (255,255).

10. Use the FUP GIVE command to give ownership of the TAEXE program to the super ID (255,255).

11. Set the PROGID of the TAEXE program to the super ID (255,255).

Renaming a Volume Managed by DSM/SCM

If a volume contains any ZPHI6030 files, it has files that DSM/SCM manages. To avoid problems running DSM/SCM if you rename such a volume, update DSM/SCM at the same time to recognize the new volume name.

To change the name of a volume that contains DSM/SCM managed files:

1. Rename $oldvol to $newname:

> RENAME $oldvol, $newname


Managing DSM/SCM Deleting a SYSnn Subvolume

2. Run Verify Database. (See Verifying the Target System Database (ZPHITI) on page 17-18.)

3. Create an independent snapshot and transfer it to the host. See Creating an Independent Snapshot of the Target System on page 17-19.

Deleting a SYSnn Subvolume

You can manually delete a SYSnn subvolume that represents the previous or current configuration. Deleting the previous SYSnn subvolume prevents you from being able to back out to the previous revision. Deleting the current SYSnn subvolume removes that logical target from the target database.

1. Delete the SYSnn subvolume.

2. Run Verify Database before the next Apply is run on the system. (See Verifying the Target System Database (ZPHITI) on page 17-18.)

Note. If $DATA00 is a scratch volume, Verify Database stops in restartable mode, giving an EMS message that no scratch volumes are configured on the target system. Define at least one scratch volume using the Target Maintenance and restart the Verify Database activity. After the successful completion of Verify Database, update the volume usage information using the ZPHIHMI also.

If $DATA00 is an archive volume, update the volume usage information using the ZPHITMI and ZPHIHMI after successful completion of Verify Database.

For more information, see Updating the Volume Usage on page 17-11.

Note. Verify Database detects the volume rename by displaying the message that all the managed files have been moved from $OLDVOL to $NEWNAME and updates the database accordingly.

If a volume is deleted, Verify Database updates the database indicating that all the managed files that were on the volume $OLDVOL, no longer exist.


Managing DSM/SCM Managing DSM/SCM Databases

Managing DSM/SCM Databases

Canceling the Check-Out of a Database Object

In normal DSM/SCM processing, a user or request that checks out these objects from the DSM/SCM database has exclusive access to the object:

The Configuration Manager profile

Target system profiles

Software inputs

Configuration revisions

No other user or request can access that object to update the DSM/SCM database until it is no longer checked out. You might cancel a check-out when an error has occurred or when a user leaves an activity unattended for an extended period, preventing other users and requests from updating the database.

When a check-out is canceled, the work in progress is lost, and the database is returned to the state it was in before the activity was initiated. If the check-out was caused by a DSM/SCM request, try to cancel the request before canceling the check-out. (See Canceling a Request on page 16-8.) If the check-out was caused by an activity other than a request, all database cleanup is automatic.

Using the Maintenance Interface, you can cancel the check-out of objects on either the host or target system:

1. On the main menu, enter a 4 (Check-Out Cancellation Management) in the Selection Number field, and press F1. DSM/SCM displays the Check-Out Cancellation Management menu.

2. On the Check-Out Cancellation Management menu, enter one of these numbers in the Selection Number field, and press F1:

DSM/SCM displays a Check-Out screen for the item you selected. The screen lists the items that have been checked out and the user ID or activity ID holding the check-out. If no items are checked out, an advisory message appears.

Note. Before canceling the check-out of an object, be sure the planner or operator who checked out the object is not available to complete the task. Cancel the check-out only if you cannot free the resource any other way.

1 To see if the Configuration Manager profile is checked out

2 To display a list of checked-out target system profiles

3 To display a list of checked-out software inputs

4 To display a list of checked-out configuration revisions


Managing DSM/SCM Moving a DSM/SCM Database (ZPHIHMI or ZPHTMI)

3. To cancel the check-out of the Configuration Manager profile, from the Configuration Manager Profile Check-Out screen, press F4.

To cancel the check-out of a target system profile, a software input, or a configuration revision, on the appropriate Check-Out screen, enter any character in the Selection field of each item to cancel the check-out; then press F4.

Moving a DSM/SCM Database (ZPHIHMI or ZPHTMI)

You can move the DSM/SCM database from one volume to another on the same system using the ZPHIHMI or ZPHITMI.

DSM/SCM databases must be on volumes with names of no more than seven characters ($six-characters) because DSM/SCM supports multiple RVUs.

To move a host or target database:

1. Make sure the Planner Interface is not running.

2. Stop all servers through PATHCOM and all processes running from PHIHDBMG (PHITDBMG for a target database).

3. On the Maintenance Interface main menu, enter 6 (Database Relocation) in the Selection Number field, and press F1. DSM/SCM displays the Database Relocation screen.

4. On the Database Relocation screen:

a. Enter the name of the volume where the database currently resides.

b. Enter the name of the new volume for the database.

c. Press F1.

DSM/SCM moves the database and recompiles the programs with embedded SQL statements it uses. The recompile can be time consuming. The Maintenance Interface waits for the compile to finish. You cannot perform other DSM/SCM activities during the compile.

Results of the database relocation are written to the file DBRELOUT in the ZDSMSCM subvolume.

5. After relocating the database, run STOPSCM and STARTSCM to update the DSM/SCM PATHMON servers with the location of the database.

Note. To update the location of the DSM/SCM SQL catalog, the user performing the relocate must have permission to access the SQL system catalog.

To improve system performance, keep the databases and archive on different volumes.


Managing DSM/SCM Updating DSM/SCM Databases

Updating DSM/SCM Databases

You might need to perform these activities periodically to ensure the target database is updated and synchronized with the host database. Keeping the databases updated and synchronized is crucial for effectively managing your system configuration.

1. Update a target database with the information regarding all TSVs. See Verifying the Target System Database (ZPHITI) on page 17-18.

2. Create an independent snapshot. See Creating an Independent Snapshot of the Target System on page 17-19.

Verifying the Target System Database (ZPHITI)

Verify the target database after volume or subvolume operations are performed outside of DSM/SCM, such as:

Deleting a SYSnn

Moving, copying, or renaming TSVs

Moving, modifying, or adding files to subvolumes on the target system

Adding, deleting or renaming a volume

Verifying the database ensures that the target database contains correct TSV information by:

Verifying the location of TSVs and files on the target system

Updating the target database with the correct locations and names of the TSVs if any TSVs have been moved, copied, or deleted

Determining whether files have been deleted (It does not check whether a file has been moved.)

To verify a target system database:

1. At the ZPHITI main menu, enter 5 (Perform database verify) in the Selection number field, and press F1. DSM/SCM displays the Verify Database - Submit Request screen.

2. From the Verify Database - Submit Request screen, press F1 to submit the request. DSM/SCM displays the Processing Verification screen, which shows status information about the progress of the request:

The screen is updated with current status information every 15 seconds.

While waiting for the request to finish, to view current request-related EMS messages, press F4.

You cannot submit any other DSM/SCM requests while a Verify Database request is running.


Managing DSM/SCM Creating an Independent Snapshot of the Target System

When the Verify Database request finishes successfully, DSM/SCM displays an informational message.

Creating an Independent Snapshot of the Target System

A snapshot of a target system provides current target database information to transfer to the host system and receive into the host database. With current information about the target contents, DSM/SCM can keep the host and target databases synchronized, which is crucial to effective system configuration management. You should create a snapshot after most DSM/SCM tasks on a target. A snapshot includes:

The physical target name

The SYSnn and configuration name of each logical target on the target system

The TSV locations associated with each logical target

File attributes, including fingerprints of each managed file on the target system

Activity records from the target system

The target’s EMS messages

Target system profile information

Disk and tape device locations on the target system

Name and timestamp of when the snapshot was generated

If you submit a Build/Apply request, a snapshot is automatically created, transferred to the host system, and received into the host database. The planner might request an independent snapshot for one of these reasons:

Software on the target system has changed outside of a Build/Apply.

The host snapshot is lost or corrupted.

Note. If $DATA00 is a scratch volume, Verify Database stops in restartable mode giving an EMS message that no scratch volumes are configured on the target system.

Define at least one scratch volume using the Target Maintenance and restart the Verify Database activity.

After successful completion of Verify Database, update the volume usage information using the ZPHIHMI also.

If $DATA00 is an archive volume, after successful completion of Verify Database, update the volume usage information using the ZPHITMI and ZPHIHMI.

For more information, see Updating the Volume Usage on page 17-11.

Note. When it receives a snapshot from a target system, DSM/SCM creates a configuration report that lists each logical target, its products, and SPRs applied to the products on the target. DSM/SCM then notifies the OSM application, which in turn creates a Software Configuration Incident report and delivers it to the GCSC.


Managing DSM/SCM Creating an Independent Snapshot of the Target System

The host and target databases are not synchronized because of a recent DSM/SCM process; for example, after an audit or database verification was performed on the target system.

To create an independent snapshot of a target system:

1. At the ZPHITI main menu, enter 2 (Perform system snapshot) in the Selection number field and press F1. DSM/SCM displays the Create Snapshot - Submit Request screen, showing the snapshot default location – the last snapshot location used for that system. There is no configurable default snapshot location.

2. If necessary, change the location where the snapshot is to be placed. You can specify either a tape drive or disk location (node and volume). If you specify disk, DSM/SCM places the file on the ZPHISNAP subvolume and supplies the file name.

3. Press F1 to submit the request. DSM/SCM creates the snapshot. While the request is processing, DSM/SCM displays the Create Snapshot - Taking Snapshot screen, which shows the request status and the snapshot file location.

The screen is updated with the current status approximately every 15 seconds.

While the request runs, to view current EMS messages related to the request, press F4.

4. After submitting the request, you can return to the main menu (F16) or leave the ZPHITI (Shift-F16). You can leave the ZPHITI while the request is running and return while it is still running or after it has completed. When you reenter the ZPHITI, the current request appears.

When the request is finished, DSM/SCM displays a completion message.

5. Send the current independent snapshot of the target database to the host system.

The Snapshot might be automatically transferred to the Host system after the Snapshot is successfully created. Transfer depends on the value of the "Use Network Connection" flag set using the ZPHITMI:

If this flag is set to Y and the Host and Target are Expand connected, the Snapshot is automatically updated into the Host database as part of the Independent Snapshot request.

If the flag is set to Y and the Host and Target are not Expand connected, the attempt to send the Snapshot to the Host system fails.

If the Host and Target are not Expand connected or if the "Use Network Connection" flag is set to N on the target, immediately transfer the snapshot to the host system on tape or, if you stored the snapshot on disk, use a file-transfer process. On the host system, receive the snapshot into the host database.

6. Receive the snapshot of the target database into the host database to update it. See Task 9: Transfer and Receive the Snapshot Into the Host Database on page 9-27.


Managing DSM/SCM Managing the DSM/SCM Archive

Managing the DSM/SCM ArchiveThe three areas of managing the DSM/SCM archive and its contents are:

Managing Files (Software Inputs) in the Archive

To efficiently manage archive space, first understand how DSM/SCM archives files. To optimize archive space, DSM/SCM ensures files are not duplicated in the archive. If two inputs contain identical files, as often occurs, the files are stored with the first archived input and are referenced by pointers in the second archived input. This saves considerable archive space. However, when an input is deleted or backed up, any files common to other inputs or configuration revisions are not removed from the archive. Therefore, deleting or backing up archive contents to manage disk space used by the archive might not save as much space as you expect.

If any configuration revision references files are associated with a software input, you cannot delete that input until you delete the revision. When you try to delete an input, DSM/SCM determines whether a configuration references any files associated with it. However, you can back up the input, which returns any space not shared with other inputs.

In Figure 17-1, the archive contains inputs from two RVUs: X20.00 and X20.01. Typically, most files do not change between RVUs. In this case, RVU X20.00 contains 450 files, and RVU X20.01 contains 460 files, with 20 new files and 10 files deleted. 440 files are identical in the two inputs.

Managing Files (Software Inputs) in the Archive 17-21

Exporting Files From the Archive 17-24

Moving the DSM/SCM Archive (ZPHIHMI) 17-27

Figure 17-1. Files in the Archive

SUTX20.00

Archive

450 Files

20 Files

SUTX20.01

460 files =

20 new files

10 files deleted

VST055.vsd


Managing DSM/SCM Managing Files (Software Inputs) in the Archive

The 440 identical files are stored with the first input and referenced by pointers from the second input. The 20 new files are the only additions to the archive for the second input. If you delete RVU X20.00, only the 10 files not referenced by X20.01 are removed from the archive. The 440 shared files remain.

To determine which configurations use a specific product in the archive, generate a Configurations Using a Product report. (See Section 18, Generating DSM/SCM Reports.) Configuration revisions in DSM/SCM also reference files in the archive. A configuration revision is a set of pointers in the database to files in the archive. The archive also stores the system generation output for configurations, including the OSIMAGE file, which can be quite large.

Estimating Freed Disk Space (ZPHIHMI)

To estimate the maximum amount of disk space that a backup or deletion frees:

1. On the ZPHIHMI main menu, enter 9 (Archive Maintenance); then press F1. DSM/SCM displays the Archive Maintenance screen.

2. Enter the software input name or configuration revision name; then press F5.

3. In case an error “DSM/SCM could not find needed information in database” occurs, rename the Software Input from the Planner Interface. To rename follow these steps:

a. In the Software in Archive window, select the Software to be renamed.

b. Select File > Show Software Input Description.

The Software Description window appears.

c. Under Software Name, enter the new name for the software and click OK.

d. Goto Step 1.

Backing Up a Software Input (ZPHIHMI)

Backing up a software input removes it from the archive and marks it in the database as backed up:

1. Check that no other DSM/SCM activities are running on the system.


3. Enter the software input name.

4. Enter the name of the tape drive to be used for the backup; then press F8.


Managing DSM/SCM Managing Files (Software Inputs) in the Archive

Deleting a Software Input (ZPHIHMI)

Deleting a software input removes it from the archive, and removes its entry from the database. However, you cannot delete an input that is referenced by any configuration revision.

To delete a backed-up input without first restoring it:

1. To find out which software inputs you can delete, generate the Configs Using a SW Input report. See Section 18, Generating DSM/SCM Reports.

2. Delete any configuration revisions that reference the input:

To delete an individual revision, see Deleting Old Software Revisions on page 8-24.

To delete an entire software configuration, removing all its revisions, see Deleting a Software Configuration (ZPHIHMI) on page 17-23.



5. Enter the name of the software input.

6. Press F6.

Deleting a Software Configuration (ZPHIHMI)

Deleting a configuration removes all of its revisions and returns an empty software configuration (with a revision level of 1) to the Planner Interface.


2. Log on to the ZPHIHMI. (See Entering the Maintenance Interface on page 2-7.)

3. On the ZPHIHMI main menu, enter 9 (Archive Maintenance); then press F1. DSM/SCM displays the Archive Maintenance Screen.

4. Enter the name of the software configuration to delete.

5. Press F6 to delete the configuration.

Restoring a Software Input (ZPHIHMI)

A backed-up input can be restored to the archive, but a deleted input cannot. Restoring an input from tape restores only files not already in the archive.


2. Enter the software input name.


Managing DSM/SCM Exporting Files From the Archive

3. If necessary, obtain the name of the backed-up input by using the FUP COPY command for the first 200 bytes of the tape.

4. Enter the name of the tape drive to be used for the backup tape; then press F9.

Exporting Files From the Archive

Exporting files copies and converts files stored in the DSM/SCM internal archive format to standard system files. Exported files are decompressed, renamed to standard name, and converted to a format that can be used on a NonStop system.

You cannot use standard file utilities on files stored in the archive because they are given unique internal file names and might be reformatted and compressed to conserve disk space. However, you can use an archive file outside the DSM/SCM environment. For example, if you perform network management from the host system, you can export a target system’s EMS template source files so you can modify them on the host system. You can then customize EMS event messages on the host.

Task 1: Select an Input or Revision

Select an input name in the Software in Archive window or a revision name in the Configuration Revisions window.

Task 2: Select Files to Export

You can export:

All the files or developer files in one or more products:

1. Select Products>List products....

2. Select one or more products.

One or more files from a product:

1. Select Products>List products....

2. Select a product.

3. Select Products>List files... .

4. Select one or more files.

Developer files from a software input or a configuration revision:

Go directly to Task 3: Create the Export Request.

Task 3: Create the Export Request

1. Select Requests>Export Files. DSM/SCM displays the Export Files Request dialog box, which is initialized with default values:


Managing DSM/SCM Exporting Files From the Archive

VSTA17.vsd


Managing DSM/SCM Bringing an Exported File Back Into the Archive After the File Has Been Modified

2. As necessary, change the values for:

The destination volume (enter the name or select one from the scrollable list).

The default security information.

Developer files: The developer file types (SPI definitions, EMS template source files, and Privileged declarations) are preselected. To clear a file type, clear its check box. You must select at least one type.

All files: The subvolumes to export files for. Scroll through the list and clear any subvolumes you do not want files exported for. Product files are put in their DSVs. Developer files are put in their TSVs, which are not in the list.

All files: The files to export. The default is to export all files. To export only developer files, click any combination of SPI definitions, EMS templates, or Privileged declarations. The Export subvolumes list is removed.

Product files: The DSVs that will contain the exported files. To omit files belonging to a particular subvolume from being exported, scroll through the list of DSVs in the dialog box and clear (Control-click) the subvolume.

Task 4: Schedule the Request

The default is to run immediately. To schedule the request for a later time:

1. Click Scheduling. DSM/SCM displays the Request Scheduling Options dialog box.

2. Schedule a later time; then click OK. DSM/SCM returns you to the Export Files Request dialog box.

Task 5: Submit the Request

Click OK. DSM/SCM processes the request as scheduled.

Bringing an Exported File Back Into the Archive After the File Has Been Modified

1. Run CNFGINFO.

2. Create a new A0CINFO file for the exported file.

3. Receive it into the archive as a separate SPR. The changed file does not replace the original file but can be handled like any other input and built into a new revision.

Note. If you cancel an Export Files request before it finishes, the files already exported remain on the disk. If you do not restart the request, you have to delete the files outside of DSM/SCM.


Managing DSM/SCM Moving the DSM/SCM Archive (ZPHIHMI)

Moving the DSM/SCM Archive (ZPHIHMI)

By default, the DSM/SCM archive on NonStop S-series systems and Integrity NonStop systems is located in the $AUDIT volume. If you need more space, you can move the DSM/SCM archive to a different volume. Moving the archive can provide more space for storing software inputs or other archive volume contents. Most users choose to move the archive to another volume when they configure DSM/SCM.

You can move a DSM/SCM archive volume or a set of archive subvolumes to another volume on any system network accessible to the target systems. If you move the archive, keep the databases and archive on different volumes if space allows. By default, the databases are kept separately on $DSMSCM. The archive must be on a volume with a name of no more than seven characters ($xxxxxx) because DSM/SCM supports multiple RVUs.

You must use ZPHIHMI to move a DSM/SCM archive volume or subvolume:

1. On the ZPHIHMI main menu, enter 8 (Archive Relocation), and then press F1. DSM/SCM displays the Archive Relocation screen.

Note. To improve system performance, configure free-space table (FST) caching for each archive volume. For information on specifying FSTCACHING, see the SCF Reference Manual for the Storage Subsystem.

VST067.vsd


Managing DSM/SCM Moving the DSM/SCM Archive (ZPHIHMI)

2. Enter the current node (optional), volume, and subvolume (if you are moving a single subvolume) in the From field, and press F5. In the Disk Space field, DSM/SCM shows an estimate of the maximum amount of disk space that moving the archive will free.

3. Move all archive subvolumes or the specified archive subvolume from the volume:

a. Enter the current node (optional), volume, and subvolume (if moving a subvolume) in the From field.

b. Enter the new node (optional) and volume in the To field.

4. Enter the current node (optional) and volume in the From field.

5. Enter the new node (optional) and volume in the To field.

6. Press F1 to change the volume.


8. Press Shift-F16 to exit the ZPHIHMI.

Note. Moving the archive might take several minutes. You cannot take further action until the move is finished.


18 Generating DSM/SCM Reports

This section describes DSM/SCM reports:

DSM/SCM Reports on page 18-2

Viewing and Printing DSM/SCM Reports on page 18-7

Creating Reports on page 18-10

Adding and Deleting Reports on page 18-15

Shorthand Views of the DSM/SCM Database on page 16

For information about generating a report on the requisite SPRs for a software update, see Creating Software Revisions on page 8-15.


Generating DSM/SCM Reports DSM/SCM Reports

DSM/SCM ReportsYou can generate a variety of reports to help you analyze software and resources managed by DSM/SCM. Report information describing the status of software configurations managed by DSM/SCM is extracted from the DSM/SCM database and formatted by SQL:

DSM/SCM reports are located at $volume.subvolume.ZZRScncc.

Custom Reports

Modifying standard reports and creating custom reports require detailed knowledge of SQL/MP report writer commands and syntax elements. See the SQL/MP Report Writer Guide.

Standard Reports

Standard DSM/SCM reports are preformatted with headers, footers, titles, number formats, and so on. You do not need special knowledge of SQL syntax or the Report Writer to produce standard reports.

Table 18-1 describes the contents and usage of the standard DSM/SCM reports.

Report Type Interface for Generating

Standard Planner Interface

System Target Interface

Table 18-1. Standard DSM/SCM Reports (page 1 of 5)

Report name Contents Usage

Configs Using a Product

Lists all configurations that reference a specified product.

To upgrade a particular product, use this report to find where the product is used.

Configs Using a SW Input

Lists all configurations that reference a specified software input.

Use to manage the archive by showing which software inputs can be deleted or backed up. To eliminate a particular input, you must eliminate the configurations that reference it.

Configuration Differences

Shows differences in product versions between two specified configurations, including products not in the second configuration.

Use to compare two configurations that are similar but were created from different inputs.


Generating DSM/SCM Reports Standard Reports

Configuration Product Files

Provides a detailed picture of the contents of a configuration by product, shows the TSV locations of all product files in the configuration, and gives the software input name for each product component file.

The specified configuration name, product name, product number, product version, base SPR number, and update SPR number appear at the head of each group of product version files.

If the logical target for the specified configuration manages OSS files, this report contains a second section showing each OSS files’ pax file, file type, and fully qualified OSS filename.

Use to determine what software versions exist on a system when you are planning an update.

Configuration Products

Lists the current set of products for a selected target.

Use to determine if a target contains the expected set of products.

Contents of All Configs

For all target systems managed by a particular host, lists each system’s logical targets, the products on each target, and the SPRs applied to those products.

Use to determine what software versions exist on many systems when you are planning an update. If you have several similarly configured systems, this saves you from creating several individual configuration reports.

Discrepancy Lists the differences between the latest snapshot for a specified target system and the most recently applied configuration on that system. Compares files expected to be placed on a logical target to the files actually on that logical target.

If the specified configuration manages OSS files, a second section of this report shows fingerprint discrepancies for OSS files. (Unlike TSVs in Guardian, TDLs cannot move, so they are not listed.)

Use when adding a new system to DSM/SCM. See Task 8: Accepting Discrepancies on page 5-37.





Input & Config Differences

Gives file information for files found in a specified DSM/SCM software input and in a specified configuration revision. Shows differences in file function, destination, and fingerprint.

The input name, configuration name, product name, product number, and product version appear at the head of each group of product version files.

Use to determine whether a given configuration contains everything from a given input and to determine what the differences are between the configuration and the input.

Replaced IPMs

Lists the SPRs replaced by the specified SPR associated with a selected software input. The new SPR contains everything in the old SPRs, so the old SPRs do not need to be included in the configuration with the new SPR.

Use when you are going to update a system with an SPR.

Request EMS Log Report

Lists all EMS messages related to a specified DSM/SCM request.

Use when a problem occurs with a given request.

Request log Shows the status of all DSM/SCM requests within a specified date range.

Use in times of heavy request activity to review the status of the requests.

Required IPMs

Lists the required SPRs for a selected SPR associated with a selected software input. Shows the chain of requisites through the last one in the archive.

The related configuration name, product name, product number, product version, and SPR number appear at the head of each group of requisite SPRs.

Use to determine the requisite SPRs to add to a configuration.





Required IPMs for a Group

Lists the minimum required SPRs missing in the selected software input (RVU) for all SPRs associated with the selected group.

This report does not list the requisite SPR of any SPR in the group if it is already in the software input.

The related configuration name, SPR number, and product name, number, and version are at the top of each group of requisite SPRs.

Use to determine the requisite SPRs to add to a configuration. Report parameters are the group name and software input name.

Run this report before overlaying a group on a RVU that was copied to a new configuration.

To include all SPRs in the group in the new configuration, copy the listed requisite SPRs to the new configuration before you overlay the group to the new configuration.

For this report, the software product group type must be Shared.

Software Contents

Lists the contents of a specified software input managed by DSM/SCM. Includes a description of each product in the input.

Use when managing many different inputs.

Software Product Components

Lists all SPRs available in the DSM/SCM archive for a specified product at a specified base RVU and names the software input that contains each SPR.

Use when determining a system’s software configuration or when performing archive maintenance.





Certain OSS files do not have fingerprints. For reports that list fingerprints, when they are generated where DSM/SCM manages OSS files, the fingerprint string for these special OSS files is (Not-Applicable-x), where x can be:

Software Product Files

Shows the destination of all files in all products contained in a specified software input.

The input name, product name, product number, product version, base SPR, and update SPR appear at the head of each group of product files.

For OSS products in the input, OSS files are listed after the Guardian files. The pax file, file type, and fully qualified OSS filename is shown.

Use when preparing to update a systems’ software configuration.

System Report

Lists all logical targets on the target system and all software managed by DSM/SCM in each logical target. Available only through the ZPHITI on a target system.

For each logical target that manages OSS files, OSS-managed TDLs are listed after the TSVs. For each file, the fingerprint and filename is shown.

Use for many tasks performed by an operator working on a target system.

Unused Input Lists the software inputs that have not been added to any configurations.

Use to determine if an input is used in an existing configuration. Helps you manage the archive by providing data on which inputs you can delete or back up.

X Description

D Directory

S Symbolic link

H Hard link

P FIFO




Generating DSM/SCM Reports Viewing and Printing DSM/SCM Reports

Viewing and Printing DSM/SCM ReportsDefault values are provided for the Report Request options.

Preparing a Report for Printing or Viewing

1. Select the report to view or print.

a. In the Planner Interface, select Requests>Prepare report....

DSM/SCM displays the Prepare Report Request dialog box. It lists the standard reports and any custom reports you have added to DSM/SCM.

b. Select a report from the list.

c. Click Description....

DSM/SCM displays the Show Report Description dialog box, which includes a three-line description of the report you selected, along with the report name and the location of the report’s IN_file.

d. Click OK to close the dialog box.

e. Click Continue....

DSM/SCM displays the Prepare Report Request dialog box, which contains formatting options and a list of any run-time parameters defined for the report:

VST131.vsd


Generating DSM/SCM Reports Preparing a Report for Printing or Viewing

2. Supply values for run-time parameters, as necessary.

(For example, the Software Contents report requires you to specify the name of a software input as a parameter. The report then lists the files contained in the specified software input.)

a. Select the parameter.

b. Click Modify parameter....

DSM/SCM displays the Modify Parameter Value dialog box, containing data fields set to the selected parameter’s name, type, value, and description.

c. Enter a value for the parameter in the Value field.

DSM/SCM validates entered data according to the rules for the parameter type. Parameters are case-sensitive.

d. Repeat the preceding three steps for each parameter to be given a value.

e. Click OK

DSM/SCM returns you to the Prepare Request dialog box.

3. Prepare the report.

For printing:

a. Check the Print formatted output location check box if it is not already checked.

b. To print the report at a location other than the default, enter a spooler name in the output location field, using standard HP spooler naming conventions.

For online viewing:

VST132.vsd


Generating DSM/SCM Reports Viewing a Report Online

a. Check the Viewable formatted file subvolume location check box if it is not already checked.

b. To write the report to a location other than the default, enter a subvolume name in the subvolume location field, using standard HP naming conventions:

If the host and target systems are network connected, the output location for target reports can be on the host system, the target system, or another system connected to both systems.

If the target system is not network connected to the host, the output location can be on the target system or another DSM/SCM system connected to it.

4. Schedule the request.

a. To change the default scheduling, click Scheduling; then schedule when to format the report for online viewing. See Submitting a Request on page 16-2. The default is to prepare the report immediately.

b. Click OK.

The report is prepared and formatted for online viewing, printing, or both, as scheduled. If it is prepared for online viewing, it is also added to the list of prepared reports.

5. Click OK to submit the Prepare Report request.

Viewing a Report Online

You can view only one report of a given type at a time. To view multiple reports of the same type, send them to the spooler or disk and view them in multiple windows using your terminal emulator package.

To view a report online:

1. After the Prepare Report request is completed, select File>View prepared documents.... DSM/SCM displays a list of reports and documents that have been prepared for online viewing.

2. Select the report from the list; then click View. DSM/SCM displays the selected report.

Note. The entire report runs twice (thus taking longer) if both the Print formatted output location and the Viewable formatted file subvolume location check boxes are selected.

Note. Reports formatted for viewing online are deleted from the list of viewable prepared documents at the end of the request retention period specified in the Configuration Manager profile. However, they remain in the subvolume they were written to. You must manually purge them from the subvolume.


Generating DSM/SCM Reports Creating Reports

Creating Reports

Modifying Standard Reports

You can modify any report in the DSM/SCM report list except:

You can modify reports in several ways:

Change the content, style, formatting, or description of a report.

Add parameters to or delete them from a report’s parameter list.

Change the type or description of a parameter.

Every DSM/SCM report is defined by an IN_file, which you can modify using a text editor. The IN_file contains:

An SQL SELECT statement that defines the contents of the report, specifying which data items to extract from the database

SQLCI Report Writer formatting commands that define the style and format of the report, including titles, headers, footers, margins, page breaks, and numeric formatting.

To change the format or contents of a report, you must edit the IN_file that contains the report definition, then update its parameters and description in the Planner Interface.

1. Edit the IN_file containing the report definition:

a. Go to the database subvolume containing the standard report you need to change.

The IN_file for the system report is in the SQL catalog subvolume, Xsystem-name, on target systems. For example, on \ALPHA, the IN_file is in subvolume XALPHA.

The IN_files for all other reports are in the database subvolume (XPHIHDB) on the host system. Actual IN_file names and locations are listed in the SQLCI Obey Filename field in the Maintain Report dialog box.

b. Copy the existing IN_file. This creates a separate, modified version of the report with its own title, description, and IN_file, making the original report available if needed by HP support personnel.

Discrepancy Report Required SPRs

Replaced SPRs System Report

Note. You must add, change, or delete a report parameter in both the SQL IN_file and the Planner Interface.

Note. The location of the database subvolume is established during the installation of DSM/SCM. If the host database is moved, so are the report IN_files.


Generating DSM/SCM Reports Modifying Standard Reports

c. Edit the new file. For more details on changing report formats, see the SQL/MP Report Writer Guide.

2. Bring the modified report file into DSM/SCM:

a. Log on to the Planner Interface.

b. Select Maintain>Report list. DSM/SCM displays the Maintain Report dialog, which shows the list of available reports.

c. Select the report being modified.

d. Change the report description:

1. Click Description. DSM/SCM displays the Modify Report dialog.

2. In the SQLCI report IN_file field, change the IN_file name to the name of the new IN_file containing the modified report definition (if you have created a new IN_file).

3. In the Description field, enter up to three lines of text describing the report. You can overwrite existing text.

4. Click OK.

e. Update the parameter list if you created a new report that has parameters or if you added or deleted any parameters when customizing a report:

1. Click Parameter list. DSM/SCM displays a list of parameters, including their names and descriptions.

2. Delete parameters from the list, as needed:

a. Select the parameter to delete.

b. Click Delete param. DSM/SCM prompts you to confirm or cancel the deletion.

3. Add parameters to the list, as needed:

a. Click Add param. DSM/SCM displays the Add Parameter dialog box. A message prompts you to add the parameter to the SQLCI IN_file and to make the parameter definition consistent with the definition in the IN_file.

b. Enter a name in the Parameter name field.

c. Scroll through the list of parameter types and select a type for the parameter you are adding.

d. In the Description field, enter up to three lines of text describing the parameter.

e. Click OK.


Generating DSM/SCM Reports Creating Custom Reports

f. Update the parameter type and description in DSM/SCM if you changed the type or usage of a parameter when customizing a report.

1. Click Parameter list.... (You can also click this button from the Modify Report dialog box.)

2. Select the parameter to modify.

3. Click Modify param....

DSM/SCM displays the Modify Parameter Definition dialog box, which contains a scrollable list of parameter types:

To change the parameter type, scroll through the list of types and select the new type.

To change the parameter description, enter up to three lines of text in the Description field. You can overwrite existing text.

4. Click OK.

g. Click OK.

Creating Custom Reports

To create customized reports, use the SQL/MP report writer. To create a custom report, create an IN_file outside of DSM/SCM that defines the report. The IN_file contains appropriate Report Writer formatting commands and a SELECT statement that extracts values from the DSM/SCM host database. DSM/SCM provides a set of shorthand views of its database that provide quick access to the database. (See Shorthand Views of the DSM/SCM Database on page 18-16.)

When creating custom reports, use parameters to generalize your reports. For example, this SELECT statement in a report’s IN_file selects the product names and numbers for a given software input:

SELECT P.PRODUCT_NAME, P.PRODUCT_NUMBER WHERE P.INPUT_NAME=?SW_INPUT_NAME

When you request the report whose definition contains this SELECT statement, specify a value for the parameter SW_INPUT_NAME. The SELECT statement selects the product name and number for a specific input name based on the value you specify. To later generate the same report for a different input name, pass the input name as a parameter.

Note. Avoid using INPUT_NAME, CONFIGURATION_REVISION, CONFIGURATION REVISION1, or CONFIGURATION_REVISION2 as parameter names. Some views used by standard reports use the SQL LIKE clause, which appends a % character to these parameter names before submission to SQLCI.


Generating DSM/SCM Reports Creating a System Report

To create a custom report:

1. Create a new IN_file, or make a copy of an existing DSM/SCM IN_file in the SQL catalog subvolume to use as a template.

If you do the latter, work from a copy of the IN_file. Do not modify the original IN_file.

2. Use a text editor to change the file. You can modify commands, syntax elements, and database fields to customize the information to include in the report:

To extract values from the database to include in the report, add a SELECT statement.

Modify the default format to any format you want.

Define parameters to use as input to the report.

3. Store the IN_file in the SQL catalog subvolume.

4. Add the report to DSM/SCM. (See Adding and Deleting Reports on page 18-15.)

Creating a System Report

A system report gives the planner a complete high-level picture of what software is on each target system and where the software is located. System reports are created at the request of a planner or as part of normal procedures for controlling changes to software revisions on a target system.The system report contains a list of:

All logical targets on the target system.

All software managed by DSM/SCM on a particular target system at a given time, including:

The name and location of every DSM/SCM-managed TSV (and TDL, if the specified logical target manages OSS files) in each configuration on the target system

The name and fingerprint of the files on each DSM/SCM-managed target subvolume

To create a system report:

1. At the ZPHITI main menu, enter 1 (Create system report) in the Selection number field, and press F1.

DSM/SCM displays the System Report screen.

2. Specify the output location for the report:

Note. Parameters in reports are case-sensitive. For example, a SELECT for \system is not the same as a SELECT for \SYSTEM. The parameter description provided with each report gives examples for all parameters. However, because reports are customizable, DSM/SCM does not try to determine the proper case for a parameter.


Generating DSM/SCM Reports Creating a Discrepancy Report for a Clone

To write the report to disk, enter the system, volume, and subvolume location and press F1. For example:

\devsys2.$dev2.data3

DSM/SCM assigns a file name to the disk file. The file name is returned in an EMS message.

To send the report to a spooler location, enter the spooler location and press F1. For example:

\devsys2.$s.#prt1

3. To return to the main menu, press F16. To exit the ZPHITI, press Shift-F16.

Creating a Discrepancy Report for a Clone

The standard process for generating a discrepancy report does not work for a clone system. Instead, use this process:

1. From the Target Interface on the clone system, start an Independent Snapshot.

The Host system receives the snapshot upon completion.

2. Create a new configuration for the clone, containing the software that you expect to be on the clone. (This software should be the software in the master’s configuration.)

3. Save the new configuration.

4. Run a discrepancy report.

5. After you finish with the discrepancy report, you might want to delete the configuration you created for this clone. Otherwise, repeated use of this procedure will result in multiple extraneous configurations.


Generating DSM/SCM Reports Adding and Deleting Reports

Adding and Deleting ReportsAfter you create an SQLCI IN_file defining a new report, you can add the report to the list of reports displayed in DSM/SCM. You can also delete from DSM/SCM any reports you no longer use.

Adding a Report to DSM/SCM (Planner Interface)

1. From the Planner Interface; select Maintain>Report list.

2. Click Add report. DSM/SCM displays the Add Report dialog:

Enter a name for the report in the Report title field.

In the SQLCI report IN_file field, enter the fully qualified name of the SQLCI IN_file you created to define the report.

In the Description field, enter up to three lines of text describing the report.

Define any parameters used by the report by clicking Parameter list....

3. Click OK. The new report is now included in the list of DSM/SCM reports.

Deleting a Report From DSM/SCM

Deleting a report from DSM/SCM does not delete the report’s IN_file. Cleanup of unused IN_files must be done outside DSM/SCM.

1. Select Maintain>Report list.

2. Select a report.

3. Click Delete. DSM/SCM displays a dialog box prompting you to confirm or cancel the deletion.

4. Click Yes to confirm the deletion. The report is removed from the list of DSM/SCM reports.


Generating DSM/SCM Reports Shorthand Views of the DSM/SCM Database

Shorthand Views of the DSM/SCM DatabaseShorthand views of the DSM/SCM database provide a means for selecting data from the database to include in the DSM/SCM reports you create, as described in Creating Custom Reports on page 18-12. Each view represents a subset of information in the database, organized in tables. For more information about the organization and structure of SQL databases, see the SQL/MP Report Writer Guide.

To reference a view, specify the view name and specific data items in an SQL SELECT statement.

For example, this TSV view contains TSV information for logical targets and target systems. The view consists of four columns of related data.

An example of a SELECT statement that references this view is:

SELECT TSV_VOL, TSV_NAME FROM =PHIH_TSV_SVIEW WHERE SYSTEM_NAME="\MAX" AND TARGET_NAME="SAT"

This statement selects from the TSV view the TSV volumes and TSV names for the target SAT on system \MAX. (=PHIH_TSV_SVIEW is the name of a DEFINE for the TSV view.)

You cannot alter the information given by the views, but you can alter the parameters and syntactical statements in the SQLCI IN_file to select the information you want and to create your own reports based on the views.

This subsection describes the DSM/SCM views and their column names. At the beginning of the table description, in parentheses, is the logical view name that you use to reference the view in a SELECT statement.

Activity Control View

The Activity Control View (=PHIH_ACT_CONTROL_SVIEW) contains information related to an internal DSM/SCM component’s processing of a request, as well as the descriptive text entered for the request by the planner or operator:

System_Name Target_Name TSV_Vol TSV_Name

\EASY DAY $GREECE ZEUS

\EASY NIGHT $GREECE PLUTO

\MAX WEEK $ATHENS ATHENA

\MAX SAT $ROME JUPITER

Column Name Description (page 1 of 2)

Activity_ID An identifier for the request

Activity_Code A code representing the type of request

Actual_End_Time The time at which the request completed

Actual_Start_Time The time at which the request was initiated


Generating DSM/SCM Reports Activity Code Descriptions

Activity Code Descriptions

Status Code Descriptions

Host_Node_Name The host system name, for activities run on the host

Operator_Logon If the request was submitted by a operator, the user ID of the operator

Planner_Logon If the request was submitted by a planner, the user ID of the planner

Request_Name The name of the request; for example, Receive Software

Request_Desc_Text Text describing the request

Stage_Code A code indicating the current processing stage of the request

Status_Code A code indicating the activity state; for example, Pending

Target_Node_Name The target system name, for activities run on the target system

Activity Code Activity Description Activity Code Activity Description

10 Build 125 Print softdoc

15 Initialization Build 130 View release doc

20 Apply 135 Print release doc

25 Initialization Apply 150 View user report

30 Backout 155 Print user report

40 Create snapshot 160 View target report

45 Independent snapshot 165 Print target report

50 Receive snapshot 170 View required SPRs

60 Input software 175 Print required SPRs

80 Receive snapshot 180 View report

90 Get preview text 185 Print report

100 Verify database 190 View replaced SPRs

110 Export files 195 Print replaced SPRs

120 View softdoc

Status Code Meaning

0 To be scheduled

100 To be scheduled

200 Processing

210 Performing cancel processing



Generating DSM/SCM Reports Activity Param View

Activity Param View

The Activity Param View (=PHIH_ACT_PARAM_SVIEW) contains additional information related to an internal DSM/SCM component’s processing of a request. It enables the internal components to monitor the processing of a request.

220 Awaiting specified time to start

230 Awaiting start

240 Awaiting operator tape mount

250 Awaiting completion of activity

260 Awaiting shutdown, rename, system load, and startup

300 Processing stopped in restartable state

310 Cancel processing stopped in restartable state

400 Processing stopped in nonrestartable state

410 Cancel processing stopped in nonrestartable state

500 Complete

510 Complete with warnings

520 Complete with errors

600 Cancelled

610 activity was cancelled

Column Name Description

Activity_ID An internal identifier for the request


IS_Input_Name Used by the Input Supervisor; the name of the software input to the Input Supervisor

IS_Software_Type Used by the Input Supervisor; the type of the software input to the Input Supervisor

Media_Type Medium (tape or disk) used for output from the DSM/SCM request

Sys_nn_Nbr Used by the Target Activator; the SYSnn number specified for the configuration revision being processed

Tool_Assigns_Flag Flag indicating whether the user assigned a special tool

Trace_Flag Flag indicating whether a trace process was activated for the DSM/SCM component

Status Code Meaning


Generating DSM/SCM Reports Configuration Manager View

Configuration Manager View

The Configuration Manager View (=PHIH_CNFG_MGR_PRF_SVIEW) contains Configuration Manager profile information:

Configuration Product Version Files View

The Configuration Product Version Files View (=PHIH_CNFG_PVL_FL_SVIEW) contains the names of the files in particular products in particular configuration revisions, together with relevant product information.


Host_Node_Name The name of the host system

Revision The version number of this revision of the profile

Days_Retain_Requests Maximum time (days) that will elapse between the time a request stops and the time it is deleted

Export_Arch_Files_Node The system DSM/SCM is using as a destination for exporting files

Export_Arch_Files_Vol The volume DSM/SCM is using as a destination for exporting files

Report_Node The system on which DSM/SCM reports are written

Report_Vol The volume on which DSM/SCM reports are written

Report_Subvol The subvolume on which the DSM/SCM reports are written

System_Serial_Nbr The NonStop system identification number

Tape_Drive_Device_Name The internal name of the default tape drive

Tape_Drive_Name The name of the default tape drive


Configuration_Name The name of a configuration revision

Apply_Date The date the application package containing the configuration revision was applied to the target system

DSV_Type The processor type for the distribution subvolume:

Y All

R TNS/R only

E TNS/E only

Product_Name A 20-character product name

Product_Base_IPM_Number If the product is a base SPR, the base SPR identifier

Product_Update_IPM_Number If the product is an update SPR, the update SPR identifier

Product_Number The product number assigned by HP, a vendor, or a customer; for example, T9050


Generating DSM/SCM Reports Configuration Products Versions View

Configuration Products Versions View

The Configuration Products Versions View (=PHIH_CNFG_PRD_VER_SVIEW) contains the file names for each product version related to a given configuration name.

Product_Version The version number of the product; for example, G06

File_Name The name of a file in the specified product

File_Fingerprint An 8-character hexadecimal value used to uniquely identify the file

File_Fingerprint_Vers The version of the file fingerprint

TSV_Name1 The name of the target subvolume on which the file will be placed

TSV_Name2 The name of a second target subvolume, if any, used by a second file function

TSV_Name3 The name of a third target subvolume, if any, used by a third file function

File_Function1File_Function2File_Function3

Up to three file functions; for example, SYSGEN or USER


Configuration_Name Name of a configuration revision

Apply_Date Date the last activation package was applied to the target system

System_Name Name of the system for which the configuration was built

DSV_Type The processor type for which the configuration revision was built:

Y All

R TNS/R only

E TNS/E only

Input_Name Name of the software input containing the product version

Base_Product_Name Product name

Base_Product_Base_IPM_Number If the product is a base SPR, the base SPR identifier

Base_Product_Update_IPM_Number If the product is an update SPR, the update SPR identifier

Base_Product_Number Base product number; for example, T9050



Generating DSM/SCM Reports Configuration View

Configuration View

The Configuration View (=PHIH_DELF_CONFIG_SVIEW) gives the highest level of information about a configuration. It includes information on Build and Apply dates, request status, instruction text, and SYSnn subvolumes.

Base_Product_Version Product version; for example, G01

Base_Product_Description Brief description of the product

Subsystem_Class_Code Not used

TNS_TNSR_DSV_Type Value indicating the processor type for which the product was designed:

Y All

R TNS/R only

E TNS/E only

Vendor_Name Name of the product’s vendor. Default is Tandem Computers, Inc.


Configuration_Name Configuration revision name

System_Name Name of the host system on which the configuration was built

System_Revision Internal revision number for the target system

Target_Name Name of the physical target system for which the configuration was built

Revision Revision number of the configuration revision

Target_Revision Revision number of the logical target profile

Apply_Date Date the revision was applied to the target system

Apply_SYSnn SYSnn to which the activation package was applied

Backout_Date Date the last backout was performed on the target system

Build_Date Date and time on which the activation package was built

Build_Sysnn SYSnn subvolume entered for the Build request

Submit_Date Time and date when the Build request was submitted

Config_Status Flag indicating whether the configuration was applied or activated on a target system

SYSnn_Activated_Flag Flag indicating whether the SYSnn volume is activated

Config_Descr_Text Text describing the configuration (entered by the planner in the Planner Interface)



Generating DSM/SCM Reports EMS View

EMS View

The EMS View (=PHIH_EMS_LOG_SVIEW) contains information about the EMS messages on a target system:

Logical Target Profile View

The Logical Target Profile View (=PHIH_LTARGET_PRF_SVIEW) contains default information used in building configurations for a logical target. The information includes planner-created descriptive text, system generation output, and work file and report locations.

Instruction_Text Instructions to the target system operator (written by the planner in the Planner Interface)

Config_Text_Seq_Nbr Internal sequence number assigned to a 240-character block of configuration description text

Instruction_Text_Seq_Nbr Internal sequence number assigned to a 240-character block of operator instruction text


Activity_ID An internal identifier for the request


Creation_Time The time at which the request was created

Creator The user ID of the planner who submitted the request

Orig_Node_Name The system from which the request originated

Server_Class_Name The name of the Pathway server class

EMS_Text EMS message text associated with the request

EMS_Text_Ptr An index to the EMS text table for the EMS text

Text_Seq_Nbr A sequence number assigned to the EMS text


System_Name Name of the target system on which the target is defined

Target_Name Logical target name

Revision Internal revision number of the target profile

AP_Snapshot_Node Default system on which the activation package and snapshot are to be created

AP_Snapshot_Vol Default disk volume on which the activation package and snapshot are to be created



Generating DSM/SCM Reports Logical Target Profile View

Backout_Allowed_Flag Internal flag indicating whether a backout is allowed for the target

Conftext_File_Node Name of the default system on which the CONFTEXT file for this target resides

Conftext_File_Vol Name of the default volume on which the CONFTEXT file for this target resides

Conftext_File_Subvol Name of the default subvolume in which the CONFTEXT file for this target resides

Conftext_File Name of the CONFTEXT file for this target

Create_SIT_Flag Flag indicating whether the default is to create a system image tape (SIT). This flag is not present in Integrity NonStop systems.

Define_Expand_Flag Flag indicating whether the default is to expand DEFINEs in the system generation output

Include_ZSPIDEF_TSV_Flag Flag indicating whether DSM/SCM by default includes all files for the ZSPIDEF subvolume for a configuration in the activation package

Include_ZTEMPL_TSV_Flag Flag indicating whether DSM/SCM by default includes source template files for the ZTEMPL subvolume for a configuration in the activation package

Priviledged_Declare_Flag Flag indicating whether DSM/SCM by default includes all privileged declaration files in the application package

Sysgen_Work_Status_Code Character indicating how system generation work files are placed:

N Temporary, placed by systemP Permanent, with a given $volume.subvolume locationT Temporary, with a given $volume location

Default_Guard_Ownership User ID for default file ownership on the target system

Default_Guard_Security Default file security setting for the target system; for example, NNNN

Host_Backup_Node System containing the Backup output file when Backup is run on the host system

Host_Backup_Vol Host volume containing the Backup output file

Host_Backup_Subvol Host subvolume containing the Backup output file

Host_Backup_File File used for Backup output when run on the host

Target_Output_Node System containing the Backup output file when Backup is run on the target system



Generating DSM/SCM Reports Snapshot Files View

Snapshot Files View

The Snapshot Files View (=PHIH_SS_FILES_SVIEW) contains file information about files returned in a snapshot:

Target_Output_Vol Volume on the target system containing the Backup output file

Target_Output_Subvol Subvolume on the target system containing the Backup output file

Target_Output_File File used for Backup output when run on the target system

Host_TSV_Default_Vol Default volume for new TSVs that do not have a volume specified

Include_All_Files_Flag Flag indicating whether the default is for DSM/SCM to include all files or only changed files in the activation package for a given configuration revision

Host_Sysgen_Node System on which the system generation output file resides

Host_Sysgen_Vol Volume containing the system generation output file

Host_Sysgen_Subvol Subvolume containing the system generation output file

Host_Sysgen_File System generation output file

Sysgen_Work_Node System on which system generation work files are to be placed

Sysgen_Work_Vol Volume on which system generation work files are placed

Sysgen_Work_Subvol Subvolume on which system generation work files are placed

Profile_Desc_Text Brief description of the target

Report_Node The name of the default system on which a report, softdoc, or release document file is placed

Report_Vol Name of the default volume on which a report, softdoc, or release document file is placed

Report_Subvol Name of the default subvolume in which a report, softdoc, or release document file is placed

Report_File Name of the report, softdoc, or release document


System_Name Name of the target system on which the snapshot was produced

File_Name Name of a file in the snapshot

Audited_Vol Name of the volume where the file resides



Generating DSM/SCM Reports Software Input Files View

Software Input Files View

The Software Input Files View (=PHIH_SW_INPUT_FL_SVIEW) contains information about the files in a particular product:

Audited_Subvol Name of the subvolume where the file resides

File_Fingerprint Eight-character hexadecimal value uniquely identifying the file

File_Fingerprint_Vers Version number of the file’s fingerprint


Input_Name Name of the software input containing the product

Product_Name Name of the product

Product_Base_IPM_Number If the product is a base SPR, the SPR identifier

Product_Update_IPM_Number If the product is an update SPR, the SPR identifier

Product_Number Five-character product number; for example, T9050

Product_Version Version number of the product; for example, D20

File_Name Name of a file in the product

Binder_Timestamp Timestamp indicating when the Binder was run for the file

File_Library_Priority If the file has the SYSGEN function, the priority value (0 through 9) of the library used by file

File_Size Size of the file, in bytes

File_TACL_Directory For a file with the TACLSEGF function, the name of the TACL directory associated with the file

File_Function1File_Function2File_Function3

Up to three file functions; for example, SYSGEN

From_Product_Version For a file with the Migration function, the version of the system the file runs on; for example, D10.

To_Product_Version For files with the Migration function, the version of the system the file is being used to build

Guard_License_Code Security attribute for the file; one of:

L—DSM/SCM is to license a program file that contains privileged code so that non privileged users can run the file.

null—(Default) Program file that contains privileged code does not need to be licensed to enable non privileged users to run it.



Generating DSM/SCM Reports Software Input Products View

Software Input Products View

The Software Input Products View (=PHIH_SW_INPUT_PRD_SVIEW) contains product-level information related to a particular input and descriptive text associated with the input:

Dest_File_Name1Dest_File_Name2Dest_File_Name3

Special destination file names, as required by File_Function1, File_Function2, and File_Function3

TSV_Name1TSV_Name2TSV_Name3

Special TSVs, as required by File_Function1, File_Function2, and File_Function3

File_Fingerprint Eight-character hexadecimal value that uniquely identifies the file

File_Fingerprint_Vers Version number of the file fingerprint


Input_Name The name of the software input

DSV_Type The processor type for the distribution subvolume from which the input was read:

1 TNS2 TNS/R3 TNS and TNS/R

4 TNS/E

Product_Name The name of a product in the input, up to 20 characters

Product_Base_IPM_Number If the selected product is a base SPR, the SPR identifier of the product

Product_Update_IPM_Number If the selected product is an update SPR, the SPR identifier of the product

Product_Number The 5-character product number; for example, T9050

Product_Version The product version; for example, D20

Product_Description A product description, entered by the customer or vendor

Subsystem_Class_Code Not used



Generating DSM/SCM Reports System View

System View

The System View (=PHIH_PTARGET_PRF_SVIEW) contains information from the system profiles for target systems:

Tape Drives View

The Tape Drives View (PHIH_TAPE_DRIVE_SVIEW) contains information about tape drives for a particular target system:

Input_Type The type of the software input:

S SUT (RVU)N NPV (Initial PVU)I IPM (SPR)

Vendor_Name The name of the product’s vendor. For HP software, the value is Tandem Computers, Inc.

Input_Desc_Text Text describing the software input, entered by the planner in the Planner Interface


System_Name The target system name

Revision The revision number of the system profile

CPU_Type The processor type of the target system: TNS, TNS/R, or TNS/E

Cnfg_Mgr_Name The name of the host system that manages the target system

Network_Connection_Flag A value indicating whether DSM/SCM is to use an Expand connection to the host:

Y YesN No

Site_ID The site identification number

Snapshot_Medium_Flag Flag indicating whether snapshots are written to tape or disk:

D diskT tape

SW_Version_Level The version number of the software on the physical target


System_Name The name of the target system

Tape_Drive_Name The tape drive name

Tape_ID A 6-character identifier that should be on the external tape label



Generating DSM/SCM Reports TSV View

TSV View

The TSV View (=PHIH_TSV_SVIEW) contains TSV information for logical targets:

Volumes View

The Volumes View (=PHIH_VOL_SVIEW) contains information about volumes for a selected target system:


System_Name Target system name

Target_Name Logical target name

TSV_Vol A TSV volume on the logical target

TSV_Name A TSV subvolume name on the logical target


System_Name The name of a target system

Vol_Node_Name The name of the system on which the volume resides

Vol The name that the volume was up as when the last snapshot was taken

Alt_Vol The alternate volume name

Vol_Usage_Flag Flag indicating how DSM/SCM uses the volume:

1. Scratch volume

2. Archive volume

3. Both scratch and archive volume


19Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning)

Cloning is the simplified use of DSM/SCM for installation and management of multiple NonStop systems with identical hardware and software configurations.

In DSM/SCM you can create a clone group, consisting of a master system and one or more clone systems. Any software configuration applied to the master is also applied to all the clones in that master’s clone group. You can configure multiple clone groups, each of which is maintained independent of the other groups.


Cloning Requirements on page 19-1

Creating a Clone Group on page 19-2

Applying a Software Configuration to a Clone Group on page 19-5

Creating a Noncloning Configuration on a Master or Clone on page 19-7

Removing a System From a Clone Group on page 19-8

Cloning RequirementsWhen deciding whether to manage multiple NonStop systems using cloning, consider:

All systems in a clone group must have the same processor type.

All systems must have the same, identically named volumes (primary and alternate) for volumes on which DSM/SCM manages TSVs.

All clone system targets must have the same logical target name.

The super ID remote password and sufficient network security access are required to remotely activate configurations on clone targets simultaneously using the CLONE utility.

These are limitations to the DSM/SCM cloning feature:

Planner Interface activities for a clone group are indicated only for the master system. For example, a new software revision created for a clone group appears created only for the master, not the clones. This applies to most Planner Interface displays and information, including applied configuration revisions.

Clone targets do not return a snapshot to the host system.


Simplified Installation and Management of Multiple Identical NonStop Servers (Cloning)

Creating a Clone Group

Discrepancy Reports can be generated for clone targets only through a special process. See Creating a Discrepancy Report for a Clone on page 18-14.

Creating a Clone GroupYou create a Clone Group by modifying the target description text for logical targets in the Planner Interface.

Task 1: Define a Master Target

1. In the Configuration Revisions window, select the system you want to be the master target. This can be a Host or Target system.

2. From the Maintain menu, select Target Maintenance->Modify.

The default information for that system appears.

3. In the Target description field, enter <MASTER> as the initial text. It must be the first text in the description, followed by a space and then the rest of the description text.

For future reference, you should add text explaining that this target is a master. For example:

<MASTER> This is a master target. Configurations installed on \master-sysname will also be installed on targets with <CLONE \master-sysname in their Target descriptions.

4. Click OK.

This system is now defined as a master target.

Task 2: Define Clone Targets

1. In the Configuration Revisions window, select the system you want to be a clone in this clone group.

2. From the Maintain menu, select Target Maintenance->Modify.

The default information for that system appears.

3. In the Target description field, enter <CLONE \master-sysname> as the initial text. It must be the first text in the description, followed by a space and then the rest of the description text.

For future reference, you should add text explaining that this is a clone target. For example:

<CLONE \master-sysname> This is a clone of \master-sysname. Configurations installed on \master-sysname will also be installed on this target, regardless of any other attributes specified here.

4. Click OK.



Examples: Clone Groups

This system is now defined as a clone for the specified master.

5. Repeat this task for all the systems that will be clones in this clone group.


When you finish defining the master and clones for a clone group, the group could be illustrated similar to:

You can have multiple logical targets as clones on a single system:

A host system in a clone group must be its master, but a group is not required to include a host system:

Target Description Text Host/Target

\PROD01 DEFAULT <MASTER> Host

\PROD02 DEFAULT <CLONE \PROD01> Target




\TEST05 DEFAULT <MASTER> Host

\TEST05 TEST <MASTER> Host

\TEST10 DEFAULT <CLONE \TEST05> Target

\TEST10 TEST <CLONE \TEST05> Target


\TEST05 DEFAULT <MASTER> Target






Display of Masters and Clones

When clone groups exist, the Planner Interface Configuration Revisions window adds a clone group column indicating the clone group membership for each system.

Indicator Description

M This system is a master.

C This system is a clone.

n A number appears to the left of every M or C in a valid group. For example, 1 M is the master for all systems listed as 1 C; 2 M is the master for all systems listed as 2 C.

If there is no number, it could be for one of several reasons:

The master has no clones.

The clone’s master is not defined.

The specified master system exists but it is not a master.

The specified master system exists but the master logical target does not.

Figure 19-1. Clones Displayed in Configuration Revisions Window

VST200.vsd



Applying a Software Configuration to a Clone Group

Applying a Software Configuration to a Clone Group

Most of the process for applying a new software configuration to a clone group is similar to the normal DSM/SCM process.

Creating a Clone Group Software Configuration

To create a new software configuration for a clone group, create a new software configuration for the master target.

SUTs copied to the clone group configuration choose licensed products based on the master target CUSTFILE.

In Planner Interface displays, only the master indicates that the configuration exists. The clones do not indicate it.

When you finish creating the new software configuration, click Build/Apply....

Building and Applying a Clone Group Configuration Revision

To avoid manually starting each clone apply in the Target Interface, make sure these options are selected:

Build, apply & process snapshot

In the Output... dialog, Disk (under Activation package/snapshot location)

Other Build notes:

SYSGEN and system load indications are accurate for the master target, but they might not be for clone targets unless their software and SYSnn are exactly identical to the master.

All applies to all clones start at the specified apply time.

Target profile values for the master target, such as the Manage OSS Files checkbox, also apply to clone targets.

After you click OK, the build starts for the clone group at the selected time.

All indicators in the Planner Interface reflect the Build/Apply request for only the master. The master Build/Apply request does not indicate completion until every clone apply is complete.

If a Clone Group apply fails to start, you can manually start it in the Target Interface. When one Group apply fails, the others continue independently.

Caution. Any software configuration installed for a clone group is indicated in the Planner Interface only on the master target. The Planner Interface does not indicate that the clones have the newly installed configuration. Therefore, Planner Interface information for clones might not appear current.



Renaming Product Files for a Clone Group

Renaming Product Files for a Clone Group

To activate the updated software configuration on all systems in a clone group, use the CLONE utility to run ZPHIRNM. You can run ZPHIRNM individually for each target, but using the CLONE utility automatically runs ZPHIRNM in parallel on all targets.

1. If necessary for the applied update, run STOPSCM on the host system.

2. In the ZDSMSCM subvolume on the host system, run CLONE.

The CLONE utility runs. If there is only one group in the host database, CLONE uses it as the active group. If there are multiple groups, CLONE prompts you to select which group to work with.

3. If multiple groups exist, use the SET GROUP command to designate an active group. For example:

SET GROUP 2

4. Run the CLONE ZPHIRNM command. For example:

zphirnm sys01,from sys01,preview

Logging is automatic, to a predetermined logfile.

The CLONE utility displays output from each ZPHIRNM, with each status line preceded by a system name prefix. When all ZPHIRNM processing finishes, CLONE displays a summary.

Note. The CLONE utility performs many tasks from the host system on target systems across an Expand network. Run CLONE with the super ID to ensure that you have sufficient read, write, execute, and purge access on the necessary files on those target systems.

Allowed ZPHIRNM Options Disallowed ZPHIRNM Options

ALL DEFAULTS

DETAIL-TO-SCREEN, DET, DTS TSV

FROM TDL

PREVIEW [-STRICT] LOG



Creating a Noncloning Configuration on a Master or Clone

Creating a Noncloning Configuration on a Master or Clone

It is unusual to update the configuration of a single member of a clone group. But if needed, you can update the software configuration for an individual master or clone system.

To create a software configuration to apply to a master but no other clone group members:

1. Remove the master from the clone group. See Removing a Master From a Clone Group on page 19-8.

2. Perform a normal Build/Apply on the master.

3. Make the system a master for the clone group again. See Task 1: Define a Master Target on page 19-2.

To create a software configuration to apply to a single clone but no other clone group members:

1. Remove the clone from the clone group. See Removing a Master From a Clone Group on page 19-8.

2. In the Planner Interface, copy the current configuration to the clone, to ensure an accurate starting point for this Build/Apply.

3. Perform a normal Build/Apply on the clone.

4. Make the system a clone in the clone group again. See Task 1: Define a Master Target on page 19-2.

Note. Once you return it to the clone group, the system where you applied a unique configuration will not have the same configuration as other clone group members.



Removing a System From a Clone Group

Removing a System From a Clone Group

Removing a Master From a Clone Group

To remove a master target from a clone group:

1. Remove the <MASTER> text from its target description in the Planner Interface.

2. Do one of three things:

Make this target a master for the group again. (This is relevant if you removed the master from the group only to create a normal software configuration for it.)

Remove all the clones from the group. (This effectively dissolves the group.)

Define a new master for the group. (You must then also update the master name in the target description text for every clone in the group.)

Removing a Clone From a Clone Group

To remove a clone target from a clone group:

1. Remove the <CLONE \master-sysname> text from the target description in the Planner Interface.

2. Copy the configuration from the master to the former clone. This ensures an accurate account of the software actually running on the system when you create a new software configuration.


20 Installation of Web Interfaces (H-Series and J-Series Only)

DSM/SCM provides web interfaces for SCOBOL screens namely Host Maintenance Interface (HMI), Target Maintenance Interface (TMI), and Target Interface (TI).


Web Interfaces Requirements on page 20-1

Installation Procedure for DSM/SCM Web Interfaces on page 20-2

Starting the Application on page 20-2

Web Interfaces RequirementsWhen you install Web interfaces, check that:

The OSS environment is installed and active

The iTP WebServer software is installed

To start the iTP WebServer, run the setup script as described below. HP recommends that you use a SUPER group user ID other than super ID when you run the setup script.

To run the script, enter the OSS environment and execute the script. For example,

TACL> LOGON SUPER.WEB

TACL> OSH

OSS: cd /usr/tandem/webserver/<version>

OSS: ./setup

The setup script walks you through the installation of administration server and iTP WebServer. By default, the script installs the product into the /usr/tandem/webserver directory. If you are logged on with a SUPER group user ID, you can accept the default settings. After accepting the default settings, start running both the iTP WebServer administration interfaces and iTP WebServer. The script automatically backs up any existing configuration file.

If you want to install iTP WebServer into an OSS directory other than /usr/tandem/webserver, specify the installation directory as a parameter to the setup script. For example,

OSS: ./setup /home/myuser/mywebserver

Note. This feature is supported only on systems running H06.09 and all subsequent H-series, and J-series RVUs.


Installation of Web Interfaces (H-Series and J-Series Only)

Installation Procedure for DSM/SCM Web Interfaces

After the installation of iTP WebServer is complete, do not delete or modify the version-specific directory (/usr/tandem/webserver/<version>) or its sub-directories. Because the OSS symbolic links present in the directory, where the iTP WebServer was installed, point to the directory tree. If any of these directories or sub-directories is deleted, the entire product (starting with unpaxing the product PAX file) will have to be reinstalled.

For details on installation and configuration of iTP WebServer, see the iTP Secure WebServer System Administrator’s Guide.

Installation Procedure for DSM/SCM Web Interfaces

Check that the OSS environment and the iTP WebServer software are installed. When you install the SPR using DSM/SCM:

1. Receive the SPR from the disk or tape

2. Copy the SPR to a new revision of the software configuration you want to update

3. Build and Apply the configuration revision

4. Run ZPHIRNM

5. Run STARTSCM

When DSM/SCM is not managing the OSS, it places the T6031PAX files in TSV ZOSSUTL. To unpax the T6031PAX files using the TACL macro COPYOSS, check that the OSS environment is installed and active. Then perform:

1. TACL> VOLUME $<>.ZOSSUTL

2. TACL> RUN COPYOSS T6031PAX

Starting the ApplicationOpen the Web browser and provide the URL address of the application in the address bar. The URL consists of the IP address of the system in which you can work with the available interfaces. For example,

http://16.107.191.176:dsmscm/ti/OI_LOGON_START.html

To make the DSM/SCM web interfaces as the default page, httpd.config file present in the WebServer location/conf directory should to be modified.

1. Go to /usr/tandem/webserver/conf

2. Stop the Webserver (using ./stop)

3. Append httpd.config to have these lines:

Filemap /hmi $root/root/dsmscm/hmi/MI_LOGON_START.html



Starting the Application

Filemap /tmi $root/root/dsmscm/tmi/MI_LOGON_START.html

Filemap /ti $root/root/dsmscm/ti/OI_LOGON_START.html

4. Start the WebServer (using ./start)

5. Open the browser and specify the DSM/SCM you want to open. For example, to open the Target Maintenance interface, specify:

http://16.107.191.176:tmi



Starting the Application


ADSM/SCM Architecture and Environment

This appendix provides an overview of the architecture of DSM/SCM. Most of what it describes is invisible to users during normal DSM/SCM processing.

Topics discussed in this appendix include:

Architecture Overview on page A-2

$YPHI Pathway Servers on page A-5

DSM/SCM User’s Guide — 529846-014A - 1

DSM/SCM Architecture and Environment Architecture Overview

Architecture Overview

Figure A-1. DSM/SCM Architecture Overview

Pathway Env. $YPHI

LINKMON

TCP

RemoteServer

TapeReader

PlannerInterface

SUT$volume

PATHMON

Server

Server

Server

Server

Server

DB Mgr DB Mgr

DB Mgr

FileManager

Archive

BackupFile MgrSYSGEN

SWID

HostDatabase

TargetInterface

MaintenanceInterface

TargetDatabase

Safeguard

TARGET

NSK

RenameProcess

SYSnn

SYSTEMZuser

Winsock PDP

TDPRSCAPI

RSC

Winsock

NonStop SystemPC

P/S

P/S

P/S

P/S

Send

IPC

IPC

IPC

(Expand)

VST070.vsd



Figure A-2. DSM/SCM Host System Environment

Host Pathway Env. $YPHI

LINKMON

TCP-H

Tape RdrFile MgrSWID

PlannerInterface

SUT$volume

PATHMON

SM-001

MISERVER

OM-001

IS-001

CB-001

Host DBMgr

Archive

BackupFile MgrSYSGEN

SWID


Expand

TARGETSystem

Winsock PDP

TDPRSCAPI

RSC

Winsock

NonStop SystemPC

HostDatabase

VST071.vsd



Figure A-3. DSM/SCM Target System Environment

Target Pathway Env. $YPHI

LINKMON PATHMON

TCP-T TISERVER

MISERVER SM-T-001

TA-001

TDB Mgr

BackupFile Mgr

Tape RdrSWID

TargetInterface


NonStopSystem

RenameProcess

TargetDatabase

SYSnn

SYSTEMZuser

VST072.vsd


DSM/SCM Architecture and Environment $YPHI Pathway Servers

$YPHI Pathway Servers

Schedule Manager (SM)

The Schedule Manager is a host and target static server that:

Ensures activities take place in the proper order

Provides delayed scheduling of requests

Provides persistence for the other server classes

Input Supervisor (IS)

The Input Supervisor runs as a host dynamic server class. The major functions of the IS are:

Archiving new software from sources such as RVUs, SPRs, third-party and customer new versions or updates, and loading the database with information referencing the software

Loading target snapshot information into the host database

Configuration Builder (CB)

The Configuration Builder runs as a host dynamic server class. It performs the steps to build and package software for a software revision, including:

Building the software revision, which includes running a system generation program if necessary

Placing the files built by a system generation program into the archive

Creating the activation package

Target Activator (TA)

The Target Activator runs under a target dynamic server class. It performs all DSM/SCM target functions, including:

Placing and securing new software on the target subvolumes

Saving the previous software revision so a backout can be performed

Building and packaging a snapshot

Retrieving operator instructions from the activation package

Performing cleanup


DSM/SCM Architecture and Environment Utility Server (US)

Utility Server (US)

The Utility Server runs as a host and target dynamic server class. Its major functions are:

Exporting files from the archive

Creating reports

Exporting softdocs and release docs for viewing and printing

Interface Servers

These components perform database inquiries, by means of the Database Manager, to retrieve information such as status or a list of software revisions requested using the Planner Interface, the Maintenance Interface, or the Target Interface.

Object Manager (OM)

The Object Manager is a host static server class. It is the interface server into DSM/SCM for the Planner Interface. It is also the interface server into DSM/SCM for the remote target system.

MISERVER

The MI Server is a host and target dynamic server class. It is the interface server into DSM/SCM for the Maintenance Interface.

TISERVER

The TI Server is a host and target dynamic server class. It is the interface server into DSM/SCM for the Target Interface.


B DSM/SCM Differences

This appendix describes:

The differences between DSM/SCM product versions

The differences between running DSM/SCM on different NonStop systems

Upgrading to DSM/SCM T6031G02

Individual SPR features and options


Comparing DSM/SCM Product Versions on page B-2

Upgrading to DSM/SCM T6031G02 on page B-3

DSM/SCM User’s Guide — 529846-014B - 1

DSM/SCM Differences Comparing DSM/SCM Product Versions

Comparing DSM/SCM Product VersionsIf possible, always install the most recent DSM/SCM product version supported for the type of NonStop system and RVU. For example, NonStop S-series systems support the DSM/SCM G02 product version. The G02/H02 planner interface supports both T6031G02 and T6031H01.

This subsection compares different DSM/SCM product versions.

Comparing T6031G02 to H01

The DSM/SCM T6031G02 can be installed on NonStop S-series systems only.

You can use a NonStop S-series host system to manage an Integrity NonStop target system.

Comparing T6031H01 to D46

The DSM/SCM H01 product version supports Integrity NonStop systems only:

TNS/E, for Integrity NonStop systems, has been added to the Planner Interface screens.

CNFGINFO now supports new system generation options for dynamic-link libraries (DLLs).

These features are not supported:

Creating a system image tape (SIT) for an Integrity NonStop system is not supported.

Creating a G-series RVU from an Integrity NonStop system for a NonStop S-series target system is not supported.


DSM/SCM Differences Upgrading to DSM/SCM T6031G02

Upgrading to DSM/SCM T6031G02To manage an Integrity NonStop target from a NonStop S-series host system, you must install the DSM/SCM G02/H02 planner interface on your PC and the T6031G02 on the NonStop S-series system. A new version of SWID is also required. For more information, see the softdoc.

Task 1: Install the DSM/SCM G02/H02 Planner Interface

Task 1.1: Copy Setup to your PC

1. On the host system, make ZDSMSCM the current subvolume:


2. Using IXF or a similar method, perform a binary copy of the ZDSMEXE file from the ZDSMSCM subvolume on the host to a subdirectory called \DSMSCM on the PC. The subdirectory can be on any drive with sufficient space.

3. On your PC, rename the PC file to ZDSM.EXE.

4. Double-click the ZDSM.EXE file. The DSM/SCM files you just transferred to your PC are decompressed.

Task 1.2: Run Setup.exe

1. In the Contents column, double-click Setup.exe. Setup displays the Enter Object Manager Server Class screen, with the default OM-001.

2. Click OK. Setup displays the Enter CNFGINFO Process Name screen, with the default $ZPHC.

3. Click OK. Setup displays the AskOption screen.

4. Click the Winsock radio button; then click OK. Setup displays the Ask Path screen, with the default WINSOCK.DLL path name C:\WINNT\SYSTEM32.

5. Click OK. Setup displays the IP Address screen.

6. Enter the IP address for your system; then click OK. Setup displays the IP Port screen.

7. Enter the port number you saved for DSM/SCM; then click OK. Setup asks for the name of the host system.

8. Enter the system name; then click OK. Setup asks if you want to run DSM/SCM now.

9. Indicate that you want to run DSM/SCM now.

Note. After you run ZDSM.EXE, you can delete it to save space. All other files are required for proper DSM/SCM operation.


DSM/SCM Differences Task 2: Start TMF and DSM/SCM

10. Check the Planner Interface startup screen to ensure you are running the G01/HO1 product version of the Planner Interface.

Task 2: Start TMF and DSM/SCM

Check that TMF and DSM/SCM are running:

> TMFCOM START TMF> VOLUME $volume.ZDSMSCM> RUN STARTSCM

Task 3: Log On to DSM/SCM

Start the Planner Interface and log on to DSM/SCM. The main Planner Interface screen appears.

Task 4: Receive DSM/SCM T6031G02 Into the Archive

1. In the Software in Archive window, click Receive Software. DSM/SCM displays the Receive Software Request dialog box.

2. Under Software Name, select Provided by planner, and enter a name for the input.

3. Schedule the request. To run immediately, click OK. DSM/SCM begins processing the request and displays the Status dialog box.

4. When the status display indicates that the request is complete, select Window> Refresh. The Software in Archive window is updated to include the newly received software.

Task 5: Upgrade Your Host and Target Systems to T6031G02

Upgrade each target system, then your host system.

Task 5.1: Create a New Software Revision for DSM/SCM T6031G02

1. In the Configuration Revisions window, select the configuration revision of the system being upgraded, then click New software revision.

DSM/SCM opens a New Software Revision window. It might take several minutes for this window to appear.

2. From the Software in Archive window, select the DSMSCM T6031G02 you just received.

3. Click Copy to. DSM/SCM puts DSMSCM G02 in the new revision.

4. Edit the revision notes for the new revision.

a. Click Edit Revision Notes. DSM/SCM displays the Revision Notes dialog box.


DSM/SCM Differences Task 5: Upgrade Your Host and Target Systems to T6031G02

b. Add a description of the changes.

c. Click OK.

Task 5.2: Build and Apply the Configuration Revision

1. From the window displaying the new software revision, click Build/Apply.

DSM/SCM displays the Build/Apply Request dialog box. It might take several minutes for this dialog box to appear.

2. In the Activation SYSnn box, enter the current SYSnn. No system generation is required.

3. Schedule the request. To have the request run immediately, click OK.

DSM/SCM runs the Build and Apply requests as scheduled. The activation package is created, and the new software is placed in the appropriate subvolumes. When the Apply is finished, a snapshot is automatically created and returned to the host. It might take several hours before the requests are completed and the snapshot is received.

When the snapshot is received into the host database, DSM/SCM displays a list of requests.

4. Double-click the name of the Build/Apply request.

DSM/SCM displays a status window. Check the status of the requests to confirm that they all successfully finished. To update the status, you might have to select Window>Refresh.

Task 5.3: Rename the Applied Files

1. Stop all applications, including DSM/SCM:


2. Run ZPHIRNM in PREVIEW mode. For more information, see Run ZPHIRNM in Preview Mode on page 11-2.

> RUN ZPHIRNM [$vol.]SYSnn , PREVIEW

The SYSnn is the current SYSnn because no system generation or system load is required.

3. If no errors occur, run ZPHIRNM again without the PREVIEW option. For more information, see Run ZPHIRNM on page 11-4.

> RUN ZPHIRNM $volume.SYSnn


DSM/SCM Differences Task 5: Upgrade Your Host and Target Systems to T6031G02

Task 5.4: Restart All Applications

Restart all applications, including DSM/SCM:

> VOLUME $volume.ZDSMSCM> RUN STARTSCM


C Running CNFGINFO

This appendix describes using the DSM/SCM Configuration Information (CNFGINFO) tool to create or modify a product’s A0CINFO or A7INFO file. Use CNFGINFO to define or modify installation information (file or product attributes) for third-party or customer-developed software applications for systems to be managed by DSM/SCM. You can run CNFGINFO from either the Planner Interface or launch it separately from the Start menu on your PC desktop.

CNFGINFO collects developer-specified or user-specified attributes for a product and its files, creates one or more records per file of the attributes, and places the records in a configuration information (A0CINFO) file in the product’s distribution subvolume (DSV). These attributes are passed to DSM/SCM when the DSV is received into the archive and stored in the DSM/SCM database. DSM/SCM later uses these attributes to process the files when it creates a configuration revision to be applied to a target.

When CNFGINFO creates an A0CINFO file, it also creates an A7CINFO file automatically if the distribution subvolume contains a USTAR format archive file created with the pax utility, and the corresponding target subvolume is set to ZOSSUTL. For more information about the pax utility, see the Open System Services Shell and Utilities Reference Manual. CNFGINFO does not handle A1CINFO files.


Preparing to Run CNFGINFO on page C-2

Entering CNFGINFO on page C-3

Exiting CNFGINFO on page C-3

CONFIGINFO Summary on page C-4

Task 1: Start and Log On to CNFGINFO on page C-4

Task 2: Open or Create an A0CINFO File on page C-5

Task 3: Specifying Product or File Information on page C-6

Task 4: Log Off on page C-16

Note. If you do not work with third-party or customer-developed software, you are unlikely to ever run CNFGINFO.

DSM/SCM User’s Guide — 529846-014C - 1

Running CNFGINFO Preparing to Run CNFGINFO

Preparing to Run CNFGINFOTo run CNFGINFO, the file CNFGI.EXE must be installed on a PC with a Winsock connection to a NonStop host system. (See Section 5, Configuring DSM/SCM.) If you are running CNFGINFO outside DSM/SCM, you must run the server program file CNFGINFO from the ZDSMSCM subvolume using these parameters: NOWAIT, NAME $ZPHC, TERM, IN, and OUT. The server will be running if the full DSM/SCM product is installed and you have run STARTSCM from the ZDSMSCM subvolume.

Before you run CNFGINFO:

1. Place the appropriate product files in a DSV:

2. Check that you have access to the needed A0CINFO files:

You must have read access to view an A0CINFO file. Otherwise, you receive an error message when you try to open it.

To modify or create an A0CINFO file, you must have read access to the files in the DSV and read, write, and purge access to the A0CINFO file.

Normally, purge access is required to modify the A0CINFO file. To modify an A0CINFO file without purge access, set the CNFGINFO-NO-PURGE option to ON:

> STOPSCM (or STOPCFG)> PARAM CNFGINFO-NO-PURGE ON> STARTSCM (or STARTCFG)

Any new A0CINFO files you create have the ownership and security attributes of the user ID under which you logged on.

Scenario Files to be put in the DSV

Defining a new application (product) All product files

Defining a new revision to your product All product files for the new revision

Defining a base SPR for your product All product files(A base SPR contains all files for a product though only a few files might have changed.)

Defining an update SPR for your product Only the changed files


Running CNFGINFO Entering CNFGINFO

Entering CNFGINFO1. If running CNFGINFO by itself, run STARTCFG on your PC:

> STARTCFG

Otherwise, check that DSM/SCM is started. See Starting DSM/SCM on page 2-2.

2. To run CNFGINFO either:

Select Start>Programs>Dsm_scm>CNFGINFO.

In the Planner Interface main window, select Tandem>Run CNFGINFO tool.

CNFGINFO displays the CNFGINFO Tool Logon dialog box.

3. Enter your user ID or alias and password and then click OK.

CNFGINFO displays the Select DSV Location dialog box:

For detailed information on using CNFGINFO, see Section C, Running CNFGINFO.

Exiting CNFGINFO1. In the Select DSV Location dialog box, click OK. CNFGINFO saves all changes

you made during the session and returns to the main task window.


3. If you have no further DSM/SCM activities to perform, on the host system:

a. Check that ZDSMSCM is the current subvolume.

b. Run STOPSCM.

c. If you are running CNFGINFO by itself, stop $ZPHC.

VST028.vsd


Running CNFGINFO CONFIGINFO Summary

CONFIGINFO SummaryTo prepare the product for DSM/SCM, the planner:

1. Log on to CNFGINFO by selecting Tandem>Run CNFGINFO tool.

2. Specify the location of the distribution subvolume containing the product files.

3. Specify these product attributes:

Product name

Product version

Subvolume where the files are to be placed

4. Because all files have a default function of USER (there are no special functions), click OK in each dialog box, including the Select DSV Location dialog box; then exit CNFGINFO by selecting File>Exit. The new product now has an A0CINFO file that contains all the appropriate product attributes.

Task 1: Start and Log On to CNFGINFO1. Start CNFGINFO by doing one of:

Click the Windows icon for the CNFGI.EXE program (it is labelled CNFGINFO Tool in the DSM/SCM program group).

If DSM/SCM is installed on your system, you can start CNFGINFO from the Planner Interface by selecting Tandem>Run CNFGINFO tool.

DSM/SCM opens a window on your PC that displays a CNFGINFO session. From this window, you can run the Planner Interface and the CNFGINFO Tool sessions in parallel. (Use Alt-Tab to switch between sessions.)

In either case, CNFGINFO displays the About DSM/SCM CNFGINFO dialog box, which contains license and copyright information. This dialog box remains visible for about five seconds; then CNFGINFO displays the Logon dialog box:

2. In the Logon dialog box, enter your user ID or alias and password.

VST141.vsd


Running CNFGINFO Task 2: Open or Create an A0CINFO File

3. Click OK.

CNFGINFO displays the Select DSV Location dialog box:

Task 2: Open or Create an A0CINFO File1. In the Select DSV Location dialog box, enter the location (system, volume, and

subvolume) of the DSV that contains the product files for which you are creating or modifying an A0CINFO file.

The system name defaults to the system you are logged on to.

2. Click View/modify product info.... CNFGINFO displays the DSV Information dialog box:

If you are modifying an existing A0CINFO file, the boxes show the current values. If an A0CINFO file already exists for the DSV, CNFGINFO opens the file and displays the current file information.

If an A0CINFO file does not exist for the product, CNFGINFO creates one after you complete all necessary dialogs and then click OK in the Select DSV Location dialog box. If you are creating a new file:

The product name, product version, and target default destination subvolume are required. All other information is optional.

You must specify ZOSSUTL as the target default destination subvolume for any pax file to be managed by DSM/SCM.

Product vendor, processor support, and DSV category are set to their default values. All other fields are blank.

If you have write access to the A0CINFO file or are creating a new one, CNFGINFO runs SWID (Software ID utility) on the NonStop system to calculate fingerprints for all files in the DSV. This can take several minutes, depending on the number and size of the files.

VST142.vsd


Running CNFGINFO Task 3: Specifying Product or File Information

Task 3: Specifying Product or File InformationFrom the DSV Information dialog box, you can enter or modify information about the product and its files. The fields are described in the online help. The boxes on the DSV Information dialog box correspond to product attributes.

1. To add or change information in the A0CINFO file:

Product information, enter the information in the boxes in the DSV Information dialog box.

Product dependency information, go to Specifying Product Dependencies on page C-8.

Information for the product files, go to Specifying File Information on page C-9.

2. When you have finished all changes, click OK. DSM/SCM returns to the Select DSV Location dialog box.

Specifying Product Attributes

If the A0CINFO file already exists, DSM/SCM initializes all data fields with the current data. To change or specify product attributes in an A0CINFO file, enter values in data fields in the CNFGINFO dialog boxes:

Attribute Description

Product Name Required; descriptive name of the product, up to 20 characters; for example, COBOL.

Product Version Required; the product number and version ID, up to 8 characters. For example, T9199D20 indicates an HP product. (Although no checking is done, customers should not use product numbers beginning with characters reserved by HP, such as T and S.)

Product Description Optional; up to 45 characters describing the product’s use.

Product Vendor Name of the supplier of the product, up to 31 characters. The value you specify for Product Vendor is placed in the DSMSCM.INI file on your PC. That value becomes the default, so you do not need to reenter the vendor name each time you create an A0CINFO file.


Running CNFGINFO Specifying Product Attributes

DSV Category Required; the category of the product. A product is either a base version or an update. Choose one of:

Base Version

Default; indicates that the software is a base version containing a complete set of files. Includes a complete set of product files and therefore replaces all previous base versions and SPR udpates applied to that product.

IPM update Indicates that the software is an update to the product, containing only changed files. Might not be a complete set of files and can be added to a base version along with other SPRs

Base IPM Version Optional, used only if the product is a base version; a 3-character code that specifies the last SPR applied, if any, to the base version; for example, AAB. For consistency, use the same 3-character convention used by HP. This software can be copied to (COPY-TO) a configuration without requiring the product version to be in the configuration.

IPM code Required if the DSV is an SPR update; 3-character code that specifies the ID of the SPR; for example, AAB. For consistency, customers should use the same 3-character convention used by HP.

Processor support Type of processor on which this set of files for the product runs: TNS, TNS/R, TNS/E, or TNS and TNS/R. Default is TNS and TNS/R for NonStop K-series systems and NonStop S-series systems, and TNS/E for HP Integrity NonStop systems.

Target default destination subvolume

Required if enabled in the dialog box; subvolume on the target system where this product’s files are placed when software is applied. Used as a default for any files with no assigned TSV. Up to eight characters, with the first character a letter. Although no checking is done, do not use subvolume names beginning with letters reserved by HP, such as X, Y, or Z.

You must specify ZOSSUTL as the target default destination subvolume for every pax file in a product to be managed by DSM/SCM.

Product dependency lists

See File Attributes on page C-10.



Running CNFGINFO Specifying Product Dependencies

Specifying Product Dependencies

A product’s A0CINFO file optionally contains two dependency lists:

The Requires list contains the product number, version ID, and SPR code of other product SPRs that must accompany the current product in the new software revision.

The Replaces list contains the product number, version ID, and SPR code of earlier versions of the product that are superseded by this version. For example, this list is used when an SPR for a product contains fixes from a previous SPR and therefore supersedes the previous SPR.

DSM/SCM uses these lists to produce the Required IPMs and Replaced IPMs reports. (See Section 18, Generating DSM/SCM Reports.) Although DSM/SCM does not perform dependency checking, the planner can use these reports to help determine product dependencies when planning new software revisions.

To specify product dependency information, add or remove products in the Requires and Replaces lists.

1. In the DSV Information dialog box, click the IPM update button and enter the SPR code.

2. Click View/modify Requires/Replaces info....

CNFGINFO displays the DSV Requires/Replaces Information dialog box.

3. Click OK.

CNFGINFO returns to the DSV Information dialog box.

Adding a Product to the Requires List

1. Enter the base product version of a required product in the field next to the Add button in the Requires list.

2. Enter the product’s three-letter SPR identifier in the IPM update code field.

3. Click Add.

Removing a Product from the Requires List

1. Scroll through the list of products in the Requires list.


3. Click Remove next to the list.


Running CNFGINFO Specifying File Information

Adding a Product to the Replaces List

1. Enter the three-letter SPR identifier in the IPM update code field. To replace multiple SPRs, enter each separately.

2. Click Add.

Removing a Product from the Replaces List

1. Scroll through the list of product versions in the Replaces list.


3. Click Remove next to the list.

Specifying File Information

You can display a list of the distribution files to add, delete, or change information about selected files.

1. In the DSV Information dialog box, click View/modify file info.... CNFGINFO displays the DSV Distribution Files dialog box that displays the product’s distribution subvolume and the file name, function, and target subvolume for each product files in that the DSV.

If a file has more than one function, each function has a separate entry. If a file does not have an A0CINFO record, the Function is set to USER, and the TSV is set to the default entered in the DSV Information dialog box.

2. Select a file by scrolling through the list.

VST144.vsd



3. From the distribution files dialog box, click either Modify function, Delete function, or Add function.

Click Add function... to add a new function for a file.

Click Modify function... to modify a file’s information.

Click Delete function.... to delete a function from the selected file. CNFGINFO displays the Confirm Deletion warning box. Click Yes to proceed with the deletion.

CNFGINFO displays the DSV File Information dialog box, which displays the information for the file and function you selected. The name of the selected file appears in the title of the dialog box.

4. Make changes only as relevant to each selected file. You might not need to make each change for every file. For each file that requires changes, repeat these tasks as needed.

5. Click OK. CNFGINFO returns to the DSV Information dialog box.

File Attributes

The file attributes you can specify through CNFGINFO are:

Entering or Changing the File Description

Enter or modify the information in the File description fields as needed.

Note. You cannot delete the last entry for a file. To remove a file from distribution, delete it from the DSV and run CNFGINFO to re-create the A0CINFO file to reflect the change.


Dependency Information

See Adding File Dependency Information on page C-11.

Destination Subvolume

TSV where the file is placed when the software is applied to the target system. Default is the target default destination subvolume. The file’s function might indicate a different destination subvolume. See Specifying a Destination Subvolume or File Name on page C-11.

File description Optional description of the file.

Function Indicates the file’s use. Default is USER. See Specifying File Functions on page C-12.

License file Indicates whether the file must be licensed for use on the target system. Can be set only if you are logged on as the super ID (255,255).

New file name Optional; the name given to the file when is it placed in its TSV on the target system. Default is the file’s name as distributed in the DSV.



Specifying a Destination Subvolume or File Name

Enter or modify the information in the Subvolume and New filename fields as needed. The TSV where the file will be placed depends on the file’s function. The destination subvolume you specify for a file depends on the file’s function:

Requiring That a File Must Be Licensed for Use by the Target System

Check the License file check box. This check box is available only if you are logged on as the super ID (255,255).

Adding File Dependency Information

ADDIF and DELIF lists are typically used when a DSV might contain an optional product, such as SQL/MP or Safeguard. The problem is that existing products on your system might contain calls to the optional product.

The A0CINFO file can optionally include an ADDIF list or a DELIF list for each product file:

The ADDIF list is a list of products that, if they are in a software revision, cause the file to be included in the revision. If any listed products are in the revision, the file is included. If none of the products are in the revision, the file is not included.

The DELIF list is a list of products that, if they are in a software revision, cause the current file to be excluded from the revision. The file is included only if none of the listed products is in the revision.

DSM/SCM uses these lists to:

Determine which product files to copy to the new revision when creating a new software revision

Determine what files to input to system generation when building the activation package

You must allow for the case where the optional product is not present:

Function Destination

DOCPRINT SOFTDOC, if the file is a softdoc

ZRLSEDOC or RLSEDOC, if the file is a release document

INSTALL PDTSYS

MIGRATION PDTSYS

PRIV DECS TSV name

SYSGEN Depends on the file’s use in the system generation process; for example, SYSnn or CSSnn.

TACL SYSnn subvolume

USER TSV name



1. Define a dummy product file that has no function but has the same name and interface as the optional product file.

2. Specify the optional product on a DELIF list for the dummy product file so it is included in the software revision only if the optional product is not present.

To require that the file’s inclusion in the software revision depends on the presence of another product:

1. Click ADDIF....CNFGINFO displays the ADDIF dialog box. The current file name is displayed in the upper portion of the dialog box. If an ADDIF list already exists for the file, it appears.

2. Create or modify the list:

To add a product to the list, enter the product number and click Add.

To remove products from the list, click the product in the list; then click Remove.

3. Click OK. CNFGINFO returns to the DSV File Information dialog box.

To indicate that the file’s exclusion in the software revision depends on the presence of another product:

1. Click DELIF....

CNFGINFO displays the DELIF dialog box. The current file name is displayed in the upper portion of the dialog box. If a DELIF list already exists for the file, it appears.

2. Create or modify the list:

To add a product to the list, enter the product number and click Add.

To remove products from the list, select the product in the list; then click Remove.

3. Click OK.

CNFGINFO returns to the DSV File Information dialog.

Specifying File Functions

Every product file has function information in the A0CINFO records that describes how the file will be used. Some functions are intended for specialized use and require additional DSM/SCM processing. Most customer and third-party files have the USER function and require no additional processing. The file functions are:

Note. You cannot enter the same product number and version in both the ADDIF and DELIF dialog boxes. If you try to, a warning box prompts you to choose the ADDIF or the DELIF list.



A file can have up to three functions. Valid combinations of functions are:

USER can coexist with any other function, including another function of USER.

INSTALL can coexist with any other function.

All other functions are mutually exclusive.

For example, a file can have the functions USER and SYSGEN, or INSTALL and SYSGEN. A file cannot have the functions SYSGEN and TACL. The DOCPRINT, SYSGEN, MIGRATION, and TACL functions require you to specify additional information.

Specifying a DOCPRINT File’s Destination

Use the DOCPRINT function to indicate that the file is a softdoc or release document. To indicate the file’s destination for a file with the DOCPRINT function, you must specify one of:

1. In the DSV File Information dialog box, click DOCPRINT.... CNFGINFO displays the DOCPRINT Destination dialog box.

2. Click the button next to the appropriate destination: SOFTDOC, RLSEDOC, or ZRLSEDOC.


Function Meaning

DOCPRINT File is a TGAL-formatted softdoc or release document.

INSTALL File is used by DSM/SCM during its processing; for example, as a tool to build an activation package.

MIGRATION File is used during migration processing. Use only under direction of HP support personnel. See Specifying the Migration Function on page C-15.

PRIV DECS File is a privileged declaration file, used when building privileged processes; for example, when defining system I/O tables.

SYSGEN File is input to system generation. See Specifying System Generation Usage for the File on page C-14.

TACL File is included in the TACLSEGF file segment. See Specifying the TACLSEGF Function on page C-15.

USER File is copied to a TSV on the target system. This function is the default.

Document Type Meaning

RLSEDOC File is either the PRODCAT or TIMESTMP file distributed by HP.

SOFTDOC File is a product-specific document.

ZRLSEDOC File is a document related to a specific RVU.



Specifying System Generation Usage for the File

1. In the DSV File Information dialog box, click SYSGEN....CNFGINFO displays the SYSGEN Usage dialog box, which shows a list of system generation options.

2. To select one of the listed options, click the corresponding button.

These options are mutually exclusive, except for SYSGEN COPY (copy file to SYSnn) and SYSGEN PROCESS (system process file).

If you select System library file, you must also select a bind group number between 0 and 9.

Entering a number in the priority field is not necessary for any systems running D40.00 or later RVUs.

3. After selecting the options, click OK. CNFGINFO returns to the DSV File Information dialog box.

Table C-1. System Generation Options

Option Indicates that... (page 1 of 2)

Controller millicode file to CSSnn

The file is downloadable controller millicode for the 3650/6100 family of communications controllers and is to be placed on the CSSnn subvolume.

Controller millicode file to SYSnn

The file is downloadable controller millicode to be placed on the SYSnn subvolume. Used for controllers that are not type 3650/6100.

Copy file to SYSnn

A system generation program copies the file to the SYSnn subvolume on the target system. Files in this subvolume are on the NEWPROCESS search path; for example, ADDUSER. (Default)

CPU (STDUCODE) millicode file

The file is standard processor millicode.

EMS Template file to ZTEMPL

The file is an EMS template to be placed in the ZTEMPL TSV.

System implicit library CORE

The file is used for dynamic-link libaries (DLL).

System implicit library ETC


System implicit library FS


System implicit library INIT


System implicit library MCP




For more information on how system generation uses these file types, see the System Generation Manual for G-Series RVUs

Specifying the TACLSEGF Function

Use the TACLSEGF function for files that are to be loaded in the TACL segment file TACLSEGF. If you select this function, you must specify a TACL directory under which the file will be placed when it is loaded in TACLSEGF. For more information on the TACLSEGF file, the TACL directory, and TACL file name conventions, see the TACL Programming Guide.

To specify the TACL directory for a file to be placed in the TACLSEGF segment file:

1. In the DSV File Information dialog box, click TACL....CNFGINFO displays the TACL Directory for DSV file dialog box.

2. Enter the name of the TACL directory.


4. Click OK. CNFGINFO returns to the DSV Distribution Files dialog box.

Specifying the Migration Function

Use the MIGRATION function to indicate that the file is a special version of a software installation tool to be used by DSM/SCM when migrating from one RVU to another.

Files used as migration tools have the destination TSV set to the PDTSYS subvolume. If you specified a different TSV location for the product’s TSV attribute, you are warned that the file’s destination was changed. Migration tools are usually released under a temporary name and renamed when placed on the PDTSYS subvolume.

System library file

A system generation program binds the file into the system code or library segments in OSIMAGE; for example, system-callable procedures and interrupt handlers.

You must also indicate a bind group number between 0 and 9.

System process file

The file is a system process that runs under its own process identification number (PIN) from OSIMAGE. Used for processes that are initialized at CPU system load; for example, memory managers and I/O processes.

System process library file

A system generation program binds the file into system processes as a user library file. (For TNS/R and TNS/E processors, the DP2 driver is the only system process library file.)

Caution. Use this feature only under the direction of HP support personnel.

Table C-1. System Generation Options

Option Indicates that... (page 2 of 2)


Running CNFGINFO Task 4: Log Off

If a file has the Migration Tool function, you must specify the migration to and optionally the migration from RVUs. The default for the migration from RVU is any RVU preceding the migration to RVU.

1. In the DSV File Information dialog box, click Migration....CNFGINFO displays the Migration Tool Usage dialog box.

2. Enter the ID of the RVU being migrated to; for example, G06.26.

3. Enter the ID of the RVU being migrated from. The default is that the file can be used on any RVU prior to the one being migrated to.


Task 4: Log OffTo end the session and leave CNFGINFO:

1. In the Select DSV Location dialog box, click OK.

CNFGINFO saves all changes you made during the session and returns to the main task window.


3. If you have no further DSM/SCM activities to perform:

a. Check that ZDSMSCM is the current subvolume.

b. Run STOPSCM.

c. If you are running CNFGINFO on a stand-alone basis, stop $ZPHC.

The DSV can now be received into DSM/SCM as a software input.


D Required Processes and Files

This appendix describes the contents of the $SYSTEM, $DSMSCM, and $AUDIT disk volumes, as preconfigured on all NonStop S-series servers and Integrity NonStop servers. DSM/SCM requires these permanent and temporary files to function correctly. Do not purge or alter subvolumes or files as noted. Doing so can cause serious performance problems and might require a reinitialization of DSM/SCM.


Required Processes on page D-2

Required Volumes on page D-2

Required Files on page D-9

DSM/SCM User’s Guide — 529846-014D - 1

Required Processes and Files Required Processes

Required Processes DSM/SCM requires these processes:

Required VolumesYou need at least three disk volumes available for DSM/SCM:

System load volume $SYSTEM (location for SYSnn subvolume and target subvolumes)

$DSMSCM (location of the DSM/SCM application and database)

$AUDIT (location of the archive and TMF audit trails)

System Load Volume

$SYSTEM is the recommended volume name.

CNFGINFO Server $ZPHC

EMS Collector $ZPHI

PATHMON Name $YPHI

Subvolume Description Contains Files

Annnnnn Site-specific subvolume, where nnnnnn is the system number.

Files that are unique to the system,

For example:

Customer file (CUSTFILE)

Licensed software products file (PRODCAT)

A099997(S7000)

A099998(S70000)

Initial site-specific subvolume. DO NOT PURGE OR ALTER THIS SUBVOLUME.

CSS00CSS01

DSM/SCM REQUIRES AT LEAST TWO CSSnn SUBVOLUMES.

Files for communications line interface processors (CLIPs) and other communication subsystem components.


Required Processes and Files System Load Volume

PURGEME Temporary files created and purged by DSM/SCM. DO NOT PURGE OR ALTER THIS SUBVOLUME.

Guardian files renamed by TA to PURGEME subvolume

$volume.PURGEME.ZPGccncc

OSS files renamed by TA to PURGEME subvolume

.dsmscm.ZPGccncc

Files renamed by ZPHIRNM to PURGEME subvolume

$volume.PURGEME.filename

The filename variable is already present in PURGEME subvolume

$volume.PURGEME.ZFABnnnn

SYS00SYS01

DO NOT DELETE THE SAVED SYSnn TO SAVE SPACE ON YOUR SYSTEM. If you delete the saved SYSnn, you cannot back out to the previous revision but must verify the database before you run the next Apply.

Most files needed to load and execute the operating system.

Includes the Subsystem Control Facility (SCF) base configuration file (CONFBASE)

SYSTEM System subvolume System and product files not included in the SYSnn subvolumes.



Required Processes and Files System Load Volume

Z* DSM/SCM target subvolumes. BE CAREFUL BEFORE YOU DELETE ANYTHING IN THESE SUBVOLUMES. For example, do not delete any ZMP* or ZFB* files.

Software product files and files added by DSM/SCM for software configuration management purposes.

ZAnnnn Activation package subvolumes, left when a user:

Performs a Build and never performs a successful Apply.

Cancels or deletes an Apply request.

The Apply request stops in a nonrestartable state.

DO NOT DELETE A ZAnnnn SUBVOLUME if any Apply activities are outstanding. If no Applies are outstanding, periodically check for and delete old ZAnnnn subvolumes.

ZSYSCONF System configuration subvolume System configuration files and some startup files.

Current SCF configuration file (CONFIG)

SCF command file (SCF0000) used to create the configuration file

STARTCOM and STARTSCF



Required Processes and Files DSM/SCM Application and Database Volume

DSM/SCM Application and Database Volume

$DSMSCM is the recommended name for the disk volume that contains the DSM/SCM application and databases. Use $DSMSCM as the volume name to avoid confusion.

Subvolume Description Contains...

PATHSCM Contains Pathway control and log files.

Pathway Control and Log Files

$volume.PATHSCM.*

ZDSMSCM Pathway Environment Files and Location

Pathway configuration and other information tailored to the DSM/SCM installation. Files Shipped on the SUT:

Cold-start file $volume.ZDSMSCM.PATHCOLD

Startup file $volume.ZDSMSCM.PATHMAIN

Stop file $volume.ZDSMSCM.PATHSTOP

Host/Target template file

$volume.ZDSMSCM.TEMPHOST

Target only template file

$volume.ZDSMSCM.TEMPTARG

Files Created During INITENV

Coolstart file $volume.ZDSMSCM.PATHCOOL

Host/Target configuration file

$volume.ZDSMSCM.TEMPHOST

Target only configuration file

$volume.ZDSMSCM.TEMPTARG

Configuration (control) file

$volume.PATHSCM.PATHCTL

Log file (also contains ZPHITI and ZPHI*MI errors)

$volume.PATHSCM.PATHLOG


Required Processes and Files DSM/SCM Application and Database Volume

\INITENV Configuration Monitoring Files

DSM/SCM uses two files, INITSTAT and ILOGnnnn, to monitor the configuration. Both are stored in the DSM/SCM installation subvolume (ZDSMSCM).

INITENV uses the INITSTAT file to record the progress of the configuration and during verification and DSM/SCM start-ups and shutdowns. It is generally not useful to users, but do not purge this file.

INITENV uses the ILOGnnnn edit file to record all DSM/SCM prompts and your responses to them. nnnn is a number from 0000 to 9999. (ILOGnnnn replaces

ZDSMSCM DSM/SCM target subvolume (product subvolume). DO NOT ALTER OR PURGE THIS SUBVOLUME.

Product Subvolume (TSV). See DSM/SCM Application and Database Volume on page D-5.

To copy this subvolume, see Switching From One ZDSMSCM Subvolume to Another on page 17-14 and Renaming a Volume Managed by DSM/SCM on page 17-14.

$volume.ZDSMSCM.*

(.dsmscm.ZFBccncc for OSS files)

TACL Start File $volume.ZDSMSCM.STARTSCM

TACL Stop File $volume.ZDSMSCM.STOPSCM

SQL SQL/MP catalog

SYS CIIN and CONFTEXT files

XSystemName DSM/SCM target database. DO NOT ALTER OR PURGE THIS SUBVOLUME.

Target Database $volume.Xsystem name.*

SQL Comp Output/Target DBM

$volume.Xsystem name.ZPHICOMP

XPHIHDB DSM/SCM host database. DO NOT ALTER OR PURGE THIS SUBVOLUME.

Host Database $volume.XPHIHDB.*

SQL Comp Output/Host DBM

$volume.XPHIHDB.ZPHICOMP

Subvolume Description Contains...


Required Processes and Files Archive and Audit Volume

INITLOG from previous versions of DSM/SCM.) You can view this file which provides a permanent record of INITENV activities. Each time you run INITENV, it logs to the next unused ILOGnnnn file in the ZDSMSCM subvolume, in ascending order. If all files ILOG0000 through ILOG9999 exist, you get a message prompting you to purge some of the ILOGnnnn files.

Archive and Audit Volume

$AUDIT is the recommended name for the volume that contains the DSM/SCM archive and TMF audit trails. You must allow an entire volume for archive storage. Because DSM/SCM supports multiple RVUs, the DSM/SCM archive must be on a volume with a name of no more than seven characters ($xxxxxx) . The archive volume must be network accessible to the system.

Many procedures in this guide assume that $AUDIT is the location for the archive and TMF audit trails. If you move the archive and audit trails, update your procedures accordingly. For instructions on how to move the archive, see Moving the DSM/SCM Archive (ZPHIHMI) on page 17-27.

Configuration Files

DSM/SCM uses the information in the configuration files to install and manage product files:

A0CINFO Files on page D-7



A0CINFO Files

The A0CINFO file for a product contains records that describe the product and its files. Every distribution subvolume (DSV) used as an input to DSM/SCM must contain an A0CINFO file. The A0CINFO file includes product and file dependencies, how the files are used, where they are placed, and which type of processor the product runs on.

HP includes an A0CINFO file in the DSV of each of its software products. HP customers and third-party vendors developing software to be managed by DSM/SCM must create an A0CINFO file for every DSV. To specify or change any of these

Subvolume Description

$volume.ZPHIcncc.ZPHIcncc

ZPHI0001ZPHI0002ZPHI0003ZPHI0004

Contain DSM/SCM archive files (product DSVs). DO NOT ALTER OR PURGE THESE SUBVOLUMES.

ZTMFAT TMF audit-trail files.


Required Processes and Files Scratch Volume

attributes through CNFGINFO, enter information and select options in the CNFGINFO dialog boxes.

A1CINFO Files

DSM/SCM requires an A1CINFO configuration file for shared run-time library (SRL) products on NonStop S-series systems. A1CINFO configuration files are distributed with SRL products. CNFGINFO has not been updated to handle A1CINFO files. Otherwise, you should be able to treat any A1CINFO file that you see just as you would any A0CINFO file.

A7CINFO Files

DSM/SCM requires A7CINFO files to manage OSS products. Every OSS product DSV that DSM/SCM manages requires both an A0CINFO and an A7CINFO file. In addition, these constraints apply to pax files and OSS product DSVs:

Each OSS DSV to be managed by DSM/SCM must contain a pax file.

Pax files must be distributed to the ZOSSUTL TSV. Furthermore, only pax files may be distributed to the ZOSSUTL DSV.

Pax files may contain only absolute paths. (Relative paths are not allowed.)

File paths may not contain /G, /E, .dsmscm.*, or zzDSMSCM.Managed.

Scratch Volume

Although these files are temporary, do not delete them.

IS Scratch Subvol $scratch.ZISSCnnn.ZSIGSCRA

System Generation Configuration Files

$scratch.ZACFGnnn.*

System Generation Tools $scratch.ZATLSnnn.*

System Generation Related Subvolume

$scratch.Tproduct-num.*

TACLSEGF Build Subvolume $scratch.ZSGFnnn.*

SYSnn Subvolume for System Generation

$scratch.SYSnn.*

Tools from CB for TA $scratch.ZTOOLnnn.ZFBccncc

CB Reserved Subvol $scratch.subvolume.ZCBSIGN

TA Reserved Subvol $scratch.subvolume.ZPHISIGN


Required Processes and Files Required Files

Required Files

DSM/SCM Server Files

ZPHIRNM Rename Work Files

ZPHIRNM uses these Rename Work files to track fabricated names and actual names for all managed files in the current and previous revisions.

Activation Package $scratch.ZAnnn.ZZAnnnnn

Snapshot Subvol $scratch.ZPHISNAP.ZZSnnnnn

Scratch Volume for OSS Files Being Applied or Verified

$ZAFPnnn

Object Name Description Runs on

CBEXE CB-001 Configuration Builder Host

ISEXE IS-001 Input Supervisor Host

TAEXE TA-001 Target Activator Host/Target

OMEXE TISERVER Target Interface Host/Target

USEXE US-001 Utility Server Host/Target

OMMIEXE MISERVER Maintenance Interface Host/Target

OMEXE OM-001 Object Manager Host

SMEXE SM-001 Schedule Manager Host

SMEXE SM-T-001 Schedule Manager Target

HELPSRVO T9154-HELP Help Server Host/Target

Located in All TSVs

Map file of all files in that TSV ZMPccncc

Map file of all OSS files in that directory .dsmscm.ZMPccncc

ID file (DSM/SCM manages this TSV) ZPHI6030

ID file (DSM/SCM manages this OSS directory) zzDSMSCM.Managed

Current state of this TSV (copy of map file) ZPHIFI

Current state of this OSS directory (copy of map file) .dsmscm.ZPHIFI

Fabricated file names ZFBccncc

Fabricated OSS file names .dsmscm.ZFBccncc


Required Processes and Files ZPHIRNM Rename Work Files

ZPHIRNM uses these internal work files. Do not purge or alter these files. To help you identify them, each has a 961 file code.

$systemload

is the system load volume.

$vol

is the volume of the ZPHISYS and ZPHIOSS files specified for the $vol.SYSnn parameter on the ZPHIRNM command.

$vol.SYSnn

is as specified for the $vol.SYSnn parameter on the ZPHIRNM command.

Located in SYSTEM subvol

Points to last rename SYSnn ZPHISYS

Points to last rename SYSnn (for OSS TSVs) ZPHIOSS

Located in SYSnn

Directory file for current revision ZSSLIST

Directory file for current revision containing OSS files ZOSSLIST

Directory file for previous revision ZWKccncc *

Directory file for previous revision containing OSS files ZWOccncc *

Directory file for the previous configuration when a FRABIBAB is performed

ZWKFRAB

Directory file for the previous OSS configuration when a FRABIBAB is performed

ZWKOFRAB

* The directory files list all TSVs managed by DSM/SCM for that revision. If a Build/Apply is done without system generation (the new revision uses the same SYSnn), ZPHIRNM renames the ZSSLIST file to ZWKnnnnn in the SYSnn subvolume.

Guardian file OSS file

$systemload.SYSTEM.ZPHISYS

$systemload.SYSTEM.ZPHIOSS

$vol.SYSTEM.ZPHISYS $vol.SYSTEM.ZPHIOSS

$vol.SYSnn.ZSSLIST $vol.SYSnn.ZOSSLIST

subvolume.ZPHIFI .dsmscm.ZPHIFI

subvolume.ZMPccncc .dsmscm.ZMPccncc

Two ZMPccncc files are usually in each subvolume managed by DSM/SCM.



subvolume

is a subvolume managed by DSM/SCM.


E ASSIGNs and PARAMs

This appendix describes using ASSIGNs and PARAMs:

Assigning and Activating Tools on page E-2

Adding ASSIGN Statements for Tools on page E-2

Specifying a PARAM From the Planner Interface on page E-5

Specifying a PARAM From PATHCOM on page E-5

DSM/SCM User’s Guide — 529846-014E - 1

ASSIGNs and PARAMs Assigning and Activating Tools

Assigning and Activating Tools

Removing PARAMs or ASSIGN Statements From the List

1. In the Tool Assigns dialog box, select a PARAM or ASSIGN name.

2. Click Remove.

3. Repeat Steps 1 and 2 for each statement to be removed; then click OK.

Adding ASSIGN Statements for ToolsYou can override the default locations of some software tools, such as DISKGEN, used by DSM/SCM during the processing of specific requests. For available ASSIGNs for system generation on a G-series RVUs, refer to the System Generation Manual for G-Series RVUs. From the planner interface:

1. Activate Tool ASSIGNS. From the Build/Apply Request dialog box, select Tandem>Support info>Activate tool assign.

2. From the Build/Apply Request dialog box, click Tool ASSIGNS. DSM/SCM displays the Tool Assigns dialog box, listing the tool’s execution location (on the host or target system), the ASSIGN name, and the file locations of existing tools.

3. Click either Host or Target.

4. Enter the ASSIGN name of the tool in the box near the bottom of the dialog box. (This name is in the instructions you receive from HP.) For example:

For an ASSIGN that uses system generation: SYSGEN^DISKGEN

For an ASSIGN that does not use system generation: NSKCOM

5. Tab to the next box and enter the tool’s location. For example:

For an ASSIGN that uses system generation: \OAK.$TREE.SYSTOOL.DISKGEN

For an ASSIGN that does not use system generation: \OAK.$IPMS.NSKCOM.NSKCOM

6. Click Add. (Do not click OK or press Return until you click Add, or the tool is not assigned.)

7. Repeat Steps 2 through 6 for each tool that needs an assign; then click OK.

Note. Perform these activities only as directed by HP support personnel or release documentation. They are performed only to help resolve a migration problem or to help troubleshoot certain situations. PARAMs and ASSIGNs are not normally required in procedures.


ASSIGNs and PARAMs Adding ASSIGN Statements for Tools

8. Deactivate Tool ASSIGNS. From the Build/Apply Request dialog box, select Tandem>Support info>Activate tool assign again.

Table E-1 lists the tools that DSM/SCM uses and the file ASSIGNs that you can use to direct DSM/SCM to use a file from a different location. Some tools have multiple assigns, so different versions of tools can be used for different tasks. Assigns are mostly limited to the Build/Apply activities. ASSIGNs specified from the planner interface are not persistent. Each new Build and Apply starts with no ASSIGNs.

Table E-1. ASSIGNs (page 1 of 2)

File Product ASSIGN Name Default Location

Server-Task

AS1 T8304 AS1 Config** CB-SRL

BACKUP T9074 SYSGEN^BACKUP $SYSTEM* CB-sysgen

BACKUP $SYSTEM* CB-sysgen

AP^BACKUP $SYSTEM* CB-AP

BIND T9621 SYSGEN^BINDER Config** CB-sysgen

BKUPIN T0431 SYSGEN^BKUPIN Config** CB-sysgen

CAT T0431 SYSGEN^CAT Config** CB-sysgen

COUP COUP $SYSTEM* TA-*

DEFINEO T0431 SYSGEN^DEFINEO Config** CB-sysgen

DISKGEN T9074 SYSGEN^DISKGEN $SYSTEM* CB-sysgen

DOPPELG T6031 DOPPELG Config** CB-sysgen

ELD T0608 SYSGENÊLD Config** CB-sysgen

DLL_ELD Config** CB-PubDLL

ENOFT SYSGENÊNOFT Config** CB-sysgen

FILEMGR T9519 FILEMGR $SYSTEM* TA-*

FUP T6553 FUP $SYSTEM* TA-*

GMAKE T0593 SYSGEN^GMAKE Config** CB-sysgen

MKOSFS T0431 SYSGEN^MKOSFS Config** CB-sysgen

NLD T6017 SYSGEN^LINKER Config** CB-sysgen

SRL_NLD Config** CB-SRL

NSKCOM T5838 NSKCOM Config** CB-SRL

OCA T0448 SYSGENÔCA Config** CB-sysgen

OSB T6031 SYSGENÔSB Config** CB-sysgen

OSBOBEY T6031 SYSGENÔSBOBE Config** CB-sysgen

OSBUILD T0431 SYSGENÔSBUILD Config** CB-sysgen

OSGEN T0431 SYSGENÔSGEN Config** CB-sysgen

OSPARSE T0431 SYSGENÔSPARSE Config** CB-sysgen


ASSIGNs and PARAMs Adding ASSIGN Statements for Tools

PDTERROR T9674 (if BIND assign, Config** CB-sysgen

PDTHELP T9674 get from same subvolume) Config** CB-sysgen

PLINSTL T2812 PLINSTL Config** CB-Pub DLL

PTAL T9248 PTAL Config** CB-SRL

PTALCOM T9248 PTALCOM Config** CB-SRL

REMOVE T0431 SYSGEN^REMOVE Config** CB-sysgen

REPLACE T0431 SYSGEN^REPLACE Config** CB-sysgen

SWID T9298 SYSGEN^SWID $SYSTEM* CB-sysgen

SWID $SYSTEM TA-*

SYSGEN T9023 SYSGEN Config** CB-sysgen

SYSGENR T9023 SYSGENR Config** CB-sysgen

TACL T9205 TACL $SYSTEM*

TAPERDR T9519 TAPERDR $SYSTEM* TA-*

TEMPLI T9633 SYSGEN^TEMPLI Config** CB-sysgen

TEMPLIMF T9633 TEMPLIMF Config** CB-sysgen

UGEN T8304 UGEN Config** CB-SRL

XLLINK T6166 SYSGEN^XLLINK Config** CB-sysgen

ZSEGFBLD T6031 $SYSTEM*

* Config - File is exported from the DSM/SCM configuration to a temporary subvolume.

** File is used from $SYSTEM.SYSTEM of $SYSTEM.SYSnn

Table E-1. ASSIGNs (page 2 of 2)

File Product ASSIGN Name Default Location

Server-Task


ASSIGNs and PARAMs Specifying a PARAM From the Planner Interface

Specifying a PARAM From the Planner Interface

DSM/SCM uses a set of appropriate PARAMs when running a system generation program. For G-series RVUs, you can pass a PARAM to a system generation program. PARAMs specified from the planner interface are not persistent. Each new Build and Apply starts with no PARAMs. For available PARAMs for system generation, refer to the System Generation Manual for G-Series RVUs.

From the DSM/SCM Planner Interface:

1. Activate Tool ASSIGNS. From the Build/Apply Request dialog box, select Tandem>Support info>Activate tool assign.

2. From the Build/Apply Request dialog box, click Tool ASSIGNS. DSM/SCM displays the Tool Assigns dialog box.

3. Click Host.

4. Enter PARAM and the PARAM name in the first box near the bottom of the dialog box. Unlike the ASSIGN statement, you must type PARAM before the PARAM name. For example:

PARAM SYSGEN^LARGE^CONFIGURATION

5. Tab to the next box and enter the PARAM value. In this example:

YES

6. Click Add. (Do not click OK or press Enter until you click Add.)

7. Click OK.

8. Deactivate Tool ASSIGNS. From the Build/Apply Request dialog box, select Tandem>Support info>Activate tool assign again.

Specifying a PARAM From PATHCOMIn most cases, you can use the defaults. You can add PARAMs to the appropriate PATHWAY server. Specifying a PARAM from PATHCOM is persistent until INITENV or PATHCOLD is run.

For example:

> PATHCOM $YPHI

= ALTER server,PARAM param-name param-value

Note. This procedure does not apply to H-series and J-series RVUs.


ASSIGNs and PARAMs PARAM Summary

server

is the appropriate PATHWAY server, IS-001, CB-001, TA-001, or OM-001. See $YPHI Pathway Servers on page A-5.

param-name param-value

See PARAM Summary on page E-6.

PARAM Summary

AP^BACKUP "backup-program-file "

Pass this PARAM to the PATHWAY server CB-001. If a tool assign was not specified for the BACKUP tool, DSM/SCM uses the BACKUP program specified in the PARAM to create the AP on tape.

backup-program-file

is a fully qualified file name in the form $volume.subvolume.file.

DELETE-OBSOLETE-TSVS

deletes all obsolete target subvolumes. This PARAM deletes not only the SYSnn target subvolume but all target subvolumes. Pass this PARAM to the PATHWAY server TA-001. See also KEEP-OBSOLETE-SYSNN.

DSM/SCM keeps obsolete SYSnn subvolumes if the SYSnn subvolume for the new configuration and the current configuration are the same, but the SYSnn ID for the previous configuration is different.

For example: The current configuration is placed on SYS01. The new configuration contains a few SPRs that don't require a system load so it is going to SYS01 also. The previous configuration is placed on SYS00. DSM/SCM will not manage SYS00 after this apply, but you can keep the old SYSnn as a backup SYSnn subvolume to perform system loads from. If PC != CC != NC, DSM/SCM deletes the previous configuration SYSnn subvolume because you can still fall back to the current configuration SYSnn subvolume.

DLL-BUILD-VERBOSE

passes the -VERBOSE option to PLINSTL when the public DLLs are built. Pass this PARAM to the PATHWAY server CB-001.

DONT-ACTIVATE-LAST-LOGON { YES | NO }

affects the options passed to USER_AUTHENTICATE_ when for login to DSM/SCM. Pass this PARAM to OM-001.



YES

specifies that the last-logon timestamp for the user that logged into DSM/SCM is not updated in the SAFEGUARD logs.

NO

specifies that the timestamp is updated. This is the default.

FORCE-PUBLIC-DLL-BUILD "system logical_target revision "

builds public DLLs for the configuration specified. Pass this PARAM to CB-001. For example:

"TARG DEFAULT 47"

system

is the target system.

logical_target

is the logical target name.

revision

is the revision number

FP-CACHE-DISABLE

disables the use of fingerprint cache. Pass this PARAM to TA-001. DSM/SCM was fingerprinting some files multiple times in the Apply and Verify DB. The fingerprint cache saves the most recent fingerprints generated. The cache is searched first when a fingerprint is requested for a file. CRONLOG contains some statistics on how successful this is (search for "FP cache").

FP-MFG-*

The FP-MFG-* PARAMs determine what type of fingerprints are assigned to manufactured files. Pass this PARAM to CB-001. If you do not specify a FP-MFG-* PARAM, all files get real fingerprints except IOPCONF, which gets delphi fingerprints(LMT and EOF). FP-MFG-* PARAMs control what types of fingerprints are used.

Precedence - The precedence is in this order, high to low:

1 FP-MFG-filename--VERSION

2 FP-MFG-SYSNN-VERSION *

2 FP-MFG-PUB-DLL-VERSION * Mutually exclusive

2 FP-MFG-SRL-VERSION *

3 FP-MFG-VERSION



FP-MFG-F-<filename>-VERSION =999

Delphi fingerprints (LMT and EOF) are calculated for this file.

FP-MFG-F-<filename>-VERSION = -1

Real fingerprints are calculated for this file, getting the latest version for the file.

FP-MFG-F-<filename>-VERSION = 1

Real fingerprints are calculated for this file, getting version 1 for the file.

FP-MFG-SYSNN-VERSION = 999

Delphi fingerprints(LMT & EOF) are calculated for files in a temporary SYSnn subvolume*.

FP-MFG-SYSNN-VERSION = -1

Real fingerprints are calculated for files in a temporary SYSnn subvol*, getting latest version for the file.

FP-MFG-SYSNN-VERSION = 1

Real fingerprints are calculated for files in a temporary SYSnn subvol*, getting version 1 for the file.

FP-MFG-SRL-VERSION = 999

Delphi fingerprints(LMT & EOF) are calculated for files in a temporary SRL subvolume*.

FP-MFG-SRL-VERSION = -1

Real fingerprints are calculated for files in a temporary SRL subvolume*, getting latest version for the file.

FP-MFG-SRL-VERSION = 1

Real fingerprints are calculated for files in a temporary SRL subvolume*, getting version 1 for the file.

FP-MFG-PUB-DLL-VERSION = 999

Delphi fingerprints(LMT & EOF) are calculated for files in a temporary Public DLL subvolume*.

FP-MFG-PUB-DLL-VERSION = -1

Real fingerprints are calculated for files in a temporary Public DLL sv*, getting latest version for the file.



FP-MFG-PUB-DLL-VERSION = 1

Real fingerprints are calculated for files in a temporary Public DLL sv*, getting version 1 for the file.

FP-MFG-VERSION = 999

Delphi fingerprints (LMT & EOF) are calculated for all manufactured files*.

FP-MFG-VERSION = -1

Real fingerprints are calculated for all manufactured files*, getting latest version for the file.

FP-MFG-VERSION = 1

Real fingerprints are calculated for all manufactured files*, getting version 1 for the file.

FP-MFG-VERSION = 999

IGNORE-SAFEGUARD-PROTECTION

bypasses the Safeguard security setting on target even if Safeguard is found to be up. Pass this PARAM to the PATHWAY server TA-001. This PARAM inactivates the Safeguard ACL for files in fabricated name, to prevent a possible misuse. If Safeguard is up and you don’t specify this PARAM, DSM/SCM always applies an adopted Safeguard security to the files placed in SYSnn, CSSnn and SYSTEM TSVs. Therefore, whether a file is placed in real or fabricated name, it inherits the same Safeguard ACL as specified for its previous version. Those files only inherit an adopted Guardian security. If Safeguard has the PERSISTENT attribute set to ON for disk files, these files might still be protected with Safeguard security automatically upon completion of APPLY (or ZPHIRNM, in case of files placed in fabricated names). See IGNORE-SAFEGUARD-PROTECTION Param on page E-11.

KEEP-OBSOLETE-SYSNN

allows you to keep obsolete SYSnn TSVs. Pass this PARAM to the PATHWAY server TA-001. If this PARAM is passed without a value, none of the obsolete SYSnn and CSSnn TSVs are purged. See also DELETE-OBSOLETE-TSVS. See KEEP-OBSOLETE-SYSNN Param on page E-12.

NO-ACTIVATION-DIALOUT-REPORT

prevents the creation of the software configuration dial-out report. Pass this PARAM to the PATHWAY server CB-001. You can enable the generation of the dial-out report again by deleting this PARAM.



NO-DB-OWNER-SERVER

specifies to use the Super ID (255,255) to communicate across the EXPAND network for the Build, Apply, Create snapshot, and Receive snapshot. Pass this PARAM to the PATHWAY server CB-001 or TA-001. By default, all communication between a host system and a target system uses the DSM/SCM user ID.

NO-DB-OWNER-SERVER-PROGID

specifies to use FUP directly from the active SYSnn subvolume, instead of using a temporary copy of FUP that running as the DSM/SCM user ID(PROGIDed). Pass this PARAM to CB-001 or TA-001.

If you specify this PARAM, some temporary files are not assigned a N purge security. The PARAM allows the DSM/SCM user ID to clean up the temporary files at the end of the activity. This includes all files that the activity needs to purge at the end of the activity, such as manufactured files, sysgen input files, SRL input files, public DLL input files, Activation Package, and tool files.

OVERRIDE-SYSNN "logical-target revision "

force an Apply to the current SYSnn subvolume. Pass this PARAM to the PATHWAY server TA-001. Use this PARAM only if you can construct the same software configuration (the new and target OSIMAGE EOFs are the same). See OVERRIDE-SYSNN and OVERRIDE-SYSNN-DIFFERENT-OS Params on page E-13. There is no space between the name and number, and the PARAM is not case-sensitive. For example:

"DEFAULT47"

logical_target


revision

is the new configuration revision number.

OVERRIDE-SYSNN-DIFFERENT-OS "logical-target revision "

See OVERRIDE-SYSNN and OVERRIDE-SYSNN-DIFFERENT-OS Params on page E-13. There is no space between the name and number, and the PARAM is not case-sensitive. For example:

"DEFAULT47"

logical_target


revision

is the new configuration revision number.


ASSIGNs and PARAMs IGNORE-SAFEGUARD-PROTECTION Param

SYSGEN-SPOOLER-OUTPUT-OWNER-ID "user-id "

DSM/SCM makes the Planner ID the owner of the system generation spooler output unless this PATHWAY PARAM is specified. Pass this PARAM to the PATHWAY server CB-001.

Examples

This command builds public DLLs for this configuration being built on \Wylee:

> PATHCOM $yphi= ALTER server,PARAM FORCE-PUBLIC-DLL-BUILD "\WYLEE &= DEFAULT 43"

This command gives delphi fingerprints to all files in the SYSnn subvolume. All other files get real fingerprints.

> PATHCOM $yphi= ALTER server,PARAM FP-MFG-SYSNN-VERSION "999"

This command gives a real version 1 fingerprint to the OSIMAGE file. All files in the SYSnn subvolume, except the OSIMAGE file, are given delphi fingerprints. All other files get real fingerprints.

> PATHCOM $yphi= ALTER server, PARAM FP-MFG-F-OSIMAGE-VERSION "1", &= PARAM FP-MFG-SYSNN-VERSION "999"

IGNORE-SAFEGUARD-PROTECTION Param

Even if Safeguard is running on the target system, you can protect the files in your new configuration with Guardian security instead of Safeguard:

1. Set the PERSISTENT attribute to ON for all existing Safeguard-protected files in the SYSnn, CSSnn, and system TSV.

PERSISTENT retains the protection record of a disk file even when the underlying disk file is purged. Normally, a protection record is associated with a specific disk file. When the file is moved or removed, so is the protection record. However, PERSISTENT specifies that the protection record is associated with a particular disk file name, not with the file identified by that name.

2. Use the Planner Interface to set the default Guardian security for the target. (See 3. Collect the Information Needed for the Build on page 9-5 and Guardian Default for New Files on page 9-17). The security you set must be sufficient to protect files being placed by the Apply from unauthorized access.

3. Specify the IGNORE-SAFEGUARD-PROTECTION PARAM to the Target Activator:

> PATHCOM $YPHI= ALTER ta-001, PARAM "ignore-safeguard-protection"

When the Target Activator detects this PARAM, a newly placed file does not inherit Safeguard protection unless PERSISTENT is set to ON for the file.


ASSIGNs and PARAMs KEEP-OBSOLETE-SYSNN Param

This PARAM remains active for all Apply requests for the target until you delete it using PATHCOM.

KEEP-OBSOLETE-SYSNN Param

DSM/SCM normally deletes the obsolete SYSnn as part of normal cleanup during a Build/Apply. However, you can choose to keep the obsolete SYSnn. subvolume.

1. Before the Apply begins, pass the KEEP-OBSOLETE-SYSNN PARAM to the Target Activator server (TA-001):

> PATHCOM $YPHI = Alter TA-001, PARAM KEEP-OBSOLETE-SYSNN

or

> PATHCOM $YPHI; Alter TA-001, PARAM KEEP-OBSOLETE-SYSNN

The SYSnn and CSSnn made obsolete in this Build/Apply become unmanaged but are not purged by DSM/SCM.

The TA saves only the obsolete SYSnn and CSSnn. All other TSVs are purged.

2. Turn off the keep function by deleting the KEEP-OBSOLETE-SYSNN PARAM:

> PATHCOM $YPHI= ALTER TA-001, DELETE PARAM KEEP-OBSOLETE-SYSNN

or

> PATHCOM $YPHI; ALTER TA-001, DELETE PARAM KEEP-OBSOLETE-SYSNN

To confirm the addition or deletion of the PARAM:

> PATHCOM $YPHI; INFO TA-001

Example

1. With the current configuration SYS00, perform a Build/Apply and system load SYS01:

SYS00 becomes the previous configuration.

2. Build/Apply and system load SYS02:

SYS00 and CSS00 become obsolete and are purged. SYS01 becomes the previous configuration.

3. Pass KEEP-OBSOLETE-SYSNN to the TA:

Subsequent obsolete SYSnn subvolumes and CSSnn subvolumes, such as SYS00 and CSS00 in Step 2, are saved and become unmanaged.

Note. All future Build/Apply request also keep the obsolete SYSnn until you turn off the keep function.


ASSIGNs and PARAMs OVERRIDE-SYSNN and OVERRIDE-SYSNN-DIFFERENT-OS Params


SYS01 and CSS01 become obsolete and unmanaged but are not purged. SYS02 becomes the previous configuration.

5. Delete the KEEP-OBSOLETE-SYSNN PARAM.


SYS02 and CSS02 are purged.

SYS01 and CSS01 are not purged by DSM/SCM, but you can purge them manually at any time.

OVERRIDE-SYSNN and OVERRIDE-SYSNN-DIFFERENT-OS Params

You can force an Apply to the current SYSnn subvolume. DSM/SCM ignores the new OSIMAGE, avoiding a system load and preventing downtime.

See Checking That the OSIMAGE File is Unchanged on page E-15. You cannot use OVERRIDE-SYSNN if:

The configuration really changed and it requires a new OSIMAGE for the target SYSnn.

DSM/SCM can perform the Apply to the target SYSnn without the OVERRIDE PARAMs. In that case, system generation is not needed for the new configuration and the new OSIMAGE is the same as the one already in the target SYSnn.

The target SYSnn is a nonexecuting current configuration SYSnn. subvolume

If you cannot construct the same configuration but believe critical files are not affected by the update, you can use the OVERRIDE-SYSNN and OVERRIDE-SYSNN-DIFFERENT-OS PARAMs.

Caution. Use the OVERRIDE-SYSNN-DIFFERENT-OS PARAM with caution. Problems can arise if critical files are affected.



Using OVERRIDE-SYSNN

To avoid a system load, insert these steps in your Build/Apply process:

1. Check that the configuration is unchanged.

2. Check that the host system is running DSM/SCM T6031AAX or later.

3. In PATHCOM, specify the OVERRIDE PARAM:

PATHCOM $YPHI=Alter TA-001, PARAM OVERRIDE-SYSNN &"logical_targetRevision"

4. Start the Build/Apply in DSM/SCM.

5. When the Apply starts, watch the messages.

DSM/SCM checks for OVERRIDE PARAMs and matches their values with the applied configuration revision. If there is a match, the Apply continues to the target SYSnn without replacing the OSIMAGE. No system load is required because the system continues running on the same OSIMAGE.

Using the OVERRIDE-SYSNN-DIFFERENT-OS Param

If error 5023 or 5028 appears and stops the Apply in a restartable state:

1. Use the OVERRIDE-SYSNN-DIFFERENT-OS PARAM:

> PATHCOM $YPHI= Alter TA-001, PARAM OVERRIDE-SYSNN-DIFFERENT-OS & "logical_targetRevision"

2. In the Target Interface, restart the Apply request.

3. When the Apply finishes, run ZPHIRNM in preview mode. Check that no files critical to the execution of the current SYSnn are being renamed.

Configuration Need Params Used Results

Normal update, system load is acceptable

None Overriding is not allowed.

(Never use this PARAM by itself)

OVERRIDE-SYSNN-DIFFERENT-OS

Overriding is not allowed.

You can create the same configuration, system load not acceptable

OVERRIDE-SYSNN If the new and target OSIMAGE EOFs are the same, overriding is allowed. Otherwise, overriding is not allowed.

You cannot create the same configuration, system load not acceptable

OVERRIDE-SYSNN and OVERRIDE-SYSNN-DIFFERENT-OS

Overriding is allowed.



Considerations

After using the OVERRIDE-SYSNN PARAM once, you must specify the PARAM for every Apply until you perform a system load.

A Discrepancy Report still shows the OSIMAGE on the system is different from that in the configuration. However, a Verify Database does not detect a difference.

The Apply takes longer with OVERRIDE-SYSNN because:

All files manufactured by the system generation program in the executing SYSnn are fingerprinted to compare against the same files in the new configuration.

Adoption extends to adopt any files in the executing SYSnn with the correct fingerprint but not the correct EOF and LMT. Files not adopted because of matching EOF and LMT are fingerprinted.

This is necessary when applying to an executing unmanaged SYSnn. Otherwise, no SRL files, among others, would be adopted (which means they are replaced). The LMT of SRL files in a new configuration never matches the LMT of SRLs on the target system because SRLs are rebuilt on every Build.

When you enter the Build/Apply request, the Planner Interface might indicate that system generation or system load is required because the EOF of OSIMAGE can be compared only after the Build finishes.

All subsequent Build/Apply requests, until you send one to a new SYSnn, report in the Planner Interface that a system load is required. The fingerprint of the last OSIMAGE built for this configuration does not match the OSIMAGE fingerprint last applied. If you are using the OVERRIDE feature, you can ignore the message that indicates a system load is required.

Checking the OSIMAGE File

Checking That the OSIMAGE File is Unchanged

To check that your OSIMAGE file is unchanged:

If you did not run INITENV:

Run the Configuration Differences report to compare the configuration last applied to the SYSnn against the new configuration.

Run a discrepancy report between the files on the target system and the new configuration. Discrepancy reports do not compare files manufactured by a system generation program.

If you ran INITENV, perform an Initialization Build/Apply to verify that the files on the system match the files in your new configuration. The discrepancy report does not compare SYSGEN-manufactured files.



Check that the OSIMAGE EOF is the same. Otherwise, OVERRIDE-SYSNN-DIFFERENT-OS is required.

Compare the old and new configuration dial-out reports (SYSHnnnn files in ZDSMSCM). This report contains all products and their versions in the configuration. To Apply to the executing SYSnn after initializing DSM/SCM, capture the old configuration report before initializing.

Check the CONFLIST and CONFAUX files. The new one is replaced, and the old one is renamed to a fabricated name. Only the timestamps should be different.

Check the CONFTEXT file. If it changed, the new one is replaced, and the old one is renamed to a fabricated name. Only the timestamps should be different.

Run ZPHIRNM in preview mode to check the files to be renamed. No files critical to running the SYSnn should be renamed.

Checking the OSIMAGE File After INITENV

To verify that the new and running OSIMAGEs are the same after an INITENV:

1. FUP DUP the latest SYSHnnnn file to a temporary subvolume. For example:

FUP DUP $DSMSCM.ZDSMSCM.SYSH0001, temp. SYSH0001, saveall

2. Run INITENV.

3. Set up DSM/SCM (profiles, receive software, and so on).

4. Perform an Initialization Build/Apply. SYSGEN is not performed for an Initialization Build/Apply.

5. Run a Discrepancy Report and check for differences. Only the SRL files should be different.

6. On the next Build/Apply, system generation is automatic. Use the statement:

PATHCOM $YPHI;ALTER ta-001,PARAM override-sysnn logical^targetrevision

For example:

PATHCOM $YPHI;ALTER ta-001,PARAM override-sysnn default2

7. Use QACOMP to compare the old SYSHnnnn file with the new one from this Build/Apply:

QACOMP TEMP.SYSH0001,ZDSMSCM.SYSH0001

Only three lines should be different:

Date of the report

The configuration revision number

The apply date line



If all other lines in both files match, they are the same.

Checking the OSIMAGE Files After System Generation

To verify that the new and running OSIMAGEs are the same after running a system generation program at the end of a series of configuration revisions, do one of:

After a Build/Apply with the OVERRIDE-SYSNN PARAM finishes, run a Configuration Differences report. Enter the oldest revision first; then enter the latest revision. The report lists the differences between all products in the two configurations. It might take a few minutes to generate the report.

Save the old SYSHnnnn file before running the Build/Apply. After the Build/Apply finishes, use QACOMP on the old and new SYSHnnnn files.


GlossaryA0CINFO file. A DSV file that contains information about a product and each of its files,

including product and file dependencies, how the files are used and where they are placed, and which type of processor the product runs on. Every product and SPR to be managed by DSM/SCM is distributed in a subvolume, and that subvolume must contain the product's A0CINFO file.

A1CINFO file. A DSV file distributed with an SRL product that contains information about a product and each of its files, including product and file dependencies, how the files are used and where they are placed, and which type of processor the product runs on. Every SRL product and SPR to be managed by DSM/SCM is distributed in a subvolume, and that subvolume must contain the product's A1CINFO file. A1CINFO files can only be received using a D30 or later product version of DSM/SCM.

A7CINFO file. A configuration file distributed with OSS products that contains information about the contents of all pax (archive) files of an OSS DSV.

activation. The operator action of putting software into use after the software has been applied from the activation package to the target system.

activation package. A set of files containing instructions for applying software on the target system, product files, and operator instructions. It consists of a header file containing the activation instructions and file attributes, multiple data files, DSM/SCM control information, and EMS events.

activation SYSnn. The SYSnn subvolume of the target system for which the planner is creating a configuration revision. The name of the activation SYSnn is specified during the Build request.

ADDIF list. A list of other products that, if they are in a software revision, cause a particular file in a product to be included in the revision. If any of the listed products are in the revision, the file is included. If none of the products are in the revision, the file is not included. The ADDIF list is an optional part of each product’s A0CINFO file.

Apply. The DSM/SCM action of executing the instructions contained in the activation package, such as placing new software on the target system and taking a snapshot of the new target system.

archive. A set of unstructured files used to collect the software received onto the host system in software inputs. Files received in the input are placed in the archive, and attributes of the files are stored in the host database. The planner specifies the archive location in the Configuration Manager profile, using the Planner Interface or the Archive and Database Maintenance Interface.

Archive and Database Maintenance Interface. A block-mode interface run by a database or system administrator on both the host system and target systems to perform DSM/SCM maintenance functions.

DSM/SCM User’s Guide — 529846-014Glossary - 1

Glossary audit

audit. An activity initiated by the operator at a target system that updates the target database with the fingerprints of all the files in a selected set of target subvolumes (TSVs).

backout. The DSM/SCM action of making the last configuration applied to the target system inaccessible and replacing it with the previous configuration.

base SPR. Last SPR (if any) that was applied to the product before it was received into the archive.

base version. The version of a specific product. A product’s base version usually changes when significant additions are made to the product’s functionality. A base version contains a complete set of files (in contrast to an SPR, which might contain only files that have changed).

HP base product versions are distributed on a SUT and have a format of TnnnnXnn, where Tnnnn is the product number and Xnn is the base version identifier; for example, T9050D20 or T9612C30.

build. The construction of the activation package, including the running of system generation if necessary. The inputs to the build are a software revision list of product versions, the configuration file (CONFTEXT), the latest snapshot of the target system, and the applicable DSM/SCM profiles.

built configuration. A configuration revision for which a system image and activation package have been created.

cancel. A planner-initiated or operator-initiated action of stopping the processing of a request.

check-out. A DSM/SCM internal component’s exclusive access to the DSM/SCM database.

CIIN file. A command file in the SYSnn subvolume that is read and executed by the startup TACL process after system load if the CIIN file is specified in the CONFTEXT file and enabled in the OSM client software. The CIIN file contains a limited set of commands that reload the remaining processors and start TACL processes on the system console.

CLEANOSS Tool. A macro that removes DSM/SCM target work files from the OSS environment. Failure to remove these files causes the next Apply to fail.

clone. A logical target designated as a member of a Clone Group, thus having an identical software configuration to every other member of the Group.

clone group. A group of systems with the same processor type, designated to have identical software configuration updates applied to them.

CLONE utility. A command line utility that performs tasks on all members of a Clone Group at once, such as running ZPHIRNM against all the target systems in a Group.


Glossary cloning

cloning. A DSM/SCM feature allowing for simplified installation and management of software configurations on multiple identical NonStop systems.

compression. The process of reducing the size of files by about one half by using algorithms to indicate how repeating characters (such as spaces) should be stored.

configuration file. See CONFTEXT file.

Configuration Information Tool (CNFGINFO). The CNFGINFO tool collects developer-specified or user-specified file attributes for a product, creates records of each file’s attributes, and places the records in the DSM/SCM configuration information file (A0CINFO) in the product’s DSV. DSM/SCM uses these file attributes to process the files during the Build and Apply tasks.

Configuration Manager profile. See profile.

configuration revision. A planner-defined set of software products and related configuration information that DSM/SCM can activate on a target system. Multiple configuration revisions might exist on a target system. A configuration revision consists of the product versions named in its software revision list, its operating system image, and the relevant profile items, such as the location of the target subvolumes on the target system. It is created by a Build request and is included in the activation package sent to the target system. A configuration revision name is composed of a system name, a target name describing the configuration’s usage, and a software revision number.

CONFTEXT file. The configuration file used as input to a system generation program that contains a series of entries defining your operating system attributes. The CONFTEXT file for G-series, H-series, and J-series RVUs consists of one or two paragraphs: DEFINES (optional) and ALLPROCESSORS.

CSSnn. The subvolume that contains the files that handle I/O for the 3650/6100 family of communications controllers. The portion of the subvolume name should be the same as that of the associated SYSnn subvolume.

current revision. The set of software products and related configuration information currently active on a target system.

CUSTFILE. An edit file included on every RVU as $SYSTEM.Annnnnn.CUSTFILE, where nnnnnn is the system serial number of the target system. The CUSTFILE contains information on the software products on the SUT, their related files, and the destination and use of each file. HP customizes information in the CUSTFILE for each customer’s system.

declaration files. See privileged declarations files.

decompression. The process of expanding files to their original size and format.


Glossary DEFINE statements

DEFINE statements. A set of optional statements in the CONFTEXT file that lets you set up string variables. When system generation runs, it substitutes actual strings for the variables.

DELIF list. A list of other products which, if they are in a software revision, cause a particular file in a product to be excluded from the revision. The file is included only if none of the listed products is in the revision. The DELIF list is an optional part of each product’s A0CINFO file.

destination. The location where a file will reside on a target system. The destination of a file depends on its function. Files whose is function is not USER are placed on the target system when software is applied. Other files are bound into OSIMAGE and placed on the target SYSnn subvolume during an Apply.

discrepancy report. A DSM/SCM report that shows the difference between the configuration sent to the target system in the activation package and the configuration reported in the snapshot at the target system.

document. In DSM/SCM, a softdoc (software document) that describes changes to a product component, or the release documentation (release highlights, PML) associated with a specific RVU.

distribution subvolume (DSV). A subvolume containing program files for a particular software product along with the software release document (softdoc) file for that product. The format for an HP DSV name is Ynnnnrrr or Rnnnnrrr where nnnn is the software product number and rrr is the base version identifier (such as G01) or SPR identifier (such as AAB.)

DSV. See distribution subvolume (DSV).

EMS event messages. The text intended for a system operator that describes a change in some condition in the system or network, whether minor or serious. The change of condition is called an event. Events can be operational errors, notifications of limits exceeded, requests for action needed, and so on.

EMS template files. A set of files containing static text and token IDs that provide for the substitution of literal values for the tokens to produce meaningful text for display. An Event Management Service (EMS) procedure converts templates written for event tokens into operator messages in DSM display format.

Event Management Service (EMS). A Distributed Systems Management (DSM) product that provides event collection, event logging, and event distribution facilities. EMS provides different event descriptions for interactive and programmatic interfaces, lets an operator or an application select specific event-message data, and allows for flexible distribution of event messages within a system or network.


Glossary Expand network

Expand network. The NonStop operating system network that extends the concept of fault-tolerant operation to networks of geographically distributed NonStop systems. If the network is properly designed, communication paths are constantly available even if a single line or component fails.

export. The act of transferring files from the DSM/SCM archive to a standard NonStop operating system format. You can export all or selected files in a subvolume, SPI definition files, EMS template files, or privileged declarations files.

external tape label. An optional, 6-character identifier that is used in EMS event messages displayed to operators during the processing of a request. It is the contents of a physical label attached to a tape, not the ID of a labeled tape.

fingerprint. A unique identifier calculated for a file and displayed in hexadecimal format.

FRABIBAB. The First Real Apply Build, Initial Build Apply Bypass is the first real Build/Apply performed on a target when an Initialization Build/Apply was not performed.

function. A file property that indicates how the file is used, such as whether it contains documentation (DOCPRINT), is to be bound into the operating system during system generation (SYSGEN), or is to be placed in a target subvolume (USER).

File Utility Program (FUP). A NonStop utility used, for example, to create, copy, purge, and set the security of files.

GCSC. See Global Customer Support Center (GCSC).

Global Customer Support Center (GCSC). A support organization that provides telephone and remote diagnostic support for HP customers. GCSCs are located all over the world.

graphical user interface (GUI). A user interface that offers point-and-click access to program functions.

group. A set of software inputs or products that is given a name and can be manipulated as a single entity.

group name. The name given by a planner to a set of software inputs or products.

GUI. See graphical user interface (GUI).

host database. An SQL database maintained for the host system and containing information about requests, software inputs, snapshots, targets, and profiles.

host system. The central site on which DSM/SCM is managed, the archive is maintained, and configuration revisions are built. The host system is also a target system.


Glossary HP NonStop™ Transaction Management Facility (TMF)

HP NonStop™ Transaction Management Facility (TMF). HP software that provides transaction protection and database consistency in demanding online transaction processing (OLTP) and decision-support environments. It gives full protection to transactions that access distributed SQL/MP and Enscribe databases, as well as recovery capabilities for transactions, online disk volumes, and entire databases.

INITENV. The DSM/SCM installation and initialization master program that performs many of the tasks related to installing and initializing software needed to run DSM/SCM.

initialization. The process of defining a new DSM/SCM system, including giving it a name, setting up default values used when processing requests, and creating the first software revision (list of products) for the system.

initial software revision. The software revision on a target system when it is first brought into the DSM/SCM environment. The DSM/SCM host database must be initialized with information about the initial software revision. The initial software revision is then used as a baseline upon which new software revisions are based.

input. See software input.

IP address. An internet protocol (IP) address. An IP address consists of two parts: a network address, which identifies the network, and a local address, which identifies a host within a network. A network address is concatenated to a host address to form the IP address and uniquely identify a host within a network. IP routes data between source and destination IP addresses.

IPM (interim product modification). See software product revision (SPR).

IPM6030/6031. For DSM/SCM D30 and later, STARTSCM runs these macros automatically as needed.

logical target. See target.

Maintenance Interface. See Archive and Database Maintenance Interface.

master. A system designated as the primary system in a Clone Group. The Master is the logical target to which all software configuration tasks for its Group are primarily performed, with those tasks automatically carried out against the Clones in the Group as well.

microcode. Software that is resident in nonvolatile memory, such as ROMs or EEPROMs.

migration. The process of moving from one RVU to another, such as from G05.00 to G06.06.

migtacl0. A TACL macro that can be used to avert or correct certain problems that arise if a G05.00 or later software input is received into DSM/SCM before DSM/SCM has been upgraded to the D30 or later product version.


Glossary network connected

network connected. Multiple computer systems (or nodes) communicating with each other by means of an Expand or other network connection. To use a network other than one with an Expand connection, you must transmit objects (such as the activation package or snapshot) outside of DSM/SCM.

new product version (NPV). A complete set of product files that contains new functions or major updates. Also refers to customer products and third-party products received into the DSM/SCM archive.

OSIMAGE. A file built during system generation that contains the complete image of the HP NonStop operating system that runs in each processor in the system.

ownership. Refers to the user who has the authority to set the security of files. The default ownership for files new to a target is set within DSM/SCM by the planner in the Defaults dialog box of the target profile. For replacement files, the ownership is set to that of the file being replaced. For exported files, the planner sets the ownership when initiating the request.

parameter list. A list of values passed to SQLCI to use when processing a request to create a DSM/SCM report.

parking lot. The area in the main DSM/SCM window below the Software in Archive and Configuration Revisions windows. If you minimize a request’s status window, DSM/SCM places an icon representing the request in the parking lot. You can then quickly check the status of a request.

Requests started in previous sessions do not appear in the parking lot unless you select a request from the Requests window, then open and minimize its status window.

physical target. See target system.

planner. The DSM/SCM user that plans and manages new software revisions using the DSM/SCM Planner Interface to carry out most of these functions.

Planner Interface. A graphical user interface to DSM/SCM that runs on the host system. It provides an interface to all the host DSM/SCM planner functions.

planner instructions. A list of tasks generated by DSM/SCM for the operator at the target system to perform when activating the software for a configuration. This list should be added to or modified by the planner and is included in the activation package.

polling. The act of checking a request while it is processing to determine if any status changes have occurred.

previously applied configuration. The configuration that was executing on the target system before the current configuration. The current configuration is saved when a new configuration is created, and becomes the previously applied configuration.


Glossary privileged declarations files

privileged declarations files. A set of files containing data structures and calling sequences for use by customers when writing privileged code to make direct use of some set of system resources.

privileged process. A process that performs privileged operations, such as direct use of a set of system resources or invoking callable procedures.

process ID (PID). A number that uniquely identifies a process. It consists of the processor (CPU) number and the process identification number (PIN).

process identification number (PIN). A number that uniquely identifies a process running in a processor. The same number can exist in other processors in the same system. See also process ID (PID).

processor type. The type of system on which the software runs:

product component. Either a base version of a product (such as G01) or an SPR to the base version (such as ABG). Product components are part of a configuration revision and are the smallest unit a planner can manipulate.

product version update (PVU). A set of files required for a particular version of a product. A PVU consists of a base version and 0 or more SPRs; for example, T9050G01 or T9100G01+AAA+AAB.

profile. Default values that DSM/SCM uses when processing requests. The three types of profiles are:

The Configuration Manager profile contains information about DSM/SCM in general, such as where the archive and databases are located and which systems are part of DSM/SCM.

The system profile contains information about the system itself, such as the host system name and whether the system uses an Expand network connection.

The target profile contains such items as the input configuration (CONFTEXT) file name, the output location for reports and the activation package, and TSV location specifications.

TNS

TNS/E

TNS/R

All TNS/R and TNS/E systems


Glossary release version update (RVU)

release version update (RVU). A collection of compatible revisions of NonStop operating system software products, identified by an RVU ID, and shipped and supported as a unit; for example, the G06.18 RVU. When HP releases a new RVU, you receive either the entire RVU or selected products from the RVU off of its SUT.

An RVU is distributed on a site update tape (SUT) from which you can receive either the entire RVU or selected products. The release ID is often different from the base product versions of the specific products issued under that RVU.

release document. A document in the release subvolume (Y9230) on the site update tape (SUT.) Release documents include the Release Highlights, Installation Guide, Product Dependencies, Product Maintenance Levels, Performance Information, and a list of all product versions and SPRs in the RVU.

release ID. An identifier that specifies a particular RVU of NonStop software; for example, the G06.07 RVU. The release ID is often different from the product version IDs of the specific products issued under that RVU.

Remote Server Call (RSC). A software product that let PCs access Pathway servers and other operating system processes on a NonStop host system. RSC is no longer supported.

request. A batch process initiated by a planner and performed by DSM/SCM. Requests include such activities as receiving software into the archive, preparing reports for printing or online viewing, and building a configuration revision. Information needed to process the request is collected from one or more screens, then the request is scheduled to run immediately or at a later, specified time.

revision. A set of software product versions. The number identifying the revision is updated whenever a change is made either to the list of software products or to the input configuration (CONFTEXT) file associated with the product list, or when a request to build a configuration revision is submitted (even if no changes have been made to the revision itself).

RSC. See Remote Server Call (RSC).

saved previous revision. See previously applied configuration.

SCF. See Subsystem Control Facility (SCF).

server. In a Pathway environment, a process that implements requests for database access from a requester. Because DSM/SCM runs in the Pathway environment, it uses servers and requesters to implement a user’s requests to access the DSM/SCM database.

shorthand view. An alternative way of looking at data in one or more SQL/MP tables. It consists of a single table derived from other tables. DSM/SCM provides shorthand views of the DSM/SCM database that specify information from which you can create custom reports.


Glossary SIT

SIT. See system image tape (SIT).

site ID. A unique 6-digit number assigned by HP to identify a particular system.

site-specific subvolume. A subvolume containing files unique to the target system, such as a list of products belonging to the target. Its format is Annnnnn, where nnnnnn is the system site ID.

site update tape (SUT). One or more tapes that contain a target system’s site-specific subvolume and various products. Each product contains a softdoc and a complete set of files. A SUT is delivered with every new NonStop system and can be ordered whenever a new RVU of the system software is available. A full SUT contains the current RVU of the operating system and all product software that has been ordered with it, including release documentation.

snapshot. A list of the target system tape and disk locations, file fingerprints for files managed by DSM/SCM, and DSM/SCM target information. It is compiled on the target system from the target database and sent to the host system to store in the host database. It contains information about the software running on the target system and the products placed on the target by the most recent revision. An instruction to create a snapshot is part of every activation package sent from the host and can also be requested independently through the Target Interface (ZPHITI).

softdoc. A software document provided with each NonStop product that describes new features, corrected problems, and remaining known problems. The softdoc also gives the product name and number; the required hardware, firmware, and software; and the names of supporting manuals.

software input. A collection of one or more products received by DSM/SCM into the archive. The products can be either HP software (an RVU, SPR, or new PVU) or software from a third-party vendor or customer.

software product revision (SPR). The HP method of releasing incremental software updates for the NonStop operating system. An SPR is one or more files that contain one or more fixes to NonStop code. It can also contain code that adds new functions to a NonStop software product. An SPR is identified by a three-letter code attached to the product number; for example, T9050AAB.

software release. See release version update (RVU).

software revision. See revision.

SPI definitions. Subsystem Programmatic Interface files that are included in programs, macros, and routines using the interface procedures; and definition files in data definition language (DDL) for programmers writing their own subsystems.

SPR. See software product revision (SPR).


Glossary SQL/MP

SQL/MP. An HP relational database management system that uses ANSI-standard Structured Query Language (SQL) to describe and manipulate data. You use SQL/MP to define, manipulate and control databases. In the DSM/SCM environment, you use the SQL/MP command interpreter (SQLCI) to define reports against the DSM/SCM database.

SQLCI IN file. A file containing the set of SQLCI statements used to produce a report. The statements contain both static and variable information.

Subsystem Control Facility (SCF). An interactive interface for configuring, controlling, and collecting information from its subsystems.

super ID. A privileged user who can read, write, execute, and purge all files on the system. In the Guardian environment, the super ID has the user ID 255,255.

SUT. See site update tape (SUT).

SWID. The software identification tool invoked by a system generation program that audits file identification information about your software.

System generation program. A system generation program such as SYSGEN or SYSGENR that generates a customized version of the operating system.

SYSnn subvolume. A subvolume on the $SYSTEM volume where the new version of the operating system image is located. Also located on the SYSnn subvolume is system-dependent and release-dependent software. nn is an octal number in the range %00 through %77.

system. The user-assigned name of a NonStop system. The name is set in the system profile. A required backslash (\) followed by up to seven characters, the first of which must be alphabetic.

system generation. The process of creating an operating system to support a particular system configuration and RVU.

system image tape (SIT). A tape that contains a minimum set of software necessary to bring up and run an HP NonStop K-series system or HP NonStop S-series system. When you use DSM/SCM to configure and install your system, you use the SIT only for disaster recovery; it is not needed in normal system installation functions. The SIT is generated by a system generation program and copied to tape by the BACKUP utility. You can create up to nine SITs during any Build/Apply process.

system load. (1) To start the system; to load the operating system image from disk or tape into the memory of a processor. (2) The process of loading the operating system. A system load changes a system from an inactive to an active (or operational) state by loading software that establishes communication between the operating system and configured system peripherals.

system profile. See profile.


Glossary TACLSEGF

TACLSEGF. A segment file containing directories for all HP products on the system that have TACL code. TACLSEGF is shared by all users of the system and is automatically attached to each TACL at log on time.

target. A name that defines a specific system usage, such as WEEKEND, PRODUCTION, or DEVELOPMENT. You can define multiple logical targets for a target system. The target name is part of the configuration revision name.

target directory location (TDL). See TDL.

Target Interface (ZPHITI). A block-mode interface run by an operator or planner at the target system. Its main function is to apply the activation package of software created by the planner on the host system if the host and target systems are not Expand network connected. It can also audit the target software, initiate a backout to a previously applied system, and create a snapshot of the target to be sent back to the host system's database.

target profile. See profile.

target subvolume (TSV). See TSV.

target system. Any system on which software configurations are managed by DSM/SCM, except for a host system. It is also the system on which a specific configuration revision is activated and where the configuration’s files reside. A target system may have multiple configuration revisions defined for it, but only one at a time can be active (the result of performing a system load).

TDL. The name of an OSS disk location on the target system where OSS software files for a configuration are placed. One TDL can contain files for a single product or multiple products. TDL names are contained in the A7CINFO file for each product and are transmitted to the target system in the activation package instructions.

template. See EMS template files.

TMF. See HP NonStop™ Transaction Management Facility (TMF).

TNS. Refers to fault-tolerant HP computers that support the HP NonStop™ operating system and are based on microcoded complex instruction-set computing (CISC) technology. TNS systems run the TNS instruction set. Contrast with TNS/E and TNS/R.

TNS/E. Refers to fault-tolerant HP computers that support the HP NonStop™ operating system and are based on the Intel® Itanium® processor. TNS/E systems run the Itanium instruction set and can run TNS object files by interpretation or after acceleration. TNS/E systems include all HP NonStop systems that use NSE-x processors. Contrast with TNS and TNS/R.


Glossary TNS/R

TNS/R. Refers to fault-tolerant HP computers that support the HP NonStop™ operating system and are based on 32-bit reduced instruction-set computing (RISC) technology. TNS/R systems run the MIPS-1 RISC instruction set and can run TNS object files by interpretation or after acceleration. TNS/R systems include all HP systems that use NSR-x processors. Contrast with TNS and TNS/E.

Transaction Delivery Process. A host process that delivers and receives host transactions. The TDP communicates with a PC through the RSC communications subsystem.

trace. A function that records internal information about a DSM/SCM session or function, such as statements executed, routines called, and parameters passed.

TSV. The subvolume name of a disk location on the target system where the software files for a configuration are placed. One TSV can contain files for a single product or multiple products. TSV names are contained in the A0CINFO file for each product and are transmitted to the target system in the activation package instructions.

version. See base version.

version ID. A code identifying the base version of a software product (such as D44 or G05).

view. See shorthand view.

wild-card character. A character that stands for any possible characters in a search string or in a name applying to multiple objects. DSM/SCM supports an asterisk (*) as a wild card for zero, one, or more consecutive characters when you enter a subvolume name in the Software Input Options dialog box.

work files. Temporary files created by a system generation program that serve as storage areas while it runs. Work files are useful for debugging purposes after system generation. You can choose to make specified work files permanent.

ZPHIRNM. A program that resides on target systems and is run when activating new software. ZPHIRNM renames to their fabricated names the files that currently have actual file names, and renames files with fabricated names to their actual names.


Glossary ZPHIRNM


Index

Numbers12-3 12-3

AA0CINFO file

adding or changing product information C-6

attributes, description of C-10

creating for exported files 17-26

dependency information C-11

destination subvolumes C-11

functions C-12/C-15

opening or creating C-5

overview D-7

product attributes, description of C-6

product dependency lists C-8

security for C-5

Activatingnew software 10-1

tools E-5

Activation packagecontents of 9-4

specifying location of 9-15

transmitting 6-4/6-5

Activity Code descriptions 18-17ADDIF

file, usage C-11

list, creating C-12

Adding a logical target 5-17Apply request

running manually 9-25, 9-27

See also Build/Apply request

See also Requests

viewing status of 9-27

Archivebacking up software inputs 17-22

bringing exported files back into 17-26

compressing inputs in 5-32

definition 6-2, 17-21

exporting files from 17-24

files stored in 17-21/17-23

maintaining 17-21

moving to another volume 5-7, 5-34, 17-27

moving to optical storage 17-27

receiving software into 6-2, 7-3

relocating 5-7, 5-34, 17-27

restoring software inputs 17-23

specifying FSTCACHING for volumes 17-11, 17-27

specifying volumes for 17-11

viewing software in 7-3, 7-10

ASSIGN for toolsactivating E-2, E-5

adding statements E-2

removing statements E-2

Assigning tools E-2, E-5

BBacking out a revision 15-1

after renaming SYSnn

if DSM/SCM will not run or system load fails 15-8

if DSM/SCM will run 15-7

if DSM/SCM will not run 15-6

if DSM/SCM will run 15-2

if no previous configuration 15-6

to older configuration 15-9

Backing up software inputs 17-22Backout

See Backing out a revision

Backup host systemcreating 5-24

overview 5-23

selecting 5-24

DSM/SCM User’s Guide — 529846-014Index - 1

Index C

using 5-26

Build requestSee Build/Apply request

Build type, indicating 5-18, 9-2Building/Applying a configuration revision

examples of 6-4

overview of 6-4, 9-1

Build, FRABIBAB 5-8, 9-3Build, result of 6-4, 9-5Build/Apply request

changing system generation options 9-18

changing TSV locations 9-12

editing planner instructions for 9-23

indicating type of build 5-18, 9-2

initialization

host system 5-18

purpose of 16-2

scheduling 9-22

See also Requests

submitting 9-8/9-24

CCanceling

checked-out objects 17-16/17-17

check-out of

Configuration Manager profile 17-17

configuration revision 17-17

software input 17-17

system profile 17-17

new software revisions 8-22

requests

in Planner Interface 16-8

in Target Interface 13-18

Changing default values 5-15Check-out cancellation 17-16Check-out management

configuration revision 17-16

software input 17-16

system profile 17-16

Check-out of database objects 17-16/17-17CLEANOSS tool

overview 13-24

running 5-5

Clone GroupCreating 19-2

Clone groupcreating 19-2

examples 19-3

CLONE utility 19-6Clone, defining 19-2Cloning 19-1

defining a clone 19-2

defining a master 19-2

requirements 19-1

CNFGINFO toolA0CINFO file

See A0CINFO file

access to C-4

ADDIF list, creating C-12

beginning session C-4

ending session C-3, C-16

file attributes, description of C-10

logging off C-3, C-16

logging on C-4

operational considerations 13-23

overview of functions C-1

requires/replaces information C-8

running C-4

running for exported files 17-26

specifying

DOCPRINT file destination C-13

file functions C-10

file information C-9/C-12

product information C-6/C-9

system generation usage C-14

specifying migration tool usage C-15

specifying product dependencies C-8


Index D

starting C-3

starting in Planner Interface C-4

TACL directory C-15

Cold loadSee System load

Configs Using a SW Input report 18-2Configuration

changing individual settings 5-15

current 8-24

previous 8-24

Configuration Differences report 18-2Configuration Manager profile

changing defaults of 5-15

check-out management 17-16

initializing 5-6, 5-33

maintaining 17-2

overview 17-2

updating

from Maintenance Interface 5-6, 5-33

from Planner Interface 17-2

Configuration Product Files report 18-3Configuration Products report 18-3Configuration revision

building/applying

examples of 6-4

overview of 6-4, 9-1, 9-27

Build/Apply request


scheduling 9-22

submitting 9-8/9-24


Configuration Revisions screen 2-5

contents of 6-4, 9-1

default name for 17-6


listing history of 8-13

performing initial revision 5-18

Configuration Revisions screen, Planner Interface 2-5Configuration revisions window

footnote definitions 8-26

sharing software configurations 8-26

Configurations Using a Product report 18-2Configuring DSM/SCM

defining host and target systems 4-2

verifying 2-16

Contents of All Configs report 18-3Copying products to new software revision 8-18/8-23Creating

a snapshot of the target system 17-19

an alternate $SYSTEM 5-22

DD46 DSM/SCM PVU

changes in B-3

migrating to B-3

Data files 5-38Database

See also Host database and Target database

checked out 17-16

managing access to 17-16/17-17

objects, cancelling check-outs 17-16

relocating 17-17

shorthand views of, overview 18-16

target system, verifying 17-18

updating 17-18

verification 17-18

Database administratoractivities 4-10

list 5-12

responsibilities 1-6, 4-13

security

initial setting (Target) 5-12

updating 5-11

tasks 4-13


Index E

Decompressing files 4-8Default values, changing 5-15Deleting

entire software configuration 17-23

logical target 5-21

new software revision 8-24

old software revisions 8-24

products from new revision 8-24

requests 13-18, 16-8

software inputs 17-23

SYSnn 17-15

target 5-21

DELIF file, usage C-11Destination subvolume, description of C-11Developer files, exporting 17-24/17-26Disaster recovery 14-14Discrepancies

during initialization 5-39

initial report of 5-39

resolution of 5-37/5-38, 13-17

reviewing 5-39

Discrepancy report 5-38, 18-3Disk space

estimating amount freed 17-22, 17-28

DOCPRINT filefunction C-13

specifying destination C-13

DSM/SCMaccess to 5-11, 5-13

migrating to D46 PVU B-3

overview 1-1/1-2

program group, contents 4-9

usage examples 11-1

DSM/SCM Web InterfacesInstallation Procedure 20-2

Requirements 20-1

Starting the Application 20-2

EEMS

exporting templates 17-24

installing templates 10-6

printing messages 13-4

viewing events 13-2

Enabling traces 14-3Error messages


on the host 13-2

on the target 13-3

on the workstation 13-4

Pathway errors 13-2

SQL errors 13-2

viewing non-request-related 13-4

ExitingCNFGINFO tool C-3, C-16

INITENV 2-16

Maintenance Interface 2-10



Expandsetting usage flag 17-5

Expand, setting usage flag 17-5Export Files request

See Exporting files

Exporting files 17-24

FFALLBACK macro 15-10File adoption

Build/Apply option 9-20

File discrepancy 13-17File functions

description of C-12

DOCPRINT C-13

Migration C-15

specifying with CNFGINFO tool C-10

SYSGEN C-14


Index G

TACLSEGF C-15

File placement options 9-19File security

See Security or Safeguard

Filesexporting

See Exporting files

listing in a product 8-7

listing in an SPR 8-9

returning to archive 17-26

Files not to purgeZFB* D-9

ZPHIRNM work files D-10

Filtering traces 14-6Firmware, updating 10-4FRABIBAB

defined 9-3

file ownership 5-8, 9-3

FSTCACHING modifier, for archive volumes 17-11, 17-27

GGroups

adding members to 7-14

disbanding 7-15

displaying members of 7-14

forming for products 7-12

forming for software inputs 7-11

hiding members of 7-14

input group list 7-13

maintaining on PC 7-11

overview 7-11

product group list 7-13

removing members from 7-15

sharing among planners or clients 4-8

viewing list of 7-12/7-13

viewing product groups 7-13

viewing software input groups 7-13

HHeap Manager Selection 8-15, 8-20Host database

definition 1-5

updating 17-18

Host database managerdisabling trace 14-6

enabling trace 14-4

Host Maintenance interface,disabling trace from 14-6Host system

backup

creating 5-24

overview 5-23

selecting 5-24

using 5-26

configuring DSM/SCM on 5-2

definition 1-3, 1-4

IIndependent snapshot 17-19INITENV

information needed by 5-32

INITLOG file D-6

INITSTAT file D-6

monitoring DSM/SCM configuration D-6

running, to configure host 5-4, 5-30

verifying DSM/SCM configuration 5-5, 5-32

when to run 5-4

Initialization Build/Applyadditional logical targets 5-18

host system 5-18

resolving discrepancies, host system 5-39

Initializing the host system 5-18INITLOG file D-6INITSTAT file D-6


Index L

Input groupsSee Groups

InstallationPlanner Interface 5-3, 5-30

Planner Interface, restoring files from SUT B-4

Installation Procedure for DSM/SCM Web Interfaces 20-2Installing user template 9-6Instructions

See Operator instructions

IN_fileSee SQLCI IN_file

LLogical target

adding 5-17

definition 1-4

deleting from system 5-21

LogoffCNFGINFO tool C-3, C-16




LogonCNFGINFO tool C-3, C-4

ID 2-15




MMacros, SIT2SCM 14-14Maintenance Interface

canceling checked-out objects 17-16

changing Configuration Manager profile 17-2

configuring host system 5-13

configuring Pathway for 2-6

enabling trace 14-4

for host system 2-6

for target system 2-6

function keys 2-9

logging on 2-7

Maintenance Interface Main Menu screen 2-8

managing

database administrator security 5-11

exclusive access 17-16/17-17

operator security 5-13, 5-14

planner security 5-9, 5-10

volumes 17-11

overview of functions 2-6/2-7

performing archive maintenance 17-21

profile maintenance

Configuration Manager 17-2

system 17-6/17-10

relocating the archive 17-27

relocating the database 17-17

Master, defining 19-2Members

adding to group 7-14

removing from group 7-15

MessagesPlanner Interface 16-6

viewing EMS events 13-2

Migrationconsiderations 13-12

migrating to DSM/SCM D46 PVU B-3

migration file function C-15

tool, specifying usage C-15

Multiple logical targetsdeleting 5-21

troubleshooting 13-5

NNetwork considerations 13-9NEW CONFIG target name 9-25, 10-3


Index O

New softwareSee also Software revisions

activating on target system

overview 10-1

running ZPHIRNM 11-1

standard operator instructions 10-3

New Software Revision screen, closing 8-22

Notepad, using to edit planner instructions 9-7/9-23

OObsolete SYSnn, keeping 6-2Online help

context-sensitive help 2-18

for block-mode interfaces 2-18

for graphical user interfaces 2-18

Operatoractivities 4-16

instructions for activating software 10-3

instructions, getting 9-26

list 5-13


reviewing instructions from planner 9-26, 10-3

security

managing 5-13

setting initial 5-13

updating 5-13

OSScleaning target work files 13-24

initializing 13-24

reports

Configuration Product Files 18-3

Discrepancy 18-3

fingerprints for special files 18-6

Software Product Files 18-6

System 18-6

OSS file managementbacking out 15-10

disabling 17-6

enabling 17-6

falling back 15-10

upgrading to B-3

Output optionschanging 9-14

changing defaults 17-7, 17-9

overriding 9-14

OVERRIDE-SYSNN 6-2OVERRIDE-SYSNN-DIFFERENT-OS 6-2

PParameters

adding to report 18-11

changing description of 18-12

changing type 18-12

defining for new report 18-15

deleting from report 18-11

explanation of 18-8

run-time, entering values for 18-8

Parking lot 2-6PATHCOLD, running 12-3Perform backout, after renaming SYSnn 15-7Performance, improving system 13-8, 17-11PHIH_ACT_CONTROL_SVIEW 18-16PHIH_ACT_PARAM_SVIEW 18-18PHIH_CNFG_MGR_PRF_SVIEW 18-19PHIH_CNFG_PRD_VER_SVIEW 18-20PHIH_CNFG_PVL_FL_SVIEW 18-19PHIH_DELF_CONFIG_SVIEW 18-21PHIH_EMS_LOG_SVIEW 18-22PHIH_LTARGET_PRF_SVIEW 18-22/18-24PHIH_PTARGET_PRF_SVIEW 18-27PHIH_SS_FILES_SVIEW 18-24PHIH_SW_INPUT_FL_SVIEW 18-25/18-26PHIH_SW_INPUT_PRD_SVIEW 18-26PHIH_TAPE_DDRIVE_SVIEW 18-27


Index P

PHIH_TSV_SVIEW 18-28PHIH_VOL_SVIEW 18-28Planner 4-14

activities 4-13

editing instructions 9-23

groups 8-25

list 5-10


security

setting initial 5-10

updating 5-9

Planner Interfaceassigning and activating tools E-5

Build/Apply request

changing output options 9-14


scheduling 9-22

submitting 9-8/9-24

canceling

requests 16-8

revisions 8-22

changing TSV locations 9-12

choosing requests to display 16-4

Configuration Revisions screen 2-5

considerations 13-20

copying products to new revision 8-18/8-23

deleting

products from new revision 8-24

revisions 8-24

targets 5-21

disabling trace from 14-5

documents, overview of preparing 8-10

editing Planner instructions 9-23

editing revision notes 8-21

enabling trace from 14-3

exiting 2-4, 2-6

exporting files from archive 17-24

files

choosing display order 8-7

groups

See Groups

listing files in a product 8-7

listing products in an input 8-6

logging off 2-4

logging on 2-4

main window (figure) 2-4

overview of functions 2-4

parking lot 2-6

products

choosing display order 8-6

deleting from new revision 8-24

viewing by group 7-13

receiving software into archive 7-3

release documents

preparing 8-11/8-12

viewing online 8-13

reports

preparing 8-10, 18-7/18-9

viewing online 18-9

restarting requests 16-7

restoring installer from SUT B-4

scheduling requests 16-2

snapshot

receiving on disk 9-28

receiving on tape 9-29

softdocs

preparing 8-10/8-12

viewing online 8-13

Software in Archive screen 2-5

software inputs

See Software inputs

software revision notes 8-9, 8-21

software revisions

See Software revisions

starting a Planner Interface trace 14-4

starting CNFGINFO tool C-4

target profile


Index R

changing output defaults 17-7, 17-9

changing system generation defaults 17-9

target systems

adding new logical target 5-17, 5-18

changing profile information 17-7

deleting a target 5-21

viewing

list of requests 16-3/16-6

other EMS events 13-3

request EMS events 13-2, 16-7

software in Archive 7-3

status of requests 16-4

Prepare Documents request, purpose of 16-2Prepare Report request, purpose of 16-2Privileged declarations files, exporting 17-24Product groups

See Groups

Productsapplying SPRs to 8-23

choosing display order

in software input 8-6

in software revisions 8-6, 8-7

copying to new software revision 8-18/8-23

deleting from new software revision 8-24


listing

files in 8-7

in a software revision 8-6/8-10

in an input 8-6

viewing 8-6, 8-7

viewing by group 7-13

viewing version details 8-8, 8-21

PRODUCTS.DAT 7-11Profiles


overview 17-6

system 17-6

target, changing information 17-7

Purge filesSee Files not to purge

RReceive Snapshot request

purpose of 16-2

scheduling 9-29

Receive Software requestSee also Software inputs

purpose of 16-2

RefreshingEMS events screen 13-2/16-6

Software in Archive screen 7-3

Reinitializinga system 5-1

DSM/SCM, without a system load 6-2

Release documentspreparing 8-10, 8-11/8-12

viewing during revision planning 8-10

viewing online 8-13

REMOTEPASSWORD 1-4Renaming

DSM/SCM managed volumes 17-14

product files using ZPHIRNM 11-1

the managed SYSnn 12-2

the SYSnn, backout procedure 15-7

REPLACEBOOT, running 10-4Reports

adding parameters 18-11

adding to Planner Interface list 18-11

changing contents 18-10/18-12

changing format of 18-10/18-12

changing parameter description 18-12

changing parameter type 18-12

changing, overview 18-10

Configs Using a SW Input 18-2


Index S

Configuration Differences 18-2

Configuration Product Files 18-3

Configuration Products 18-3

Configurations Using a Product 18-2

Contents of All Configs 18-3

customized

adding 18-15

deleting 18-15

overview 18-12

deleting 18-15

deleting parameters 18-11

Discrepancy 18-3

displaying list of 18-7

list of available reports 18-2/18-6

parameters

adding to report 18-11, 18-15

defining for new report 18-15

deleting from report 18-11

entering values for 18-8

preparing

for viewing or printing 18-7/18-9

overview 8-10

Request EMS Log 18-4

Request Log 18-4

requesting discrepancy report 5-38

scheduling request 18-9

shorthand views for

See Shorthand views

standard, list of 18-2/18-6

System report 18-13

viewing descriptions of 18-7

viewing from the Planner Interface 18-7

viewing online 18-9

RequestsBuild/Apply 9-4, 9-22

canceling


in Target Interface 2-13, 13-18

choosing types to display 16-4

Create Snapshot 17-19

deleting 13-18, 16-8

discrepancy report 5-38

displaying by type 16-4

error messages for 16-7

Perform Backout 15-1

Prepare Release Documents 8-11/8-12

Prepare Report 18-7/18-9

Prepare Softdoc 8-10/8-12

Receive Software 7-3

Request EMS Log report 18-4

Request Log report 18-4

restarting 16-7

retention period for 17-3

scheduling 16-2

scheduling options 7-7

source options 7-6

status messages 16-6

Verify Database 17-18

viewing list of 16-3/16-6

viewing status of 16-4, 16-7

Requires/Replaces Information screen C-8Restarting requests 16-7Restore DSM/SCM from the SUT B-4Reviewing discrepancies 5-39Revision notes

definition 8-9

editing 8-21

Revision, backing out 15-1Roles, guidelines for assigning 4-10RPASSWRD 1-4

SSafeguard

setting required flag 17-5

using Guardian security instead of 9-15

Saving new software revision 8-22Scheduling requests

Build/Apply 9-22


Index S

Export Files 17-24/17-26

options 7-7

overview 16-2

Prepare Report 18-9

Receive Software 7-7

Securitysetting default for new files 9-17

setting for database administrator 5-11, 5-12

setting for operator 5-13, 5-14

setting for planner 5-9, 5-10, 5-13

settings for DSM/SCM users 1-6

using Guardian instead of Safeguard 9-15

SETUP.EXE, running 4-8Sharing software configurations 8-25Shorthand views

Activity Control 18-16

Activity Param 18-18

Configuration 18-21


Configuration Product Version Files 18-19

Configuration Products Versions 18-20

EMS 18-22

overview 18-16

SELECT statement 18-16

Snapshot Files 18-24

Software Input Files 18-25/18-26

Software Input Products 18-26

System 18-27

Tape Drives 18-27

TSV 18-28

Volumes 18-28

Show EMS messages screen 13-3Show non-request-related errors screen 13-4SIT

booting from 14-14

creating multiple 5-21

SIT2SCM 14-14

SIT2SCM macro 14-14Site ID, entering for system 17-5Snapshot

creating an independent 17-19

receiving from target system 6-5

examples of 6-5

on disk 9-28

on tape 9-29

when to request 17-19

Softdocspreparing 8-10, 8-10/8-12

using to edit planner instructions 9-6

viewing

for an SPR 8-10

online 8-13

Softwareactivating on target system 6-5

examples of receiving 7-6

receiving 7-3

receiving into archive 6-2, 7-3

revision notes

changing 8-21

viewing 8-9

Software in Archive screen 2-5Software input groups

See Groups

Software inputsbacking up 17-22

changing description of 7-9


choosing display order of products 8-6

choosing for display 7-10

compressing in archive 5-32

deleting from archive 7-3, 17-23


listing files in 8-7

listing products in 8-6

managing, overview of 7-1


Index S

receiving, overview of 7-1

restoring from tape 17-23

specifying source options 7-6

types of 6-2

viewing by group 7-12/7-13

viewing description of 7-9

Software product revisionsee SPR

Software revisionscanceling new revisions 8-22

changing revision notes 8-21

choosing display order of products 8-6, 8-7

closing new revision 8-22

copying products to 8-18/8-23

creating 8-1, 8-15

definition 6-3, 8-1

deleting products from 8-24

deleting revision 8-24

initial contents 6-3

listing files in product version 8-7

listing history of 8-13

listing products in 8-6/8-10

planning 6-3

product versions, listing files in 8-7

saving new revision 8-22

sharing 8-25

viewing

product version details 8-8, 8-21

revision notes 8-9

SPR details 8-9

Space management considerations 13-9Special cases, ADDIF C-12SPI files, exporting 17-24SPRCHECK tool 2-17, 8-2SPRs (software product revisions)

applied to a product 8-8, 8-21, 8-23

checking for recommended 2-17, 8-2

definition 6-2

example of installing 9-29

order of display 8-23

viewing files in 8-9

SQL Statistics, updating 13-8SQLCI

IN_file

changing name of 18-11

creating 18-12

definition of 18-10

editing 18-10

location of 18-10, 18-15

SELECT statements in 18-10, 18-12

using 18-10, 18-12

STARTSCM startup program 2-2Startup program, STARTSCM 2-2Status code descriptions 18-17Status messages in Planner Interface

list of 16-6

viewing 16-7

STOPSCM shutdown file 2-2, 2-7, 2-15, 11-1, 11-4Super ID

required for FALLBACK macro 15-11

required to license files C-10

Support Note, checking for new SPRs 2-17, 8-2SUT (site update tape)

copying products from 8-18

creating initial revision from 6-3

definition 6-2

preparing release documents for 8-11

SWINPUTS.DAT 7-11SYSnn

always using the same 12-2

applying software to 9-26

deleting 17-15

keeping the obsolete 6-2

list 9-11

specifying 9-26

System generation


Index T

changing defaults 17-9

errors in the output file 13-4

file function C-14

forcing a 9-18

options

changing defaults 17-9

overriding 9-18

output, deleting from archive 17-22

usage, specifying C-14

System loadavoiding 6-2

in operator instructions 10-5

reinitializing DSM/SCM without 6-2

System profilecheck-out management 17-16

displaying checked-out profiles 17-16

updating 17-4/17-5

System reportcreating 18-13

definition 18-13

Systems, listing 17-5

TTACL directory for DSV C-15TACL Macro, UPDATES 13-8TACLSEGF file function C-15Target database

definition 1-5

updating 17-18

verifying 17-18

Target information, changing 17-6Target Interface

applying software manually 9-25, 9-27

backing out a revision 15-1

canceling requests 13-18

disabling trace from 14-6

enabling trace 14-4

function keys 2-13

logging on 2-11


printing EMS messages 13-4

reviewing operator instructions 9-27, 10-2, 10-3

selecting a target 9-25, 10-3

snapshot, creating 17-19

submitting requests

Create Snapshot 17-19

Get Operator Instructions 9-25/9-26, 10-3

Perform Backout 15-1

System Report 18-13

Verify Database 17-18

system report, creating 18-13

verifying target system database 17-18

viewing EMS messages 13-3, 17-18, 17-20

Target Maintenance Interface (TMI)See Maintenance Interface

Target Maintenance interface,disabling trace from 14-6Target subvolumes

See TSVs

Target systemsactivating new software

overview 10-1

running ZPHIRNM 11-1

standard operator instructions 10-3

adding new logical target 5-17/5-18

changing profile information 17-7

creating a snapshot of 17-19

database volume 5-32

definition 1-4

deleting a target 5-21

listing all managed by DSM/SCM 17-5

listing revision history of software configuration 8-13

performing maintenance for 2-6

profiles for, maintaining 17-4, 17-6/17-10


Index U

requesting a snapshot of 17-19

See also Logical target

setting passwords for 1-4

verifying database of 17-18

Target work files, cleaning 13-24Tool ASSIGN E-5

adding statements for E-2

button

activating E-2, E-5

removing statements for E-2

Tracedisabling 14-5

enabling 14-3

filtering 14-6

levels 14-7

search strings 14-8

TRACEINI file 14-6TSVs

adding to a volume 9-14

changing location of 9-12, 9-15

discrepancy 13-17

moving to new volume 9-14

removing from a volume 9-14

working files D-9

UUPDATES 13-8Updating

DSM/SCM databases 17-18

SQL Statistics 13-8

Upgrade to DSM/SCM D46 PVU B-3

VVerify database 17-18VERIFYI

defined 2-16

INITENV automatically running 5-5, 5-32

running 2-16

Version details, viewing 8-8View

products, summary 8-6, 8-7

Viewingerror messages 13-2

products 8-6

software in archive 7-10

Volumesarchive 17-11

change name of 17-14

changing usage information from Planner Interface 17-12

FSTCACHING modifier 17-11, 17-27

initializing, on target system 17-12

managing 17-11

not to purge or alter D-2

scratch 17-11

usage by DSM/SCM 17-12

ZDSMSCM, changing 17-13

$AUDIT D-2

$DSMSCM D-2

$SYSTEM D-6

WWeb Interfaces Requirements 20-1Winsock, configuring on the PC 4-9

ZZDSMSCM subvolume

changing 17-13

creating a new 17-13

purging 17-13

switching 17-14

ZFB* files D-9ZMP* files D-10ZPHIRNM

messages and error handling 11-6


running


Index Special Characters

in Preview mode 11-2

on actual files 11-4

overview 11-1

starting 2-15, 11-1

work files D-10

Special Characters$AUDIT volume D-2$DSMSCM volume D-2$SYSTEM volume D-6


DSM/SCM User's Guide - h20628. · DSM/SCM User’s Guide. Abstract. This guide describes the...

Documents

Transcript of DSM/SCM User's Guide - h20628. · DSM/SCM User’s Guide. Abstract. This guide describes the...