═══ 1. We'd Like to Hear from You ═══ Please let us know how you feel about the books for this product by placing a check mark in one of the columns following each question below: Note that IBM may use or distribute the responses to this form without obligation. To return this form, print it, write your comments, and: o Mail it to: International Business Machines Corporation Department 452, internal zip 9151 Austin, TX 78758 USA o Send a FAX (U.S. only) to: (512) 838-0666 For postage-paid mailing, please give your form to your IBM representative. Please check off the online (O/L) or hardcopy (H/C) book you are commenting about: O/L H/C ___ ___Easy Start ___ ___Up and Running! ___ ___NARV1: Planning, Installation and Configuration ___ ___NARV2: Performance Tuning ___ ___NARV3: Network Administrator Tasks ___ ___OS/2 LAN Requester User's Guide ___ ___DLS and Windows User's Guide ___ ___Problem Determination Guide ___ ___Programming Guide and Reference ___ ___Commands and Utilities n/a ___Guide to LAN Server Books ___ ___MPTS Configuration Guide ___ ___LAN CID Utility Guide Overall, how satisfied are you with the book? Very Very Satisfied Dissatisfied 1 2 3 4 Overall Satisfaction ___ ___ ___ ___ Are you satisfied that the book is: Accurate ___ ___ ___ ___ Complete ___ ___ ___ ___ Easy to find ___ ___ ___ ___ Easy to understand ___ ___ ___ ___ Well organized ___ ___ ___ ___ Applicable to your tasks ___ ___ ___ ___ Please tell us how we can improve the information: _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ Thank you! May we contact you to discuss your responses? ___Yes ___No Name: _________________________________________________________ Title: _________________________________________________________ Company or Organization: _________________________________________________________ Address: _________________________________________________________ _________________________________________________________ _________________________________________________________ Phone: (___)__________________________________________ Fax (___)__________________________________________ Do not use this form to request IBM publications. Please direct any requests for copies of publications or for assistance in using your IBM system, to your IBM representative or to the IBM branch office serving your locality. ═══ 2. Version Notice ═══ First Edition (August 1994) The following paragraph does not apply to the United Kingdom or any country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you. This publication could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time. It is possible that this publication may contain reference to, or information about, IBM products (machines and programs), programming, or services that are not announced in your country. Such references or information must not be construed to mean that IBM intends to announce such IBM products, programming, or services in your country. Requests for copies of this publication and for technical information about IBM products should be made to your IBM Authorized Dealer or your IBM Marketing Representative. (C) Copyright International Business Machines Corp. 1991, 1994. All Rights Reserved. (C) Copyright Microsoft Corp. 1988, 1991. Note to US Government Users - Documentation and programs related to restricted rights - Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. ═══ 3. Notices ═══ References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any of IBM's intellectual property rights or other legally protectible rights may be used instead of the IBM product, program, or service. Evaluation and verification of operation in conjunction with other products, programs, or services, except those expressly designated by IBM, are the user's responsibility. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any rights to these patents. You can inquire, in writing, to the IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594, USA. The following terms, denoted by an asterisk (*) in this publication, are trademarks of the IBM Corporation in the United States and/or other countries: Extended Services Extended Services for OS/2 IBM Operating System/2 OS/2 Presentation Manager Workplace Shell The following terms, denoted by a double asterisk (**) in this publication, are trademarks of other companies as follows: EtherCard PLUS Standard Microsystems Corporation EtherLink 3Com Corporation NIUpc Ungermann-Bass, Inc. NIUps Ungermann-Bass, Inc. Standard Microsystems Standard Microsystems Corporation Windows Microsoft Corporation ═══ 4. Introduction ═══ IBM* Multi-Protocol Transport Services (MPTS) provides a program that enables Operating System/2* (OS/2*) products to operate on a network. MPTS consists of the following publications and diskettes: o Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide o Multi-Protocol Transport Services - AnyNet for OS/2: Error Messages and Problem Determination Guide o LAN Configuration, Installation, and Distribution Utility Guide o Multi-Protocol Transport Services - AnyNet for OS/2: Programmer's Reference o Multi-Protocol Transport Services - AnyNet for OS/2: Error Messages and Problem Determination Guide o MPTS diskettes 1 through 3 ═══ 4.1. About This Book ═══ Note: This book is supplemented by the MPTS README.UTL file on MPTS diskette 3. Ensure that you read this file. The code server setup information in the README is also presented in this book for your convenience. See The CASSETUP Code Server Setup Utility. This LAN Configuration, Installation, and Distribution Utility Guide describes how to install and configure CID-enabled products on a number of workstations by using redirected installation. The term CID stands for Configuration Installation Distribution. A product that is CID enabled is a product based on the OS/2 program that can be installed and configured with redirection in a local area network (LAN) environment with little or no user interaction. The utility that allows the automation of redirected installation and configuration is the LAN Configuration Installation Distribution Utility (LAN CID Utility). File redirection between the workstations and the server is handled by the Service Installable File System (SRVIFS). This book discusses the installation and use of both LAN CID Utility and SRVIFS. ═══ 4.2. Who Should Read This Book ═══ This book is designed for system administrators, network administrators, or other support personnel responsible for installation in OS/2 environments. They should have experience with the products they plan to install with redirection. ═══ 4.3. How This Book Is Structured ═══ This book contains the following chapters: o Overview and Roadmap, provides an overview of CID, LAN CID Utility, and SRVIFS as well as a road map of the CID process. The map points to sources of additional information. o Setting Up the Directory Structure on the Code Server, shows you how to set up the recommended directory structure on the server and provides an alternate structure. o Loading LAN CID Utility, SRVIFS, and LAPS on the Code Server, explains how to load LAN CID Utility, SRVIFS, and LAPS images and how to obtain required OS/2 2.x files. o Loading Product Images on the Code Server, shows you how and where to load product images on the code server. o Loading the OS/2 2.x Program on the Code Server, gives procedures for loading the OS/2 2.x program on the code server and determining if you need a Service Pak. o Installing SRVIFS on the Code Server, shows you how to install SRVIFS on the server and explains NetBIOS requirements. A sample SRVIFS configuration file and authorization file are provided. o Creating and Using Response Files, shows you how to create and use response files, which contain choices and settings used to install individual products. This chapter also contains a sample response file. o Creating LAN CID Utility REXX Command Files, shows you how to create and use command files, which control the remote installation of one or more products. This chapter also contains a sample LAN CID Utility REXX command file. o Creating Boot Diskettes, shows you how to create boot diskettes. o Redirected Installation of Products on the Client, shows you two ways to install products on a client. One way to install is with boot diskettes and the other is without boot diskettes. o Return Code Processing, explains return codes and recovery procedures for CID-enabled products. o Installation Scenarios, lists scenarios for installing products, including the command file statements, the installation statements, and the resulting log files. This book contains the following appendixes: o The CASPREP Program, Keywords, and Input Files, provides the CASPREP SAMPLE program and sample CASPREP input files. It also explains the run-time invocation of CASPREP. o Migrating from Previous LAN CID Utility Command Files and Directory Structures, discusses migration and use of command files and directory structures created for use with the NTS/2 version of this product. o Engineering Firm Example, contains examples of using this product for installations in an engineering firm. o Example Steps for Installing the OS/2 2.x Program, provides an example of the steps required for installing the OS/2 2.x program with redirection. o System-Wide CID Recovery, describes the recovery procedure for CID-enabled products using LAN CID Utility. o Sample Files, groups the sample files MPTS requires in one place. The files include: the SRVIFS configuration file, the SRVIFS authorization list file, the response file, and the command file. o Commands Reference, provides syntax and parameters for using LAN CID Utility and SRVIFS commands. o REXX Procedures for System Administrators, lists REXX procedures for use during an installation sequence. o The CASSETUP Code Server Setup Utility, provides information on a tool that assists in setting up the code server and creating boot diskettes. o LAN CID Utility and SRVIFS Problem Determination, provides problem determination information for LAN CID Utility and SRVIFS. In addition, this book contains a glossary and an index. ═══ 4.4. Related Publications ═══ You can find additional information about CID in the following publications: o Automated Installation for CID Enabled OS/2 V2.0 o Automated Installation for CID Enabled Extended Services, LAN Server V3.0, and Multi-Protocol Transport Services - AnyNet for OS/2 V1.0 o Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide o Multi-Protocol Transport Services - AnyNet for OS/2: Error Messages and Problem Determination Guide o IBM Operating System/2 Local Area Network Server Version 4.0 Network Administrator Reference - Volume 1: Planning and Administration - Volume 2: Performance Tuning - Volume 3: Network Administrator Tasks o IBM LAN NetView Start User's Guide. In addition, the following product provides online information: o The IBM Extended Services Configuration, Installation, and Distribution Utility provides an ESCID Utility User's Guide on the product diskettes. o System Performance Monitor/2 2.0 provides online information on the product diskettes. Contact your IBM authorized dealer or your IBM marketing representative for information about ordering the preceding publications. In addition, the IBM OS/2 NDIS Driver Implementation Package contains information about the following items: o NDIS Version 2.01 o Extended network information file (NIF) format o NDIS extensions to Version 2.01 o IBM Local Area Network Technical Reference extensions o Message processes and national language support. Contact IBM Corporation, Dept. 483, Attn: NDIS, Austin, TX, 78758, to request copies. ═══ 5. Overview and Roadmap ═══ Note: This book is supplemented by the MPTS README.UTL file on MPTS diskette 3. Ensure that you read this file. The code server setup information in the README is also presented in this book for your convenience. See The CASSETUP Code Server Setup Utility. This chapter contains an overview of redirected installation and configuration, which is provided with Multi-Protocol Transport Services - AnyNet for OS/2 (MPTS). Also discussed are the components of redirected installation and configuration: o LAN CID Utility o SRVIFS This chapter concludes with a roadmap of tasks to perform for redirected installation and configuration. ═══ 5.1. Overview of Redirected Installation and Configuration ═══ Installing software products on a large number of workstations can be a complex, time-consuming process. You may be accustomed to sitting at each workstation with a set of diskettes and manually entering answers to the configuration questions every time a workstation needs to have a software product installed, configured, or maintained. Redirected installation and configuration can help you automate this process because it takes advantage of OS/2 2.x connectivity. You can install a set of OS/2 2.x-based products on any number of connected workstations without having to interact directly with the installation process. These OS/2 2.x-based products are CID-enabled for redirected installation and configuration. Configuration Installation Distribution (CID) provides for a centrally managed system of OS/2 2.x that can create, store, distribute, and maintain software on a LAN. The program that automates the redirected installation and configuration of CID-enabled products is LAN Configuration, Installation, and Distribution Utility Guide. LAN CID Utility allows you to perform a series of CID-enabled product installations. The program that handles the redirection is the Service Installable File System (SRVIFS). With SRVIFS, you can install and configure these products on a number of clients from one server. The following types of files are used in the redirected installation and configuration process: o A LAN CID Utility REXX command file on the server identifies the products that you plan to install on the client and contains the commands for performing the installations. o Individual product response files contain information needed for installing a product on a client. These product response files contain answers to the configuration questions that are asked during installation. o A SRVIFS configuration file is used to configure the code server. o A SRVIFS authorization list file is used to give clients access to the code server. The process for redirected installation and configuration discussed in this book also applies to any OEM products that have been enabled for CID. ═══ 5.2. LAN Configuration, Installation, and Distribution Utility Guide Overview ═══ LAN CID Utility is a software distribution manager that enables the ordering of software installations on client workstations and performs the installations with minimal user interaction. LAN CID Utility is comprised of REXX procedures and several supporting modules that track the current state of an installation across reboots and ensure that each step is run in the proper sequence. Once the desired sequence is defined to LAN CID Utility, the installation process runs to completion without user involvement (assuming no errors are encountered). Each product that you plan to install with redirection may have different requirements. It is important to understand the installation requirements for these individual products. For example, both the IBM Communications Manager/2 and the IBM LAN Server 4.0 programs require that the OS/2 2.x system on which they are to run is already installed and active. Both also require that the Presentation Manager* feature of the OS/2 2.x program be installed and active. In addition, the LAN Adapter and Protocol Support (LAPS) component of the MPTS product needs to be installed for two reasons: o The LAPS component of MPTS gives you access to the server in a LAN environment so that you can use redirected installation. o MPTS LAPS is a prerequisite for the LAN Server 4.0 product and may also be required by the Communications Manager/2 program. Note: The workstation from which you install CID-enabled products onto clients is termed a code server. If your code server already has IBM Extended Services* installed or will have Extended Services installed, do the following: o On a new code server, install Extended Services first and then MPTS LAPS. o On an existing code server, if Extended Services is already installed, install MPTS LAPS. o See Product-Specific Notes for more information on installing Communications Manager/2. ═══ 5.3. SRVIFS Overview ═══ SRVIFS provides both client and server functions to allow for sharing file access in a LAN environment. SRVIFS utilizes NetBIOS protocol and an OS/2 2.x installable file system (IFS) to accomplish its objectives. The SRVIFS server function is driven by a configuration file. The primary information in this configuration file defines: o A NetBIOS name that the server is to be known by on the network. o The aliases for the directory structure on the server that SRVIFS clients can gain access to. The access to the directory structure on the server can be ReadWrite or ReadOnly. The SRVIFS client function consists of an IFS that is initiated by an IFS= statement in CONFIG.SYS. This IFS, which is also referred to as a file system driver (FSD), provides a command interface (FS_ATTACH). IFS allows the client to attach to a SRVIFS server and to access the directories as defined by the aliases in the server's SRVIFS configuration (.INI) file. Once the IFS is active, the client explicitly issues specific attach commands to establish a connection with a specified server-alias pair as a logical drive. For example, in a CID environment the user may attach to a server and gain access to a directory containing installable product images as the logical drive (Z:). Note: SRVIFS is only intended to be used in conjunction with LAN CID Utility. It is not intended to be used as a general redirector in the LAN environment. SRVIFS should be removed from the client workstations at the end of the installation process. ═══ 5.4. Roadmap for Redirected Installation and Configuration ═══ Many of the details about planning and setting up to use LAN CID Utility are contained in this book. However, you must also refer to the publications provided by the individual CID-enabled products for some of the information you will need. Related Publications contains a list of publications that you may need. The road map that follows provides a series of steps for you to follow and guides you to the information you need. The steps are organized into four parts: o Planning o Obtaining prerequisites o Setting up the code server o Installing product images on a client. For an example of installing the OS/2 2.x product, see Example Steps for Installing the OS/2 2.x Program. ═══ 5.4.1. Steps for Planning ═══ ┌────────────────────────────────────────────────────┬─────────────────────────┐ │ STEPS │ WHERE TO FIND MORE │ │ │ INFORMATION │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 1. Plan your network. │ See the publications │ │ │ provided by the │ │ When planning your network, you should already │ CID-enabled products. │ │ have read the planning publications provided by │ Most products have doc- │ │ the individual products that you will install on │ umentation about │ │ the workstations in your network, and you should │ network planning, │ │ know how you want your network to be organized. │ installation, and con- │ │ │ figuration that you │ │ Now you must plan how you will use CID to dis- │ will need to study. │ │ tribute the product images from the code server to │ │ │ the client workstations. │ Also, see the publica- │ │ │ tions listed in Related │ │ │ Publications for more │ │ │ information. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 2. Ensure that your network meets the pre- │ See the Multi-Protocol │ │ requisites for redirected installation using CID: │ Transport Services - │ │ │ AnyNet for OS/2: Con- │ │ o The code server and the client workstations on │ figuration Guide and │ │ which you will install product images must be │ the publications listed │ │ connected by a LAN. │ in Related Publications │ │ │ for more information. │ │ The clients and code server must communicate │ │ │ over the LAN connection using the NetBIOS pro- │ │ │ tocol. │ │ │ │ │ │ o The code server must have NetBIOS installed │ │ │ and configured for LAN communications. │ │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 3. Make a list of all the CID-enabled pro- │ See the publications │ │ ducts that you want to install with redirection │ provided by the │ │ from the code server to all of your client │ CID-enabled products. │ │ (target) workstations. │ Most products have doc- │ │ │ umentation about │ │ Later you will install each product image onto the │ network planning, │ │ code server. │ installation, and con- │ ├────────────────────────────────────────────────────┤ figuration that you │ │ STEP 4. Make another list, organized by indi- │ will need to study. │ │ vidual workstations. │ │ │ │ See the publications │ │ For each workstation, decide which CID-enabled │ listed in Related │ │ products you will install with redirection. For │ Publications for more │ │ some products, you must also decide which features │ information. │ │ to install. For example, for Extended Services, │ │ │ you can install Communications Manager and Data- │ │ │ base Manager with redirection; within Communi- │ │ │ cations Manager, you may need to install │ │ │ customized keyboard profiles. │ │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 5. Plan the directory structure on the code │ See Preparing for the │ │ server. │ Recommended Directory │ │ │ Structure for informa- │ │ Plan the directory structure for the product │ tion about planning │ │ images and files that you will store on the code │ your overall file │ │ server. You will set up the directory structure │ directory structure. │ │ in a later step, and then you will copy the │ │ │ product images and other files onto the code │ See the appropriate │ │ server. │ publication for each │ │ │ CID-enabled product for │ │ When planning the directory structure, you can │ recommendations for a │ │ either: │ specific file directory │ │ │ structure. │ │ o Plan the complete directory structure first │ │ │ o Or plan each subdirectory as you need it. │ │ │ │ │ │ Some CID-enabled products have a fixed directory │ │ │ structure for their own files. You should ensure │ │ │ that any product-specific structure fits into your │ │ │ root directory structure. │ │ └────────────────────────────────────────────────────┴─────────────────────────┘ ┌────────────────────────────────────────────────────┬─────────────────────────┐ │ STEPS │ WHERE TO FIND MORE │ │ │ INFORMATION │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 6. Plan code server prerequisites. │ See Loading LAN CID │ │ │ Utility, SRVIFS, and │ │ Ensure that you have planned for the prerequisites │ LAPS on the Code Server │ │ required for the workstation that will be your │ and the documentation │ │ code server, such as hardware, software, and LAN │ for the products you │ │ connectivity. │ plan to install for │ │ │ more information. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 7. Plan client workstation prerequisites. │ o If the OS/2 │ │ │ program, version │ │ Ensure that you have planned for the following │ 1.3 or later, is │ │ prerequisites required for each client │ not already │ │ workstation: │ installed on the │ │ │ client, see │ │ o Level of operating system: The clients must │ Creating Boot │ │ be able to run the OS/2 2.0 program or higher. │ Diskettes for more │ │ │ information. │ │ o Random access memory (RAM): Each CID-enabled │ │ │ product has its own memory requirements. In │ o See the publica- │ │ addition, when LAN CID Utility runs on the │ tions provided by │ │ client workstation, it requires 6MB of RAM on │ the CID-enabled │ │ the client. │ products for memory │ │ │ requirements. │ │ o Fixed-disk space: Each CID-enabled product │ │ │ has its own requirements for fixed-disk space. │ o See the publica- │ │ │ tions provided by │ │ │ the CID-enabled │ │ │ products for fixed- │ │ │ disk requirements. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 8. Plan for boot diskettes. │ See Creating Boot │ │ │ Diskettes for more │ │ Decide how many client workstations will need boot │ information. │ │ diskettes. You must create boot diskettes for a │ │ │ client workstation that does not already have the │ │ │ OS/2 program, version 1.3 or later, and NetBIOS │ │ │ installed and configured for LAN communications. │ │ │ You may also decide to use boot diskettes even for │ │ │ a workstation that has the OS/2 program, version │ │ │ 1.3 or later, and NetBIOS installed and configured │ │ │ for LAN communications. │ │ └────────────────────────────────────────────────────┴─────────────────────────┘ ═══ 5.4.2. Obtaining Prerequisites ═══ After completing the planning steps, obtain and install the prerequisites you need for the code server and the clients. ═══ 5.4.3. Steps for Setting Up the Code Server ═══ The following steps outline how to set up the code server, install product images in the recommended directory structure, and build response files and command files. Note: For the first four steps listed in this section, you can also use the setup utility. See The CASSETUP Code Server Setup Utility for more information. ┌────────────────────────────────────────────────────┬─────────────────────────┐ │ STEPS │ WHERE TO FIND MORE │ │ │ INFORMATION │ ├────────────────────────────────────────────────────┼─────────────────────────┤ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 1. Determine if you will use an OS/2 Service │ See Determining If a │ │ Pak. │ Service Pak Is to Be │ │ │ Used.. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 2. Set up the directory structure on the │ See Creating the Direc- │ │ code server. │ tory Structure for more │ │ │ information. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 3. Load the LAN CID Utility, SRVIFS, and │ Follow the steps in │ │ LAPS product images onto the code server. │ Loading LAN CID │ │ │ Utility, SRVIFS, and │ │ │ LAPS on the Code │ │ │ Server.. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 4. Load the product images and files for │ See Loading Product │ │ each CID-enabled product onto your code server. │ Images on the Code │ │ │ Server.. │ │ Each product has its own method for loading │ │ │ product images. │ Also see the publica- │ │ │ tions provided by each │ │ │ CID-enabled product for │ │ │ product-specific │ │ │ instructions. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 5. Load programs that LAN CID Utility │ See Obtaining the │ │ requires from the operating system onto the code │ Required OS/2 2.x │ │ server. │ Files.. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 6. Use the THINSRV command to install and │ See Using THINSRV to │ │ configure the SRVIFS server on the code server. │ Install the SRVIFS │ │ SRVIFS provides file redirection service. │ Server and THINSRV for │ │ │ more information. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 7. Start the SRVIFS server by rebooting the │ See Starting the SRVIFS │ │ code server workstation or by running STARTUP.CMD. │ Server and SERVICE for │ │ │ more information. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 8. Create response files to be used with │ See Creating and Using │ │ individual product installations. │ Response Files,, for │ │ │ more information. │ │ Each CID-enabled product has its own method for │ │ │ creating its response files, and each product has │ See the publications │ │ its own requirements and keywords that you must │ provided by each │ │ use. │ CID-enabled product for │ │ │ its response file │ │ │ requirements. │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 9. Create command files. │ See Creating LAN CID │ │ │ Utility REXX Command │ │ The LAN CID Utility REXX command files that you │ Files,, for details. │ │ create will control installation at the client │ │ │ workstations. │ See the publications │ │ │ provided by each │ │ LAN CID Utility provides a sample command file │ CID-enabled product for │ │ that you can edit. │ specifics about its │ │ │ command-line interface. │ │ When you create the command file, you must know │ See the IBM LAN NetView │ │ the command that each CID-enabled product uses to │ Start User's Guide if │ │ initiate installation of that product. │ you are using the IBM │ │ │ LAN NetView Start │ │ │ product. │ └────────────────────────────────────────────────────┴─────────────────────────┘ ═══ 5.4.4. Steps for Installing Products on a Client ═══ The following steps outline how to install product images on the client workstations. ┌────────────────────────────────────────────────────┬─────────────────────────┐ │ STEPS │ WHERE TO FIND MORE │ │ │ INFORMATION │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 1. If necessary, create boot diskettes for │ See Creating Boot │ │ those client workstations that do not already have │ Diskettes,, for │ │ NetBIOS installed and configured for LAN communi- │ details. │ │ cations. │ │ ├────────────────────────────────────────────────────┼─────────────────────────┤ │ STEP 2. Install each client workstation. │ See Redirected Instal- │ │ │ lation of Products on │ │ You can: │ the Client, for │ │ │ details. │ │ o Install a client using boot diskettes that you │ │ │ have created. │ │ │ │ │ │ o Or install a client without boot diskettes. │ │ │ In this case, you must have SRVIFS and LAN CID │ │ │ Utility installed on the client. │ │ └────────────────────────────────────────────────────┴─────────────────────────┘ ═══ 6. Setting Up the Directory Structure on the Code Server ═══ This chapter shows you how to plan your directory structure and then how to create that structure on the code server. If you are using the setup utility detailed in The CASSETUP Code Server Setup Utility, you can still benefit from reading Planning the Directory Structure. ═══ 6.1. Planning the Directory Structure ═══ Before you begin loading product images and installing the SRVIFS server on the code server, you must first consider the type of directory structure that you want on the code server. The structure determines where the product images and other files are located so that LAN CID Utility and SRVIFS can find them. LAN CID Utility itself does not require any specific directory structure. ═══ 6.1.1. Directory and Path Names Used in This Book ═══ This book frequently refers to the directories shown here in the recommended directory structure. The path names are in the following form: \IMG\product The path name contains the following: The path preceding the directory structure. For example, if you have the directory structure on your C: drive at the \CID directory, the example path name is C:\CID\IMG\product. product The specific product subdirectory. See the list of example product subdirectories in Product Subdirectories to Create. For example, if the product is the OS/2 2.0 program, the example path name is \IMG\OS2V20. This book assumes that you plan to follow the recommended directory structure. If you have created a directory structure other than the recommended directory structure, insert your own directory names whenever necessary. Also, see Directory Structure Alternatives. ═══ 6.1.2. Preparing for the Recommended Directory Structure ═══ The following diagram shows a recommended directory structure for use with LAN CID Utility. You have the choice of creating your own directory structure or using the recommended directory structure shown here. Note: If you do not plan to use the recommended directory structure but do intend to use the sample command file, you must make modifications to the path names in the sample command file, which was built for the recommended directory structure. ═══ 6.1.3. Recommended Directory Structure ═══ Recommended Directory Structure CID ───────┐ │ IMG ├────────┐ product1 │ ├──────── │ │ product2 │ ├──────── │ │ │ CSD ├────────┐ product1 │ ├────────┐ CSD01 │ │ ├──────── │ │ product2 │ ├────────┐ CSD01 │ │ ├──────── │ EXE ├────────┐ V200 │ ├────────┐ FILEn.EXE │ │ ├──────── │ │ V2nn │ ├────────┐ FILEn.EXE │ │ ├──────── │ │ │ │ FILEn.EXE │ DLL ├────────┐ V200 │ ├────────┐ FILEn.DLL │ │ ├──────── │ │ V2nn │ ├────────┐ FILEn.DLL │ │ ├──────── │ │ │ │ FILEn.DLL │ DISK1 ├────────┐ V200 │ ├────────┐ FILEn.EXE │ │ │ FILEn.DLL │ │ │ FILEn.xxx │ │ V2nn │ ├────────┐ FILEn.EXE │ │ │ FILEn.DLL │ │ │ FILEn.xxx │ LOG ├────────┐ product1 │ ├─────────────┐ CLIENTn.LOG │ │ product2 │ ├─────────────┐ CLIENTn.LOG │ RSP ├────────┐ product1 │ │ │ CLIENTn.RSP │ │ │ DEFAULT.RSP │ │ product2 │ ├─────────────┐ CLIENTn.RSP │ │ │ DEFAULT.RSP │ CLIENT ├────────┐ CLIENTn.CMD │ DEFAULT.CMD SERVER ───────┐ │ SERVER1.INI ├──────── Note: 1. Create the directories (but not the file names) that are pictured in italic uppercase letters with extensions such as .EXE and .RSP. 2. The \V200 and \V2nn. directories under the \EXE, \DLL, and \DISK1 directories are to accommodate multiple versions of the OS/2 product images on the code server. The REXX DLLs and redirected installation modules shipped with one version of the OS/2 program may not necessarily work with another version of the OS/2 program. If more than one version of the OS/2 program is to be resident on the code server, it is necessary to separate these modules. This book uses the \EXE\V200, \DLL\V200, and \DISK1\V200 directories as examples. 3. SRVIFS is put on the code server twice, first as product images and second as an installation of the product itself. For the actual installation, it is suggested that you create a directory in which to install the SRVIFS server that is at a different level from the directories for the product images. The examples in the remainder of this book use D:\SERVER for installing the SRVIFS server. 4. The illustration shows only two product subdirectories in each directory, but you can include as many more as you need. ═══ 6.1.3.1. Product Subdirectories to Create ═══ The product1, product2 ... productn subdirectories in the recommended directory structure can contain any products that you want to load on the server for a redirected installation. The following is an example list of product subdirectories that you can put in place of product1, product2 ... productn in the recommended directory structure: Directory Program name LCU LAN CID Utility SRVIFS SRVIFS OS2V20 The OS/2 2.0 program OS2V21 The OS/2 2.1 program CM10 The Communications Manager/2 1.0 program LS40 The LAN Server 4.0 program LAPS The MPTS LAPS program. ═══ 6.1.3.2. Directories to Create ═══ Following is a description of the directories found in the recommended directory structure and the intended contents of the directories. CID The user-defined name of the root directory for all other directories in the recommended structure. IMG The product images directory containing a subdirectory for each product. The individual product subdirectories hold the product images for each product. CSD The CSD directory containing a subdirectory for each product. The individual product subdirectories hold the CSD (Service Pak) images for each product. EXE The executables directory containing the OS/2 2.x EXE files to be used by LAN CID Utility and OS/2 2.x redirected installation programs as unpacked from shipped product images. DLL The dynamic link library (DLL) directory containing the dynamically linked files to be used by REXX. DISK1 The diskette 1 directory containing the files from bootable diskette 1. Use this directory only if you plan to have a redirected diskette1 on the code server. See the definition of the CASINSTL /PD: parameter on page Parameters for more information. LOG The log directory containing a subdirectory for each product. The individual product subdirectories hold the log files for each client on which this product is to be installed. Note: An alternative is to have the log directory contain a subdirectory for each client. In this case, each individual client subdirectory holds all the log files for the products being installed on the client. In order to distinguish among the different product log files, you need to ensure that you specify unique and self-identifying log file names for each product installation. See LAN CID Utility Log File for the OS/2 2.x Program without Boot Diskettes for an example of a log file produced by an installation sequence. RSP The response files directory containing a subdirectory for each product. The individual product subdirectories hold the general response files, the individual client response files, and the default response files for that product. Not all programs use response files. For example, the LAN CID Utility installation program, CASINSTL, and the SRVIFS requester installation program, THINIFS, do not. CLIENT The client directory containing the command files that LAN CID Utility is to use for the redirected installations on the clients. These can be specific client command files, default command files, or both. SERVER The SRVIFS server directory on the code server. It is recommended that this directory be at a different level from the directories for the product images. ═══ 6.2. Creating the Directory Structure ═══ When you have finished planning the directory structure, create the following on the code server if you are using the recommended directory structure: \CID \CID\EXE \CID\EXE\V200 \CID\DISK1 \CID\DISK1\V200 \CID\DLL \CID\DLL\V200 \CID\CLIENT \CID\CSD \CID\CSD\OS2V20 \CID\CSD\OS2V20\CSD1 \CID\CSD\product \CID\IMG \CID\IMG\OS2V20 \CID\IMG\LAPS \CID\IMG\LCU \CID\IMG\SRVIFS \CID\IMG\product \CID\LOG \CID\LOG\OS2V20 \CID\LOG\LAPS \CID\LOG\LCU \CID\LOG\SRVIFS \CID\LOG\product \CID\RSP\ \CID\RSP\OS2V20 \CID\RSP\LAPS \CID\RSP\product \SERVER · · · Give user-defined names to the product subdirectories. For example, to create the directories in which to store product images, you could enter the following at the root directory, where dbprod and comprod are the names of hypothetical CID-enabled products that you plan to install: md cid cd cid md img cd img md os2v20 md laps md lcu md srvifs md dbprod md comprod · · · ═══ 6.3. Directory Structure Compatibility ═══ In order to have a directory structure compatible with all of the CID-enabled products, you need to keep the following items in mind: o LAN CID Utility, by itself, does not require any fixed directory structure. o If you want to ensure a minimal level of security, you must have a directory structure that supports ReadOnly and ReadWrite access to different directories within the directory structure. See Limited Security for more details. o You might want to access information on multiple drives because all of the files that are needed for LAN CID Utility, especially the product images, may not fit on a single drive. See Using Multiple Drives for more details. The following chart summarizes these last two items: ┌──────────────────────────────────────────────────────────────────────────────┐ │ Table 1. Minimal Security with Share Type and Aliases │ ├──────────┬──────────────────┬──────────────────────────┬─────────────────────┤ │ DIREC- │ RECOMMENDED │ SUBDIRECTORY STRUCTURE │ FREQUENCY OF │ │ TORY │ SHARE TYPE │ │ ALIASES │ │ TYPES │ │ │ │ ├──────────┼──────────────────┼──────────────────────────┼─────────────────────┤ │ Images │ Single, ReadOnly │ \IMG\product │ One per drive; one │ │ │ │ │ per system │ ├──────────┼──────────────────┼──────────────────────────┼─────────────────────┤ │ Logs │ Single, │ \LOG\product │ One per system │ │ │ ReadWrite │ OR │ │ │ │ │ \LOG\CLIENT │ │ │ │ or PerClient, │ │ │ │ │ ReadWrite │ │ │ ├──────────┼──────────────────┼──────────────────────────┼─────────────────────┤ │ Response │ Single, ReadOnly │ \RSP\product │ One per system │ │ files │ │ │ │ ├──────────┼──────────────────┼──────────────────────────┼─────────────────────┤ │ Client │ Single, ReadOnly │ \CLIENT │ One per system │ └──────────┴──────────────────┴──────────────────────────┴─────────────────────┘ For the recommended share type, the following definitions apply: Single A single directory for that file type. PerClient A single directory for each client for logs. ReadOnly The directory is ReadOnly for any client. ReadWrite The directory is ReadWrite for any client. Note: When LAN CID Utility first boots on a client, it must have access to \DLL\V2xx, \LOG, and \IMG\LCU. Access may require calling SRVATTCH several times. Before the LAN CID Utility-enabling agent (CASAGENT) runs, all the required paths must be in the CONFIG.SYS file. Also, \IMG\LCU and \DLL\V2xx must be accessible before STARTUP.CMD runs. For more information, see CASAGENT and SRVATTCH. ═══ 6.4. Directory Structure Alternatives ═══ The directory structure shown in Preparing for the Recommended Directory Structure is a basic structure on one disk drive. It assumes that the IBM LAN NetView Start product was not used to create response files. It does not take into account that you may need to use multiple drives, like those shown in Alternative Directory Structure. ═══ 6.4.1. Using Multiple Drives ═══ If you need to spread the directory structure over two or more drives on the code server, Alternative Directory Structure shows the recommended places to make the splits at the user path designations. Use separate SRVATTCH commands to access these points. ═══ 6.4.2. Limited Security ═══ If you require security for the code server, you can accomplish it in a limited way with the SRVATTCH command if you keep the log files separate from the other data. The log files are the only files in the recommended directory structure that must be ReadWrite. For the log files, set up a SRVATTCH alias that is ReadWrite. You can set up everything else with an alias that is ReadOnly. For LAN CID Utility to log information before the command file is called, LAN CID Utility must have access to the subdirectory that contains the log files. This access requires a SRVATTCH outside the command file. If all the files required for LAN CID Utility are on one disk and ReadWrite access is allowed, you can use the THINIFS command to add one SRVATTCH to gain access to this drive. For more information, see THINIFS. Always use the THINIFS command to add SRVATTCH calls to the CONFIG.SYS file. Use one of two methods to give LAN CID Utility access to the log subdirectory: o Issue a second THINIFS command to attach to the subdirectory that contains the logs. This THINIFS command can be the same as the initial command except that the drive, path, and server alias are different. o Define the LAN CID Utility files and the subdirectory for the logs so that you can access both with the same SRVATTCH command. Before the LAN CID Utility-enabling agent (CASAGENT) runs, all the required paths must be in the CONFIG.SYS file. ═══ 6.4.3. Alternative Directory Structure for Multiple Drives ═══ Alternative Directory Structure drive (for example, C:) C:\user path\ │ IMG ├────────┐ product1 │ ├──────── D:\user path\IMG │ │ product2 │ ├──────── E:\user path\ │ CSD ├────────┐ product1 │ ├────────┐ CSD01 │ │ ├──────── F:\user path\CSD │ │ product2 │ ├────────┐ CSD01 │ │ ├──────── G:\user path\ │ EXE ├────────┐ V200 │ ├────────┐ FILEn.EXE │ │ ├──────── │ │ V2nn │ ├────────┐ FILEn.EXE │ │ ├──────── │ │ │ │ FILEn.EXE │ DLL ├────────┐ V200 │ ├────────┐ FILEn.DLL │ │ ├──────── │ │ V2nn │ ├────────┐ FILEn.DLL │ │ ├──────── │ │ │ │ FILEn.DLL H:\user path\ │ DISK1 ├────────┐ V200 │ ├────────┐ FILEn.EXE │ │ │ FILEn.DLL │ │ │ FILEn.xxx │ │ V2nn │ ├────────┐ FILEn.EXE │ │ │ FILEn.DLL │ │ │ FILEn.xxx I:\user path\ │ LOG ├────────┐ product1 │ ├─────────────┐ CLIENTn.LOG │ │ product2 │ ├─────────────┐ CLIENTn.LOG │ RSP ├────────┐ product1 │ │ │ CLIENTn.RSP │ │ │ DEFAULT.RSP │ │ product2 │ ├─────────────┐ CLIENTn.RSP │ │ │ DEFAULT.RSP │ J:\user path\ │ CLIENT ├────────┐ CLIENTn.CMD │ │ DEFAULT.CMD drive (for example, K:) SERVER │ │ SERVER1.INI ├──────── Note: You can substitute other drive letters for those shown in the illustration. For example, the directories for drives G:, H:, and I: are usually small enough to fit on the same drive. ═══ 7. Loading LAN CID Utility, SRVIFS, and LAPS on the Code Server ═══ This chapter explains how and where to load the LAN CID Utility, SRVIFS, and LAPS images. This chapter also explains how to obtain the OS/2 2.x modules that LAN CID Utility requires to perform redirected installations of CID-enabled programs on client workstations. Note: The term images in this book refers to the files and directories used to store a product on the code server. ═══ 7.1. Overview ═══ The following overview shows the steps required in loading LAN CID Utility, SRVIFS, and LAPS on the code server and enabling the code server to perform redirected installations. Following the steps are the detailed instructions that you should use when you are ready to load the product images. 1. Load the LAN CID Utility images. 2. Load the SRVIFS images. 3. Load the LAPS images. 4. Obtain the required OS/2 2.x files. a. Load OS/2 2.x images if they are to be installed on client workstations. b. Obtain the required REXX files. c. Obtain SETBOOT.EXE and XCOPY.EXE. d. Load the OS/2 2.x Service Pak images if they are required. e. If a Service Pak are used, get the fixed modules from the Service Pak. You can use an OS/2 1.3 or an OS/2 2.x workstation as the code server. This chapter includes instructions for both types of code servers. This chapter assumes that you plan to use the recommended directory structure, as illustrated in Recommended Directory Structure. ═══ 7.2. Loading the LAN CID Utility Images ═══ LAN CID Utility is located on MPTS diskette 3. The LAN CID Utility files are packed in a file called LCU.ZIP in the \LCU directory on MPTS diskette 3. In order to unpack the LAN CID Utility files into the desired directory, insert MPTS diskette 3 into drive A: on the code server and issue the following command: PKUNZIP2 A:\LCU\LCU.ZIP \IMG\LCU Note: If MPTS is not installed on the workstation on which you are unpacking LAN CID Utility, you must copy the PKUNZIP2.EXE program from the root directory of MPTS diskette 1 into a directory that is in the current PATH. The files unpacked into the \IMG\LCU directory are: CASAGENT.EXE The program that determines which .CMD file to run on the client. CASAGENT.DLL The dynamic link library for LAN CID Utility command files. CASINSTL.EXE The program for installing LAN CID Utility on a client. CASDELET.EXE The program for deleting LAN CID Utility from a client. CASSKEL.CMD A sample command file (skeleton). CASCKREX.CMD The command file for determining if REXX has been initialized on the target workstation. GETBOOT.CMD The command file for getting the SETBOOT and XCOPY program files. GETFIX.CMD The command file for getting the OS/2 2.x installation fixes. GETOSCID.CMD The command file for getting the OS/2 2.x redirected installation modules. GETREXX.CMD The command file for getting the required REXX files. SRVREXX.EXE The program used to initialize REXX on the client. CAS.MSG The LAN CID Utility message file. CASH.MSG The LAN CID Utility message help file. CASSAMP1.CMD A sample command file. CASSAMP2.CMD A sample command file. SYSLEVEL.LCU The LAN CID utility syslevel file. ═══ 7.3. Loading the SRVIFS Images ═══ SRVIFS is located on MPTS diskette 3. The SRVIFS files are packed in a file called SRVIFS.ZIP in the \SRVIFS directory on MPTS diskette 3. In order to unpack the SRVIFS files into the desired directory, insert MPTS diskette 3 into drive A: on the code server and issue the following command: PKUNZIP2 A:\SRVIFS\SRVIFS.ZIP \IMG\SRVIFS Note: If MPTS is not installed on the workstation on which you are unpacking LAN CID Utility, you must copy the PKUNZIP2.EXE program from the root directory of MPTS diskette 1 into a directory that is in the current PATH. The files unpacked into the \IMG\SRVIFS directory are: THINIFS.EXE The program for installing SRVIFS on the client. IFSDEL.EXE The program for deleting SRVIFS from the client. THINSRV.EXE The program for installing SRVIFS on the code server. SERVICE.EXE The program for starting a SRVIFS server. SRVIFS.SYS The device driver for the client. SRVIFSC.IFS The installable file system driver for the client. SRVATTCH.EXE The program for attaching to a SRVIFS server. XI1.MSG The SRVIFS messages file. XI1H.MSG The SRVIFS message help file. SYSLEVEL.SIF The SRVIFS syslevel file. ═══ 7.4. Loading the LAPS Images ═══ LAPS is located on MPTS diskettes 1 and 2. LAPS provides a utility for copying its files because they are in a specific directory structure on the diskette that needs to be preserved on the code server. In order to copy the LAPS files to the code server, insert the MPTS diskette 1 into drive A: and issue the following command: A:\LAPSDISK A: \IMG\LAPS For more information, see the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide. ═══ 7.5. Obtaining the Required OS/2 2.x Files ═══ Note: The steps presented in this chapter for obtaining OS/2 files are only valid for versions of OS/2 that do not document how to set up the code server. If the version of OS/2 you intend to load on the code server has a file called README.CID on the OS/2 installation diskette, follow the directions in the README.CID file instead of the remaining directions in this chapter. Two methods are available for obtaining the OS/2 2.x files that LAN CID Utility requires for installing CID-enabled programs. o The first method is copying the files from a workstation that has the OS/2 2.0 program or higher installed. This may or may not be the code server. If you want to use this method, but the code server does not have the OS/2 2.0 program or higher installed, you must copy the files from a workstation running the OS/2 2.0 program or higher to the code server. o The second method of obtaining the required files is to use programs provided by LAN CID Utility to unpack the files from the OS/2 2.x images on the code server. For more information on these programs provided by LAN CID Utility, see GETBOOT and GETREXX. ═══ 7.5.1. OS/2 2.x Diskettes and Files Required by LAN CID Utility ═══ The OS/2 2.x diskettes and files that are required by LAN CID Utility are the following: o The diskettes and files required to build boot diskettes: - OS/2 2.x Installation diskette - OS/2 2.x diskette 1 - OS/2 2.x diskette 4 - UNPACK*.EXE from diskette 2 - SEDISK.EXE from the CID pack file on diskette 7 (diskette 8 in some double-byte character set (DBCS) countries). o REXX files o SETBOOT.EXE o XCOPY.EXE. ═══ 7.5.2. Loading the OS/2 2.x Images If Needed ═══ If the client workstations do not have the OS/2 2.x program already installed, you can install it with redirection. To do this, you need to load the OS/2 2.x product images on the code server and unpack some utilities. However, if you plan to install OS/2 2.x on clients using LAN CID Utility, perform the steps in Loading the OS/2 2.x Program on the Code Server, before continuing with this task. The reason is that if you load the OS/2 2.x images on the code server now, it is easier to obtain some of the OS/2 2.x files required by LAN CID Utility. Note: If the OS/2 2.x program is not installed on any available workstation including the code server, you either have to install the OS/2 2.x program onto an available workstation with diskettes, or perform the steps in Loading the OS/2 2.x Program on the Code Server, before continuing with this section. ═══ 7.5.3. Obtaining the Files for Building Boot Diskettes ═══ Before you can build boot diskettes for redirected installations started by diskettes, you must obtain the OS/2 2.x modules required for building the boot diskettes. This procedure is necessary only if you do not want to install the OS/2 2.x program on client workstations with LAN CID Utility. Thus, if you have already performed the steps in Loading the OS/2 2.x Program on the Code Server, you do not need to get these files again. Use the following steps to get the files needed for creating boot diskettes: 1. Insert the OS/2 2.x Installation diskette into drive A: and issue the following command: XCOPY A:\ \OS2V20\DISK_0\ 2. Insert the OS/2 2.x diskette 1 into drive A: and issue the following command: XCOPY A:\ \OS2V20\DISK_1\ 3. Insert the OS/2 2.x diskette 4 into drive A: and issue the following command: XCOPY A:\ \OS2V20\DISK_4\ 4. Insert the OS/2 2.x diskette 2 into drive A: and issue the following commands: COPY A:\UHPFS.DLL \OS2V20\DISK_0\ COPY A:\UNPACK*.EXE \EXE\V200 5. Insert OS/2 2.x diskette 7 (diskette 8 in some DBCS countries) into drive A: and issue the following command from the \EXE\V2xx directory: UNPACK A:\CID \EXE\V200 /N:SEDISK.EXE ═══ 7.5.4. Obtaining the Required REXX Files ═══ Because the LAN CID Utility command files are written in REXX, the files required to interpret and run a REXX program must be available to the client workstation before the OS/2 2.x program is installed on the client. The REXX files must be the same version as OS/2 program being installed. Note: On workstations running the OS/2 2.x program, the REXX files were included as an installation option unless it was explicitly specified not to install them. If you plan to copy the REXX files from a workstation, ensure that the REXX files were installed before you attempt to copy them. Because the files that are required to interpret and run a REXX program are too large to fit on the boot diskettes, the files must be accessed from the code server. However, if the code server is not running OS/2 2.x, do not access the REXX files that are currently in use on the code server. Instead, obtain the required REXX modules in one of the following ways: o Copy the REXX files into the \DLL\V2xx directory on the code server. If you have access to a workstation or code server running OS/2 2.x, you can manually copy the REXX files by issuing the following commands: COPY \OS2\DLL\*REX*.DLL \DLL\V200 COPY \OS2\SYSTEM\*REX*.MSG \DLL\V200 o Use the GETREXX program provided with LAN CID Utility. LAN CID Utility provides a program named GETREXX.CMD, which unpacks the required REXX files from the OS/2 2.x product images and places them in the \DLL\V2xx subdirectory on the code server. From there, the client can access them. Before using GETREXX.CMD, ensure that the OS/2 2.x product images are already loaded on the code server. Following is an example of how to use GETREXX: GETREXX \IMG\OS2V20 \DLL\V200 For details of this command, see GETREXX. ═══ 7.5.5. Obtaining SETBOOT.EXE and XCOPY.EXE ═══ To control the installation process, LAN CID Utility must be able to reboot the client workstation when it is appropriate. To do this, LAN CID Utility uses the OS/2 program, SETBOOT. SETBOOT must be available to the client system that is running LAN CID Utility. Obtain SETBOOT in one of the following ways: o Copy SETBOOT into the \EXE\V2xx directory on the code server. If you have access to a workstation or code server running OS/2 2.x, you can manually copy the SETBOOT files by issuing the following commands: COPY \OS2\SETBOOT.EXE \EXE\V200 COPY \OS2\XCOPY.EXE \EXE\V200 o Use the GETBOOT program provided with LAN CID Utility. In order to ensure that SETBOOT and XCOPY are available, LAN CID Utility provides a utility called GETBOOT.CMD, which unpacks the SETBOOT and XCOPY modules from the OS/2 2.x product images and places them in the \EXE\V2xx subdirectory on the code server. Following is an example of how to use GETBOOT: GETBOOT \IMG\OS2V20 \EXE\V200 See GETBOOT for details on running this utility. ═══ 7.5.6. Loading the OS/2 2.x Service Pak Images If Needed ═══ Skip this step if you have already performed the tasks in Loading the OS/2 2.x Program on the Code Server. You may need Service Pak fixes for the OS/2 2.x files that LAN CID Utility requires. Read and follow the steps in Determining If a Service Pak Is to Be Used to determine if you uses a Service Pak. If you uses a Service Pak, first follow the procedures in Loading the OS/2 Service Pak Product Images and then follow the procedures in Obtaining OS/2 2.x CID Module Service Pak Fixes. If you do not plan to install the Service Pak that was copied to the code server fixed disk onto client workstations using LAN CID Utility, you can erase the Service Pak files in \CSD\OS2V20\CSD1 because they are no longer needed. ═══ 8. Loading Product Images on the Code Server ═══ This chapter explains how and where to load the product images for CID-enabled programs. This chapter assumes that you plan to use the recommended directory structure, as illustrated in Recommended Directory Structure. Note: The term images in this book refers to the files and directories used to store a product on the code server. ═══ 8.1. Where to Load Product Images ═══ If you followed the recommended directory structure, load each set of product images into the \IMG\product subdirectory for that specific product, where product is a user-defined name. For example, with LAPSDISK, a utility provided with the MPTS program, you can specify \IMG\LAPS as the target directory. LAPSDISK then loads all the product images for MPTS LAPS from the diskettes into the \IMG\LAPS subdirectory on the code server. From there, you can install the MPTS LAPS program onto the clients with redirection, as described in Redirected Installation of Products on the Client. ═══ 8.2. How to Load Product Images ═══ To install a product on the client with redirection, you must first load the product images into a subdirectory on the code server. Each CID-enabled product can have its own command for loading the images. For example, the LAPSDISK command loads the product images for the MPTS LAPS program. Some CID-enabled products may use the COPY or XCOPY command to transfer the product images from the product diskettes to the code server. Note: The OS/2 2.x product images cannot be loaded on the code server until the SEIMAGE program is available. See Loading the OS/2 2.x Product Images for more information. ═══ 9. Loading the OS/2 2.x Program on the Code Server ═══ This chapter explains how to load the OS/2 2.x program on the code server for redirected installation on client workstations. The OS/2 2.x program is different from most CID-enabled programs, because it requires that the redirected installation modules be unpacked from the installation diskettes before they can be used. Also, a Service Pak may be required in order to use LAN CID Utility to install the OS/2 2.x program on client workstations. Note: 1. This book is supplemented by the MPTS README.UTL file on MPTS diskette 3. Ensure that you read this file. The code server setup information in the README is also presented in this book for your convenience. See The CASSETUP Code Server Setup Utility. 2. The steps presented in this chapter are valid only for versions of OS/2 that do not document how to set up the code server. If the version of OS/2 you intend to load on the code server has a file called README.CID on the OS/2 installation diskette, follow the directions in the README.CID file instead of the directions in this chapter. ═══ 9.1. Overview ═══ The following shows the steps required in loading the OS/2 2.x program on the code server for redirected installation onto client workstations. Following the steps are the detailed instructions that you should use when you are ready to load the OS/2 2.x program on the code server. 1. Determine if a Service Pak is to be used. If SYSLEVEL.OS2 on diskette 1 indicates version XR02000_XR00000, a Service Pak is required for the redirected installation modules. If you have a Service Pak for the version of OS/2 that you intend to install, it is recommended you that use the Service Pak version of the redirected installation modules. 2. Load the OS/2 2.x product images on the code server. a. Obtain UNPACK*.EXE from diskette 2. b. Unpack SEIMAGE.EXE from the file named CID on diskette 7 (diskette 8 in some DBCS countries). c. Run SEIMAGE to copy the OS/2 2.x diskettes to the code server. 3. Retrieve the OS/2 2.x redirected installation modules from the product images on the code server. Run the GETOSCID program provided with LAN CID Utility. 4. If a Service Pak is to be used, load the OS/2 2.x Service Pak product images on the code server. XCOPY the Service Pak diskettes to the code server. 5. If a Service Pak is to be used, get the modified versions of the OS/2 2.x redirected installation modules from the copy of the Service Pak on the code server. Run the GETFIX program provided with LAN CID Utility. ═══ 9.2. Determining If a Service Pak Is to Be Used ═══ You can use redirected installation only with the 2.0 or later version of the OS/2 program. Some versions of the OS/2 program do not successfully install with redirection unless you provide fixes for the redirected installation modules. To determine if a Service Pak is required for the version of OS/2 2.x you plan to install, use the following procedure: 1. Insert the OS/2 2.x diskette 1 into drive A: and issue the following command: TYPE A:\SYSLEVEL.OS2 2. Scan the output on the screen from the previous command and find the string that matches the form: XRxxxxx_XRxxxxx where xxxxx is a string of numbers 0 through 9. The first part of the string is the Current CSD level; the second part of the string is the Prior CSD level. 3. If the current CSD level indicates XR02000, an OS/2 2.0 Service Pak Version 2.00 or higher is required for the redirected installation modules. It is also recommended that this Service Pak be installed on client workstations before you use LAN CID Utility to install other applications. If this is not done, folders and icons may be missing from your desktop following remote installation of applications. The instructions for the redirected installation of Service Paks are documented in Automated Installation for CID Enabled OS/2 V2.0. If you have a Service Pak for the version of OS/2 that you intend to install, it is recommended you that use the Service Pak version of the redirected installation modules even if you determine by the steps previously described that a Service Pak is not required. See the README.UTL file on the MPTS diskette3 for the latest information on restrictions and Service Pak requirements. In addition, you should consult documentation provided with the products you plan to install for their operating system and Service Pak requirements. ═══ 9.3. Loading the OS/2 2.x Product Images ═══ The program that loads the OS/2 2.x product images onto the code server is packed into a file named CID on diskette 7 (diskette 8 in some DBCS countries). The following steps are required to unpack this program from the CID pack file and to run it: 1. Obtain UNPACK*.EXE from the OS/2 2.x diskette 2. Insert diskette 2 into drive A: and issue the following command: COPY A:\UNPACK*.EXE \EXE\V200 2. Unpack SEIMAGE.EXE from CID on OS/2 2.x diskette 7 (diskette 8 in some DBCS countries). Insert diskette 7 (diskette 8 in some DBCS countries) into drive A: and issue the following command from the \EXE\V2xx directory: UNPACK A:\CID \EXE\V200 /N:SEIMAGE.EXE 3. Run SEIMAGE to copy the OS/2 2.x diskettes to the code server. a. If you determined that an OS/2 2.x Service Pak will not be used in Determining If a Service Pak Is to Be Used, skip this step. Also, if a Service Pak will be used but no replacement diskettes were shipped with the Service Pak, skip to step Loading the OS/2 2.x Product Images. Otherwise, for each replacement diskette, take the corresponding diskette out of the OS/2 2.x set of diskettes and replace it with the diskette shipped with the Service Pak. b. Issue the following command to copy the OS/2 2.x diskettes to the code server: \EXE\V200\SEIMAGE /S:A: /T:\IMG\OS2V20 All of the OS/2 2.x diskettes will be loaded in order with a prompt for each. ═══ 9.4. Obtaining the OS/2 2.x Redirected Installation Modules ═══ The programs and files that are required for the redirected installation of the OS/2 2.x program are packed in files on the diskettes that were copied to the code server in Loading the OS/2 2.x Product Images. The following OS/2 2.x modules are required for redirected installation of the OS/2 2.x program: o RSPINST.EXE o SAMPLE.RSP o SEDISK.EXE o SEIMAGE.EXE o SEINST.EXE o SEMAINT.EXE You can obtain these modules with the GETOSCID program, a utility provided with LAN CID Utility, that scans the OS/2 2.x packed images on the code server's fixed disk for the files that are needed. GETOSCID is copied to the code server's fixed disk as described in Loading the LAN CID Utility Images. Issue the following commands to unpack the OS/2 2.x redirected installation modules and to place SAMPLE.RSP in the correct directory: \IMG\LCU\GETOSCID \IMG\OS2V20 \EXE\V200 MOVE drive and path\EXE\V200\SAMPLE.RSP \RSP\OS2V20 Note: You can specify the drive only for the source on the MOVE command. If the \EXE\V200 and \RSP directories are on different drives, use the XCOPY command. ═══ 9.5. Loading the OS/2 Service Pak Product Images ═══ If you determined that an OS/2 2.x Service Pak will be used in Determining If a Service Pak Is to Be Used, you must copy the Service Pak product images to the code server. Use the following procedure: 1. Insert the first Service Pak diskette in drive A: and issue the following command for it and for each subsequent Service Pak diskette: XCOPY A: \CSD\OS2V20\CSD1 /S 2. Use the following steps for replacement diskettes that may have been shipped with the Service Pak: a. If no replacement diskettes were shipped with this Service Pak, skip all of step Loading the OS/2 Service Pak Product Images. b. If you already replaced the OS/2 2.x diskettes with the replacement diskettes and copied them with SEIMAGE in Loading the OS/2 2.x Product Images, skip all of step Loading the OS/2 Service Pak Product Images. c. If you have replacement diskettes that you have not copied, for each replacement diskette, insert the diskette into drive A: and issue the following command: XCOPY A:\ \IMG\OS2V20\DISK_n Where n is the number of the replacement diskette. For example, if the diskette is a replacement for diskette 3, the command is: XCOPY A:\ \IMG\OS2V20\DISK_3 ═══ 9.6. Obtaining OS/2 2.x CID Module Service Pak Fixes ═══ If you determined that an OS/2 2.x Service Pak will be used in Determining If a Service Pak Is to Be Used, you must unpack the fixes for the OS/2 2.x redirected installation modules shipped with the Service Pak to the code server. You can obtain these modules with GETFIX, a program provided with LAN CID Utility. GETFIX unpacks the required modules from the Service Pak on the code server's fixed disk if the modules are located there. Some redirected installation modules may not require a Service Pak fix. To copy GETFIX to the code server's fixed disk, see Loading the LAN CID Utility Images. To copy the Service Pak to the code server's fixed disk, see Loading the OS/2 Service Pak Product Images. To obtain the Service Pak fixes for OS/2 2.x redirected installation modules, issue the following command: \IMG\LCU\GETFIX \CSD\OS2V20\CSD1 \EXE\V200 For more information, see GETFIX. Note: If SAMPLE.RSP was shipped with the Service Pak, this file will be unpacked into the \EXE\V200 directory. Check for this file in the \EXE\V200 directory and, if it exists, copy it to the OS/2 2.x response file directory (\RSP\OS2V20) so that you can find it later. ═══ 10. Installing SRVIFS on the Code Server ═══ This chapter provides information on the following: o NetBIOS resources required before you can install SRVIFS o A sample SRVIFS configuration file that you can modify in order to configure the code server on which SRVIFS is being installed o The keyword=value pairs in the SRVIFS configuration file o A sample SRVIFS authorization list file, an optional file that you can modify to authorize specific clients for access to the SRVIFS server o The THINSRV program (THINSRV.EXE) o The server program (SERVICE.EXE). Note: You must create a configuration file or modify the sample SRVIFS configuration file before you can install SRVIFS on the server. If you plan to use authorization, you must create an authorization list file or modify the sample SRVIFS authorization list file before you can install SRVIFS on the server. ═══ 10.1. Configuring NetBIOS Resources before Installing SRVIFS ═══ You must have the LAN Adapter and Protocol Support (LAPS) component of MPTS installed before proceeding with the installation of SRVIFS. See the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide for instructions on installing and configuring LAPS. SRVIFS is a NetBIOS application and requires an appropriately configured LAN transport subsystem for NetBIOS before you can use SRVIFS. Since SRVIFS is a NetBIOS application, if there are other NetBIOS applications on the same workstation, you must calculate the total NetBIOS resource requirements to configure in the PROTOCOL.INI file in the \IBMCOM subdirectory. For a SRVIFS server, the NetBIOS resources that must be available are: Number of Sessions = MaxClients Number of Commands = Number of LAN adapters used by server * (number of ClientWorkers + 10) Number of Names = 1 See Keyword=Value Descriptions for the SRVIFS Configuration File for an explanation of MaxClients and ClientWorkers. ═══ 10.1.1. NetBIOS Resources for Multiple SRVIFS Servers on the Same Workstation ═══ To configure NetBIOS resources for multiple SRVIFS server, use the following values: Number of Sessions = Sum of MaxClients of all SRVIFS configuration (.INI) files Number of Commands = n * ((sum of number of ClientWorkers of all servers installed) + 10 * number of servers) Number of Names = Number of servers installed if unique names are used Note: In this example, n in the Number of Commands formula refers to the number of LAN adapters used by the server, up to a maximum of 2. If you are running SRVIFS on the OS/2 Extended Edition 1.3 program, you must also configure 802.2 protocol for link stations: o For one SRVIFS server, use the following value: Link Stations = MaxClients o For multiple SRVIFS servers, use the following value: Link Stations = Sum of MaxClients of all SRVIFS configuration (.INI) files. See Multiple SRVIFS Servers for more information. ═══ 10.2. The SERVICE.INI SRVIFS Configuration File ═══ This configuration file is the SRVIFS response file used to configure the code server on which SRVIFS is being installed. This file, named SERVICE.INI, is an ASCII file that contains keyword=value pairs. It is required to have an extension of .INI and, by convention, it is called the SRVIFS configuration (.INI) file. The SRVIFS configuration (.INI) file contains the following keyword=value pairs that you can set: o Name o GroupName o Adapter o MaxClients o MaxFiles o ClientWorkers o Authlist o Path o PermitWrite o PerClient o Alias ═══ 10.3. Sample SERVICE.INI SRVIFS Configuration File ═══ The sample SRVIFS configuration file, named SERVICE.INI, is located in the SAMPLE.ZIP pack file in the \SAMPLE directory on MPTS diskette 3. To obtain this file, insert MPTS diskette 3 in drive A: and run the following command: PKUNZIP2 A:\SAMPLE\SAMPLE.ZIP \SERVER SAMPLE\SERVICE.INI Note: Copy SERVICE.INI to another file name with an extension of .INI before you begin editing. Use any standard text editor to modify this file. This book uses the configuration file name of SERVER1.INI in the examples. * * SAMPLE SRVIFS CONFIGURATION (.INI) FILE FOR SERVER (SERVICE.INI) ; ! @ # Adapter = 0 MaxClients = 5 MaxFiles = 102 Name = SERVER1 Groupname = No ClientWorkers = 6 Authlist = d:\server\service.lst ; Path = c:\ PerClient = No PermitWrite = Yes ; alias= readonly,single,cid,c:\cid alias= readonly,single,img,c:\cid\img alias= readwrite,perclient,csd,c:\cid\csd ═══ 10.4. Keyword=Value Descriptions for the SRVIFS Configuration File ═══ The .INI file accepts comments. Any line whose first character is one of the following is considered to be a comment: # Pound sign ! Exclamation point @ At sign ; Semicolon * Asterisk The following is a list of the valid keyword=value pairs for a SRVIFS configuration file: Name=netbname Specifies the 1- to 15-character alphanumeric NetBIOS name that this server is to be known by on the network. This keyword and value are required. Note: SRVIFS does not follow the NetBIOS naming convention. Therefore, the SRVIFS server name should be alphanumeric even though it is a NetBIOS name. GroupName = { Yes | No } Specifies whether the server NetBIOS name is a group name or a unique name. If set to No, this name must be unique on your logical LAN network. The Yes value provides for multiple servers with the same name, which allows more than one server to provide the same service. A client attempting to connect to a server with this name will connect to the first server that responds. The servers should provide the same services or else the end result for the client is unpredictable. This keyword and value are required. Adapter = { 0 | 1 | Both } Specifies the adapter to be used by the SRVIFS server program. If not specified, the default is 0. This keyword and value are optional. MaxClients = nnn Specifies the maximum number of clients that are allowed to concurrently connect to this server per adapter. Valid values are 1 through 100. If Adapter=Both is specified, this value applies to both adapters. The default value is 1. This keyword and value are optional. MaxFiles = nnnn Specifies the maximum number of files that the server may have open concurrently. The default is 100; the maximum is 9999. This value should be at least as large as the number of concurrent clients that are expected to attach. In some cases, a single client may have more than one file open at a time, in which case you may want to specify a value equivalent to 3 to 4 files per client. This keyword and value are optional. ClientWorkers = nn Defines the number of threads used to support workstation requests. Valid values are 2 through 12. The default is 6. For small networks, a value of 6 is recommended. For larger networks (20 or more concurrent clients), a value of 12 is recommended. This keyword and value are optional. Authlist = drive:\path\filename Specifies a file containing a list of authorized clients that are allowed to access this server. Note: drive and path are required values if you use the Authlist keyword. If you plan to use an authorization list file, give it a name and see The SRVIFS Authorization List File. This file is an ASCII file with one requester NetBIOS name per line. All comment markers described previously are acceptable. Comments are allowed following the requester name, which must be 1 through 8 characters long and followed by at least 1 space. If the comment is on the same line as a client name, the comment indicator (#,@,!,;,*) is not required. For each requester, the name can optionally be followed by a LAN adapter address. Use of the adapter address feature can restrict a particular client to a specific workstation. This feature provides an additional layer of security. This address checking is performed on a per-client basis. This means that some entries could have the address specified while others do not, though this limits the effectiveness of the additional layer of security. In order to specify a LAN address associated with a particular NetBIOS name, the address should be separated from the NetBIOS name by a period (.). No other characters, including spaces, can be used. If the file cannot be found, an error message is displayed and the server does not start. This keyword and value are optional. Path = drive:\path Specifies the single drive:\path that appears as the root of the attached drive to the client workstations. For example, this path could be D:\ or D:\CID This string does not contain a trailing backslash except for the root directory of a specific drive, for example: D:\ This is the drive and path that a SRVATTCH statement attaches to when it contains only the server name without an alias. An example of this type of statement is: SRVATTCH X: SERVER1 This keyword and value are required. PermitWrite = { Yes | No } Specifies whether the drive and path in the path statement can be accessed in ReadWrite or ReadOnly mode. The default value is Yes (ReadWrite). This keyword and value are required. PerClient = { Yes | No } If this feature is enabled, a subdirectory descendant from the Path= directory is used for each client. The subdirectory name is the client name. If this client-name subdirectory does not exist, it is created. This action provides what is called client discovery. The date and time on the directory entry can be used to determine when the client first attached to the server. This feature can be used to gain access to workstation-specific files. An example follows: If you have the following path Server Path=D:\CID and the following clients in an authorization list file REQ1 REQ2 REQ3 and you set PerClient=Yes SRVIFS creates the following subdirectories: D:\CID \REQ1 (files for REQ1) \REQ2 (files for REQ2) \REQ3 (files for REQ3). However, if you set PerClient=No SRVIFS does not create subdirectories. It creates the client files under the D:\CID subdirectory: D:\CID (files for REQ1, REQ2, and REQ3) This keyword and value are required. Alias = read_type,access_type,alias_name,alias_path This optional keyword=value pair can be used more than once in the same file. You can use different Alias= statements to establish a unique name for each subdirectory tree. The values for the parameters are as follows: read_type Can be either ReadOnly or ReadWrite and specifies whether clients can write to the subdirectories represented by this alias. This value is independent of the PermitWrite keyword and is not affected by it. This read_type value applies only to this particular alias. access_type Can be specified as Single or PerClient. This determines whether the subdirectory being referenced is the shared resource or, if PerClient is specified, whether unique subdirectories are created or used. The unique subdirectories would have the name of the client and would be located below the subdirectory defined by this alias. See the PerClient keyword for examples. This value is independent of the PermitWrite keyword and is not affected by it. This access_type value applies only to this particular alias. alias_name Specifies the alias by which this subdirectory is to be accessed by the clients. alias_path Specifies the fully qualified drive and path that is to be represented by this alias. The alias_path value can be on a different drive than that specified in the Path= value. Note: This path (drive and subdirectory) must exist on the server or the server fails to initialize. This keyword and value are optional. ═══ 10.5. The SRVIFS Authorization List File ═══ The authorization list file is an ASCII file that contains information for SRVIFS about the clients that are allowed access to the server. This file is specified in the SERVICE.INI configuration file as the parameter value of the Authlist keyword. Since using an authorization file is optional, the Authlist keyword is an optional parameter. Use any standard text editor to modify this file or to create your own authorization list file. The authorization list file is a list of client names, one on each line. You can set different types of access, depending on whether you include an authorization list file in the SRVIFS.INI configuration file and, if so, how you specify the client name in that authorization list file. Following are the ways in which you can specify client access: o Not specifying an authorization list file in the SRVIFS configuration (.INI) file. This allows unrestricted client access. o Specifying an empty authorization list file in the SRVIFS configuration (.INI) file. An empty file contains only comments and no client names. This allows unrestricted client access. o Specifying the client NetBIOS name in the authorization list file. This allows the specified client to access the server from any system. The client name must be the NetBIOS name for the client. An example is: SRVREQ where SRVREQ is the client name. o Specifying the client NetBIOS name and its universally administered address (UAA) in the authorization list file. This allows the client to access the server only if it uses the specific NetBIOS name and the adapter that matches the UAA address. An example is: SRVREQ.10005A265C73 where SRVREQ is the client NetBIOS name and 10005A265C73 is the UAA of the system from which the client can gain access to the server. o Specifying *.UAA in the authorization list file. This allows any user to access the server from the client that has the specified UAA. An example is: *.10005A265C73 This specifies that any user can access the server but only from the client workstation that has the 10005A265C73 UAA. Note: A locally administered address (LAA) is not supported in the authorization list file. ═══ 10.6. Sample SRVIFS Authorization List File ═══ Following is a sample authorization list file named SERVICE.LST. Use of this file is optional. * * This is a sample authorization list file for the service.ini file. * This file should have one requester name per line. The requester * name should be 1 to 8 characters long followed by at least 1 space. * For each requester, the name may optionally be followed by a * Universally Administered address of the LAN adapter. This optional * feature provides an additional layer of security. * client1 client2 client3.10005a882805 SERVICE.LST can be found in the SAMPLE.ZIP pack file in the \SAMPLE directory on MPTS diskette 3. To obtain this file, insert MPTS diskette 3 in drive A: and run the following command: PKUNZIP2 A:\SAMPLE\SAMPLE.ZIP \SERVER SAMPLE\SERVICE.LST ═══ 10.7. Using THINSRV to Install the SRVIFS Server ═══ Use the THINSRV command to install the files required for a SRVIFS server. THINSRV adds a statement to STARTUP.CMD to start the SRVIFS server automatically the next time the system is rebooted. Following is an example of using the THINSRV command: D:\CID\IMG\SRVIFS\THINSRV /S:D:\CID\IMG\SRVIFS /T:D:\SERVER /R:D:\SERVER\SERVER1.INI /U:D:\SERVER\SERVER1.LST See THINSRV for details of the syntax and parameters. Also, see Multiple SRVIFS Servers if you need more than one SRVIFS server. Note: Since the SRVIFS server does not require DEVICE= or IFS= statements in the CONFIG.SYS file, you do not have to reboot the system. You can start the SRVIFS server manually with the SERVICE command. ═══ 10.8. Starting the SRVIFS Server ═══ After installation, you can start the SRVIFS server in one of two ways: o Shut down and reboot the system. The SRVIFS server starts automatically because the THINSRV command places a start statement in STARTUP.CMD. o Change to the directory where SRVIFS is installed without rebooting and use the SERVICE command. You can also stop, restart, or get status on the server by using the SERVICE command. See SERVICE for details of the syntax and parameters. ═══ 11. Creating and Using Response Files ═══ Note: This book is supplemented by the MPTS README.UTL file on MPTS diskette 3. Ensure that you read this file. The code server setup information in the README is also presented in this book for your convenience. See The CASSETUP Code Server Setup Utility. This chapter defines a response file and shows how to create and use response files with LAN CID Utility. ═══ 11.1. Definition of a Response File ═══ A response file is an ASCII file that supplies the client-specific configuration information required during redirected installation of a product on the client. The response file contains predefined answers to the configuration questions that users are normally asked during a product installation, such as the domain name and the number of sessions to configure for LAN Server 4.0. Response files commonly have an extension of .RSP and are found in the \RSP directory. Examples of products that use a response file include the MPTS LAPS installation program (MPTS) and the SRVIFS server installation program (THINSRV). A response file contains pairs of keywords and values that are interpreted during a product installation. Usually, these keyword=value pairs are unique to a particular product but not necessarily unique to a particular client. For example, to cut down on the number of response files you must create, use, and maintain, you can create a general or group response file that contains all the common responses for a set of similar clients. You can account for the client-specific differences, such as the workstation ID, by creating a specific response file, which contains such unique values. You can then specify the INCLUDE keyword in the specific response file and set the value to the name of the separate file containing the common responses. Not all products support the use of a response file. If the product you are installing does, the response file makes it unnecessary for you to sit at each client and manually enter an answer to each question that is displayed during installation. A response file is not invoked directly. Instead, a response file is specified as a parameter value for an installation program. The installation command can be defined in the LAN CID Utility REXX command file. The response file directs the processing of the installation for a particular product. See Creating LAN CID Utility REXX Command Files, for more information. ═══ 11.1.1. Sources of Information for Response Files ═══ Note: The IBM LAN NetView Start User's Guidecontains information on using the IBM LAN NetView Start tool to maintain configuration of LANs and to generate response files. If the products you are installing use response files, you can get information for the response files from one or more of the following sources: o A sample response file shipped on the product diskettes. You can tailor this file, which is also known as a default or a model response file, to reflect the specific set of keyword=value pairs that you want to assign to a client or a group of clients. See Sample Response File or A Sample Response File for an example of an OS/2 2.0 response file. o A record of your answers to configuration questions asked while you are installing a product. Some products provide a way to capture the entries you make on the panels that are displayed during configuration and installation. o An extract from files that contain existing configuration information. An extract is similar to a record, but you retrieve this information after an installation instead of capturing it during an installation. Note: For information on using response files and the record and extract functions, see the documentation for the products you plan to install with redirection. The following table lists some of the OS/2 2.x products you may plan to install and shows the sources of information that are available for the product response files: ┌──────────────────────────────────────────────────────────┐ │ Table 2. Sources of Response File Information │ ├───────────────────┬────────────┬────────────┬────────────┤ │ OS/2 2.X PRODUCT │ SAMPLE │ RECORD │ EXTRACT │ ├───────────────────┼────────────┼────────────┼────────────┤ │ OS/2 2.x │ X │ X │ │ ├───────────────────┼────────────┼────────────┼────────────┤ │ LAN Server 4.0 │ X │ X │ │ ├───────────────────┼────────────┼────────────┼────────────┤ │ Extended Services │ X │ │ X │ │ │ │ │ │ ├───────────────────┼────────────┼────────────┼────────────┤ │ LAPS │ X │ │ X │ ├───────────────────┴────────────┴────────────┴────────────┤ │ NOTE: For some products, the keyword=value pairs that │ │ are valid in a particular version can be migrated to │ │ future versions. │ └──────────────────────────────────────────────────────────┘ ═══ 11.1.2. Response File Hierarchy ═══ A response file can contain included, or nested, response files, in which keyword=value pairs may conflict with pairs in the main file. These conflicts, such as missing or incomplete keyword=value pairs and duplicate keywords set to different values, are resolved by rules governing the order in which these pairs are interpreted. This hierarchy ensures consistent interpretation, processing, and implementation, both among multiple response files and within a single response file. ═══ 11.1.2.1. Source Precedence Rules for Response File Parameters ═══ Note: For the way in which the OS/2 2.x program follows precedence rules, see the OS/2 2.x documentation. A description of precedence rules, where highest has precedence, follows: o The product default is used only when there is no existing value to migrate and no keyword=value pair exists in any response file referenced. o The migration value is used only when there is no keyword=value pair existing in any response file being processed. o The included response file keyword=value pair overrides a prior matching keyword=value pair existing in the including response file. This pertains to included response files which are nested to any level and the specific response file (first including file) which functions as the root response file. The purpose of included response files is to provide a general response file specification that can apply to more than one workstation. Physical placement of an INCLUDE= keyword in the specific or any other general response file determines the merged response file definition. ┌──────────────────────────────────────────────────────────────────────────────┐ │ Table 3. Response File Hierarchy │ ├─────────────────┬────────────────────────────────────────────────────────────┤ │ PRECEDENCE │ VALUE │ ├─────────────────┼────────────────────────────────────────────────────────────┤ │ Highest │ Specific response file and included response files │ ├─────────────────┼────────────────────────────────────────────────────────────┤ │ │ Migration of existing values │ ├─────────────────┼────────────────────────────────────────────────────────────┤ │ Lowest │ Product default │ └─────────────────┴────────────────────────────────────────────────────────────┘ ═══ 11.1.2.2. Precedence Rules within a Single Response File ═══ The following list describes the precedence of interpretation within a single response file in highest to lowest priority: 1. When a product supports only a single keyword=value pair for a particular setting, the last pair in the response file is used if there are duplicate keywords set to different values. 2. When a product supports more than one keyword=value pair for a particular setting, the pairs are interpreted on an individual basis and are unrelated to each other. 3. Keywords with a missing value (keyword= ) are interpreted in one of three ways: a. The product uses the product default for the missing value if a default is provided. b. The product accepts a null value if null is specified as acceptable and if the null value does not create an ambiguity or a conflict with a product default value. c. The product treats the missing value as an error. 4. If a required keyword=value pair is not present in the response file, the product searches for the pair in other response files, following the precedence rules outlined in Source Precedence Rules for Response File Parameters. For more on response files, see Automated Installation for CID Enabled OS/2 V 2.0. ═══ 11.2. Creating a Response File ═══ You can create response files for the various products you plan to install by using one of the following: o A recording or extraction utility supplied with a product. However, not all products provide a utility to create or modify the response file. o Any text editor for manually creating a response file or modifying a sample response file provided with the product. For example, to install the SRVIFS server, you must have a SRVIFS configuration file before you start. This configuration file is the response file for SRVIFS. Although SRVIFS does not provide a utility to create the configuration file, it gives you a sample configuration file (SERVICE.INI) to start with. See Installing SRVIFS on the Code Server, for details. For other products, refer to the product documentation for: o Details on whether the product being installed uses a response file and, if so, how to modify a sample response file or create one manually. o Details on the specific format of response files. ═══ 11.3. Using Response Files with LAN CID Utility ═══ Note: For an example of using response files with LAN CID Utility, see Engineering Firm Example. To use LAN CID Utility to install a product that requires a response file, you have the following choices: o Create a unique (client-specific) response file. Use a client-specific response file to install the product on an individual client workstation. This file contains unique keyword=value pairs. o Create a default response file. Use the default response file to install the product on a set of similar workstations. o Create both unique and default response files. Use the default response file for as many client installations as possible, and use the unique response file only for selected workstations. Store the response files you create in the \RSP\product directory or a directory separate from the other response files, such as \RSP\product\GENERAL. You can specify for LAN CID Utility to look first for a client-specific response file to use. If LAN CID Utility cannot find a client-specific response file, you can specify for LAN CID Utility to look for and use the default response file. However, LAN CID Utility will not perform these actions if RSPDIR and DEFAULT are set to the null string (''). Note: See Default Response Files and the Response File Subdirectory for more information. ═══ 11.4. Sample Response File ═══ Following is the response file supplied with OS/2 2.1, with one exception. For LAN CID Utility to use this response file, one value was changed from the shipped value. The keyword ExitOnError was changed from the default value (0), which does not cause an exit but displays a panel when an error occurs or when the installation is complete. The panel would require user interaction. In the sample file that follows, ExitOnError was changed to the alternate value (1), which causes an exit and sends a return code to LAN CID Utility. Keyword=value pairs not initially configured in OS/2 2.1 are preceded by an asterisk (*). See A Sample Response File for the documentation that accompanies each keyword=value pair in the sample response file. APM=1 AlternateAdapter=0 BaseFileSystem=1 CDROM=0 CountryCode=001 CountryKeyboard=US DefaultPrinter=0 DiagnosticAids=1 DisplayAdapter=0 Documentation=1 DOSSupport=1 WIN-OS/2Support=1 *WindowedWIN-OS/2=1 *WIN-OS/2Desktop=0 *ExistingWindowsPath= *ShareDesktopConfigFiles=1 DPMI=1 ExitOnError=1 Fonts=1 FormatPartition=0 * Include=include.rsp * IncludeAtEnd=atend.rsp * IncludeInLine=inline.rsp MigrateConfigFiles=1 *MigrateApplications= MoreBitmaps=1 Mouse=1 MousePort=0 OptionalFileSystem=1 OptionalSystemUtilities=1 OS2IniData=/AppName/KeyName/KeyValue/ PCMCIA=1 PrimaryCodePage=1 PrinterPort=1 ProcessEnvironment=1 ProgressIndication=1 RebootRequired=0 REXX=1 SCSI=1 SerialDeviceSupport=1 * SourcePath=D:\os2se20 TargetDrive=C: *WIN-OS/2TargetDrive=C: ToolsAndGames=1 * ConfigSysLine=REM This is a CONFIG.SYS remark line. * Copy=vga c:\ /n:ini.rc * EarlyUserExit=T c:\config.sys * ExtendedInstall=PROGRAM.EXE *ID=OS2SE20 Sample Response File * SeedConfigSysLine=REM This is a remark line in the seed CONFIG.SYS. * UserExit=T.EXE C:\OS2\INSTALL\INSTALL.LOG *Version=OS2SE20 *DDISrc = Z:\DDP *DDIDest = C:\ *DDIDDP = *.DDP ═══ 12. Creating LAN CID Utility REXX Command Files ═══ Note: This book is supplemented by the MPTS README.UTL file on the MPTS diskette 3. Ensure that you read this file. The code server setup information in the README is also presented in this book for your convenience. See The CASSETUP Code Server Setup Utility. This chapter defines command files and shows how to create and use them to install products. In addition, it discusses how to edit the sample REXX command file shipped with LAN CID Utility. See Installation Scenarios, for examples of how command files are used. ═══ 12.1. Definition of a LAN CID Utility REXX Command File ═══ A LAN CID Utility REXX command file is a REXX program that installs products on clients. It calls the RunInstall command, which runs product-specific installation commands such as SEINST to install OS/2 2.x, LANINSTR to install LAN Server 4.0, and CASINSTL to install LAN CID Utility. The command file can also contain commands to delete LAN CID Utility and SRVIFS after installation is complete. If a product you are installing uses a response file, the command file contains the name of the response file and the subdirectory where it is located. For more information, see Creating and Using Response Files. ═══ 12.2. Creating a LAN CID Utility REXX Command File ═══ You can create a command file in the following ways: o Use CASPREP. See The CASPREP Program, Keywords, and Input Files, for more information. o Edit the sample command file, CASSKEL.CMD, shipped with LAN CID Utility. See The Sample LAN CID Utility REXX Command File or A Sample Command File for a listing of this file. Note: Copy CASSKEL.CMD to another file name with an extension of .CMD before you begin editing. The remainder of this chapter focuses on the structure of the shipped command file and shows how to modify it with a text editor. ═══ 12.3. Using REXX Command Files with LAN CID Utility ═══ LAN CID Utility can run two types of command files: o A client-specific command file. LAN CID Utility invokes a client-specific command file to install a unique set of products on one client. o A default command file. LAN CID Utility invokes a default command file to install a common set of products on a number of clients. You have the following choices when creating command files for more than one client: o Create a unique LAN CID Utility command file for each client. For example, create CLIENT1.CMD to install the OS/2 2.1, LAPS, and Communications Manager/2 programs on one client. Create CLIENT2.CMD to install the OS/2 2.1, LAPS, and LAN Server 4.0 programs on another client, and so on. o Create a default LAN CID Utility command file for all clients. For example, create DEFAULT.CMD to install OS/2 2.1, LAPS, and Communications Manager/2 on all clients that require these products. o Create both types. Create a unique command file for each client that requires a unique set of products, and create a default command file for all other clients that require the same set of products. Note: For clients requiring different configuration values, see Using Response Files with LAN CID Utility for more information. When LAN CID Utility runs, it calls the CASAGENT.EXE program to search for a client-specific command file. If LAN CID Utility cannot find a client-specific command file, LAN CID Utility uses a default command file. If LAN CID Utility cannot find either a client-specific or a default command file, CASAGENT.EXE exits and the installation ends. See CASINSTL for more information. Note: To use a default command file, you must specify the /D or /D: on CASINSTL when creating boot diskettes or when creating an LAN CID Utility default command file. Refer to the definitions of the CASINSTL /D and /D: parameters on Loading the LAN CID Utility Images for more information. The command files are located in the \CLIENT subdirectory in the recommended directory structure. ═══ 12.4. LAN CID Utility REXX Command File Structure ═══ LAN CID Utility ships a sample command file, CASSKEL.CMD, located in the LCU.ZIP pack file in the \LCU subdirectory on the MPTS diskette 3. To obtain this file, insert the MPTS diskette 3 in drive A: and run the following command: PKUNZIP2 A:\LCU\LCU.ZIP \IMG\LCU LCU\CASSKEL.CMD The sample command file has three sections: o The first section contains the variables. These variables refer to such items as the path to the product installation program, the parameters to be used by the product installation program, the path to the product response file, and the name of the default response file. o The second section of the command file contains the installation statements. Depending on the products to be installed, a multiproduct installation can take place in several phases, delimited by an event such as a reboot. Most programs require a reboot after they are installed. The installation statements in the command file set up the steps needed to install the products and to ensure that the reboots occur as required. o The third section contains REXX subroutines for processing the installations. Warning: You must not make any modifications to the third section of the command file. ═══ 12.5. Editing the Sample LAN CID Utility REXX Command File ═══ When editing the command file, you should make modifications only in the areas marked for modification. These areas are in the first two sections of the command file. Parts of the command file that you must not modify are separated with comment lines that warn you not to modify that section. You must not modify anything in the third section of the command file, where the REXX subroutines are located. Note: Copy CASSKEL.CMD to another file name with an extension of .CMD before you begin editing. ═══ 12.5.1. Review of REXX Syntax ═══ Since a LAN CID Utility REXX command file is a REXX program, a review of the REXX language is provided here to ensure that, as you edit the command file, you do not make an inadvertent error in REXX syntax. For more information, see the online guide to REXX if you installed the REXX documentation when installing the OS/2 2.x program. o Comments are enclosed in the symbols /* and */. If there are statements you do not want to have processed, you can either delete them or put /* in front of the statement and */ at the end of the statement. Comments in the command file shipped with LAN CID Utility provide examples. o The comma is a continuation character. For a REXX instruction that spans more than one line, each intermediate line must end with a comma. For example, the following is a single REXX instruction spanning more than one line. x.3.instprog = 'x:\img\laps\mpts ', /* fully qualified install program name */ ' /e:prep ', /* - prep installation */ ' /s:x:\img\laps ', /* - source directory */ ' /t:c:\service ', /* - target directory */ ' /tu:' || bootdrive || '', /* - location of config.sys*/ ' /l1:x:\log\laps\' || client || '.log ', /* - log file */ ' /r:x:\rsp\laps\lapsrsp.rsp' /* - response file */ o A REXX instruction can end with a semicolon, but no end-of-line symbol is required. For example, both of the following statements are valid in REXX: x = 1; x = 1 o REXX allows variable substitution. This is a method of assigning an object to a specific variable name and then later referring to the object by the variable name. If you choose to change the object, you need to change it only once where it is assigned to the variable name instead of every place that the object is used. This feature of REXX allows you to reduce the number of changes you must make when an object changes. For example, if your object is the value D: and your variable name is BOOTDRIVE, the following line assigns the object D: to the variable name BOOTDRIVE: bootdrive = 'D:' Later in the program, the following statement assigns the value D:\CONFIG.SYS to the variable name CONFIGSYS: configsys = bootdrive || '\CONFIG.SYS' The variable name BOOTDRIVE evaluates to D:, and the || operator concatenates D: to the string \CONFIG.SYS, resulting in D:\CONFIG.SYS. Then if BOOTDRIVE changes to C:, the CONFIGSYS variable value automatically changes to C:\CONFIG.SYS. o Commands that REXX passes to the operating system for processing are strings and must be enclosed in quotation marks, for example 'SRVATTCH X: SERVER1' and 'XCOPY C:\ D:\' The commands that REXX passes to the operating system can also be built from variables, for example 'XCOPY ' BOOTDRIVE '\ D:\' o The iterate instruction in REXX is used to return processing to the beginning of the loop. ═══ 12.5.2. Editing the Variables Section of the Command File ═══ Following is a list of what to edit in the variables section, found in Section One: Variables: o SRVATTCH commands o Global variables o Product-specific data o Product count. ═══ 12.5.2.1. SRVATTCH Commands ═══ A SRVATTCH command establishes a connection between a logical drive on the client and the remote file system on the code server. The command can be issued from the command line, from a command file, or from a CALL= statement in the CONFIG.SYS file. Two SRVATTCH commands are provided in the sample command files. Initially, both are commented out with /* and */ symbols. You can remove the comment symbols from one or both and modify them to reference the code server from the client. See SRVATTCH for details of the syntax and parameters. ═══ 12.5.2.2. Global Variables ═══ Global variables are created by using variable substitution, as described in Review of REXX Syntax. You need to modify two global variables in the sample command file to reflect your system-specific information. When shipped, the sample command file contains the following values for these global variables: bootdrive='C:' exepath = 'X:\EXE\V210' In the BOOTDRIVE statement, replace C: with the drive indicator of the fixed disk that you boot from on the client. This is also the drive from which the command file reboots during the phases of a multiproduct installation. In the EXEPATH statement, replace X:\EXE\V210 with the path where you located the installation programs (such as SEINST, RSPINST, and SETBOOT) on the client accessed by SRVATTCH. Note: Ensure that SETBOOT.EXE is in the directory specified by the EXEPATH variable. If it is not, the client cannot find this program and, therefore, cannot reboot during the installation sequence. Another example of variable substitution is defining response file and log file names. CLIENT is a reserved variable in LAN CID Utility for the name of the client. If you substitute the variable name CLIENT for the response file name in the product-specific data described in the next section, REXX replaces the CLIENT variable name with the actual client name. This replacement allows the command file to be used for several clients that require the same configuration. You can do the same thing for log file names. Note: If you substitute CLIENT for the response file or log file name, do not surround it with quotation marks. ═══ 12.5.2.3. Product-Specific Data ═══ Product-specific data is designed for a particular product installation. Each product you plan to install and each program you plan to run requires a set of product-specific data. The sample command files shipped with some products may already contain product-specific data. If so, do not remove the product-specific data for the products you plan to install. Also, ensure that the path names are specified according to the way you set up the server directory structure. If you used the recommended directory structure illustrated in Recommended Directory Structure, make the following modifications in the product-specific data sections for the products already contained in the sample command file: o Change SERVER1 in THINIFS to the actual name of your code server. See THINIFS for more information. o If you are installing the LAN Server 4.0, make the following changes after referring to the product documentation: - Change /REQ to /SRV on the LANINSTR command when installing a server. - Delete the /G parameter on the LANINSTR command if you do not have an include file directory. ═══ 12.5.2.3.1. Format of Variables in the Product-Specific Data ═══ The variable format used in the command file statements is as follows: ┌──────────────────────────────────────────────────────────────────────────────┐ │ Table 4. Format of Variables (X.1.NAME) in the LAN CID Utility REXX Command │ │ File │ ├────────────┬─────────────────────────────────────────────────────────────────┤ │ VARIABLE │ DESCRIPTION │ ├────────────┼─────────────────────────────────────────────────────────────────┤ │ X │ The name of the container for all product information. │ ├────────────┼─────────────────────────────────────────────────────────────────┤ │ n │ The identifier, an integer, of the container for a specific │ │ │ product. │ ├────────────┼─────────────────────────────────────────────────────────────────┤ │ NAME │ The name of a container for a product variable. │ ├────────────┴─────────────────────────────────────────────────────────────────┤ │ NOTE: Container is a generic term meaning that the variable holds an object │ │ or a set of objects, such as product names or product information. │ └──────────────────────────────────────────────────────────────────────────────┘ If you are familiar with the C programming language, the following analogies may increase your understanding of product variables: o X.n is analogous to a structure containing the variable names NAME, STATEVAR, INSTPROG, RSPDIR, and DEFAULT. o X is analogous to an array containing multiple instances of X.n. o X.program_name is analogous to the index value for the program product-specific data in array X. ═══ 12.5.2.3.2. Sample of Product-Specific Data for LAPS ═══ Following is a sample of the product-specific data for installing LAPS: x.laps = 4 /* structure index */ x.4.name='LAPS' /* product name */ x.4.statevar = 'CAS_' || x.4.name /* state variable name */ x.4.instprog = 'x:\img\laps\mpts ', /* fully qualified program name */ ' /e:maint ', /* - maintenance installation */ ' /s:x:\img\laps ', /* - source directory */ ' /t:' || bootdrive || '\ ', /* - target directory */ ' /l1:x:\log\laps\' || client || '.log ', /* - log file */ ' /r:' /* - response file flag (auto selection)*/ x.4.rspdir = 'x:\rsp\laps' /* response file directory */ x.4.default = 'lapsrsp.rsp' /* default response file name */ Note: The product-specific information is presented in the /E, /S, /T, /L1, and /R parameters. See the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide for more information on these parameters. ═══ 12.5.2.3.3. Descriptions of Product Variables ═══ Product-specific variables are described in the following table: ┌──────────────────────────────────────────────────────────────────────────────┐ │ Table 5. Descriptions of Product Variables │ ├─────────────┬─────────────────────┬──────────────────────────────────────────┤ │ VARIABLE │ TITLE │ DESCRIPTION │ ├─────────────┼─────────────────────┼──────────────────────────────────────────┤ │ x.seinst │ Structure index │ The name of the installation program and │ │ │ │ a number that identifies the program. │ │ │ │ (This example is for the OS/2 2.x │ │ │ │ program. For a different product, │ │ │ │ replace SEINST with the name of the │ │ │ │ product installation program.) │ ├─────────────┼─────────────────────┼──────────────────────────────────────────┤ │ x.1.name │ Product name │ A user-defined name for this product. │ │ │ │ It is used for messages and for building │ │ │ │ the value for X.1.STATEVAR. The user- │ │ │ │ defined names must be unique for all of │ │ │ │ the products. One method of setting │ │ │ │ this name is to use the same subdirec- │ │ │ │ tory name you used for the product sub- │ │ │ │ directories in the directory structure. │ │ │ │ Alternately, you can use the name of the │ │ │ │ product itself, for example OS/2 2.0. │ ├─────────────┼─────────────────────┼──────────────────────────────────────────┤ │ x.1.statevar│ State variable name │ The name of the environment variable │ │ │ │ that is used to maintain the installa- │ │ │ │ tion state of the product across │ │ │ │ reboots. It is constructed from the │ │ │ │ product name. For the OS/2 2.0 program, │ │ │ │ the state variable is CAS_OS/2 2.0. │ │ │ │ (The underscore and the space are part │ │ │ │ of the name.) │ │ │ │ │ │ │ │ If a state variable is not specified in │ │ │ │ the product-specific data section for a │ │ │ │ program, that program runs any time the │ │ │ │ REXX program encounters it. The │ │ │ │ STATEVAR keyword must always be defined, │ │ │ │ but you can use the null string ('') to │ │ │ │ indicate that it is not specified. │ │ │ │ │ │ │ │ However, if there is any chance that a │ │ │ │ program will request a callback, you │ │ │ │ must specify a value other than the null │ │ │ │ string for the state variable. Also, if │ │ │ │ you do not want a certain program to be │ │ │ │ rerun in the event that another program │ │ │ │ in the same state requests a callback, │ │ │ │ you must specify a value other than the │ │ │ │ null string for the state variable. │ ├─────────────┼─────────────────────┼──────────────────────────────────────────┤ │ x.1.instprog│ Fully qualified │ The name of the installation program for │ │ │ installation │ this product with its path and parame- │ │ │ program name │ ters. This name should end with /R: if │ │ │ │ X.1.RSPDIR (the value on the next line │ │ │ │ of the command file) is specified. │ ├─────────────┼─────────────────────┼──────────────────────────────────────────┤ │ x.1.rspdir │ Response file sub- │ The path to the default response file │ │ │ directory │ for this product. │ │ │ │ │ │ │ │ Set this value to the null string ('') │ │ │ │ if the response file is indicated in the │ │ │ │ X.n.INSTPROG string or if this product │ │ │ │ does not use response files. │ ├─────────────┼─────────────────────┼──────────────────────────────────────────┤ │ x.1.default │ Default response │ The name of the default response file to │ │ │ file name │ use if a specific response file for this │ │ │ │ client cannot be found. Response files │ │ │ │ can have the name client_name.RSP, but │ │ │ │ if many clients are to be configured │ │ │ │ identically, you can use a default │ │ │ │ response file. │ │ │ │ │ │ │ │ Set this value to the null string ('') │ │ │ │ if the response file is indicated in the │ │ │ │ X.n.INSTPROG string or if this product │ │ │ │ does not use response files. │ └─────────────┴─────────────────────┴──────────────────────────────────────────┘ ═══ 12.5.2.4. Default Response Files and the Response File Subdirectory ═══ For products that use response files with LAN CID Utility, there are two ways to specify the response file that the installation program is to use. If you want to hardcode the response file name for the installation program, specify the response file keyword (usually /R:) followed by its value (usually the fully qualified response file name) in the X.n.INSTPROG string. Then, set X.n.RSPDIR and X.n.DEFAULT to the null string (''). If you want the installation program to use a client-specific response file, if it exists, or a default response file if a client-specific response file does not exist, LAN CID Utility can select the correct response file for the installation program. To do this, place the response file keyword (usually /R:) without a value at the end of the X.n.INSTPROG string. Then specify both of the following: The fully qualified path to the response files in X.n.RSPDIR The desired default response file name in X.n.DEFAULT. When you specify the response file in this way, LAN CID Utility checks the directory specified in X.n.RSPDIR for client_name.RSP. If this response file exists, LAN CID Utility appends its fully qualified path and file name to the X.n.INSTPROG string. If LAN CID Utility does not find client_name.RSP, it appends the fully qualified path and file name of the default response file indicated in X.n.DEFAULT, located in the directory specified by X.n.RSPDIR. LAN CID Utility does not verify that the default response file exists. For more information on the /R: parameter, see SEINST and THINSRV. Note: 1. If the program you are running does not use response files, you must set X.n.RSPDIR and X.n.DEFAULT to the null string (''). 2. If you specify a value for the /R: parameter in the X.n.INSTPROG string, you must set the values for X.n.RSPDIR and X.n.DEFAULT to the null string (''). If you do not, LAN CID Utility attempts to select a response file for the installation program, and the response file it chooses is appended to the X.n.INSTPROG string that already had a response file specified in it. This action produces unpredictable results. The following examples show you how to handle response files in four different situations. ═══ 12.5.2.4.1. Hardcoding a Value ═══ The following is an example of hardcoding the response file name to a specific value for an installation program: x.progA = 20 x.20.name = programA x.20.statevar = 'CAS_' || x.20.name x.20.instprog = 'progains /s:x:\img\proga /t:c:\proga ', '/r:x:\rsp\proga\proga.rsp ' x.20.rspdir = '' x.20.default = '' In this example, LAN CID Utility causes all client workstations to run the following command: progains /s:x:\img\proga /t:c:\proga /r:x:\rsp\proga\proga.rsp ═══ 12.5.2.4.2. Hardcoding a Client-Specific Value ═══ The following is an example of hardcoding the response file name to a client-specific value for an installation program: x.progB = 21 x.21.name = programB x.21.statevar = 'CAS_' || x.21.name x.21.instprog = 'progbins /s:x:\img\progb /t:c:\progb ', '/r:x:\rsp\progb\' || client ||' .rsp', x.21.rspdir = '' x.21.default = '' In this case, LAN CID Utility substitutes the client workstation SRVIFS requester name for the word client in the INSTPROG string. For example, if the client workstation SRVIFS requester name is BREAUX, LAN CID Utility runs the following command: progbins /s:x:\img\progb /t:c:\progb /r:x:\rsp\progb\breaux.rsp ═══ 12.5.2.4.3. Having LAN CID Utility Choose the Response File ═══ The following is an example of how to allow LAN CID Utility to choose the response file name for the installation program: x.progC = 22 x.22.name = programC x.22.statevar = 'CAS_' || x.22.name x.22.instprog = 'progcins /s:x:\img\progc /t:c:\progc /r:' x.22.rspdir = 'x:\rsp\progc' x.22.defaul = 'default.rsp' In this case, if the workstation name is CHANG, and the file CHANG.RSP exists in the directory X:\RSP\PROGC, LAN CID Utility runs the following command: progcins /s:x:\img\progc /t:c:\progc /r:x:\rsp\progc\chang.rsp If CHANG.RSP does not exist in the X:\RSP\PROGC directory, LAN CID Utility runs the following command: progcins /s:x:\img\progc /t:c:\progc /r:x:\rsp\progc\default.rsp ═══ 12.5.2.4.4. Handling Programs That Do Not Use Response Files ═══ The following is an example of a program that does not use response files. x.progD = 23 x.23.name = programD x.23.statevar = 'CAS_' || x.23.name x.23.instprog = 'progdins /s:x:\img\progd /t:c:\progd' x.23.rspdir = '' x.23.default = '' In this case, LAN CID Utility causes all client workstations to run the following command: progdins /s:x:\img\progd /t:c:\progd ═══ 12.5.2.5. Product Count ═══ Indicate the total number of products that are defined in the product-specific data section, such as this example: NUM_INSTALL_PROGS = 10 ═══ 12.5.3. Editing the Installation Statements of the Command File ═══ In the second section of the command file, you should modify the installation statements to match your requirements. This section is found in Section Two: Installation Sequences. The following REXX structure is used to install the products in the correct order and to reboot the client at the correct time. Following are definitions of the various lines in the structure: tsize 15. Select The REXX structure name. When The REXX instruction used to determine what should be run between each reboot. RunInstall The command to call the installation command of a product. For an example of an installation sequence, see Installation Scenarios. ═══ 12.5.3.1. RunInstall ═══ The following diagram defines a RunInstall statement: This part of the statement tells what to do if the installation fails. In all failing cases, the entire installation sequence stops. │ │ │ ┌───────────────┴───────────────┐ │ │ │ │ ─┴ ───────┴─────────── if RunInstall(x.cmsetup,y) == BAD_RC then exit ─────────┬────────── │ ─────┬── │ │ │ └──────── Modify this part │ with the product │ name to be installed. This part of the Y is an optional statement says to parameter that tells install the named what the OVERALL_STATE product. This name is should be reset to if the one you used when BAD_RC is returned. you set up the structure index. Format of the RunInstall Statement ReturncodesarediscussedinmoredetailinErrorProcessing . ═══ 12.5.3.2. Deleting LAN CID Utility and SRVIFS ═══ In the last step of the installation sequence, the IFSDEL and CASDELET RunInstall statements remove SRVIFS and LAN CID Utility from the client. IFSDEL removes SRVIFS statements from the CONFIG.SYS file. If these statements were not removed, the final reboot would cause the entire installation process to be restarted. Warning: Do not remove the IFSDEL and CASDELET RunInstall statements from the installation sequence. See CASDELET and IFSDEL for the syntax and parameters of these commands. ═══ 12.5.3.3. Product-Specific Notes ═══ Following is information related to specific products. o To install the Extended Services program, you need the IBM Extended Services Configuration, Installation, and Distribution Utility (ESCID). The ESAINST program is included in this utility. ESCID is available as a separately orderable publication and diskette (S96F-8378-00). o The Extended Services, Communications Manager/2, Database Manager/2, LAN Server 3.0, and LAN Server 4.0 programs require the OS/2 2.x Presentation Manager facility in order for their installation programs to run. If you are installing the OS/2 2.x program prior to installing one of these programs, a reboot is required after the OS/2 2.x installation. o If you are installing the LAN Server program after installing the Extended Services program, you must reboot the client after the Extended Services installation. Place the installation commands for the two products in separate queues or separate When OVERALL_STATE= statements. o The response file for the OS/2 2.x program must contain the following keyword=value pairs: RebootRequired=0 ExitOnError=1 Note: If you are not using boot diskettes and you plan to format the partition where you plan to install the OS/2 2.x program, you must install your SEMAINT files on a drive different from the drive you are formatting. Specify different drive letters on the /T: and /B: parameters for SEMAINT. ═══ 12.5.3.4. Installing Other CID-Enabled Products ═══ You can install any CID-enabled product with the LAN CID Utility by modifying the command file as follows: o Add the product-specific data. o Increment the NUM_INSTALL_PROGS variable. o Add a When OVERALL_STATE= statement to the installation sequence. Include RunInstall and CheckBoot statements. o Adjust When OVERALL_STATE= statements to be sequential. Note: The When OVERALL_STATE= statement that contains IFSDEL and CASDELET must remain last in the command file. Insert the new When OVERALL_STATE= statement before it, and adjust the When OVERALL_STATE= numbers to be sequential. ═══ 12.6. The Sample LAN CID Utility REXX Command File ═══ Following is a partial command file showing the sections that you need to edit. The REXX subroutines, the third section of the sample file, are not included because you must not modify them. ═══ 12.6.1. Section One: Variables ═══ /* CASSKEL 2.0 */ /*---------------------------------------------------*/ /* DO NOT MODIFY THE NEXT EIGHT LINES */ /*---------------------------------------------------*/ parse ARG client logfile additional QUEUE_REBOOT = 0 CALL_AGAIN = 0 Call AddDLLFunctions x.0.instprog = '' x.0.rspdir = '' x.0.statevar = 'CAS_STATE' x.0.default = '' /*---------------------------------------------------*/ /* MODIFICATIONS START HERE */ /*---------------------------------------------------*/ /*****************************************************/ /* SRVATTCH SECTION */ /*****************************************************/ /* 'SRVATTCH z: \\SERVER1\ALIAS' */ /* Additional SRVATTCHs can be placed here*/ /* 'SRVATTCH y: SERVER2'*/ /* They can be placed before specific */ /* RunInstall statements too if you only */ /* want to attach to a special server */ /* right before a specific install. */ /*****************************************************/ /* VARIABLES SECTION */ /*****************************************************/ /*---------------------------------------------------*/ /* DO NOT REMOVE THE NEXT FOUR LINES */ /* (They may be modified) */ /*---------------------------------------------------*/ bootdrive='c:' /* Boot Drive */ configsys = bootdrive || '\CONFIG.SYS' /* Fully qualified path to the CONFIG.SYS file */ maintdir = bootdrive || '\SERVICE' /* Maintenance directory, refrenced by */ /* SEMAINT, SEINST, and LAPS. */ exepath = 'X:\EXE\V210' /* Path to executable directory on server */ dllpath = 'X:\DLL\V210' /* Paths to the DLL directories on server */ /*---------------------------------------------------*/ /* The next four lines are included to make it */ /* easier to change the version of OS/2 2.x that is */ /* to be installed. */ /* */ /* These variables are referenced in the product */ /* data sections for SEINST and SEMAINT. */ /*---------------------------------------------------*/ os2dir = 'OS2V21' /* Name of OS/2 2.1 directories */ os2img = 'X:\IMG\' || os2dir /* - product image directory */ os2rsp = 'X:\RSP\' || os2dir /* - response file directory */ os2log = 'X:\LOG\' || os2dir /* - log file directory */ /*****************************************************/ /* PRODUCT-SPECIFIC DATA SECTION */ /*****************************************************/ x.seinst = 1 /* structure index */ x.1.name='OS/2 2.1' /* product name */ x.1.statevar = 'CAS_' || x.1.name /* state variable name */ x.1.instprog = exepath || '\seinst ', /* fully qualified program name */ ' /b:' || bootdrive || '', /* - bootdrive */ ' /s:' || os2img || ' ', /* - source directory */ ' /t:' || maintdir || ' ', /* - service directory */ ' /l1:' || os2log || '\' || client || '.log ', /* - log file */ ' /r:' /* - response file flag (auto selection) */ x.1.rspdir = os2rsp /* response file directory */ x.1.default = 'default.rsp' /* default response file name */ x.semaint = 2 /* structure index */ x.2.name='OS/2 2.1 Maintenance' /* product name */ x.2.statevar = 'CAS_' || x.2.name /* state variable name */ x.2.instprog = exepath || '\semaint ', /* fully qualified program name */ ' /s:' || os2img || ' ', /* - source directory */ ' /t:' || maintdir || ' ', /* - target directory */ ' /b:' || bootdrive || ' ', /* - target boot drive (not necessarily current) */ ' /l1:' || os2log || '\' || client || '.log' /* - log file */ x.2.rspdir = '' /* no auto selection */ x.2.default = '' x.laps_prep = 3 /* structure index */ x.3.name='LAPS Maintenance' /* product name */ x.3.statevar = 'CAS_' || x.3.name /* state variable name */ x.3.instprog = 'x:\img\laps\mpts ', /* fully qualified program name */ ' /e:prep ', /* - prep installation */ ' /s:x:\img\laps ', /* - source directory */ ' /t:' || maintdir || ' ', /* - target directory */ ' /tu:' || bootdrive || '', /* - location of config.sys*/ ' /l1:x:\log\laps\' || client || '.log ', /* - log file */ ' /r:x:\rsp\laps\lapsrsp.rsp' /* - response file */ x.3.rspdir = '' /* no auto selection */ x.3.default = '' x.laps = 4 /* structure index */ x.4.name='LAPS' /* product name */ x.4.statevar = 'CAS_' || x.4.name /* state variable name */ x.4.instprog = 'x:\img\laps\mpts ', /* fully qualified program name */ ' /e:maint ', /* - maintenance installation */ ' /s:x:\img\laps ', /* - source directory */ ' /t:' || bootdrive || '\ ', /* - target directory */ ' /l1:x:\log\laps\' || client || '.log ', /* - log file */ ' /r:' /* - response file flag (auto selection)*/ x.4.rspdir = 'x:\rsp\laps' /* response file directory */ x.4.default = 'lapsrsp.rsp' /* default response file name */ x.laninstr = 5 /* structure index */ x.5.name='LAN Services 4.0' /* product name */ x.5.statevar = 'CAS_' || x.5.name /* state variable name */ x.5.instprog = 'x:\img\ls40\laninstr', /* fully qualified program name */ ' /req ', /* - install a requester */ ' /l1:x:\log\ls40\' || client || '.L1 ', /* - error log file */ ' /l2:x:\log\ls40\' || client || '.L2 ', /* - history log file */ ' /g:x:\rsp\ls40 ', /* - include file directory */ ' /r:' /* - response file flag (auto selection)*/ x.5.rspdir = 'x:\rsp\ls40' /* response file directory */ x.5.default = 'req.rsp' /* default response file name */ x.thinifs = 6 /* structure index */ x.6.name='SRVIFS Requester' /* product name */ x.6.statevar = '' /* state variable name */ x.6.instprog = 'x:\img\srvifs\thinifs', /* fully qualified program name */ ' /s:x:\img\srvifs ',/* - source directory */ ' /t:' || bootdrive || '\srvifsrq ', /* - target directory */ ' /tu:' || bootdrive || '\ ', /* - config.sys location */ ' /l1:x:\log\srvifs\' || client || '.log ', /* - log file */ ' /req:' || client || ' ', /* - requester name */ ' /srv:server1 ', /* - server name */ ' /d:x' /* - remote drive identifier */ x.6.rspdir = '' /* no auto selection */ x.6.default = '' x.ifsdel = 7 /* structure index */ x.7.name='SRVIFS Delete' /* product name */ x.7.statevar = '' /* state variable name */ x.7.instprog = 'x:\img\srvifs\ifsdel', /* fully qualified program name */ ' /t:' || bootdrive || '\srvifsrq ', /* - target directory */ '/tu:' || bootdrive /* - config.sys location */ x.7.rspdir = '' /* no auto selection */ x.7.default = '' x.casinstl = 8 /* structure index */ x.8.name='LAN CID Utility' /* product name */ x.8.statevar = '' /* state variable name */ x.8.instprog = 'x:\img\lcu\casinstl', /* fully qualified program name */ '/cmd:x:\client ', /* - location of .cmd files */ ' /tu:' || bootdrive || ' ', /* - config.sys location */ ' /pl:' || dllpath || ' ', /* - string to add to libpath */ ' /pa:x:\img\lcu ', /* - path to LCU images */ ' /l1:x:\log\lcu\' || client || '.log ', /* - CASINSTL log file */ ' /l2:x:\log\lcu\SRVIFS_REQ.log', /* - CASAGENT log file */ ' /req:' || client || ' ' /* - LCU client name */ x.8.rspdir = '' /* no auto selection */ x.8.default = '' x.casdelet = 9 /* structure index */ x.9.name='LAN CID Utility Delete' /* product name */ x.9.statevar = '' /* state variable name */ x.9.instprog = 'x:\img\lcu\casdelet ', /* fully qualified program name */ '/pl:' || dllpath || ' ', /* - string to delete from libpath*/ '/tu:' || bootdrive /* - config.sys location */ x.9.rspdir = '' /* no auto selection */ x.9.default = '' /*---------------------------------------------------*/ /* NUMBER OF PROGRAMS SET UP IN THE */ /* PRODUCT DATA SECTION */ /*---------------------------------------------------*/ NUM_INSTALL_PROGS = 9 /*---------------------------------------------------*/ /* DO NOT MODIFY OR REMOVE THE NEXT LINE */ /*---------------------------------------------------*/ OVERALL_STATE = GetEnvironmentVars() ═══ 12.6.2. Section Two: Installation Sequences ═══ /*****************************************************/ /* INSTALL SECTION */ /*****************************************************/ Do Forever Select when OVERALL_STATE = 0 then do if BootDriveIsDiskette() == YES then iterate /* Check if booted from diskette*/ /* if it was, then goto state 1*/ if RunInstall(x.semaint) == BAD_RC then exit /* Install maintenance system */ if RunInstall(x.laps_prep) == BAD_RC then exit /* Install LAPS prep system */ if RunInstall(x.thinifs) == BAD_RC then exit /* Install SRVIFS requester */ if RunInstall(x.casinstl) == BAD_RC then exit /* Install LCU */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 1 then do if RunInstall(x.seinst) == BAD_RC then exit /* Install operating system */ if RunInstall(x.laps) == BAD_RC then exit /* Install LAPS */ if RunInstall(x.thinifs) == BAD_RC then exit /* Install SRVIFS requester */ if RunInstall(x.casinstl) == BAD_RC then exit /* Install LCU */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 2 then do if RunInstall(x.laninstr) == BAD_RC then exit /* Install LS */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 3 then do if RunInstall(x.ifsdel) == BAD_RC then exit /* Delete SRVIFS requester */ if RunInstall(x.casdelet) == BAD_RC then exit /* Delete LCU */ Call Reboot /* Reboot */ end end end exit ═══ 13. Creating Boot Diskettes ═══ Note: This book is supplemented by the MPTS README.UTL file on the MPTS diskette 3. Ensure that you read this file. The code server setup information in the README is also presented in this book for your convenience. See The CASSETUP Code Server Setup Utility. This chapter explains how to create the two boot diskettes and how to install required programs on the boot diskettes. Note: To create boot diskettes, you need two 3.5-inch diskettes of 2.0MB capacity. Label them, for example, as follows: o Boot diskette 0 o Boot diskette 1 ═══ 13.1. Planning for the Boot Diskettes ═══ You must create boot diskettes to install product images on any client that does not have NetBIOS installed and configured for LAN communications. Create the boot diskettes for one specific client installation, or create a set of general-use boot diskettes to be used on a number of client installations. The boot diskettes must contain the following: o A minimal version of the OS/2 2.x program OS/2 2.x provides a program called SEDISK that installs a minimal OS/2 2.x on the boot diskettes. Also known as a maintenance system, this minimal OS/2 does not contain the Presentation Manager or Workplace Shell features of the OS/2 program. o A LAN transport program MPTS provides a program called THINLAPS that installs a minimal version of MPTS LAPS on the boot diskettes. THINLAPS installs MPTS LAPS for one adapter configured for NetBIOS. o A redirector program MPTS provides a program called THINIFS that installs a minimal redirector called SRVIFS on the boot diskettes. o LAN CID Utility MPTS provides a program called CASINSTL that installs LAN CID Utility on the boot diskettes. To create the two boot diskettes, you must run the following programs in the sequence listed: SEDISK Installs a minimal version of the OS/2 2.x program on the boot diskettes. THINLAPS Installs a minimal version of LAPS on the boot diskettes. THINIFS Installs SRVIFS for the client on the boot diskettes. CASINSTL Installs LAN CID Utility on the boot diskettes. Note: If you want to use a LAN transport other than MPTS LAPS or a redirector other than SRVIFS, you can substitute your own LAN transport and redirector installation programs for THINLAPS and THINIFS. It is important to remember that space is very limited on boot diskettes and most LAN transports and redirectors other than THINLAPS and SRVIFS do not fit on the boot diskettes. ═══ 13.2. Creating the Boot Diskettes with SEDISK ═══ The SEDISK command creates the boot diskettes. Note: It is suggested that you create boot diskettes from the latest level of the OS/2 2.x product images that are installed on the code server unless you are using the boot diskettes to install the operating system. If you are, create the boot diskettes from the version of the OS/2 2.x product that is to be installed on the client workstations. Ensure that you use the correct version of SEDISK when you are creating boot diskettes. For example, use \EXE\V200\SEDISK.EXE with the product images in \IMG\OS2V20 or use \EXE\V210\SEDISK.EXE with the product images in \IMG\OS2V21. See Loading the OS/2 2.x Program on the Code Server, for the steps to unpack SEDISK from OS/2 2.x diskette 7 (diskette 8 in some DBCS countries) and put it into the \EXE\V2xx. When the two boot diskettes are created, leave the second diskette (labeled Boot diskette 1, for example) in the disk drive to complete the installations that follow. See SEDISK for details of the syntax and parameters. ═══ 13.2.1. Installing LAPS on the Boot Diskettes with THINLAPS ═══ Use the THINLAPS command to install the minimal version of LAPS on the boot diskettes. An appropriately configured LAN transport subsystem on the client is necessary so that you can run SRVIFS on that client. A SRVIFS client must have the following NetBIOS resources available: o A NetBIOS name o A NetBIOS session per server that the client is to connect to o Four NetBIOS commands. When you run THINLAPS, the command sets the default NetBIOS resources in the PROTOCOL.INI file. Specify the target drive as the drive that contains the boot diskettes you are creating. See THINLAPS for details of the syntax and parameters. ═══ 13.2.2. Installing SRVIFS on the Boot Diskettes with THINIFS ═══ Use the THINIFS command to install SRVIFS on the boot diskettes. THINIFS installs a SRVIFS client, which includes: o A SRVIFS device driver o The Installable File System (IFS) with the SRVIFS device driver statement (IFS statement) o A SRVATTCH statement. The THINIFS command also updates statements in the CONFIG.SYS file so that these SRVIFS client features are activated. Specify both the target path (/T:) and the updated CONFIG.SYS path (/TU:) as the drive that contains the boot diskettes you are creating. See THINIFS for details of the syntax and parameters. ═══ 13.2.3. Installing LAN CID Utility on the Boot Diskettes with CASINSTL ═══ Use the CASINSTL command to accomplish the last step in creating the boot diskettes, which is installing LAN CID Utility. Specify the updated CONFIG.SYS path (/TU:) as the drive that contains the boot diskettes you are creating. See CASINSTL for details of the syntax and parameters. ═══ 13.2.4. Example of Creating Boot Diskettes ═══ Following is an example of using the SEDISK, THINLAPS, THINIFS, and CASINSTL commands to create boot diskettes: C:\EXE\V200\SEDISK /S:C:\IMG\OS2V20 /T:A: C:\IMG\LAPS\THINLAPS C:\IMG\LAPS A: IBMTOK.NIF C:\IMG\SRVIFS\THINIFS /S:C:\IMG\SRVIFS /T:A: /TU:A: /SRV:SERVER1 /REQ:* /D:X C:\IMG\LCU\CASINSTL /CMD:X:\CLIENT /TU:A: /PA:X:\IMG\LCU /PL:X:\DLL\V200 /L2:X:\LOG\LCU\SRVIFS_REQ.LOG /REQ:*P ═══ 14. Redirected Installation of Products on the Client ═══ This chapter provides the steps for the redirected installation of products on the client. One method uses boot diskettes and the other does not. ═══ 14.1. Installing with Boot Diskettes ═══ Use the boot diskettes created in Creating Boot Diskettes, to install products on a client that does not have NetBIOS installed and configured for LAN communications. This type of installation is termed an installation started from boot diskettes. The steps in this type of installation follow: 1. Start or reboot the client with diskette 0 (the installation diskette) in the A: drive. Later, you are prompted for diskette 1. 2. Depending on how the boot diskettes are set up, you may be prompted to enter the client name and the server name. Enter these names as necessary. The installation begins. 3. You are prompted to remove the last diskette. Warning: You must wait for the prompt before removing the diskette. If you are using a redirected diskette 1, the prompt displays just after the CASAGENT program starts, otherwise, the prompt displays before the first reboot is to occur. After you have removed the last diskette, the installation continues without further interaction. Note: See the definition of the CASINSTL /PD: parameter on page Parameters for more information on the redirected diskette 1. For detailed examples, see the following: o Installing the OS/2 2.x Program with Boot Diskettes o Installing an Application with Boot Diskettes o Installing LAPS and an Application with Boot Diskettes ═══ 14.2. Installing without Boot Diskettes ═══ You do not need to use the boot diskettes to install products on a client that already has OS/2 1.3 or later and NetBIOS installed and configured for LAN communications. This type of installation is termed an installation started from the fixed disk. Note: You can use boot diskettes on this type of client if you want to. The steps in this type of installation follow: 1. Ensure that you have the following files available to the client: o SRVIFS product images in the \IMG\SRVIFS subdirectory on the code server or in the SRVIFS.ZIP pack file in the \SRVIFS directory on the MPTS diskette 3. o CASINSTL.EXE located in the \IMG\LCU subdirectory on the code server or in the LCU.ZIP pack file in the \LCU directory on the MPTS diskette 3. See Loading LAN CID Utility, SRVIFS, and LAPS on the Code Server, for more information. You can make the SRVIFS and CASINSTL files available to the client in the following ways: o From a diskette o From a LAN Server through redirection o From a host by downloading them to the client Continue with the next step of the installation after ensuring that the client has access to these files. 2. Install SRVIFS on the client by using the THINIFS command. See THINIFS for details of the syntax and parameters. 3. Install LAN CID Utility on the client by using the CASINSTL command. See CASINSTL for details of the syntax and parameters. 4. Reboot the client. The installation process begins. From this point, the installation continues without further interaction. For detailed examples, see the following: o Installing the OS/2 2.x Program without Boot Diskettes o Installing LAPS without Boot Diskettes o Installing LAPS and an Application without Boot Diskettes ═══ 15. Return Code Processing ═══ CID-enabled programs return four types of return codes LAN CID Utility can act on: o Successful completion: reboot not required o Successful completion: reboot required o Successful completion: reboot and callback required o Error The first type of return code requires no additional information. The other types are discussed in the remainder of this chapter. ═══ 15.1. Return Codes ═══ The return codes and descriptions for CID-enabled products are divided into two lists: ═══ 15.1.1. Return codes FE 00 to FD 00 ═══ Return Description Code FE 00 Successful program processing; reboot queued but no callback required. FE 04 Successful program processing; warning messages logged; reboot queued but no callback required. FE 08 Successful program processing; error messages logged; reboot queued but no callback required. FE 12 Successful program processing; severe error messages logged; reboot queued but no callback required. FF xx Successful program processing; reboot queued and callback required. LAN CID Utility manages the state of the product installation by validating the state that the product installation program returns. LAN CID Utility takes the following steps: 1. When an exiting product installation program requests a reboot with callback, that program must set the correct byte of the return code to its next state; xx can range from X'00' to X'FF'. For example, on the initial call from LAN CID Utility, the state variable is X'00' and the product installation program can change this value for each reboot request. This value returns to the installation program when LAN CID Utility calls it back. 2. LAN CID Utility reboots the workstation, retrieves the product installation state parameter, stores it, and passes it to the invoked product installation program by means of the REMOTE_INSTALL_STATE state variable. FD 00 Reserved RC. ═══ 15.1.2. Return codes 00 00 to FC FF ═══ Return Description Code 00 00 Successful program termination occurred. 00 04 Successful program processing; warning messages logged. 00 08 Successful program processing; error messages logged. 00 12 Successful program processing; severe error messages logged. 08 00 Data resource was not found. 08 04 Data resource access denied because resource is already in use. 08 08 Data resource access denied because authorization is missing. 08 12 Data path was not found. 08 16 Product is not configured. 12 00 Storage medium exception (I/O error) occurred. 12 04 Device is not ready. 12 08 Not enough disk space is available. 16 00 Incorrect program invocation was used. 16 04 Unexpected condition occurred. Note: Refer to SetCIDType for information on how to make LAN CID Utility treat return codes 00 04, 00 08, and 00 12 as bad return codes. ═══ 15.2. Reboot Processing ═══ Through return codes, CID-enabled programs can request that LAN CID Utility queue a reboot of the system. Queueing a reboot means that when an installation program requests a reboot, the requested reboot does not necessarily happen immediately. LAN CID Utility remembers that an installation program requested a reboot. LAN CID Utility proceeds with the installation and, at some predetermined point, reboots the system if any of the programs had requested a reboot. In LAN CID Utility, the predetermined point to check for requested reboots is the next Call CheckBoot statement in the installation sequence. If LAN CID Utility encounters a Call CheckBoot statement, but a reboot was not queued since the last reboot, LAN CID Utility does not reboot. It continues to the next state. See Installation Scenarios, for examples of reboot processing during an installation. The following steps describe a simplified version of the LAN CID Utility reboot processing. Refer to Reboot and Callback Processing to see exactly how reboots are processed. 1. Product installation programs communicate to LAN CID Utility that a reboot is required by specifying a reboot return code when they exit to LAN CID Utility. For example, the return code X'FE00' indicates that a reboot is required. 2. LAN CID Utility uses this return code to set a flag, QUEUE_REBOOT, within the LAN CID Utility command file to indicate that a program has requested a reboot. 3. When LAN CID Utility encounters a Call CheckBoot statement, LAN CID Utility checks the QUEUE_REBOOT flag to determine if a reboot is required. o If a reboot is required, LAN CID Utility state information is saved. Then the workstation is rebooted. o If a reboot is not required, LAN CID Utility proceeds to the next state. ═══ 15.3. Reboot and Callback Processing ═══ Through return codes, CID-enabled programs can request that LAN CID Utility call them back after a reboot. An installation program can use the LAN CID Utility ability to call back or rerun CID-enabled programs to perform functions such as cleanup routines. Installation programs may request a callback more than once. As in Reboot Processing, LAN CID Utility does not reboot the client workstation until it encounters the next Call Checkboot statement in the installation sequence. If a CID-enabled program requests a callback, LAN CID Utility does not proceed to the next state after the reboot. Instead, LAN CID Utility enters the same state it was in before the reboot, as controlled by the When OVERALL_STATE=n statement in the installation sequence. LAN CID Utility then reruns the CID-enabled program that requested the callback. See Installation Scenarios, for examples of reboot and callback processing during an installation. ═══ 15.3.1. LAN CID Utility Reboot and Callback Implementation ═══ Before any installation programs are run, LAN CID Utility initializes all of the installation program state variables in the product-specific data section. See Descriptions of Product Variables for more information on state variables. The following steps describe LAN CID Utility reboot and callback processing: 1. When LAN CID Utility encounters a RunInstall statement, LAN CID Utility must determine if a program should be run. The following criteria are used to determine if a program should be run: o All programs that do not have state variables indicated in the product-specific data section are run. o All programs that have state variables, but whose state variables have not yet been cleared by LAN CID Utility, are run. Initially, the state variables for all programs are active (not cleared). The clearing of state variables is explained in step LAN CID Utility Reboot and Callback Implementation. 2. Before LAN CID Utility runs an installation program, LAN CID Utility sets the environment variable REMOTE_INSTALL_STATE to the same value indicated in the installation program state variable. As stated previously, this value is initially 0. This value can be changed by LAN CID Utility to another value as indicated by the installation program itself. This is explained in step LAN CID Utility Reboot and Callback Implementation. LAN CID Utility sets REMOTE_INSTALL_STATE to 0 for all programs that do not have state variables. Installation programs are not required to have knowledge of or utilize the REMOTE_INSTALL_STATE environment variable. Installation programs can use REMOTE_INSTALL_STATE in the following ways: o For determining that the installation program is being run remotely instead of interactively. o For determining the callback state of the program. For instance, REMOTE_INSTALL_STATE set to 2 may indicate that this is the second time that the program has been run. To a CID-enabled program, a REMOTE_INSTALL_STATE set to 0 always indicates that this is the first time a program has been run during an installation. 3. Product installation programs communicate to LAN CID Utility that a reboot and a callback are required by specifying a reboot and callback return code (X'FFxx') when they exit to LAN CID Utility. If the return code received from the program was not in the range of X'FF01' through X'FFFF', then no more processing is required for this program; LAN CID Utility clears the program state variable by removing it from the environment. This is done to ensure that programs not requesting a callback are not rerun after a reboot. 4. LAN CID Utility uses the reboot and callback (X'FFxx') or reboot (X'FExx') return code to set a flag, QUEUE_REBOOT, within the LAN CID Utility command file to indicate that a program has requested a reboot. 5. LAN CID Utility uses the reboot and callback return code (X'FFxx') to set a flag, CALL_AGAIN, within the LAN CID Utility command file to indicate that a program has requested a callback. 6. LAN CID Utility also uses the reboot and callback return code to set the state variable indicated for this installation program in X.n.STATEVAR to a value that the installation program requests, where n is an integer. The state variable is set to the decimal (base 10) ASCII representation of the two-digit hexadecimal (base 16) value indicated in the low-order byte of the return code. This means that if LAN CID Utility receives a return code of X'FF02' from an installation program, its state variable is set to 2; if the return code is X'FF11', its state variable is set to 17. When LAN CID Utility reruns the program after the reboot, the environment variable REMOTE_INSTALL_STATE is also set to this value. This tells the CID-enabled program the state it should be in. 7. When LAN CID Utility encounters a Call Checkboot statement, LAN CID Utility checks the QUEUE_REBOOT flag to determine if a reboot is required. Note that if the CALL_AGAIN flag is set to true, the QUEUE_REBOOT flag is always set to true. o If a reboot is required: - If a callback was not requested, OVERALL_STATE is incremented by 1. This causes the LAN CID Utility to enter the next state after the reboot. - If a callback was requested, OVERALL_STATE does not change. This causes the LAN CID Utility to enter the same state after the reboot. - LAN CID Utility saves its state information. - LAN CID Utility reboots the workstation. o If a reboot is not required, LAN CID Utility proceeds to the next state. This procedure returns to step LAN CID Utility Reboot and Callback Implementation for the OVERALL_STATE set by LAN CID Utility in step LAN CID Utility Reboot and Callback Implementation. ═══ 15.3.2. Overview of Program Reprocessing Criteria ═══ Note that other programs in the same state can be rerun along with a program that requests a callback. Use the following criteria to determine if a program would be rerun. A more detailed explanation follows in the Details of Program Reprocessing Criteria step. 1. All programs that are processed with a RunInstall command and specify a state variable in the product-specific data section and also request a callback are rerun along with other installation programs in a specific state that request callbacks. 2. All programs that are processed with a RunInstall command and do not specify a state variable in the product-specific data section are rerun along with the program that requested the callback if located in the same state with the installation program that requested a callback. 3. All programs that are not processed with a RunInstall command are rerun after the reboot if located in the same state as an installation program that requests a callback. ═══ 15.3.3. Details of Program Reprocessing Criteria ═══ Following are the detailed explanations of the reprocessing criteria given previously: 1. All programs that are processed with a RunInstall command and specify a state variable in the product-specific data section and also request a callback are rerun along with other installation programs in a specific state that requests callbacks. See Descriptions of Product Variables for more information on state variables. In the following example, all of the programs have state variables. If program A and program C request callbacks, and program B does not, program A and program C are rerun after the reboot, but program B is not. when OVERALL_STATE = 0 then do if RunInstall(x.programA) == BAD_RC then exit if RunInstall(x.programB) == BAD_RC then exit if RunInstall(x.programC) == BAD_RC then exit Call CheckBoot end 2. All programs that are processed with a RunInstall command and do not specify a state variable in the product-specific data section are rerun along with the program that requested the callback if located in the same state with the installation program that requested a callback. See Descriptions of Product Variables for more information on state variables. In the following example, all of the programs except program X have state variables. If program Y requests a callback and program Z does not, program X (because it had no state variable) and program Y (because it requested the callback) are rerun after the reboot, but program Z is not. (Note that program X cannot request a callback because, as indicated previously, a state variable was not specified for it in the product-specific data section.) when OVERALL_STATE = 0 then do if RunInstall(x.programX) == BAD_RC then exit if RunInstall(x.programY) == BAD_RC then exit if RunInstall(x.programZ) == BAD_RC then exit Call CheckBoot end 3. All programs that are not processed with a RunInstall command are rerun after the reboot if located in the same state as an installation program that requests a callback. In the following example, program A has a state variable. If program A requested a callback, the XCOPY command would be run again after the reboot, along with program A. when OVERALL_STATE = 0 then do if RunInstall(x.programA) == BAD_RC then exit 'XCOPY X:\IMG\PROGRAMB C:\APPS\PROGRAMB' Call CheckBoot end In order to prevent the rerunning of an ordinary (non-CID-enabled) program such as XCOPY, provide product-specific data for it, including the state variable. The entire command can be provided on the X.n.INSTPROG line. For example, the product-specific data section and installation sequence for the installation of program B using XCOPY are in the following example: o Product-specific data section: x.xcopyProgramB x.15.name = 'ProgramB' x.15.statevar = 'CAS_' || x.15.name x.15.instprog = 'XCOPY X:\IMG\PROGRAMB C:\APPS\PROGRAMB' x.15.rspdir = '' x.15.default = '' o Installation section: when OVERALL_STATE = 0 then do if RunInstall(x.programA) == BAD_RC then exit if RunInstall(x.xcopyProgramB) == BAD_RC then exit Call CheckBoot end In this case, if program A requests a callback, the XCOPY does not rerun after the reboot, whereas it does rerun in the example given previously. ═══ 15.3.4. Enabling LAN CID Utility for Callbacks ═══ To ensure that a CID-enabled program can request a callback, specify a value for the X.n.STATEVAR variable in the LAN CID Utility command file. See Descriptions of Product Variables for more information on state variables. You must also give LAN CID Utility the ability to rerun a CID-enabled program that requests a callback after a reboot. Ensure that the following are true: o If you install with boot diskettes, include THINIFS and CASINSTL in the first state (When OVERALL_STATE = 0) of the installation sequence. This is explained more fully in Installing an Application with Boot Diskettes. o If OS/2 2.x is being installed, THINIFS and CASINSTL must be included after, but in the same state as, both SEMAINT and SEINST. This is explained more fully in Installing the OS/2 2.x Program. Note: Unless you know specifically which return codes a CID-enabled program returns, you must assume that an installation program can return the reboot and callback type of return code to LAN CID Utility. LAN CID Utility must be able to process the callback. ═══ 15.4. Error Processing ═══ CID-enabled programs can indicate error conditions to LAN CID Utility. When an error code is returned, LAN CID Utility can do the following: o Display and log the generic meaning of the error code and then exit the LAN CID Utility command file running on the client. This is the default. o Continue with the next statement in the same state. o Exit the current state and go to another state without rebooting. o Exit the current state and go to another state after rebooting. You can change the default to one of the other actions: o Implement Continue by removing the If statement that precedes the call to RunInstall in the installation sequence. An example is changing if RunInstall(x.laninstr) == BAD_RC then exit to RunInstall(x.laninstr) o Implement Exit the current state and go to another state without rebooting by substituting certain REXX statements after the == BAD_RC. An example is changing if RunInstall(x.laninstr) == BAD_RC then exit to if RunInstall(x.laninstr, 4) == BAD_RC then iterate; The program then goes to the When OVERALL_STATE = 4 statement in the installation sequence. You can specify this action for a CID-enabled program that is the only one listed in a When OVERALL_STATE = n statement in the installation sequence. If other programs are listed, the results are unpredictable, especially if a program that ran before the failing program requested a callback. o Implement Exit the current state and go to another state after a reboot by substituting a call to RebootAndGotoState after the == BAD_RC. An example is changing if RunInstall(x.laninstr) == BAD_RC then exit to if RunInstall(x.laninstr) == BAD_RC then Call RebootAndGotoState(4) The parameter for RebootAndGotoState is the number of the state that you want the program to go to after the reboot, in this case the When OVERALL_STATE = 4 statement in the installation sequence. You can specify this action for a CID-enabled program that is the only one listed in a When OVERALL_STATE = n statement in the installation sequence. If other programs are listed, the results are unpredictable, especially if a program that ran before the failing program requested a callback. See System-Wide CID Recovery, for more information. Note: The REXX program can also encounter certain errors that cause the program to exit to the command line. ═══ 16. Installation Scenarios ═══ This chapter contains scenarios for the following types of installations: o Installing the OS/2 2.x program with or without boot diskettes o Installing an application with boot diskettes o Installing LAPS with or without boot diskettes o Installing LAPS and an application with or without boot diskettes. Each scenario presents the following: o A section of the command file o The steps in the installation sequence o A detailed explanation of each step o An example log file that could be produced by the installation sequence. ═══ 16.1. Installing the OS/2 2.x Program ═══ Following are walkthroughs of an installation scenario used when installing the OS/2 2.x program with and without boot diskettes The LAN CID Utility command file is written to handle installations started from both boot diskettes and fixed disks. The first walkthrough in this section shows an installation started from the fixed disk. The second walkthrough shows an installation started from boot diskettes. ═══ 16.1.1. LAN CID Utility REXX Command File for Installing the OS/2 2.x Program ═══ Following is the pertinent section of the LAN CID Utility REXX command file. It is used both with and without boot diskettes. Each queue (Q1...Q3) contains all the commands listed for an installation sequence. do forever select when OVERALL_STATE = 0 then do | Q1 if BootDriveIsDiskette() == YES then iterate | if RunInstall(x.semaint) == BAD_RC then exit | if RunInstall(x.laps_prep) == BAD_RC then exit | if RunInstall(x.thinifs) == BAD_RC then exit | if RunInstall(x.casinstl) == BAD_RC then exit | Call CheckBoot | end when OVERALL_STATE = 1 then do | Q2 if RunInstall(x.seinst) == BAD_RC then exit | if RunInstall(x.laps == BAD_RC then exit | if RunInstall(x.thinifs) == BAD_RC then exit | if RunInstall(x.casinstl) == BAD_RC then exit | Call CheckBoot | end when OVERALL_STATE = 2 then do | Q3 if RunInstall(x.ifsdel) == BAD_RC then exit | if RunInstall(x.casdelet) == BAD_RC then exit | Call Reboot | end end end For the complete LAN CID Utility REXX command file, see A Sample Command File. Note: 1. The line containing X.LAPS_PREP refers to a previous definition of LAPS in the product-data section where the LAPS parameter /E: was assigned the value prep (/E:PREP). This parameter tells the LAPS installation program that it is running in the production environment (the OS/2 program with the Presentation Manager program) and that the installation is being done to prepare the maintenance system for LAN connectivity. The maintenance system, or maintenance environment, is the OS/2 program running without the Presentation Manager program being loaded or active. 2. The line containing X.LAPS refers to a previous definition of LAPS in the product-specific data section where the LAPS parameter /E: was assigned the value maint (/E:MAINT). This parameter tells the LAPS program that it is running in the maintenance environment. The maintenance system, or maintenance environment, is the OS/2 program running without the Presentation Manager being loaded or active. ═══ 16.1.2. Installing the OS/2 2.x Program without Boot Diskettes ═══ The following is a walkthrough of an installation scenario used when installing the OS/2 2.x program without boot diskettes. This walkthrough shows why the LAN CID Utility command file must have two additional installations of SRVIFS and LAN CID Utility, even if SRVIFS and LAN CID Utility have been previously loaded on the client workstation. This walkthrough explains the callback that SEINST requests as well as its effects on the processing of the LAN CID Utility command file. Note: If you are not using boot diskettes and you want to format the partition where you plan to install the OS/2 2.x program, you must install your SEMAINT files on a drive other than the drive you are formatting. ═══ 16.1.2.1. Installation Sequence for Installing the OS/2 2.x Program without Boot Diskettes ═══ Following is the sequence in which the statements are processed. The vertically listed numbers to the immediate right of the statements correspond to the numbers in the detailed explanation that follows this installation sequence. These numbers are grouped according to the pass (1...4) in which they are processed. Note that the statements in queue 2 are processed twice. Pass # 1 2 3 4 do forever select when OVERALL_STATE = 0 then do 1 | Q1 if BootDriveIsDiskette() == YES then iterate 2 | if RunInstall(x.semaint) == BAD_RC then exit 3 | if RunInstall(x.laps_prep) == BAD_RC then exit 4 | if RunInstall(x.thinifs) == BAD_RC then exit 5 | if RunInstall(x.casinstl) == BAD_RC then exit 6 | Call CheckBoot 7 | end when OVERALL_STATE = 1 then do 8 14 | Q2 if RunInstall(x.seinst) == BAD_RC then exit 9 15 | if RunInstall(x.laps) == BAD_RC then exit 10 16 | if RunInstall(x.thinifs) == BAD_RC then exit 11 17 | if RunInstall(x.casinstl) == BAD_RC then exit 12 18 | Call CheckBoot 13 19 | end when OVERALL_STATE = 2 then do 20 | Q3 if RunInstall(x.ifsdel) == BAD_RC then exit 21 | if RunInstall(x.casdelet) == BAD_RC then exit 22 | Call Reboot 23 | end end end ═══ 16.1.2.2. Details of Installing the OS/2 2.x Program without Boot Diskettes ═══ The user of the workstation runs THINIFS and CASINSTL to gain LAN connectivity to the code server and to install LAN CID Utility initialization statements in the CONFIG.SYS file and STARTUP.CMD. The installation process begins when the system is rebooted. 1. when OVERALL_STATE = 0 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 0. 2. if BootDriveIsDiskette() == YES then iterate This statement instructs LAN CID Utility to go to the next state if the installation was started from diskettes. Because the installation was started from the fixed disk in this example, the next statement in this state is processed. 3. if RunInstall(x.semaint) == BAD_RC then exit This statement instructs LAN CID Utility to install the OS/2 2.x maintenance system. This installation program first backs up the CONFIG.SYS file, STARTUP.CMD, and AUTOEXEC.BAT on the boot drive and then replaces the CONFIG.SYS file with a modified version of the file from the DISK_1 directory of the source path \IMG\OS2V2x. At this point, the new CONFIG.SYS file has neither NetBIOS installed and configured for LAN communications to the server through SRVIFS nor the LAN CID Utility initialization statements. This installation program requests a reboot. Note: SEMAINT backs up the CONFIG.SYS, STARTUP.CMD, and AUTOEXEC.BAT files to the CONFIG.S13, STARTUP.S13, and AUTOEXEC.S13 files respectively. SEINST restores these files to the root directory of the boot drive if they exist in the maintenance directory. Because LAN CID Utility runs from STARTUP.CMD, writing over the file while it is running can cause problems. To solve this problem, LAN CID Utility renames STARTUP.CMD in the maintenance directory from STARTUP.S13 to STARTUP.LCU so that SEINST cannot find and restore it. 4. if RunInstall(x.laps_prep) == BAD_RC then exit This statement instructs LAN CID Utility to install LAPS for the maintenance system. In this step, NetBIOS connectivity is added to the CONFIG.SYS file. This program requests a reboot. 5. if RunInstall(x.thinifs) == BAD_RC then exit This statement instructs LAN CID Utility to install SRVIFS on the client. LAN connectivity to the server is added to the CONFIG.SYS file in this step. This program requests a reboot. 6. if RunInstall(x.casinstl) == BAD_RC then exit This statement specifies to install LAN CID Utility on the client. A SRVREXX statement is added to the end of the CONFIG.SYS file along with additional paths added to the DPATH= and LIBPATH= statements. A CASAGENT statement is also added to the STARTUP.CMD file. 7. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or a callback since the last reboot. None of the installation programs in this state requested a callback, but at least one of them requested a reboot. LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 1 because none of the installation programs requested a callback. If at least one of the installation programs requests a callback, LAN CID Utility reenters OVERALL_STATE = 0. 8. when OVERALL_STATE = 1 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever OVERALL_STATE is equal to 1. 9. if RunInstall(x.seinst) == BAD_RC then exit Because this is the first time through this state, the statement instructs LAN CID Utility to install the OS/2 2.x program. Before the OS/2 2.x program is installed, SEINST restores to the root directory of the boot drive the original CONFIG.SYS file backed up by SEMAINT. This program removes any statements in the CONFIG.SYS file on the boot drive that it cannot interpret, including the SRVIFS statements and the LAN CID Utility SRVREXX statement. This program requests a reboot and a callback. 10. if RunInstall(x.laps) == BAD_RC then exit This statement instructs LAN CID Utility to install LAPS for the production system in the maintenance environment. This program requests a reboot, but not a callback. 11. if RunInstall(x.thinifs) == BAD_RC then exit This statement instructs LAN CID Utility to install SRVIFS on the client. LAN connectivity to the code server is added to the CONFIG.SYS file in this step because SEINST commented out the original statements added by the first SRVIFS installation. This program requests a reboot. 12. if RunInstall(x.casinstl) == BAD_RC then exit This statement specifies to install LAN CID Utility on the client. It also adds a SRVREXX statement to the end of the CONFIG.SYS file because SEINST removed the original SRVREXX statement. 13. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or a callback since the last reboot. In a typical installation, many programs request a reboot, and in this case SEINST also requests a callback. LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 1 again, because SEINST requested a callback. 14. when OVERALL_STATE = 1 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 1. The callback request from SEINST causes OVERALL_STATE to equal 1. With LAN CID Utility, x number of states does not necessarily equate with x number of reboots. Unless you know the internal workings of all the programs you are installing, including whether they request reboots and callbacks, you cannot accurately determine how many times each individual state will be entered or how many reboots will occur. 15. if RunInstall(x.seinst) == BAD_RC then exit On the second time through this state, the statement instructs LAN CID Utility to check whether the installation program needs to be called back. Because SEINST requested a callback, LAN CID Utility processes SEINST again. SEINST now cleans up the maintenance system installed by SEMAINT and LAPS_PREP. This action could not be taken during the first run of SEINST, because many of the DLLs in the directory being cleaned up were locked. This program does not exit until the OS/2 2.x Workplace Shell* has been built. On the second time through, this program does not request a reboot. 16. if RunInstall(x.laps) == BAD_RC then exit On the second time through this state, this statement instructs LAN CID Utility to check whether this installation program needs to be called back. Because it did not request a callback, LAN CID Utility does not run this program again. 17. if RunInstall(x.thinifs) == BAD_RC then exit On the second time through this state, because THINIFS does not have a state variable, this statement causes LAN CID Utility to run THINIFS again. The reason THINIFS does not have a state variable specified is so that the THINIFS parameters can be specified only once. If a state variable was specified in the product-specific data section, that state variable cleared when SRVIFS was installed in OVERALL_STATE = 0. When LAN CID Utility entered OVERALL_STATE = 1 the first time, the SRVIFS installation does not run because its state variable was cleared earlier. If a state variable is not specified in the product-specific data section for any installation program, that program runs any time LAN CID Utility encounters it. If there is any chance that a program would request a callback, you must specify a state variable. This program requests a reboot. 18. if RunInstall(x.casinstl) == BAD_RC then exit On the second time through this state, because CASINSTL does not have a state variable, this statement causes LAN CID Utility to run CASINSTL again. As with THINIFS, the reason CASINSTL does not have a state variable specified is so that the CASINSTL parameters can be specified only once. If a state variable were specified in the product-specific data section, that state variable would have been cleared when LAN CID Utility was installed in OVERALL_STATE = 0. When LAN CID Utility entered OVERALL_STATE = 1 the first time, the LAN CID Utility installation would not have run because its state variable would have been cleared earlier. 19. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or a callback since the last reboot. None of these programs requested a callback, but THINIFS requested a reboot. LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 2. 20. when OVERALL_STATE = 2 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 2. 21. if RunInstall(x.ifsdel) == BAD_RC then exit This statement instructs LAN CID Utility to run IFSDEL, which removes the SRVIFS statements from the CONFIG.SYS file. IFSDEL also erases SRVIFS from the fixed disk. 22. if RunInstall(x.casdelet) == BAD_RC then exit This statement instructs LAN CID Utility to run CASDELET, which removes SRVREXX.EXE and the PATH= and DPATH= additions that were previously made to the CONFIG.SYS file. CASDELET also removes CASAGENT.EXE from STARTUP.CMD. 23. Call Reboot This statement instructs LAN CID Utility to reboot the system. ═══ 16.1.2.3. LAN CID Utility Log File for the OS/2 2.x Program without Boot Diskettes ═══ The following is an example of a LAN CID Utility log file that could be produced from a successful processing of the previous installation scenario: OS/2 2.1 maintenance install is starting. OS/2 2.1 maintenance install was successful. LAPS maintenance install is starting. LAPS maintenance install was successful. SRVIFS requester install is starting. SRVIFS requester install was successful. LAN CID Utility install is starting. LAN CID Utility install was successful. Reboot. OS/2 2.1 install is starting. OS/2 2.1 install was successful. LAPS install is starting. LAPS install was successful. SRVIFS requester install is starting. SRVIFS requester install was successful. LAN CID Utility install is starting. LAN CID Utility install was successful. Reboot. OS/2 2.1 install is starting, REMOTE_INSTALL_STATE=1. OS/2 2.1 install was successful. SRVIFS requester install is starting. SRVIFS requester install was successful. LAN CID Utility install is starting. LAN CID Utility install was successful. Reboot. SRVIFS delete install is starting. SRVIFS delete install was successful. LAN CID Utility delete install is starting. LAN CID Utility delete install was successful. Reboot. ═══ 16.1.3. Installing the OS/2 2.x Program with Boot Diskettes ═══ The following is a walkthrough of an installation scenario used when installing the OS/2 2.x program with boot diskettes. This walkthrough shows how the LAN CID Utility command file handles boot diskettes in installing the OS/2 2.x program. See Installing an Application with Boot Diskettes for information on how the LAN CID Utility command file can handle boot diskettes in relation to the installation of other applications. ═══ 16.1.3.1. Installation Sequence for Installing the OS/2 2.x Program with Boot Diskettes ═══ Following is the sequence in which the statements are processed. The vertically listed numbers to the immediate right of the statements correspond to the numbers in the detailed explanation that follows this installation sequence. These numbers are grouped according to the pass (1...4) in which they are processed. Note that only the first two statements in queue 1 are processed and that the statements in queue 2 are processed twice. Pass # 1 2 3 4 do forever select when OVERALL_STATE = 0 then do 1 | Q1 if BootDriveIsDiskette() == YES then iterate 2 | if RunInstall(x.semaint) == BAD_RC then exit | if RunInstall(x.laps_prep) == BAD_RC then exit | if RunInstall(x.thinifs) == BAD_RC then exit | if RunInstall(x.casinstl) == BAD_RC then exit | Call CheckBoot | end when OVERALL_STATE = 1 then do 3 9 | Q2 if RunInstall(x.seinst) == BAD_RC then exit 4 10 | if RunInstall(x.laps) == BAD_RC then exit 5 11 | if RunInstall(x.thinifs) == BAD_RC then exit 6 12 | if RunInstall(x.casinstl) == BAD_RC then exit 7 13 | Call CheckBoot 8 14 | end when OVERALL_STATE = 2 then do 15 | Q3 if RunInstall(x.ifsdel) == BAD_RC then exit 16 | if RunInstall(x.casdelet) == BAD_RC then exit 17 | Call Reboot 18 | end end end ═══ 16.1.3.2. Details of Installing the OS/2 2.x Program with Boot Diskettes ═══ The installation process starts after the user boots the workstation with the boot diskettes that the administrator created. 1. when OVERALL_STATE = 0 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 0. 2. if BootDriveIsDiskette() == YES then iterate This statement instructs LAN CID Utility to go to the next state if the installation was started from diskettes. Because the installation was started from the diskettes in this example, processing continues from OVERALL_STATE = 1. Note: The iterate instruction is used to return processing to the beginning of the select loop. 3. when OVERALL_STATE = 1 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 1. 4. if RunInstall(x.seinst) == BAD_RC then exit Because this is the first time through this state, this statement instructs LAN CID Utility to install the OS/2 2.x program. If the current operating system on the workstation is being upgraded, this program removes any statements in the CONFIG.SYS file on the boot drive that the program cannot interpret. This program requests a reboot and a callback. 5. if RunInstall(x.laps) == BAD_RC then exit This statement instructs LAN CID Utility to install LAPS for the production system in the maintenance environment. This program requests a reboot, but not a callback. 6. if RunInstall(x.thinifs) == BAD_RC then exit This statement instructs LAN CID Utility to install SRVIFS on the client. LAN connectivity to the code server is added to the CONFIG.SYS file in this step. This program requests a reboot. 7. if RunInstall(x.casinstl) == BAD_RC then exit This statement instructs LAN CID Utility to install LAN CID Utility on the client. It also adds a SRVREXX statement to the end of the CONFIG.SYS file. 8. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or a callback since the last reboot. In a typical installation, many programs request a reboot, and in this case SEINST also requests a callback. LAN CID Utility performs some cleanup and then requests that the diskette be removed from the boot drive. After the diskette has been removed from the boot drive, LAN CID Utility reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 1 again because SEINST requested a callback. 9. when OVERALL_STATE = 1 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 1. The callback request from SEINST causes OVERALL_STATE to equal 1. 10. if RunInstall(x.seinst) == BAD_RC then exit On the second time through this state, this statement instructs LAN CID Utility to check whether this installation program needs to be called back. Because SEINST requested a callback, LAN CID Utility runs this program again. This program does not exit until the OS/2 2.x Workplace Shell has been built. On the second time through, this program does not request a reboot. 11. if RunInstall(x.laps) == BAD_RC then exit On the second time through this state, this statement instructs LAN CID Utility to check whether the installation program needs to be called back. Because the program did not request a callback, LAN CID Utility does not run this program again. 12. if RunInstall(x.thinifs) == BAD_RC then exit On the second time through this state, because THINIFS does not have a state variable, this statement causes LAN CID Utility to run THINIFS again. The reason THINIFS does not have a state variable specified is so that the THINIFS parameters can be specified only once. If a state variable is not specified in the product-specific data section for any installation program, that program runs any time LAN CID Utility encounters it. If there is any chance that a program may request a callback, you must specify a state variable. This program requests a reboot. 13. if RunInstall(x.casinstl) == BAD_RC then exit On the second time through this state, because CASINSTL does not have a state variable, this statement causes LAN CID Utility to run CASINSTL again. The reason CASINSTL does not have a state variable specified is so that the CASINSTL parameters can be specified only once. 14. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or a callback since the last reboot. None of these programs requested a callback, but THINIFS requested a reboot. LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 2. 15. when OVERALL_STATE = 2 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 2. 16. if RunInstall(x.ifsdel) == BAD_RC then exit This statement instructs LAN CID Utility to run IFSDEL, which removes the SRVIFS statements from the CONFIG.SYS file. IFSDEL also erases SRVIFS from the fixed disk. 17. if RunInstall(x.casdelet) == BAD_RC then exit This statement instructs LAN CID Utility to run CASDELET, which removes SRVREXX.EXE and the PATH= and DPATH= additions that were previously made to the CONFIG.SYS file. CASDELET also removes the CASAGENT.EXE from the STARTUP.CMD file. 18. Call Reboot This statement instructs LAN CID Utility to reboot the system. ═══ 16.1.3.3. LAN CID Utility Log File from Installing the OS/2 2.x Program with Boot Diskettes ═══ The following is an example of a LAN CID Utility log file that could be produced from a successful processing of the previous installation scenario: OS/2 2.1 install is starting. OS/2 2.1 install was successful. LAPS install is starting. LAPS install was successful. SRVIFS requester install is starting. SRVIFS requester install was successful. LAN CID Utility install is starting. LAN CID Utility install was successful. Reboot. OS/2 2.1 install is starting, REMOTE_INSTALL_STATE=2. OS/2 2.1 install was successful. SRVIFS requester install is starting. SRVIFS requester install was successful. LAN CID Utility install is starting. LAN CID Utility install was successful. Reboot. SRVIFS delete install is starting. SRVIFS delete install was successful. LAN CID Utility delete install is starting. LAN CID Utility delete install was successful. Reboot. ═══ 16.2. Installing an Application with Boot Diskettes ═══ The following is a walkthrough of an installation scenario used when installing applications other than the OS/2 2.x program with boot diskettes. In this example, Communications Manager/2 was used. The LAN CID Utility command file is written to handle installations started from either the fixed disk or the boot diskettes. This walkthrough shows only the portion started from boot diskettes. This walkthrough shows how the LAN CID Utility command file can handle boot diskettes when installing applications other than the OS/2 2.x program. Other applications are handled differently from the OS/2 2.x program because most other applications require the Presentation Manager program to be active when the installation is started. When boot diskettes are used, the Presentation Manager program is not immediately active. This scenario shows a workaround. This example assumes that the workstation has NetBIOS installed and configured for LAN communications and that the OS/2 2.x program is already installed on the fixed disk. Another scenario, Installing LAPS and an Application with and without Boot Diskettes, handles the case where the OS/2 2.x program is installed on the workstation but LAPS is not. ═══ 16.2.1. LAN CID Utility Command File for Installing an Application with and without Boot Diskettes ═══ Following is the pertinent section of the LAN CID Utility REXX command file. The command file is written to handle installations started from either boot diskettes or the fixed disk. This walkthrough, however, presents only the section of the command file that runs when the installation is started from boot diskettes. Each queue (Q1...Q3) contains all the commands listed for an installation sequence. do forever select when OVERALL_STATE = 0 then do | Q1 if BootDriveIsFixedDisk() == YES then iterate | if RunInstall(x.thinifs) == BAD_RC then exit | if RunInstall(x.casinstl) == BAD_RC then exit | Call CheckBoot | end when OVERALL_STATE = 1 then do | Q2 if RunInstall(x.cmsetup) == BAD_RC then exit | Call CheckBoot | end when OVERALL_STATE = 2 then do | Q3 if RunInstall(x.ifsdel) == BAD_RC then exit | if RunInstall(x.casdelet) == BAD_RC then exit | Call Reboot | end end end ═══ 16.2.2. Installation Sequence for an Application with Boot Diskettes ═══ Following is the sequence in which the statements are processed. The vertically listed numbers to the immediate right of the statements correspond to the numbers in the detailed explanation that follows this installation sequence. These numbers are grouped according to the pass (1...3) in which they are processed. Pass # 1 2 3 do forever select when OVERALL_STATE = 0 then do 1 | Q1 if BootDriveIsFixedDisk() == YES then iterate 2 | if RunInstall(x.thinifs) == BAD_RC then exit 3 | if RunInstall(x.casinstl) == BAD_RC then exit 4 | Call CheckBoot 5 | end when OVERALL_STATE = 1 then do 6 | Q2 if RunInstall(x.cmsetup) == BAD_RC then exit 7 | Call CheckBoot 8 | end when OVERALL_STATE = 2 then do 9 | Q3 if RunInstall(x.ifsdel) == BAD_RC then exit 10 | if RunInstall(x.casdelet) == BAD_RC then exit 11 | Call Reboot 12 | end end end ═══ 16.2.3. Details of Installing an Application with Boot Diskettes ═══ The installation process starts after the user boots the workstation with the boot diskettes that the administrator created. 1. when OVERALL_STATE = 0 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 0. The purpose of this state in the LAN CID Utility command file is to determine if LAN CID Utility and SRVIFS need to be installed on the fixed disk of the workstation. The LAN CID Utility command file reboots the workstation after the user removes the diskette from the boot drive. This causes the workstation to boot from the fixed disk, which in effect activates the Presentation Manager program. If the workstation was booted from the fixed disk, LAN CID Utility and SRVIFS were already installed on the fixed disk and the Presentation Manager program is already active. No further action is necessary, and this state is skipped. 2. if BootDriveIsFixedDisk() == YES then iterate This statement instructs LAN CID Utility to go to the next state if the installation was started from the fixed disk. Because the installation was started from the diskettes in this example, the next statement in this state is processed. 3. if RunInstall(x.thinifs) == BAD_RC then exit This statement instructs LAN CID Utility to install SRVIFS on the client. LAN connectivity to the server is added to the CONFIG.SYS file on the fixed disk of the workstation in this step. This program requests a reboot. 4. if RunInstall(x.casinstl) == BAD_RC then exit This statement instructs LAN CID Utility to install LAN CID Utility on the client. A SRVREXX statement is added to the end of the CONFIG.SYS file on the fixed disk of the workstation along with additional paths added to the DPATH= and LIBPATH= statements. A CASAGENT statement is also added to STARTUP.CMD on the fixed disk of the workstation. 5. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or a callback since the last reboot. None of the installation programs in this state requested a callback, but THINIFS requested a reboot. LAN CID Utility performs some cleanup and then requests that the diskette be removed from the boot drive. After the user removes the diskette, LAN CID Utility reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 1. 6. when OVERALL_STATE = 1 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 1. 7. if RunInstall(x.cmsetup) == BAD_RC then exit This statement instructs LAN CID Utility to install Communications Manager/2. This program requests a reboot, but not a callback. 8. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or a callback since the last reboot. Because CMSETUP requested a reboot, LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 2. 9. when OVERALL_STATE = 2 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 2. 10. if RunInstall(x.ifsdel) == BAD_RC then exit This statement instructs LAN CID Utility to run IFSDEL, which removes the SRVIFS statements from the CONFIG.SYS file. IFSDEL also erases the SRVIFS files from the fixed disk. 11. if RunInstall(x.casdelet) == BAD_RC then exit This statement instructs LAN CID Utility to run CASDELET, which removes SRVREXX.EXE and the PATH= and DPATH= additions that were previously made to the CONFIG.SYS file. CASDELET also removes CASAGENT.EXE from the STARTUP.CMD file. 12. Call Reboot This statement instructs LAN CID Utility to reboot the system. ═══ 16.2.4. LAN CID Utility Log File from Installing an Application with Boot Diskettes ═══ The following is an example of a LAN CID Utility log file that could be produced from a successful processing of the previous installation scenario: SRVIFS requester install is starting. SRVIFS requester install was successful. LAN CID Utility install is starting. LAN CID Utility install was successful. Reboot. CM/2 install is starting. CM/2 install was successful. Reboot. SRVIFS delete install is starting. SRVIFS delete install was successful. LAN CID Utility delete install is starting. LAN CID Utility delete install was successful. Reboot. ═══ 16.3. Installing LAPS with and without Boot Diskettes ═══ Following are walkthroughs of an installation scenario used when installing LAPS with and without boot diskettes. The LAN CID Utility command file is written to handle installations started from both the fixed disk and the boot diskettes. The first walkthrough shows an installation initiated from boot diskettes. The second walkthrough shows an installation initiated from the fixed disk. The installation of LAPS (and only LAPS) with a LAN CID Utility command file is different from the example shown in Installing an Application with Boot Diskettes. For LAPS, you run one state for installations started from the fixed disk or another for installations started from boot diskettes, but never both. With other applications, an additional state was added to handle the installations started from boot diskettes. This example assumes that the workstation has the OS/2 2.x program already installed on the fixed disk. ═══ 16.3.1. LAN CID Utility Command File for Installing LAPS with or without Boot Diskettes ═══ Following is the pertinent section of the LAN CID Utility REXX command file. It is used both with and without boot diskettes. Each queue (Q1, Q2) contains all the commands listed for an installation sequence. do forever select when OVERALL_STATE = 0 then do | Q1 if BootDriveIsFixedDisk() == YES then iterate | if RunInstall(x.laps_maint) == BAD_RC then exit | if RunInstall(x.casdelet) == BAD_RC then exit | Call Reboot | end when OVERALL_STATE = 1 then do | Q2 if RunInstall(x.laps_prod) == BAD_RC then exit | if RunInstall(x.casdelet) == BAD_RC then exit | if RunInstall(x.ifsdel) == BAD_RC then exit | Call Reboot | end end end Note: 1. The line containing X.LAPS_MAINT refers to a previous definition of LAPS in the product-specific data section where the LAPS parameter /E: was assigned the value maint (/E:MAINT). This parameter tells the LAPS program that it is running in the maintenance environment. The maintenance system, or maintenance environment, is the OS/2 program running without the Presentation Manager being loaded or active. 2. The line containing X.LAPS_PROD refers to another previous definition of LAPS in the product-specific data section where the LAPS parameter /E: was assigned the value prod (/E:PROD). This parameter tells the LAPS installation program that it is running in the production environment (the OS/2 program with the Presentation Manager program). ═══ 16.3.2. Installing LAPS with Boot Diskettes ═══ The following is a walkthrough of an installation scenario used when installing LAPS with boot diskettes. ═══ 16.3.2.1. Installation Sequence for LAPS with Boot Diskettes ═══ Following is the sequence in which the statements are processed. The vertically listed numbers to the immediate right of the statements correspond to the numbers in the detailed explanation that follows this installation sequence. These numbers are grouped according to the pass (1) in which they are processed. Pass # 1 do forever select when OVERALL_STATE = 0 then do 1 | Q1 if BootDriveIsFixedDisk() == YES then iterate 2 | if RunInstall(x.laps_maint) == BAD_RC then exit 3 | if RunInstall(x.casdelet) == BAD_RC then exit 4 | Call Reboot 5 | end when OVERALL_STATE = 1 then do | Q2 if RunInstall(x.laps_prod) == BAD_RC then exit | if RunInstall(x.casdelet) == BAD_RC then exit | if RunInstall(x.ifsdel) == BAD_RC then exit | Call Reboot | end end end ═══ 16.3.2.2. Details of Installing LAPS with Boot Diskettes ═══ The installation process starts after the user boots the workstation with the boot diskettes that the administrator created. 1. when OVERALL_STATE = 0 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 0. 2. if BootDriveIsFixedDisk() == YES then iterate This statement instructs LAN CID Utility to go to the next state if the installation was started from the fixed disk. Because the installation was started from the diskettes in this example, the next statement in this state is processed. 3. if RunInstall(x.laps_maint) == BAD_RC then exit This statement instructs LAN CID Utility to install LAPS on the client in the maintenance environment. LAN connectivity to the server is added to the CONFIG.SYS file on the fixed disk of the workstation in this step. This program requests a reboot. 4. if RunInstall(x.casdelet) == BAD_RC then exit This statement instructs LAN CID Utility to delete LAN CID Utility from the client. CASDELET is run here only to remove a SET CAS_ ... line from the CONFIG.SYS file that was added by the RunInstall procedure invoked in the previous step. 5. Call Reboot This statement instructs LAN CID Utility to reboot the workstation after the user removes the diskette from the boot drive. CheckBoot is not called in this case, because from the point of view of the installation started from boot diskettes, this is the only state to be run. OVERALL_STATE = 1 is never processed if the installation is started from the boot diskettes. ═══ 16.3.2.3. LAN CID Utility Log File from Installing LAPS with Boot Diskettes ═══ The following is an example of a LAN CID Utility log file that could be produced from a successful processing of the previous installation scenario: LAPS maintenance install is starting. LAPS maintenance install was successful. LAN CID Utility delete install is starting. LAN CID Utility delete install was successful. Reboot. ═══ 16.3.3. Installing LAPS without Boot Diskettes ═══ The following is a walkthrough of an installation scenario used when installing LAPS without boot diskettes. ═══ 16.3.3.1. Installation Sequence for LAPS without Boot Diskettes ═══ Following is the sequence in which the statements are processed. The vertically listed numbers to the immediate right of the statements correspond to the numbers in the detailed explanation that follows this installation sequence. These numbers are grouped according to the pass (1) in which they are processed. Note that only the first two statements in queue 1 are processed. Pass # 1 do forever select when OVERALL_STATE = 0 then do 1 | Q1 if BootDriveIsFixedDisk() == YES then iterate 2 | if RunInstall(x.laps_maint) == BAD_RC then exit | if RunInstall(x.casdelet) == BAD_RC then exit | Call Reboot | end when OVERALL_STATE = 1 then do 3 | Q2 if RunInstall(x.laps_prod) == BAD_RC then exit 4 | if RunInstall(x.casdelet) == BAD_RC then exit 5 | if RunInstall(x.ifsdel) == BAD_RC then exit 6 | Call Reboot 7 | end end end ═══ 16.3.3.2. Details of Installing LAPS without Boot Diskettes ═══ The user of the workstation runs THINIFS and CASINSTL to gain LAN connectivity to the code server and to install LAN CID Utility initialization statements in the CONFIG.SYS file and the STARTUP.CMD file. The installation process begins when the system is rebooted. 1. when OVERALL_STATE = 0 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 0. 2. if BootDriveIsFixedDisk() == YES then iterate This statement instructs LAN CID Utility to go to the next state if the installation was started from the fixed disk. Because the installation was started from the fixed disk in this example, processing continues from OVERALL_STATE = 1. 3. when OVERALL_STATE = 1 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 1. 4. if RunInstall(x.laps_prod) == BAD_RC then exit This statement instructs LAN CID Utility to install LAPS on the client in the production environment. LAN connectivity to the server is added to or changed in the CONFIG.SYS file on the fixed disk of the workstation in this step. This program requests a reboot. 5. if RunInstall(x.ifsdel) == BAD_RC then exit This statement instructs LAN CID Utility to run IFSDEL, which removes the SRVIFS statements from the CONFIG.SYS file. IFSDEL also erases the SRVIFS files from the fixed disk. 6. if RunInstall(x.casdelet) == BAD_RC then exit This statement instructs LAN CID Utility to run CASDELET, which removes SRVREXX.EXE and the PATH= and DPATH= additions that were previously made to the CONFIG.SYS file. CASDELET also removes CASAGENT.EXE from the STARTUP.CMD file. 7. Call Reboot This statement instructs LAN CID Utility to reboot the system. ═══ 16.3.3.3. LAN CID Utility Log File from Installing LAPS without Boot Diskettes ═══ The following is an example of a LAN CID Utility log file that could be produced from a successful processing of the previous installation scenario: LAPS install is starting. LAPS install was successful. SRVIFS delete install is starting. SRVIFS delete install was successful. LAN CID Utility delete install is starting. LAN CID Utility delete install was successful. Reboot. ═══ 16.4. Installing LAPS and an Application with and without Boot Diskettes ═══ Following are walkthroughs of an installation scenario used when installing LAPS and another application with and without boot diskettes. This example uses Communications Manager/2 as the other application. The LAN CID Utility command file is written to handle installations started from both the fixed disk and boot diskettes. The first walkthrough shows an installation started from boot diskettes. The second walkthrough shows an installation started from the fixed disk. The installation of LAPS, along with other applications with an LAN CID Utility command file that handles installations started from both the fixed disk and boot diskettes, is different from the example shown in Installing an Application with Boot Diskettes and Installing LAPS with and without Boot Diskettes. In this scenario, you would process OVERALL_STATE = 0 for an installation started from the boot diskettes or OVERALL_STATE = 1 for an installation started from the fixed disk, but never both. Then, unlike in Installing LAPS with and without Boot Diskettes, more steps are processed after LAPS is installed. This example assumes that the workstation has the OS/2 2.x program already installed on the fixed disk. ═══ 16.4.1. LAN CID Utility Command File for LAPS and an Application with or without Boot Diskettes ═══ Following is the pertinent section of the LAN CID Utility REXX command file. It is used both with and without boot diskettes. Each queue (Q1...Q4) contains all the commands listed for an installation sequence. do forever select when OVERALL_STATE = 0 then do | Q1 if BootDriveIsFixedDisk() == YES then iterate | if RunInstall(x.laps_maint) == BAD_RC then exit | if RunInstall(x.thinifs) == BAD_RC then exit | if RunInstall(x.casinstl) == BAD_RC then exit | Call RebootAndGotoState(2) | end when OVERALL_STATE = 1 then do | Q2 if RunInstall(x.laps_prod) == BAD_RC then exit | Call CheckBoot | end When OVERALL_STATE = 2 then do | Q3 if RunInstall(x.cmsetup) == BAD_RC then exit | Call CheckBoot | end when OVERALL_STATE = 3 then do | Q4 if RunInstall(x.ifsdel) == BAD_RC then exit | if RunInstall(x.casdelet) == BAD_RC then exit | Call Reboot | end end end Note: 1. The line containing X.LAPS_MAINT refers to a previous definition of LAPS in the product-specific data section where the LAPS parameter /E: was assigned the value maint (/E:MAINT). This parameter tells the LAPS program that it is running in the maintenance environment. The maintenance system, or maintenance environment, is the OS/2 program running without the Presentation Manager being loaded or active. 2. The line containing X.LAPS_PROD refers to another previous definition of LAPS in the product-specific data section where the LAPS parameter /E: was assigned the value prod (/E:PROD). This parameter tells the LAPS installation program that it is running in the production environment (the OS/2 program with the Presentation Manager program). ═══ 16.4.2. Installing LAPS and an Application with Boot Diskettes ═══ The following is a walkthrough of an installation scenario used when installing LAPS and another application with boot diskettes. ═══ 16.4.2.1. Installation Sequence for LAPS and Another Application with Boot Diskettes ═══ Following is the sequence in which the statements are processed. The vertically listed numbers to the immediate right of the statements correspond to the numbers in the detailed explanation that follows this installation sequence. These numbers are grouped according to the pass (1...3) in which they are processed. Note that the statements in queue 2 are not processed. Pass # 1 2 3 do forever select when OVERALL_STATE = 0 then do 1 | Q1 if BootDriveIsFixedDisk() == YES then iterate 2 | if RunInstall(x.laps_maint) == BAD_RC then exit 3 | if RunInstall(x.thinifs) == BAD_RC then exit 4 | if RunInstall(x.casinstl) == BAD_RC then exit 5 | Call RebootAndGotoState(2) 6 | end when OVERALL_STATE = 1 then do | Q2 if RunInstall(x.laps_prod) == BAD_RC then exit | Call CheckBoot | end When OVERALL_STATE = 2 then do 7 | Q3 if RunInstall(x.cmsetup) == BAD_RC then exit 8 | Call CheckBoot 9 | end when OVERALL_STATE = 3 then do 10 | Q4 if RunInstall(x.ifsdel) == BAD_RC then exit 11 | if RunInstall(x.casdelet) == BAD_RC then exit 12 | Call Reboot 13 | end end end ═══ 16.4.2.2. Details of Installing LAPS and Another Application with Boot Diskettes ═══ The installation process starts after the user boots the workstation with the boot diskettes that the administrator created. 1. when OVERALL_STATE = 0 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 0. 2. if BootDriveIsFixedDisk() == YES then iterate This statement instructs LAN CID Utility to go to the next state if the installation was started from the fixed disk. Because the installation was started from the diskettes in this example, the next statement in this state is processed. 3. if RunInstall(x.laps_maint) == BAD_RC then exit This statement instructs LAN CID Utility to install LAPS on the client in the maintenance environment. LAN connectivity to the server is added to the CONFIG.SYS file on the fixed disk of the workstation in this step. This program requests a reboot. 4. if RunInstall(x.thinifs) == BAD_RC then exit This statement instructs LAN CID Utility to install SRVIFS on the client. LAN connectivity to the server is added to the CONFIG.SYS file on the fixed disk of the workstation in this step. This program requests a reboot. 5. if RunInstall(x.casinstl) == BAD_RC then exit This statement specifies to install LAN CID Utility on the client. A SRVREXX statement is added to the end of the CONFIG.SYS file on the fixed disk of the workstation along with additional paths added to the DPATH= and LIBPATH= statements. A CASAGENT statement is also added to STARTUP.CMD on the fixed disk of the workstation. 6. Call RebootAndGotoState(2) This statement instructs LAN CID Utility to perform some cleanup and reboot the system after the user removes the diskette from the boot drive. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 2. Call RebootAndGotoState(2) is used in this case instead of Call CheckBoot, because the program should not enter OVERALL_STATE = 1 when booted from diskettes. Call RebootAndGotoState(n) performs the same function as Call CheckBoot except that instead of incrementing OVERALL_STATE by 1, RebootAndGotoState explicitly sets OVERALL_STATE to the value indicated. 7. when OVERALL_STATE = 2 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 2. 8. if RunInstall(x.cmsetup) == BAD_RC then exit This statement instructs LAN CID Utility to install Communications Manager/2. This program requests a reboot, but not a callback. 9. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or callback since the last reboot. Because CMSETUP requested a reboot, LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 3. 10. when OVERALL_STATE = 3 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 3. 11. if RunInstall(x.ifsdel) == BAD_RC then exit This statement instructs LAN CID Utility to run IFSDEL, which removes the SRVIFS statements from the CONFIG.SYS file. IFSDEL also erases SRVIFS from the fixed disk. 12. if RunInstall(x.casdelet) == BAD_RC then exit This statement instructs LAN CID Utility to run CASDELET, which removes SRVREXX.EXE and the PATH= and DPATH= additions that were previously made to the CONFIG.SYS file. CASDELET also removes CASAGENT.EXE from STARTUP.CMD. 13. Call Reboot This statement instructs LAN CID Utility to reboot the system. ═══ 16.4.2.3. LAN CID Utility Log File from Installing LAPS and Another Application with Boot Diskettes ═══ The following is an example of a LAN CID Utility log file that could be produced from a successful processing of the previous installation scenario: LAPS maintenance install is starting. LAPS maintenance install was successful. SRVIFS requester install is starting. SRVIFS requester install was successful. LAN CID Utility install is starting. LAN CID Utility install was successful. Reboot. CM/2 install is starting. CM/2 install was successful. Reboot. SRVIFS delete install is starting. SRVIFS delete install was successful. LAN CID Utility delete install is starting. LAN CID Utility delete install was successful. Reboot. ═══ 16.4.3. Installing LAPS and an Application without Boot Diskettes ═══ The following is a walkthrough of an installation scenario used when installing LAPS and another application without boot diskettes. ═══ 16.4.3.1. Installation Sequence for LAPS and Another Application without Boot Diskettes ═══ Following is the sequence in which the statements are processed. The vertically listed numbers to the immediate right of the statements correspond to the numbers in the detailed explanation that follows this installation sequence. These numbers are grouped according to the pass (1...3) in which they are processed. Note that the first two statements in queue 1 and all the statements in queue 2 are processed in the first pass. Pass # 1 2 3 do forever select when OVERALL_STATE = 0 then do 1 | Q1 if BootDriveIsFixedDisk() == YES then iterate 2 | if RunInstall(x.laps_maint) == BAD_RC then exit | if RunInstall(x.thinifs) == BAD_RC then exit | if RunInstall(x.casinstl) == BAD_RC then exit | Call RebootAndGotoState(2) | end when OVERALL_STATE = 1 then do 3 | Q2 if RunInstall(x.laps_prod) == BAD_RC then exit 4 | Call CheckBoot 5 | end When OVERALL_STATE = 2 then do 6 | Q3 if RunInstall(x.cmsetup) == BAD_RC then exit 7 | Call CheckBoot 8 | end when OVERALL_STATE = 3 then do 9 | Q4 if RunInstall(x.ifsdel) == BAD_RC then exit 10 | if RunInstall(x.casdelet) == BAD_RC then exit 11 | Call Reboot 12 | end end end ═══ 16.4.3.2. Details of Installing LAPS and Another Application without Boot Diskettes ═══ The user of the workstation runs THINIFS and CASINSTL to gain LAN connectivity to the code server and to install LAN CID Utility initialization statements in the CONFIG.SYS file and STARTUP.CMD. The installation process begins when the system is rebooted. 1. when OVERALL_STATE = 0 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 0. 2. if BootDriveIsFixedDisk() == YES then iterate This statement instructs LAN CID Utility to go to the next state if the installation was started from the fixed disk. Because the installation was started from the fixed disk in this example, processing continues from OVERALL_STATE = 1. 3. when OVERALL_STATE = 1 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 1. 4. if RunInstall(x.laps_prod) == BAD_RC then exit This statement instructs LAN CID Utility to install LAPS on the client in the production environment. LAN connectivity to the server is added to or changed in the CONFIG.SYS file on the fixed disk of the workstation. This program requests a reboot. 5. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or callback since the last reboot. Because LAPS requested a reboot, LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 2. Unlike OVERALL_STATE = 0, Call CheckBoot can be used in this state because the program needs to proceed to the next state when this state is complete. 6. when OVERALL_STATE = 2 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 2. 7. if RunInstall(x.cmsetup) == BAD_RC then exit This statement instructs LAN CID Utility to install Communications Manager/2. This program requests a reboot but not a callback. 8. Call CheckBoot This statement instructs LAN CID Utility to check whether any installation programs requested a reboot or callback since the last reboot. Because CMSETUP requested a reboot, LAN CID Utility performs some cleanup and then reboots the system. When the LAN CID Utility command file begins to run again after the reboot, LAN CID Utility enters OVERALL_STATE = 3. 9. when OVERALL_STATE = 3 then do This statement instructs LAN CID Utility to process the statements between this statement and the corresponding end statement whenever the OVERALL_STATE is equal to 3. 10. if RunInstall(x.ifsdel) == BAD_RC then exit This statement instructs LAN CID Utility to run IFSDEL, which removes the SRVIFS statements from the CONFIG.SYS file. IFSDEL also erases the SRVIFS files from the fixed disk. 11. if RunInstall(x.casdelet) == BAD_RC then exit This statement instructs LAN CID Utility to run CASDELET, which removes SRVREXX.EXE and the PATH= and DPATH= additions that were previously made to the CONFIG.SYS file. CASDELET also removes CASAGENT.EXE from the STARTUP.CMD file. 12. Call Reboot This statement instructs LAN CID Utility to reboot the system. ═══ 16.4.3.3. LAN CID Utility Log File for LAPS and Another Application without Boot Diskettes ═══ The following is an example of a LAN CID Utility log file that could be produced from a successful processing of the previous installation scenario: LAPS install is starting. LAPS install was successful. Reboot. CM/2 install is starting. CM/2 install was successful. Reboot. SRVIFS delete install is starting. SRVIFS delete install was successful. LAN CID Utility delete install is starting. LAN CID Utility delete install was successful. Reboot. ═══ 17. The CASPREP Program, Keywords, and Input Files ═══ This appendix describes CASPREP.CMD, a program shipped on MPTS diskette 3 in the \APPLETS directory. CASPREP is used to compile a Script file in a specific format into a LAN CID Utility REXX command file. The Script file contains keywords, but no REXX syntax. This program enables a user unfamiliar with REXX to create a syntactically correct LAN CID Utility REXX command file. Experienced users can also benefit from using this program. CASPREP is normally run by the administrator on the code server before installation on the client. Alternatively, CASPREP can be run during, instead of before, installation. CASPREP uses two forms for the input files: Basic input file Contains fewer keywords and no default response file. Advanced input file Allows the use of a default response file. See Basic Input File and Advanced Input File for the two sample input files are located in the MPTSAPLT.ZIP pack file in the \APPLETS directory on MPTS diskette 3. Also see CASPREP Run-Time Invocation for information on using CASPREP at run time. CASPREP requires a base file and a user-generated file (either the basic or advanced form). The base file is located in the MPTSAPLT.ZIP pack file in the \APPLETS directory on MPTS diskette 3. You are not required to make any modifications to the base file. CASPREP reads the base and user-generated files, merges the two together, and produces a command file that LAN CID Utility can use. You can define your own base file if you want to add performance hooks, recovery, or user exits that will be common to all command files. ═══ 17.1. Obtaining the Required CASPREP Files ═══ The files required to run the CASPREP program are packed in the file MPTSAPLT.ZIP in the \APPLETS directory on MPTS diskette 3. To unpack the required files, insert MPTS diskette 3 in drive A: and run the following command: PKUNZIP2 A:\APPLETS\MPTSAPLT.ZIP APPLETS\CAS*.* The following files are required to run CASPREP: CASPREP.CMD The CASPREP utility. CASBASE.FIL The base file that the user file is integrated with to create the LAN CID Utility command file. CASADV.FIL A sample advanced input file. CASBASIC.FIL A sample basic input file. See CASPREP for details of the syntax and parameters. ═══ 17.2. CASPREP Run-Time Invocation ═══ You can call CASPREP during, instead of before, installation. Calling it at run time lets you modify a base file without having to rebuild all the command files created from that base file. The command files are built when the installation is initiated. To call CASPREP at run time, follow these steps: 1. Create a REXX command file that calls CASPREP. 2. When the client is enabled for installation using LAN CID Utility, the /CMD parameter on the CASINSTL command must point to the directory containing the REXX command file created in the previous step. 3. When CASPREP completes, check the return code to determine if the installation should continue: o 0 = Successful o 1 = Unsuccessful 4. If the return code is successful, call the LAN CID Utility REXX command file created by CASPREP. 5. If the return code is unsuccessful, exit from the process. See Example REXX Command File for a command file that implements the previous steps. After the created command file starts processing, the procedure is the same as if it had been called directly from CASINSTL. Your directories should be set up as follows: \compile\casprep.cmd Compiler \compile\client.fil Client-specific input file \compile\default.fil Default or general input file \compile\casbase.fil Base input file \compile\client.cmd Invokes the compiler; client-specific \compile\default.cmd Invokes compiler; default or general \client\client.cmd Client-specific; runs the installation Following is a brief explanation: \compile\ The path to where CASPREP and the input files are located. \client\ The path to where the output command file is to be located. client.fil A client-specific input file. default.fil A default input file. When you use a default, the /D parameter is required on the CASINSTL command. \compile\client.cmd The REXX command file that invokes the compiler. In this example, it is named for a specific client. \compile\default.cmd The REXX command file that invokes the compiler. In this example, it is the default command file for clients that do not use the client-specific REXX command file. \client\client.cmd The output command file that performs the installation. casbase.cmd The base file to which CASPREP adds the user-created CLIENT.FIL. The CLIENT.FIL and DEFAULT.FIL files are interchangeable, as are the CLIENT.CMD and DEFAULT.CMD files. The one you choose depends upon your situation. For example, if you want to use the same REXX file for all clients, but use client-specific files for the input file, call CASINSTL with the /D parameter. CASPREP does not find a CLIENT.CMD file in the compile subdirectory. However, because /D is set, CASPREP uses DEFAULT.CMD. The REXX command file checks to see if CLIENT.FIL exists. If so, CLIENT.FIL is used; if not, DEFAULT.FIL is used. Place an additional call to CASINSTL in the first queue element (the When OVERALL_STATE = n function) in the installation sequence of the resulting .CMD file. This action ensures that CASINSTL uses the new command file after the next reboot. Place this call in the installation sequence in the file \COMPILE\CLIENT.FIL. Enablement (first call) --> casinstl /cmd:x:\compile In resultant REXX file --> casinstl /cmd:x:\client The first call refers to either the CASINSTL command that was used for creating the boot diskettes or to the user's invocation of CASINSTL on the client workstation to enable the workstation for an installation started from the fixed disk. ═══ 17.3. Example REXX Command File ═══ Following is an example of a REXX command file to invoke CASPREP during installation. /* */ parse ARG client logfile additional error_string = "An error occurred in processing " client " file ." /********************************************************************/ /* See if a client-specific input file exists */ /********************************************************************/ if stream('x:\compile\' ||client || '.fil','c','query exists') <> '' then clientfile = client || '.fil' /* client file exists use it */ else clientfile = 'default.fil' /* client file does not exist*/ /* use the default.fil */ /********************************************************************/ /* Run CASPREP */ /********************************************************************/ 'cmd /c x:\compile\casprep x:\compile\' ||clientfile || ' x:\client\', || client || '.cmd x:\compile\basefile.cmd' if rc = 0 then /* If the new file was */ 'x:\client\' || client client logfile /* created OK, call it */ else do /* else log the error */ lineout logfile, error_string say error_string /* display error */ casdelet /tu:c: /tu:d: /* delete lcu */ call RxFuncAdd 'AskRemoveDiskIfFloppy', 'CASAGENT', 'ASKREMOVEDISKIFFLOPPY' rc = AskRemoveDiskIfFloppy( ) /* remove diskette if */ /* one is in drive */ x:\exe\V200\setboot /ibd:c: /* reboot */ end Note: 1. When issuing the CASDELET command, you can use more than one /TU parameter to cover different systems installing on different drives. 2. AskRemoveDiskIfFloppy checks to see if the drive is removable and, if it is, asks the user to remove the diskette before the reboot occurs. ═══ 17.4. Keywords ═══ Both the basic and advanced forms of the user-generated Script file use keywords, which are listed as follows: o Common keywords, which can be used in both basic and advanced files. o Basic form keywords o Advanced form keywords ═══ 17.4.1. Common Keywords ═══ You can use common keywords with the basic form and the advanced form. :VARS Defines any variables that you want to define for the command file. :ENDVARS Ends the :VARS keyword. Example: :vars maintdrive=c: bootdrive=d: exepath='x:\exe\V200' :endvars Note: 1. The BOOTDRIVE= and EXEPATH= variables are required for the :VARS keyword. 2. You can use defined variables in any definitions of these keywords. When using previously defined variables in the statements associated with the keywords, always enclose the variable name in quotation marks. :SRVATTCH Defines attaches to server disk drives to access data for installations. Note: 1. The SRVATTCH statement is placed in the LAN CID Utility REXX command file exactly as you enter it. Place the quotation marks exactly where they are to occur in the command file. 2. The SRVATTCH keyword is not placed in an If RunInstall... statement. 3. The plus sign indicating that more programs are to be run in the same state cannot be placed at the end of a statement containing the SRVATTCH keyword. If more programs are to be installed in the same state, place the plus sign at the beginning of the next line. :ENDSRVATTCH Ends the :SRVATTCH keyword. Examples: :srvattch z: \\server1\alias w: server2 :endsrvattch :srvattch= x: \\server1\alias USERLINE Defines a statement that you want to place in an installation sequence. This statement can be placed anywhere in the installation sequence between the INSTALL or :INSTALL keyword and the :ENDINSTALL keyword. Note: 1. The USERLINE statement is placed in the LAN CID Utility REXX command file exactly as you enter it. Place the quotation marks exactly where they are to occur in the command file. 2. The USERLINE keyword is not placed in an If RunInstall... statement. 3. The plus sign indicating that more programs are to be run in the same state cannot be placed at the end of a statement containing a USERLINE keyword. If more programs are to be installed in the same state, place the plus sign at the beginning of the next line. 4. A USERLINE statement can contain a Call Reboot or Call RebootAndGotoState(n) statement. If it does, the USERLINE statement places the Call Reboot or Call RebootAndGotoState(n) statement in the installation sequence immediately followed by a Call CheckBoot statement, which the CASPREP program automatically adds. However, when the LAN CID Utility command file is run, only the first reboot statement occurs, because the workstation reboots before ever reaching the Call CheckBoot statement. Examples: userline='xcopy x:\img\programA c:\apps\programA' userline='xcopy 'd1'\img\programA 'd2'\apps\programA' userline=Call RebootAndGotoState(3) ═══ 17.4.2. Basic Form Keywords ═══ :INSTALL Defines the installation sequence. You can enter the specific product installation commands. Compare this command with the advanced form in topic Advanced Form Keywords. CASPREP adds a statement (if BootDriveIsDiskette() == YES then iterate) to the beginning of any state that will run the OS/2 program SEMAINT. You do not have to add this statement manually in this one location. :ENDINSTALL Ends the :INSTALL keyword. Example: INSTALL (without KEYWORDS parameter) :install x:\img.\progA\progAins /s:x:\img\progA /t:c:\progA + x:\img.\progB\progBins /s:x:\img\progB /t:c:\progB ++ x:\img.\progC\progCins /s:x:\img\progC /t:c:\progC :endinstall A + indicates that the statement is part of this queue or installation sequence. A ++ indicates that this statement is the last in this sequence. ═══ 17.4.3. Advanced Form Keywords ═══ :PROG Begins a product definition. Other keywords are required to make up the definition. Valid keywords are: o NAME o INVOKE o RSPDIR o DEFAULT :ENDPROG Ends the :PROG keyword. Examples: :prog seinst name = OS2V20 invoke = "exepath"\seinst /b:"bootdrive" /s:"os_img" /t:"maintenance" /l1:"os_log"\"client".log /r: rspdir = "os_rsp" default = sample.rsp :endprog :prog programA name = programA invoke = xcopy x:\img\programA c:\apps\programA :endprog :UTILITY Begins a utility definition. Other keywords are required to make up the definition. Valid keywords are: o NAME o INVOKE o RSPDIR o DEFAULT A utility does not have a STATEVAR. :ENDUTILITY Ends the :UTILITY keyword. Example: :utility thinifs name = SRVIFS REQUESTER invoke = "laps_img"\thinifs /S:"laps_img" /t:"ifs_dir" /tu:"bootdrive"\ /l1:"laps_log"\"client".log /req:"client" /srv:server1 /d:"srvifs_d1" :endutility Since a state variable is not specified in the utility data section, a utility runs any time the REXX program encounters it. NAME Indicates a user-defined name for a product or utility. This name must be unique across all products and utilities. Examples: name = OS2V20 name = "os" INVOKE Indicates the fully qualified path, name, and parameters for invoking the installation program for a product. Examples: invoke = "exepath"\seinst /b:"bootdrive" /s:"os_img" /t:"maintenance" /l1:"os_log"\"client".log /r: invoke = x:\EXE\V200\seinst /b:c:/s:x:\prod\os2v20\img /t:c:\service\ /l1:x:\prod\log\client1.log /r: Note: For more information on the /R parameter, see Default Response Files and the Response File Subdirectory. RSPDIR Indicates the path to the default response file for this product. Examples: rspdir = "os_rsp" rspdir = x:\RSP DEFAULT Indicates the name of the default response file for this product. Examples: default = sample.rsp default = "defrsp" :INSTALL KEYWORDS Defines the installation sequence for the advanced form. The KEYWORDS parameter requires either the :PROG or the :UTILITY keyword. Compare this command with the basic form in topic Basic Form Keywords. CASPREP adds a statement (if BootDriveIsDiskette() == YES then iterate) to the beginning of any state that will run the OS/2 program SEMAINT. You do not have to add this statement manually in this one location. A + indicates that the programs are all part of the same queue. Example: INSTALL KEYWORDS :install keywords seinst+laps+thinifs+casinstl ifsdel+casdelet :endinstall :ENDINSTALL Ends the :INSTALL keyword. Note: Incorrectly applying the keywords to the form (basic or advanced) may cause undesired results. Use only the keywords associated with the particular form you are creating. ═══ 17.5. Basic Input File ═══ The following is the basic input file CASBASIC.FIL. It is located in the MPTSAPLT.ZIP pack file in the \APPLETS directory on MPTS diskette 3. When compiled with CASPREP, the basic input file produces a LAN CID Utility REXX command file that is functionally equivalent to CASSKEL.CMD shown in Creating LAN CID Utility REXX Command Files, and A Sample Command File. /* CASPREP Sample Basic input file 2.0 */ :vars bootdrive=c: /* boot drive */ exepath=x:\exe\v210 /* executables path */ maintdrive=c: /* maintenance drive */ maint_dir="maintdrive"\service /* maintenance directory */ dllpath=x:\dll\v210 /* dll paths */ :endvars :srvattch y: \\server1\alias /* Not really used, */ z: server2 /* example only. */ :endsrvattch :install "exepath"\semaint /s:x:\img\os2v21 /t:"maint_dir" /b:"bootdrive" /l1:x:\log\os2v21\"client".log + x:\img\laps\mpts /e:prep /s:x:\img\laps /t:"maint_dir" /tu:"bootdrive" /l1:x:\log\laps\"client".log /r:x:\rsp\laps\lapsrsp.rsp + x:\img\srvifs\thinifs /S:x:\img\srvifs /t:"bootdrive"\srvifsrq /tu:"bootdrive"\ /req:* /srv:server1 /d:x: /l1:x:\log\srvifs\"client".log + x:\img\lcu\casinstl /cmd:x:\client /tu:"bootdrive" /pl:"dllpath" /pa:x:\img\lcu /l1:x:\log\lcu\"client".log /l2:x:\log\lcu\srvifs_req.log /req:"client" ++ "exepath"\seinst /b:"bootdrive" /s:x:\img\os2v21 /t:"maint_dir" /l1:x:\log\os2v21\"client".log /r:x:\rsp\os2v21\"client".rsp + x:\img\laps\mpts /e:maint /s:x:\img\laps /t:"bootdrive"\ /l1:x:\log\laps\"client".log /r:x:\rsp\laps\"client".rsp + x:\img\srvifs\thinifs /s:x:\img\srvifs /t:"bootdrive"\srvifsrq /tu:"bootdrive"\ /l1:x:\log\srvifs\"client".log /req:* /srv:server1 /d:x: + x:\img\lcu\casinstl /cmd:x:\client /tu:"bootdrive" /pl:"dllpath" /pa:x:\img\lcu /l1:x:\log\lcu\"client".log /l2:x:\log\lcu\srvifs_req.log /req:"client" ++ x:\img\ls40\laninstr /req /g:x:\rsp\ls40 /l1:x:\log\ls40\"client".l1 /l2:x:\log\ls40\"client".l2 /r:"client".rsp ++ x:\img\srvifs\ifsdel /t:"bootdrive"\srvifsrq /tu:"bootdrive" + x:\img\lcu\casdelet /pl:"dllpath" /tu:"bootdrive" ++ :endinstall ═══ 17.6. Advanced Input File ═══ The following is the advanced input file CASBASIC.FIL. It is located in the MPTSAPLT.ZIP pack file in the \APPLETS directory on MPTS diskette 3. When compiled with CASPREP, the advanced input file produces a LAN CID Utility REXX command file that is functionally equivalent to CASSKEL.CMD shown in Creating LAN CID Utility REXX Command Files, and A Sample Command File. /* CASPREP Sample Advanced input file 2.0 */ :vars d1=x: /* drive #1 */ d2=y: /* drive #2 (not really */ /* used, example only) */ d3=z: /* drive #3 (not really */ /* used, example only) */ bootdrive=c: /* boot drive */ maintdrive=c: /* maintenance drive */ exepath="d1"\exe\v210 /* executables path */ maint_dir="maintdrive"\service /* maintenance directory */ ifs_dir="bootdrive"\srvifsrq /* SRVIFS requester drive */ dll_dirs="d1"\dll\v210 /* DLL directories */ rsp_dir="d1"\rsp /* Response file directory*/ log_dir="d1"\log /* Log file directory */ img_dir="d1"\img /* Product image directory*/ srvifs_server1=server1 /* SRVIFS server #1 */ srvifs_alias1=\\server1\alias /* SRVIFS alias #1 */ srvifs_server2=server2 /* SRVIFS server #2 */ :endvars /* SRVATTACHES */ :srvattch "d2" "srvifs_alias1" /* Not really used, */ "d3" "srvifs_server2" /* example only. */ :endsrvattch :prog seinst name = OS/2 2.1 invoke = "exepath"\seinst /b:"bootdrive" /s:"img_dir"\os2v21 /t:"maint_dir" /l1:"log_dir"\os2v21\"client".log /r: rspdir = "rsp_dir"\os2v21 default = default.rsp :endprog :prog semaint name = OS/2 2.1 Maintenance invoke = "exepath"\semaint /s:"img_dir"\os2v21 /t:"maint_dir" /b:"bootdrive" /l1:"log_dir"\os2v21\"client".log :endprog :prog laps_prep name = LAPS Maintenance invoke = "img_dir"\laps\mpts /e:prep /s:"img_dir"\laps /t:"maint_dir" /tu:"bootdrive" /l1:"log_dir"\laps\"client".log /r:"rsp_dir"\laps\lapsrsp.rsp :endprog :prog laps name = LAPS invoke = "img_dir"\laps\mpts /e:maint /s:"img_dir"\laps /t:"bootdrive"\ /l1:"log_dir"\laps\"client".log /r: rspdir = "rsp_dir"\laps default = lapsrsp.rsp :endprog :prog laninstr name = LAN Services 4.0 invoke = "img_dir"\ls40\laninstr /req /g:"rsp_dir"\ls40 /l1:"log_dir"\ls40\"client".l1 /l2:"log_dir"\ls40\"client".l2 /r: rspdir = "rsp_dir"\ls40 default = rdr.rsp :endprog :prog thinsrv name = SRVIFS Server invoke = "img_dir"\srvifs\thinsrv /s:"img_dir"\srvifs /t:"bootdrive"\server /tu:"bootdrive"\ /l1:"log_dir"\srvifs\"client".log /u:"rsp_dir"\srvifs\server.lst /r:"rsp_dir"\srvifs\server.ini :endprog :utility thinifs name = SRVIFS Requester invoke = "img_dir"\srvifs\thinifs /S:"img_dir"\srvifs /t:"ifs_dir" /tu:"bootdrive"\ /l1:"log_dir"\srvifs\"client".log /req:* /srv:"srvifs_server1" /d:"d1" :endutility :utility ifsdel name = SRVIFS Delete invoke = "img_dir"\srvifs\ifsdel /t:"ifs_dir" /tu:"bootdrive" :endutility :utility casinstl name = LAN CID Utility invoke = "img_dir"\lcu\casinstl /cmd:"d1"\client /tu:"bootdrive" /pl:"dll_dirs" /pa:"img_dir"\lcu /l1:"log_dir"\lcu\"client".log /l2:"log_dir"\lcu\srvifs_req.log /req:"client" :endutility :utility casdelet name = LAN CID Utility Delete invoke = "img_dir"\lcu\casdelet /pl:"dll_dirs" /tu:"bootdrive" :endutility :install keywords semaint+laps_prep+thinifs+casinstl seinst+laps+thinifs+casinstl laninstr ifsdel+casdelet :endinstall ═══ 17.7. Examples of Using CASPREP Keywords ═══ The following are examples of the installation sections of CASPREP advanced-form input files and the LAN CID Utility REXX command file installation sequences they produce. These examples show how to use some of the keywords and how to produce some of the installation sequences detailed in Installation Scenarios. ═══ 17.7.1. Using CASPREP to Install an Application with Boot Diskettes ═══ The following example corresponds to the installation scenario in Installing an Application with Boot Diskettes, where Communications Manager/2 is used as the other application. :install keywords userline=if BootDriveIsFixedDisk() == YES then iterate +thinifs+casinstl cmsetup ifsdel+casdelet :endinstall Note: Do not place the plus sign, which is the first character in the second line of the installation sequence of the input file, at the end of the first line, because the first line is a USERLINE keyword=value pair. If you place the plus at the end of the first line, the following is generated for the installation section of the command file: IfBootDriveIsFixedDisk() == YES then iterate + This example produces the following command file installation sequence: do forever select when OVERALL_STATE = 0 then do if BootDriveIsFixedDisk() == YES then iterate if RunInstall(x.thinifs) == BAD_RC then exit if RunInstall(x.casinstl) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 1 then do if RunInstall(x.cmsetup) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 2 then do if RunInstall(x.ifsdel) == BAD_RC then exit if RunInstall(x.casdelet) == BAD_RC then exit Call Reboot end end end ═══ 17.7.2. Using CASPREP to Install LAPS ═══ The following example corresponds to the installation scenario shown in Installing LAPS with Boot Diskettes. :install keywords userline=if BootDriveIsFixedDisk() == YES then iterate +laps_maint+casdelet+ userline=Call Reboot laps_prod+casdelet+ifsdel :endinstall Note: 1. Do not place the plus sign, which is the first character in the second line of the installation sequence of the input file, at the end of the first line because the first line is a USERLINE keyword=value pair. If you place the plus at the end of the first line, the following is generated for the installation section of the command file: IfBootDriveIsFixedDisk() == YES then iterate + 2. LAPS_MAINT refers to the parameter /E:MAINT being provided to the LAPS installation program. LAPS_PROD refers to the parameter /E:PROD. This example produces the following command file installation sequence: do forever select when OVERALL_STATE = 0 then do if BootDriveIsFixedDisk() == YES then iterate if RunInstall(x.laps_maint) == BAD_RC then exit if RunInstall(x.casdelet) == BAD_RC then exit Call Reboot Call CheckBoot end when OVERALL_STATE = 1 then do if RunInstall(x.laps_prod) == BAD_RC then exit if RunInstall(x.casdelet) == BAD_RC then exit if RunInstall(x.ifsdel) == BAD_RC then exit Call Reboot end end end Note: The Call CheckBoot statement shown in the first state in the resultant installation sequence has no effect. The Call Reboot statement reboots the workstation before Call CheckBoot is ever called. ═══ 17.7.3. Using CASPREP to Install LAPS and Another Application ═══ The following example corresponds to the installation scenario shown in Installing LAPS and an Application with and without Boot Diskettes. :install keywords userline=if BootDriveIsFixedDisk() == YES then iterate +laps_maint+thinifs+casinstl+ userline=Call RebootAndGotoState(2) laps_prod cmsetup ifsdel+casdelet :endinstall Note: 1. Do not place the plus sign, which is the first character in the second line of the installation sequence of the input file, at the end of the first line because the first line is a USERLINE keyword=value pair. If you place the plus at the end of the first line, the following is generated for the installation section of the command file: IfBootDriveIsFixedDisk() == YES then iterate + 2. LAPS_MAINT refers to the parameter /E:MAINT being provided to the LAPS installation program. LAPS_PROD refers to the parameter /E:PROD. This example produces the following command file installation sequence: do forever select when OVERALL_STATE = 0 then do if BootDriveIsFixedDisk() == YES then iterate if RunInstall(x.laps_maint) == BAD_RC then exit if RunInstall(x.thinifs) == BAD_RC then exit if RunInstall(x.casinstl) == BAD_RC then exit Call RebootAndGotoState(2) Call CheckBoot end when OVERALL_STATE = 1 then do if RunInstall(x.laps_prod) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 2 then do if RunInstall(x.cmsetup) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 3 then do if RunInstall(x.casdelet) == BAD_RC then exit if RunInstall(x.ifsdel) == BAD_RC then exit Call Reboot end end end Note: The Call CheckBoot statement shown in the first state in the resultant installation sequence has no effect. The Call RebootAndGotoState(2) statement will reboot the workstation before Call CheckBoot is ever called. ═══ 18. Migrating from Previous LAN CID Utility Command Files and Directory Structures ═══ It is possible to migrate previous LAN CID Utility command files and directory structures by using the following methods. ═══ 18.1. Migrating NTS/2 LAN CID Utility Command Files ═══ The command files you create for use with the LAN CID Utility program provided with MPTS are slightly different than the command files created for use with the LAN CID Utility program provided with NTS/2. Although the variables and install sections are the same, minor modifications were made to the base section of the command file. The modifications include the addition of the GetOS2Version and SetCIDType functions and a logging enhancement that indicates when an install program is processing a callback. Command files that were written for use with the LAN CID Utility program provided with NTS/2 run properly without modification with the LAN CID Utility program provided with MPTS. However, if you want to take advantage of the GetOS2Version and SetCIDType functions and the logging enhancement, it is necessary to replace the base section of your NTS/2 LAN CID Utility command file with the one provided with the MPTS LAN CID Utility program. This can be done by deleting everything in your NTS/2 LAN CID Utility command file that follows the comment: /*************************************************************/ /* DO NOT MODIFY ANY CODE BELOW THIS LINE !!! */ /*************************************************************/ The base section that was removed should be replaced with the corresponding section provided in the MPTS LAN CID Utility command file CASSKEL.CMD. CASSKEL.CMD can be found in the LCU.ZIP pack file in the \LCU directory on MPTS diskette3 or in the \LCU directory or in the \IMG\LCU directory on the code server. If you want to use only the new GetOS2Version and SetCIDType functions, instead of replacing the base section of your command file, you can add the following line to the AddDLLFunctions procedure at the end of the command file: Call RxFuncAdd 'GetOS2Version', 'CASAGENT', 'GETOS2VERSION' Call RxFuncAdd 'SetCIDType', 'CASAGENT', 'SETCIDTYPE' ═══ 18.2. Migrating from a Previous LAN CID Utility Directory Structure ═══ If you used the LAN CID Utility directory structure provided in early test versions of the NTS/2 product, you can migrate your old LAN CID Utility directory structure to the new recommended directory structure. If you used the LAN CID Utility directory structure provided in Setting Up the Directory Structure on the Code Server, there is no need to change. The difference between the directory structure provided previously and the one recommended here is that the earlier directory structure was split into product directories with file type subdirectories within each product directory. The recommended directory structure splits into file type directories and product subdirectories within each file type directory as needed. To migrate to the new directory structure, you must create the appropriate directories and move the files. This appendix provides two methods for migrating. ═══ 18.2.1. MOVE Method ═══ The first example uses the MOVE command, which saves disk space, but you can use it only if you are moving the files to a different directory structure on the same logical drive. 1. Create the following directories: path\IMG path\CSD path\RSP path\LOG path\EXE\V200 path\DLL\V200 2. Perform the following steps: a. MOVE path\EXE path\EXE\V200 b. MOVE path\DLL path\DLL\V200 3. Perform the following steps for each product: a. MOVE path\product\IMG path\IMG\product b. MOVE path\product\CSD path\CSD\product c. MOVE path\product\RSP path\RSP\product d. MOVE path\product\LOG path\LOG\product ═══ 18.2.2. XCOPY Method ═══ The second example uses the XCOPY command and requires twice as much disk space for each directory that is moved if it is done on the same logical drive. 1. Perform the following steps: a. MD path\EXE\V200 b. MD path\DLL\V200 c. XCOPY path\EXE path\EXE\V200 d. XCOPY path\DLL path\DLL\V200 e. ERASE path\EXE\*.* f. ERASE path\DLL\*.* 2. Perform the following steps for each product: a. XCOPY path\product\IMG path\IMG\product\ /S /E b. XCOPY path\product\CSD path\CSD\product\ /S /E c. XCOPY path\product\RSP path\RSP\product\ /S /E d. XCOPY path\product\LOG path\LOG\product\ /S /E e. Delete the old directory structure under path\product. ═══ 19. Engineering Firm Example ═══ This appendix provides examples of three ways to install products at an engineering firm. By using default command files and response files, you can significantly reduce the number of LAN CID Utility REXX command files and product response files required to install a set of workstations. For example, installing three applications on 100 workstations could require up to 100 LAN CID Utility REXX command files and 300 response files if everything were coded uniquely for each client workstation. Default command files and default response files can reduce these numbers to one command file and three response files, if every workstation is installed and configured exactly the same. Since you probably do not want to configure every workstation exactly the same, the following example is given to show how you can use default command files and default response files along with client-specific command files and response files in a typical installation. ═══ 19.1. Installation for Job-Related Workstations ═══ Suppose the Adondo Engineering Company wants to install the OS/2 2.1 program and various other CID-enabled programs on all 44 of its employees' workstations as well as on two LAN servers (other than the code server). Suppose the company has five secretaries, 35 engineers, and four managers for a total of 44 employee systems, all who have the OS/2 2.1, LAPS, and LAN Server 4.0 programs installed. In addition: o The secretaries have an additional editor and chart graphics package. o The engineers have an additional CAD program. o The managers have an additional planning package and spreadsheet program. o The LAN servers has all the previously listed software as well as a compiler. If all the software is configured the same on all of the workstations, you need four LAN CID Utility REXX command files, one for each type of system: o Secretaries' workstations o Engineers' workstations o Managers' workstations o LAN servers In addition, you need 10 response files, one for each product: Product Name Abbreviation OS/2 2.1 OS2 LAPS LAP OS/2 LAN Requester LR OS/2 LAN Server LS CAD CAD Editor EDT Chart graphics CHR Planning package PLN Spreadsheet SPR Compiler CMP. In this example, the following are assumed: o Each installation group has a separate command file (\CLIENT\group.CMD). o Each product has a separate default response file. o The response files reside in the \RSP\product subdirectory set up for each product being installed, where product is a user-defined name. ═══ 19.1.1. Table for Job-Related Installation ═══ An X in the following table indicates that the product is to be installed on the type of workstation indicated in the Installation Group column. break=fit. ┌───────────────────────────────────────────────────────────────────────┐ │ Table 6. Table of Job-Related Installations │ ├──────────────┬────┬─────┬────┬────┬─────┬─────┬─────┬─────┬─────┬─────┤ │ INSTALLATION │ OS │ LAP │ LR │ LS │ CAD │ EDT │ CHR │ PLN │ SPR │ CMP │ │ GROUP │ │ │ │ │ │ │ │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ SECRETARIES │ X │ X │ X │ │ │ X │ X │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ ENGINEERS │ X │ X │ X │ │ X │ │ X │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ MANAGERS │ X │ X │ X │ │ │ │ │ X │ X │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ LAN SERVERS │ X │ X │ │ X │ X │ X │ X │ X │ X │ X │ └──────────────┴────┴─────┴────┴────┴─────┴─────┴─────┴─────┴─────┴─────┘ ═══ 19.1.2. Files for Job-Related Installation ═══ In this example, the following files are required: \RSP\OS2V21\DEFAULT.RSP \RSP\LS40\RDR.RSP \RSP\LS40\SRV.RSP \RSP\LAPS\DEFAULT.RSP \RSP\CAD\DEFAULT.RSP \RSP\EDIT\DEFAULT.RSP \RSP\CHART\DEFAULT.RSP \RSP\PLAN\DEFAULT.RSP \RSP\SPREAD\DEFAULT.RSP \RSP\COMPILE\DEFAULT.RSP \CLIENT\SEC.CMD \CLIENT\ENG.CMD \CLIENT\MGR.CMD \CLIENT\SRV.CMD ═══ 19.2. Installation for Additional Products on Selected Workstations ═══ Suppose some of the employees want additional software installed, but they still want their workstations configured the same way. The employees request the following changes: o One of the engineers, Pat, wants the chart graphics. o Another engineer, Shinya, wants the chart graphics and the compiler. o One of the secretaries, Principio, wants the spreadsheet. o Two of the managers, Carolyn and Ernst, want the chart graphics. These changes require the same 10 response files as those in the job-related example, but now you need nine LAN CID Utility REXX command files (the same four from before plus one each for Pat, Shinya, Principio, Carolyn, and Ernst). In this example, the following are assumed: o Each installation group has a separate command file (\CLIENT\group.CMD). o Each unique client has a separate command file (\CLIENT\client.CMD). o The command files for each unique client are in the same directory as their installation group. o Each product has a separate response file. o The response files reside in the \RSP\product subdirectory set up for each product being installed, where product is a user-defined name. ═══ 19.2.1. Table for Additional Products Installation ═══ An X in the table that follows indicates that the product is to be installed on the type of workstation indicated in the Installation Group column. A # indicates that an additional product is to be installed installed on the client workstation indicated in the Installation Group column. break=fit. ┌───────────────────────────────────────────────────────────────────────┐ │ Table 7. Table of Installations for Additional Products │ ├──────────────┬────┬─────┬────┬────┬─────┬─────┬─────┬─────┬─────┬─────┤ │ INSTALLATION │ OS │ LAP │ LR │ LS │ CAD │ EDT │ CHR │ PLN │ SPR │ CMP │ │ GROUP │ │ │ │ │ │ │ │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ SECRETARIES │ X │ X │ X │ │ │ X │ X │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Principio │ │ │ │ │ │ │ │ │ # │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ ENGINEERS │ X │ X │ X │ │ X │ │ X │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Shinya │ │ │ │ │ │ │ # │ │ │ # │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Pat │ │ │ │ │ │ │ # │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ MANAGERS │ X │ X │ X │ │ │ │ │ X │ X │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Carolyn │ │ │ │ │ │ │ # │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Ernst │ │ │ │ │ │ │ # │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ LAN SERVERS │ X │ X │ │ X │ X │ X │ X │ X │ X │ X │ └──────────────┴────┴─────┴────┴────┴─────┴─────┴─────┴─────┴─────┴─────┘ ═══ 19.2.2. Files for Additional Products Installation ═══ In this example, the following files are required: \RSP\OS2V21\DEFAULT.RSP \RSP\LS40\RDR.RSP \RSP\LS40\SRV.RSP \RSP\LAPS\DEFAULT.RSP \RSP\CAD\DEFAULT.RSP \RSP\EDIT\DEFAULT.RSP \RSP\CHART\DEFAULT.RSP \RSP\PLAN\DEFAULT.RSP \RSP\SPREAD\DEFAULT.RSP \RSP\COMPILE\DEFAULT.RSP \CLIENT\SEC.CMD \CLIENT\PRINCIPI.CMD \CLIENT\ENG.CMD \CLIENT\PAT.CMD \CLIENT\SHINYA.CMD \CLIENT\MGR.CMD \CLIENT\CAROLYN.CMD \CLIENT\ERNST.CMD \CLIENT\SRV.CMD ═══ 19.3. Installation with Customized Configuration on Certain Workstations ═══ Suppose some of the employees want the software configured differently. They requested the following differences: o Two of the secretaries, Principio and Mary Jo, want additional fonts for the editor. o Mary Jo also wants Gant charts from the chart graphics package. o Two of the engineers, Gamala and Jeff, want the math coprocessor support in the CAD program. o Shinya, an engineer, wants LAPS configured for both Token-Ring and Ethernet. o One of the managers, Carolyn, wants Gant charts configured for both the planning package and the chart graphics. o Another manager, Troy, wants the programming support in the spreadsheet. Now you need 19 response files and nine command files (the same nine command files and 10 response files listed in the preceding example in addition to an extra response file for each product that each person requested to be configured differently). In this example, the following are assumed: o Each installation group has a separate command file (\CLIENT\group.CMD). o Each unique client has a separate command file (\CLIENT\client.CMD). o Each product has a separate default response file. o Each client requesting a unique configuration has a separate response file. o The response files reside in the \RSP\product subdirectory set up for each product being installed, where product is a user-defined name. ═══ 19.3.1. Table for Customized Configuration ═══ An X in the chart that follows indicates that the product is to be installed on the type of workstation indicated in the Installation Group column. A # indicates that an additional product is to be installed on the client workstation indicated in the Installation Group column. A $ indicates that the product is to be configured differently from the default for the client workstation. break=fit. ┌───────────────────────────────────────────────────────────────────────┐ │ Table 8. Table of Installations for Customized Configurations │ ├──────────────┬────┬─────┬────┬────┬─────┬─────┬─────┬─────┬─────┬─────┤ │ INSTALLATION │ OS │ LAP │ LR │ LS │ CAD │ EDT │ CHR │ PLN │ SPR │ CMP │ │ GROUP │ │ │ │ │ │ │ │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ SECRETARIES │ X │ X │ X │ │ │ X │ X │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Principio │ │ │ │ │ │ $ │ │ │ # │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Mary Jo │ │ │ │ │ │ $ │ $ │ │ # │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ ENGINEERS │ X │ X │ X │ │ X │ │ X │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Shinya │ │ $ │ │ │ │ │ # │ │ │ # │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Pat │ │ │ │ │ │ │ # │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Gamala │ │ │ │ │ $ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Jeff │ │ │ │ │ $ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ MANAGERS │ X │ X │ X │ │ │ │ │ X │ X │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Carolyn │ │ │ │ │ │ │ #$ │ $ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Ernst │ │ │ │ │ │ │ # │ │ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ Troy │ │ │ │ │ │ │ │ │ $ │ │ ├──────────────┼────┼─────┼────┼────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ LAN SERVERS │ X │ X │ │ X │ X │ X │ X │ X │ X │ X │ └──────────────┴────┴─────┴────┴────┴─────┴─────┴─────┴─────┴─────┴─────┘ ═══ 19.3.2. Files for Customized Configuration ═══ In this example, the following files are required: \RSP\OS2V21\DEFAULT.RSP \RSP\LS40\RDR.RSP \RSP\LS40\SRV.RSP \RSP\LAPS\DEFAULT.RSP \RSP\LAPS\SHINYA.RSP \RSP\CAD\DEFAULT.RSP \RSP\CAD\GAMALA.RSP \RSP\CAD\JEFF.RSP \RSP\EDIT\DEFAULT.RSP \RSP\EDIT\PRINCIPI.RSP \RSP\EDIT\MARYJO.RSP \RSP\CHART\DEFAULT.RSP \RSP\CHART\MARYJO.RSP \RSP\CHART\CAROLYN.RSP \RSP\PLAN\DEFAULT.RSP \RSP\PLAN\CAROLYN.RSP \RSP\SPREAD\DEFAULT.RSP \RSP\SPREAD\TROY.RSP \RSP\COMPILE\DEFAULT.RSP \CLIENT\SEC.CMD \CLIENT\PRINCIPI.CMD \CLIENT\ENG.CMD \CLIENT\PAT.CMD \CLIENT\SHINYA.CMD \CLIENT\MGR.CMD \CLIENT\CAROLYN.CMD \CLIENT\ERNST.CMD \CLIENT\SRV.CMD ═══ 19.4. Recommendations ═══ Selectively installing nine software products across the 44 client workstations and two LAN Servers in this example requires nine LAN CID Utility REXX command files and 19 response files. If you created unique command files and response files for every workstation in this example, however, you have 46 command files and 208 response files. Extending the example to fit a large installation, the number of command files and response files required could reach into the thousands. This large number makes it important to plan your installation carefully so that you understand and use all the facilities provided by LAN CID Utility. ═══ 19.5. Creating the Boot Diskettes ═══ Now that the needed files are identified, implementation is next. Assuming that everyone does an installation started from boot diskettes, you must create four different sets of boot diskettes, one each for secretaries, engineers, managers, and LAN servers. The suggested THINIFS command for all the boot diskettes contains the /REQ:*P parameter, so that the user of the workstation is prompted for the requester name. You can create the diskettes once and duplicate them for each workstation or pass them around to each workstation. See THINIFS for more information. If you look at the file names given previously, the secretaries' default REXX command file is \CLIENT\SEC.CMD. The CASINSTL command for the secretaries' boot diskettes contains: /D:SEC.CMD The CASINSTL command for the engineers' boot diskettes contains: /D:ENG.CMD The CASINSTL command for the managers' boot diskettes contains: /D:MGR.CMD The CASINSTL command for the LAN server's boot diskettes contains: /D:SRV.CMD See CASINSTL for more information. Run the following THINIFS command on all the boot diskettes: THINIFS /S:C:\IMG\SRVIFS /T:A: /TU:A: /REQ:*P /SRV:SERVER1 /D:X For the secretaries' boot diskettes, run the following CASINSTL command: CASINSTL /CMD:X:\CLIENT /D:SEC.CMD /TU:A: /PA:X:\IMG\LCU /PL:X:\DLL\V210 /L2:X:\LOG\LCU\SRVIFS_REQ.LOG For the engineers' boot diskettes, run the following CASINSTL command: CASINSTL /CMD:X:\CLIENT /D:ENG.CMD /TU:A: /PA:X:\IMG\LCU /PL:X:\DLL\V210 /L2:X:\LOG\LCU\SRVIFS_REQ.LOG For the managers' boot diskettes, run the following CASINSTL command: CASINSTL /CMD:X:\CLIENT /D:MGR.CMD /TU:A: /PA:X:\IMG\LCU /PL:X:\DLL\V210 /L2:X:\LOG\LCU\SRVIFS_REQ.LOG For the LAN servers' boot diskettes, run the following CASINSTL command: CASINSTL /CMD:X:\CLIENT /D:SRV.CMD /TU:A: /PA:X:\IMG\LCU /PL:X:\DLL\V210 /L2:X:\LOG\LCU\SRVIFS_REQ.LOG ═══ 19.6. Creating the LAN CID Utility REXX Command Files ═══ The next step after creating the boot diskettes is to create the LAN CID Utility REXX command files. ═══ 19.6.1. Example Command File for All Engineers ═══ The following is an example of a section of the default command file for the engineers. bootdrive='c:' configsys = bootdrive || '\CONFIG.SYS' exepath = 'x:\exe\V210' x.seinst = 1 x.1.name='OS/2 2.1' x.1.statevar = 'CAS_' || x.1.name x.1.instprog = exepath || '\seinst ', ' /b:' || bootdrive || ' ', ' /s:x:\img\os2v21 ', ' /t:c:\service ', '/l1:x:\log\os2v21\' || client || '.log ', ' /r:' x.1.rspdir = 'x:\rsp\os2v21' x.1.default = 'default.rsp' x.laps = 2 x.2.name='LAPS' x.2.statevar = 'CAS_' || x.2.name x.2.instprog = 'x:\img\laps\mpts ', ' /e:maint ', ' /s:x:\img\laps ', ' /t:' || bootdrive || '\ ', '/l1:x:\log\laps\' || client || '.log ', ' /r:' x.2.rspdir = 'x:\rsp\laps' x.2.default = 'lapsrsp.rsp' x.laninstr = 3 x.3.name='LS 4.0' x.3.statevar = 'CAS_' || x.3.name x.3.instprog = 'z:\img\ls40\laninstr ', ' /req ', '/l1:z:\log\ls40\' || client || '.L1 ', '/l2:z:\log\ls40\' || client || '.L2 ', ' /g:z:\rsp\ls40 ', ' /r:' x.3.rspdir = 'z:\rsp\ls40' x.3.default = 'req.rsp' x.cad = 4 x.4.name='CAD' x.4.statevar = 'CAS_' || x.4.name x.4.instprog = 'x:\img\cad\cadinst ', ' /s:x:\img\cad ', ' /t:c:\cad ', '/l4:x:\log\cad\' || client || '.log ', ' /r:' x.4.rspdir = 'x:\rsp\cad' x.4.default = 'default.rsp' . . . do forever select when OVERALL_STATE = 0 then do if RunInstall(x.seinst) == BAD_RC then exit if RunInstall(x.laps) == BAD_RC then exit if RunInstall(x.thinifs) == BAD_RC then exit if RunInstall(x.casinstl) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 1 then do if RunInstall(x.laninstr) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 2 then do if RunInstall(x.cad) == BAD_RC then exit Call CheckBoot end . . . end end ═══ 19.6.2. Example Command File for One Engineer ═══ The following is an example of a command file for an engineer, Pat, who required additional software. It is assumed that the product-specific data in this case is duplicated from the default command file with one addition for the chart graphics: x.seinst = 5 x.5.name='CHART' x.5.statevar = 'CAS_' || x.5.name x.5.instprog = 'x:\img\chart\chartins ', ' /s:x:\img\chart ', ' /t:c:\chart ', '/l4:x:\log\chart\' || client || '.log ', ' /r:' x.5.rspdir = 'x:\rsp\chart' x.5.default = 'default.rsp' . . . do forever select when OVERALL_STATE = 0 then do if RunInstall(x.seinst) == BAD_RC then exit if RunInstall(x.laps) == BAD_RC then exit if RunInstall(x.thinifs) == BAD_RC then exit if RunInstall(x.casinstl) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 1 then do if RunInstall(x.laninstr) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 2 then do if RunInstall(x.cad) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 3 then do if RunInstall(x.chart) == BAD_RC then exit Call CheckBoot end . . . end end ═══ 20. Example Steps for Installing the OS/2 2.x Program ═══ This appendix contains two examples of the steps needed to install the OS/2 2.x program on client workstations using LAN CID Utility. After you understand these steps, you can modify them to fit your situation. The examples show you how to: 1. Create the directory structure on the code server. 2. Load the LAN CID Utility, SRVIFS, and MPTS product images on the code server. 3. Install the SRVIFS server on the code server. 4. Load the OS/2 2.x product images on the code server. 5. Obtain the OS/2 2.x modules required by LAN CID Utility. 6. Create OS/2 2.x and LAPS response files. 7. Create the LAN CID Utility command file. 8. Create boot diskettes. 9. Use the boot diskettes to initiate the LAN CID Utility redirected installation of the OS/2 2.x program on the client workstation. The first example shows the steps needed to install a version of the OS/2 2.x program that requires Service Pak fixes for the redirected installation utilities. It is known that the OS/2 Operating System Version 2.00 requires a Service Pak. The second example shows the steps needed to install a version of the OS/2 2.x program that does not require Service Pak fixes for the redirected installation utilities. In both examples, you need to know the name of the workstation that is to be the code server; in the examples, it is called SERVER1. Also, in both examples, all of the code related to installation is installed in the C:\CID directory. This directory has shared ReadWrite privileges. The access method in Limited Security is not implemented. The examples assume that the target workstation and the code server communicate through the Token-Ring. Another assumption is that the fixed disk on the target workstation is formatted before the OS/2 2.x program is installed. ═══ 20.1. Example Steps for Installing the OS/2 Operating System Version 2.00 Program ═══ The following steps show you one way to install the OS/2 Operating System Version 2.00 on client workstations using LAN CID Utility. These steps show you how to load the code server and how to create and use boot diskettes to install the OS/2 Operating System Version 2.00 on client workstations. To perform these steps, you need the MPTS diskettes, the OS/2 Operating System Version 2.00 diskettes, and an OS/2 2.0 Service Pak. 1. Install LAPS on the code server. Configure LAPS for NetBIOS and Token-Ring. See the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide for more information. 2. Make the recommended directory structure on the code server. Create the following directories and subdirectories: \SERVER \CID \CID\EXE \CID\EXE\V200 \CID\DLL \CID\DLL\V200 \CID\CliENT \CID\CSD \CID\CSD\OS2V20 \CID\CSD\OS2V20\CSD1 \CID\IMG \CID\IMG\OS2V20 \CID\IMG\LAPS \CID\IMG\LCU \CID\IMG\SRVIFS \CID\LOG \CID\LOG\OS2V20 \CID\LOG\LAPS \CID\LOG\LCU \CID\LOG\SRVIFS \CID\RSP\OS2V20 \CID\RSP\LAPS 3. Copy LAN CID Utility and SRVIFS to the product images directory. Insert MPTS diskette 3 in drive A: and issue the following commands: PKUNZIP2 A:\LCU\LCU.ZIP C:\CID\IMG\LCU PKUNZIP2 A:\SRVIFS\SRVIFS.ZIP C:\CID\IMG\SRVIFS 4. Copy the MPTS diskette image to the product images directory. Insert MPTS diskette 1 into drive A: and issue the following command: A:\LAPSDISK A:\ C:\CID\IMG\LAPS 5. Create the response file (the SRVIFS configuration (.INI) file) for the SRVIFS server. a. Insert MPTS diskette 3 in drive A: and issue the following commands: PKUNZIP2 A:\SAMPLE\SAMPLE.ZIP C:\SERVER SAMPLE\SERVICE.INI RENAME C:\SERVER\SERVICE.INI SERVER1.INI b. Edit C:\SERVER\SERVER1.INI as follows: o Change Authlist = c:\srvifs\service.lst to Authlist = c:\server\server1.lst o Change Path = c:\ to Path = c:\cid o Remove the three alias= read ... lines at the end of the file: alias= readonly,single,cid,c:\cid alias= readonly,single,img,c:\cid\img alias= readwrite,perclient,csd,c:\cid\csd 6. Create the SRVIFS server authorization list file. Use an editor to create the file C:\SERVER\SERVER1.LST with the following contents: client1 client2 7. Install the SRVIFS server with THINSRV. Issue the following command: C:\CID\SRVIFS\THINSRV /R:C:\SERVER\SERVER1.INI /T:C:\SERVER /S:C:\CID\SRVIFS /TU:C: /U:C:\SERVER\SERVER1.LST 8. Copy the OS/2 2.0 and OS/2 2.0 Service Pak diskette images. a. Insert OS/2 2.0 diskette 2 in drive A: and issue the following command: COPY A:\UNPACK*.EXE C:\CID\EXE\V200 b. Insert OS/2 2.0 diskette 7 (diskette 8 in some DBCS countries) into drive A: and issue the following command: C:\CID\EXE\V200\UNPACK A:\CID C:\CID\EXE\V200 /N:SEIMAGE.EXE c. If replacement diskettes were shipped with the OS/2 2.0 Service Pak, remove the corresponding diskettes from the set of OS/2 2.0 diskettes and replace them with the OS/2 2.0 Service Pak replacement diskettes. d. Issue the following command to copy the OS/2 2.0 product images: C:\CID\EXE\V200\SEIMAGE /T:C:\CID\IMG\OS2V20 /S:A: OS/2 2.0 diskettes are loaded in order with a prompt for each. e. Insert the first OS/2 2.0 Service Pak diskette in drive A: and issue the following command for it and for each subsequent Service Pak diskette: XCOPY A: C:\CID\CSD\OS2V20\CSD1 /S f. Issue the following command to unpack the OS/2 2.0 redirected installation modules from the OS/2 2.0 diskette images: \CID\IMG\LCU\GETOSCID C:\CID\IMG\OS2V20 C:\CID\EXE\V200 Note: The GETOSCID command unpacks SEIMAGE.EXE again. 9. Obtain the OS/2 2.0 modules required by LAN CID Utility. a. Issue the following command to unpack the required REXX modules from the OS/2 2.0 diskette images: \CID\IMG\LCU\GETREXX C:\CID\IMG\OS2V20 C:\CID\DLL\V200 b. Issue the following command to unpack the SETBOOT and XCOPY modules from the OS/2 2.0 diskette images: \CID\IMG\LCU\GETBOOT C:\CID\IMG\OS2V20 C:\CID\EXE\V200 10. Obtain the Service Pak fixes for the modules previously unpacked from the OS/2 2.0 product images. Issue the following command to retrieve the correct level of the required OS/2 2.0 modules from the Service Pak if they exist in the Service Pak: \CID\IMG\LCU\GETFIX C:\CID\CSD\OS2V20\CSD1 C:\CID\EXE\V200 11. Create the OS/2 2.0 response file DEFAULT.RSP. a. Issue one of the following commands to retrieve the OS/2 2.0 sample response file: MOVE C:\CID\EXE\V200\SAMPLE.RSP \CID\RSP\OS2V20 or COPY C:\CID\RSP\OS2V20\SAMPLE.RSP C:\CID\RSP\OS2V20\DEFAULT.RSP b. Edit C:\CID\RSP\OS2V20\DEFAULT.RSP and change the following keywords to the values indicated: ExitOnError=1 FormatPartition=1 12. Obtain the LAPS response file. Insert MPTS diskette 3 in drive A: and issue the following command: PKUNZIP2 A:\SAMPLE\SAMPLE.ZIP C:\CID\RSP\LAPS SAMPLE\LAPSRSP.RSP 13. Create the LAN CID Utility command file, named DEFAULT.CMD. a. Issue the following command: COPY C:\CID\IMG\LCU\CASSKEL.CMD C:\CID\CliENT\DEFAULT.CMD b. Edit C:\CID\CliENT\DEFAULT.CMD as follows: o Change exepath = 'X:\EXE\V210' dllpath = 'X:\DLL\V210' os2dir = 'OS2V21' x.1.name='OS/2 2.1' x.2.name='OS/2 2.1 Maintenance' to exepath = 'X:\EXE\V200' dllpath = 'X:\DLL\V200;' os2dir = 'OS2V20' x.1.name='OS/2 2.0' x.2.name='OS/2 2.0 Maintenance' o Remove the lines if RunInstall(x.laninstr) == BAD_RC, exit up through and including when OVERALL_STATE = 3 then do 14. Create the boot diskettes. Issue the following commands in order. After SEDISK creates the second diskette, leave it in the diskette drive so that the other programs can modify it. a. Create the diskettes: C:\CID\EXE\V200\SEDISK /S:C:\CID\IMG\OS2V20 /T:A: b. Install LAPS: C:\CID\IMG\LAPS\THINLAPS C:\CID\IMG\LAPS A: IBMTOK.NIF c. Install the SRVIFS requester: C:\CID\IMG\SRVIFS\THINIFS /T:A: /TU:A: /S:C:\CID\IMG\SRVIFS /REQ:* /SRV:SERVER1 /D:X d. Install LAN CID Utility: C:\CID\IMG\LCU\CASINSTL /TU:A: /CMD:X:\CliENT /PA:X:\IMG\LCU /PL:X:\DLL\V200; /L2:X:\LOG\LCU\SRVIFS_REQ.LOG /D /REQ:*P 15. Reboot the code server to start the SRVIFS server. 16. At the client workstation, perform the following setup: Note: If you make two copies of the boot diskettes, you can install two client workstations (CliENT1 and CliENT2) at the same time. a. Insert the first boot diskette (diskette 0) into drive A: of the workstation and then reboot. b. Insert boot diskette 1 when prompted. c. Enter a workstation name when prompted (CliENT1 or CliENT2). d. Remove the diskette from drive A: only when prompted. e. When the installation is complete, OS/2 2.0 and LAPS should be installed and active on the client workstation. ═══ 20.2. Example Steps for Installing Versions of the OS/2 2.x Program That Do Not Require Service Paks ═══ The following steps show you one way to install the OS/2 2.x program on client workstations using LAN CID Utility. This example assumes that the version of OS/2 2.x being installed does not require Service Pak fixes for the redirected installation modules. These steps show you how to load the code server and how to create and use boot diskettes to install the OS/2 2.x program on client workstations. To perform these steps, you need the MPTS diskettes and the OS/2 2.x diskettes, where OS/2 2.x is OS/2 Operating System Version 2.00.1 or higher. Only as an example, these steps use OS/2 2.11 for creating the directory structures. A directory name that matches the version you actually have should be substituted for \V211 and \OS2V211 when you perform the steps. It is assumed that the code server is running the same version of OS/2 as the one being copied to it. If this is not the case, after UNPACK*.EXE is copied to the \EXE\V2xx directory, this directory must be made the current directory. An alternative is to add the \EXE\V2xx directory to the current PATH BEFORE the \OS2 directory. This is necessary so that the proper version of the UNPACK*.EXE programs are used to unpack the required files. 1. Install LAPS on the code server. Configure LAPS for NetBIOS and Token-Ring. See the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide for more information. 2. Make the recommended directory structure on the code server. Create the following directories and subdirectories: \SERVER \CID \CID\EXE \CID\EXE\V211 \CID\DLL \CID\DLL\V211 \CID\CliENT \CID\IMG \CID\IMG\OS2V211 \CID\IMG\LAPS \CID\IMG\LCU \CID\IMG\SRVIFS \CID\LOG \CID\LOG\OS2V211 \CID\LOG\LAPS \CID\LOG\LCU \CID\LOG\SRVIFS \CID\RSP\OS2V211 \CID\RSP\LAPS 3. Copy LAN CID Utility and SRVIFS to the product images directory. Insert MPTS diskette 3 in drive A: and issue the following commands: PKUNZIP2 A:\LCU\LCU.ZIP C:\CID\IMG\LCU PKUNZIP2 A:\SRVIFS\SRVIFS.ZIP C:\CID\IMG\SRVIFS 4. Copy the MPTS diskette image to the product images directory. Insert MPTS diskette 1 into drive A: and issue the following command: A:\LAPSDISK A:\ C:\CID\IMG\LAPS 5. Create the response file (the SRVIFS configuration (.INI) file) for the SRVIFS server. a. Insert MPTS diskette 3 in drive A: and issue the following commands: PKUNZIP2 A:\SAMPLE\SAMPLE.ZIP C:\SERVER SAMPLE\SERVICE.INI RENAME C:\SERVER\SERVICE.INI SERVER1.INI b. Edit C:\SERVER\SERVER1.INI as follows: o Change Authlist = c:\srvifs\service.lst to Authlist = c:\server\server1.lst o Change Path = c:\ to Path = c:\cid o Remove the three alias= read ... lines at the end of the file: alias= readonly,single,cid,c:\cid alias= readonly,single,img,c:\cid\img alias= readwrite,perclient,csd,c:\cid\csd 6. Create the SRVIFS server authorization list file. Use an editor to create the file C:\SERVER\SERVER1.LST with the following contents: client1 client2 7. Install the SRVIFS server with THINSRV. Insert MPTS diskette 3 in drive A: and issue the following command: C:\CID\SRVIFS\THINSRV /R:C:\SERVER\SERVER1.INI /T:C:\SERVER /S:C:\CID\SRVIFS /TU:C: /U:C:\SERVER\SERVER1.LST 8. Determine if the version of OS/2 you want to copy documents how to set up a code server. Check the OS/2 installation diskette for a file called README.CID. If README.CID does not exist on the OS/2 installation diskette, proceed to step Example Steps for Installing Versions of the OS/2 2.x Program That Do Not Require Service Paks. Otherwise, do the following: a. Follow the steps documented in README.CID to load the OS/2 diskette images onto the code server. b. Follow the steps documented in README.CID to set up the code server to load the OS/2 program onto client workstations. c. Skip to step Example Steps for Installing Versions of the OS/2 2.x Program That Do Not Require Service Paks. 9. Copy the OS/2 2.x diskette images. a. Insert OS/2 2.x diskette 2 in drive A: and issue the following command: COPY A:\UNPACK·*.EXE C:\CID\EXE\V211 b. Insert OS/2 2.x diskette 7 (diskette 8 in some DBCS countries) into drive A: and issue the following command: C:\CID\EXE\V211\UNPACK A:\CID C:\CID\EXE\V211 /N:SEIMAGE.EXE c. Issue the following command to copy the OS/2 2.x product images: C:\CID\EXE\V211\SEIMAGE /T:C:\CID\IMG\OS2V211 /S:A: OS/2 2.x diskettes are loaded in order with a prompt for each. d. Issue the following command to unpack the OS/2 2.x redirected installation modules from the OS/2 2.x diskette images: \CID\IMG\LCU\GETOSCID C:\CID\IMG\OS2V211 C:\CID\EXE\V211 Note: The GETOSCID command unpacks SEIMAGE.EXE again. 10. Obtain the OS/2 2.x modules required by LAN CID Utility. a. Issue the following command to unpack the required REXX modules from the OS/2 2.x diskette images: \CID\IMG\LCU\GETREXX C:\CID\IMG\OS2V211 C:\CID\DLL\V211 b. Issue the following command to unpack the SETBOOT and XCOPY modules from the OS/2 2.x diskette images: \CID\IMG\LCU\GETBOOT C:\CID\IMG\OS2V211 C:\CID\EXE\V211 11. Create the OS/2 2.x response file DEFAULT.RSP. a. Issue one of the following commands to retrieve the OS/2 2.x sample response file: MOVE C:\CID\EXE\V211\SAMPLE.RSP \CID\RSP\OS2V211 or COPY C:\CID\RSP\OS2V211\SAMPLE.RSP C:\CID\RSP\OS2V211\DEFAULT.RSP b. Edit C:\CID\RSP\OS2V211\DEFAULT.RSP and change the following keywords to the values indicated: ExitOnError=1 FormatPartition=1 12. Obtain the LAPS response file. Insert MPTS diskette 3 in drive A: and issue the following command: PKUNZIP2 A:\SAMPLE\SAMPLE.ZIP C:\CID\RSP\LAPS SAMPLE\LAPSRSP.RSP 13. Create the LAN CID Utility command file, named DEFAULT.CMD. a. Issue the following command: COPY C:\CID\IMG\LCU\CASSKEL.CMD C:\CID\CliENT\DEFAULT.CMD b. Edit C:\CID\CliENT\DEFAULT.CMD as follows: o Change exepath = 'X:\EXE\V210' dllpath = 'X:\DLL\V210' os2dir = 'OS2V21' x.1.name='OS/2 2.1' x.2.name='OS/2 2.1 Maintenance' to exepath = 'X:\EXE\V211' dllpath = 'X:\DLL\V211;X:\IMG\LCU' os2dir = 'OS2V211' x.1.name='OS/2 2.11' x.2.name='OS/2 2.11 Maintenance' o Remove the lines if RunInstall(x.laninstr) == BAD_RC, exit up through and including when OVERALL_STATE = 3 then do 14. Create the boot diskettes. Issue the following commands in order. After SEDISK creates the second diskette, leave it in the diskette drive so that the other programs can modify it. a. Create the diskettes: C:\CID\EXE\V211\SEDISK /S:C:\CID\IMG\OS2V21 /T:A: b. Install LAPS: C:\CID\IMG\LAPS\THINLAPS C:\CID\IMG\LAPS A: IBMTOK.NIF c. Install the SRVIFS requester: C:\CID\IMG\SRVIFS\THINIFS /T:A: /TU:A: /S:C:\CID\IMG\SRVIFS /REQ:* /SRV:SERVER1 /D:X d. Install LAN CID Utility: C:\CID\IMG\LCU\CASINSTL /TU:A: /CMD:X:\CliENT /PA:X:\IMG\LCU /PL:X:\DLL\V211;X:\IMG\LCU; /L2:X:\LOG\LCU\SRVIFS_REQ.LOG /D /REQ:*P 15. Reboot the code server to start the SRVIFS server. 16. At the client workstation, perform the following setup: Note: If you make two copies of the boot diskettes, you can install two client workstations (CliENT1 and CliENT2) at the same time. a. Insert the first boot diskette (diskette 0) into drive A: of the workstation and then reboot. b. Insert boot diskette 1 when prompted. c. Enter a workstation name when prompted (CliENT1 or CliENT2). d. Remove the diskette from drive A: only when prompted. e. When the installation is complete, OS/2 2.x and LAPS should be installed and active on the client workstation. ═══ 21. System-Wide CID Recovery ═══ This appendix discusses a method for implementing backup and recovery for the CID environment. Product installations in this environment can be initiated to occur overnight or over a weekend. Thus, it is important to plan a way to restore a workstation to its previous working state if the installation fails because of an incorrect product installation, an invasion by a virus, or installed fixes or product versions that do not run correctly. The failing condition can be detected by: o Product installation error codes o Operation of the system o Some other means. For OS/2 system products that have dependencies on each another, a plan to implement recovery for one product at the time is difficult for the following reasons: o Specific files changed by the installation of a CID-enabled product may not be easily identified because the installation process can indirectly change files through a system application programming interface (API) not related to the files. o Inter-product dependencies can exist when two or more products update the same file. For example, assume that a product backs up the CONFIG.SYS file before altering it. If subsequent product installations also make changes to this file, this product cannot merely restore its backed up version because this action can invalidate the CONFIG.SYS file for those products that were installed after this product. Therefore, a system-wide recovery procedure is recommended in which the data for all products within a partition or drive are saved at a code server. This type of recovery makes it unnecessary for each product to provide unique backup and recovery procedures and also removes all inter-product file dependencies. One way to accomplish a system-wide recovery is to back up and restore all files within a particular partition or drive by using file system APIs. This method removes the requirement that each product specify a set of files to be backed up and restored. However, the recovery plan must consider any access control lists (ACLs) associated with files that are to be backed up and restored. The suggested form of recovery for LAN CID Utility is to save all files within a partition. This method saves all data, requires no product participation, and is easy to understand. This backup and restore function uses the XCOPY utility updated to copy hidden files and directories, ReadOnly files, and system files. The backup and restore files can be local to the client workstation or redirected to a server. ═══ 21.1. Single Partition Recovery during Installation of the OS/2 2.x Program with ACLs ═══ A brief overview of the steps needed for system-wide recovery using the LAN CID Utility is contained in Recovery during Installation of the OS/2 2.x Program. This description assumes that ACL-protected files exist on the system before the CID installation begins. The existing running production system could be OS/2 1.3 or OS/2 2.x. Following this table is a detailed explanation of each step listed in the left column, along with preventive actions and recovery actions to take in case of failure. break=fit split=yes. ┌──────────────────────────────────────────────────────────────────────────────┐ │ Table 9. Recovery during Installation of the OS/2 2.x Program │ ├────────────────────┬────────────────────────────┬────────────────────────────┤ │ INSTALLATION │ PREVENTIVE ACTIONS │ RECOVERY ACTIONS │ │ SEQUENCE │ │ │ ├────────────────────┼────────────────────────────┼────────────────────────────┤ │ RUNNING BASE │ │ │ │ SYSTEM OS/2 1.3 │ │ │ │ PRODUCTION │ │ │ ├────────────────────┼────────────────────────────┼────────────────────────────┤ │ 1. BACKUP PROCE- │ 1. XCOPY C:\*.* in │ 1. End if the SAVE in │ │ DURE │ D:\OLDROOT.. │ D:\OLDROOT, and │ │ │ │ optionally D:\ACLIST, │ │ │ Saved files include: │ does not complete suc- │ │ │ o OS2LDR │ cessfully. │ │ │ o OS2KRNL │ 2. Optionally restore │ │ │ o CONFIG.SYS │ saved ACL files. │ │ │ 2. Optionally SAVE 386 │ │ │ │ ACLs in D:\ACLIST and │ │ │ │ then REMOVE ACLS from │ │ │ │ C: by running the LAN │ │ │ │ SERVER BACKACC and │ │ │ │ REMOVE ACL Utilities. │ │ ├────────────────────┼────────────────────────────┼────────────────────────────┤ │ 2. INSTALL │ │ 1. Restore files saved in │ │ SEMAINT + │ │ Step 1 (OLDROOT). │ │ LAPS_MAINT + │ │ 2. Exposure when changing │ │ CASINSTL + │ │ the boot record from │ │ THINIFS... │ │ EE 1.3 to OS/2 2.x. │ │ │ │ (SYSINSTX). │ │ │ │ 3. REBOOT EE 1.3. │ │ │ │ 4. Optionally run RESTACC │ │ │ │ for ACL restore and │ │ │ │ then ERASE D:\ACLIST. │ │ │ │ 5. Erase D:\OLDROOT. │ │ │ │ 6. Otherwise end and │ │ │ │ install EE 1.3. │ ├────────────────────┼────────────────────────────┼────────────────────────────┤ │ 3. REBOOT to │ │ Diskette recovery │ │ activate OS/2 │ │ │ │ maintenance system │ │ │ ├────────────────────┼────────────────────────────┼────────────────────────────┤ │ RUNNING BASE │ │ │ │ SYSTEM OS/2 2.X │ │ │ │ MAINTENANCE │ │ │ ├────────────────────┼────────────────────────────┼────────────────────────────┤ │ 4. │ XCOPY C: D:\BACKUP /S │ 1. End the XCOPY func- │ │ │ /E... (PKZIP, SAVERAM, │ tion. │ │ │ ...) │ 2. Erase C:\*.*