ALL-IN-1____________________________________________ Installation: Guide Order Number: AA-N323J-TE Revision/Update Information: Revised for ALL-IN-1 Version 3.1 Operating system: OpenVMS VAX Version 5.5-2 and higher and OpenVMS AXP Version 6.1 Software version: Version 3.1 ________________________________________________________________ June 1994 Possession, use, or copying of the software described in this documentation is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. While Digital believes the information included in this publication is correct as of the date of publication, it is subject to change without notice. Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. © Digital Equipment Corporation 1994. All Rights Reserved. We welcome your comments on this book. Please use one of the following ways to send your comments: o Send an electronic mail message to books@reo.mts.dec.com o Send an electronic mail message to S=IDC BOOKS; O=digital; OU1=reo; P=digital; A=CWMail; C=gb o Send a fax to (+44) 1734 206018 The following are trademarks of Digital Equipment Corporation: ACMS, ALL-IN-1, Alpha AXP, CDA, DDIF, DECnet, DEC FMS, DEC Notes, DECtrace, DECwindows, EDT, MAILbus, OpenVMS, TeamLinks, TeamRoute, VAX, VAXcluster, VAX DATATRIEVE, VAX FMS, VAX Notes, VMS, VMScluster, WPS-PLUS, the AXP logo and the DIGITAL logo. Calendar Manager is a trademark of Russell Information Sciences, Inc. DIF is a trademark of Software Arts Production Corporation. Ethernet is a trademark of Xerox Corporation. Lotus 1-2-3 is a registered trademark of Lotus Development Corporation. MacWrite and MacDraw are registered trademarks of Claris Corporation. Macintosh is a registered trademark of Apple Computer Inc. Microsoft is a registered trademark of Microsoft Corporation. Motif is a registered trademark of Open Software Foundation, Inc. PostScript is a registered trademark of Adobe Systems, Inc. WordPerfect is a registered trademark of WordPerfect Corporation. All other trademarks and registered trademarks are the property of their respective holders. This document was prepared using VAX DOCUMENT, Version 2.1. _________________________________________________________________ Contents Preface................................................... xi 1 Planning an ALL-IN-1 Version 3.1 Installation 1.1 Checklist of Installation Decisions and Information................................... 1-2 1.2 General Information About Installing ALL-IN-1 Version 3.1 .................................. 1-7 1.2.1 Support for Different Architectures....... 1-7 1.2.2 Version 3.1 Architecture-Dependent Files and Directories........................... 1-8 1.2.3 Components of ALL-IN-1 Version 3.1........ 1-8 1.2.4 Additional Languages...................... 1-9 1.2.5 Accounts Needed for ALL-IN-1.............. 1-9 1.2.6 Use of ALL-IN-1 Areas..................... 1-10 1.3 Installation Paths............................ 1-10 1.4 Installing on More Than One Architecture in a VMScluster.................................... 1-14 1.4.1 Installing AXP Architecture Support....... 1-16 1.4.2 Installing VAX Architecture Support....... 1-17 1.4.3 Replacing a VAX System with an AXP System.................................... 1-18 1.5 Mail System Planning.......................... 1-19 1.5.1 Batch Queue for Mail...................... 1-20 1.5.2 Using Message Router...................... 1-20 1.5.3 Level of Mail Directory Support........... 1-21 1.5.4 Setting up a Remote Directory Service..... 1-23 1.5.5 Translating Outgoing Mail Messages to ASCII..................................... 1-24 1.6 Other Software Referenced by the Installation Procedure..................................... 1-25 1.6.1 Software Which can be Integrated During the Installation.......................... 1-25 iii 1.6.2 Compound Document Architecture (CDA) Support................................... 1-26 1.6.3 Installing WPS-PLUS as the Default Editor.................................... 1-27 1.6.4 Using TCP/IP to Communicate With Client Applications.............................. 1-28 1.7 Running the IVP (Installation Verification Procedure).................................... 1-29 1.8 Planning an Upgrade Installation.............. 1-29 1.9 What to do Next............................... 1-30 2 Preparing to Upgrade a Customized System 2.1 Overview of the CART.......................... 2-2 2.2 Modified ALL-IN-1 Systems..................... 2-5 2.3 Understanding the CART Reports................ 2-6 2.3.1 Types of CART Report...................... 2-6 2.3.2 Format of the CART Reports................ 2-8 2.3.3 CART Status Codes and the Severity of Conflict.................................. 2-9 2.4 Preparing to Run the CART..................... 2-11 2.4.1 Printing a System Modification Report..... 2-11 2.4.2 Importing Elements from Outside Customization Management.................. 2-11 2.4.3 Customized Help Modules................... 2-11 2.4.4 Customized Message Files.................. 2-12 2.5 Running the CART.............................. 2-12 2.6 What to do After Running the CART............. 2-14 2.6.1 Checking the Site Elements Report......... 2-14 2.6.2 Checking for Missing Elements (Status Codes B and C)............................ 2-14 2.6.3 Rerunning the CART........................ 2-16 2.6.4 Preparing Your Upgrade Plan............... 2-16 2.6.5 Guidelines for Resolving Conflicts........ 2-18 2.6.6 CART Resolution Procedure................. 2-18 2.6.7 Planning Postinstallation Tasks........... 2-19 2.7 Mandatory Status Codes (I, K, L, M and N)..... 2-20 2.8 Recommended Status Codes (D, E, O, P and Q)... 2-24 2.9 Informational Status Codes (A, F, G, H and R)............................................ 2-27 iv 3 Preparing Your System for Installation 3.1 Preinstallation Checklist..................... 3-1 3.2 Reading and Printing the Online Release Notes......................................... 3-5 3.3 Checking Prerequisite and Optional Software... 3-6 3.4 Linking Software Products During the Installation.................................. 3-9 3.5 Checking the Licence for the Installing Account....................................... 3-10 3.6 Registering License Product Authorization Keys (PAKs)........................................ 3-10 3.6.1 Registering Before a Full Installation.... 3-11 3.6.2 Registering License PAKs for Software Provided with ALL-IN-1 Version 3.1........ 3-11 3.7 Example Order for Installing Optional Software...................................... 3-12 3.8 Installation Procedure Requirements........... 3-13 3.8.1 Installing Account Requirements........... 3-13 3.8.2 System Parameters......................... 3-14 3.8.3 Displaying Current System Parameters...... 3-17 3.8.4 Changing System Parameter Values.......... 3-17 3.8.4.1 Updating Dynamic System Parameters with AUTOGEN................................. 3-19 3.8.4.2 Updating Non-Dynamic System Parameter with AUTOGEN............................ 3-19 3.8.5 Disk Space on Your System Disk or Alternate Working Device.................. 3-20 3.8.6 Using the OA$LIB_SHARE Disk as the AWD.... 3-21 3.8.7 Disk Space for ALL-IN-1 Areas on Target Disks..................................... 3-21 3.8.8 Assigning Logical Names to Your Disks..... 3-22 3.8.9 Full Installation: Disk Space for ALL-IN-1 Areas..................................... 3-23 3.8.10 Upgrade Installation: Disk Space for ALL-IN-1 Areas............................ 3-24 3.8.11 Addition of Architecture Support: Disk Space for ALL-IN-1 areas.................. 3-25 3.8.12 Disk Quota Allocation..................... 3-26 3.8.13 Installed Images.......................... 3-26 3.8.14 Installing FDVMSG.EXE and FDVSHR.EXE Images.................................... 3-27 3.8.15 Installing Other Images................... 3-27 3.8.16 Checking The Location of DCLTABLES.EXE.... 3-28 v 3.9 Additional Tasks for Upgrade Installations.... 3-28 3.9.1 Copying Customized Data Files............. 3-29 3.10 Using a Remote Message Router................. 3-30 3.10.1 Create an ALL-IN-1 Mailbox on the Remote Message Router Node ...................... 3-30 3.11 Preinstallation System Check.................. 3-31 3.11.1 Types of Errors Reported.................. 3-32 3.11.2 Running the Perform all Preinstallation Checks (PC) Option........................ 3-32 3.12 System Preparation Tasks...................... 3-33 3.12.1 Shut Down ALL-IN-1........................ 3-34 3.12.2 Deinstall Files Installed in Memory....... 3-35 3.12.3 Back Up Your System and Target Disks...... 3-35 4 Planning and Implementing a Minimal Shutdown Upgrade 4.1 How the Minimal Shutdown Upgrade Works........ 4-2 4.1.1 Explanation of Phase 1.................... 4-3 4.1.2 Files and Directories Involved in Phase 1......................................... 4-4 4.1.3 Explanation of Phase 2.................... 4-6 4.2 Disadvantages of a Minimal Shutdown Upgrade... 4-8 4.3 Installation Planning Decisions............... 4-8 4.4 Preparing Your System for a Minimal Shutdown Upgrade....................................... 4-9 4.5 Installation Procedure for Minimal Shutdown Upgrade....................................... 4-10 4.5.1 Procedure for Phase 1..................... 4-11 4.5.2 Phase 2 Procedure......................... 4-14 4.6 Manual Postinstallation Procedures............ 4-16 4.6.1 Running the Postinstallation Procedures... 4-19 5 Installation Procedure: Full, Upgrade and Addition of Architecture Support 5.1 Keeping a Record of the Installation.......... 5-3 5.2 Installation Procedure for Full and Upgrade Installations................................. 5-3 5.3 Adding Architecture Support................... 5-23 5.3.1 Before You Start.......................... 5-24 5.3.2 Installation Procedure for Adding Architecture Support...................... 5-25 5.4 Automatic Postinstallation Tasks.............. 5-34 vi 5.5 Manual Postinstallation Tasks................. 5-35 6 Installation Procedure: Additional Languages 6.1 Keeping a Record of the Installation.......... 6-2 6.2 Installation Procedure for Additional Language Installations................................. 6-2 6.3 Installing Architecture Support for an Additional Language........................... 6-11 7 Installation Errors and Failure 7.1 Common Error Message That Does Not Require Action........................................ 7-1 7.2 Common Errors Which Require Action............ 7-1 7.3 Failure During Postinstallation............... 7-2 7.4 Installation Failure.......................... 7-3 7.4.1 Failure of Upgrade Installations in Safety Mode...................................... 7-3 7.4.2 Failure of Upgrade Installations in Non-Safety Mode........................... 7-3 7.4.3 Full Installations........................ 7-4 7.4.4 Failure Due to Insufficient Dynamic Memory.................................... 7-4 7.5 Error Messages when Running the IVP........... 7-4 7.6 IVP Failure................................... 7-6 8 Postinstallation Tasks 8.1 Checklist of Manual Postinstallation Tasks.... 8-1 8.2 Start ALL-IN-1 on all Nodes in a VMScluster System........................................ 8-6 8.3 Create or Modify the Site-specific ALL-IN-1 Startup Procedure............................. 8-6 8.4 Edit the Site-specific Startup Procedure...... 8-7 8.5 Replace the DCLTABLES on Cluster Systems...... 8-9 8.6 Delete Files That Are No Longer Required...... 8-10 8.7 Install Missing Images........................ 8-10 8.8 Recompile Form Libraries...................... 8-11 8.9 Migrate SITELINK30 Using Customization Management.................................... 8-11 8.10 Migrating Your Customizations After Upgrading..................................... 8-12 vii 8.10.1 Running the CART Resolution Procedure..... 8-13 8.10.2 Deleting Obsolete Files................... 8-14 8.10.3 Restoring Customizations to Data Files.... 8-15 8.10.4 Replacing the Help Modules for Your Application............................... 8-16 8.11 Link ALL-IN-1 to Include Code-level Customizations................................ 8-17 8.12 Check Entries in RIGHTSLIST.DAT............... 8-17 8.13 Setting up Remote Mail........................ 8-17 8.13.1 Create a Mailbox for ALL-IN-1............. 8-19 8.13.2 Modifying the Message Router Mailbox Entry..................................... 8-20 8.13.3 Setting Up Area Routing................... 8-20 8.13.4 Configuring the VMSmail Gateway for Remote Access.................................... 8-22 8.13.5 Setting Up the Mail Directory............. 8-22 8.13.5.1 Message Router is in the Same VMScluster.............................. 8-23 8.13.5.2 Message Router is not in the Same VMScluster.............................. 8-25 8.13.6 Remote Mail Directory Startup Procedure... 8-27 8.14 Restoring Your Sender and Fetcher Environment................................... 8-28 8.15 Delete or Remove Old Mail Log Files........... 8-28 8.16 Convert WPS-PLUS for VMS Documents For Use in ALL-IN-1 ..................................... 8-28 8.17 WPS-PLUS Login Command Procedure.............. 8-30 8.18 Install the File Cabinet Server Distributed License....................................... 8-31 8.19 Moving the CDA DOC_STYLE Files................ 8-31 8.20 Update the Facility Definition to Use DECtrace...................................... 8-31 A ALL-IN-1 Version 3.1 Distribution Media A.1 Magnetic Tape and TK50 Kits (for VAX Installations)................................ A-1 A.2 Compact Disc Distribution Kits (VAX or AXP Installations)................................ A-3 viii B ALL-IN-1 Version 3.1 Files and Directories B.1 New Directories Created in ALL-IN-1 Version 3.1........................................... B-1 B.2 Files in the ALL-IN-1 Kit..................... B-2 B.3 Files Installed in Non- ALL-IN-1 Directories................................... B-2 Index Figures 1-1 Installing AXP Architecture Support....... 1-17 1-2 Installing VAX Architecture Support....... 1-18 2-1 What the CART Does........................ 2-4 4-1 Minimal Shutdown Upgrade: Phase 1......... 4-3 4-2 Minimal Shutdown Postinstallation Phase... 4-17 Tables 1-1 Checklist of Installation Decisions and Information Required...................... 1-2 1-2 Installation Paths........................ 1-12 1-3 Strategy for Adding Architecture Support................................... 1-15 1-4 Mail System Planning Decisions............ 1-19 1-5 Installation Options for Levels of Mail Directory Support......................... 1-22 1-6 Questions Asked During a Customized Configuration............................. 1-24 1-7 TCP/IP Service Information................ 1-28 1-8 What To Do Next........................... 1-30 2-1 Terminology used by the CART.............. 2-2 2-2 CART Reports.............................. 2-7 2-3 CART Conflict Severity, Status Codes and Actions................................... 2-10 2-4 CART Status Codes B and C................. 2-15 2-5 Mandatory Status Codes (I, K, L, M and N)........................................ 2-21 ix 2-6 Recommended Status Codes (D, E, O, P, Q).. 2-25 2-7 Informational Status Codes (A, F, G, H, R) 2-28 3-1 Preinstallation Checklist................. 3-1 3-2 Prerequisite and Optional Software........ 3-7 3-3 Process Account Quotas for the Installing Account................................... 3-14 3-4 Minimum System Parameter Values Required.................................. 3-15 3-5 Changing System Parameter Values.......... 3-18 3-6 Full Installation: Disk Space for ALL-IN-1 Areas..................................... 3-23 3-7 Upgrade Installations: Disk Space for ALL-IN-1 Areas ........................... 3-25 3-8 Addition of Architecture Support: Disk Space for ALL-IN-1 Areas.................. 3-26 4-1 Minimal Shutdown Upgrade: Disk Space for ALL-IN-1 Areas ........................... 4-10 4-2 Installation Procedure for Phase 1 of the Minimal Shutdown Upgrade ................. 4-11 4-3 Installation Procedure for Phase 2 of the Minimal Shutdown Upgrade ................. 4-14 4-4 Minimal Shutdown Postinstallation Procedures................................ 4-17 5-1 Information About the Installation Procedure................................. 5-2 5-2 Installation Procedure for Full and Upgrade Installations..................... 5-4 5-3 When to Install VAX or AXP Architecture Support................................... 5-24 5-4 Installation Procedure for Adding Architecture Support...................... 5-25 6-1 Installation Procedure for An Additional Language ................................. 6-3 6-2 Installation Procedure for Addition of Architecture Support for an Additional Language.................................. 6-11 8-1 Postinstallation Tasks.................... 8-1 x 8-2 Editing the OpenVMS Site-specific Startup File...................................... 8-8 8-3 Tasks for Setting up Remote Mail.......... 8-18 B-1 New ALL-IN-1 Directories for Architecture Dependent Files........................... B-1 xi _________________________________________________________________ Preface About This Book This guide describes how to do the following: 1. Plan an ALL-IN-1 Version 3.1 installation on: - An OpenVMS AXP system (standalone or in a VMScluster) - An OpenVMS VAX system (standalone or in a VMScluster) 2. Prepare your system for an ALL-IN-1 Version 3.1 installation. 3. Install ALL-IN-1 Version 3.1. 4. Set up ALL-IN-1 Version 3.1 so that the ALL-IN-1 manager can log in and use it locally. ALL-IN-1 Installation: Language and Market Supplement The ALL-IN-1 Installation: Language and Market Supplement is provided with your language and market kit. It provides the disk space values for installing the ALL-IN-1 Version 3.1 kit, and information on the language and market components that you will need during the installation. Prerequisite Knowledge In order to use this guide, you need the following experience: o To install ALL-IN-1 Version 3.1 you must be familiar with the VMSINSTAL utility. xi o To run the Conflict Checking and Resolution Tool you must be familiar with ALL-IN-1 application programming, Customization Management, and ideally, the customizations at your site. Management Documentation Set In addition to the ALL-IN-1 Installation: Guide and the ALL-IN-1 Installation: Language and Market Supplement, the Management documentation set contains the following: o ALL-IN-1 Version 3.1 Release Notes o ALL-IN-1 Management Guide This guide describes the tasks for setting up and managing an ALL-IN-1 Version 3.1 system, so that it operates efficiently. o ALL-IN-1 Mail Management Guide This guide describes how to plan and manage an ALL-IN-1 Version 3.1 mail system. o Differences Between ALL-IN-1 Version 3.0 and ALL-IN-1 Version 3.1. This document introduces the new and changed functionality in ALL-IN-1 Version 3.1. In addition, there are answers to some common questions about the new version. o ALL-IN-1 WPS-PLUS Printer Characteristics This guide describes the use of printer tables, and teaches you how to use the printer table utility to customize existing printer tables to meet your needs. Related Documents You may also need to refer to the documentation on the following products: o VAX Message Router o DEC Notes[TM] o OpenVMS system management xii Conventions The following conventions are used throughout this guide: ___________________________________________________________ Convention__Description____________________________________ AIDA Means ALL-IN-1[TM] Distributed Access Server Server ALL-IN-1 Means the ALL-IN-1[TM] software that is installed on your system, for example, ALL-IN-1 Integrated Office System (IOS) Server or ALL-IN-1 Core Services for OpenVMS[TM] AXP[TM] and OpenVMS VAX[TM]. OpenVMS Means the OpenVMS AXP operating system AXP OpenVMS Means the OpenVMS VAX operating system VAX TLC Means TeamLinks[TM] Connection to ALL-IN-1 IOS for OpenVMS VMScluster Discussions that refer to VMScluster systems environments apply to both VAXcluster systems that include only VAX nodes and VMScluster systems that include at least one AXP node. Any differences are noted in the text. WPS-PLUS Means WPS-PLUS[TM] software [] In the installation description, this indicates a default value. Press Return to use the default value CTRL/Z Indicates that you hold down the CTRL key while ____________pressing_the_other_key_(Z).____________________ Returning Comments About this Documentation We would like to know what you think about the ALL-IN-1 documentation set. If you have any comments, or suggestions, please return them in any of the following ways: o Fill out and submit the Reader's Comments form at the back of the printed book o Send an electronic mail message to books@reo.mts.dec.com xiii o Send an electronic mail message to S=IDC BOOKS; O=digital; OU1=reo; P=digital; A=CWMail; C=gb o Send a fax to (+44) 1734 206018 xiv 1 _________________________________________________________________ Planning an ALL-IN-1 Version 3.1 Installation This chapter contains background information about installing ALL-IN-1 Version 3.1 and covers the following topics: o Installation paths o Installing on a VMScluster o Preinstallation planning decisions o Information required during the installation If ALL-IN-1 Version 3.0 is already installed on your system and you have customized it, you must also read Chapter 2 which explains how to prepare your customized system for an upgrade installation. Allow enough time for planning before you intend to install ALL-IN-1 Version 3.1 as the planning will take some time, especially if you are upgrading from a previous version of ALL-IN-1. In addition to this installation guide, you should also read the ALL-IN-1 Installation: Language and Market Supplement that is supplied with your kit. This provides the language and market-specific information that you need to know when installing ALL-IN-1 Version 3.1. Section 1.1 gives a list of all the questions that you will be asked during the installation. Planning an ALL-IN-1 Version 3.1 Installation 1-1 Planning an ALL-IN-1 Version 3.1 Installation 1.1 Checklist of Installation Decisions and Information 1.1 Checklist of Installation Decisions and Information Table 1-1 lists the questions that you will be asked during an ALL-IN-1 Version 3.1 installation and gives you references to additional information in this chapter where appropriate. The table follows the order of questions in the installation script. Table 1-1 Checklist of Installation Decisions and __________Information_Required_____________________________ Decision___________________Where_to_Find_Information_______ What type of installation Section 1.2 gives general do you want to perform? information about installing on OpenVMS VAX and OpenVMS AXP. Section 1.3 describes the installation options and explains how to plan an ALL-IN-1 installation on a VMScluster consisting of both VAX and AXP nodes. Section 1.8 and Chapter 2 explain how to plan an upgrade installation. ___________________________________________________________ Do you want to integrate Section 1.6.1 DATATRIEVE during the installation? ___________________________________________________________ Do you want to install Section 1.6.3 WPS-PLUS with ALL-IN-1? ___________________________________________________________ Do you want to integrate Section 1.6.1 ACMS (Application Control and Management System) during the installation? (continued on next page) 1-2 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.1 Checklist of Installation Decisions and Information Table 1-1 (Cont.) Checklist of Installation Decisions and __________________Information_Required_____________________ Decision___________________Where_to_Find_Information_______ ___________________________________________________________ Do you want to build a Section 1.3 multilanguage ALL-IN-1 system? ___________________________________________________________ Which ALL-IN-1 date A list of date formats format do you want to is displayed during the use? installation. See the ALL-IN-1 Installation: Language and Market Supplement for the default. ___________________________________________________________ What will be the greatest This is the number of users that number of simultaneous you expect to use ALL-IN-1 at ALL-IN-1 users? the same time. Identify which node on the cluster has the most users, and use that value during the installation. On which batch queue Section 1.5.1 should the Sender/Fetcher check job run? ___________________________________________________________ (continued on next page) Planning an ALL-IN-1 Version 3.1 Installation 1-3 Planning an ALL-IN-1 Version 3.1 Installation 1.1 Checklist of Installation Decisions and Information Table 1-1 (Cont.) Checklist of Installation Decisions and __________________Information_Required_____________________ Decision___________________Where_to_Find_Information_______ Do you want ALL-IN-1 Section 1.5 and Chapters 1 and 2 to be configured to use in the ALL-IN-1 Mail Management Message Router? Guide. If you do, you will be asked the following: o Do you want to use a remote Message Router? o What node is the Message Router on? o What level of Mail directory support do you want? ___________________________________________________________ Do you want to translate Section 1.5.5 outgoing WPS-PLUS messages to ASCII? ___________________________________________________________ Do you want to use TCP Section 1.6.4 /IP? If you answer yes, you will be prompted for the port numbers for the AIDA and File Cabinet servers if they do not already exist. ___________________________________________________________ (continued on next page) 1-4 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.1 Checklist of Installation Decisions and Information Table 1-1 (Cont.) Checklist of Installation Decisions and __________________Information_Required_____________________ Decision___________________Where_to_Find_Information_______ What is the language ALL-IN-1 Installation: Language code? and Market Supplement If your language includes a dialect code, you also need to supply the dialect code. ___________________________________________________________ For full installations, Section 1.2.6 you will be asked for the name of the device that will hold the ALL-IN-1: o Shared library files o Shared data files o Language files o Mail area SDAF (Shared Document Attributes File) file ___________________________________________________________ How many shared If you want to create more than directories do you want 2 or 3 shared directories, it is to create? recommended that you enter 1 at the installation prompt and then create the shared directories from the Management subsystem after installation is complete. See Chapter 7 in the ALL-IN-1 Management Guide. ___________________________________________________________ What is the market code ALL-IN-1 Installation: Language for the installation? and Market Supplement (continued on next page) Planning an ALL-IN-1 Version 3.1 Installation 1-5 Planning an ALL-IN-1 Version 3.1 Installation 1.1 Checklist of Installation Decisions and Information Table 1-1 (Cont.) Checklist of Installation Decisions and __________________Information_Required_____________________ Decision___________________Where_to_Find_Information_______ ___________________________________________________________ For full installations, See Section 1.2.5. you are asked to supply the following details for the ALL-IN-1 MANAGER account: o OpenVMS username o Password o UIC o Default device o Default directory You are also asked to supply a different UIC for each ALL-IN-1 utility account. ___________________________________________________________ For full installations, Section 1.2.6 and Section 3.8.7 you are asked to supply a top-level directory specification for the following: o Shared library files o Shared data files o Language files o Mail area SDAF file o Shared directories ___________________________________________________________ (continued on next page) 1-6 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.1 Checklist of Installation Decisions and Information Table 1-1 (Cont.) Checklist of Installation Decisions and __________________Information_Required_____________________ Decision___________________Where_to_Find_Information_______ Do you want to run See Section 1.7. the IVP after the installation? ___________________________________________________________ What to do after reading See Section 1.9 this chapter . ___________________________________________________________ 1.2 General Information About Installing ALL-IN-1 Version 3.1 This section gives some background information about installing ALL-IN-1 Version 3.1. Note that the ALL-IN-1 Version 3.1 base kit provides all the files required to install ALL-IN-1 Version 3.1 on a VAX system or an AXP system. In this book, the term architecture is used to differentiate between OpenVMS VAX systems and OpenVMS AXP systems. For example, architecture-independent files, means files that can be used on both VAX and AXP systems. If ALL-IN-1 is already installed on an OpenVMS VAX system in a VMScluster, then architecture support for ALL-IN-1 can be installed on an AXP system in the same cluster. The term mixed architecture cluster means a VMScluster that contains both AXP and VAX nodes. 1.2.1 Support for Different Architectures The ALL-IN-1 Version 3.1 kit contains all the software that is required to install ALL-IN-1 on an OpenVMS VAX system or an OpenVMS AXP system. You can install and run ALL-IN-1 Version 3.1 on a VMScluster consisting of both VAX and AXP nodes. The majority of the ALL-IN-1 Version 3.1 files are architecture-independent and common to both VAX and Alpha AXP architectures. Separate ALL-IN-1 system files are provided for each architecture. Planning an ALL-IN-1 Version 3.1 Installation 1-7 Planning an ALL-IN-1 Version 3.1 Installation 1.2 General Information About Installing ALL-IN-1 Version 3.1 For more information about installing on a VMScluster, see Section 1.4. 1.2.2 Version 3.1 Architecture-Dependent Files and Directories The majority of ALL-IN-1 Version 3.1 files are architecture-independent and shared by both AXP and VAX systems. The shared ALL-IN-1 Version 3.1 files are installed during an installation on either a VAX system or an AXP system. There are some architecture specific files which are only installed when the installation procedure is run on that architecture, for example, executable and shareable images. When the ALL-IN-1 startup command procedure is run on each node to start up ALL-IN-1, it uses the information in the data file, OA$DATA_SHARE:A1CONFIG.DAT to define the logicals for the VAX-specific and AXP-specific directories. For example, on a VAX system OA$EXE_SHARE is defined to point to the directory, OA$EXE_VAX_SHARE. On an AXP system, OA$EXE_SHARE is defined to point to the directory OA$EXE_ AXP_SHARE. 1.2.3 Components of ALL-IN-1 Version 3.1 The ALL-IN-1 Version 3.1 kit has the following components: o International base component which is common to all installations and which is country and language independent. o Language component. The language supplied with your ALL-IN-1 Version 3.1 kit is the default (or primary) language that is provided in the language field of a user's account details. Some languages may also have a dialect component. A dialect component may be required when a language is spoken in more than one country. There may be some differences in the language, depending on which country it is being used in. o Market component. The market component provides market-specific features such as currency, date formats, address formats and keyboard support. 1-8 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.2 General Information About Installing ALL-IN-1 Version 3.1 The installation procedure in Chapter 5 describes how to install all of these components. During the installation, you will be asked to supply information about the language and market components that you are installing with your base system. See the ALL-IN-1 Installation: Language and Market Supplement. 1.2.4 Additional Languages In addition to the primary language supplied with your kit, you can install and use other languages with ALL-IN-1 Version 3.1. You must, however, install each language separately using the additional language installation procedure. See Chapter 6. ________________________ Note ________________________ You must upgrade all additional languages to Version 3.1 before you can use them with ALL-IN-1 Version 3.1. Earlier versions of additional languages are not supported. ______________________________________________________ During the ALL-IN-1 Version 3.1 installation you will be asked if you want to build a multilanguage system. Answer yes to this prompt if you want to install additional languages. You can build a multilanguage system at any time after the installation by relinking ALL-IN-1 Version 3.1 and answering yes when you are prompted with the question again. See the ALL-IN-1 Management Guide for details on linking the ALL-IN-1 image. 1.2.5 Accounts Needed for ALL-IN-1 ALL-IN-1 needs an OpenVMS account for running the ALL-IN-1 management batch jobs. This OpenVMS account has four ALL-IN-1 accounts: o MANAGER account for running ALL-IN-1 management tasks. o POSTMASTER account for running the mail Sender and Fetcher. o IVP account for running the installation verification procedure. Planning an ALL-IN-1 Version 3.1 Installation 1-9 Planning an ALL-IN-1 Version 3.1 Installation 1.2 General Information About Installing ALL-IN-1 Version 3.1 o A1$SCRIPT account for running the script symbiont. See Chapter 19 in the ALL-IN-1 Management Guide for more information about ALL-IN-1 accounts. 1.2.6 Use of ALL-IN-1 Areas You can install ALL-IN-1 Version 3.1 in the following ways: o On a single target disk o Across several target disks by installing ALL-IN-1 areas on separate disks. The areas are: o Shared library files, for example, OA$LIB_SHARE and OA$BLP_SHARE. This area contains language-independent files, scripts, templates and form libraries. o Shared data files, for example, OA$DATA_SHARE. This area contains shared data files, for example printer management files. o Language files, for example, OA$LIB_language. This area contains form libraries and similar language-specific files. For more information about the ALL-IN-1 files and directories, see Chapter 19 in the ALL-IN-1 Management Guide. 1.3 Installation Paths The following types of installation are provided for ALL-IN-1 Version 3.1: o A full installation which installs a new ALL-IN-1 system. o An upgrade installation which upgrades an existing ALL-IN-1 Version 3.0 system. o The addition of architecture support. This adds support for an additional architecture where a full ALL-IN-1 Version 3.1 system is already installed on a different architecture in the same VMScluster. For example, you can use this option when you are installing ALL-IN-1 Version 3.1 in a VMScluster consisting of both AXP and 1-10 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.3 Installation Paths VAX systems. You can do an upgrade installation on the VAX system and then add AXP support on the AXP system. o An additional language installation. If you want to run your ALL-IN-1 system as a multilanguage system, you can install other languages in addition to your primary language. See Chapter 6. o The addition of architecture support for an additional language. This adds support for an additional architecture where the additional language is already installed on a different architecture in the same VMScluster. o A minimal shutdown upgrade. This option is provided for sites where system downtime is critical. The implications of using this option are discussed in Chapter 4. o An update installation. This option updates the files for an existing ALL-IN-1 Version 3.1 system. Table 1-2 gives a complete list of supported installation paths for ALL-IN-1 Version 3.1. Planning an ALL-IN-1 Version 3.1 Installation 1-11 Planning an ALL-IN-1 Version 3.1 Installation 1.3 Installation Paths Table_1-2_Installation_Paths_______________________________ Type_of_Installation__Use_When_____________________________ Full You do not have a version of ALL-IN-1 installed. You can install a new ALL-IN-1 Version 3.1 system on a VAX system or an AXP system. Upgrade One of the following versions of ALL-IN-1 is already installed on a VAX system: o ALL-IN-1 Version 3.0[1] o ALL-IN-1 STARTER Version 3.0 Minimal shutdown ALL-IN-1 Version 3.0 is already upgrade installed and system downtime is critical for your organization. See Chapter 4. Update ALL-IN-1 Version 3.1 is already installed Add VAX architecture ALL-IN-1 Version 3.1 is already support installed on an AXP system in a VMScluster. Add AXP architecture ALL-IN-1 Version 3.1 is already support installed on a VAX system in a VMScluster. Additional language You want to add a new additional language to an existing ALL-IN-1 Version 3.1 multilanguage system. Upgrade additional Version 3.0 of an additional language language is already installed and you have upgraded your primary language to Version 3.1 Update additional Version 3.1 of an additional language language is already installed. [1]Optionally_with_ALL-IN-1_Version_3.0A_installed_and_____ TeamLinks Connection Version 2.0 or Version 2.1. (continued on next page) 1-12 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.3 Installation Paths Table_1-2_(Cont.)_Installation_Paths_______________________ Type_of_Installation__Use_When_____________________________ Add VAX architecture ALL-IN-1 Version 3.1 and Version support for an 3.1 of the additional language are additional language already installed on an AXP system in the same VMScluster. Add AXP architecture ALL-IN-1 Version 3.1 and Version support for an 3.1 of the additional language are additional language already installed on a VAX system in ______________________the_same_VMScluster._________________ Planning an ALL-IN-1 Version 3.1 Installation 1-13 Planning an ALL-IN-1 Version 3.1 Installation 1.4 Installing on More Than One Architecture in a VMScluster 1.4 Installing on More Than One Architecture in a VMScluster If you want to install ALL-IN-1 Version 3.1 on a VMScluster with both VAX and AXP nodes, you must consider the following: o Each architecture requires its own system disk. This means that you must not use SYS$SYSDEVICE in ALL-IN-1 directory locations as SYS$SYSDEVICE cannot be the same for both the the VAX system and the AXP system. o VAX images can only be linked on a VAX system and AXP images can only be linked on an AXP system. o All existing ALL-IN-1 systems on VAX must be upgraded to Version 3.1 before you can add AXP support. o The VAX and the AXP must have a common user environment. This means that the VAX and AXP both reference the same data files for the AUTHORIZE utility. o You can spread the ALL-IN-1 areas around your cluster disks, just as you would for a single-node system. See Section 3.8.7. o You must run the ALL-IN-1 startup command procedure on all nodes in the part of the cluster with the common ALL-IN-1 user environment. You do not need to perform a full ALL-IN-1 Version 3.1 installation on both AXP and VAX machines in the same VMScluster. Once you have installed a full ALL-IN-1 Version 3.1 system on either VAX or AXP, you can then add architecture support for ALL-IN-1 on the second architecture. Table 1-3 shows the strategy to follow when you want to install ALL-IN-1 on both VAX and AXP nodes in a VMScluster. 1-14 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.4 Installing on More Than One Architecture in a VMScluster Table_1-3_Strategy_for_Adding_Architecture_Support_________ If_________________________Then____________________________ ALL-IN-1 Version 3.0 or Do the following: ALL-IN-1 STARTER Version 1. Do an upgrade installation to 3.0 is already installed ALL-IN-1 Version 3.1 on the on a VAX system VAX 2. Add AXP architecture support on the AXP ALL-IN-1 is not installed Do the following: on your VMScluster 1. Do a full ALL-IN-1 Version 3.1 installation on the AXP system 2. Add VAX architecture support on the VAX This order of installation gives ___________________________you_the_best_performance._______ For general information about running ALL-IN-1 on a VMScluster, see Chapter 5 in the ALL-IN-1 Management Guide. Planning an ALL-IN-1 Version 3.1 Installation 1-15 Planning an ALL-IN-1 Version 3.1 Installation 1.4 Installing on More Than One Architecture in a VMScluster 1.4.1 Installing AXP Architecture Support If you already have a version of ALL-IN-1 installed on a VAX system, you must upgrade it to ALL-IN-1 Version 3.1 before you can add AXP architecture support on the AXP system. Figure 1-1 shows which files are installed during each part of the installation. When you upgrade ALL-IN-1 Version 3.0 to ALL-IN-1 Version 3.1, directories are created for the following files: o VAX-specific files o AXP-specific files. The locations of these directories are derived from the ALL-IN-1 configuration file, OA$DATA_SHARE:A1CONFIG.DAT. The shared files and VAX-specific files are installed into these directories during the upgrade but the AXP-specific files are not installed until you add AXP architecture support. When you install additional architecture support for AXP, the following files are installed: o AXP system files for ALL-IN-1 on the AXP system disk o AXP-specific files into the directories already created during the ALL-IN-1 Version 3.1 installation on the VAX system. When adding AXP support, the installation procedure prompts you for the location of the ALL-IN-1 configuration file, OA$DATA_SHARE:A1CONFIG.DAT, on the VAX that is already running ALL-IN-1 Version 3.1. The ALL-IN-1 startup file, A1V31START.COM reads the information in this file and defines the logicals to point to to the AXP-specific directories that were created during the ALL-IN-1 Version 3.1 installation on the VAX system. The AXP-specific files are then installed in the directories that have already been created during the upgrade installation on VAX. 1-16 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.4 Installing on More Than One Architecture in a VMScluster Figure 1-1 Installing AXP Architecture Support 1.4.2 Installing VAX Architecture Support If you do not have a version of ALL-IN-1 installed, you can install ALL-IN-1 Version 3.1 on an AXP system and then add VAX architecture support on the VAX. When you install a new ALL-IN-1 system on AXP, all the shared, architecture- independent, and AXP-specific files are installed on your data disk. AXP-specific system files are installed on your AXP system disk. The directories for VAX-specific files are created during the installation but they are left empty. When you add VAX architecture support, the VAX-specific system files are installed on the VAX system disk, and the VAX-specific files are installed in the VAX directories that have already been set up during the full installation on the AXP. See Figure 1-2. The installation procedure prompts you for the location of the ALL-IN-1 configuration file, OA$DATA_ SHARE:A1CONFIG.DAT, for the existing ALL-IN-1 Version 3.1 AXP system. The ALL-IN-1 startup file, A1V31START.COM reads the information in the configuration file and creates the pointers to the VAX-specific directories that were created during the ALL-IN-1 Version 3.1 installation on the AXP system. The VAX-specific files are installed in the directories that have already been created during the installation on AXP. Planning an ALL-IN-1 Version 3.1 Installation 1-17 Planning an ALL-IN-1 Version 3.1 Installation 1.4 Installing on More Than One Architecture in a VMScluster Figure 1-2 Installing VAX Architecture Support 1.4.3 Replacing a VAX System with an AXP System Read this section if you: o Have hardware that can be upgraded from VAX to Alpha AXP o Have an existing standalone VAX system that you are replacing with an AXP system Your strategy for installing ALL-IN-1 Version 3.1 will depend on whether ALL-IN-1 is already installed. ________________________ Note ________________________ If you have an existing ALL-IN-1 Version 3.0 system, you must upgrade it to ALL-IN-1 Version 3.1 before you change your hardware to Alpha AXP or replace your VAX. This ensures that you retain your ALL-IN-1 configuration and that the ability to support two architectures is installed. If you do not upgrade to ALL-IN-1 before changing your hardware to AXP or replace your VAX, ALL-IN-1 will not be available until you do a full installation on AXP. You will lose any customizations that you have made and you will have to set up ALL-IN-1 as a completely new system. ______________________________________________________ When you have upgraded your hardware to Alpha AXP, you can add AXP support for ALL-IN-1 to your existing ALL-IN-1 Version 3.1 system. If you have not installed a previous version of ALL-IN-1 on your Alpha-ready system, do a full ALL-IN-1 Version 3.1 installation when you have upgraded your hardware to Alpha AXP. 1-18 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.5 Mail System Planning 1.5 Mail System Planning This section describes the planning decisions that you need to make about your mail system before installing ALL-IN-1 Version 3.1. ________________________ Note ________________________ For the full implications of planning a mail system, you must read Chapters 1 and 2 in the ALL-IN-1 Mail Management Guide before starting the installation. ALL-IN-1 running on an AXP system must use a remote Message Router running on a VAX. This VAX can be in the same VMScluster or remote from the cluster. The ALL-IN-1 Mail Management Guide gives details of planning the use of a remote Message Router. Section 8.13 describes the postinstallation tasks that you must do in order to set up remote mail. ______________________________________________________ Table 1-4 lists the decisions that you need to make when planning your mail system. Table_1-4_Mail_System_Planning_Decisions___________________ Decision___________________Where_to_Find_Information_______ Which batch queue you See Section 1.5.1. want to use for running the job to check the mail Sender and Fetcher processes. Do you want ALL-IN-1 See Section 1.5.2. to be configured to use Message Router? Do you want to use a See Section 1.5.2 and remote Message Router? Section 1.5.4. What level of Mail See Section 1.5.3. directory support do you_want?__________________________________________________ Planning an ALL-IN-1 Version 3.1 Installation 1-19 Planning an ALL-IN-1 Version 3.1 Installation 1.5 Mail System Planning 1.5.1 Batch Queue for Mail ALL-IN-1 uses a system batch queue to run the job that checks the mail Sender and Fetcher processes. The default option at installation is to use SYS$BATCH, but you can specify the name of another batch queue that already exists. If you are installing ALL-IN-1 on a multiple-environment cluster, you must use a batch queue that runs only on the part of the cluster on which you are installing ALL-IN-1. 1.5.2 Using Message Router ALL-IN-1 uses Message Router to send messages to, and receive messages from, other nodes and mail systems. The ALL-IN-1 Version 3.1 kit supplies: o Message Router Version 3.3A o Message Router VMSmail Gateway (MRGATE) Version 3.3. ALL-IN-1 uses the Message Router VMSmail Gateway to exchange messages with VMSmail users on other nodes. The gateway must be installed and configured before you install ALL-IN-1 Version 3.1. Message Router is known as a local Message Router when it is installed on the same node as ALL-IN-1 and a remote Message Router when it is installed on a different node. When Message Router is installed on a node that is not in the same VMScluster, it is known as the server node. Both VAX and AXP nodes in a VMScluster can use a remote Message Router. ________________________ Note ________________________ When you install ALL-IN-1 on an AXP system, you must use a remote Message Router. ______________________________________________________ If you are using a local Message Router, you must upgrade it to Version 3.3A before you install ALL-IN-1 Version 3.1. 1-20 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.5 Mail System Planning If you want to use a remote Message Router, you must do the following before installing ALL-IN-1 Version 3.1: 1. If a previous version of Message Router is installed on your system, you must upgrade it to Version 3.3A. Message Router Version 3.3A allows you to use the remote Message Router Directory Service and Transfer Service from ALL-IN-1 on a VAX system or an AXP system. 2. In order to use the remote Directory Service, Message Router must be correctly configured. To use a remote Message Router Directory Service, you must do a customized configuration of the Message Router Directory Service. See Section 1.5.4. 3. Decide if you want to use Message Router exception reporting. See Chapter 2 in the ALL-IN-1 Mail Management Guide for information about planning exception reporting. 4. If your ALL-IN-1 node or cluster will be using a remote Message Router server node, you must create a mailbox entry for ALL-IN-1 on the Message Router server node before you start the installation. See Section 3.10.1. If you do not do this, you will have problems when the Sender and Fetcher processes are started up by the installation procedure. 1.5.3 Level of Mail Directory Support Table 1-5 shows the installation options that are available for setting the level of Mail directory support. Directories allow users to look up names and electronic mail addresses of users in the network. There are two directories for addressing available with ALL-IN-1: o The ALL-IN-1 directory. This is provided with ALL-IN-1 and is always available. o The Mail directory This is provided by the Directory Service component of Message Router and it is optional. It contains the names, mail addresses and other details of all Mail directory subscribers on the network. Planning an ALL-IN-1 Version 3.1 Installation 1-21 Planning an ALL-IN-1 Version 3.1 Installation 1.5 Mail System Planning ________________________ Note ________________________ Digital recommends that you use the ALL-IN-1 directory as the primary directory and the Mail directory as the secondary directory to reduce the response time. For more information about the two types of directory, and for help with deciding which to use, see Chapter 2 in the ALL-IN-1 Mail Management Guide. In ALL-IN-1 Version 3.1, Message Router does not have to be installed on the same node as ALL-IN-1 in order to use the Mail directory. Remote Directory Service enquiries can be made from ALL-IN-1 Version 3.1 running on either a VAX system or an AXP system, provided that: o Message Router V3.3A is installed on a remote VAX node o The Directory Service component has a customized configuration to start up the query servers o The Directory Service node is a world search node You can update Directory Service entries remotely but this is not an automatic process. For the implications of updating remote Directory Service entries, see Chapter 4 in the ALL-IN-1 Mail Management Guide. ______________________________________________________ Table 1-5 Installation Options for Levels of Mail Directory __________Support__________________________________________ Level of Mail Directory Support__________Meaning___________________________________ 0 The ALL-IN-1 directory is the primary directory for users to look up mail addresses. The Mail directory is not available (continued on next page) 1-22 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.5 Mail System Planning Table 1-5 (Cont.) Installation Options for Levels of Mail __________________Directory_Support________________________ Level of Mail Directory Support__________Meaning___________________________________ 1 The ALL-IN-1 directory is the primary directory for users to look up names and mail addresses. The Mail directory is available as the secondary directory. 2 The Mail directory is the primary directory for users to look up names and addresses. The ALL-IN-1 directory is available as the _________________secondary_directory.______________________ The value 0, 1 or 2 is the value given to the logical OA$DDS_PRIME. You can change the value of this logical after installation. If you do not want to make the decision about the Mail directory when you install, you can set the value to 1 so that you can either ignore the Directory Service or set it up later. See the ALL-IN-1 Mail Management Guide. 1.5.4 Setting up a Remote Directory Service In order to use a remote Message Router Directory Service, you must do a customized configuration of the Directory Service to set up the query servers. When you do a customized configuration of the Directory Service, query servers are set up to service remote enquiries to the Directory Service node which must be a world search node. See the Message Router Configuration Guide for details of configuring Message Router using the MAILbus configuration procedure, MB$CONFIG. If you do a default configuration of the Directory Service component of Message Router instead of a customized configuration, the query servers are not set up and you cannot make remote enquiries. Planning an ALL-IN-1 Version 3.1 Installation 1-23 Planning an ALL-IN-1 Version 3.1 Installation 1.5 Mail System Planning Table 1-6 list some of the questions that you will be asked during the customized configuration: Table_1-6_Questions_Asked_During_a_Customized_Configuration Question________________________What_You_Must_Do___________ Do you want to enable Answer Y to enable the Directory Service exception exception reporting. reporting? The exception reporting routines monitor the Directory Service for errors and unusual occurrences. See Chapter 2 in the ALL-IN-1 Mail Management Guide for information about planning exception reporting. Do you want to allow remote Answer Y to allow remote Directory Service access? access to the Directory Service. You are prompted for the number of query servers that you want to ________________________________create.____________________ The Message Router Configuration Guide gives more detailed information about doing a customized configuration. Chapter 2 in the ALL-IN-1 Mail Management Guide gives further information about using a Remote Message Router. 1.5.5 Translating Outgoing Mail Messages to ASCII If all nodes in a network are running ALL-IN-1, then mail can be sent between the nodes in the same format in which it was created, for example, WPS-PLUS or ASCII text. Other user agents in different parts of a network may not be able to translate WPS-PLUS messages, so mail must be sent between the nodes in ASCII format. During the installation you are asked if you want to to translate outgoing messages to ASCII. The following options are available: o Messages are not translated to ASCII (MTI_TRNS is set to 0). 1-24 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.5 Mail System Planning o Only the message part is translated, leaving all document attachments in their original format (MTI_ TRNS is set to 1). o All of the message is translated to ASCII, including the message part and all document attachments (MTI_TRNS is set to 2). 1.6 Other Software Referenced by the Installation Procedure This section covers software that is referred to by the installation procedure. It includes: o Software that can be integrated (linked to the ALL-IN-1 image) during the installation. See Section 1.6.1. o CDA (Compound Document Architecture). See Section 1.6.2. o WPS-PLUS. See Section 1.6.3. o DEC TCP/IP Services. See Section 1.6.4. 1.6.1 Software Which can be Integrated During the Installation You are asked if you want to integrate the following products during the installation: o DATATRIEVE (VAX DATATRIEVE (on VAX systems) or DEC DATATRIEVE (on AXP systems)) If DATATRIEVE is only occasionally used within ALL-IN-1, it is recommended that you do not integrate it during the installation. You will still be able to use DATATRIEVE within ALL-IN-1, but you will avoid any performance impact of having it physically linked with the ALL-IN-1 image. However, if you use a DATATRIEVE image other than SYS$SHARE:DTRSHR.EXE, then you must integrate it during the installation and supply the name of the DATATRIEVE image. o Application Control Management System (ACMS). If you want to integrate these products during the installation, they should be installed and running before you start the ALL-IN-1 Version 3.1 installation. See Chapter 3. You can also integrate them after the installation, see Chapter 5 in the ALL-IN-1 Management Guide. Planning an ALL-IN-1 Version 3.1 Installation 1-25 Planning an ALL-IN-1 Version 3.1 Installation 1.6 Other Software Referenced by the Installation Procedure DEC Notes can also be integrated during the installation. You are not asked any questions about DEC Notes during the installation. If the required version of DEC Notes is already installed and running when you do the installation, DEC Notes is automatically integrated with ALL-IN-1. 1.6.2 Compound Document Architecture (CDA) Support CDA converters are provided with ALL-IN-1 and installed automatically during the ALL-IN-1 Version 3.1 installation. The CDA converters provided with ALL-IN-1 Version 3.1 are described in the CDA Converter Library documentation. The following converters are installed with ALL-IN-1 Version 3.1: o DX (WPS-PLUS Version 3.0) o MACWRITE[R] (MacWrite) o RTF (Microsoft[R] Word[TM] for Microsoft Windows[R]) o WORD5 (Microsoft Word for MS-DOS) o WPL (WPS-PLUS) o DIF[TM] (Data Interchange Format) o WK1 (Lotus 1-2-3[R] Version 2.0 and 2.01) o WK3 (Lotus 1-2-3 Version 3.0) o PICT (Image and graphical format used on the Macintosh[R]) o WORDP (WordPerfect[TM]) You can also install and use the additional CDA converters that are provided with the Version 2.2 CDA Converter Library for OpenVMS (VAX only). Other versions of the CDA Converter Library are not supported. In order to install the CDA converters, you must have Version 1.4-911015 or higher of the file SYS$SHARE:CDA$ACCESS.EXE installed. To check which version is currently installed, enter the following: $ ANALYZE/IMAGE/INTER SYS$SHARE:CDA$ACCESS.EXE 1-26 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.6 Other Software Referenced by the Installation Procedure Press RETURN until the image file identification is displayed. If you do not have V1.4-911015 or higher, you must install the CDA Interoperability kit that is supplied with your language kit. The saveset name is CDAPAT011.A. This kit can be installed with either DECwindows Version 2.0 or DECwindows Motif Version 1.0. To install full CDA support, this software must be running before you install ALL-IN-1 Version 3.1. If you do not have the correct sofware installed, the installation procedure ask you if you want to continue the installation without full CDA support. If you choose to continue without full CDA support, only the WPL (WPS-PLUS) to DDIF (Digital Document Interchange Format) converters are automatically provided. The CDA DOC_STYLE files are provided to CDA$LIBRARY, if that directory exists, or to OA$LIB_SHARE as a temporary location if CDA$LIBRARY does not exist. A script to update the format master record with the CDA format and the name of the converters is run as an automatic postinstallation task, if full CDA prerequisites are present. For more information about the use of converters, see Chapter 14 in the ALL-IN-1 Management Guide. To install CDA support after the installation, see Chapter 5 in the same book. 1.6.3 Installing WPS-PLUS as the Default Editor The WPS-PLUS Version 4.2 software is provided with ALL-IN-1 Version 3.1. If you want to use WPS-PLUS as the default editor, you can install the WPS-PLUS Version 4.2 software during the ALL-IN-1 Version 3.1 installation. Note that you cannot install WPS-PLUS unless you have a license that includes WPS-PLUS. If you want to install WPS-PLUS some time after the ALL-IN-1 Version 3.1 installation, you can do an ALL-IN-1 Version 3.1 update installation. The WPS-PLUS kit contains a library of encapsulated PostScript[TM] graphics and page overlay samples. If you specify that you want to install WPS-PLUS during the ALL-IN-1 Version 3.1 installation, you are asked if you wish to copy these files directly to the ALL-IN-1 library. Planning an ALL-IN-1 Version 3.1 Installation 1-27 Planning an ALL-IN-1 Version 3.1 Installation 1.6 Other Software Referenced by the Installation Procedure Some language kits provide international lexicons which are used by WPS-PLUS. The international lexicons are automatically installed during the ALL-IN-1 Version 3.1 installation. If lexicons are provided, you will be prompted for a device on which they can be installed. See the ALL-IN-1 Installation: Language and Market Supplement. If you are installing ALL-IN-1 for the first time and you have been using WPS-PLUS for VMS Version 4.0 or 4.1, you can copy users' files to ALL-IN-1 Version 3.1. Users can then access their WPS-PLUS for VMS files from ALL-IN-1. See Section 8.16. 1.6.4 Using TCP/IP to Communicate With Client Applications If you want client applications such as TeamLinks to connect to ALL-IN-1 using the TCP/IP network protocol, then you must have one of the following sofware packages installed: o DEC TCP/IP Services for OpenVMS (UCX) Version 2.0 or later o Other TCP/IP software that runs in UCX emulation If this software is installed and the logical name UCX$DEVICE is defined on your system when you install ALL-IN-1 Version 3.1, the installation procedure asks you if you want to use TCP/IP. If TCP/IP port numbers have not already been set up for the default AIDA (ALL-IN-1 Distributed Access) Server and File Cabinet Server, then you must supply them. Each server must have a different port number which can be in the range 1024 to 65535. Table 1-7 shows the default values for the servers. Table_1-7_TCP/IP_Service_Information_______________________ Default Port Server___________Number______Associated_Service_Name_______ AIDA Server 7300 OA$AIDA (continued on next page) 1-28 Planning an ALL-IN-1 Version 3.1 Installation Planning an ALL-IN-1 Version 3.1 Installation 1.6 Other Software Referenced by the Installation Procedure Table_1-7_(Cont.)_TCP/IP_Service_Information_______________ Default Port Server___________Number______Associated_Service_Name_______ File Cabinet 7373 OA$FCS[1] Server [1]The_service_name_for_the_File_Cabinet_Server_is_not_used in the ALL-IN-1 Management interface. ___________________________________________________________ 1.7 Running the IVP (Installation Verification Procedure) The Installation Verification Procedure (IVP) for ALL-IN-1 Version 3.1 verifies the installation. During the installation, you are asked if you want to run the IVP as part of the installation. If you respond yes, VMSINSTAL runs the IVP. ________________________ Note ________________________ Digital recommends that you run the IVP to ensure that ALL-IN-1 Version 3.1 is installed correctly. ______________________________________________________ After the IVP has run, your system may still require some postinstallation work before it is ready for use. See Chapter 8 for information about postinstallation tasks. After ALL-IN-1 Version 3.1 is installed, you can run the IVP independently to verify that the software is available on your system. You can also run the IVP after a system failure to ensure that users can access ALL-IN-1 Version 3.1. Instructions on running the IVP after installation are given in the ALL-IN-1 Management Guide. 1.8 Planning an Upgrade Installation If you are upgrading from ALL-IN-1 Version 3.0 you must ensure that any customizations that you have made to your system will continue to work with ALL-IN-1 Version 3.1. Planning an ALL-IN-1 Version 3.1 Installation 1-29 Planning an ALL-IN-1 Version 3.1 Installation 1.8 Planning an Upgrade Installation Digital recommends the use of a separate test system to verify your ALL-IN-1 customizations. This enables you to: o Learn about new features and plan user training o Evaluate new functionality o Migrate your customizations Follow the instructions in Chapter 2 if you are planning to upgrade a customized ALL-IN-1 Version 3.0 system. Chapter 2 explains how to use the Conflict Checking and Resolution Tool (CART) to assess the impact of an upgrade on your customizations and how to migrate your customizations to ALL-IN-1 Version 3.1. 1.9 What to do Next Table 1-8 shows you what to do next. Table_1-8_What_To_Do_Next__________________________________ Type_of_Installation__What_to_do_Next______________________ Full installations Go to Chapter 3 to prepare your and upgrades of non- system for the installation. customized ALL-IN-1 Version 3.0 systems Upgrade Go to Chapter 2 to find out how to installations of prepare your system for an upgrade customized ALL-IN-1 installation. Version 3.0 systems Additional language Go to Chapter 3. installations For minimal shutdown Go to Chapter 4. upgrades___________________________________________________ 1-30 Planning an ALL-IN-1 Version 3.1 Installation 2 _________________________________________________________________ Preparing to Upgrade a Customized System Read this chapter if you are upgrading a customized ALL-IN-1 Version 3.0 system to ALL-IN-1 Version 3.1. This chapter describes how to run the ALL-IN-1 Conflict Checking and Resolution Tool (CART) and how to interpret the reports that it produces. The CART reports help you to do the following: o Assess the implications that an upgrade will have on your system customizations. o Create an upgrade plan for migrating your customizations to ALL-IN-1 Version 3.1 so that you can continue to use them. o Prepare your system customizations ready for the upgrade. The CART is a migration tool that provides information to help you understand how the changes made in ALL-IN-1 Version 3.1 will affect the customizations at your site. When you run the CART, it compares the customized elements on your system with the list of base elements provided in ALL-IN-1 Version 3.1. If the customized element has the same name as a base element the CART reports that there is a conflict. The level of severity of the conflict is determined by the CART status code that is assigned to the base element. ________________________ Note ________________________ Digital recommends that you run the CART and take the appropriate actions on all systems that you will be upgrading to ALL-IN-1 Version 3.1. This will ensure that your Customization Management data files Preparing to Upgrade a Customized System 2-1 Preparing to Upgrade a Customized System accurately reflect the customizations at your site for ALL-IN-1 Version 3.1. If you are running a multilingual system, you must also run the CART for each additional language that is installed on your system. ______________________________________________________ It is recommended that you run the CART well in advance of the upgrade. This will allow you time to rerun the CART if necessary and to spend time reviewing the CART reports and deciding how to migrate your customizations. 2.1 Overview of the CART Table 2-1 gives the definitions of some terms that are used throughout this chapter. See Application Programming: Customization Management for information about Customization Management. Table_2-1_Terminology_used_by_the_CART_____________________ Term_____________Explanation_______________________________ Base element A base element is an element that is part of the ALL-IN-1 application. Customization Management defines the ALL-IN-1 application as the OA application area. (continued on next page) 2-2 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.1 Overview of the CART Table_2-1_(Cont.)_Terminology_used_by_the_CART_____________ Term_____________Explanation_______________________________ CART runid An identification string allocated to a specific CART data file. For example, V31$PRIMARY is the runid for the primary language data file for ALL-IN-1 Version 3.1 and V31$FRENCH is the runid for the French language data file for ALL-IN-1 Version 3.1. If you install other applications, they may also provide CART data files. After installation, you can run the CART from Customization Management. You select the runid for the CART data file that you want to use. See Chapter 21 in the ALL-IN-1 Management Guide for details of running the CART after installing ALL-IN-1 Version _________________3.1.______________________________________ The CART data file provides information about changes to Version 3.1 base elements. Base elements in ALL-IN-1 Version 3.1 may contain mandatory changes. They can be new, minimally changed, substantially changed, deleted, or moved. If you have customized a base element that has been modified in ALL-IN-1 Version 3.1, the CART reports that there is a conflict and assigns a status code to the customized element. The severity of the conflict determines what action you must take with your customizations. For example, if a major (mandatory) change has been made to a base element in ALL-IN-1 Version 3.1, and you have customized that base element, the CART report will give the customized element a mandatory status code. This means that there is a direct conflict between your customized element and the Version 3.1 base element and you must take some action with your customized element before upgrading. Other conflicts reported by the CART are due to customized elements that have the same name as new Version 3.1 base elements. The customized elements may be in the same area as the new element or in a different area. In each case the CART will report a conflict. Preparing to Upgrade a Customized System 2-3 Preparing to Upgrade a Customized System 2.1 Overview of the CART When you use Customization Management to customize a base element, the name of the customized element remains the same. ALL-IN-1 distinguishes between different versions of an element by their locations. Each time you use Customization Management to customize an element, a record is written to the site modification log, OA$DATA:CM$SITELOG.DAT. When you run the CART, it compares the customized elements listed in your site modification log with the list of base elements provided in the ALL-IN-1 Version 3.1 data file and creates a report detailing the differences. The data file is identified by the CART runid as described in Table 2-1. Figure 2-1 shows what the CART does. Figure 2-1 What the CART Does The CART does the following: 1 Gets the list of customized elements from the site modification log. 2 Checks in the live and site areas for the elements listed in the site modification log. If a customized element listed in the site modification log cannot be found, it is listed in the site elements report. If the CART finds elements in the site area which are not listed in the site modification log it adds an entry for these elements in the full CART report. 3 Checks the list of customized elements in the site and live areas against the list of base elements in the CART data file. 2-4 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.1 Overview of the CART If the customized element has the same name as an ALL-IN-1 Version 3.1 base element, the CART assigns the status code associated with the base element, to the customized element. 4 Produces the CART full report and summary reports which lists the status codes assigned to the customized elements. In addition to producing reports, the CART also provides an ALL-IN-1 script which is called the CART resolution procedure. This script can be edited and used after the upgrade, to resolve some of your conflicts automatically. See Section 2.6.6. 2.2 Modified ALL-IN-1 Systems You may have installed and integrated other software products that can be used with ALL-IN-1, for example, TeamRoute. Most applications that are installed and integrated with ALL-IN-1 add new elements in their own application area. The CART data file for ALL-IN-1 Version 3.1 does not contain a record of any new elements that have been added by installing additional software so you do not need to do any additional preparation tasks. If applications do add elements to the OA application area, an entry is made in the site modification log file. As the CART checks all elements in the site modification log file, it will report on these elements even if they are not customized. If any applications have added elements to the OA application base area and you have customized these elements, then the CART will report a conflict if the customized element has the same name as a new ALL-IN-1 Version 3.1 element. If you have previously installed ALL-IN-1 Version 3.0A, the CART full report will indicate which elements were changed in Version 3.0A. Preparing to Upgrade a Customized System 2-5 Preparing to Upgrade a Customized System 2.3 Understanding the CART Reports 2.3 Understanding the CART Reports To interpret the CART reports, you must be familiar with application programming and ALL-IN-1 Customization Management. Ideally, you should also be familiar with the customizations at your site. This section explains the types of CART report that are generated and the format of the reports. The CART status codes are described in more detail in Section 2.7, Section 2.8 and Section 2.9. The following topics are discussed in this section: o Types of CART report. See Section 2.3.1. o Format of the CART reports. See Section 2.3.2. o CART status codes and level of conflict. See Section 2.3.3. Note that the CART produces a separate set of reports for each additional language. 2.3.1 Types of CART Report When you run the CART, it produces four types of report and an ALL-IN-1 script (the CART resolution procedure) in your top-level site directory, for example, [ALLIN1.SITE]. Table 2-2 gives a description of each type of CART report. The CART resolution procedure is described in Section 2.6.6. 2-6 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.3 Understanding the CART Reports Table_2-2_CART_Reports_____________________________________ Type_of_Report________Description__________________________ CART full report CM_CART_FULL_runid.TXT For the primary language, the name of this report is CM_CART_FULL_ V31$PRIMARY.TXT, where V31$PRIMARY is the CART runid. This report gives detailed information about the conflicts between your customized elements and Version 3.1 base elements. It gives information on why the element has changed, and suggests resolutions for the conflicts. There is also a description of each status code at the beginning of each status code section. CART summary report CM_CART_SUMMARY_runid.TXT Lists which of your customized elements conflict with ALL-IN-1 Version 3.1 base elements, ordered by status code. As you become more experienced with using the CART, you may find that the summary report provides you with sufficient information. The summary report may also be useful as a checklist when you rerun the CART after upgrading, see Chapter 8. CART site elements CM_CART_SITE_ELEMENTS.TXT report Lists elements in your site areas that are not registered in your site modification log. (continued on next page) Preparing to Upgrade a Customized System 2-7 Preparing to Upgrade a Customized System 2.3 Understanding the CART Reports Table_2-2_(Cont.)_CART_Reports_____________________________ Type_of_Report________Description__________________________ CART error report CM_CART_ERR_runid.TXT Gives details of any errors that occur during the CART run. If there are no errors, this report is not ______________________produced.____________________________ 2.3.2 Format of the CART Reports In the CART reports, elements are listed in alphabetical order by status code, not by the severity of conflict. At the beginning of each set of status codes, there is an explanation of what the code means and the recommended action you should take to resolve the conflict. Additional information is also provided on the reason for a conflict, and information about the changed element itself. The elements are listed in alphabetical order with the element type and location. For example: ALL-IN-1 IOS Conflict Checking and Resolution Tool Full Report ----------- Page: 1 Run at: 18:52 on 30-Dec-1993 Element Status ------- ------ . ARCHIVE_MARK_DOCUMENT_PENDING SCP SHARE A 1 2 3 4 . FC_RESERVE_LIST_CREATE COM SHARE A . NETWORK$CREATE FRM ENGLISH A . TMEVCARG FRM ENGLISH A . 1 Element name 2 Element type 3 Location 2-8 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.3 Understanding the CART Reports 4 Status code Section 2.7, Section 2.8 and Section 2.9 describe each of the CART status codes in more detail. 2.3.3 CART Status Codes and the Severity of Conflict The CART reports give one or more status codes for each customized element. Each status code has an associated conflict level. The severity of the conflict determines the action that you must take to resolve the conflict both before and after the upgrade. There are three levels of severity of conflict: mandatory, recommended and informational. Table 2-3 shows the impact of each level of conflict severity and the action you must take to resolve the conflict. ________________________ Note ________________________ The severity of the conflict is only a guideline. You may find that conflicts listed as recommended action may be very important for your site. Use your knowledge of your system to determine this. ______________________________________________________ For guidelines for resolving conflicts, see Section 2.6.5. Preparing to Upgrade a Customized System 2-9 Preparing to Upgrade a Customized System 2.3 Understanding the CART Reports Table_2-3_CART_Conflict_Severity,_Status_Codes_and_Actions_ Conflict Status Severity____Codes_______Action_You_Must_Take_______________ Mandatory I K L M N You must resolve all mandatory conflicts before you upgrade to ALL-IN-1 Version 3.1. If the conflict is marked mandatory, the installation of ALL-IN-1 Version 3.1 will probably fail; even if it does succeed, you will not be able to run ALL-IN-1 Version 3.1 unless you resolve the conflict before upgrading. There are no automatic procedures for resolving conflicts for elements with status codes I and L. Recommended D E O P Q You must resolve the conflict soon after the upgrade to ALL-IN-1 Version 3.1. You will be able to run ALL-IN-1 Version 3.1 after the upgrade without resolving the conflict, but you will not have full functionality and users may also see inconsistencies within the system. For example, if you have modified the Electronic Messaging menu form but not the Word and Document Processing menu form, users may see new features in Word and Document Processing but not Electronic Messaging. Informational F G H R Resolve the conflict when convenient, after the upgrade to ________________________ALL-IN-1_Version_3.1.______________ 2-10 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.4 Preparing to Run the CART 2.4 Preparing to Run the CART Depending on the customizations on your system, you must do some or all of the tasks listed in this section to prepare your system before running the CART. Do the following before running the CART: o Check the value of JTQUOTA. See Section 3.8.1. o Print a system modification report. See Section 2.4.1 o Import elements and applications that were customized outside of the site areas. See Section 2.4.2. 2.4.1 Printing a System Modification Report To help you work through the CART reports, you should print out a system modification report. This report lists the changes made to elements in the live area. Run this once for the SHARE area and once for each additional language that is installed on your system. To create a system modification report: o Enter AM to go to the Application Maintenance menu o Use the Print modification report (PMR) option 2.4.2 Importing Elements from Outside Customization Management Before you run the CART, it is recommended that you import any elements or applications that were customized outside of Customization Management site areas, into Customization Management. The CART can only check for conflicts with customizations that have been made using Customization Management. The ALL-IN-1 Management Guide explains how to create an application area and move an application from OpenVMS into Customization Management. The CART checks all application areas. 2.4.3 Customized Help Modules When ALL-IN-1 Version 3.1 is installed, a new version of the base Help library, OAHELP.HLB is provided. If you have created or modified Help modules, you will need to add your customized Help modules to the new base Help library after installation. See the Application Programming: Guide. Preparing to Upgrade a Customized System 2-11 Preparing to Upgrade a Customized System 2.4 Preparing to Run the CART 2.4.4 Customized Message Files The message files ending in .MSG that are provided with ALL-IN-1 are not supported by Customization Management. Examples of these are OAMESS.MSG and OAMGRMESS.MSG. If you have customized any of these message files, you must take some action before upgrading, otherwise you will lose your customizations. Save your customized versions of any .MSG message files outside the ALL-IN-1 directory structure. Reapply your changes after the upgrade installation. 2.5 Running the CART You should have completed the preparatory tasks in Section 2.4 before running the CART from the ALL-IN-1 Version 3.1 installation procedure. Read the following notes before running the CART: o If you are upgrading additional languages to ALL-IN-1 Version 3.1, you you must run the CART for each additional language using the ALL-IN-1 Version 3.1 installation procedure for that language. o You do not need to shut down ALL-IN-1 while you run the CART, so your users can continue to use the system. o It may take several hours to run the CART depending on the following factors: o The number of users on your system o The amount of customizations on your system o The configuration of your system and the amount of processing power In addition to the time that the CART takes to run, you must set aside time to work through the reports and to decide on an upgrade plan for each of your customizations. To run the CART from the ALL-IN-1 Version 3.1 installation procedure: 1. Create a log of the installation: $ SET HOST 0/LOG=filename 2. Follow steps 1 to 4 in Table 5-2. 2-12 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.5 Running the CART 3. Press RETURN when the list of installation options are displayed: Using the FULL ALL-IN-1 V3.1 kit, the following installation types can be performed: (1) Upgrade of ALL-IN-1 V3.0 TO ALL-IN-1 V3.1 (2) Minimal Shutdown Upgrade of ALL-IN-1 V3.0 to ALL-IN-1 V3.1 (RL) Register licenses for prerequisite software * Which installation do you wish to perform [1]: ________________________ Note ________________________ Choosing this option does not install the software. ______________________________________________________ 4. Choose the Run conflict checking and resolution tool (RC) option by entering: RC: The installation procedure allows you to perform the following actions: (I) Perform the installation (PC) Perform all preinstallation checks (RC) Run conflict and checking resolution tool (CART) * Which action do you wish to perform [I]: RC 5. Enter the language code (and dialect code if applicable) when prompted. When you have answered all of the questions asked by the installation procedure, the procedure restores the CART kit saveset. For example: %A1LUS-I-RESCARTSS, Restoring ENGLISH CART kit saveset The CART processes each of your customized elements in turn, and displays informational messages. When the CART has finished running, the installation procedure terminates. 6. Log out. 7. Check the installation log to find the location of the CART reports and the CART resolution script. Preparing to Upgrade a Customized System 2-13 Preparing to Upgrade a Customized System 2.6 What to do After Running the CART 2.6 What to do After Running the CART After running the CART, do the following: 1. Check the site elements report, CM_CART_SITE_ELEMENTS.TXT, and take appropriate action. See Section 2.6.1. 2. Check the full report, CM_CART_FULL_runid.TXT for missing elements (elements reported with status codes B or C) and take appropriate action. See Section 2.6.2. 3. Rerun the CART if necessary. See Section 2.6.3. 4. Prepare an upgrade plan. See Section 2.6.4. 2.6.1 Checking the Site Elements Report Check the CART site elements report, CM_CART_SITE_ELEMENTS.TXT, for references to supported Customization Management elements that are registered in your site modification log but which cannot be found by the CART. If the site elements report refers to any of these elements, you can either find them and import them into Customization Management, or remove the entries from the site modification log. See Chapter 20 in the ALL-IN-1 Management Guide. Elements that were not supported by Customization Management in ALL-IN-1 Version 3.0 may also be listed in this report. It is recommended that you put any newly- supported elements into Customization Management. Files with the extension .EXE or .FLC in site directories can be safely ignored. 2.6.2 Checking for Missing Elements (Status Codes B and C) Search the CART full report, CM_CART_FULL_runid.TXT, for all elements with status codes B and C. The CART reports any elements that it cannot find with these status codes. As the CART has not found these elements, it has not been able to check if the customized elements conflict with Version 3.1 elements. It is possible that elements which should be reported with a mandatory conflict are being reported with status B or C instead. Table 2-4 gives a more detailed description of these status codes and the action that you can take. 2-14 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.6 What to do After Running the CART You must take some action, for example, find and move the element to the correct location. You must then rerun the CART so that it can check for conflicts and ensure that all mandatory conflicts are identified and reported. See Section 2.6.3. Do not proceed any further until you can generate a CART report which does not have any elements reported with status code B or C. Table_2-4_CART_Status_Codes_B_and_C________________________ Code___Description___________Action________________________ B The site Check that the entry in the modification log site modification log is contains an entry correct. You can either: for this customized o Delete the entry in the element which site modification log. indicates that it is in the development o Locate the element and area but the element correct the problem, for cannot be found example recover or recreate at the specified the file. location. ___________________________________________________________ C The site Check that the entry in the modification log site modification log is contains an entry correct. You can either: for this customized o Delete the entry in the element which site modification log. indicates that it is in the live area but o Locate the element and the element cannot correct the problem, for be found at the example recover or recreate specified location. the file. ___________________________________________________________ Preparing to Upgrade a Customized System 2-15 Preparing to Upgrade a Customized System 2.6 What to do After Running the CART 2.6.3 Rerunning the CART It is recommended that you rerun the CART in the following cases: o If the CART reported elements with status code B or C and you have taken some action with those elements o If you had to import many elements into Customization Management because of information in the site elements report ________________________ Note ________________________ You should only continue with the tasks in the rest of this chapter when the CART generates a report that does not contain any elements reported with status code B or C. This is to ensure that all elements have been found and correctly processed by the CART. ______________________________________________________ Rerun the CART from the ALL-IN-1 Version 3.1 installation procedure as described in Section 2.5. When you rerun the CART, it overwrites all of the existing CART reports, except for the error report, which is appended to the original. If you want to retain old copies of the CART report files, rename them before running the CART. For example, to rename the full CART report: $ RENAME/LOG dev:[ALLIN1.SITE]CM_CART_FULL_REPORT_V31$PRIMARY.TXT - _$ dev:[ALLIN1.SITE]OLD_CART_FULL_PRIMARY.TXT 2.6.4 Preparing Your Upgrade Plan An upgrade plan details the action you are going to take for each of the customization conflicts that are reported. These are the actions that you will take for each customized element before and after the upgrade installation. In addition to the time needed to perform the upgrade, allow time to make mandatory changes, and time to decide how you are going to migrate your customizations. 2-16 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.6 What to do After Running the CART Use the supplementary information in the full report to help you decide how to migrate your customizations to ALL-IN-1 Version 3.1. Do the following: 1. Review the conflicts reported by the full CART report, CM_CART_FULL_runid.TXT, in the order of severity of conflict: a. Mandatory status codes o Find and review all customized elements with status codes: I, K, L, M and N. See Section 2.7. o Plan the action you will take before upgrading, and decide how you will resolve these conflicts after upgrading, see Section 2.6.5. b. Recommended status codes o Find and review all customized elements with status codes: D, E, O, P and Q. See Section 2.8. o Plan how to resolve these conflicts immediately after upgrading. c. Informational status codes o Find and review the customized elements with status codes: A, F, G, H and R. See Section 2.9. o Plan how you will resolve these conflicts after upgrading. 2. Plan postinstallation tasks, for example how you will use the CART resolution procedure. See Section 2.6.6 and Section 2.6.7. If an element is reported with two status codes, review its conflicts in severity order in the same way. For example, if an element is reported with status codes E and H, review the recommended conflict first, then the informational conflict. For guidelines on resolving conflicts, see Section 2.6.5. The actions that you need to take will depend on the customizations at your site. Preparing to Upgrade a Customized System 2-17 Preparing to Upgrade a Customized System 2.6 What to do After Running the CART 2.6.5 Guidelines for Resolving Conflicts To ensure that you have access to all the functionality of ALL-IN-1 Version 3.1, you will have to resolve each conflict in one of the following ways: o Delete your customized element, so that you use the Version 3.1 base element instead. Do this if you no longer require your customization, for example, if your customization fixed a problem or provided functionality that is now supplied as part of ALL-IN-1 Version 3.1. o Apply your customizations to the Version 3.1 element. Do this if you want to retain your customizations. o Customize your version of the base element to include the Version 3.1 changes. Do this if you want to retain your customizations, and there are fewer changes in the Version 3.1 element than in your customized element. You can only do this after the upgrade. 2.6.6 CART Resolution Procedure After the upgrade to ALL-IN-1 Version 3.1, the CART provides an ALL-IN-1 script in your top level site directory, for example, [ALLIN1.SITE]. This script is known as the CART resolution procedure, CM_CART_SCRIPT_runid.SCP. The script enables you to automatically resolve some of the conflicts reported by the CART. For these conflicts, the procedure performs the minimum steps necessary to ensure that your system works correctly and that you have access to all the ALL-IN-1 Version 3.1 features. ________________________ Note ________________________ You must customize the CART resolution procedure to do what is required for your site. The CART resolution procedure calls individual scripts to process elements for each of the CART status codes. To see what processing the CART resolution procedure does for each status code, refer to the relevant script (called OA$LIB:CM_CART_SCRIPT_n, where n is the status code). 2-18 Preparing to Upgrade a Customized System Preparing to Upgrade a Customized System 2.6 What to do After Running the CART You can edit the script to customize it before you upgrade but you cannot run the script until you have completed the upgrade installation to ALL-IN-1 Version 3.1. See Chapter 8. ______________________________________________________ The CART resolution procedure marks obsolete files that are no longer required by ALL-IN-1 Version 3.1 for deletion. It deletes element records from the base elements file. You can delete these files automatically after upgrading by running a command procedure. See Section 8.10.2. It is not mandatory to use the CART resolution procedure to resolve conflicts. For example, if it does not do enough to resolve your particular conflicts, you may decide to resolve your conflicts directly, using Customization Management. 2.6.7 Planning Postinstallation Tasks You must allow some time in your upgrade plan for reviewing your customizations after the upgrade installation. The details of the tasks tha