OS/2 Shareware BBS: 10 Tools

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / lansystk.zip / MPTSUTIL / LCU / CASGUIDE.INF (.txt) < prev next >

Wrap

OS/2 Help File | 1998-05-08 | 371KB | 13,900 lines

ΓòÉΓòÉΓòÉ 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: <path>\IMG\product The path name contains the following: <path> 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 <path>\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 <path>\EXE, <path>\DLL, and <path>\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 <path>\EXE\V200, <path>\DLL\V200, and <path>\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 Γöé <path>\IMG\product Γöé One per drive; one Γöé Γöé Γöé Γöé Γöé per system Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Logs Γöé Single, Γöé <path>\LOG\product Γöé One per system Γöé Γöé Γöé ReadWrite Γöé OR Γöé Γöé Γöé Γöé Γöé <path>\LOG\CLIENT Γöé Γöé Γöé Γöé or PerClient, Γöé Γöé Γöé Γöé Γöé ReadWrite Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Response Γöé Single, ReadOnly Γöé <path>\RSP\product Γöé One per system Γöé Γöé files Γöé Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Client Γöé Single, ReadOnly Γöé <path>\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 <path>\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 <path>\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 <path>\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 <path>\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: <path>\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:\ <path>\OS2V20\DISK_0\ 2. Insert the OS/2 2.x diskette 1 into drive A: and issue the following command: XCOPY A:\ <path>\OS2V20\DISK_1\ 3. Insert the OS/2 2.x diskette 4 into drive A: and issue the following command: XCOPY A:\ <path>\OS2V20\DISK_4\ 4. Insert the OS/2 2.x diskette 2 into drive A: and issue the following commands: COPY A:\UHPFS.DLL <path>\OS2V20\DISK_0\ COPY A:\UNPACK*.EXE <path>\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 <path>\EXE\V2xx directory: UNPACK A:\CID <path>\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 <path>\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 <path>\DLL\V200 COPY \OS2\SYSTEM\*REX*.MSG <path>\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 <path>\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 <path>\IMG\OS2V20 <path>\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 <path>\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 <path>\EXE\V200 COPY \OS2\XCOPY.EXE <path>\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 <path>\EXE\V2xx subdirectory on the code server. Following is an example of how to use GETBOOT: GETBOOT <path>\IMG\OS2V20 <path>\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 <path>\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 <path>\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 <path>\IMG\LAPS as the target directory. LAPSDISK then loads all the product images for MPTS LAPS from the diskettes into the <path>\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 <path>\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 <path>\EXE\V2xx directory: UNPACK A:\CID <path>\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: <path>\EXE\V200\SEIMAGE /S:A: /T:<path>\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: <path>\IMG\LCU\GETOSCID <path>\IMG\OS2V20 <path>\EXE\V200 MOVE drive and path\EXE\V200\SAMPLE.RSP <path>\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: <path>\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:\ <path>\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:\ <path>\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: <path>\IMG\LCU\GETFIX <path>\CSD\OS2V20\CSD1 <path>\EXE\V200 For more information, see GETFIX. Note: If SAMPLE.RSP was shipped with the Service Pak, this file will be unpacked into the <path>\EXE\V200 directory. Check for this file in the <path>\EXE\V200 directory and, if it exists, copy it to the OS/2 2.x response file directory (<path>\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 <path>\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 <path>\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 <path>\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 <path>\RSP\product directory or a directory separate from the other response files, such as <path>\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 <path>\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 <path>\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 <path>\EXE\V200\SEDISK.EXE with the product images in <path>\IMG\OS2V20 or use <path>\EXE\V210\SEDISK.EXE with the product images in <path>\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 <path>\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 <path>\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 <path>\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 <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: <Fri May 08 12:29:13> OS/2 2.1 maintenance install is starting. <Fri May 08 12:31:20> OS/2 2.1 maintenance install was successful. <Fri May 08 12:31:21> LAPS maintenance install is starting. <Fri May 08 12:32:40> LAPS maintenance install was successful. <Fri May 08 12:32:40> SRVIFS requester install is starting. <Fri May 08 12:32:55> SRVIFS requester install was successful. <Fri May 08 12:32:56> LAN CID Utility install is starting. <Fri May 08 12:33:01> LAN CID Utility install was successful. <Fri May 08 12:33:11> Reboot. <Fri May 08 12:34:56> OS/2 2.1 install is starting. <Fri May 08 12:47:18> OS/2 2.1 install was successful. <Fri May 08 12:47:18> LAPS install is starting. <Fri May 08 12:48:21> LAPS install was successful. <Fri May 08 12:48:21> SRVIFS requester install is starting. <Fri May 08 12:48:31> SRVIFS requester install was successful. <Fri May 08 12:48:31> LAN CID Utility install is starting. <Fri May 08 12:48:34> LAN CID Utility install was successful. <Fri May 08 12:48:45> Reboot. <Fri May 08 12:50:32> OS/2 2.1 install is starting, REMOTE_INSTALL_STATE=1. <Fri May 08 12:54:02> OS/2 2.1 install was successful. <Fri May 08 12:54:02> SRVIFS requester install is starting. <Fri May 08 12:54:15> SRVIFS requester install was successful. <Fri May 08 12:54:15> LAN CID Utility install is starting. <Fri May 08 12:54:19> LAN CID Utility install was successful. <Fri May 08 12:54:24> Reboot. <Fri May 08 12:56:05> SRVIFS delete install is starting. <Fri May 08 12:56:09> SRVIFS delete install was successful. <Fri May 08 12:56:10> LAN CID Utility delete install is starting. <Fri May 08 12:56:15> LAN CID Utility delete install was successful. <Fri May 08 12:56:16> 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: <Fri May 08 12:34:56> OS/2 2.1 install is starting. <Fri May 08 12:47:18> OS/2 2.1 install was successful. <Fri May 08 12:47:18> LAPS install is starting. <Fri May 08 12:48:21> LAPS install was successful. <Fri May 08 12:48:21> SRVIFS requester install is starting. <Fri May 08 12:48:31> SRVIFS requester install was successful. <Fri May 08 12:48:31> LAN CID Utility install is starting. <Fri May 08 12:48:34> LAN CID Utility install was successful. <Fri May 08 12:48:45> Reboot. <Fri May 08 12:50:32> OS/2 2.1 install is starting, REMOTE_INSTALL_STATE=2. <Fri May 08 12:54:02> OS/2 2.1 install was successful. <Fri May 08 12:54:02> SRVIFS requester install is starting. <Fri May 08 12:54:15> SRVIFS requester install was successful. <Fri May 08 12:54:15> LAN CID Utility install is starting. <Fri May 08 12:54:19> LAN CID Utility install was successful. <Fri May 08 12:54:24> Reboot. <Fri May 08 12:56:05> SRVIFS delete install is starting. <Fri May 08 12:56:09> SRVIFS delete install was successful. <Fri May 08 12:56:10> LAN CID Utility delete install is starting. <Fri May 08 12:56:15> LAN CID Utility delete install was successful. <Fri May 08 12:56:16> 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: <Fri May 08 12:48:21> SRVIFS requester install is starting. <Fri May 08 12:48:31> SRVIFS requester install was successful. <Fri May 08 12:48:31> LAN CID Utility install is starting. <Fri May 08 12:48:34> LAN CID Utility install was successful. <Fri May 08 12:48:45> Reboot. <Fri May 08 12:50:32> CM/2 install is starting. <Fri May 08 12:54:02> CM/2 install was successful. <Fri May 08 12:54:24> Reboot. <Fri May 08 12:56:05> SRVIFS delete install is starting. <Fri May 08 12:56:09> SRVIFS delete install was successful. <Fri May 08 12:56:10> LAN CID Utility delete install is starting. <Fri May 08 12:56:15> LAN CID Utility delete install was successful. <Fri May 08 12:56:16> 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: <Fri May 08 12:47:18> LAPS maintenance install is starting. <Fri May 08 12:48:21> LAPS maintenance install was successful. <Fri May 08 12:48:21> LAN CID Utility delete install is starting. <Fri May 08 12:48:31> LAN CID Utility delete install was successful. <Fri May 08 12:48:31> 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: <Fri May 08 12:47:18> LAPS install is starting. <Fri May 08 12:48:21> LAPS install was successful. <Fri May 08 12:48:21> SRVIFS delete install is starting. <Fri May 08 12:48:31> SRVIFS delete install was successful. <Fri May 08 12:48:32> LAN CID Utility delete install is starting. <Fri May 08 12:48:42> LAN CID Utility delete install was successful. <Fri May 08 12:48:43> 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: <Fri May 08 12:47:18> LAPS maintenance install is starting. <Fri May 08 12:48:21> LAPS maintenance install was successful. <Fri May 08 12:48:21> SRVIFS requester install is starting. <Fri May 08 12:48:31> SRVIFS requester install was successful. <Fri May 08 12:48:31> LAN CID Utility install is starting. <Fri May 08 12:48:34> LAN CID Utility install was successful. <Fri May 08 12:48:45> Reboot. <Fri May 08 12:50:32> CM/2 install is starting. <Fri May 08 12:54:02> CM/2 install was successful. <Fri May 08 12:54:24> Reboot. <Fri May 08 12:56:05> SRVIFS delete install is starting. <Fri May 08 12:56:09> SRVIFS delete install was successful. <Fri May 08 12:56:10> LAN CID Utility delete install is starting. <Fri May 08 12:56:15> LAN CID Utility delete install was successful. <Fri May 08 12:56:16> 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: <Fri May 08 12:47:41> LAPS install is starting. <Fri May 08 12:48:43> LAPS install was successful. <Fri May 08 12:48:45> Reboot. <Fri May 08 12:50:32> CM/2 install is starting. <Fri May 08 12:54:02> CM/2 install was successful. <Fri May 08 12:54:24> Reboot. <Fri May 08 12:56:05> SRVIFS delete install is starting. <Fri May 08 12:56:09> SRVIFS delete install was successful. <Fri May 08 12:56:10> LAN CID Utility delete install is starting. <Fri May 08 12:56:15> LAN CID Utility delete install was successful. <Fri May 08 12:56:16> 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 <path> 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: <path>\compile\casprep.cmd Compiler <path>\compile\client.fil Client-specific input file <path>\compile\default.fil Default or general input file <path>\compile\casbase.fil Base input file <path>\compile\client.cmd Invokes the compiler; client-specific <path>\compile\default.cmd Invokes compiler; default or general <path>\client\client.cmd Client-specific; runs the installation Following is a brief explanation: <path>\compile\ The path to where CASPREP and the input files are located. <path>\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. <path>\compile\client.cmd The REXX command file that invokes the compiler. In this example, it is named for a specific client. <path>\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. <path>\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 <path>\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 (<path>\CLIENT\group.CMD). o Each product has a separate default response file. o The response files reside in the <path>\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 (<path>\CLIENT\group.CMD). o Each unique client has a separate command file (<path>\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 <path>\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 (<path>\CLIENT\group.CMD). o Each unique client has a separate command file (<path>\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 <path>\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 <path>\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 <path>\EXE\V2xx directory, this directory must be made the current directory. An alternative is to add the <path>\EXE\V2xx directory to the current PATH BEFORE the <boot drive>\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:\*.* <X.FIL(1) Γöé Γöé Γöé Γöé 3. Restore contents saved Γöé Γöé Γöé Γöé in D:\OLDROOT (step Γöé Γöé Γöé Γöé 1). Γöé Γöé Γöé Γöé 4. REBOOT EE 1.3. Γöé Γöé Γöé Γöé 5. Optionally run RESTACC Γöé Γöé Γöé Γöé for ACL Restore and Γöé Γöé Γöé Γöé then ERASE D:\ACLIST. Γöé Γöé Γöé Γöé 6. Erase D:\OLDROOT. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 5. INSTALL SEINST Γöé Γöé 1. Erase C:\*.* <X.FIL(1) Γöé Γöé + LAPS_PROD + Γöé Γöé 2. XCOPY D:\BACKUP C:\ /S Γöé Γöé CASINSTL + THINIFS Γöé Γöé /E... Γöé Γöé Γöé Γöé 3. XCOPY D:\OLDROOT C:\ Γöé Γöé Γöé Γöé 4. REBOOT EE 1.3. Γöé Γöé Γöé Γöé 5. Optionally run RESTACC Γöé Γöé Γöé Γöé for ACL Restore and Γöé Γöé Γöé Γöé then ERASE D:\ACLIST. Γöé Γöé Γöé Γöé 6. Erase D:\OLDROOT. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 6. REBOOT with Γöé Γöé Diskette recovery Γöé Γöé CASINSTL and Γöé Γöé Γöé Γöé THINIFS to acti- Γöé Γöé Γöé Γöé vate OS/2 pro- Γöé Γöé Γöé Γöé duction system Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé RUNNING BASE Γöé Γöé Γöé Γöé SYSTEM OS/2 2.X Γöé Γöé Γöé Γöé PRODUCTION Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Table 9. Recovery during Installation of the OS/2 2.x Program Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé INSTALLATION Γöé PREVENTIVE ACTIONS Γöé RECOVERY ACTIONS Γöé Γöé SEQUENCE Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 7. INSTALL Γöé Γöé 1. Build maintenance Γöé Γöé CMSETUP, LANINSTR, Γöé Γöé system. Γöé Γöé and other products Γöé Γöé 2. REBOOT maintenance Γöé Γöé Γöé Γöé system. Γöé Γöé Γöé Γöé 3. Erase C:\*.* <X.FIL(1) Γöé Γöé Γöé Γöé 4. XCOPY D:\BACKUP C: /S Γöé Γöé Γöé Γöé /E... Γöé Γöé Γöé Γöé 5. XCOPY D:\OLDROOT C: Γöé Γöé Γöé Γöé 6. REBOOT EE 1.3. Γöé Γöé Γöé Γöé 7. Optionally run RESTACC Γöé Γöé Γöé Γöé for ACL restore and Γöé Γöé Γöé Γöé then ERASE D:\ACLIST. Γöé Γöé Γöé Γöé 8. Erase D:\OLDROOT. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 8. REBOOT to Γöé Γöé Diskette recovery Γöé Γöé activate OS/2 pro- Γöé Γöé Γöé Γöé duction system Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé RUNNING BASE Γöé Γöé Γöé Γöé SYSTEM OS/2 2.X Γöé Γöé Γöé Γöé PRODUCTION AND CM, Γöé Γöé Γöé Γöé LS, ... PRODUCTION Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 9 Erase Γöé Γöé Warning message Γöé Γöé D:\OLDROOT and Γöé Γöé Γöé Γöé D:\ACLIST Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé NOTE: Because the ERASE *.* command requires a "Y" or an "N" response, this Γöé Γöé CID recovery environment assumes that a predefined file contains the "Y" Γöé Γöé response. The file content is then piped to the ERASE *.* command. The Γöé Γöé following steps are required: Γöé Γöé Γöé Γöé 1. Define a file, for example, X.FIL, that contains the character Y in the Γöé Γöé first line or space and a blank second line. Γöé Γöé 2. Pipe the file containing the "Y" response to the ERASE *.* command, for Γöé Γöé example, ERASE *.* <X.FIL. Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The graphical flow shown in Recovery during Installation of the OS/2 2.x Program indicates the installation steps for OS/2 2.x, the preventive recovery actions taken in anticipation of a failure, and the actual recovery actions taken when the failure occurs. The numbers in the left column are associated with the various functions that occur during the installation of OS/2 2.x, qualified by the preventive and actual recovery action columns (middle and right columns respectively). The detailed description for these functions follows: Step Description 1. Preventive actions A BACKUP procedure (XCOPY) is invoked to save designated OS/2 Extended Edition 1.3 files on a drive that is on either the requester or a server workstation. These files must be preserved, because the installation procedure of SEINST, by means of the SEMAINT maintenance system, overlays these Extended Edition 1.3 files with the files needed for the installation of the OS/2 2.x program. This example assumes that a file redirector is used for access to server files. The files saved include: o CONFIG.SYS o OS2LDR o OS2KRNL In addition, if files protected by ACLs exist on the Extended Edition 1.3 workstation, the LAN Server program provides a utility (BACKACC) that preserves these ACLs. This step makes it unnecessary for subsequent file copy programs (step 4) to deal with the ACL anomaly. After the ACLs are saved, the LAN Server ACL REMOVE utility is invoked to permit subsequent access to all Extended Edition 1.3 files under the OS/2 2.x maintenance system or the OS/2 2.x production system because both use the 286 file system. Note that 286 file access to a 386 ACL-protected file causes the system to wait indefinitely. ACL 386 files exist because the LAN Server program was installed on the existing Extended Edition 1.3 system. Recovery actions If a failure occurs during the BACKUP procedure, the recovery action is to end this procedure, restore any ACLs (use the LAN Server RESTACC utility), and erase the files contained in D:\OLDROOT and the optional D:\ACLIST. Then try again. 2. Recovery actions If the installation of SEMAINT or LAPS fails, the files saved in step 1 must be restored to the base Extended Edition 1.3 system from the backup D:\OLDROOT. The boot record modified by SYSINSTX 2.x is an exposed procedure that must complete for the subsequent REBOOTs to function properly. Running the OS/2 2.x SYSINSTX program permits Extended Edition 1.3 OS2LDR and OS2KRNL to be restored to a different boot record location from where it was saved. The RESTACC utility provided by LAN Server must be invoked after the Extended Edition 1.3 REBOOT to restore ACLs that were previously saved in D:\ACLIST. Cleanup of D:\OLDROOT and the optional D:\ACLIST is then performed. 3. Recovery actions If a failure occurs during the REBOOT procedure, the recovery action is to boot from a CID-enabled recovery diskette to return the system to its initial state. See LAN CID Utility Recovery for Major Failures for a description of how CID recovery is performed at the failing workstation site. 4. Preventive actions A file save procedure (XCOPY, PKZIP, logical sector, ...) is invoked to save all files from the drive where the OS/2 2.x program is to be installed. The save function must include hidden files, system files, files with long names, extended attribute files, locked files, and subdirectory structures. The SAVED partition can be on either the requester or a server workstation. These files must be preserved, because the installation procedure of SEINST overlays these Extended Edition 1.3 files by new or corresponding files for SEINST. Note that the ACLs were previously saved by the LAN Server BACKACC utility in step 1. Recovery actions If the file SAVE procedure fails, erase C:\*.* for cleanup of the root directory. The files saved in step 1 must be restored to the base Extended Edition 1.3 system from the backup D:\OLDROOT before the REBOOT procedure is performed. The RESTACC utility provided by LAN Server must be invoked after the Extended Edition 1.3 REBOOT to restore ACLs that were previously saved in D:\ACLIST. Cleanup of D:\OLDROOT and the optional D:\ACLIST is then performed. 5. Recovery actions If the installation of SEINST or LAPS fails, the D:\BACKUP files and the files saved in D:\OLDROOT must be restored before the REBOOT procedure is performed. The RESTACC utility provided by LAN Server must be invoked after the Extended Edition 1.3 REBOOT in order to restore ACLs that were previously saved in D:\ACLIST. Cleanup of D:\OLDROOT and the optional D:\ACLIST is then performed. 6. Recovery actions If a failure occurs during the REBOOT procedure, the recovery action is to boot from a CID-enabled recovery diskette to return the system to its initial state. See LAN CID Utility Recovery for Major Failures for a description of how CID recovery is performed at the failing workstation site. 7. Recovery actions If a failure occurs during the installation of subsequent CID-enabled products, the recovery action is to initiate a separately bootable build for the maintenance procedure to provide a minimum system needed to restore Extended Edition 1.3 files on the C: drive. The files for the currently installed CID-enabled products must be erased by issuing, for example, ERASE C:\*.*. The files saved in D:\BACKUP and D:\OLDROOT must be restored, and the Extended Edition 1.3 system is rebooted. The RESTACC utility provided by LAN Server must be invoked after the Extended Edition 1.3 REBOOT in order to restore ACLs that were previously saved. The backup files (D:\OLDROOT and the optional D:\ACLIST) are then erased. 8. Recovery actions If a failure occurs during the REBOOT procedure, the recovery action is to boot from a CID-enabled recovery diskette to return the system to its initial state. See LAN CID Utility Recovery for Major Failures for a description of how CID recovery is performed at the failing workstation site. 9. Recovery actions If a failure occurs during the removal of the backup files, D:\OLDROOT and optionally D:\ACLIST, an error message is logged. The installed OS/2 2.x, Communications Manager/2, and LAN Server systems are not affected by the failure of this cleanup activity. ΓòÉΓòÉΓòÉ 21.2. Single Partition Recovery during Installation of OS/2 2.x with ACLs Using THIN386 ΓòÉΓòÉΓòÉ This description is similar to the one in Recovery during Installation of the OS/2 2.x Program. It is assumed that ACL protected files exist on the system before the CID installation begins. However, a procedure provided by LAN Server called THIN386 is used to access ACL-protected files throughout the installation process. The existing running production system could be OS/2 1.3 or OS/2 2.x. Following Recovery during Installation of the OS/2 2.x Program with ACLs 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 10. Recovery during Installation of the OS/2 2.x Program with ACLs Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 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 does not Γöé Γöé Γöé Γöé complete successfully. Γöé Γöé Γöé Saved files include: Γöé Γöé Γöé Γöé o OS2LDR Γöé Γöé Γöé Γöé o OS2KRNL Γöé Γöé Γöé Γöé o CONFIG.SYS Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 2 INSTALL SEMAINT Γöé Γöé 1. Restore files saved in Γöé Γöé + LAPS_MAINT + Γöé Γöé Step 1 (OLDROOT). Γöé Γöé CASINSTL + THINIFS Γöé Γöé 2. Exposure when changing Γöé Γöé + THIN386... Γöé Γöé the boot record from Γöé Γöé Γöé Γöé EE 1.3 to OS/2 2.x. Γöé Γöé Γöé Γöé (SYSINSTX). Γöé Γöé Γöé Γöé 3. REBOOT EE 1.3. Γöé Γöé Γöé Γöé 4. Erase D:\OLDROOT. Γöé Γöé Γöé Γöé 5. Otherwise end and Γöé Γöé Γöé Γöé install EE 1.3. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 3 REBOOT to acti- Γöé Γöé Diskette recovery Γöé Γöé vate OS/2 mainte- Γöé Γöé Γöé Γöé nance 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:\*.* <X.FIL(1) Γöé Γöé Γöé Γöé 3. Restore contents saved Γöé Γöé Γöé Γöé in D:\OLDROOT (step Γöé Γöé Γöé Γöé 1). Γöé Γöé Γöé Γöé 4. REBOOT EE 1.3. Γöé Γöé Γöé Γöé 5. Erase D:\OLDROOT. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 5 INSTALL SEINST Γöé Γöé 1. Erase C:\*.* <X.FIL(1) Γöé Γöé + LAPS_PROD + Γöé Γöé 2. XCOPY D:\BACKUP C:\ /S Γöé Γöé CASINSTL + THINIFS Γöé Γöé /E... Γöé Γöé + THIN386 Γöé Γöé 3. XCOPY D:\OLDROOT C:\ Γöé Γöé Γöé Γöé 4. REBOOT EE 1.3. Γöé Γöé Γöé Γöé 5. Erase D:\OLDROOT. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 6 REBOOT using Γöé Γöé Diskette recovery Γöé Γöé CASINSTL and Γöé Γöé Γöé Γöé THINIFS to acti- Γöé Γöé Γöé Γöé vate OS/2 pro- Γöé Γöé Γöé Γöé duction system Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé RUNNING BASE Γöé Γöé Γöé Γöé SYSTEM OS/2 2.X Γöé Γöé Γöé Γöé PRODUCTION Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 7 INSTALL Γöé Γöé 1. Build maintenance Γöé Γöé CMSETUP, LANINSTR, Γöé Γöé system. Γöé Γöé and other products Γöé Γöé 2. REBOOT maintenance Γöé Γöé Γöé Γöé system. Γöé Γöé Γöé Γöé 3. Erase C:\*.* <X.FIL(1) Γöé Γöé Γöé Γöé 4. XCOPY D:\BACKUP C: /S Γöé Γöé Γöé Γöé /E... Γöé Γöé Γöé Γöé 5. XCOPY D:\OLDROOT C: Γöé Γöé Γöé Γöé 6. REBOOT EE 1.3. Γöé Γöé Γöé Γöé 7. Erase D:\OLDROOT. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 8 REBOOT to acti- Γöé Γöé Diskette recovery Γöé Γöé vate OS/2 pro- Γöé Γöé Γöé Γöé duction system Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé RUNNING BASE Γöé Γöé Γöé Γöé SYSTEM OS/2 2.X Γöé Γöé Γöé Γöé PRODUCTION AND CM, Γöé Γöé Γöé Γöé LS, ... PRODUCTION Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Table 10. Recovery during Installation of the OS/2 2.x Program with ACLs Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé INSTALLATION Γöé PREVENTIVE ACTIONS Γöé RECOVERY ACTIONS Γöé Γöé SEQUENCE Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 9 Erase Γöé Γöé Warning message Γöé Γöé D:\OLDROOT Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé NOTE: Because the ERASE *.* command requires a "Y" or an "N" response, this Γöé Γöé CID recovery environment assumes that a predefined file contains the "Y" Γöé Γöé response. The file content is then piped to the ERASE *.* command. The Γöé Γöé following steps are required: Γöé Γöé Γöé Γöé 1. Define a file, for example, X.FIL, that contains the character Y in the Γöé Γöé first line or space and a blank second line. Γöé Γöé 2. Pipe the file containing the "Y" response to the ERASE *.* command, for Γöé Γöé example, ERASE *.* <X.FIL. Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The graphical flow shown in Recovery during Installation of the OS/2 2.x Program with ACLs briefly indicates the installation steps for the OS/2 2.x program, the preventive recovery actions taken in anticipation of a failure, and the actual recovery actions taken when the failure occurs. The numbers in the left hand column are associated with the various functions that occur during the installation of the OS/2 2.x program qualified by the preventive and actual recovery action columns (middle and right hand respectively). The detailed description for these functions follow: Step Description 1. Preventive actions A BACKUP procedure (XCOPY) is invoked to save designated Extended Edition 1.3 files on a drive that is on either the requester or a server workstation. These files must be preserved, because the installation procedure of SEINST, by means of the SEMAINT maintenance system, overlays these Extended Edition 1.3 files with the files needed for the installation of the OS/2 2.x program. This example assumes that a file redirector is used for server file access. The files saved include: o CONFIG.SYS o OS2LDR o OS2KRNL Recovery actions If a failure occurs during the BACKUP procedure, the recovery action is to end this procedure and erase the files contained in D:\OLDROOT. Then try again. 2. Recovery actions If the installation of SEMAINT, LAPS, or THIN386 fails, the files saved in step 1 must be restored to the base Extended Edition 1.3 system from the backup D:\OLDROOT. The boot record modified by SYSINSTX 2.x is an exposed procedure that must complete for the subsequent REBOOT procedures to function properly. Running the OS/2 2.x SYSINSTX program permits the OS2LDR and OS2KRNL Extended Edition 1.3 programs to be restored in different boot record locations from where they were saved. Cleanup of D:\OLDROOT is then performed. 3. Recovery actions If a failure occurs during the REBOOT procedure, the recovery action is to boot from a CID-enabled recovery diskette to return the system to its initial state. See LAN CID Utility Recovery for Major Failures for a description of how CID recovery is performed at the failing workstation site. 4. Preventive actions A file save procedure (XCOPY, PKZIP, logical sector, ...) is invoked to save all files from the drive where the OS/2 2.x program is to be installed. The save function must include hidden files, system files, files with long names, extended attribute files, locked files, and subdirectory structures. The saved partition can be on either the requester or a server workstation. These files must be preserved, because the installation procedure of SEINST overlays these Extended Edition 1.3 files by new or corresponding files for SEINST. Recovery Action If the file SAVE procedure fails, erase C:\*.* for cleanup of the root directory. The files saved in step 1 must be restored to the base Extended Edition 1.3 system from the backup D:\OLDROOT before the REBOOT procedure is performed. Cleanup of D:\OLDROOT is then performed. 5. Recovery actions If the installation of SEINST, LAPS, or THIN386 fails, the D:\BACKUP files and the files saved in D:\OLDROOT must be restored before the REBOOT procedure is performed. Cleanup of D:\OLDROOT is then performed. 6. Recovery actions If a failure occurs during the REBOOT procedure, the recovery action is to boot from a CID-enabled recovery diskette to return the system to its initial state. See LAN CID Utility Recovery for Major Failures for a description how CID recovery is performed at the failing workstation site. 7. Recovery actions If a failure occurs during the installation of subsequent CID-enabled products, the recovery action is to initiate a separately bootable build for the maintenance procedure to provide a minimum system needed to restore Extended Edition 1.3 files on the : drive. The files for the currently installed CID-enabled products must be erased by issuing, for example, ERASE C:\*.*. The files saved in D:\BACKUP and D:\OLDROOT must be restored, and the Extended Edition 1.3 system is rebooted. The backup files (D:\OLDROOT) are then erased. 8. Recovery actions If a failure occurs during the REBOOT procedure, the recovery action is to boot from a CID-enabled recovery diskette to return the system to its initial state. See LAN CID Utility Recovery for Major Failures for a description of how CID recovery is performed at the failing workstation site. 9 Recovery actions If a failure occurs during the removal of the backup files (D:\OLDROOT), an error message is logged. The installed OS/2 2.x, Communications Manager/2, and LAN Server systems are not affected by the failure of this cleanup activity. ΓòÉΓòÉΓòÉ 21.3. LCU CID Recovery Capability ΓòÉΓòÉΓòÉ The restore procedure for the failed client workstation needs to be attended at the remote installation site if the failure occurs during a critical function such as a REBOOT procedure. This event is termed a major failure. Note that REBOOT procedures are a normal part of some CID installation procedures, such as the LAN Server, Communications Manager/2, and OS/2 2.x programs, to activate the newly installed code, such as the the CONFIG.SYS file and .INI statements. The LAN CID Utility recovery procedure can be automatically invoked by a bad return code received from an unsuccessful CID installation program. You can customize the recovery procedure for each client workstation. A sample LAN CID Utility REXX command file is specified in Sample LAN CID Utility REXX Command File with Recovery. The REXX file illustrates how this CID recovery can be automated without intervention at the remote site. The REXX file contains the statements for the case when the code server and the client workstation are the same. In Sample LAN CID Utility REXX Command File with Recovery (Continued), the REXX file contains the statements for the case when the code server and the client workstation are not the same. ΓòÉΓòÉΓòÉ 21.3.1. Sample LAN CID Utility REXX Command File with Recovery ΓòÉΓòÉΓòÉ exepath = 'X:\EXE\V200' OVERALL_STATE = GetEnvironmentVars() Do Forever Select when OVERALL_STATE = 0 then do 'exepath || '\XCOPY C:\*.* D:\OLDROOT /H /T /R /O' /* save root files for OS/2 base*/ if rc <> 0 then Exit Call CheckBoot end when OVERALL_STATE = 1 then do if BootDriveIsDiskette() == YES then iterate /*if boot install go to next state*/ if RunInstall(x.semaint) == BAD_RC then Call Recover1 if RunInstall(x.laps_prep) == BAD_RC then Call Recover1 if RunInstall(x.thinifs) == BAD_RC then Call Recover1 if RunInstall(x.casinstl) == BAD_RC then Call Recover1 Call CheckBoot end when OVERALL_STATE = 2 then do exepath || '\XCOPY C:\*.* D:\BACKUP /S /E /H /T /R /O' /*save all partition fls for OS/2 base*/ if rc <> 0 then Exit Call CheckBoot end when OVERALL_STATE = 3 then do if RunInstall(x.seinst) == BAD_RC then Call Recover2 if RunInstall(x.laps_maint) == BAD_RC then Call Recover2 if RunInstall(x.thinifs) == BAD_RC then Call Recover2 if RunInstall(x.casinstl) == BAD_RC then Call Recover2 Call CheckBoot end when OVERALL_STATE = 4 then do if RunInstall(x.cmsetup) == BAD_RC then Recover3 Call CheckBoot end when OVERALL_STATE = 5 then do if RunInstall(x.laninstr) == BAD_RC then Recover3 Call CheckBoot end when OVERALL_STATE = 6 then do if RunInstall(x.casdelet) == BAD_RC then Exit if RunInstall(x.ifsdel) == BAD_RC then Exit Call Reboot end end end This sample code string continues. ΓòÉΓòÉΓòÉ 21.3.1.1. Sample LAN CID Utility REXX Command File with Recovery (Continued) ΓòÉΓòÉΓòÉ Recover1: 'ERASE C:\*.* <X.FIL' /* to erase root files before restore*/ exepath || '\XCOPY D:\OLDROOT C:\ /H /R /T /O ' /* restore root files */ 'ERASE D:\OLDROOT\*.* <X.FIL' /* cleanup saved root files*/ if RunInstall(x.casdelet) == BAD_RC then Exit if RunInstall(x.ifsdel) == BAD_RC then Exit EXIT Recover2: 'ERASE C:\*.* <X.FIL' /* to erase root files before restore*/ exepath || '\XCOPY D:\BACKUP C:\ /S /E /H /T /R /O' /* restore all files */ exepath || '\XCOPY D:\OLDROOT C:\ /H /R /T /O ' /* restore root files */ 'ERASE D:\OLDROOT\*.* <X.FIL' /* cleanup saved root files*/ if RunInstall(x.casdelet) == BAD_RC then Exit if RunInstall(x.ifsdel) == BAD_RC then Exit CALL Reboot /* reboot restored system */ Recover3: if RunInstall(x.semaint) == BAD_RC then Exit /* build maintenance system*/ 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 REBOOTANDGOTOSTATE (8) /* reboot maintenance system*/ when OVERALL_STATE = 8 then do 'ERASE C:\*.* <X.FIL' /* to erase root files before restore*/ exepath || '\XCOPY D:\BACKUP C:\ /S /E /H /T /R /O' /* restore all files */ exepath || '\XCOPY D:\OLDROOT C:\ /H /R /T /O' /* restore root files */ 'ERASE D:\OLDROOT\*.* <X.FIL' /* cleanup restored root files */ 'C:\Service\Lapsdel' /* run LAPS cleanup of itself */ 'ERASE C:\Service\*.* <X.FIL' /* delete files in service directory */ 'RD C:\Service' /* remove service directory */ if RunInstall(x.casdelet) == BAD_RC then Exit if RunInstall(x.ifsdel) == BAD_RC then Exit CALL Reboot /* reboot restored system */ end ΓòÉΓòÉΓòÉ 21.3.2. REXX Recovery Sequence Preceding a Single CID-Enabled Product Installation ΓòÉΓòÉΓòÉ When installing CID-enabled products separately, you can use the following series of statements (using a bootable OS/2 maintenance system) to back up the system before the actual installation of the CID-enabled product occurs. These statements assume that there are no ACL files on the current system. exepath= 'X:\EXE\V200' /* path to XCOPY on server */ OVERALL_STATE = GetEnvironmentVars() Do Forever Select when OVERALL_STATE = 0 then do exepath || '\XCOPY C:\*.* D:\OLDROOT /H /T /R /O' /* save root files for OS/2 base*/ if rc <> 0 then Exit Call CheckBoot end when OVERALL_STATE = 1 then do if RunInstall(x.semaint) == BAD_RC then Call Recover1 if RunInstall(x.laps_prep) == BAD_RC then Call Recover1 if RunInstall(x.thinifs) == BAD_RC then Call Recover1 if RunInstall(x.casinstl) == BAD_RC then Call Recover1 Call REBOOTANDGOTOSTATE(2) end when OVERALL_STATE = 2 then do exepath || '\XCOPY C:\*.* D:\BACKUP /S /E /H /T /R /O' /* save all partition files for OS/2 base*/ if rc <> 0 then Exit 'ERASE C:\*.* <X.FIL' /*cleanup root*/ exepath || '\XCOPY D:\OLDROOT c:\ ' /* restore root files for reboot*/ if rc <> 0 then Exit Call REBOOTANDGOTOSTATE(3) end when OVERALL_STATE = 3 then do 'C:\Service\Lapsdel' /* run LAPS cleanup of itself */ 'ERASE C:\Service\*.* <X.FIL' /* delete files in service directory */ 'RD C:\Service' /* remove service directory*/ end end end . . exit ΓòÉΓòÉΓòÉ 21.3.3. LAN CID Utility Recovery for Major Failures ΓòÉΓòÉΓòÉ Failures that occur during a REBOOT function in an installation run by a CID installation sequence (such as a LAN CID Utility command file) are considered major failures. Because the system is inoperable, someone must be present to attend to the CID recovery. This event requires the following steps: 1. At the code server, create a command file on the code server that is to be accessed by a client workstation in a major recovery state. Assign any name for this command file. The following example uses the file name RECOVER. The command file contains the following REXX statements: 'ERASE C:\*.* <X.FIL' /* erase root files before restore*/ exepath || '\XCOPY D:\BACKUP C:\ /S /E /H /T /R /O' /* restore root files */ exepath || '\XCOPY D:\OLDROOT C:\ /H /T /R /O' /* restore root files */ CALL Reboot /* reboot restored system */ Because the reboot failure in the installation sequence can have occurred before data was saved in D:\BACKUP, any error returned from the statement exepath || '\XCOPY D:\BACKUP C:\ /S /E /H /T /R /O assumes that the installation sequence saved data only from D:\OLDROOT. This save should not affect the restoration of the workstation to its prior operating environment, because the original C:\ files remain intact. 2. At the client, the user inserts the boot diskettes created for LAN CID Utility. The name of the client workstation must match the name (RECOVER) of the recovery command file on the code server. The command file runs and the system is restored. The only user action at the failed workstation is to insert the boot diskettes. No knowledge about the failed system or recovery procedures is required. If this manual CID recovery fails, the system must be built as in a first-time installation. ΓòÉΓòÉΓòÉ 22. Sample Files ΓòÉΓòÉΓòÉ This appendix contains some of the sample files shipped with MPTS and OS/2: o A sample SRVIFS configuration (.INI) file (SERVICE.INI) o A sample SRVIFS authorization list file (SERVICE.LST). See A Sample SRVIFS Authorization List File. o A sample command file (CASSKEL.CMD). See A Sample Command File. o A sample response file (SAMPLE.RSP). See A Sample Response File. ΓòÉΓòÉΓòÉ 22.1. A Sample SRVIFS Configuration (.INI) File ΓòÉΓòÉΓòÉ Following is a sample configuration file (SERVICE.INI). This file is discussed in Installing SRVIFS on the Code Server. ; ! @ # 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 ΓòÉΓòÉΓòÉ 22.2. A Sample SRVIFS Authorization List File ΓòÉΓòÉΓòÉ Following is a sample authorization list file (SERVICE.LST). This file is discussed in Installing SRVIFS on the Code Server. * 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 ΓòÉΓòÉΓòÉ 22.3. A Sample Command File ΓòÉΓòÉΓòÉ Following is part of a sample command file (CASSKEL.CMD) showing the two sections that you need to edit. The REXX subroutines, the third section of the file, are not included because you must not modify them. This file is discussed in Creating LAN CID Utility REXX Command Files. /* 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 CONFIG.SYS */ 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() /*****************************************************/ /* 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 /*************************************************************/ /* DO NOT MODIFY ANY CODE BELOW THIS LINE !!! */ /*************************************************************/ ΓòÉΓòÉΓòÉ 22.4. A Sample Response File ΓòÉΓòÉΓòÉ Following is a sample response file (SAMPLE.RSP) shipped with the OS/2 2.1 program. This file is discussed in Creating and Using Response Files. ************************************************************** * * * Advance Power Management * * * * Specifies whether or not to install APM. * * * * Valid Parms: * * * * 0=Do not install * * 1=Autodetect (DEFAULT) * * 2=Install * * * ************************************************************** APM=1 *************************************************************** * * * AlternateAdapter * * * * Specifies secondary adapter for two display systems. * * This should be a lower or equal resolution display since * * the highest resolution display will be primary for PM. * * * * Valid Parms: * * * * 0=None (DEFAULT) * * 1=Other than following (DDINSTAL will handle) * * 2=Monochrome/Printer Adapter * * 3=Color Graphics Adapter * * 4=Enhanced Graphics Adapter * * 5=PS/2 Display Adapter * * 6=Video Graphics Adapter * * 7=8514/A Adapter * * 8=XGA Adapter * * 9=SVGA Adapter * * * *************************************************************** AlternateAdapter=0 ************************************************************** * * * BaseFileSystem * * * * Specifies which file system should be used to format * * the install partition * * * * Valid Parms: * * * * 1=HPFS (DEFAULT) * * 2=FAT * * * ************************************************************** BaseFileSystem=1 ************************************************************** * * * CDROM * * * * Specifies which, if any, CD ROM devices you wish to * * install support for. * * * * Valid Parms: * * * * 0 = None * * 1 = Autodetect * * 2=CDTechnology T3301 * * 3=HitachiCDR-1650,1750,3650 * * 4=HitachiCDR-3750 * * 5=IBMCD-ROM I * * 6=IBMCD-ROM II * * 7=NEC25,36,37,72,73,74,82,83,84 * * 8=NECMultiSpin 38,74,84 * * 9=PanasonicCR-501,LK-MC501S * * 10=PioneerDRM-600 * * 11=PioneerDRM-604X * * 12=SonyCDU-541,561,6211,7211 * * 13=SonyCDU-6111 * * 14=TexelDM-3021,5021 * * 15=TexelDM-3024,5024 * * 16=Toshiba3201 * * 17=Toshiba3301,3401 * * 18=OTHER * * * * NOTE: Autodetection is enabled only when all scsi * * device drivers are loaded. * ************************************************************** CDROM=0 ************************************************************** * * * CountryCode * * * * Specifies which country should be installed. This * * causes all country information to be installed. * * * * Valid Parms: * * * * 3 digit country code (DEFAULT shipped version) * * * ************************************************************** CountryCode=001 ************************************************************** * * * CountryKeyboard * * * * Specifies which country keyboard should be installed. * * This causes all keyboard information to be installed. * * * * Valid Parms: * * * * 2-5 character keyboard code (DEFAULT="US") * * * ************************************************************** CountryKeyboard=US ************************************************************** * * * DefaultPrinter * * * * Specifies which default printer to install * * * * Valid Parms: * * * * 0=None * * or * * * * Keyvalue=printer driver index (DEFAULT=line # of * * 42XX) in PRDESC.LST shipped on first printer diskette* * * * NOTE: the driver index is the same as the line * * number in the ASCII PRDESC.LST file that * * the desired printer name appears on * * * ************************************************************** DefaultPrinter=0 ************************************************************** * * * DiagnosticAids * * * * Specifies whether or not to install certain RAS * * utilities. * * * * Valid Parms: * * * * 0=Do not install * * 1=Install (DEFAULT) * * * ************************************************************** DiagnosticAids=1 ************************************************************** * * * DisplayAdapter * * * * Specifies which adapter should override the primary * * adapter detected by the install process * * * * Valid Parms: * * * * 0=Accept as correct (DEFAULT) * * 1=Other than following (DDINSTAL will handle) * * 2=Color Graphics Adapter * * 3=Enhanced Graphics Adapter * * 4=Video Graphics Adapter * * 5=8514/A Adapter * * 6=XGA Adapter * * 7=SVGA Adapter * * * ************************************************************** DisplayAdapter=0 ************************************************************** * * * Documentation * * * * Specifies which documentation should be installed * * * * Valid Parms: * * * * 0=None * * 1=All (DEFAULT) * * 2=OS/2 Command Reference * * 3=OS/2 Tutorial * * 4=Rexx Documentation * * * ************************************************************** Documentation=1 ************************************************************** * * * DOSSupport * * * * Specifies whether or not to install DOS Box. * * * * Valid Parms: * * * * 0=Do not install DOS * * 1=Install DOS (DEFAULT) * * * ************************************************************** DOSSupport=1 ************************************************************** * * * WIN-OS/2Support * * * * Specifies whether or not to install WIN-OS/2 * * Environment. If do, select WIN-OS/2 groups or * * other components. This option is valid only * * when option 1 (DOSSupport) is selected for * * the DOSSupport keyvalue. * * * * Valid Parms: * * * * 0=Do NOT install WIN-OS/2 * * ---- Followings INSTALL WIN-OS/2 ---------------------- * * 1=All available groups and components (DEFAULT) * * 2=WIN-OS/2 Readme File * * 3=WIN-OS/2 Accessories Group * * 4=WIN-OS/2 Screen Save Utility * * 5=WIN-OS/2 Sound Utility * * 6=WIN-OS/2 Main and Startup Group ONLY (Minimum support)* * * * Note: * * * WIN-OS/2 Main Group and StartUp Group will be * * installed mandatorily when WIN-OS/2 supported * * ( case 1,2,3,4,5 ). * * * Case 6 is minimum WIN-OS/2 support. * * * * Example: * * * * WIN-OS/2Support=3,4 * * would install WIN-OS/2 Main Group, StartUp Group and * * WIN-OS/2 Accessories and Screen Save Utility. * * * ************************************************************** WIN-OS/2Support=1 ************************************************************** * * * WindowedWIN-OS/2 * * * * Specifies whether Windows** applications should run in * * windowed sessions on the Presentation Manager desktop * * or in Full Screen sessions. This option is valid only * * when option 1 (WIN-OS/2 Support) is selected for the * * DOSSupport keyvalue. * * * * Valid Parms: * * * * 0=Windowed WIN-OS/2 sessions * * 1=Full Screen WIN-OS/2 sessions * * * ************************************************************** *WindowedWIN-OS/2=1 ************************************************************** * * * WIN-OS/2Desktop * * * * Specifies what the WIN-OS/2 desktop should look like. * * This option is valid only when option 1 (WIN-OS/2 * * Support) is selected for the DOSSupport keyvalue. * * Option 1 should be selected only if Windows** currently * * exists (two related options follow this one). * * Option 2 should be selected only if WIN-OS/2 has * * previously been installed. * * * * Valid Parms: * * * * 0=Install standard WIN-OS/2 desktop (DEFAULT) * * 1=Copy existing Windows** desktop and use as the * * WIN-OS/2 desktop (two related options follow) * * 2=Preserve WIN-OS/2 desktop currently installed * * * ************************************************************** *WIN-OS/2Desktop=0 ************************************************************** * * * ExistingWindowsPath * * * * Specifies the path to an existing Windows** system. * * This option is valid only when option 1 is selected * * for the WIN-OS/2Desktop keyvalue. * * * * Valid Parms: * * * * A string that specifies the path to the existing * * Windows** system (Example: C:\WINDOWS) * * * ************************************************************** *ExistingWindowsPath= ************************************************************** * * * ShareDesktopConfigFiles * * * * Specifies that the desktop configuration files should * * be shared between an existing Windows** system and the * * WIN-OS/2 system being installed. If this option is * * selected, the Windows** desktop will be updated when * * changes are made to the WIN-OS/2 desktop. This * * option is valid only when option 1 is selected for the * * WIN-OS/2Desktop keyvalue. * * * * Valid Parms: * * * * 0=Do not share the Windows** desktop configuration * * files * * 1=Share the Windows** desktop configuration files * * * ************************************************************** *ShareDesktopConfigFiles=1 ************************************************************** * * * DPMI * * * * Specifies which DPMI options to install. * * * * Valid Parms: * * * * 0=none * * 1=All (DEFAULT) * * 2=Virtual DOS Protect Mode Interface * * 3=Virtual Expanded Memory Management * * 4=Virtual Extended Memory Support * * * ************************************************************** DPMI=1 ************************************************************** * * * ExitOnError * * * * Specifies if the install program should exit with an * * error code if an error occurs. This also determines * * whether the installation process will exit with a return* * code when it completes rather than the C-A-D panel. * * * * Valid Parms: * * * * 0 = Do not exit when error occurs; display panel * * (DEFAULT) * * 1 = Exit quietly with a return code * * * ************************************************************** ExitOnError=0 ************************************************************** * * * Fonts * * * * Specifies which fonts should be installed * * * * Valid Parms: * * * * 0 = None * * 1 = All (DEFAULT) * * 2 = Courier (Bitmap) * * 3 = Helvetica (Bitmap) * * 4 = System Mono-spaced (Bitmap) * * 5 = Times Roman (Bitmap) * * 6 = Courier (Outline) * * 7 = Helvetica (Outline) * * 8 = Times New Roman (Outline) * * * ************************************************************** Fonts=1 ************************************************************** * * * FormatPartition * * * * Specifies whether or not to format the install * * partition * * * * Valid Parms: * * * * 0=Do not format (DEFAULT) * * 1=Format * * * ************************************************************** FormatPartition=0 ************************************************************** * * * Include * * * * For a description of the function of this keyword, * * see IncludeAtEnd which is functionally equivalent * * to this keyword. * * * * Valid Parms: * * * * KEYWORD = valid filename * * * ************************************************************** * Include=include.rsp ************************************************************** * * * IncludeAtEnd * * * * Specifies another response file to process along * * with the current one. There may be multiple * * occurrences of this keyword. The "included" * * response file is appended to the end of all * * response files that have been processed before * * this one. * * * * File1.RSP Processing * * +------------------------+ ---------- * * | IncludeAtEnd=File2.RSP | Mouse=1 * * | IncludeAtEnd=File4.RSP | Mouse=2 * * | Mouse=1 | Mouse=4 * * +------------------------+ Mouse=3 * * File2.RSP * * +------------------------+ * * | IncludeAtEnd=File3.RSP | * * | Mouse=2 | * * +------------------------+ * * File3.RSP * * +------------------------+ * * | Mouse=3 | * * +------------------------+ * * File4.RSP * * +------------------------+ * * | Mouse=4 | * * +------------------------+ * * * * No validity checking is done. * * * * Valid Parms: * * * * KEYWORD = valid filename * * * ************************************************************** * IncludeAtEnd=atend.rsp ************************************************************** * * * IncludeInLine * * * * Specifies another response file to process along * * with the current one. There may be multiple * * occurrences of this keyword. The "included" * * response file is processed immediately when the * * keyword is found. * * No validity checking is done. * * * * File1.RSP Processing * * +-------------------------+ ---------- * * | IncludeInLine=File2.RSP | Mouse=3 * * | IncludeInLine=File4.RSP | Mouse=2 * * | Mouse=1 | Mouse=4 * * +-------------------------+ Mouse=1 * * File2.RSP * * +-------------------------+ * * | IncludeInLine=File3.RSP | * * | Mouse=2 | * * +-------------------------+ * * File3.RSP * * +-------------------------+ * * | Mouse=3 | * * +-------------------------+ * * File4.RSP * * +-------------------------+ * * | Mouse=4 | * * +-------------------------+ * * * * Valid Parms: * * * * KEYWORD = valid filename * * * ************************************************************** * IncludeInLine=inline.rsp ΓòÉΓòÉΓòÉ 22.5. A Sample Response File (Continued) ΓòÉΓòÉΓòÉ The following files are a continuation of the sample response file. ************************************************************** * * * MigrateConfigFiles * * * * Specifies whether or not to migrate configuration files * * from a previous release of the operating system. * * * * Valid Parms: * * * * 0=Do not migrate * * 1=Migrate files (DEFAULT) * * * ************************************************************** MigrateConfigFiles=1 ************************************************************** * * * MigrateApplications * * * * Specifies whether or not to migrate existing DOS, * * Windows** and OS/2 applications. Only those * * applications listed in the database specified will * * be migrated. * * * * Valid Parms: * * * * Drives to search, database to use for search * * (Example: C:D:,C:\OS2\INSTALL\DATABASE.DAT) * * * ************************************************************** *MigrateApplications= ************************************************************** * * * MoreBitmaps * * * * Specifies whether or not to install more bitmaps. * * * * Valid Parms: * * * * 0=Do not install More Bitmaps * * 1=Install More Bitmaps (DEFAULT) * * * ************************************************************** MoreBitmaps=1 ************************************************************** * * * Mouse * * * * Specifies which mouse device driver, if any, to * * install * * * * Valid Parms: * * * * 0 = No pointing device support * * 1 = PS/2 Style Pointing Devicee (DEFAULT) * * 2 = Bus Version * * 3 = Serial Version * * 4 = InPort Version * * 5 = Logitech (tm) 'C' Series Serial Mouse * * 6 = IBM PS/2 Touch Display * * 7 = Logitech 'M' Series Mouse * * 8 = PC Mouse Systems (tm) Mouse * * 9 = Other Pointing Device for Mouse Port * * * ************************************************************** Mouse=1 ************************************************************** * * * MousePort * * * * Specifies to which port a serial-type mouse should * * be attatched (valid for serial or Logitech(tm) mice) * * * * Valid Parms: * * * * 0 = No port necessary (DEFAULT) * * 1 = COM1 * * 2 = COM2 * * 3 = COM3 * * 4 = COM4 * * * ************************************************************** MousePort=0 ************************************************************** * * * OptionalFileSystem * * * * Specifies whether or not to install optional file * * system(s) that is, HPFS * * * * Valid Parms: * * * * 0=Do Not Install Optional File System(s) * * 1=Install Optional File System (DEFAULT) * * * ************************************************************** OptionalFileSystem=1 ************************************************************** * * * OptionalSystemUtilities * * * * Specifies whether or not to install the following * * system utilities. * * * * Valid Parms: * * * * 0=Install none * * 1=Install all (DEFAULT) * * 2=Backup Hard Disk * * 3=Change File Attributes * * 4=Display Directory Tree * * 5=Manage Partitions * * 6=Label Diskettes * * 7=Link Object Modules * * 8=Picture Utilities * * 9=PMREXX * * 10=Recover Files * * 11=Restore Backed-up Files * * 12=Sort Filter * * 13=Installation Aid * * * * Example: * * OptionalSystemUtilities=2,9,4 * * would install Backup, PMREXX and Tree utilities. * * * ************************************************************** OptionalSystemUtilities=1 ************************************************************** * * * OS2IniData * * * * Specifies a profile string to be written to the * * user configuration file OS2.INI. There may be * * multiple occurrences of this keyword. * * * * Valid Parms: * * * * KEYWORD = /AppName/KeyName/KeyValue/ * * * * NOTE: Since each of these names can contain * * imbedded blanks and white space, the "slash" * * character must be used as a delimiter. There * * must be three tokens delineated on all sides or * * this keyword will be ignored. * * * ************************************************************** OS2IniData=/AppName/KeyName/KeyValue/ ************************************************************** * * * PCMCIA * * * * Specifies whether or not to install PCMCIA. * * * * Valid Parms: * * * * 0=Do not install * * 1=Install (DEFAULT) * * * ************************************************************** PCMCIA=1 ************************************************************** * * * PrimaryCodePage * * * * Specifies whether "national" or "multi-lingual" code * * page is primary (first active code page before * * switching). * * * * Valid Parms: * * * * 1=National (DEFAULT) * * 2=Multilingual * * * ************************************************************** PrimaryCodePage=1 ************************************************************** * * * PrinterPort * * * * Specifies to which printer port the default printer * * should be attached * * * * Valid Parms: * * * * 1=LPT1 (DEFAULT) * * 2=LPT2 * * 3=LPT3 * * 4=COM1 * * 5=COM2 * * 6=COM3 * * 7=COM4 * * * ************************************************************** PrinterPort=1 ************************************************************** * * * ProcessEnvironment * * * * Each of the Keyword/Keyvalue statements specified in * * this response file may be added to the environment as * * environment variables. * * This makes it possible for user programs, batch files, * * etc. (UserExit) to access response file settings. * * * * Valid Parms: * * * * 0 = Do not add keyword/keyvalue statements specified * * in this response file to environment. * * 1 = Add all keyword/keyvalue statements specified * * in this response file to environment (DEFAULT). * * * ************************************************************** ProcessEnvironment=1 ************************************************************** * * * ProgressIndication * * * * Specifies whether or not to display progress indicators * * during the installation. Disabling this will allow a * * frontend program to display something else while we do * * our job in an unattended environment. * * * * Valid Parms: * * * * 0 = No progress indication * * 1 = Progress indication (DEFAULT) * * * ************************************************************** ProgressIndication=1 ************************************************************** * * * RebootRequired * * * * Specifies if the machine should be automatically * * warm booted when installation is complete. This is * * ignored if the ExtendedInstall response is specified. * * * * Valid Parms: * * * * 0=Ask user to reboot (DEFAULT) * * 1=Auto-reboot * * * ************************************************************** RebootRequired=0 ************************************************************** * * * REXX * * * * Specifies whether or not to install REXX * * * * Valid Parms: * * * * 0=Do not Install REXX * * 1=Install REXX (DEFAULT) * * * ************************************************************** REXX=1 ************************************************************** * * * SCSI * * * * Specifies which, if any, CD ROM adapter support you * * wish to install support for. * * * * Valid Parms: * * * * 0 = None * * 1 = Autodetect * * 2=Adaptec1510, 1520, 1522 * * 3=Adaptec1540, 1542 * * 4=Adaptec1640 * * 5=Adaptec1740, 1742, 1744 * * 6=DPTPM2011, PM2012 * * 7=FutureDomain 845,850,850IBM,860,875,885 * * 8=FutureDomain 1650,1660,1670,1680,MCS700 * * 9=FutureDomain 7000EX * * 10=IBMPS/2 SCSI Adapter * * 11=IBM16-Bit AT Fast SCSI Adapter * * * ************************************************************** SCSI=1 ************************************************************** * * * SerialDeviceSupport * * * * Specifies whether or not to install the serial * * device driver. * * * * Valid Parms: * * * * 0=Do not install * * 1=Install (DEFAULT) * * * ************************************************************** SerialDeviceSupport=1 ************************************************************** * * * SourcePath * * * * Specifies a single media (no disk switching) that should* * be used as a source drive and directory from which to * * install. * * * * Valid Parms: * * * * KEYVALUE=drive and optional path (D:\OS2SE20\...) * * DEFAULT=A:\ * * * ************************************************************** * SourcePath=D:\os2se20 ************************************************************** * * * TargetDrive * * * * Specifies the target drive to which OS/2 should be * * installed. This drive is assumed to be a valid * * partition. If a partition other than C: is specified, * * it is assumed that MOST support is already installed to * * enable booting an operating system from any partition. * * * * Valid Parms: * * * * KEYVALUE=d: * * * * where "d:" is a valid partition that OS/2 may be * * installed to. * * DEFAULT=first acceptable partition * * * ************************************************************** TargetDrive=C: ************************************************************** * * * WIN-OS/2TargetDrive * * * * Specifies which valid partition drive to install * * WIN-OS/2. * * * * Valid Parms: any valid FORMATTED partition. * * * * C: (DEFAULT) * * D: * * . * * . * * * * Z: * * * * Example: * * * * WIN-OS/2TargetDrive=D: * * would install WIN-OS/2 to partition D: located in * * \OS2\MDOS\WINOS2 * * * ************************************************************** *WIN-OS/2TargetDrive=C: ************************************************************** * * * ToolsAndGames * * * * Specifies whether or not to install tools and games * * such as editors and jigsaw. * * * * Valid Parms: * * * * 0=Install none * * 1=Install all (DEFAULT) * * 2=Enhanced Editor * * 3=Search and Scan Tool * * 4=Terminal Emulator * * 5=Chart Maker * * 6=Personal Productivity * * 7=Solitaire - Klondike * * 8=Reversi * * 9=Scramble * * 10=Cat and Mouse * * 11=Pulse * * 12=Jigsaw * * 13=Chess * * * * Example: * * ToolsAndGames=2,8,13 * * would install the Enhanced Editor, Reversi and * * Chess. * * * ************************************************************** ToolsAndGames=1 ************************************************************** * * * ConfigSysLine * * * * Specifies a text line to be appended to CONFIG.SYS. * * There may be multiple occurrences of this keyword. * * No validity checking is done. * * * * Valid Parms: * * * * KEYWORD = a valid CONFIG.SYS statement * * * ************************************************************** * ConfigSysLine=REM This is a CONFIG.SYS remark line. ************************************************************** * * * Copy * * * * Specifies a source file and destination directory * * of a file to be copied during install. Errors are * * ignored, though they will be logged. Packed files * * are acceptable since UNPACK will do the copy. * * There may be multiple occurrences of this keyword. * * No validity checking is done. * * * * Valid Parms: * * * * KEYWORD= source file destination * * * * where source file = valid filename * * and destination = valid directory name * * * * ex: Copy = readme.dat c:\os2 * * * ************************************************************** * Copy=vga c:\ /n:ini.rc ************************************************************** * * * EarlyUserExit * * * * Specifies the name of a program that Install will * * DosExec after the target drive is prepared. Install * * waits for the program to return. This keyword may occur* * more than once. Each will be executed in the order that* * they appear at the end of OS/2 Install. The only * * difference between this keyword and the UserExit keyword* * is that this one is executed early in the installation * * process while the latter is executed at the very end. * * * * Valid Parms: * * * * KEYVALUE=user exit program name (DEFAULT=none) * * * ************************************************************** * EarlyUserExit=T c:\config.sys ************************************************************** * * * ExtendedInstall * * * * Specifies program to be run asynchronously while SE * * Install DosExits * * * * Valid Parms: * * * * KEYVALUE=full pathname of program * * (DEFAULT=none) * * * ************************************************************** * ExtendedInstall=PROGRAM.EXE ************************************************************** * * * ID * * * * Specifies some identification string which may be * * used by install or UserExit to identify the * * response file(s) used for this installation * * * * Valid Parms: * * * * KEYWORD = ASCII string * * * ************************************************************** *ID=OS2SE20 Sample Response File ************************************************************** * * * SeedConfigSysLine * * * * Specifies a text line to be appended to the CONFIG.SYS * * written to the seed system from which PM Install boots. * * This will allow device drivers (that may be required) to* * become part of that seed system. * * There may be multiple occurrences of this keyword. * * No validity checking is done. * * * * Valid Parms: * * * * KEYWORD = a valid CONFIG.SYS statement * * * ************************************************************** * SeedConfigSysLine=REM This is a remark line in the seed CONFIG.SYS. ************************************************************** * * * UserExit * * * * Specifies the name of a program that Install will * * DosExec before exiting memory. Install waits for the * * program to return. This keyword may occur more than * * once. Each will be executed in the order that they * * appear at the end of OS/2 Install. * * * * Valid Parms: * * * * KEYVALUE=user exit program name (DEFAULT=none) * * * ************************************************************** * UserExit=T.EXE C:\OS2\INSTALL\INSTALL.LOG ************************************************************** * * * Version * * * * Specifies specific version of the operating system for * * which this file is intended. The file can be used for * * future versions, though some keywords may no longer * * be valid. * * * * Valid Parms: * * * * KEYWORD = some version string (determined later) * * * ************************************************************** *Version=OS2SE20 ************************************************************** * * * DDInstall * * Use OS/2 Device Driver Installation to install external * * loadable device drivers. A Device Driver Profile ( a * * text file with a .DDP file name extension) must be * * provided by the device driver author to control the * * installation of the device driver. * * * * Valid Parms: * * DDISrc = Directory where the .DDP files are. * * DDIDest = Directory where to copy the device driver * * files. * * DDIDDP = List of .DDP files to install. * * (example: file1.DDP,file2.DDP) * * * * * ************************************************************** *DDISrc = Z:\DDP *DDIDest = C:\ ΓòÉΓòÉΓòÉ 23. Commands Reference ΓòÉΓòÉΓòÉ This appendix contains syntax and other detailed information for the following commands: CASAGENT Selects the LAN CID Utility command to run the installation. CASCKREX Determines if REXX is initialized. CASDELET Deletes LAN CID Utility. CASINSTL Installs LAN CID Utility. CASPREP Creates the LAN CID Utility REXX command file. CASSETUP Is a code server setup utility. FSERVICE Applies Service Paks to program products on the client. GETBOOT Gets SETBOOT and XCOPY from the OS/2 2.x diskettes. GETFIX Gets the required fixes for the OS/2 2.x files that LAN CID Utility uses. GETOSCID Gets the required OS/2 2.x redirected installation files. GETREXX Gets REXX files from the OS/2 2.x diskettes. IFSDEL Deletes the SRVIFS utility. SEDISK Creates boot diskettes with a minimal version of the OS/2 2.x program. SEIMAGE Installs the OS/2 2.x product images on the code server. SEINST Is the CID-enabled OS/2 2.x installation program. SEMAINT Creates the OS/2 2.x maintenance system. SERVICE Starts a SRVIFS server and performs status, update, and stop functions. SRVATTCH Attaches to a SRVIFS server. SRVIFSC.IFS Initiates the SRVIFS installable file system function. THINIFS Installs the SRVIFS requester on the client. THINLAPS Installs a thin version of LAPS on the boot diskettes. THINSRV Installs the SRVIFS server on the code server. Unless otherwise specified, parameters for these commands can be entered as uppercase or lowercase and can be in any order. Note: For information on the LAPS command, see the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide. For information on the CMSETUP, ESAINST, LANINSTR commands and other installation commands for CID-enabled products, see the documentation for those products. ΓòÉΓòÉΓòÉ 23.1. CASAGENT ΓòÉΓòÉΓòÉ The CASAGENT command is used to select an appropriate LAN CID Utility command file to run an installation. The CASINSTL command places the CASAGENT command in STARTUP.CMD. When called, CASAGENT tries to run the LAN CID Utility REXX command file, corresponding to the LAN CID Utility client name, located in the directory that is specified on the /CMD: parameter. If CASAGENT does not find this command file, but if the /D or /D: parameter is specified, CASAGENT tries to run the default command file in the subdirectory specified on the /CMD: parameter. If CASAGENT cannot find the default command file, it exits with an error. The LAN CID Utility client name can come from SRVIFS or from the CASAGENT command line. The LAN CID Utility client name is determined with the following rules: o If the /REQ: parameter is specified on the CASAGENT command line, the LAN CID Utility client name is one of the following: - The value specified on the /REQ: parameter if the value was not *P or *. - The name specified by the user if the value on the /REQ: parameter was *P. - A name randomly selected by CASAGENT if the value on the /REQ: parameter was *. o If SRVIFS is loaded, a SRVIFS drive is attached, and the /REQ: parameter was not provided on the CASAGENT command line, the LAN CID Utility client name is the SRVIFS requester name. ΓòÉΓòÉΓòÉ 23.1.1. Prerequisites ΓòÉΓòÉΓòÉ Following are the prerequisites for running CASAGENT: o If the /REQ: parameter is not provided on the CASAGENT command line, the SRVIFS client name must be available. Therefore, the SRVIFS requester must be installed and active. In addition, CASAGENT must have a redirected SRVIFS drive available. o The REXX files for OS/2 2.x must be available. In addition, the LAN CID Utility image directory (<path>\IMG\LCU) must be in the active LIBPATH= and DPATH= statements on the client. To modify these path statements, specify the appropriate subdirectories on the /PL and /PA parameters of the CASINSTL command. See CASINSTL for more information. ΓòÉΓòÉΓòÉ 23.1.2. Invocation ΓòÉΓòÉΓòÉ CASAGENT is invoked within STARTUP.CMD and is run when the client is rebooted. CASAGENT can also be run from the command line. ΓòÉΓòÉΓòÉ 23.1.3. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates CASAGENT syntax: ΓöîΓöÇΓöÇΓöÇ CASAGENT ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\CASAGENTΓöÇΓöÇ/CMD:pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/REQ:xxxxxxxxΓöÇΓöÿ Γö£ΓöÇ/DΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé ΓööΓöÇ/D:filenameΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/L1:path\filenameΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ CASAGENT is located in the <path>\IMG\LCU directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.1.4. Parameters ΓòÉΓòÉΓòÉ The following list describes the CASAGENT parameters: /CMD:path The redirected drive and path to the directory containing the LAN CID Utility command file that drives the installation. See Creating LAN CID Utility REXX Command Files, for details on this command file. The file name of the LAN CID Utility command file is to be the LAN CID Utility client name previously described. If you used the recommended directory structure, this parameter is <path>\CLIENT. However, the drive for this path is the redirected drive for this subdirectory on the client. This parameter is required. /REQ:xxxxxxxx The LAN CID Utility client name for this workstation. The supported values are: o An alphanumeric name 1 through 20 bytes long. (The underscore character is also allowed.) o *P This value specifies to prompt for the client name. Specifying *P for the client name prompts the user at the workstation for the LAN CID Utility client name during installation. o * This value specifies to allow CASAGENT to randomly select an 8-byte LAN CID Utility client name for the workstation. If this selection is chosen, one of the /D or /D: parameters is required on the command line. This parameter is optional if SRVIFS is being used as the redirector, otherwise it is required. Warning: At this time, some programs, such as FSERVICE and SEINST, do not support long file names for the response files and log files. If you are using LAN CID Utility client names more than 8 bytes long and you are using the LAN CID Utility client name for the response file and log file names, it is important that you test your LAN CID Utility command file before using it in a production environment to determine if the install programs you are using support long file names. /D The indicator to search for and run the default LAN CID Utility command file the DEFAULT.CMD file if a command file matching the client name cannot be found. the DEFAULT.CMD file must be located in the directory indicated on the /CMD: parameter. This parameter is optional. If the /REQ:* was specified on the command line, this parameter or the /D: parameter must also be specified on the command line. If the /D: parameter is specified on the command line, this parameter cannot be specified on the command line. /D:filename The indicator to search for and run the default LAN CID Utility command file filename.CMD if a command file matching the client name cannot be found. The file must be located in the directory indicated on the /CMD: parameter. The filename can be indicated with or without the .CMD extension. This parameter is optional. If the /REQ:* was specified on the command line, this parameter or the /D parameter must also be specified on the command line. If the /D parameter is specified on the command line, this parameter cannot be specified on the command line. /L1:path\filename The fully qualified name of the file that CASAGENT and the LAN CID Utility REXX command file running the installation uses as the log file. Note: If you entered * or *P on the diskettes for the client name, it is recommended that you use the SRVIFS_REQ keyword for the log file name. This ensures that a unique log file is used for each client installed with these diskettes. The SRVIFS_REQ keyword tells LAN CID Utility to replace the SRVIFS_REQ keyword in the log file name with the LAN CID Utility client name being generated at run time. This parameter is optional. ΓòÉΓòÉΓòÉ 23.1.5. Return Values ΓòÉΓòÉΓòÉ 0 CASAGENT ended successfully. 1 CASAGENT was run without parameters. 2 CASAGENT was run with invalid or missing parameters. 3 The logfile was not found. 4 The directory specified on the /CMD: parameter was not found. 5 REXX is not initialized. 6 A client name is not available. 7 The REXX command file was not found. Note: If CASAGENT returns 0, it does not necessarily mean that the LAN CID Utility command file also completed successfully. ΓòÉΓòÉΓòÉ 23.1.6. Examples ΓòÉΓòÉΓòÉ CASAGENT Examples X:\IMG\LCU\CASAGENT /CMD:X:\CLIENT /L1:X:\LOG\LCU\SRVIFS_REQ.LOG /D X:\IMG\LCU\CASAGENT /CMD:X\CLIENT /REQ:* /L1:X:\LOG\LCU\SRVIFS_REQ.LOG /D:ENGDEF.CMD ΓòÉΓòÉΓòÉ 23.2. CASCKREX ΓòÉΓòÉΓòÉ The CASCKREX command is used to determine if REXX is initialized on the client workstation. CASCKREX is ordinarily run by the CASAGENT program immediately before running the LAN CID Utility command file. CASCKREX can also be run by the user. If CASCKREX is run from the command line, a message is displayed indicating whether or not REXX is initialized on the workstation. ΓòÉΓòÉΓòÉ 23.2.1. Invocation ΓòÉΓòÉΓòÉ CASCKREX is invoked by the CASAGENT program or from the command line. ΓòÉΓòÉΓòÉ 23.2.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates CASCKREX syntax: ΓöîΓöÇΓöÇΓöÇ CASCKREX ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\CASCKREXΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇCASAGENTΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ CASCKREX is located in the <path>\IMG\LCU directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.2.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the CASCKREX parameters: CASAGENT This parameter indicates that messages should not be printed to the screen. This parameter is used when CASAGENT runs CASCKREX. This parameter is optional. ΓòÉΓòÉΓòÉ 23.2.4. Return Values ΓòÉΓòÉΓòÉ 0 REXX is initialized. 1 REXX is not initialized. ΓòÉΓòÉΓòÉ 23.2.5. Example ΓòÉΓòÉΓòÉ CASCKREX Example X:\IMG\LCU\CASCKREX ΓòÉΓòÉΓòÉ 23.3. CASDELET ΓòÉΓòÉΓòÉ The CASDELET command is used to delete LAN CID Utility from the client workstation at the end of a system installation. You should delete LAN CID Utility to prevent CASAGENT from attempting installs after every reboot of the workstation. ΓòÉΓòÉΓòÉ 23.3.1. Invocation ΓòÉΓòÉΓòÉ CASDELET is invoked from the command line or from within a LAN CID Utility command file. ΓòÉΓòÉΓòÉ 23.3.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates CASDELET syntax: ΓöîΓöÇΓöÇΓöÇ CASDELET ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé Γöé Γöé >>ΓöÇΓöÇpath\CASDELETΓöÇΓöÇΓöÇΓöÇ/TU:driveΓöÇΓö┤ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/L1:path\filename.extΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/PL:pathΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ CASDELET is located in the <path>\IMG\LCU directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.3.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the CASDELET parameters: /TU:drive Drive on the client where the CONFIG.SYS and the STARTUP.CMD files are to be updated. If LAN CID Utility has been installed on more than one fixed disk on the client workstation, this parameter can be specified once for each fixed disk that has it installed. This parameter is required and can be specified more than once. /L1:path\filename.ext The fully qualified name of the CASDELET log file. The path should be a redirected drive for the client. It is recommended that the file name include the client name. This parameter is optional. /PL:path The name of a path to be deleted from the LIBPATH= and the DPATH= statements in the CONFIG.SYS file that is being updated on the client. Typically, this path is added by the CASINSTL command. The path should match the /PL: path with which you invoked the CASINSTL command for this client. This parameter is optional. ΓòÉΓòÉΓòÉ 23.3.4. Examples ΓòÉΓòÉΓòÉ CASDELET Examples X:\IMG\LCU\CASDELET /TU:C: /L1:X:\LOG\LCU\PAT.LOG /PL:X:\DLL\V200 X:\IMG\LCU\CASDELET /TU:C: /TU:E: /TU:F: ΓòÉΓòÉΓòÉ 23.4. CASINSTL ΓòÉΓòÉΓòÉ The CASINSTL command is used to install LAN CID Utility on either the boot diskettes or onto the fixed disk of a client workstation during system installation. ΓòÉΓòÉΓòÉ 23.4.1. Invocation ΓòÉΓòÉΓòÉ CASINSTL is invoked from the command line or from within a LAN CID Utility command file. ΓòÉΓòÉΓòÉ 23.4.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates CASINSTL syntax: ΓöîΓöÇΓöÇΓöÇ CASINSTL ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\CASINSTLΓöÇΓöÇ/TU:driveΓöÇΓöÇ/CMD:pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/PL:pathΓöÇΓöÿ ΓööΓöÇ/PA:pathΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/PD:pathΓöÇΓöÿ ΓööΓöÇ/REQ:xxxxxxxxΓöÇΓöÿ Γö£ΓöÇ/DΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ ΓööΓöÇ/0ΓöÇΓöÿ Γöé Γöé ΓööΓöÇ/D:filenameΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/L1:path\filenameΓöÇΓöÿ ΓööΓöÇ/L2:path\filenameΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ CASINSTL is located in the <path>\IMG\LCU directory if you used the recommended directory structure on the code server. ΓòÉΓòÉΓòÉ 23.4.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the CASINSTL parameters: /TU:drive The boot drive where the CONFIG.SYS file is located on the client. If you are creating boot diskettes, this parameter is the drive location for these diskettes. This parameter also indicates the drive where the CONFIG.SYS file and STARTUP.CMD are to be updated. If you are creating boot diskettes, this drive is probably A:; the drive is probably C: if you are enabling a client for installation from a fixed disk. This parameter is required. /CMD:path The redirected drive and path to the directory containing the LAN CID Utility command file that drives the installation. See Creating LAN CID Utility REXX Command Files, for details on this command file. The file name of the LAN CID Utility command file is LAN CID Utility client name. See CASAGENT for information on how the client name is determined. If you used the recommended directory structure, this parameter is <path>\CLIENT. However, the drive for this path is the redirected drive for this subdirectory on the client. This parameter is required. /PL:path The redirected drive and path to be appended to the LIBPATH= and DPATH= statements in the CONFIG.SYS file that is updated on the client or boot diskettes. Typically, the purpose of this parameter is to permit REXX to find the DLLs and message files it needs. This parameter is normally the redirected drive letter and the subsequent paths to the directories containing the REXX DLLs and message files installed by GETREXX. You can specify multiple paths with semicolons but no spaces separating the paths, for example, x:\path1;x:\path2;x:\path3 If you used the recommended directory structure, this parameter includes the <path>\DLL\V2xx directory. This parameter is optional if the client workstation has the appropriate level of REXX installed and accessible through the LIBPATH= statement. However, this parameter is required for proper operation if you are installing with boot diskettes. /PA:path The redirected drive and path to the LAN CID Utility program files. These files are typically located on the code server in the <path>\IMG\LCU subdirectory. This path is added to the LIBPATH= and DPATH= statements in the CONFIG.SYS file that is updated on the client or boot diskettes. This path is also used to locate the CASAGENT and SRVREXX programs in the STARTUP.CMD and the CONFIG.SYS files respectively. This parameter is optional if the LAN CID Utility files are accessible on the client workstation through the LIBPATH=, DPATH=, and PATH= statements in the CONFIG.SYS file. However, this parameter is required for proper operation if you are installing with boot diskettes. /PD:path The redirected drive and path to the workstation LAN CID Utility boot diskette 1 image on the code server. This path is <path>\DISK1\V2xx if you used the recommended directory structure. This parameter is used if you want to be able to remove the LAN CID Utility boot diskette 1 at the beginning of the first section of the installation instead of waiting until just before the first reboot. Note: CASINSTL does not copy the diskette into this directory. It is up to the administrator to ensure that the directory contains the up-to-date LAN CID Utility boot diskette 1 files. This parameter is optional. /REQ:xxxxxxxx The LAN CID Utility client name of the target workstation. The supported values are: o An alphanumeric name 1 through 20 bytes long. (The underscore character is also allowed.) o *P This value specifies to prompt for the client name. Specifying *P for the client name prompts the user at the workstation for the LAN CID Utility client name during installation. o * This value specifies to allow CASAGENT to randomly select an 8-byte LAN CID Utility client name. If this selection is chosen, one of the /D or /D: parameters are required on the command line. This parameter is optional. Warning: At this time, some programs, such as FSERVICE and SEINST, do not support long file names for the response files and log files. If you are using LAN CID Utility client names more than 8 bytes long and you are using the LAN CID Utility client name for the response file and log file names, it is important that you test your LAN CID Utility command file before using it in a production environment to determine if the install programs you are using support long file names. /D The indicator to search for and run the default LAN CID Utility command file the DEFAULT.CMD file if a command file matching the client name cannot be found. The file must be located in the directory indicated on the /CMD: parameter. This parameter is optional. If the /REQ:* was specified on the command line, this parameter or the /D: parameter must also be specified on the command line. If the /D: parameter is specified on the command line, this parameter cannot be specified on the command line. /D:filename The indicator to search for and run the default LAN CID Utility command file filename.CMD if a command file matching the client name cannot be found. The file must be located in the directory indicated on the /CMD: parameter. The filename can be indicated with or without the .CMD extension. This parameter is optional. If the /REQ:* was specified on the command line, this parameter or the /D parameter must also be specified on the command line. If the /D parameter is specified on the command, this parameter cannot be specified on the command line. /0 The indicator that the next LAN CID Utility command file run on the target workstation should start at the beginning of the installation. When this parameter is indicated, all variables (CAS_...state) are removed from the CONFIG.SYS file on the drive indicated on the /TU parameter. Warning: Do not specify this parameter inside a LAN CID Utility command file or else the command file does not run correctly. This parameter is optional. /L1:path\filename The redirected drive and path to the files that CASINSTL, CASAGENT, and the LAN CID Utility command file driving the installation uses as log files. If you used the recommended directory structure, this path is <path>\LOG\LCU. However, the drive for this path is the redirected drive for this subdirectory on the client. This parameter is optional. /L2:path\filename The fully qualified name of the files that CASAGENT and the LAN CID Utility command file driving the installation uses as log files. If you used the recommended directory structure, this parameter is <path>\LOG\LCU. However, the drive for this path is the redirected drive for this subdirectory on the client. The keyword SRVIFS_REQ, explained in the notes that follow the parameter list, indicates the substitution of the client workstation name in the log file name. This parameter is optional. Note: 1. The /L1 and /L2 parameters function as follows: o If only /L1 is defined, CASINSTL, CASAGENT, and the LAN CID Utility command file enter log information to log file 1. o If only /L2 is defined, CASAGENT and the LAN CID Utility command file enter log information to log file 2, and CASINSTL does not log any information. o If both are defined, CASINSTL logs information to log file 1. CASAGENT and the LAN CID Utility command file log information to log file 2. 2. If the LAN CID Utility client name is prompted for or randomly selected either by CASAGENT or SRVIFS, it is recommended that you use the SRVIFS_REQ keyword for the log file name on the /L2 parameter. This ensures that a unique log file is used for each client installed with these diskettes. The SRVIFS_REQ keyword tells LAN CID Utility to replace the SRVIFS_REQ keyword in the log file name with the LAN CID Utility client name being generated at run time. 3. Specify the SRVIFS_REQ keyword only for the /L2 parameter. 4. Only specify the /REQ:* or /REQ:*P parameters when creating boot diskettes or when prepping a workstation fixed disk for install. When CASINSTL is run from within an LAN CID Utility command file, it is recommended that the /REQ: parameter be specified as the client name that was passed into the command file. For example: '/REQ:' || client 5. If the /REQ:* parameter is specified on the command line, the one of the /D or /D: parameters must also be supplied on the command line. 6. Both the /D and /D: cannot be specified on the command line at the same time. 7. If you created boot diskettes specifying the /D or /D: parameter, it is important that you use the same parameter on the CASINSTL command inside the default command file that is to be run. If this is not done, after CASINSTL is run inside the command file and the system is restarted, CASAGENT does not know that it should run a default command file. ΓòÉΓòÉΓòÉ 23.4.4. Examples ΓòÉΓòÉΓòÉ CASINSTL Examples Following is an example if a normal installation of LAN CID Utility. It uses the client name JEFF. X:\IMG\LCU\CASINSTL /CMD:X:\CLIENT /TU:A: /PA:X:\IMG\LCU /PL:X:\DLL\V200 /L2:X:\LOG\LCU\SRVIFS_REQ.LOG /REQ:JEFF Following is an example of installing LAN CID Utility. It uses the default command file, DEFAULT.CMD, in the X:\CLIENT directory. The client name is randomly selected because the /REQ:* parameter was indicated. Because of this, X:\CLIENT\the DEFAULT.CMD file always runs. X:\IMG\LCU\CASINSTL /CMD:X:\CLIENT /TU:A: /PA:X:\IMG\LCU /PL:X:\DLL\V200 /L2:X:\LOG\LCU\SRVIFS_REQ.LOG /REQ:* /D Following is an example of installing LAN CID Utility. It uses the default command file ENGDEF.CMD in the X:\CLIENT directory if a command file corresponding to the client name does not exist. Also, because the /REQ: parameter is not supplied, the client name is obtained from SRVIFS. X:\IMG\LCU\CASINSTL /CMD:X:\CLIENT /TU:A /PA:X:\IMG\LCU /PL:X:\DLL\V200 /PD:X:\DISK1\V200 /L2:X:\LOG\LCU \SRVIFS_REQ.LOG/D:ENGDEF.CMD ΓòÉΓòÉΓòÉ 23.5. CASPREP ΓòÉΓòÉΓòÉ The CASPREP command is used to invoke the sample program CASPREP.CMD, which processes a user-generated Script file into a LAN CID Utility command file. See The CASPREP Program, Keywords, and Input Files for more information on using the CASPREP program. ΓòÉΓòÉΓòÉ 23.5.1. Invocation ΓòÉΓòÉΓòÉ CASPREP is invoked from the command line. ΓòÉΓòÉΓòÉ 23.5.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates CASPREP syntax: ΓöîΓöÇΓöÇΓöÇ CASPREP ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\CASPREPΓöÇΓöÇinputfname.fextΓöÇΓöÇoutputfname.fextΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇbasefname.fextΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ CASPREP is located in the MPTSAPLT.ZIP pack file in the \APPLETS directory on MPTS diskette 3. To unpack to CASPREP program from MPTSAPLT.ZIP, refer to Obtaining the Required CASPREP Files. ΓòÉΓòÉΓòÉ 23.5.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the CASPREP parameters: inputfname.fext A user-generated Script input file built with the keywords described in Keywords. This parameter is required, although the input file name extension is optional. outputfname.fext The name of the LAN CID Utility command file that you want to generate. This parameter is required, although the output file name extension is optional. basefname.fext The name of the CASPREP base file that should be used. The CASPREP base file and the user-generated Script input file are integrated to create the LAN CID Utility command file. The default base file name is CASBASE.FIL. This file can be found in the MPTSAPLT.ZIP pack file in the \APPLETS directory on MPTS diskette 3. To unpack to CASBASE.FIL program from MPTSAPLT.ZIP, refer to Obtaining the Required CASPREP Files. This parameter is optional. Note: If you enter a question mark (?) as a file name or if any of the required parameters are missing, a message explaining the syntax of the command is displayed. ΓòÉΓòÉΓòÉ 23.5.4. Example ΓòÉΓòÉΓòÉ CASPREP Example CASPREP BARB.FIL \CID\CLIENT\BARB.CMD ΓòÉΓòÉΓòÉ 23.6. CASSETUP ΓòÉΓòÉΓòÉ CASSETUP prepares the code server for use. See The CASSETUP Code Server Setup Utility for more information on using the CASSETUP program. ΓòÉΓòÉΓòÉ 23.6.1. Invocation ΓòÉΓòÉΓòÉ CASSETUP is invoked from the command line. ΓòÉΓòÉΓòÉ 23.6.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates CASSETUP syntax: ΓöîΓöÇΓöÇΓöÇ CASSETUP ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\CASSETUPΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The path is the drive and directory where the CASSETUP program is located. This path is <path>\CASSETUP if you followed the instructions in Installing CASSETUP from MPTS Diskette 3. ΓòÉΓòÉΓòÉ 23.6.3. Parameters ΓòÉΓòÉΓòÉ The CASSETUP command does not take any parameters. ΓòÉΓòÉΓòÉ 23.6.4. Examples ΓòÉΓòÉΓòÉ CASSETUP Examples A:CASSETUP D:\CID\APPLETS\CASSETUP ΓòÉΓòÉΓòÉ 23.7. FSERVICE ΓòÉΓòÉΓòÉ The FSERVICE command applies Service Paks to program products on the client workstation. FSERVICE normally runs under a maintenance system created by SEMAINT or boot diskettes created by SEDISK. See SEMAINT for more information on the maintenance system. Warning: At this time, the FSERVICE program does not support long file names for any of the parameters. Long directory names are supported. ΓòÉΓòÉΓòÉ 23.7.1. Invocation ΓòÉΓòÉΓòÉ FSERVICE is invoked from the command line or from within a LAN CID Utility command file. ΓòÉΓòÉΓòÉ 23.7.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the FSERVICE syntax for operation in unattended mode: ΓöîΓöÇΓöÇΓöÇ FSERVICE ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\FSERVICEΓöÇΓöÇ/S:pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇ/R:path\filename.extΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/T:targetΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/L1:path\filename.extΓöÇΓöÿ ΓööΓöÇ/CIDΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ With the recommended directory structure and an OS/2 2.0 Service Pak, this path is <path>\CSD\OS2V20\CSD01 ΓòÉΓòÉΓòÉ 23.7.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the FSERVICE parameters used in an unattended installation: /S:path The fully qualified path to the Service Pak images. The path can be either a local fixed disk or a redirected drive on the code server. If you used the recommended directory structure and an OS/2 2.0 Service Pak, this path is <path>\CSD\OS2V20\CSD01 This parameter is required. /T:target The fully qualified path to the target directory from which the system was booted. If the system was booted from a maintenance system on the fixed disk, this path matches the /T: parameter passed on the previous invocation of the SEMAINT program. FSERVICE restores the CONFIG.SYS, STARTUP.CMD, and AUTOEXEC.BAT files from backups located in this directory. This parameter is optional. If this parameter is specified when booted from diskette, no parameter validation is done on its value. Warning: Because FSERVICE deletes all files as it cleans up this subdirectory, back up the files you want to save. /R:path\filename.ext The fully qualified file name of a response file supported by FSERVICE. A sample of this response file, RESPONSE.FIL, is supplied with the Service Pak. It is located in the <path>\CSD\OS2V20\CSD01 directory if you used the recommended directory structure. This parameter is required. /L1:path\filename.ext The fully qualified path to the file into which the Service Pak log information is to be placed. This parameter is optional. /CID This parameter indicates that FSERVICE should restore the following files from the backups made by SEMAINT: OS2BOOT OS2KRNL OS2LDR OS2DASD.DMD OS2SCSI.DMD OS2LDR.MSG This parameter is optional. Note: 1. This parameter is not supported on all versions of the FSERVICE program. Before using this parameter, check the documentation provided with the Service Pak you plan to apply to see if this parameter is supported. 2. This parameter should be indicated only if FSERVICE is running under a maintenance system created by SEMAINT. 3. The SEMAINT program that created the maintenance system must support the backing up of the indicated files. The SEMAINT program from OS/2 2.1 Service Pak XR06200 or higher supports this function. Note: 1. If more than one Service Pak is to be applied to the workstation, it is possible to run them in the same LAN CID Utility OVERALL_STATE. When this is done, if the Service Paks are to be applied when running under a maintenance system created by SEMAINT, you should supply the /T: parameter only to the first FSERVICE program that is to be run. 2. If the /CID parameter is not supplied, the /T: parameter is supplied, and FSERVICE is running under a maintenance system created by SEMAINT, the OS2BOOT, OS2KRNL, OS2LDR ... files are not restored from backups, but the CONFIG.SYS, STARTUP.CMD, and AUTOEXEC.BAT files are restored from backups located in the directory indicated on the /T: parameter. Check your Service Pak documentation for any modifications to this rule. ΓòÉΓòÉΓòÉ 23.7.4. Examples ΓòÉΓòÉΓòÉ FSERVICE Examples X:\CSD\OS2V20\CSD01\FSERVICE /S:X:\CSD\OS2V20\CSD01 /T:C:\SERVICE /R:X:\CSD\OS2V20\CSD01\RESPONSE.FIL /L1:X:\LOG\CSD\OS2V20 \WS1.LOG X:\CSD\OS2V21\CSD01\FSERVICE /S:X:\CSD\OS2V21\CSD01 /R:X:\RSP\CSD\OS2V21\WS1.RSP /CID ΓòÉΓòÉΓòÉ 23.8. GETBOOT ΓòÉΓòÉΓòÉ The GETBOOT command is used to ensure that SETBOOT and XCOPY are available for use by LAN CID Utility. ΓòÉΓòÉΓòÉ 23.8.1. Invocation ΓòÉΓòÉΓòÉ GETBOOT is invoked from the command line. ΓòÉΓòÉΓòÉ 23.8.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates GETBOOT syntax: ΓöîΓöÇΓöÇΓöÇ GETBOOT ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\GETBOOTΓöÇΓöÇsource_pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇtarget_pathΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ GETBOOT is located in the <path>\IMG\LCU directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.8.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the GETBOOT parameters: source_path The path where the OS/2 2.x product images have been placed. With the recommended directory structure and OS/2 2.0, this path is <path>\IMG\OS2V20. This parameter is required. target_path The path to the subdirectory where SETBOOT and XCOPY should be placed. This directory needs to be accessible to the client through SRVIFS. With the recommended directory structure and OS/2 2.0, this path is <path>\EXE\V200. This parameter is optional and defaults to the current directory. ΓòÉΓòÉΓòÉ 23.8.4. Example ΓòÉΓòÉΓòÉ GETBOOT Example D:\CID\IMG\LCU\GETBOOT D:\CID\IMG\OS2V20 D:\CID\EXE\V200 ΓòÉΓòÉΓòÉ 23.9. GETFIX ΓòÉΓòÉΓòÉ The GETFIX command is used to retrieve OS/2 2.x Service Pak fixes for the OS/2 2.x files that LAN CID Utility requires. ΓòÉΓòÉΓòÉ 23.9.1. Invocation ΓòÉΓòÉΓòÉ GETFIX is invoked from the command line. ΓòÉΓòÉΓòÉ 23.9.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates GETFIX syntax: ΓöîΓöÇΓöÇΓöÇ GETFIX ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\GETFIXΓöÇΓöÇsource_pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇtarget_pathΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ GETFIX is located in the <path>\IMG\LCU directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.9.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the GETFIX parameters: source_path The path where the OS/2 2.x Service Pak is located. With the recommended directory structure and an OS/2 2.0 Service Pak, this path is <path>\CSD\OS2V20\CSD01. This parameter is required. target_path The path where SEINST, RSPINST, UNPACK, and other OS/2 specific programs that are used during installation are located. With the recommended directory structure and OS/2 2.0, this path is <path>\EXE\V200. If UNPACK.EXE is not located in this directory or in the source_path directory, the program exits with an error. This parameter is optional and defaults to the current directory. ΓòÉΓòÉΓòÉ 23.9.4. Example ΓòÉΓòÉΓòÉ GETFIX Example D:\CID\IMG\LCU\GETFIX D:\CID\CSD\OS2V20\CSD1 D:\CID\EXE\V200 ΓòÉΓòÉΓòÉ 23.10. GETOSCID ΓòÉΓòÉΓòÉ The GETOSCID command is used to retrieve the required OS/2 2.x CID files from the OS/2 2.x product images on the fixed disk of the code server. GETOSCID gets the following files and places them in the target directory: o Files from the CID pack file SEDISK.EXE SEIMAGE.EXE SEINST.EXE SEMAINT.EXE. o Files from the REQUIRED pack files RSPINST.EXE SAMPLE.RSP. o Files from diskette 2 UNPACK*.EXE ΓòÉΓòÉΓòÉ 23.10.1. Invocation ΓòÉΓòÉΓòÉ GETOSCID is invoked from the command line. ΓòÉΓòÉΓòÉ 23.10.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates GETOSCID syntax: ΓöîΓöÇΓöÇΓöÇ GETOSCID ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\GETOSCIDΓöÇΓöÇsource_pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇtarget_pathΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ GETOSCID is located in the <path>\IMG\LCU directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.10.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the GETOSCID parameters: source_path The path where the OS/2 2.x product images have been placed. If you used the recommended directory structure and OS/2 2.0, this path is <path>\IMG\OS2V20. This parameter is required. target_path The path to the subdirectory where the files should be placed. This path must be accessible to the client through SRVIFS. With the recommended directory structure and OS/2 2.0, this path is <path>\EXE\V200. This parameter is optional and defaults to the current directory. If this parameter is specified and the directory does not exist, GETOSCID attempts to create it. ΓòÉΓòÉΓòÉ 23.10.4. Example ΓòÉΓòÉΓòÉ GETOSCID Example D:\CID\IMG\LCU\GETOSCID D:\CID\IMG\OS2V20 D:\CID\EXE\V200 ΓòÉΓòÉΓòÉ 23.11. GETREXX ΓòÉΓòÉΓòÉ The GETREXX command is used to get a copy of the required OS/2 2.x REXX files. GETREXX also unpacks OSO001.MSG, and, for the versions of OS/2 that use it, INSCFG32.DLL. ΓòÉΓòÉΓòÉ 23.11.1. Invocation ΓòÉΓòÉΓòÉ GETREXX is invoked from the command line. ΓòÉΓòÉΓòÉ 23.11.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates GETREXX syntax: ΓöîΓöÇΓöÇΓöÇ GETREXX ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\GETREXXΓöÇΓöÇsource_pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇtarget_pathΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ GETREXX is located in the <path>\IMG\LCU directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.11.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the GETREXX parameters: source_path The path where the OS/2 2.x product images have been placed. If you used the recommended directory structure and OS/2 2.0, this path is <path>\IMG\OS2V20. This parameter is required. target_path The path to the subdirectory where the REXX files should be placed. This directory must be accessible to the client through SRVIFS. With the recommended directory structure and OS/2 2.0, this path is <path>\DLL\V200. This parameter is optional and defaults to the current directory. ΓòÉΓòÉΓòÉ 23.11.4. Example ΓòÉΓòÉΓòÉ GETREXX Example D:\CID\IMG\LCU\GETREXX D:\CID\IMG\OS2V20 D:\CID\DLL\V200 ΓòÉΓòÉΓòÉ 23.12. IFSDEL ΓòÉΓòÉΓòÉ The IFSDEL program is installed on the workstation by the THINSRV and THINIFS commands. The IFSDEL program removes the SRVIFS function from the workstation. When IFSDEL is run on the client, it removes the SRVIFS requester files and the SRVIFS statements from the CONFIG.SYS file. When IFSDEL is run on the code server, it removes the SRVIFS server files and the SRVIFS statements from STARTUP.CMD. IFSDEL is supported in both OS/2 1.3 and OS/2 2.x environments. ΓòÉΓòÉΓòÉ 23.12.1. Invocation ΓòÉΓòÉΓòÉ On the client, IFSDEL is invoked from the command line or within a LAN CID Utility command file. On the code server, IFSDEL is invoked from the command line. Note: When IFSDEL is being run on the remote redirected drive (logical drive), XI1.MSG is not deleted as it is being used by SRVIFS. ΓòÉΓòÉΓòÉ 23.12.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates IFSDEL syntax: ΓöîΓöÇΓöÇΓöÇ IFSDEL ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé Γöé Γöé >>ΓöÇΓöÇpath\IFSDELΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓö┤ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/T:pathΓöÇΓöÿ ΓööΓöÇ/TU:pathΓöÇΓöÿ ΓööΓöÇ/SDΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ IFSDEL is located in the <path>\IMG\SRVIFS directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.12.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the IFSDEL parameters: /T:path The directory where the SRVIFS files are to be deleted. This parameter is optional and, if omitted, the value of the target is the root directory of the currently booted drive. If the target is not valid or does not contain SRVIFS files, IFSDEL continues running. However, a return code indicating unsuccessful completion is returned. If you are running IFSDEL on the client, the path should match the path used in the /T: parameter for THINIFS. If you are running IFSDEL on the SRVIFS server, the path should match the path used in the /T: parameter for THINSRV. /TU:path The path to the file from which SRVIFS statements are to be deleted: o If you are running IFSDEL on the client, this is the path to the CONFIG.SYS file. o If you are running IFSDEL on the SRVIFS server, this is the path to STARTUP.CMD. This parameter is optional, but if you omit it, the value of the /T parameter is used. If you enter an incorrect value for this parameter, the SRVIFS statements are not removed from the CONFIG.SYS file on the client or STARTUP.CMD on the code server. A return code indicating unsuccessful completion is returned. /SD The indicator to remove the SRVIFS program and any of the configuration files that are indicated by the statements in the STARTUP.CMD file. Authorization list files that are referenced in those configuration (.INI) files are also deleted. This parameter is used only when invoking IFSDEL on the code server. This parameter is optional. ΓòÉΓòÉΓòÉ 23.12.4. Messages ΓòÉΓòÉΓòÉ IFSDEL does not support command-line messages or logging. All returned information is provided by return codes from the program. ΓòÉΓòÉΓòÉ 23.12.5. Example ΓòÉΓòÉΓòÉ IFSDEL Example D:\CID\IMG\SRVIFS\IFSDEL /T:C:\SRVIFSRQ /TU:C: ΓòÉΓòÉΓòÉ 23.13. SEDISK ΓòÉΓòÉΓòÉ The SEDISK command creates the boot diskettes that are prepared for an installation on the client. ΓòÉΓòÉΓòÉ 23.13.1. Invocation ΓòÉΓòÉΓòÉ SEDISK is invoked from the command line. ΓòÉΓòÉΓòÉ 23.13.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates SEDISK syntax: ΓöîΓöÇΓöÇΓöÇ SEDISK ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\SEDISKΓöÇΓöÇ/S:sourceΓöÇΓöÇ/T:target_driveΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ With the recommended directory structure and OS/2 2.0, this path is <path>\EXE\V200. ΓòÉΓòÉΓòÉ 23.13.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the SEDISK parameters: /S:source The fully qualified path to the OS/2 2.x product images. If you used the recommended directory structure and OS/2 2.0, this path is <path>\IMG\OS2V20. This parameter is required. /T:target_drive The drive indicator of the diskette drive where the boot diskettes is created. This parameter can be in any of the following formats: A, A:, or A:\. This drive is usually A:. This parameter is required. ΓòÉΓòÉΓòÉ 23.13.4. Example ΓòÉΓòÉΓòÉ Example D:\CID\EXE\V200\SEDISK /S:D:\CID\IMG\OS2V20 /T:A: ΓòÉΓòÉΓòÉ 23.14. SEIMAGE ΓòÉΓòÉΓòÉ The SEIMAGE program loads the OS/2 2.x product images from diskettes to a directory on the code server. ΓòÉΓòÉΓòÉ 23.14.1. Invocation ΓòÉΓòÉΓòÉ SEIMAGE is invoked from the command line. ΓòÉΓòÉΓòÉ 23.14.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates SEIMAGE syntax: ΓöîΓöÇΓöÇΓöÇ SEIMAGE ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\SEIMAGEΓöÇΓöÇ/S:source_driveΓöÇΓöÇ/T:target_pathΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ With the recommended directory structure and OS/2 2.0, SEIMAGE is located in the <path>\EXE\V200 directory. ΓòÉΓòÉΓòÉ 23.14.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the SEIMAGE parameters: /S:source_drive The drive indicator of the diskette drive from which the product images are to be loaded. This parameter can be in any of the following formats: A, A:, or A:\. This drive is usually A:. This parameter is required. /T:target_path The fully qualified path to the directory to which the product images are to be loaded. If you used the recommended directory structure and OS/2 2.0, this path is <path>\IMG\OS2V20. This parameter is required. ΓòÉΓòÉΓòÉ 23.14.4. Example ΓòÉΓòÉΓòÉ SEIMAGE Example D:\CID\EXE\V200\SEIMAGE /S:A: /T:D:\CID\IMG\OS2V20 ΓòÉΓòÉΓòÉ 23.15. SEINST ΓòÉΓòÉΓòÉ The SEINST program installs the OS/2 2.x program on the client workstation. SEINST is normally run under a maintenance system created by SEMAINT or boot diskettes created by SEDISK. See SEMAINT for more information on the maintenance system. ΓòÉΓòÉΓòÉ 23.15.1. Invocation ΓòÉΓòÉΓòÉ SEINST is invoked from within the LAN CID Utility command file. SEINST runs RSPINST.EXE, which reads the response file provided and performs the installation. If SEINST is run under a maintenance system created by SEMAINT, SEINST also cleans up the directory from which the system was booted. ΓòÉΓòÉΓòÉ 23.15.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates SEINST syntax when booted from fixed disk: ΓöîΓöÇΓöÇΓöÇ SEINST ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\SEINSTΓöÇΓöÇ/B:driveΓöÇΓöÇ/T:pathΓöÇΓöÇ/R:path\filename.extΓöÇΓöÇ/S:pathΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé Γöé Γöé >ΓöÇΓöÇ/L1:path\filename.extΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The following diagram illustrates SEINST syntax when booted from diskette: ΓöîΓöÇΓöÇΓöÇ SEINST ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\SEINSTΓöÇΓöÇ/B:driveΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇ/R:path\filename.extΓöÇΓöÇ/S:path- ΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/T:path- ' Γöé Γöé Γöé Γöé >ΓöÇΓöÇ/L1:path\filename.extΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ With the recommended directory structure and OS/2 2.0, this path is <path>\EXE\V200. ΓòÉΓòÉΓòÉ 23.15.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the SEINST parameters: /B:drive The drive from which the system boots after installation. This parameter can be in any of the following formats: C, C:, or C:\, where C is a local drive. This parameter is required. /T:path The fully qualified path to the target directory from which the system was booted. If the system was booted from a maintenance system on the fixed disk, this path matches the /T: parameter passed on the previous invocation of the SEMAINT program. This parameter is required if booted from the fixed disk but optional if booted from diskette. If this parameter is specified when booted from diskette, no parameter validation is done on its value. Warning: Because SEINST deletes all files as it cleans up this subdirectory, back up the files you want to save. /R:path\filename.ext The fully qualified file name of the response file supported for SEINST. Warning: The SEINST program from OS/2 2.11 Service Pak XR06200 or earlier does not support long file names for this parameter. Long directory names are supported. This parameter is required. /S:path The fully qualified path to the OS/2 2.x product images. The path can be either a local fixed disk or a redirected drive on the code server. If you used the recommended directory structure and OS/2 2.0, this path is <path>\IMG\OS2V20. This parameter is required. /L1:path\filename.ext The fully qualified path to the file into which installation log information is to be placed. This parameter is required. ΓòÉΓòÉΓòÉ 23.15.4. Messages ΓòÉΓòÉΓòÉ When RSPINST encounters an error, it returns a non-zero return code to SEINST. SEINST displays this return code. Following is an explanation of the known RSPINST return codes: 710 MS-Windows system missing or invalid. 711 Cannot format Windows partition if you support it. 901 Partition Size Error. 905 FDISK unsuccessful. 906 Less than xMB primary partition exists. 907 Primary partition exists, greater than xMB available. 908 No primary partition exists, less than xMB available. 909 Greater than xMB primary partition exists. 911 Could not create a file. 914 System Installation detected an internal error. 915 System Installation failed to initialize. 916 System Installation failed to start the session. 920 Load Module Error. 932 Copy File Error. 933 Delete File Error. 934 Device Configuration Error while determining system configuration. 935 Close File Error. 936 Make Directory Error. 937 Rename File Error. 938 Open File Error. 939 Read File Error. 940 Write File Error. 941 Format Error. 942 Display Panel Error. 943 Installation Error. Can't install OS/2 2.1 Special Edition over OS/2 2.1 944 Display Driver Install Error. 945 Format Error. The target drive is not formatted and formatpartition option was not selected. 946 Video System Error. 947 System Install Internal Error 949 System File Transfer Error. 950 Unpack File Not Found 951 Unpack Partial Copy. 952 Unpack Ctrl+Break Error. 953 Unpack Critical Error. 954 Run Program Error. 955 Get/Set file Attributes Error. 957 Memory Allocation Error. 1000-1020 System Installation detected an internal error(00-20). 1021 Invalid Path. 1022 Invalid Filename. 1023 Number Out of Range. 1024 System Installation detected an internal error(24). 1025 No Data Entry. 1026 System Installation detected an internal error(26). 1060 Invalid Base Product Level, incorrect version. 1061 Invalid Base Product Level, incorrect type. 1062 Invalid Base Product Level, missing syslevel file. 1063 Memory Allocation Error 1064 CheckSum Failure, unable to OPEN or READ specified file. 1065 CheckSum Failure, unknown CheckSum return code. ΓòÉΓòÉΓòÉ 23.15.5. Example ΓòÉΓòÉΓòÉ SEINST Example X:\EXE\V200\SEINST /B:C: /T:C:\SERVICE /R:X:\RSP\OS2V20 \DEFAULT.RSP /S:X:\IMG\OS2V20 /L1:X:\LOG\OS2V20\BARB.LOG ΓòÉΓòÉΓòÉ 23.16. SEMAINT ΓòÉΓòÉΓòÉ The SEMAINT command installs a minimal version of the OS/2 2.x program on a workstation hard disk. This minimal OS/2, also known as a maintenance system, does not contain the Presentation Manager or Workplace Shell features of the OS/2 program. The OS/2 2.x install program (SEINST) and the Service Pak install program (FSERVICE) runs under the maintenance system created by SEMAINT or on boot diskettes created by SEDISK. ΓòÉΓòÉΓòÉ 23.16.1. Invocation ΓòÉΓòÉΓòÉ SEMAINT is invoked from the command line or from within a LAN CID Utility command file. ΓòÉΓòÉΓòÉ 23.16.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates SEMAINT syntax: ΓöîΓöÇΓöÇΓöÇ SEMAINT ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\SEMAINTΓöÇΓöÇ/S:pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇ/T:targetΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/S2:service_pak_pathΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇ/B:boot_driveΓöÇΓöÇ/L1:path\filename.extΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ With the recommended directory structure and OS/2 2.0, this path is <path>\EXE\V200. ΓòÉΓòÉΓòÉ 23.16.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the SEMAINT parameters: /S:path The fully qualified path to the OS/2 2.x product images. The path can be either a local fixed disk or a redirected drive on the code server. If you used the recommended directory structure and OS/2 2.0, this path is <path>\IMG\OS2V20. This parameter is required. /S2:service_pak_path The fully qualified path to the OS/2 2.x Service Pak images. The path can be either a local fixed disk or a redirected drive on the code server. This parameter is used to apply Service Pak fixes to the maintenance system being created. If you used the recommended directory structure and OS/2 2.0, this path is <path>\CSD\OS2V20\CSD01 This parameter is optional, but it should be supplied when an OS/2 2.x Service Pak has been applied to the target workstation prior to running SEMAINT. The /S2: parameter in this case should point to the same version of the Service Pak as was previously applied to the workstation. This is especially important when applying a Service Pak other than an OS/2 2.x Service Pak, such as a LAN Server Service Pak, when running under the maintenance system created by SEMAINT. If the /S2: parameter is not supplied in this case, you run the risk of the OS2KRNL and OS2LDR being at the wrong level when the system is returned to its normal environment. Note: This parameter is available only with SEMAINT from OS/2 2.1 and higher. /T:target The fully qualified path to the maintenance directory to be created. This path must be on a local drive. If this path is on a different drive than the one indicated on the /B: parameter, and if this path is on an drive running the HPFS file system, the drive indicated on the /B: parameter must also be running the HPFS file system. This path is also passed on the /T: parameter on subsequent invocations of SEINST.EXE, FSERVICE.EXE, and MPTS.EXE (with the /E:PREP parameter) in a LAN CID Utility command file. This parameter is required. /B:drive The drive from which the system boots after SEMAINT completes. This parameter can be in any of the following formats: C, C:, or C:\, where C is a local drive. This parameter is required. /L1:path\filename.ext The fully qualified path to the file into which installation log information is to be placed. This parameter is required. ΓòÉΓòÉΓòÉ 23.16.4. Examples ΓòÉΓòÉΓòÉ SEMAINT Examples X:\EXE\V200\SEMAINT /S:X:\IMG\OS2V20 /T:C:\SERVICE /B:D: /L1:X:\LOG\CSD\OS2V20\WS1.LOG X:\EXE\V200\SEMAINT /S:X:\IMG\OS2V20 /T:C:\SERVICE /B:C: /S2:X:\CSD\OS2V20\CSD01 /L1:X:\LOG\CSD\OS2V20\WS1.LOG ΓòÉΓòÉΓòÉ 23.17. SERVICE ΓòÉΓòÉΓòÉ The SERVICE command is used to start a SRVIFS server. It is also used to get status, update the authorization list file, and stop a SRVIFS server. ΓòÉΓòÉΓòÉ 23.17.1. Invocation ΓòÉΓòÉΓòÉ SERVICE is run from STARTUP.CMD on the code server; it can also be invoked from the command line. ΓòÉΓòÉΓòÉ 23.17.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates SERVICE syntax for starting a SRVIFS server: ΓöîΓöÇΓöÇΓöÇ SERVICE (START) ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\SERVICEΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/INI=inifileΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The following diagram illustrates SERVICE syntax for getting status, updating the authorization list file, or stopping the SRVIFS server: ΓöîΓöÇΓöÇΓöÇ SERVICE (STATUS, UPDATE, STOP) ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\SERVICEΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇ/StatusΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/INI=inifileΓöÇΓöÿ Γö£ΓöÇ/AuthlistΓöÇΓöñ Γöé Γöé Γö£ΓöÇ/QuitΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé ΓööΓöÇ/ForceΓöÇΓöÇΓöÇΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ SERVICE is located in the <path>\SERVER and <path>\IMG\SRVIFS directories if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.17.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the SERVICE parameters: /INI=inifile inifile specifies the name of the SRVIFS configuration .INI file. The .INI file must exist in the current subdirectory or a subdirectory specified in the DPATH= environment variable. See Sample SERVICE.INI SRVIFS Configuration File for more information on the .INI file. This parameter is optional and defaults to SERVICE.INI. /Status Queries the status of a running SRVIFS server. The abbreviated form of this parameter is /S or /ST. This parameter is optional. /Authlist Updates the authorization list file of a running SRVIFS server. The abbreviated form of this parameter is /A. This parameter is optional. /Quit Stops the running SRVIFS server from taking new requests and requires it to shut down when the last client disconnects. The abbreviated form of this parameter is /QU. This parameter is optional. /Force Forces the running SRVIFS server to make an immediate stop. The abbreviated form of this parameter is /F. This parameter is optional. Note: 1. When starting the SRVIFS server, none of the optional parameters except /INI= can be on the command line. 2. To get status, update, or stop the SRVIFS server, specify only one of the optional parameters each time you run SERVICE. Run the command once for each parameter. ΓòÉΓòÉΓòÉ 23.17.4. Messages ΓòÉΓòÉΓòÉ When a SRVIFS program encounters a NetBIOS error for which there is no specific error message defined, it displays one of the following messages where <return code> is the NetBIOS return code: o XI10073: A NetBIOS error occurred with rc = <return code> (in decimal). o XI10108: A NetBIOS reset call failed on adapter <adapter> with rc = <return code>. o XI10110: NetBIOS could not add a name on adapter <adapter>. The rc = <return code>. The NetBIOS return codes are defined as follows: 0 Command Successful 1 Illegal Buffer Length 3 Invalid Command 5 Command Time Out 6 Message Incomplete 7 Data Not Received 8 Illegal Local Session 9 No Resources Available 10 Session Closed 11 Command Cancelled 13 Duplicate Name 14 Name Table Full 15 Command Complete Deregistered 17 Session Table Full 18 Session Open Rejected 19 Illegal Name Number 20 Remote Name Not Found 21 Local Name Not Found 22 Name In Use 23 Name Deleted 24 Session Ended Abnormally 25 Name Conflict 33 Interface Busy 34 Max Commands Exceeded 35 Invalid Adapter 36 Command Already Completed 37 Command Invalid To Cancel 48 Name Defined By Others 52 Environment Not Defined 53 No Operating System Resources 54 Max Appl Exceeded 55 No SAP Available 56 Inadequate Resources 57 Invalid NCB Address 58 Reset Invalid 59 Invalid Device Driver ID 60 Segment Lock Unsuccessful 63 Device Driver Open Error 64 Operating System Error Detected 79 Perm Ring Status 246 Unexpected Ccb Error 248 Adapter Open Error 249 Adapter Handler Error 250 Adapter Check 251 Code Not Operational 252 Open Failures 253 Unexpected Close 255 Command In Process ΓòÉΓòÉΓòÉ 23.17.5. Examples ΓòÉΓòÉΓòÉ SERVICE Examples If you need to start multiple SRVIFS servers on the same machine, you can use the following examples: D:\SERVER\SERVICE /ini=server1 D:\SERVER\SERVICE /ini=server2 Use the following examples for the other parameters: D:\SERVER\SERVICE /ST /ini=server1 D:\SERVER\SERVICE /A /ini=server1 D:\SERVER\SERVICE /ini=server1 /QU D:\SERVER\SERVICE /ini=server1 /F ΓòÉΓòÉΓòÉ 23.17.6. Sample Status Display ΓòÉΓòÉΓòÉ Status Display SERVICE Status Report Version 1.30 Server Name = IFSRV Group Name = Yes Adapter = 0 Client Workers = 4 Maximum Clients = 3 Maximum Files = 100 Open Files = 0 Authorizations = No Shutdown Requested = No Alias Name ReadWrite PerClient Path Default Yes No C:\CMLIB NEWS No No D:\NEWS TOOLS No No E:\TOOLS STATUS Yes Yes E:\CLIENT\INVENTORY Active Clients on Adapter 0 = 1 Client Name Session Adapter Address OpenFiles Current Dir SRV99931 2 1 5A CCFE9 0 0 \ Alias Drive NEWS Z: ΓòÉΓòÉΓòÉ 23.18. SRVATTCH ΓòÉΓòÉΓòÉ The SRVATTCH command is used to attach the client to the code server. ΓòÉΓòÉΓòÉ 23.18.1. Invocation ΓòÉΓòÉΓòÉ SRVATTCH can be issued from the command line, from a command file, or from a CALL= statement in the CONFIG.SYS file. If invoked from a REXX command file, SRVATTCH must be enclosed in single quotation marks (' ... '). ΓòÉΓòÉΓòÉ 23.18.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates SRVATTCH syntax: ΓöîΓöÇΓöÇΓöÇ SRVATTCH ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇSRVATTCHΓöÇΓöÇΓö¼ΓöÇdrive_letterΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓö¼ΓöÇserver_nameΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ*ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ Γöé Γö£ΓöÇ\\server\aliasΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé Γöé Γöé ΓööΓöÇ*PΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÿ Γöé Γöé Γöé Γöé ΓööΓöÇ"prompt string"ΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇ/DeleteΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 23.18.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the SRVATTCH parameters: drive_letter The drive letter that SRVATTCH should attach to or detach from the SRVIFS server. * Indicates that the client should be attached to the next available drive. The drive search starts at Z: and works backward. A string is printed to STDOUT in the following format: Drive F: Connected successfully server_name This value specifies the name of the SRVIFS server to which the client should be attached. The client is attached to the default path of the SRVIFS server named. The default path is defined with the PATH=default_path keyword=value pair in the SRVIFS server .INI file. \\server_name\alias This value specifies the SRVIFS server and alias to which the client should be attached. *P Indicates that SRVATTCH should prompt for the SRVIFS server name to attach. When this parameter is specified without a prompt string, SRVATTCH displays a default prompt, Enter Server Name to Connect to. You can supply a customized string to replace the default prompt string by supplying the desired prompt after the *P parameter on the command line. If the prompt string contains blanks, the entire string must be surrounded by quote marks. /Delete The indicator to delete the attached drive specified in the drive parameter. ΓòÉΓòÉΓòÉ 23.18.4. Messages ΓòÉΓòÉΓòÉ The SRVATTCH program can display messages that contain a NetBIOS return code as part of the message. See Messages for more information on the meaning of the NetBIOS return codes. ΓòÉΓòÉΓòÉ 23.18.5. Examples ΓòÉΓòÉΓòÉ SRVATTCH Examples The following example deletes the drive specified: SRVATTCH X: /d The following example attaches to a particular drive for a specified ServerName\Alias: SRVATTCH X: \\SERVER1\ALIAS1 The following example attaches to the next available drive for the specified ServerName: SRVATTCH * SERVER1 The following example prompts the user for the code server to attach to the specified drive and replaces the default prompt string: SRVATTCH Y: *P "Enter Your Desired Server Name:" ΓòÉΓòÉΓòÉ 23.19. SRVIFSC.IFS ΓòÉΓòÉΓòÉ The IFS=path\SRVIFSC.IFS statement in the CONFIG.SYS file initiates the SRVIFS installable file system function, but does not actually attach to a code server or create a logical drive. The SRVATTCH command handles those functions. For more information on the SRVATTCH command, refer to SRVATTCH. ΓòÉΓòÉΓòÉ 23.19.1. Invocation ΓòÉΓòÉΓòÉ IFS=SRVIFSC.IFS is loaded from the CONFIG.SYS file during system startup. ΓòÉΓòÉΓòÉ 23.19.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the IFS=SRVIFSC.IFS syntax: ΓöîΓöÇΓöÇΓöÇ IFS=SRVIFSC.IFS ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇIFS=drive:\path\SRVIFSC.IFSΓöÇΓöÇΓö¼ΓöÇclient_nameΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé Γö£ΓöÇ*ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé ΓööΓöÇΓö¼ΓöÇ*PΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÿ Γöé Γöé ΓööΓöÇ*IΓöÇΓöÿ ΓööΓöÇ"customized prompt"ΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/A:adapter_numberΓöÇΓöÿ ΓööΓöÇ/S:netbios_sessionsΓöÇΓöÿ ΓööΓöÇ/TΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 23.19.3. Parameters ΓòÉΓòÉΓòÉ client_name The 1- to 15-byte alphanumeric NetBIOS client name that SRVIFS should use for the workstation. * Indicates that SRVIFS should randomly select the client name. *P Indicates that SRVIFS should prompt for the client name. If the "customized prompt" is provided, SRVIFS displays the customized prompt supplied instead of the default prompt. *I Indicates that SRVIFS should obtain the client name from the IBMLAN.INI file. If the IBMLAN.INI file is not found, SRVIFS prompts for the requester name. If the "customized prompt" is provided, SRVIFS displays the customized prompt supplied instead of the default prompt. /A:adapter_number The adapter number that SRVIFS should use. The supported values are 0 and 1. /S:netbios_sessions The number of NetBIOS sessions that SRVIFS requires. The supported values are 2 through 9. This parameter corresponds to the /NS: parameter on the THINIFS command. /T Indicates that the timeout value should be 30 seconds instead of 15 seconds. This parameter corresponds to the /W parameter on the THINIFS command. Note: For a more detailed description of these parameters, refer to the corresponding THINIFS parameter definitions in THINIFS. ΓòÉΓòÉΓòÉ 23.19.4. Examples ΓòÉΓòÉΓòÉ IFS=SRVIFSC.IFS Examples IFS=C:\SRVIFSRQ\SRVIFSC.IFS BJA99 IFS=C:\SRVIFSRQ\SRVIFSC.IFS *P /A:1 IFS=C:\SRVIFSRQ\SRVIFSC.IFS *I "No IBMLAN.INI file. Enter client name:" ΓòÉΓòÉΓòÉ 23.20. THINIFS ΓòÉΓòÉΓòÉ The THINIFS command is used to install files required for a SRVIFS requester on boot diskettes or on a client workstation. LAPS must be installed and configured for NetBIOS in the CONFIG.SYS file on the target drive before you run THINIFS. ΓòÉΓòÉΓòÉ 23.20.1. Invocation ΓòÉΓòÉΓòÉ THINIFS is invoked from the command line or from within the LAN CID Utility command file. ΓòÉΓòÉΓòÉ 23.20.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates THINIFS syntax: ΓöîΓöÇΓöÇΓöÇ THINIFS ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\THINIFSΓöÇΓöÇ/S:pathΓöÇΓöÇ/T:pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇ/D:driveΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/TU:pathΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇ/REQ:xxxxxxxxΓöÇΓöÇ/SRV:xxxxxxxxΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/NS:nΓöÇΓöÿ ΓööΓöÇ/A:nΓöÇΓöÿ ΓööΓöÇ/WΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/L1:path\filename.extΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ THINIFS is located in the <path>\IMG\SRVIFS directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.20.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the THINIFS parameters: /S:path The source path to the SRVIFS files on the code server. This parameter is required. /T:path The target of the THINIFS installation. If you are creating boot diskettes for the client, this parameter is the drive location where the boot diskettes are located. If you specify a directory, THINIFS attempts to create the target (subdirectory) if it does not exist. THINIFS also supports long directory names. This parameter is required. If you used the recommended directory structure, this path is <path>\IMG\SRVIFS. /TU:path The path to the CONFIG.SYS file that is to be updated with the appropriate SRVIFS statements for the client. This parameter is optional. If you omit it, the value of the /T parameter is used. If you specify a directory, THINIFS ends if the CONFIG.SYS file does not exist in the location you specified. /D:drive One alphabetic character for the redirected drive letter on the SRVIFS SRVATTCH statement added to the CONFIG.SYS file on the client. The value for x must be a single character but can be followed by a colon. This parameter is required. /REQ:xxxxxxxx The NetBIOS name of this client. The name is used in the SRVIFS IFS= statement that is included in the CONFIG.SYS file. The supported values are: o A name 1 through 15 bytes long. This value specifies the alphanumeric NetBIOS client name that must be unique on your entire logical LAN network. If the NetBIOS client name is entered onto the diskettes, the log and response files that THINIFS can access are for that client name; these diskettes can be used only for the named client. Note: SRVIFS does not follow the NetBIOS naming convention. Therefore, the SRVIFS requester name should be alphanumeric even though it is a NetBIOS name. o * This value specifies to allow any client name. When THINIFS copies the asterisk (*) to the client CONFIG.SYS file on the boot diskettes, any client can use the boot diskettes. A six byte client name is determined during the connection process. o *P This value specifies to prompt for the client name. Specifying *P for the client name prompts the user at the workstation for the client name during installation. Note: If you want the user to have a customized prompt for the requester name with the *P option, modify the IFS=A:\SRVIFSC.IFS *P statement generated by THINIFS in the CONFIG.SYS file. Add the customized prompt in quotes following the *P parameter, as follows: IFS=A:\SRVIFSC.IFS *P "Customized Prompt" o *I This value specifies that SRVIFS should get the client name from the LAN requester IBMLAN.INI file. If this file cannot be found, the user is prompted for a client name. This parameter allows a single name to be used for both the SRVIFS client and the LAN requester. SRVIFS pads the NetBIOS name to 15 bytes with NULL characters (0x00), while LAN Requester pads with blanks (0x20). This difference in pad characters permits SRVIFS and the LAN Requester to be used with the same name at the same time. Because the use of the same name requires pad character differences, SRVIFS only uses a client name in the IBMLAN.INI file that is up to 14 bytes long. If the client name is more than 14 bytes long, SRVIFS prompts the user for a client name. To find the IBMLAN.INI file, SRVIFS searches the CONFIG.SYS file for the keyword NETWKSTA. When it finds the keyword, it looks for the path to the IBMLAN.INI file. Therefore, the CONFIG.SYS file should have the IFS=path\NETWKSTA.IFS /I:path statement before you can use the *I option. However, when the user is using boot diskettes, the NETWKSTA.IFS driver is not be on the boot diskettes. If you want a user of the boot diskettes to have the *I option, after you run THINIFS, add the following statement to the CONFIG.SYS file: REM IFS=path\NETWKSTA.IFS /I:path This statement is required so that SRVIFS can be loaded. If the user does not have the IBMLAN.INI file on the workstation where the boot diskettes are used, SRVIFS prompts for the client name when the system is booted. Note: If you want the user to have a customized prompt for the client name with the *I option, modify the IFS=A:\SRVIFSC.IFS *I statement generated by THINIFS. Add the customized prompt in quotes following the *I parameter, as follows: IFS=A:\SRVIFSC.IFS *I "Customized Prompt" This parameter is required. Warning: At this time, some programs, such as FSERVICE and SEINST, do not support long file names for the response files and log files. If you are using LAN CID Utility client names more than 8 bytes long and you are using the LAN CID Utility client name for the response file and log file names, it is important that you test your LAN CID Utility command file before using it in a production environment to determine if the install programs you are using support long file names. /SRV:xxxxxxxx The name of the code server that is set on the SRVIFS SRVATTCH statement that is added to the CONFIG.SYS file on the client. The supported values are: o 1- through 15-byte name of the SRVIFS server. This value specifies the name of the SRVIFS server to which the client should be attached. The client is attached to the default path of the SRVIFS server named. The default path is defined with the PATH=default_path keyword=value pair in the SRVIFS server .INI file. o \\server_name\alias The code server and alias name. This value must be in the form of two backslashes, followed by a maximum of 15 bytes, followed by one backslash, followed by a maximum of 8 bytes. o *P Indicates that you want the user to be prompted for the code server name during installation. This parameter is required. /NS:n The number of NetBIOS sessions that SRVIFS requires. One NetBIOS session is required for each SRVIFS server that this client attaches to concurrently. The value supplied is used to set the /S: option on the SRVIFS IFS= statement that is added to the CONFIG.SYS file on the client. Supported values are 2 through 9. This parameter is optional and defaults to 5. /A:n The adapter for SRVIFS to use. The value supplied sets the /A: option of the SRVIFS IFS= statement that is added to the CONFIG.SYS file on the client. Supported values are 0 and 1. This parameter is optional and THINIFS does not select a value if the parameter is omitted. However, SRVIFS defaults to Adapter 0. /W The timeout value for the NetBIOS session. This parameter increases the timeout value from 15 seconds to 30 seconds in the IFS= statement. This increase is useful in cases where the LAN is bridged by slower line speeds, such as a LAN-to-LAN WAN or a remote bridge. This parameter indicates that the /T option should be included on the SRVIFS IFS= statement that is added to the CONFIG.SYS file on the client. This parameter is optional. If omitted, the /T option is not included on the SRVIFS IFS= statement added to the CONFIG.SYS file on the client. /L1:path\filename.ext The fully qualified file name of the log file. This parameter is optional. However, logging does not occur if this parameter is omitted or is not valid. The logging function is not performed until after the command-line arguments are obtained and the value for this parameter and the source parameter are validated. ΓòÉΓòÉΓòÉ 23.20.4. Examples ΓòÉΓòÉΓòÉ THINIFS Examples Following is an example of using THINIFS to create boot diskettes: D:\CID\IMG\SRVIFS\THINIFS /D:X /TU:A: /T:A: /S:D:\CID\IMG\SRVIFS /SRV:SERVER1 /REQ:*P Following is an example of using THINIFS to install the SRVIFS client on the fixed disk of the client workstation. The SRVIFS requester name is obtained from the IBMLAN.INI file: A:\SRVIFS\THINIFS /D:X /TU:C: /T:C:\SRVIFSRQ /S:A:\SRVIFS /SRV:\\SERVER\ALIAS /REQ:*I Following is another example of using THINIFS to install the SRVIFS client on the fixed disk of the client workstation. The SRVIFS requester name is hardcoded in this example: D:\IMG\SRVIFS\THINIFS /D:X /TU:C: /T:C:\SRVIFSRQ /S:D:\IMG\SRVIFS /SRV:SERVER1 /REQ:MANFRED ΓòÉΓòÉΓòÉ 23.20.5. CONFIG.SYS Updates ΓòÉΓòÉΓòÉ THINIFS updates the CONFIG.SYS file on the workstation located by the value provided on the /TU parameter. The following statements are modified in or added to the CONFIG.SYS file: THINIFS CONFIG.SYS Updates PATH=...<target_path>; DEVICE=<target_path>\SRVIFS.SYS IFS=<target_path>\SRVIFSC.IFS options CALL=<target_path>\SRVATTCH.EXE drive: server_name For the syntax of the IFS=SRVIFSC.IFS statement in the CONFIG.SYS file, refer to SRVIFSC.IFS. For the syntax of the CALL=SRVATTCH statement in the CONFIG.SYS file, refer to SRVATTCH. ΓòÉΓòÉΓòÉ 23.20.6. Multiple Invocations of THINIFS ΓòÉΓòÉΓòÉ Multiple invocations of THINIFS modify the CONFIG.SYS file cumulatively. The first invocation adds the client name and the server name to the CONFIG.SYS file. The second invocation replaces the first client name with the second client name and adds the second server name. ΓòÉΓòÉΓòÉ 23.20.7. First Invocation ΓòÉΓòÉΓòÉ Following is an example of the command for the first invocation of THINIFS: a:\srvifs\thinifs /s:a:\ifs /t:c:\srvifsrq /tu:c: /srv:\\server1\alias1 /req:ziggy /d:x The following lines show how the CONFIG.SYS file changes: DEVICE=C:\SRVIFSRQ\SRVIFS.SYS IFS=C:\SRVIFSRQ\SRVIFS.SYS ZIGGY CALL=C:\SRVIFSRQ\SRVATTTCH.EXE X: \\SERVER1\ALIAS1 ΓòÉΓòÉΓòÉ 23.20.8. Second Invocation ΓòÉΓòÉΓòÉ Following is an example of the command for the second invocation of THINIFS: a:\srvifs\thinifs /s:a:\srvifs /t:c:\srvifsrq /tu:c: /srv:server2 /req:chilerm /d:y The following lines show the cumulative changes to the CONFIG.SYS file after both invocations: DEVICE=C:\SRVIFSRQ\SRVIFS.SYS IFS=C:\SRVIFSRQ\SRVIFS.SYS CHILERM CALL=C:\SRVIFSRQ\SRVATTTCH.EXE X: \\SERVER1\ALIAS1 CALL=C:\SRVIFSRQ\SRVATTTCH.EXE Y: SERVER2 ΓòÉΓòÉΓòÉ 23.21. THINLAPS ΓòÉΓòÉΓòÉ The THINLAPS program installs a subset of the LAN Adapter and Protocol Support, known as thin LAPS or thin LAN transport, onto the boot diskettes. A thin LAN transport consists of the MPTS files, including a valid PROTOCOL.INI file, required to establish a NetBIOS LAN connection for one network adapter. ΓòÉΓòÉΓòÉ 23.21.1. Requirements ΓòÉΓòÉΓòÉ For a SRVIFS client, the NetBIOS resources that must be available are: o One NetBIOS name o One NetBIOS session per SRVIFS server that is attached o Four NetBIOS commands. ΓòÉΓòÉΓòÉ 23.21.2. Restrictions ΓòÉΓòÉΓòÉ o THINLAPS supports only the configuration of one network adapter. o THINLAPS provides only NetBIOS support. o THINLAPS installs only in the root of the target drive. o THINLAPS works only with valid MAC NIF files. MPTS provides an applet called SNIFFLE that validates .NIF files. See the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide for more information on the SNIFFLE applet. ΓòÉΓòÉΓòÉ 23.21.3. Invocation ΓòÉΓòÉΓòÉ THINLAPS is invoked from the command line. ΓòÉΓòÉΓòÉ 23.21.4. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates THINLAPS syntax: ΓöîΓöÇΓöÇΓöÇ THINLAPS ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\THINLAPSΓöÇΓöÇsource_drive_and_path- -target_driveΓöÇΓöÇnif_nameΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/P:path\protocol.ini filenameΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ THINLAPS is located in the <path>\IMG\LAPS directory if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.21.5. Parameters ΓòÉΓòÉΓòÉ The following list describes the THINLAPS parameters: source_drive_and_path The drive and path where the MPTS product image resides. If you loaded MPTS images on the code server and used the recommended directory structure, this parameter is path>\IMG\LAPS. This parameter is required. target_drive The target drive for the thin LAN transport files. This parameter can be in either of the following formats: A: or A:\, where A is a diskette drive. This parameter is required. nif_name The name of the network information file (NIF) for the network adapter driver that you want to install on the target drive. You must specify the .NIF file name extension. For a partial list of the .NIF files available, see NIF Files. For more information on .NIF files, see the Multi-Protocol Transport Services - AnyNet for OS.2: Configuration Guide. This parameter is required. /P:path\protocol.ini filename The fully qualified file name of the specific PROTOCOL.INI file that you want to install on the target drive to replace the PROTOCOL.INI file created by THINLAPS. You can use your own file-naming scheme for this PROTOCOL.INI file, because THINLAPS copies it to PROTOCOL.INI on the target drive at installation time. This parameter is optional. If it is omitted, THINLAPS creates a PROTOCOL.INI in the root directory of the target drive. ΓòÉΓòÉΓòÉ 23.21.6. Examples ΓòÉΓòÉΓòÉ THINLAPS Examples Following is an example of using THINLAPS with a default PROTOCOL.INI file: D:\CID\IMG\LAPS\THINLAPS D:\CID\IMG\LAPS A: IBMTOK.NIF Following is an example of using THINLAPS with a specified PROTOCOL.INI file: D:\CID\IMG\LAPS\THINLAPS D:\CID\IMG\LAPS A: IBMNETA.NIF /P:D:\PROTOCOL.INI ΓòÉΓòÉΓòÉ 23.21.7. NIF Files ΓòÉΓòÉΓòÉ Following is a list of often used ┬╖NIF files: EL3IBMO2 3Com** EtherLink** III Family OS/2 ELNKII.NIF 3Com 3C503 EtherLink II Adapter ELNKMC.NIF 3Com 3C503 EtherLink/MC Adapter IBMENI.NIF IBM LAN Adapter for Ethernet IBMTOK.NIF IBM Token-Ring Adapter IBMTRBM.NET IBM Token-Ring Network Busmaster Server Adapter IBMTRDB.NIF IBM LANStreamer Adapter IBMXLN.NIF 3270 Adapter for 3174 Peer Communications MACETH.NIF IBM PS/2* Adapter for Ethernet Networks MACWDAT.NIF Standard Microsystems** EtherCard PLUS** Software-Configured Adapters MACWDMC.NIF Standard Microsystems EtherCard PLUS Micro Channel Adapters UBNEIPC.NIF Ungermann-Bass NIUpc** Adapters UBNEIPS.NIF Ungermann-Bass NIUps** Adapters For more information on .NIF files, see the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide. ΓòÉΓòÉΓòÉ 23.21.8. Using non-MPTS Supplied MAC Drivers ΓòÉΓòÉΓòÉ THINLAPS supports the installation and configuration of MAC drivers that did not ship with MPTS. This could include MAC drivers that are shipped by IBM after the release of MPTS or MAC drivers that are supplied by other manufacturers. If you want to use a MAC driver that did not ship with MPTS, you must do the following on the code server: o Copy the MAC driver and its associated files (except for the ┬╖MSG files) into the <path>\IBMCOM\MACS directory. o Copy the ┬╖MSG files into the <path>\IBMCOM directory. Where <path> is the target directory that was indicated when you ran the LAPSDISK utility to copy the MPTS disks to the code server. After the MAC driver files have been copied to the code server, you can use THINLAPS to configure LAPS on the boot diskettes for use with the adapter that the new MAC driver supports. To do this, run THINLAPS specifying the NIF file associated with the new MAC driver. ΓòÉΓòÉΓòÉ 23.21.9. CONFIG.SYS File Updates ΓòÉΓòÉΓòÉ THINLAPS adds the following statements to the end of the CONFIG.SYS file if it exists on the target drive: THINLAPS CONFIG.SYS Updates rem *** Start of ThinLAPS additions *** device = lanmsgdd.os2 device = protman.os2 device = netbeui.os2 device = netbios.os2 device = <associated .OS2 file name> run = netbind.exe run = lanmsgex.exe rem *** End of THINLAPS additions *** If the CONFIG.SYS file does not exist on the target drive, THINLAPS displays a warning message indicating that it is creating a new CONFIG.SYS file. This new CONFIG.SYS file consists only of the CONFIG.SYS file additions shown previously. ΓòÉΓòÉΓòÉ 23.21.10. PROTOCOL.INI Creation ΓòÉΓòÉΓòÉ Following is an example of a PROTOCOL.INI file created with THINLAPS: PROTOCOL.INI Example [protman] drivername = protman$ [netbeui_nif] drivername = netbeui$ bindings = mac ; If running on an ethernet network, remove the semicolon from ; the "ETHERAND_TYPE =" statement to change the protocol ; convention from IEEE 802.3 to DIX 2.0. ; ETHERAND_TYPE = "D" [mac] drivername = IBMTOK$ ; EARLYRELEASE ADAPTER = "PRIMARY" ; NETADDRESS = "" MAXTRANSMITS = 6 RECVBUFS = 2 RECVBUFSIZE = 256 XMITBUFS = 1 ; XMITBUFSIZE = ; INTERRUPT = PCMCIA ; RAM = 0x RINGSPEED = 4 ; RAMSIZE = ; MMIO = 0x The following list describes the keyword types in the PROTOCOL.INI example: o ADAPTER, MAXTRANSMITS, RECVBUFS, RECVBUFSIZE, XMITBUFS, RINGSPEED These are keywords with decimal values that have default values associated with them. o XMITBUFSIZE, INTERRUPT, RAMSIZE These are keywords with decimal values that do not default value associated with them. To activate one of these keywords, remove the semicolon in column one and place a valid value after the equal sign. For example, XMITBUFSIZE = 256. o PCMICA This is a keyword without a value that is defaulted to ON in the .NIF file. o EARLYRELEASE This is a keyword without a value that is defaulted to OFF in the .NIF file. To activate this keyword, remove the semicolon in column one. o NETADDRESS This is a keyword with a string value that does not have a default value associated with it. To activate this keyword, remove the semicolon in column one, and place the desired value within the double quotes. For example, NETADDRESS = "400000274715". o RAM, MMIO These are keywords with hexadecimal values that do not have default values associated with them. To activate one of these keywords, remove the semicolon in column one and place a valid hexadecimal value after the 0x. For example, RAM = 0xA00. Note: Keywords requiring values that do not have default values associated with them and keywords not requiring values that are defaulted to OFF are remarked out with a semicolon in column one in the PROTOCOL.INI file. ΓòÉΓòÉΓòÉ 23.21.11. User Modification of PROTOCOL.INI ΓòÉΓòÉΓòÉ The PROTOCOL.INI file created by THINLAPS is sufficient for most network environments. However, since the PROTOCOL.INI file may not be appropriate for your network environment, you may need to adjust some parameter values in the PROTOCOL.INI file that THINLAPS created. You can use an ASCII editor to view and change the PROTOCOL.INI file created on the target drive after running THINLAPS. Because THINLAPS supports non-IBM supplied MAC device drivers, all keywords within the MAC NIF files are defined in the resulting PROTOCOL.INI file. Following are guidelines for modifying the MAC section in the PROTOCOL.INI file: o To modify the value of a keyword without a semicolon in column one, edit the value in the same format that it appears in the file (decimal, hexadecimal, string, and so on). o To modify the value of a keyword with a semicolon in column one, remove the semicolon from column one, if there is: No "=" You are through. Nothing following the "=" Supply a decimal value. For example, 129. A 0x following the "=" Supply a hexadecimal value after the 0x. For example, 0xA00 Quotes following the "=" Supply an ASCII string inside the quotes. For example, "400000274715". Note: 1. All keywords from the NIF file occur in the PROTOCOL.INI file. 2. Keywords that have defaults are activated and have the default value provided. 3. Keywords requiring values that do not have default values associated with them are remarked out with a semicolon in column one . 4. Keywords that do not have values that are defaulted to ON are activated. 5. Keywords not requiring values that are defaulted to OFF in the .NIF file are remarked out with a semicolon in column one. 6. If you have any questions concerning the keywords or valid values for each of the keywords, you can use an ASCII editor to view the MAC NIF file, which describes each of the keywords and its valid values. ΓòÉΓòÉΓòÉ 23.22. THINSRV ΓòÉΓòÉΓòÉ The THINSRV command is used to install the SRVIFS server on the code server. LAPS must be installed and configured for NetBIOS in the CONFIG.SYS file on the target boot drive before you can run THINSRV. ΓòÉΓòÉΓòÉ 23.22.1. Invocation ΓòÉΓòÉΓòÉ THINSRV is invoked from the command line or from within a LAN CID Utility command file. ΓòÉΓòÉΓòÉ 23.22.2. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates THINSRV syntax: ΓöîΓöÇΓöÇΓöÇ THINSRV ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇpath\THINSRVΓöÇΓöÇ/S:pathΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇ/R:path\name.iniΓöÇΓöÇΓöÇΓöÇΓöÇ> Γöé Γöé ΓööΓöÇ/T:pathΓöÇΓöÿ ΓööΓöÇ/TU:pathΓöÇΓöÿ Γöé Γöé Γöé Γöé >ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇ/U:path\filenameΓöÇΓöÿ ΓööΓöÇ/L1:path\filenameΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The path is <path>\IMG\SRVIFS if you used the recommended directory structure. ΓòÉΓòÉΓòÉ 23.22.3. Parameters ΓòÉΓòÉΓòÉ The following list describes the THINSRV parameters: /S:path The source path to the SRVIFS files. The SRVIFS files are located in the SRVIFS.ZIP pack file in the \SRVIFS directory on MPTS diskette3 or in the <path>\IMG\SRVIFS directory on the code server if you used the recommended directory structure. This parameter is required. /T:path The target of the THINSRV installation. This parameter is optional. If you omit this parameter, the default is the currently booted drive. THINSRV attempts to create the target directory if it does not exist. /TU:path The source path to STARTUP.CMD that is to be updated with the SRVIFS server information. This parameter is optional. If you omit this parameter, the value of the /T parameter is used. THINSRV creates a STARTUP.CMD if the file does not exist in the location specified in the value established for the /TU parameter. /R:path\filename.ext The fully qualified file name of the response file supported for THINSRV. This response file is actually the .INI file to be used by the SRVIFS server. It is also known as the SRVIFS configuration (.INI) file. THINSRV validates the information in the response file and copies it to the target. THINSRV renames the extension of the file to .INI if necessary. See The SERVICE.INI SRVIFS Configuration File for more information on the .INI file. This parameter is required. /U:path\filename The fully qualified file name on the code server of the authorization list file for the SRVIFS server being installed. The authorization list file contains a list of clients that the SRVIFS server supports. The authorization list file specified on this parameter is copied to the target as indicated by the value of the Authlist= keyword in the .INI file provided on the /R: parameter. If the directory indicated on the Authlist= keyword in the .INI file does not exist, THINSRV attempts to create it. This parameter is optional. If you omit this parameter and set an Authlist= keyword in the .INI file, THINSRV attempts to locate an authorization list file on the code server corresponding to the filename indicated on the Authlist=path\filename statement. It locates the authorization list file in the same drive and directory as the .INI file. For example, if you indicated /R:X:\RSP\SRVIFS\SERVER1.INI on the THINSRV command and Authlist=C:\SRVIFS\AUTHLST1.LST in SERVER1.INI, THINSRV looks for the authorization list file AUTHLST1.LST in the X:\RSP\SRVIFS directory. If AUTHLST1.LST is found in the X:\RSP\SRVIFS directory, THINSRV copies it to the C:\SRVIFS directory. THINSRV ends with an error if it cannot locate the authorization list file in this way. See Keyword=Value Descriptions for the SRVIFS Configuration File for more information on constructing an authorization file. /L1:path\filename The fully qualified file name of the log file. This parameter is optional. However, if this parameter is omitted or an incorrect value is given, THINSRV does not log information until after it obtains the command-line arguments and validates the values for /L1 and /S. ΓòÉΓòÉΓòÉ 23.22.4. .INI File Validation ΓòÉΓòÉΓòÉ The /R parameter specifies the value of the THINSRV response file. The THINSRV response file is actually the .INI file that is used to configure the SRVIFS server that is being installed. The server configuration file (.INI file) is validated by THINSRV, using the same acceptance rules implemented by the SRVIFS SERVICE.EXE program. The following restrictions apply: o No blank lines are allowed in the .INI file. o The CID response file keyword INCLUDE is not supported. o The CID response file keyword LIST is not supported. o The CID response file keyword USER EXIT is not supported. o Each keyword=value statement must be contained on one line. THINSRV ends if you provide values that are not valid or not supported, but it completes the validation and supplies information on all errors discovered. THINSRV restricts the validation of the path statement and paths included in the alias statement, which is a parameter supported by SRVIFS. THINSRV ensures that the value of the path statement and the value of the path in the alias statement exist. Dynamic Authlist is not supported, and THINSRV ends if it is supplied. Required parameters are also determined as prescribed in the SRVIFS documentation. THINSRV ends if the required SRVIFS configuration parameters are missing from the .INI file. THINSRV adds a new CALL=SERVICE.EXE (ini=xxx statement) to STARTUP.CMD, where xxx is the name of the .INI file. ΓòÉΓòÉΓòÉ 23.22.5. Multiple SRVIFS Servers ΓòÉΓòÉΓòÉ To install multiple SRVIFS servers on the code server, run THINSRV with a different SRVIFS configuration file for each server. Each time THINSRV is invoked, it adds one new CALL=SERVICE statement to STARTUP.CMD. Each server should have a different SRVIFS configuration file (servername.INI file). See NetBIOS Resources for Multiple SRVIFS Servers on the Same Workstation for more information. ΓòÉΓòÉΓòÉ 23.22.6. Example ΓòÉΓòÉΓòÉ THINSRV Example D:\CID\IMG\SRVIFS\THINSRV /R:D:\SERVER\SERVER1.INI /U:D:\SERVER\SERVER1.LST /S:D:\CID\IMG\SRVIFS /T:D:\SERVER /TU:C:\ ΓòÉΓòÉΓòÉ 24. REXX Procedures for System Administrators ΓòÉΓòÉΓòÉ This appendix contains the externalized REXX procedures that the system administrator can use in the installation sequences documented in Installation Scenarios. This appendix documents the following REXX procedures: o BootDriveIsDiskette o BootDriveIsFixedDisk o CheckBoot o GetOS2Version o RebootAndGotoState o Reboot o RunInstall o SetCIDType These procedures are run from within the LAN CID Utility REXX command file. ΓòÉΓòÉΓòÉ 24.1. BootDriveIsDiskette ΓòÉΓòÉΓòÉ This procedure is used to determine if the system was booted from diskette. If the system was booted from diskette, the procedure increments OVERALL_STATE by 1 and returns YES. If the system was booted from the fixed disk, this procedure returns NO. ΓòÉΓòÉΓòÉ 24.1.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of BootDriveIsDiskette: ΓöîΓöÇΓöÇΓöÇ BOOTDRIVEISDISKETTE ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇBootDriveIsDiskette()ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.1.2. Parameters ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.1.3. Returns ΓòÉΓòÉΓòÉ BootDriveIsDiskette returns the following: YES Boot drive is diskette NO Boot drive is fixed disk ΓòÉΓòÉΓòÉ 24.1.4. Example ΓòÉΓòÉΓòÉ Example of BootDriveIsDiskette If BootDriveIsDiskette() == YES then iterate ΓòÉΓòÉΓòÉ 24.2. BootDriveIsFixedDisk ΓòÉΓòÉΓòÉ This procedure is used to determine if the system was booted from fixed disk. If the system was booted from the fixed disk, the procedure increments OVERALL_STATE by 1 and returns YES. If the system was booted from diskette, this procedure returns NO. ΓòÉΓòÉΓòÉ 24.2.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of BootDriveIsFixedDisk: ΓöîΓöÇΓöÇΓöÇ BOOTDRIVEISFIXEDDISK ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇBootDriveIsFixedDisk()ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.2.2. Parameters ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.2.3. Returns ΓòÉΓòÉΓòÉ BootDriveIsFixedDisk returns the following: YES Boot drive is fixed disk NO Boot drive is diskette ΓòÉΓòÉΓòÉ 24.2.4. Example ΓòÉΓòÉΓòÉ Example of BootDriveIsFixedDisk If BootDriveIsFixedDisk() == YES then iterate ΓòÉΓòÉΓòÉ 24.3. CheckBoot ΓòÉΓòÉΓòÉ This procedure checks the environment variables QUEUE_REBOOT and CALL_AGAIN and uses the following rules to determine what should happen next: o If QUEUE_REBOOT is set to 1, the procedure saves the LAN CID Utility environment variables to the CONFIG.SYS file. It then checks CALL_AGAIN; if CALL_AGAIN was set to 0, OVERALL_STATE is incremented. If CALL_AGAIN was set to 1, OVERALL_STATE is not incremented. The procedure then calls the Reboot procedure. o If QUEUE_REBOOT is set to 0, the procedure increments OVERALL_STATE and returns to the calling procedure. Note: For more information on how QUEUE_REBOOT and FALL_AGAIN are set, see Return Code Processing. ΓòÉΓòÉΓòÉ 24.3.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of CheckBoot: ΓöîΓöÇΓöÇΓöÇ CALL CHECKBOOT ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇCheckBootΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.3.2. Parameters ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.3.3. Returns ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.3.4. Example ΓòÉΓòÉΓòÉ Example of Call CheckBoot Call CheckBoot ΓòÉΓòÉΓòÉ 24.4. GetOS2Version ΓòÉΓòÉΓòÉ This procedure is used to determine the version of OS/2 that the system is running. GetOS2Version is basically the same as the SysOS2Ver function provided with REXXUTIL. GetOS2Version was provided because REXXUTIL.DLL does not load in a maintenance environment, and it may be necessary to know the version of OS/2 running on the workstation in order to control the installation. ΓòÉΓòÉΓòÉ 24.4.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of GetOS2Version: ΓöîΓöÇΓöÇΓöÇ GETOS2VERSION ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇGetOS2Version()ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.4.2. Parameters ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.4.3. Returns ΓòÉΓòÉΓòÉ GetOS2Version returns the version of OS/2 running on the workstation. If OS/2 2.1 is running on the workstation, GetOS2Version returns 2.1. ΓòÉΓòÉΓòÉ 24.4.4. Example ΓòÉΓòÉΓòÉ Example of GetOS2Version If GetOS2Version() = 2.0 then if RunInstall(x.semaint20) == BAD_RC then exit else nop else If GetOS2Version() = 2.1 then if RunInstall(x.semaint21) == BAD_RC then exit else nop else if RunInstall(x.semaint2x) == BAD_RC then exit ΓòÉΓòÉΓòÉ 24.5. RebootAndGotoState ΓòÉΓòÉΓòÉ This procedure is used to reboot the workstation and then re-enter the LAN CID Utility REXX command file in a specific state. The procedure saves all of the LAN CID Utility environment variables to CONFIG.SYS, sets OVERALL_STATE to the value specified, and then calls the Reboot procedure. ΓòÉΓòÉΓòÉ 24.5.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of RebootAndGotoState: ΓöîΓöÇΓöÇΓöÇ REBOOTANDGOTOSTATE ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇCall RebootAndGotoStateΓöÇΓöÇ(state)ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.5.2. Parameters ΓòÉΓòÉΓòÉ The following list describes the RebootAndGotoState parameters: State The number (integer) of the state you want to enter after the reboot. This parameter is required. ΓòÉΓòÉΓòÉ 24.5.3. Returns ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.5.4. Example ΓòÉΓòÉΓòÉ Example of RebootAndGotoState Call RebootAndGotoState(4) ΓòÉΓòÉΓòÉ 24.6. Reboot ΓòÉΓòÉΓòÉ This procedure is used to reboot the workstation. It calls SETBOOT.EXE from the EXEPATH directory that is set up at the beginning of the LAN CID Utility REXX command file. This procedure requests that the user remove the diskette from the boot drive if the workstation was booted from diskettes. This procedure does not save any LAN CID Utility state information. LAN CID Utility state information is saved only by CheckBoot and RebootAndGotoState. ΓòÉΓòÉΓòÉ 24.6.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of Reboot: ΓöîΓöÇΓöÇΓöÇ REBOOT ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇRebootΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.6.2. Parameters ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.6.3. Returns ΓòÉΓòÉΓòÉ None ΓòÉΓòÉΓòÉ 24.6.4. Example ΓòÉΓòÉΓòÉ Example of Call Reboot Call Reboot ΓòÉΓòÉΓòÉ 24.7. RunInstall ΓòÉΓòÉΓòÉ This procedure processes the installation program that was set up in the x.n.instprog section of the product data. ΓòÉΓòÉΓòÉ 24.7.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of RunInstall: ΓöîΓöÇΓöÇΓöÇ RUNINSTALL ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇRunInstallΓöÇΓöÇindexΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇstateΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.7.2. Parameters ΓòÉΓòÉΓòÉ The following list describes the RunInstall parameters: index The index value (an integer) of the installation program that is to be installed. This is usually a substitution variable set up earlier in the program, such as X.SEINST. This parameter is required. state The value (an integer) that you want OVERALL_STATE to be set to in the event that the installation fails. This parameter is optional. ΓòÉΓòÉΓòÉ 24.7.3. Returns ΓòÉΓòÉΓòÉ RunInstall returns the following: GOOD_RC Installation was successful. BAD_RC Installation failed. ΓòÉΓòÉΓòÉ 24.7.4. Examples ΓòÉΓòÉΓòÉ Examples of RunInstall if RunInstall(x.laninstr) == BAD_RC then exit if RunInstall(x.laninstr, 4) == BAD_RC then iterate if RunInstall(x.laninstr) == BAD_RC then Call RebootAndGotoState(4) ΓòÉΓòÉΓòÉ 24.8. SetCIDType ΓòÉΓòÉΓòÉ This procedure allows you to set the way that LAN CID Utility processes certain CID return codes received from the installation programs. Some of the CID warning return codes conflict with predefined OS/2 return codes. LAN CID Utility cannot detect whether a return code was received from the operating system or from the install program that it is running. The return codes in question are 0x0004, 0x0008, and 0x0012. OS/2 defines these return codes as follows: 0x0004 ERROR_INVALID_ACCESS 0x0008 ERROR_NOT_ENOUGH_MEMORY 0x0012 ERROR_TOO_MANY_OPEN_FILES The main problem is with 0x0008. CID defines this return code to be "Successful program processing; error messages logged", and OS/2 defines it to be "Not Enough Memory". The CID definition of the return code falls into the successful category, while the OS/2 definition of the return code falls into the severe error category. In the case of a machine that is low on memory, if OS/2 cannot load the program because of insufficient memory, LAN CID Utility receives a return code 0x0008 from the operating system. Because this return code is defined as a successful CID return code, LAN CID Utility assumes that the program completed the installation successfully. This can cause many problems. If you have a command file that is running into this return code conflict problem, you can change the way LAN CID Utility processes the 0x0004, 0x0008, and 0x0012 return codes with the SetCIDType function. You can set the CID type for an entire run of a command file or for only one installation program. When you set the CID type, it is active until it is changed with another call to the SetCIDType function or until the machine is rebooted. By default, the CID type is set to NORMAL. ΓòÉΓòÉΓòÉ 24.8.1. Syntax ΓòÉΓòÉΓòÉ The following diagram illustrates the syntax of SetCIDType: ΓöîΓöÇΓöÇΓöÇ SETCIDTYPE ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇSetCIDTypeΓöÇΓöÇΓö¼ΓöÇNORMALΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé ΓööΓöÇNO4812ΓöÇΓöÿ Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 24.8.2. Parameters ΓòÉΓòÉΓòÉ The following list describes the SetCIDType parameters: NORMAL This parameter indicates that LAN CID Utility should process the CID return codes as they are defined in Return Code Processing. NO4812 This parameter indicates that LAN CID Utility should treat the CID return codes 0x0004, 0x0008, and 0x0012 as bad return codes. ΓòÉΓòÉΓòÉ 24.8.3. Examples ΓòÉΓòÉΓòÉ Examples of SetCIDType The following example shows how to set the CID type to NO4812 for just one installation program. SetCIDType(NO4812) if RunInstall(x.programA) == BAD_RC then exit SetCIDType(NORMAL) The following example shows how to set the CID type to NO4812 for the entire run of an LAN CID Utility command file. SetCIDType(NO4812) Do Forever Select when OVERALL_STATE = 0 then do if RunInstall(x.programA) == BAD_RC then exit Call CheckBoot end when OVERALL_STATE = 1 then do if RunInstall(x.programB) == BAD_RC then exit Call CheckBoot end . . . end end exit ΓòÉΓòÉΓòÉ 25. The CASSETUP Code Server Setup Utility ΓòÉΓòÉΓòÉ This appendix describes CASSETUP, a program shipped on MPTS diskette 3 in the \APPLETS directory. This utility can simplify your redirected installation tasks. ΓòÉΓòÉΓòÉ 25.1. Overview ΓòÉΓòÉΓòÉ CASSETUP provides a Presentation Manager interface for installing and configuring a code server for redirected installation. CASSETUP also provides a user interface to assist in creating boot diskettes and command files for use by clients to initialize and process remote installation sessions. ΓòÉΓòÉΓòÉ 25.2. Functions ΓòÉΓòÉΓòÉ CASSETUP provides the following functions to assist administrators in preparing for redirected installation: o A Presentation Manager interface for the installation and removal of redirected installation support. Redirected installation support includes the LAN CID Utility and the Service Installable File System (SRVIFS). Note: If you are not familiar with LAN CID Utility and SRVIFS, refer to Overview and Roadmap, for a brief overview of these features. o Initial configuration and reconfiguration of SRVIFS. o Installation and removal of diskette images for: - IBM OS/2 2.1 and OS/2 2.11 - IBM OS/2 2.1 Service Pak XR06200 - Multi Protocol Transport Services (MPTS) - IBM LAN Server 4.0 - Other applications. Note: Other applications are supported through user-written or IBM-supplied profiles. See the online documentation, CASSETUP.INF, for information on how to create profiles. o Creating CASPREP input files that allow clients to install any combination of product images that were either installed on or registered with the code server through CASSETUP. For more information on the CASPREP program, see The CASPREP Program, Keywords, and Input Files. o Creating boot diskettes for use by clients to initialize and process redirected installation sessions. ΓòÉΓòÉΓòÉ 25.3. Planning ΓòÉΓòÉΓòÉ The roadmap in Overview and Roadmap, outlines the initial planning steps that you should conduct prior to installing the code server. Therefore, you should read steps 1 through 6 before using CASSETUP to install the code server. In addition to these steps, you should review the following important considerations prior to using the CASSETUP. ΓòÉΓòÉΓòÉ 25.3.1. Requirements ΓòÉΓòÉΓòÉ o The OS/2 program CASSETUP runs on OS/2 2.1 or higher. CASSETUP provides profiles for loading diskette images for the OS/2 2.1 and OS/2 2.11 programs. Any version of OS/2 later than 2.00 may be loaded provided a CASSETUP profile is available. See the online documentation, CASSETUP.INF, for information on how to create profiles. o MPTS LAPS MPTS LAPS must be installed and configured for NetBIOS before you can use CASSETUP to install redirected installation support. Refer to the Multi-Protocol Transport Services - AnyNet for OS/2: Configuration Guide for information on installing and configuring LAPS. o REXX Redirected installation support requires REXX. Therefore, CASSETUP requires REXX to be installed on the workstation before you can install CASSETUP. See Installing CASSETUP from MPTS Diskette 3 for information on how to install CASSETUP. ΓòÉΓòÉΓòÉ 25.4. Obtaining the CASSETUP Online Documentation (CASSETUP.INF) ΓòÉΓòÉΓòÉ More complete information about the CASSETUP program is located in an online document called CASSETUP.INF. This file is located in a pack file called CASSETUP.ZIP in the \APPLETS directory on MPTS diskette 3. To obtain CASSETUP.INF, follow the directions in Installing CASSETUP from MPTS Diskette 3, or unpack the file directly from the diskette. To unpack CASSETUP.INF from the diskette, insert MPTS diskette 3 in drive A: and run the following command: PKUNZIP2 A:\APPLETS\CASSETUP.ZIP <path>\CASSETUP APPLETS\CASSETUP.INF Note: If MPTS is not installed on the workstation on which you are unpacking CASSETUP.INF, you must copy the PKUNZIP2.EXE program from the root directory of MPTS diskette 1 into a directory that is in the current PATH. ΓòÉΓòÉΓòÉ 25.5. CASSETUP Installation ΓòÉΓòÉΓòÉ CASSETUP is located on MPTS diskette 3. The CASSETUP files are packed in a file called CASSETUP.ZIP in the \APPLETS directory on MPTS diskette 3. ΓòÉΓòÉΓòÉ 25.5.1. Installing CASSETUP from MPTS Diskette 3 ΓòÉΓòÉΓòÉ To install CASSETUP from MPTS diskette 3, perform the following steps: 1. To unpack the CASSETUP files into the desired directory, insert MPTS diskette3 into drive A: on the code server and issue the following command: PKUNZIP2 A:\APPLETS\CASSETUP.ZIP <path>\CASSETUP Note: If MPTS is not installed on the workstation on which you are unpacking CASSETUP, you must copy the PKUNZIP2.EXE program from the root directory of MPTS diskette 1 into a directory that is in the current PATH. 2. To place the Code Server Setup icon on the desktop and initialize the CASSETUP files, issue the following command: <path>\CASSETUP\CASINST ΓòÉΓòÉΓòÉ 25.5.2. Installing from a Code Server ΓòÉΓòÉΓòÉ The complete instructions on how to install CASSETUP from a code server are located in the CASSETUP.INF file packed in the file CASSETUP.ZIP in the \APPLETS directory on MPTS diskette 3. The CASSETUP.INF file is located in the <path>\CASSETUP directory on the code server if you followed the installation instructions in Installing from MPTS diskette 3. If you want to unpack CASSETUP.INF from the diskette, follow the directions in Obtaining the CASSETUP Online Documentation (CASSETUP.INF). ΓòÉΓòÉΓòÉ 25.6. Starting CASSETUP ΓòÉΓòÉΓòÉ You can start CASSETUP from the OS/2 desktop or from an OS/2 window. ΓòÉΓòÉΓòÉ 25.6.1. Starting CASSETUP from the OS/2 Desktop ΓòÉΓòÉΓòÉ To start CASSETUP from the OS/2 desktop, double click on the Code Server Setup icon. The Code Server Setup icon is not available unless you ran the CASINST program described in Installing CASSETUP from MPTS Diskette 3 and in the CASSETUP.INF online documentation. ΓòÉΓòÉΓòÉ 25.6.2. Starting CASSETUP from an OS/2 Command Line ΓòÉΓòÉΓòÉ To start CASSETUP from an OS/2 command line, run the following command: <path>\APPLETS\CASSETUP ΓòÉΓòÉΓòÉ 26. LAN CID Utility and SRVIFS Problem Determination ΓòÉΓòÉΓòÉ This appendix contains problem determination information for the LAN CID Utility and SRVIFS. ΓòÉΓòÉΓòÉ 26.1. LAN CID Utility Problem Determination ΓòÉΓòÉΓòÉ LAN CID Utility problem determination includes: o Using the LAN CID Utility log files o Controlling how errors are reported o Recovering from errors o Sending files to IBM ΓòÉΓòÉΓòÉ 26.1.1. Using the LAN CID Utility Log Files ΓòÉΓòÉΓòÉ The LAN CID Utility provides two log files that you can specify in the parameters for the call to the CASINSTL program. One log file records information for CASINSTL and the other records information for the CASAGENT program and the LAN CID Utility REXX command file. If you followed the recommended directory structure, these log files are initially located in the <path>\LOG\LCU directory. Both log files are optional. If you use them, you can control their names and locations. See CASINSTL for information on the /L1: and /L2: parameters of the CASINSTL command and Setting Up the Directory Structure on the Code Server for information on the recommended directory structure. The LAN CID Utility log files are ASCII files that you can browse with any text editor. Following is an example of the contents of a LAN CID Utility log file. <Fri May 08 12:29:13> OS/2 2.1 MAINTENANCE install is starting. <Fri May 08 12:31:20> OS/2 2.1 MAINTENANCE install was successful. <Fri May 08 12:31:21> LAPS MAINTENANCE install is starting. <Fri May 08 12:32:40> LAPS MAINTENANCE install was successful. <Fri May 08 12:32:40> SRVIFS REQUESTER install is starting. <Fri May 08 12:32:55> SRVIFS REQUESTER install was successful. <Fri May 08 12:32:56> LAN CID Utility install is starting. <Fri May 08 12:33:01> LAN CID Utility install was successful. <Fri May 08 12:33:11> Reboot. <Fri May 08 12:34:56> OS/2 2.1 install is starting. <Fri May 08 12:47:18> OS/2 2.1 install was successful. <Fri May 08 12:47:18> LAPS install is starting. <Fri May 08 12:48:21> LAPS install was successful. <Fri May 08 12:48:21> SRVIFS REQUESTER install is starting. <Fri May 08 12:48:31> SRVIFS REQUESTER install was successful. <Fri May 08 12:48:31> LAN CID Utility install is starting. <Fri May 08 12:48:34> LAN CID Utility install was successful. <Fri May 08 12:48:45> Reboot. <Fri May 08 12:50:32> OS/2 2.1 install is starting, REMOTE_INSTALL_STATE=1. <Fri May 08 12:54:02> OS/2 2.1 install was successful. <Fri May 08 12:54:02> SRVIFS REQUESTER install is starting. <Fri May 08 12:54:15> SRVIFS REQUESTER install was successful. <Fri May 08 12:54:15> LAN CID Utility install is starting. <Fri May 08 12:54:19> LAN CID Utility install was successful. <Fri May 08 12:54:24> Reboot. <Fri May 08 12:56:05> SRVIFS DELETE install is starting. <Fri May 08 12:56:09> SRVIFS DELETE install was successful. <Fri May 08 12:56:10> LAN CID Utility DELETE install is starting. <Fri May 08 12:56:15> LAN CID Utility DELETE install was successful. <Fri May 08 12:56:16> Reboot. ΓòÉΓòÉΓòÉ 26.1.2. Controlling How Errors Are Reported ΓòÉΓòÉΓòÉ When an error occurs during an installation using the LAN CID Utility, the default is for the command file to exit to the command line. This action takes place whether the error occurred in an installation program, such as SEINST, or in the LAN CID Utility command file. If you do not want the command file to exit to the command line, you can specify other actions. See Error Processing for additional information. When the LAN CID Utility command file encounters an error that the REXX interpreter found, the error is displayed on the screen. If an installation program such as LANINSTR or SEINST finds the error, it is displayed on the screen and logged in a LAN CID Utility log file, if you specified to use a log file. The following example shows an error message displayed on the screen: CAS0021: PUTSTATEVAR cannot open the file C:\CONFIG.SYS for input. When an installation program encounters an error, the actual return code along with the generic definition of the error, is displayed and logged in the LAN CID Utility log file, if you specified to use a log file. Following is an example: <Tue May 19 14:47:55> LAPS install is starting. <Tue May 19 14:48:03> Product returned 0x1600, Incorrect program invocation. <Tue May 19 14:48:04> LAPS install failed. If an error occurred in an installation program, but the error is not as obvious as the previous example, you should follow the problem determination procedures for the failing installation. Usually, you must consult the error log files specified for the product. Most obscure errors take the following form: <Tue May 12 07:31:07> Product A install is starting. <Tue May 12 07:32:33> Product returned 0x1604, Unexpected condition. <Tue May 12 07:32:34> Product A install failed. See Return Code Processing for the definition of the standard CID return codes. ΓòÉΓòÉΓòÉ 26.1.3. Recovering from Errors ΓòÉΓòÉΓòÉ After you have identified and corrected an error, you can proceed with the installation. If the problem occurred during an installation program that is the only one listed in the When OVERALL_STATE = n statement in the installation sequence, you can either reboot the system or rerun STARTUP.CMD. The command file returns to the state it was in before the error, and the installation continues, starting with the installation program that previously failed. If the failing installation program was not the only one listed in the When OVERALL_STATE = n statement in the installation sequence, recovery is more complicated. The following example shows the difficulties: do forever select when OVERALL_STATE = 0 then do 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 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 if RunInstall(x.ifsdel) == BAD_RC then exit if RunInstall(x.casdelet) == BAD_RC then exit Call Reboot end end end In When OVERALL_STATE = 1, assume that LAPS contains incorrect parameters and fails after SEINST runs successfully. Correct the parameters in the command file and then try to continue with the installation. You cannot reboot, because no connectivity is available; LAN transport or NetBIOS drivers were not installed because LAPS failed. However, you cannot remove the call to SEINST, because SEINST requests a callback. See Reboot and Callback Processing for additional information. Two recovery actions are possible in this example: 1. You can rerun the STARTUP.CMD file to start the entire installation process over. However, this action reinstalls the OS/2 program and may not provide a satisfactory recovery. 2. More specifically, you can edit the LAN CID Utility command file for this client and move the installation of SEINST to the next state (When OVERALL_STATE = 3). From there, it could be called again after the reboot. Then run STARTUP.CMD. LAN CID Utility saves the state of SEINST in the CONFIG.SYS file. When it is called again from the next state, the LAN CID Utility knows that this is the second call to SEINST, and not the first. Recovery actions cannot be provided for all the types of problems that can occur during an installation, but the two examples in this chapter should help get you started. If you cannot devise a recovery action to start the installation process at or near the point of failure, you can always start over again with the boot diskettes. ΓòÉΓòÉΓòÉ 26.1.4. Sending Files to IBM ΓòÉΓòÉΓòÉ When reporting problems to IBM, you should send certain files, located as follows if you used the recommended directory structure: File Location LAN CID Utility command files <path>\CLIENT LAN CID Utility log files <path>\LOG\LCU Product response files <path>\RSP\product CONFIG.SYS Boot drive STARTUP.CMD Boot drive CASPREP files Unspecified For information on sending files to IBM, see the Multi-Protocol Transport Services - AnyNet for OS/2: Error Messages and Problem Determination Guide. See Setting Up the Directory Structure on the Code Server for information on the recommended directory structure. ΓòÉΓòÉΓòÉ 26.1.5. Tracing the LAN CID Utility ΓòÉΓòÉΓòÉ At this time, the LAN CID Utility contains no trace points to use with the OS/2 system tracing utility. ΓòÉΓòÉΓòÉ 26.2. SRVIFS Problem Determination ΓòÉΓòÉΓòÉ SRVIFS problem determination includes: o Recovering from installation errors o Recovering from processing errors o Sending files to IBM ΓòÉΓòÉΓòÉ 26.2.1. Recovering from Installation Errors ΓòÉΓòÉΓòÉ If errors occur during installation, the THINSRV and THINIFS programs display messages you can use to diagnose problems. ΓòÉΓòÉΓòÉ 26.2.1.1. Using THINSRV Messages ΓòÉΓòÉΓòÉ When an error occurs during a SRVIFS server installation, THINSRV displays error messages. THINSRV also supports an optional logging function indicated when you supply the invocation parameter /L1: and provide a valid fully qualified log file name. THINSRV does not support a local error log; it logs information only to the log file provided with the /L1: parameter. If you provide an incorrect log value, THINSRV does not end, but it does not log information to a file. If required configuration parameters are missing from the .INI file, THINSRV ends and displays an error message. After correcting the .INI file, you can start the installation again. ΓòÉΓòÉΓòÉ 26.2.1.2. Using THINIFS Messages ΓòÉΓòÉΓòÉ When an error occurs during a SRVIFS client installation, THINIFS displays error messages. THINIFS also supports an optional logging function indicated when you supply the invocation parameter /L1: and provide a valid fully qualified log file name. THINIFS does not support a local error log; it logs information only to the log file provided with the /L1: parameter. If you provide an incorrect log value, THINIFS does not end, but it does not log information to a file. If an error occurs during installation of the client, you can start the installation again. ΓòÉΓòÉΓòÉ 26.2.2. Recovering from Processing Errors ΓòÉΓòÉΓòÉ If errors occur during processing, the SRVIFS server and SRVIFS client may log and display messages you can use to diagnose problems. ΓòÉΓòÉΓòÉ 26.2.2.1. SRVIFS Server ΓòÉΓòÉΓòÉ SRVIFS on the server can log and display messages, depending on how the command is run. If the SRVIFS server is running as a foreground process, it displays messages and also logs them to the LANTRAN.LOG file under the \IBMCOM directory. If the SRVIFS server is running as a background process, it logs messages to LANTRAN.LOG but does not display them. However, if SRVIFS is running on the OS/2 Extended Edition 1.3 program, a logging facility is not available. The error messages for SRVIFS consist of a generic definition of the error and an error code. Since THINSRV validates most of the configuration parameters, you may not receive any error messages relating to configuration during processing. If the message refers to NetBIOS, the error code is a NetBIOS return code. The following is an example of a NetBIOS error: A NETBIOS error occurred with rc=48 SRVIFS gives the return code in decimal form. The IBM Local Area Network Technical Reference lists the return codes in hex format. Therefore, convert the return code to hex before referring to the IBM Local Area Network Technical Reference. In the preceding NetBIOS example, the hex return code is X'30'. Since SRVIFS is a NetBIOS application, most of the run-time errors (excluding the configuration errors) may relate to NetBIOS. When SRVIFS is running on an OS/2 2.0 system, the system trace utility can be used. For additional information see the Multi-Protocol Transport Services - AnyNet for OS/2: Error Messages and Problem Determination Guide. For NetBIOS minor event codes, see the IBM OS/2 NDIS Driver Implementation Package. ΓòÉΓòÉΓòÉ 26.2.2.2. SRVIFS Client ΓòÉΓòÉΓòÉ If the OS/2 Extended Edition 1.3 program is installed, the SRVIFS client only displays the messages. If LAPS is installed, it logs messages to LANTRAN.LOG because SRVIFS uses the LAPS messages functions. During an OS/2 or Service Pak installation, the SRVIFS client is being run from boot diskettes or in a maintenance system created by SEMAINT. The boot diskettes and the maintenance system created by SEMAINT provide a minimal version of the OS/2 2.x operating system. In both cases, this minimal version of the operating system can be called a maintenance system. The maintenance system does not support the system trace utility. When SRVIFS is run in a maintenance system, it cannot use the system trace utility. Therefore, SRVIFS cannot use NetBIOS diagnostic tools or tools for advanced problem determination of LAPS. SRVIFS provides its own tracing facility to be used during SRVIFS processing in a maintenance system. See SEMAINT for more information on the maintenance system. The major event code for SRVIFS is 164 (X'A4'), which is the same as for NetBIOS, but the minor event codes are: o 144 (X'90') for the issuing of the command o 145 (X'91') for the completion of the command ΓòÉΓòÉΓòÉ 26.2.2.3. Trace Facility ΓòÉΓòÉΓòÉ The traces are not turned on by default. The traces can be turned on or off at any time. You can turn the traces on by issuing the following command: SRVATTCH m: TRACEON where m is the drive letter. After recreating the problem, you can dump the trace buffer to a file by issuing the following command: SRVATTCH m: TRACE where m is the drive letter. This command creates a file (IFSTRC.LOG) and writes the trace data to this file. You can turn the traces off at any time by issuing the following command: SRVATTCH m: TRACEOFF where m is the drive letter. Note: You must use the same drive letter for turning the traces on and off (m in the previous examples). When you use the commands to turn trace on or off or to dump the traces, select drive letters that are not used in the system. When SRVIFS is being run on an OS/2 2.x system, the OS/2 system trace utility can be used. For additional information on the system trace utility, see the Multi-Protocol Transport Services - AnyNet for OS/2: Error Messages and Problem Determination Guide. For NetBIOS minor event codes, see the IBM OS/2 NDIS Driver Implementation Package. ΓòÉΓòÉΓòÉ 26.2.3. Sending Files to IBM ΓòÉΓòÉΓòÉ In addition to any traces you have run, send the following files to IBM: File Location THINSRV log file Specified in the optional /L1: parameter of THINSRV LANTRAN.LOG \IBMCOM IFSTRC.LOG Trace dump in the directory in which you run SRVATTCH. For additional information on sending files to IBM, see Multi-Protocol Transport Services - AnyNet for OS/2: Error Messages and Problem Determination. ΓòÉΓòÉΓòÉ 27. Glossary ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 27.1. authorization list file ΓòÉΓòÉΓòÉ authorization list file A file containing a list of clients that are authorized to access a particular code server. ΓòÉΓòÉΓòÉ 27.2. boot diskettes ΓòÉΓòÉΓòÉ boot diskettes Diskettes created to perform a redirected installation on a client. ΓòÉΓòÉΓòÉ 27.3. callback ΓòÉΓòÉΓòÉ callback A statement in an installation sequence that starts a rebooted CID-enabled program so that it can perform functions such as cleanup routines. ΓòÉΓòÉΓòÉ 27.4. CID ΓòÉΓòÉΓòÉ CID The Configuration Installation Distribution architecture. ΓòÉΓòÉΓòÉ 27.5. CID-enabled program ΓòÉΓòÉΓòÉ CID-enabled program A program that can be installed through redirection by means of a software distribution manager. ΓòÉΓòÉΓòÉ 27.6. client ΓòÉΓòÉΓòÉ client A system being installed, configured, or maintained by redirection. It uses the resources of a code server to gain access to the files and programs it requires. In some cases, it operates under the direction of a software distribution manager. ΓòÉΓòÉΓòÉ 27.7. client discovery ΓòÉΓòÉΓòÉ client discovery A feature of the PerClient keyword that uses the date and time on a directory entry to determine when a client first attached to a server. ΓòÉΓòÉΓòÉ 27.8. code server ΓòÉΓòÉΓòÉ code server A LAN Server on which product images are loaded prior to installing them on clients. Product images must be placed on the code server in a predefined format and structure. ΓòÉΓòÉΓòÉ 27.9. command file ΓòÉΓòÉΓòÉ command file A file containing the user-defined variables and installation commands for installing various programs. The variables point to the installation programs. The installation commands indicate the order in which the programs will be installed. ΓòÉΓòÉΓòÉ 27.10. corrective service diskette (CSD) ΓòÉΓòÉΓòÉ corrective service diskette (CSD) A diskette provided by IBM to registered service coordinators for resolving user-identified problems. This diskette includes program updates designed to resolve problems. ΓòÉΓòÉΓòÉ 27.11. fully qualified path ΓòÉΓòÉΓòÉ fully qualified path The drive and path to the location of a file, where the drive is expressed as, for example, A: or D:, and the path is a series of subdirectories, such as \IMG. The name of the file is not included; D:\IMG is a fully qualified path. ΓòÉΓòÉΓòÉ 27.12. installation sequence ΓòÉΓòÉΓòÉ installation sequence A set of RunInstall statements in a LAN CID Utility REXX command file that controls the order in which products are installed on a client. ΓòÉΓòÉΓòÉ 27.13. keyword=value pair ΓòÉΓòÉΓòÉ keyword=value pair String values recognized by installation programs. ΓòÉΓòÉΓòÉ 27.14. LAN CID Utility ΓòÉΓòÉΓòÉ LAN CID Utility Software distribution manager that uses command files to process product installation on clients. ΓòÉΓòÉΓòÉ 27.15. LAPS ΓòÉΓòÉΓòÉ LAPS LAN Adapter Protocol Support, a transport program for use with LAN CID Utility. ΓòÉΓòÉΓòÉ 27.16. loading ΓòÉΓòÉΓòÉ loading Copying files from diskettes into directories on the code server without installing and configuring the product. ΓòÉΓòÉΓòÉ 27.17. maintenance system ΓòÉΓòÉΓòÉ maintenance system A system that has the OS/2 operating system installed with an established connection to a SRVIFS server but has neither the Presentation Manager program nor the Workplace Shell graphical interface installed. ΓòÉΓòÉΓòÉ 27.18. NetBIOS ΓòÉΓòÉΓòÉ NetBIOS See network basic input/output system. ΓòÉΓòÉΓòÉ 27.19. network basic input/output system (NetBIOS) ΓòÉΓòÉΓòÉ network basic input/output system (NetBIOS) An application programming interface (API) between a local area network adapter and programs. A programming interface provided to the local area network (LAN) so that an application program can have LAN communications without knowledge and responsibility of some of the lower layer protocol functions. Nodes are identified on the LAN by NETBIOS names, and two types of data transfer are supported. Session support provides guaranteed delivery of the data, while datagram support does not guarantee delivery. ΓòÉΓòÉΓòÉ 27.20. NTS/2 ΓòÉΓòÉΓòÉ NTS/2 A product containing LAN CID Utility and SRVIFS. It facilitates redirected installation of clients. ΓòÉΓòÉΓòÉ 27.21. product images ΓòÉΓòÉΓòÉ product images Copies of a product's files loaded onto a code server. These are not installed and configured on the code server, only stored in a directory. ΓòÉΓòÉΓòÉ 27.22. production system ΓòÉΓòÉΓòÉ production system A system that has the full OS/2 2.x program installed, including Presentation Manager program, the Workplace Shell, or both. It also has NetBIOS installed and configured for LAN communications. ΓòÉΓòÉΓòÉ 27.23. reboot ΓòÉΓòÉΓòÉ reboot A programmatic way of simulating a manually performed Ctrl+Alt+Del keystroke sequence. SETBOOT, a utility provided with the OS/2 2.x program, simulates this keystroke sequence. ΓòÉΓòÉΓòÉ 27.24. redirected installation ΓòÉΓòÉΓòÉ redirected installation Installation on a client by means of a drive that is remotely attached over a LAN to a code server. ΓòÉΓòÉΓòÉ 27.25. redirection ΓòÉΓòÉΓòÉ redirection The assigning of a local device name to a remote shared resource on the network. ΓòÉΓòÉΓòÉ 27.26. response file ΓòÉΓòÉΓòÉ response file A file containing answers to the the configuration questions asked during the installation of OS/2 products. A response file contains keyword=value pairs that establish how a client or code server is to be configured and used. ΓòÉΓòÉΓòÉ 27.27. software distribution manager ΓòÉΓòÉΓòÉ software distribution manager A program that orders installations on a client and performs the installations in the specified order. ΓòÉΓòÉΓòÉ 27.28. SRVIFS ΓòÉΓòÉΓòÉ SRVIFS A small, limited-function file redirector over NetBIOS. It enables clients to gain access to files on a code server by means of a remotely attached drive. It is well suited to the CID environment because its relatively small size permits it fit onto the boot diskettes.