home *** CD-ROM | disk | FTP | other *** search
ΓòÉΓòÉΓòÉ 1. Version Notice ΓòÉΓòÉΓòÉ First Edition (February 1994) This edition describes the Configuration, Installation, and Distribution (CID) methodology. Any modifications will appear in new editions. Publications are not stocked at the address given below. If you want more IBM publications, ask your IBM representative or write to the IBM branch office serving your locality. A form for your comments is provided at the back of this document. If the form has been removed, you may address your comments to: IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. ΓòÉΓòÉΓòÉ 2. Notices ΓòÉΓòÉΓòÉ References in this book to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. The evaluation and verification of operation in conjunction with other products, except those expressly designated by IBM, are the responsibility of the user. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You may send license inquiries, in writing, to: IBM Corporation IBM Director of Licensing 208 Harbor Drive Stamford, Connecticut United States 06904 This document is not intended for production use and is furnished as is without any warranty of any kind, and all warranties are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose. ΓòÉΓòÉΓòÉ 2.1. Trademarks ΓòÉΓòÉΓòÉ The following terms, denoted by an asterisk (*) at their first occurrence in this publication, are trademarks of the IBM Corporation in this country or other countries or both: ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Extended Services Γöé Operating System/2 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé IBM Γöé OS/2 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Micro Channel Γöé VTAM Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé NetView Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The following terms, denoted by two asterisks (**) at their first occurrence in this publication, are trademarks of other companies: ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Microsoft Windows Γöé Microsoft Corporation Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé NetWare Γöé Novell, Inc. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Novell Γöé Novell, Inc. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé SMC Γöé Standard Microsystems Corporation Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Ungermann-Bass Γöé Ungermann-Bass, Inc. Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Windows Γöé Microsoft Corporation Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé WordPerfect Γöé WordPerfect Corporation Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 3Com Γöé 3Com Corporation Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓòÉΓòÉΓòÉ 3. About This Book ΓòÉΓòÉΓòÉ The IBM* Configuration, Installation, and Distribution (CID) methodology allows CID-enabled products to be installed and configured at client workstations in local area network (LAN) environments with little or no user interaction. This book describes how to install three CID-enabled products on client machines from a central server: o PC DOS 6.1 (with the PC DOS CID diskette) or higher o LAN Support Program 1.35 or higher Note: If you have LAN Support Program 1.34 or lower, you will need Corrective Service Diskette UR40349. o NetView* Distribution Manager/2 2.0 with Corrective Service Diskette XR20334 or higher Once installed, these three products form an enablement platform on the client which enables subsequent unattended CID installations of DOS or Microsoft Windows** applications on the LAN. This book focuses on CID enablement in stand-alone LANs, but having accomplished CID tasks and enablement within the LAN, an administrator can extrapolate CID tasks to more complex environments using NetView DM/2 for LAN-to-LAN procedures and NetView DM for host-attached workstations or host-attached LANs. ΓòÉΓòÉΓòÉ 3.1. Who Should Read This Book ΓòÉΓòÉΓòÉ This book is intended for the LAN administrator of a stand-alone LAN, consisting of an Operating System/2* (OS/2*) server and one or more DOS clients. This book assumes that the LAN administrator has installed NetView DM/2 on the server and is familiar with NetView DM/2 functions such as change file creation, naming conventions, and creating client/server names. Product Enablement is intended for those who want to enable OS/2, DOS, or DOS with Windows** applications for CID installation. ΓòÉΓòÉΓòÉ 3.2. How to Use This Book ΓòÉΓòÉΓòÉ This book is organized as follows: o An Introduction to CID briefly describes CID terminology and concepts. o CID Enablement of Pristine DOS Clients describes how to install CID-enabled PC DOS, LAN Support Program, and NetView DM/2 on pristine DOS clients. o Migration of CID-Enabled Clients describes how to migrate CID-enabled PC DOS, LAN Support Program, and NetView DM/2 on DOS clients. o DOS Application Installation at CID-Enabled Clients describes how to install non-CID-enabled applications on DOS clients. o PC DOS Response File and Command Line Parameters documents the PC DOS response file and command line parameters, and lists the return codes. o LAN Support Program Response File and Command Line Parameters documents the LAN Support Program response file and command line parameters, and lists the return codes. o NetView DM/2 Response File and Command Line Parameters documents the NetView DM/2 response file and command line parameters. o Product Enablement describes how to enable OS/2, DOS, or DOS with Windows applications for CID. ΓòÉΓòÉΓòÉ 3.3. Terminology ΓòÉΓòÉΓòÉ The following terms are used in this book: o A pristine system is a programmable workstation without an installed operating system. Workstations with other network operating systems, such as Novell**, are also considered pristine. o Diskette images are source files transferred from product diskettes to a server hard drive. The files are copied to the server drive in a product-specific directory structure understandable to the installation program. o The seed diskette (also boot diskette) contains: - A "kernel" DOS system - A LAN transport system for NetBIOS and adapter interfaces - A redirector and NetView DM/2 agent to access the OS/2 code server and the files residing there o A change control server (also CC server, code server, or simply server) stores diskette images and manages the installation of software on CC clients. In this book, the code server is an OS/2 workstation. Note: You can also use another workstation, a preparation site, to prepare the files and send them to the server. See NetView Distribution Manager/2 Change Distribution Manager User's Guide for more information about using preparation sites. This book assumes that the preparation site is the code server. o Change control clients (also CC clients or simply clients) are the workstations in the LAN which are controlled by the code server. In the scenarios in this book, the clients are DOS or DOS with Windows workstations. o A software distribution manager (SDM) distributes CID-enabled software to client workstations. In the scenarios in this book, the SDM is NetView DM/2. o A change file profile (also profile) specifies installation programs, client/server relationships (names, target/source directories, location and name of error log files), response files, and the paths/names of directories to be referenced by the client. The information built by the profile is stored as a change file object. o Change file objects are built from profiles and are the objects selected for a CID install. ΓòÉΓòÉΓòÉ 3.4. Where to Find More Information ΓòÉΓòÉΓòÉ The following books offer more information about CID enablement and implementation in the Q4 (host-connected LAN) and Q3 (host-connected workstation) environments: o OS/2 Version 2.0 Remote Installation and Maintenance (GG24-3780) explains how to use IBM LAN Server's Remote IPL (RIPL) feature, TCP/IP Network File System (NFS), and NetWare** Server as code providers for the CID process. It also describes OS/2 2.0 response file samples and provides a response file keyword reference, information about automated disk partitioning, and the C source code of a CID-enabled OS/2 2.0 application. o Automated Installation for CID Enabled Extended Services, LAN Server V3.0, and Network Transport Services/2 (GG24-3781) describes how to install NTS/2 LAN Adapter and Protocol Support (LAPS), LAN Server V3.0, and Extended Services*, exploiting CID features and the OS/2 LAN CID Utility. In addition, it details the CID enablement requirements for products and introduces LAN NetView Start. o Automated Installation for CID Enabled OS/2 V2.x (GG24-3783) provides conceptual information about the CID process as well as detailed information about the installation, maintenance, and migration of OS/2 using the tools provided by NTS/2 (LAPS, SRVIFS, and the OS/2 LAN CID Utility). In addition, the C source code of a CID-enabled OS/2 application is provided. o NetView Distribution Manager Overview and Scenarios (SH19-6797) describes installation and migration scenarios using the CID features of OS/2 2.0. o NetView Distribution Manager/2 Change Distribution Manager User's Guide (SH19-5048) describes how to use the CDM function to distribute data and software. o NetView Distribution Manager/2 Concepts and Overview (GH19-4009) provides an overview of NetView DM/2 2.0 structure and function. o NetView Distribution Manager/2 Installation and Customization Guide (SH19-6915) describes how to set up NetView DM/2 2.0 in different system environments. Some of these environments can then be used to install CID-enabled applications. o Network Transport Services/2 Redirected Installation and Configuration Guide (S96F-8488) provides information about the OS/2 LAN CID Utility and its usage in installations of OS/2 CID-enabled products. o OS/2 System Software Distribution & Installation Using NetView DM/2 (GG66-3253) describes the remote installation of OS/2 and CID-enabled OS/2 applications in a stand-alone LAN. It also discusses host-connected server systems. o Software Profile Management Facility MVS/ESA Implementation Guide (SC30-3574) provides information about SPMF and its usage. ΓòÉΓòÉΓòÉ 4. An Introduction to CID ΓòÉΓòÉΓòÉ The information technology resources of enterprises are increasingly decentralized. The traditional environment-nonprogrammable workstations connected to a host-has given way to the use of intelligent workstations. Those workstations can be attached to stand-alone local area networks (LANs), to host-connected LANs, or directly to hosts. Where users once shared a common system and set of applications, they are more likely today to operate and maintain fully functional and customizable systems. Advances in graphical interfaces and more intuitive command interfaces have simplified operating tasks for users of workstations, but installation, maintenance, and configuration have grown more complicated as personal software grows in complexity and capability. Consequently, the task of administration becomes more complicated since each new workstation represents a new resource to be managed. System support personnel must address problems with program incompatibilities and user mismanagement on each system and must install software with each new release. The administrator's involvement can be particularly intense in production environments where owners of the workstations are not expected to have the technical expertise to respond accurately to customization dialogs during installation and migration. Configuration, Installation, and Distribution (CID) helps to consolidate the resources needed for workstation administration and to eliminate the need for installation expertise at the client workstation. CID allows installation of software at client machines from code residing at a central server, freeing support personnel from the tedious, repetitive, and time-consuming tasks of inserting diskettes and responding to installation dialogs at each client workstation. CID minimizes, and often eliminates, the need for human intervention at the client machine. Distribution of CID-enabled software is performed by a software distribution manager (SDM), such as NetView DM/2. The SDM preempts the manual tasks usually expected when installing software at the workstation: swapping diskettes, reacting to customization prompts, monitoring error conditions, performing diagnostics, and rebooting the system at the conclusion of the process. SDMs differ in the degree of automation they offer the systems administrator, varying from attended modes requiring invocation from the client machines, to unattended modes that allow off-shift scheduling and remote invocation. ΓòÉΓòÉΓòÉ 4.1. CID Enablement ΓòÉΓòÉΓòÉ Six characteristics distinguish CID-enabled software: o Redirected installation: The ability to install software from a source other than a diskette drive (for example, A:) of the user's machine. In the CID scenarios discussed in this book, the product's source data consists of diskette images residing on drives, directories, and subdirectories on a server machine attached via a LAN. o Response file support: CID install programs must be able to automatically access and use the scripted information on a code server which is normally entered by a user as part of an attended product installation. o Command-line-driven execution: Installation and customization prompts from CID-enabled products must use a command line interface. Dialog-driven installations require human intervention and are, therefore, unsuitable for CID purposes. o Logging facilities: CID-enabled products can define logs used to store information about the progress and completion of product installs and updates. These logs contain information such as update history and error information. o Standard return codes: Return codes conforming to CID standards must be provided by the installation program. The SDM uses these codes to verify successful completion of the installation process and to identify errors. o Code transfer utilities: CID requires that code be transferred to a hard drive as diskette images. All CID-enabled products must have explicitly stated methods of loading files from shipped product diskettes into a predetermined hard drive directory format that is understood and accessible by the CID-enabled installation program. ΓòÉΓòÉΓòÉ 4.2. CID Process for DOS ΓòÉΓòÉΓòÉ CID procedures depend on network configurations and the SDMs used in those environments. The following high-level scenario describes the general process required to install PC DOS 6.1, LAN Support Program 1.35, and NetView DM/2 2.0 on a stand-alone LAN with an OS/2 server and DOS clients. Once an operating base is established with these three products, the DOS clients, using NetView DM/2 as an SDM, provide the CID enablement platform for the installation of DOS applications. The administrator must perform the following steps for CID enablement: 1. Transfer the product diskette images. 2. Create a seed diskette for client workstations. 3. Create or edit the response files. 4. Build change file profiles. 5. Boot the seed diskette at the client machine. 6. Install the product code. The scenarios in this book provide more information about each of these steps. For more details, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. Note: If the DOS client has multiple named sections in the CONFIG.SYS file and the product installation modifies CONFIG.SYS, CID installs of products may not work correctly. You may need to build a customized minimal CONFIG.SYS from the multiple sections of the CONFIG.SYS file, using the NetView DM/2 ANXIDMCF utility. Refer to NetView Distribution Manager/2 Installation and Customization Guide for more details. Refer to the product documentation to see if it supports CONFIG.SYS files with multiple named sections. ΓòÉΓòÉΓòÉ 4.3. Installation Modes ΓòÉΓòÉΓòÉ There are various degrees of CID automation, defined by the amount of human intervention required at the workstation. These levels of automation are called "installation modes," but are not limited to installation tasks. Throughout this book, installation implies the subtasks of customization, migration, and maintenance. ΓòÉΓòÉΓòÉ 4.3.1. Attended Installation ΓòÉΓòÉΓòÉ Attended installation is a familiar scenario. It includes (but is not limited to) the standard diskette install that CID methodologies are meant to replace. In both the CID and the traditional scenario, attended installation requires a knowledgeable user at the client workstation. This user issues the install command, responds to configuration prompts, inserts diskettes, responds to error conditions, and reboots the system (if required). Although attended installation with CID requires user presence, it can minimize user interaction. With redirected drives, for instance, installation can be performed without the use of diskettes. The client system accesses diskette images residing on the server. This lowest level of CID automation, referred to as a "pull" process, offers some improvements and savings over the traditional install. LAN administrators can keep only one copy of the shipped product diskettes on the server, instead of replicating, distributing, and maintaining several copies. ΓòÉΓòÉΓòÉ 4.3.2. Lightly Attended Installation ΓòÉΓòÉΓòÉ Lightly attended installation is characterized by an environment where a user initiates the installation process (via a startup diskette or "ready" acknowledgment to the server), perhaps replaces diskettes when prompted, and reboots the system. However, in a lightly attended CID mode, the requirements of the user are for mechanical, not technical, support. The "attended" or "pull" process uses only the CID-enabled product's redirected drive capabilities. The lightly attended scenario adds reliance on a second CID characteristic: response file capabilities. The pristine scenarios described in this book are lightly attended scenarios. The administrator boots a seed diskette on the client machine and removes it after a single object calling the ANXDXCPY file from NetView DM/2 has been downloaded from the server. The scenarios can also be described as "push" scenarios because redirected drives and response files allow an administrator to concentrate technical expertise at the server, issuing the install command and monitoring the procedure from a server. Lightly attended installs can also be accomplished with a client redirector such as DOS LAN Requester with the response file residing on the server and a manual reboot at the client. ΓòÉΓòÉΓòÉ 4.3.3. Unattended Installation ΓòÉΓòÉΓòÉ Unattended installation requires no user intervention at the client workstation. Installation invocation and logging is handled by the SDM. Unattended installation requires that the client have a distribution agent running. When the SDM initiates an installation, it communicates with the client agent to invoke the CID install program, which then transfers the product images from the server to the client workstation, optionally logs error and history information, and exits to the SDM client agent. ΓòÉΓòÉΓòÉ 4.4. CID Environments ΓòÉΓòÉΓòÉ The CID process can be implemented in each of the following environments: o Stand-alone PCs (Q1) o Stand-alone LAN (Q2) o Host-connected workstation (Q3) o Host-connected LAN (Q4) Note: The Qx in parentheses signifies the different types of LAN environments. In each of these environments, the server must be an OS/2 machine. For the purposes of this book, the client is a DOS machine. This document focuses on the stand-alone LAN. Information about the other environments can be found in the publications listed in Where to Find More Information. A stand-alone LAN (defined as the Q2 environment) consists of workstations in a local area network with no host connection and with one workstation acting as the server system. See Stand-Alone LAN (Q2). Stand-Alone LAN (Q2) In the CID environment, the stand-alone LAN can be used in a lightly attended or unattended fashion. In each of these, all files and software objects are prepared at the NetView DM/2 2.0 code server or at some other workstation and sent to the code server. ΓòÉΓòÉΓòÉ 4.5. Planning for Enabler Installation ΓòÉΓòÉΓòÉ Before installing the CID enabler products, you need to consider the naming conventions and the directory structure. ΓòÉΓòÉΓòÉ 4.5.1. Naming Conventions ΓòÉΓòÉΓòÉ NetView DM/2 2.0 requires that names of servers and clients be a maximum of eight alphanumeric characters in length. The names you select should follow a convention chosen by your organization to make it easier to identify the resources and maintain your LAN. Examples of Valid and Invalid Server and Client Names shows LANs with various client and server names. Examples of Valid and Invalid Server and Client Names Example A shows a LAN with valid names. The NetView DM/2 server and each client have unique names that are eight characters or fewer. Example B shows a LAN containing two clients with the same name. Because all clients within the same LAN must have unique names, the client names for this LAN are invalid. Example C shows a LAN where the server and client have the same name. This is also invalid because the client and server cannot have the same name. Example D shows a LAN that is connected to another LAN. In an interconnected environment, all server names within the network must have unique names. Both servers are named SERVER1, which is invalid. Both the server and client names are known to each server and client. If you change the name of the server, the server name must be changed in both the server and in each client known to that server. Note: In a host-attached LAN environment, the server and client names are also known to the host. Any changes to names in this environment must be made in the host, server, and client. Since the clients and servers must have unique names, you might want to consider using the same naming conventions used by your enterprise for VTAM* LUs for your NetView DM/2 2.0 names. For more details about operating in a host-attached environment, refer to the publications listed in Where to Find More Information. ΓòÉΓòÉΓòÉ 4.5.2. CID Directory Structure ΓòÉΓòÉΓòÉ A well structured directory makes maintenance on your server easier. You should organize the files for CID-enabled products in a standard fashion. NetView DM/2 does not require a fixed CID directory structure. Instead, it provides the flexibility to support any structure you define. Although many CID-enabled products are capable of adding themselves to an existing directory structure, it is recommended that you create a directory tree such as the one shown in Sample CID Directory Structure. Note that the CID structure should be built on a dedicated large disk partition. Remember that images of all of your CID-enabled products need to be stored there. The code server should use the HPFS file system. SA:\ Γö£ΓöÇΓöÇCID Γöé Γö£ΓöÇΓöÇEXE Common EXE files Γöé Γö£ΓöÇΓöÇIMG Diskette images of... Γöé Γöé Γö£ΓöÇΓöÇCSD Γöé Γöé Γöé Γö£ΓöÇΓöÇDOS Service Pak for PC DOS 6.1 Γöé Γöé Γöé ΓööΓöÇΓöÇNVDM2 Service Pak for NetView DM/2 2.0 Γöé Γöé Γö£ΓöÇΓöÇDOS PC DOS 6.1 Γöé Γöé Γö£ΓöÇΓöÇLSP LAN Support Program 1.35 Γöé Γöé ΓööΓöÇΓöÇNVDM2 NetView DM/2 2.0 Γöé Γö£ΓöÇΓöÇLOG Installation log files of... Γöé Γöé Γö£ΓöÇΓöÇCSD Γöé Γöé Γöé Γö£ΓöÇΓöÇDOS Service Pak for PC DOS 6.1 Γöé Γöé Γöé ΓööΓöÇΓöÇNVDM2 Service Pak for NetView DM/2 2.0 Γöé Γöé Γö£ΓöÇΓöÇDOS PC DOS 6.1 Γöé Γöé Γö£ΓöÇΓöÇLSP LAN Support Program 1.35 Γöé Γöé ΓööΓöÇΓöÇNVDM2 NetView DM/2 2.0 Γöé ΓööΓöÇΓöÇRSP Response files for... Γöé Γö£ΓöÇΓöÇCSD Γöé Γöé Γö£ΓöÇΓöÇDOS Service Pak for PC DOS 6.1 Γöé Γöé ΓööΓöÇΓöÇNVDM2 Service Pak for NetView DM/2 2.0 Γöé Γö£ΓöÇΓöÇDOS PC DOS 6.1 Γöé Γö£ΓöÇΓöÇLSP LAN Support Program 1.35 . ΓööΓöÇΓöÇNVDM2 NetView DM/2 2.0 Sample CID Directory Structure ΓòÉΓòÉΓòÉ 4.5.2.1. Subdirectories ΓòÉΓòÉΓòÉ The example directory structure in Sample CID Directory Structure contains four main subdirectories. These subdirectories are used as follows: EXE The SA:\CID\EXE subdirectory is used to store executable files that are to be accessed from the client workstations during the installation or migration process. IMG The SA:\CID\IMG subdirectory is used to store diskette images of products to be installed or migrated. LOG The SA:\CID\LOG subdirectory can be used during the installation process to hold log files written by CID-enabled products. Each product should write its log files to the appropriate product-specific directory. For consistency, it is recommended that log files be named with the extension .LOG. RSP The SA:\CID\RSP subdirectory contains response files for each product within the product-specific directories. For consistency, it is recommended that response files be named with the extension .RSP. ΓòÉΓòÉΓòÉ 4.6. DOS Implementations ΓòÉΓòÉΓòÉ In a stand-alone LAN environment with DOS clients (the network configuration described in this book), NetView DM/2 is the SDM managing the distribution of CID-enabled DOS and Windows applications. In this stand-alone network, NetView DM/2 2.0 is installed on one of the OS/2 workstations in the network. This workstation becomes the change control server for the network. Other workstations on the LAN are designated as change control clients. The Change Distribution Manager (CDM) is the component of NetView DM/2 that provides software and data distribution, scheduling, and other change control functions. Specifically, CDM allows the distribution of: o Software (both applications and system executable code) o Flat data o Relational data o Procedures (.CMD or .BAT files) o Dumps (hexadecimal dumps for diagnosis) o Configuration files o Traces o Error logs In order to distribute software and data, you must use CDM to build data into objects for distribution. The objects reside in the server and are distributed to clients via the install command issued from the CDM-Catalog. For specific NetView DM/2 configurations and packages, refer to NetView Distribution Manager/2 Concepts and Overview. ΓòÉΓòÉΓòÉ 5. CID Enablement of Pristine DOS Clients ΓòÉΓòÉΓòÉ This chapter describes the: o Transfer of diskette images to the NetView DM/2 server in preparation for a CID install of PC DOS, LAN Support Program, and NetView DM/2 client code o Creation of the seed diskette for the transfer of minimal PC DOS, LAN Support Program, and NetView DM/2 code to pristine machines o Installation of PC DOS, LAN Support Program, and NetView DM/2 on the client The following procedures assume that NetView DM/2 is already installed at the server site. These scenarios assume that the client is pristine, meaning that the machine has no operating system installed and its hard drive is unformatted. Workstations with other network operating systems, such as Novell, can also be treated as pristine systems. Note: You cannot do a pristine installation for workstations that already have NetView DM/2 installed. Instead, see Migration of CID-Enabled Clients. ΓòÉΓòÉΓòÉ 5.1. Before You Begin ΓòÉΓòÉΓòÉ You will need the following items before installing code onto a pristine DOS client: o PC DOS 6.1 diskettes (including the PC DOS CID diskette) o LAN Support Program 1.35 diskette Note: If you have LAN Support Program 1.34 or lower, you will need CSD UR40349. o NetView DM/2 2.0 diskettes (including CSD XR20334 or higher) o A blank, 3-1/2 inch, 1.44 MB diskette Note: It is recommended that the blank diskette be at least 1.44 MB to enable storage of decompression code, an NDIS MAC driver, and the product code. If you are using a 5-1/4 inch, 1.2 MB diskette for the seed diskette, see Alternate Procedures. Note: If the DOS client has multiple named sections in the CONFIG.SYS file, refer to the note on page CID Process for DOS before installing the product code. ΓòÉΓòÉΓòÉ 5.2. Transferring Diskette Images to the Server ΓòÉΓòÉΓòÉ 1. Transfer the diskette images to the server's hard drive following the procedures outlined in the README file (located on one of the product diskettes) or in the product documentation. The directory structure of the diskette images on the server's hard drive is critical because the install sequence executing at the client will anticipate the predetermined format. See CID Directory Structure for more details. o To copy the PC DOS 6.1 CID-enabled code to the server: - Get the PC DOS 6.1 package and do an admin install (SETUP /A) to a directory on the code server (for example, SA:\CID\IMG\DOS). If you plan on upgrading any machines that are using a disk compression program, you need to make sure that your package contains the compression function. Search for SSUNCOMP.EXE in the PC DOS 6.1 directory on the code server. Refer to the README.CID file for more details. - Copy the following files from the PC DOS CID diskette to the same directory as used in the previous step: USETUP.COM, USETUP1.OVL, USETUP.INI, SAMPLE.RSP, README.CID, DOSDISK.COM, and DOSDISK.INI. o To copy the LAN Support Program 1.35 CID-enabled code to the server: - Use the XCOPY command with the /S parameter to load LAN Support Program onto the code server. Note: The /S parameter on the XCOPY command is necessary because the LAN Support Program source diskette contains subdirectories. In the following example, assume that the LAN Support Program source diskette is in the A: drive and that the current drive is the code server drive: MD LSP XCOPY A: LSP /S The directory structure on the code server and the name of the directory to which the LAN Support Program source is copied is up to the administrator. For example, it might be SA:\CID\IMG\LSP. o To copy the NetView DM/2 2.0 CID-enabled code to the server: - Use the NVDMDCPY command to load NetView DM/2 onto the code server. With NetView DM/2 diskette 13 in the A: drive, enter the NVDMDCPY command. For example, you might type: NVDMDCPY /S:A: /T:C:\CID\IMG\NVDM2 2. Call up the sample product response files (a .RSP file located on one of the product diskettes) using an ASCII text editor. The response file for a CID-enabled product, such as PC DOS or LAN Support Program, consists of a series of keywords preceded by an asterisk (*) or a semicolon (;). Note: NetView DM/2 uses a double slash (//) to indicate a comment. Each keyword is followed by a list of potential values and the default value for that keyword, if applicable. Using the sample response file as a model, customize the product response files by deleting the comment tags and specifying the appropriate keyword for the desired action. Response files must be stored in the shared area on the code server. For example: SA:\CID\RSP\<ProductDirectory>. See Sample Response Files and the appendixes for examples of response files. 3. Create a change file profile using Change Distribution Manager (CDM) dialogs or (if the CDM BUILD function is to be used) an ASCII editor. The profile specifies: o CDM-Catalog information identifying the type and global name of the object to be cataloged o File specification information providing the local names of the files that are to be copied to the client during the installation o Installation information specifying: - The install program to be run at the client machine - Any parameters needed - The name of the response file A profile must be created and cataloged for each product to be installed. See Sample Change File Profiles for examples of change file profiles. For more details about profiles, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. Note: Some CID-enabled products, such as LAN NetView Agent for DOS, require that the current directory on the client be set to the directory where the code images are stored when installing code. This is not the case for CID installations. To enable a CID installation to complete successfully, use CDM-Catalog dialogs or edit the change file profile to specify the working directory (for example, WorkingDir = SA:\CID\LNV\IMG). 4. Invoke the NetView DM/2 BUILD function to create a change file for the install procedure. This change file object must be located in the FSDATA directory on the code server. 5. The resulting change file object is available in the CDM-Catalog awaiting the product install request. ΓòÉΓòÉΓòÉ 5.3. Creating the Seed Diskette ΓòÉΓòÉΓòÉ Having copied PC DOS, LAN Support Program, and NetView DM/2 into a directory structure on the server hard drive, you need to create a bootable seed diskette containing minimal code for each of the three products. The seed diskette should be at least 1.44 MB to enable the storage of decompression code (such as DBLSPACE.BIN and DBLSPACE.SYS), an NDIS MAC driver, and the PC DOS, LAN Support Program, and NetView DM/2 code. If you are using a 5-1/4 inch, 1.2 MB diskette for creating the seed diskette, see Alternate Procedures. 1. Invoke the DOS command DOSDISK from a native DOS machine running PC DOS 4.0 or higher. If you do not have a native DOS machine nearby, see Alternate Procedures. a. Make sure that the DOSDISK.COM and DOSDISK.INI files are in the same directory on the code server as all of the other PC DOS 6.1 files. Note: The DOSDISK.INI file contains a list of the DOS files that are to be copied to the seed diskette. All of the files must be in the same directory as the DOSDISK program. This should be the PC DOS 6.1 directory on the code server. b. Insert the seed diskette into the diskette drive (for example, A:). c. Invoke the DOSDISK program. DOSDISK requires two parameters: the drive to create the diskette and the directory containing the version of DOS that is running on the machine. For example, the command might look like this: DOSDISK A: C:\DOS61. Note: DOSDISK allows a third parameter. This parameter enables the user to specify another file that contains a list of additional files to copy to the diskette. The lines in the file are appended to the COPY command and then executed. If only one file name is specified on the line, the file is copied to the destination diskette with the same name. If a second file name is specified on the line, then the file is copied to the destination diskette with that name. The format is as follows: C:\README.DOC G:\DOS61\AUTOEXEC.NEW AUTOEXEC.BAT d. When prompted to format another diskette, press N. e. You should see DOSDISK copy several files to the diskette. 2. Invoke the LAN Support Program command DXMAID from the code server. a. At the code server, invoke DXMAID from the subdirectory containing the LAN Support Program files and perform a normal attended install. The DXMAID command can be issued from an OS/2 or DOS command prompt in OS/2 2.0 or higher, or from a DOS command prompt in OS/2 1.3. b. On the Setup screen, provide the following information: Are you updating an existing configuration? NO Do you have driver diskettes? YES (if using NDIS) Target for LSP: A:\ (or appropriate drive and path) CONFIG.SYS to update: A:\ (or same drive as above) AUTOEXEC.BAT to update: A:\ (or same drive as above) c. On the Process Driver Diskette screen (if using NDIS), provide the drive and path where the NDIS MAC driver files are located for the adapter that this seed diskette is intended to support. Note: A seed diskette can support only one adapter interface driver. d. You should see DXMAID copy several files to the diskette. 3. Invoke the NetView DM/2 command NVDMBDSK from an OS/2 window on the code server. a. At the code server, invoke the NVDMBDSK command. CDM-Catalog Boot Diskette Update Panel appears. CDM-Catalog Boot Diskette Update Panel b. From the Boot Diskette Update panel, you can specify both server and client names. However, if a client name is given at this point, then one diskette must be made for each client workstation, since each client must be given a unique name. The more efficient approach for larger LANs would be to give only the server name during seed diskette creation and specify the client name during client workstation reboot. c. NetView DM/2 updates the DOS CONFIG.SYS file to reflect its install parameters. d. The AUTOEXEC.BAT and CONFIG.SYS files are updated with the NetView DM/2 equivalent for correct execution of the seed diskette at the client workstation. At this point, the seed diskette has been created and can be distributed to client workstations. You might want to test the diskette on a workstation to make sure that either the IBM DOS 6.1 Startup Menu or the CDM Agent pop-up panel appears. ΓòÉΓòÉΓòÉ 5.4. Installing Code at the Pristine Client ΓòÉΓòÉΓòÉ Having copied the diskette images to the server and created a seed diskette, you can proceed with the installation of PC DOS, LAN Support Program, and NetView DM/2. At the code server: 1. Check to make sure that the client is active at the server by using CDM dialogs or by typing CDM LISTWS. Note: This command lists the status of all client workstations. 2. From the CDM-Catalog main panel, select the objects representing the products to be installed: PC DOS, LAN Support Program, and NetView DM/2 (see CDM-Catalog Main Panel). In addition, a fourth object, ANXDXCPY, must be selected since it is a prerequisite for a pristine install. The ANXDXCPY object is built from a change file profile calling the ANXDXCPY.EXE program from NetView DM/2. CDM-Catalog Main Panel For more information about the CDM-Catalog, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. Note: If you want only one partitioned drive on the DOS client, see step Installing Code at the Pristine Client before proceeding. 3. Select Install... from the "Selected" pull-down menu. CDM-Catalog Install Panel appears. CDM-Catalog Install Panel 4. From the Install panel, click on Order... to select the order in which the objects are to be installed. In a pristine installation, ANXDXCPY must be the first object sent to the client. The product installation sequence is PC DOS, LAN Support Program, and then NetView DM/2. To return to the Install panel, click on OK. CDM-Catalog Install Order Panel 5. From the Install panel, select the names of the clients that are to receive the code. Your initial tests should probably be directed toward a single client. 6. Click on Options.... From the Options panel, click the Install as a coreq group box. Then, click on Set. CDM-Catalog Options Panel 7. From the Install panel, click on Install to execute the INSTALL command immediately. If you want to schedule the install for later execution, click on Schedule.... At the DOS client: 1. Boot the seed diskette at the client workstation with the Ctrl-Alt-Del sequence or by powering on. 2. The IBM DOS 6.1 Startup Menu appears, offering three options: 1. NetView DM/2 Pristine Machine: Run FDISK 2. NetView DM/2 Pristine Machine: Format New Drives 3. NetView DM/2 Pristine Machine: Start Agent For a pristine installation, you can select one of two options: o If you want only one partitioned drive, select option 3. You must first install PC DOS at the client, which automatically partitions and formats the drive. Then, you can perform a chained install of ANXDXCPY, LAN Support Program, and NetView DM/2. o If you want more customized partitions and drives, use the IBM DOS 6.1 Startup Menu. Select option 1. Then, select option 2. After the disks have been partitioned and formatted, select option 3. Note: If the disk is partitioned and formatted using keystroke files, this menu does not appear. Refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide for details about keystroke files. You must partition and format the drives before beginning a CID installation. Although PC DOS automatically creates one partition and formats the drive in an attended install, it is not possible in a CID install. 3. The CDM Pristine Client Agent window prompts the user for the client name and server name, if not already specified on the seed diskette. Type in the two names. The names are stored in \ANXPRST\IBMNVDM2.INI on the seed diskette. 4. The CDM Agent pop-up panel appears, indicating that the agent has successfully started. 5. ANXDXCPY is loaded to a virtual RAM drive, which is determined by the physical and logical drives on the system. 6. The CDM agent prompts you to remove the seed diskette from the client. Press Enter after removing the seed diskette to proceed with the installation. 7. The PC DOS 6.1 Setup screen appears with the yellow "progress bar." 8. At completion of PC DOS installation, the CDM Agent panel reappears. 9. LAN Support Program installation commences, but no progress indicator is displayed. The CDM Agent panel remains on the screen. LAN Support Program installation proceeds fairly quickly. 10. The CC Client Installation panel appears on the screen with a progress indication scale. 11. At completion of the CC client installation, the CDM Agent panel reappears. 12. The client machine reboots at least twice. 13. The IBM DOS Shell or the C: prompt appears. Installation is complete. ΓòÉΓòÉΓòÉ 5.5. Alternate Procedures ΓòÉΓòÉΓòÉ This section describes alternate procedures if you are using a 5-1/2 inch, 1.2 MB seed diskette or if you do not have a native DOS machine nearby for running the DOSDISK program. ΓòÉΓòÉΓòÉ 5.5.1. Using 5-1/4 Inch Diskettes ΓòÉΓòÉΓòÉ If you are using a 5-1/4 inch, 1.2 MB diskette for creating the seed diskette, you first need to create a compressed diskette. To create a compressed seed diskette, follow these steps: 1. From an OS/2 window, prepare the 5-1/4 inch, 1.2 MB diskette by running the SuperStor (SSTOR) program. Answer No to the universal data exchange (UDE) question that appears. This compresses the volume of the diskette. 2. Shrink the compressed volume by running the SSUTIL program. You need to shrink the volume so that all of the system files can be copied. You should use 250 KB. 3. Run the SYS program on the drive that SSTOR gives the uncompressed part of the diskette (for example, G:). 4. Copy DBLSPACE.BIN to that drive. 5. Expand the compressed volume by running the SSUTIL program. The program displays the maximum amount that can be expanded. Use a size just under the maximum amount (for example, use 105 KB if the maximum is 110 KB). This ensures you the largest compression volume possible. 6. Follow the procedure in Creating the Seed Diskette to create a 3-1/2 inch, 1.44 MB seed diskette. 7. From a native DOS machine (or from a code server with a native DOS window) with PC DOS 6.1 and SSTOR installed, use the XCOPY command to copy the 3-1/2 inch, 1.44 MB diskette files into a temporary directory. 8. Use the XCOPY command to copy all of the temporary directory files onto the compressed, 5-1/4 inch, 1.2 MB diskette. 9. Proceed with Installing Code at the Pristine Client. ΓòÉΓòÉΓòÉ 5.5.2. Running DOSDISK from the Code Server ΓòÉΓòÉΓòÉ If you do not have a native DOS machine nearby, you can invoke the DOSDISK command from your code server by following these steps: 1. Select the DOS Window (or DOS Full Screen) icon. 2. Create a copy of the icon and rename it to "Native DOS Window," for example. 3. Select the new icon. 4. Click once on the new icon with mouse button 2. Select "Open" and then "Settings." 5. Select the Session page. 6. Select DOS Settings. 7. Select DOS_VERSION. 8. Add these programs to the Value box: FORMAT.COM,6,0,255 DOSDISK.COM,6,0,255 ATTRIB.EXE,6,0,255 9. Select Save. 10. Double-click the new icon. 11. Switch to the image directory in which the PC DOS 6.1 CID-enabled code is installed. 12. Proceed with step Creating the Seed Diskette. ΓòÉΓòÉΓòÉ 5.6. Sample Response Files ΓòÉΓòÉΓòÉ This section shows sample response files for CID enablement of PC DOS, LAN Support Program, and NetView DM/2. For more details about response files, refer to the appendixes in this book and to the README files on the product diskettes. ΓòÉΓòÉΓòÉ 5.6.1. PC DOS (DOS.RSP) ΓòÉΓòÉΓòÉ CountryCode = 18 CountryKeyboard = 19 TargetPath = C:\DOS61 PreviousDOSPath = C:\DOS5 ExitIfCompression = N ErrorLogFile = C:\DOSERR.LOG HistoryLogFile = C:\DOSHIS.LOG ΓòÉΓòÉΓòÉ 5.6.2. LAN Support Program (LSP.RSP) ΓòÉΓòÉΓòÉ INST_SECTION = ( MigrateControlFiles = 0 TargetPath = C:\LSP ) PROT_SECTION = ( DriverName = DXMC0MOD$ LSP_Primary ) PROT_SECTION = ( DriverName = DXMT0MOD$ S = 16 C = 14 ES = 2 EST = 2 PBA = 0 LSP_Primary ) ΓòÉΓòÉΓòÉ 5.6.3. NetView DM/2 (CIDCLT2.RSP) ΓòÉΓòÉΓòÉ ServerName = SERVER1 ClientName = CIDCLT2 Note: You can select other optional parameters for NetView DM/2. Refer to NetView Distribution Manager/2 Installation and Customization Guide for more information. ΓòÉΓòÉΓòÉ 5.7. Sample Change File Profiles ΓòÉΓòÉΓòÉ This section shows sample change file profiles for CID enablement of PC DOS, LAN Support Program, and NetView DM/2. It also shows a sample change file profile for ANXDXCPY. For more details about profiles, refer to NetView DM/2 Change Distribution Manager User's Guide Version 2.0. ΓòÉΓòÉΓòÉ 5.7.1. ANXDXCPY ΓòÉΓòÉΓòÉ TargetDir = "C:\" Section Catalog Begin ObjectType = SOFTWARE GlobalName = ANXDXCPY.EXE.REF.1 Description = 'ANXDXCPY command' End Section Install Begin Program = ANXDXCPY.EXE End ΓòÉΓòÉΓòÉ 5.7.2. PC DOS ΓòÉΓòÉΓòÉ TargetDir = "C:\" CompNameLen = 2 Section Catalog Begin ObjectType = SOFTWARE GlobalName = DOS.61.PRODUCT.REF.1 Description = 'PC DOS 6.1 files' End Section Install Begin Program = $(SourceDir)\USETUP.COM Parms = "/R:$(ResponseFile) /L1:$(LogFile1)" SourceDir = SA:\CID\IMG\DOS ResponseFile = SA:\CID\RSP\DOS\DOS.RSP LogFile1 = SA:\CID\LOG\DOS\$(WorkStatName).LOG End ΓòÉΓòÉΓòÉ 5.7.3. LAN Support Program ΓòÉΓòÉΓòÉ TargetDir = "C:\" CompNameLen = 2 Section Catalog Begin ObjectType = SOFTWARE GlobalName = LSP.135.PRODUCT.REF.1 Description = 'LAN Support Program 1.35 files' End Section Install Begin Program = $(SourceDir)\DXMAID.EXE Parms = "/S:$(SourceDir) /TU:$(TargetDir) /R:$(ResponseFile) /L1:$(LogFile1)" SourceDir = SA:\CID\IMG\LSP ResponseFile = SA:\CID\RSP\LSP\LSP.RSP LogFile1 = SA:\CID\LOG\LSP\$(WorkStatName).LOG End ΓòÉΓòÉΓòÉ 5.7.4. NetView DM/2 ΓòÉΓòÉΓòÉ TargetDir = "C:\" CompNameLen = 2 Section Catalog Begin ObjectType = SOFTWARE GlobalName = NVDM2CLI.20.PRODUCT.REF.1 Description = 'NetView DM/2 2.0 files' End Section Install Begin Program = $(SourceDir)\NVDMIDOS.EXE Parms = "/B:C /S:$(SourceDir) /T:$(TargetDir) /R:$(ResponseFile) /L:$(LogFile1)" SourceDir = SA:\CID\IMG\NVDM2 ResponseFile = SA:\CID\RSP\NVDM2\$(WorkStatName).RSP LogFile1 = SA:\CID\LOG\NVDM2\$(WorkStatName).LOG End ΓòÉΓòÉΓòÉ 6. Migration of CID-Enabled Clients ΓòÉΓòÉΓòÉ This chapter describes the: o Transfer of diskette images to the NetView DM/2 server in preparation for a CID install of PC DOS, LAN Support Program, and NetView DM/2 client code o Creation of the seed diskette for the transfer of minimal PC DOS, LAN Support Program, and NetView DM/2 code to machines without NetView DM/2 already installed o Installation of PC DOS, LAN Support Program, and NetView DM/2 on the client The following procedures assume that NetView DM/2 is already installed at the server site. These scenarios assume that the client has earlier versions of PC DOS and LAN Support Program already installed (for example, PC DOS 5.02 and LAN Support Program 1.31). ΓòÉΓòÉΓòÉ 6.1. Before You Begin ΓòÉΓòÉΓòÉ You will need the following items before migrating code on a DOS client: o PC DOS 6.1 diskettes (including the PC DOS CID diskette) o LAN Support Program 1.35 diskette Note: If you have LAN Support Program 1.34 or lower, you will need CSD UR40349. o NetView DM/2 2.0 diskettes (including CSD XR20334 or higher) o A blank, 3-1/2 inch, 1.44 MB diskette Note: It is recommended that the blank diskette be at least 1.44 MB to enable storage of decompression code, an NDIS MAC driver, and the product code. If you are using a 5-1/4 inch, 1.2 MB diskette for the seed diskette, see Alternate Procedures. Note: If the DOS client has multiple named sections in the CONFIG.SYS file, refer to the note on page CID Process for DOS before installing the product code. ΓòÉΓòÉΓòÉ 6.2. Transferring Diskette Images to the Server ΓòÉΓòÉΓòÉ 1. Transfer the diskette images to the server's hard drive following the procedures outlined in the README file (located on one of the product diskettes) or in the product documentation. The directory structure of the diskette images on the server's hard drive is critical because the install sequence executing at the client will anticipate the predetermined format. See CID Directory Structure for more details. o To copy the PC DOS 6.1 CID-enabled code to the server: - Get the PC DOS 6.1 package and do an admin install (SETUP /A) to a directory on the code server (for example, SA:\CID\IMG\DOS). If you plan on upgrading any machines that are using a disk compression program, you need to make sure that your package contains the compression function. Search for SSUNCOMP.EXE in the PC DOS 6.1 directory on the code server. Refer to the README.CID file for more details. - Copy the following files from the PC DOS CID diskette to the same directory as used in the previous step: USETUP.COM, USETUP1.OVL, USETUP.INI, SAMPLE.RSP, README.CID, DOSDISK.COM, and DOSDISK.INI. o To copy the LAN Support Program 1.35 CID-enabled code to the server: - Use the XCOPY command with the /S parameter to load LAN Support Program onto the code server. Note: The /S parameter on the XCOPY command is necessary because the LAN Support Program source diskette contains subdirectories. In the following example, assume that the LAN Support Program source diskette is in the A: drive and that the current drive is the code server drive: MD LSP XCOPY A: LSP /S The directory structure on the code server and the name of the directory to which the LAN Support Program source is copied is up to the administrator. For example, it might be SA:\CID\IMG\LSP. o To copy the NetView DM/2 2.0 CID-enabled code to the server: - Use the NVDMDCPY command to load NetView DM/2 onto the code server. With NetView DM/2 diskette 13 in the A: drive, enter the NVDMDCPY command. For example, you might type: NVDMDCPY /S:A: /T:C:\CID\IMG\NVDM2 2. Call up the sample product response files (a .RSP file located on one of the product diskettes) using an ASCII text editor. The response file for a CID-enabled product, such as PC DOS or LAN Support Program, consists of a series of keywords preceded by an asterisk (*) or a semicolon (;). Note: NetView DM/2 uses a double slash (//) to indicate a comment. Each keyword is followed by a list of potential values and the default value for that keyword, if applicable. Using the sample response file as a model, customize the response files by deleting the comment tags and specifying the appropriate keyword for the desired action. Response files must be stored in the shared area on the code server. For example: SA:\CID\RSP\<ProductDirectory>. See Sample Response Files and the appendixes for examples of response files. 3. Create a change file profile using Change Distribution Manager (CDM) dialogs or (if the CDM BUILD function is to be used) an ASCII editor. The profile specifies: o CDM-Catalog information identifying the type and global name of the object to be cataloged o File specification information providing the local names of the files that are to be copied to the client during the installation o Installation information specifying: - The install program to be run at the client machine - Any parameters needed - The name of the response file A profile must be created and cataloged for each product to be installed. See Sample Change File Profiles for examples of change file profiles. For more details about profiles, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. Note: Some CID-enabled products, such as LAN NetView Agent for DOS, require that the current directory on the client be set to the directory where the code images are stored when installing code. This is not the case for CID installations. To enable a CID installation to complete successfully, use CDM-Catalog dialogs or edit the change file profile to specify the working directory (for example, WorkingDir = SA:\CID\LNV\IMG). 4. Invoke the NetView DM/2 BUILD function to create a change file for the install procedure. This change file object must be located in the FSDATA directory on the code server. 5. The resulting change file object is available in the CDM-Catalog awaiting the product install request. ΓòÉΓòÉΓòÉ 6.3. Creating the Seed Diskette ΓòÉΓòÉΓòÉ Having copied PC DOS, LAN Support Program, and NetView DM/2 into a directory structure on the server hard drive, you need to create a bootable seed diskette containing minimal code for each of the three products. The seed diskette should be at least 1.44 MB to enable the storage of decompression code (such as DBLSPACE.BIN and DBLSPACE.SYS), an NDIS MAC driver, and the PC DOS, LAN Support Program, and NetView DM/2 code. If you are using a 5-1/4 inch, 1.2 MB diskette for creating the seed diskette, see Alternate Procedures. Note: If the client has NetView DM/2 2.0 DOS Change Control Client (June 1993) installed, you do not need to create a seed diskette. Proceed with Installing Code at Clients with NetView DM/2. 1. Invoke the DOS command DOSDISK from a native DOS machine running PC DOS 4.0 or higher. If you do not have a native DOS machine nearby, see Alternate Procedures. a. Make sure that the DOSDISK.COM and DOSDISK.INI files are in the same directory on the code server as all of the other PC DOS 6.1 files. Note: The DOSDISK.INI file contains a list of the DOS files that are to be copied to the seed diskette. All of the files must be in the same directory as the DOSDISK program. This should be the PC DOS 6.1 directory on the code server. b. Insert the seed diskette into the diskette drive (for example, A:). c. Invoke the DOSDISK program. DOSDISK requires two parameters: the drive to create the diskette and the directory containing the version of DOS that is running on the machine. For example, the command might look like this: DOSDISK A: C:\DOS61. Note: DOSDISK allows a third parameter. This parameter enables the user to specify another file that contains a list of additional files to copy to the diskette. The lines in the file are appended to the COPY command and then executed. If only one file name is specified on the line, the file is copied to the destination diskette with the same name. If a second file name is specified on the line, then the file is copied to the destination diskette with that name. The format is as follows: C:\README.DOC G:\DOS61\AUTOEXEC.NEW AUTOEXEC.BAT d. When prompted to format another diskette, press N. e. You should see DOSDISK copy several files to the diskette. 2. Invoke the LAN Support Program command DXMAID from the code server. a. At the code server, invoke DXMAID from the subdirectory containing the LAN Support Program files and perform a normal attended install. The DXMAID command can be issued from an OS/2 or DOS command prompt in OS/2 2.0 or higher, or from a DOS command prompt in OS/2 1.3. b. On the Setup screen, provide the following information: Are you updating an existing configuration? NO Do you have driver diskettes? YES (if using NDIS) Target for LSP: A:\ (or appropriate drive and path) CONFIG.SYS to update: A:\ (or same drive as above) AUTOEXEC.BAT to update: A:\ (or same drive as above) c. On the Process Driver Diskette screen (if using NDIS), provide the drive and path where the NDIS MAC driver files are located for the adapter that this seed diskette is intended to support. Note: A seed diskette can support only one adapter interface driver. d. You should see DXMAID copy several files to the diskette. 3. Invoke the NetView DM/2 command NVDMBDSK from an OS/2 window on the code server. a. At the code server, invoke the NVDMBDSK command. CDM-Catalog Boot Diskette Update Panel appears. CDM-Catalog Boot Diskette Update Panel b. From the Boot Diskette Update window, you can specify both server and client names. However, if a client name is given at this point, then one diskette must be made for each client workstation, since each client must be given a unique name. The more efficient approach for larger LANs would be to give only the server name during seed diskette creation and specify the client name during client workstation reboot. c. NetView DM/2 updates the DOS CONFIG.SYS file to reflect its install parameters. d. The AUTOEXEC.BAT and CONFIG.SYS files are updated with the NetView DM/2 equivalent for correct execution of the seed diskette at the client workstation. At this point, the seed diskette has been created and can be distributed to client workstations. You might want to test the diskette on a workstation to make sure that either the IBM DOS 6.1 Startup Menu or the CDM Agent pop-up panel appears. ΓòÉΓòÉΓòÉ 6.4. Installing Code at Clients without NetView DM/2 ΓòÉΓòÉΓòÉ Having copied the diskette images to the server and created a seed diskette, you can proceed with the installation of PC DOS, LAN Support Program, and NetView DM/2. Note: If the DOS client has NetView DM/2 2.0 DOS CC Client (June 1993) installed, go to Installing Code at Clients with NetView DM/2. At the code server: 1. Check to make sure that the client is active at the server by using CDM dialogs or by typing CDM LISTWS. Note: This command lists the status of all client workstations. 2. From the CDM-Catalog main panel, select the objects representing the products to be installed: PC DOS, LAN Support Program, and NetView DM/2 (see CDM-Catalog Main Panel). In addition, a fourth object, ANXDXCPY, must be selected since it is a prerequisite for installs on clients without NetView DM/2. The ANXDXCPY object is built from a change file profile calling the ANXDXCPY.EXE program from NetView DM/2. CDM-Catalog Main Panel For more information about CDM-Catalog, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. 3. Select Install... from the "Selected" pull-down menu. CDM-Catalog Install Panel appears. CDM-Catalog Install Panel 4. From the Install panel, click on Order... to select the order in which the objects are to be installed. In this installation, ANXDXCPY must be the first object sent to the client. The product installation sequence is PC DOS, LAN Support Program, and then NetView DM/2. To return to the Install panel, click on OK. CDM-Catalog Install Order Panel 5. From the Install panel, select the names of the clients that are to receive the code. Your initial tests should probably be directed toward a single client. 6. Click on Options.... From the Options panel, click the Install as a coreq group box. Then, click on Set. CDM-Catalog Options Panel 7. From the Install panel, click on Install to execute the INSTALL command immediately. If you want to schedule the install for later execution, click on Schedule.... At the DOS client: 1. Boot the seed diskette at the client workstation with the Ctrl-Alt-Del sequence or by powering on. 2. The IBM DOS 6.1 Startup Menu appears, offering three options: 1. NetView DM/2 Pristine Machine: Run FDISK 2. NetView DM/2 Pristine Machine: Format New Drives 3. NetView DM/2 Pristine Machine: Start Agent Select option 3. Note: This menu does not appear if you used keystroke files. Refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide for details about keystroke files. 3. The CDM Pristine Client Agent window prompts the user for the client name and server name, if not already specified on the seed diskette. Type in the two names. The names are stored in \ANXPRST\IBMNVDM2.INI on the seed diskette. 4. The CDM Agent pop-up panel appears, indicating that the agent has successfully started. 5. ANXDXCPY is loaded to a virtual RAM drive, which is determined by the physical and logical drives on the system. 6. The CDM agent prompts you to remove the seed diskette from the client. Press Enter after removing the seed diskette to proceed with the installation. 7. The PC DOS 6.1 Setup screen appears with the yellow "progress bar." 8. At completion of PC DOS installation, the CDM Agent panel reappears. 9. LAN Support Program installation commences, but no progress indicator is displayed. The CDM Agent panel remains on the screen. LAN Support Program installation proceeds fairly quickly. 10. The CC Client Installation panel appears on the screen with a progress indication scale. 11. At completion of the CC client installation, the CDM Agent panel reappears. 12. The client machine reboots at least twice. 13. The IBM DOS Shell or the C: prompt appears. Installation is complete. ΓòÉΓòÉΓòÉ 6.5. Installing Code at Clients with NetView DM/2 ΓòÉΓòÉΓòÉ This procedure should be used when NetView DM/2 2.0 DOS CC Client (June 1993) is already installed at the client. You do not need to create a seed diskette for this install procedure. Note: If the client has DOS 6.0 or higher and the June 1993 version of NetView DM/2 already installed, you must perform a manual, attended installation of NetView DM/2 2.0 (with CSD XR20334 or higher) at the client. Having copied the diskette images to the server, you can proceed with the installation of NetView DM/2, PC DOS, and LAN Support Program. This procedure requires two separate install requests: first to install NetView DM/2, and second to perform a chained install of PC DOS and LAN Support Program. At the code server: 1. Check to make sure that the client is active at the server by using CDM dialogs or by typing CDM LISTWS. Note: This command lists the status of all client workstations. 2. From the CDM-Catalog main panel, select the object representing NetView DM/2 (see CDM-Catalog Main Panel). For more information about CDM-Catalog, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. CDM-Catalog Main Panel 3. Select Install... from the "Selected" pull-down menu. CDM-Catalog Install Panel appears. CDM-Catalog Install Panel 4. From the Install panel, select the names of the clients that are to receive the code. Your initial tests should probably be directed toward a single client. 5. Click on Install to execute the INSTALL command immediately. If you want to schedule the install for later execution, click on Schedule.... At the DOS client: 1. A NetView DM/2 message appears on the screen, asking if you want to ACCEPT, RESUME, or DEFER the install request. Press F1 to accept the install request. If no one is present at the client machine, the install will proceed after a predetermined amount of time. 2. The CDM Agent pop-up panel appears on the screen. 3. The client machine reboots twice. 4. The CDM Agent panel reappears. 5. The CC Client Installation panel appears on the screen with a progress indication scale. 6. At completion of the CC client installation, the CDM Agent panel reappears. 7. The client machine reboots. 8. The IBM DOS Shell or the C: prompt appears. At the code server: 1. Check to make sure that the client is active at the server by using CDM dialogs or by typing CDM LISTWS. Note: This command lists the status of all client workstations. 2. From the CDM-Catalog main panel, select the objects representing the products to be installed: PC DOS and LAN Support Program (see CDM-Catalog Main Panel). CDM-Catalog Main Panel 3. Select Install... from the "Selected" pull-down menu. CDM-Catalog Install Panel appears. CDM-Catalog Install Panel 4. From the Install panel, click on Order... to select the order in which the objects are to be installed. The product installation sequence is PC DOS and then LAN Support Program. To return to the Install panel, click on OK. CDM-Catalog Install Order Panel 5. From the Install panel, select the names of the clients that are to receive the code. Your initial tests should probably be directed toward a single client. 6. Click on Options.... From the Options panel, click the Install as a coreq group box. Then, click on Set. CDM-Catalog Options Panel 7. From the Install panel, click on Install to execute the INSTALL command immediately. If you want to schedule the install for later execution, click on Schedule.... At the DOS client: 1. A NetView DM/2 message appears on the screen, asking if you want to ACCEPT, RESUME, or DEFER the install request. Press F1 to accept the install request. If no one is present at the client machine, the install will proceed after a predetermined amount of time. 2. The CDM Agent pop-up panel appears on the screen. 3. The PC DOS 6.1 Setup screen appears with the yellow "progress bar." 4. At completion of PC DOS installation, the CDM Agent panel reappears. 5. LAN Support Program installation commences, but no progress indicator is displayed. The CDM Agent panel remains on the screen. LAN Support Program installation proceeds fairly quickly. 6. The client machine reboots at least twice. 7. The IBM DOS Shell or the C: prompt appears. Installation is complete. ΓòÉΓòÉΓòÉ 7. DOS Application Installation at CID-Enabled Clients ΓòÉΓòÉΓòÉ This chapter describes the installation of non-CID-enabled DOS applications on the client. Note: Check individual applications to see if they are CID-enabled. The following procedure assumes that NetView DM/2 is already installed at the server site and that the client has PC DOS, LAN Support Program, and NetView DM/2 already installed. This scenario uses WordPerfect** 6.0 for DOS as the non-CID-enabled DOS application. WordPerfect installation in this scenario is accomplished by replication. Replication is the most effective way to install an application on a large number of workstations when more efficient methods (such as CID-enabled install programs) are unavailable. However, if a significant number of client workstations require unique application configurations, then manual installation may be necessary. This scenario describes application installation using two NetView DM/2 utilities: the DiskCamera program (NVDMDCAM.EXE) and the Client Update program (NVDMUPD.EXE). For more information about these utilities, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. ΓòÉΓòÉΓòÉ 7.1. Before You Begin ΓòÉΓòÉΓòÉ You will need the shipped product diskettes of the DOS application before installing it at a CID-enabled DOS client. Note: If the DOS client has multiple named sections in the CONFIG.SYS file, refer to the note on page CID Process for DOS before installing the product code. ΓòÉΓòÉΓòÉ 7.2. Installing Code at the CID-Enabled Client ΓòÉΓòÉΓòÉ At the code server: 1. Start PC DOS from the code server. 2. Run DiskCamera against the WordPerfect installation program by inserting WordPerfect installation diskette 1 in the diskette drive (for example, A:) and typing: NVDMDCAM A:\INSTALL C: where A:\INSTALL is the WordPerfect installation program (INSTALL.EXE) and C: is the target drive for installation. The target drive parameter is used by DiskCamera to specify the drive for which to record changes. If additional parameters are required for the installation program, refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. 3. DiskCamera runs the setup program that installs WordPerfect. When the setup program finishes, DiskCamera resumes control of the workstation and builds two disk change summary files under the NVDMTMP directory: NVDMUPD.PRO and NVDMUPD.MOD. The Client Update file (NVDMUPD.PRO) provides information for the change file profile. NVDMUPD.PRO might contain the following information: TargetDir = C:\ Section FileSpecList Begin \WP60\*.* /is \WPC60DOS\*.* /is \WPDOCS\*.* /is \BTFONTS\*.* /is \PSFONTS\WPBD____.WA0 \PSFONTS\WPCE08N_.WA0 \PSFONTS\WPCO03N_.WA0 \PSFONTS\WPCO08N_.WA0 \PSFONTS\WPCOB___.WA0 \PSFONTS\WPCO____.WA0 \PSFONTS\WPCS____.WA0 \PSFONTS\WPHV02N_.WA0 \PSFONTS\WPHV04N_.WA0 \PSFONTS\WPHV05NA.WA0 \PSFONTS\WPHV06NA.WA0 \PSFONTS\WPHV07N_.WA0 \PSFONTS\WPHVB___.WA0 \PSFONTS\WPHV____.WA0 \PSFONTS\WPRO01NA.WA0 \PSFONTS\WPROBI__.WA0 \PSFONTS\WPROB___.WA0 \PSFONTS\WPROI___.WA0 \PSFONTS\WPROXXN_.WA0 \PSFONTS\WPRO____.WA0 End The modification file (NVDMUPD.MOD) serves as input to the Client Update program (NVDMUPD.EXE), which manages updates to the workstation system files. NVDMUPD.MOD might contain the following information: [CONFIG.SYS] InsertCommand(FILES,,TOP) FILES=30 [AUTOEXEC.BAT] InsertToken(SET,PATH,RIGHT) C:\WP60; 4. Do not restart the workstation if asked by the installation program. This prevents any information from being lost before it is correctly stored by DiskCamera. Wait until DiskCamera displays a message indicating that processing has completed. 5. You can now modify the Client Update file and the modification file, if necessary. For example, the modification file can be edited to incorporate other tasks. In the following example, statements were added to delete the autostart of the IBM DOS Shell and to add the autostart of WordPerfect. [CONFIG.SYS] InsertCommand(FILES,,TOP) FILES=30 [AUTOEXEC.BAT] InsertToken(SET,PATH,RIGHT) C:\WP60; DeleteLine() C:\DOS\DOSSHELL.EXE AddLine(BOTTOM) WP Note: Ensure that all manual changes to NVDMUPD.MOD are correct. If the syntax is incorrect in this file, the installation will end immediately. 6. Start the OS/2 operating system at the code server and ensure that CDM is active by typing this command: CDM STATUS. If it is not active, issue this command to activate CDM: CDM START. 7. Create a change file profile for WordPerfect. Note that the FileSpecList section contains the information from NVDMUPD.PRO. For example, the profile might look as follows: TargetDir = "C:\" Section Catalog Begin ObjectType = SOFTWARE GlobalName = WP.60.PRODUCT.REF.1 Description = 'WordPerfect 6.0 for DOS files' End Section Install Begin Program = NVDMUPD.EXE Parms = $(TargetDir)NVDMTMP\NVDMUPD.MOD SourceDir = SA:\APPS\WP60FILE WorkingDir = C:\IBMNVDD2\BIN End Section FileSpecList Begin \NVDMTMP\NVDMUPD.MOD \WP60\*.* /is \WPC60DOS\*.* /is \WPDOCS\*.* /is \BTFONTS\*.* /is \PSFONTS\WPBD____.WA0 \PSFONTS\WPCE08N_.WA0 \PSFONTS\WPCO03N_.WA0 \PSFONTS\WPCO08N_.WA0 \PSFONTS\WPCOB___.WA0 \PSFONTS\WPCO____.WA0 \PSFONTS\WPCS____.WA0 \PSFONTS\WPHV02N_.WA0 \PSFONTS\WPHV04N_.WA0 \PSFONTS\WPHV05NA.WA0 \PSFONTS\WPHV06NA.WA0 \PSFONTS\WPHV07N_.WA0 \PSFONTS\WPHVB___.WA0 \PSFONTS\WPHV____.WA0 \PSFONTS\WPRO01NA.WA0 \PSFONTS\WPROBI__.WA0 \PSFONTS\WPROB___.WA0 \PSFONTS\WPROI___.WA0 \PSFONTS\WPROXXN_.WA0 \PSFONTS\WPRO____.WA0 End Note: When installing products using replication, the product files are not required to be in the shared area on the code server. Some CID-enabled products, such as LAN NetView Agent for DOS, require that the current directory on the client be set to the directory where the code images are stored when installing code. This is not the case for CID installations. To enable a CID installation to complete successfully, use CDM-Catalog dialogs or edit the change file profile to specify the working directory (for example, WorkingDir = SA:\CID\LNV\IMG). 8. If you are using CDM commands, build the change file object WP60.PKG by typing: CDM BUILD D:\PROFILES\NVDMUPD.PRO FS:\WP60.PKG /S:SA:\APPS\WP60FILE You can also use the CDM dialogs to build the change file object. Refer to NetView Distribution Manager/2 Change Distribution Manager User's Guide. 9. Install the change file object by using CDM dialogs or by typing: CDM INSTALL WP.60.PRODUCT.REF.1 /WS:<ClientName> where ClientName is the name of the client machine on which the application is to be installed. At the DOS client: 1. A NetView DM/2 message appears on the screen, asking if you want to ACCEPT, RESUME, or DEFER the install request. Press F1 to accept the install request. If no one is present at the client machine, the install will proceed after a predetermined amount of time. 2. The client machine reboots twice. 3. The CDM Agent pop-up panel appears on the screen. 4. The WordPerfect files are being copied to the client machine, but there is no progress indicator. The CDM Agent panel remains on the screen. 5. The client machine reboots. 6. The IBM DOS Shell, the C: prompt, or WordPerfect 6.0 for DOS appears. Note: Messages are logged in the message log defined in the IBMNVDM2.INI file at the client workstation. The default is \IBMNVDD2\MESSAGE.DAT. Installation is complete. ΓòÉΓòÉΓòÉ 8. PC DOS Response File and Command Line Parameters ΓòÉΓòÉΓòÉ This appendix documents the response file keywords and command line parameters that have been implemented to install PC DOS using the CID process. It also lists the return codes. ΓòÉΓòÉΓòÉ 8.1. PC DOS Response File ΓòÉΓòÉΓòÉ PC DOS Response File The PC DOS response file allows PC DOS to be installed without user intervention. This file defines all the responses which would be entered by a person during an attended installation. There can be a single response file or multiple response files that can be nested using the Include keyword. For detailed information about the functions related to the keywords and their values, see the SAMPLE.RSP file on the PC DOS CID diskette. Syntax The PC DOS response file is a text file containing keywords and comments. The general format is as follows: * This is a comment Keyword = 10 ; Another comment AnotherKeyword = some string of characters Comments begin with an asterisk (*) or semicolon (;) as the first non-blank character on the line. All text up to and including the new line character are part of the comment. Comments are not allowed on the same line as a keyword. Only one keyword is allowed per line. The keyword must be the first non-blank character on the line. Following the keyword is an equal sign (=), which is followed by either a number or a string of characters. Blanks can be inserted between the keyword, equal sign, and number or character string. The case of the keyword is not significant. For example, all of these are the same keyword: Include, INCLUDE, and InClude. If there are multiple occurrences of a keyword in the response file when only one is valid, then the value of the last keyword is used. The response file is processed from beginning to end, so last refers to the keyword closest to the end of the file. Keywords AntiVirus=value Specifies whether or not to install IBM AntiVirus/DOS. Valid values: N Do not install IBM AntiVirus/DOS (default) Y Install IBM AntiVirus/DOS AntiVirusforWindows=value Specifies whether or not to install IBM AntiVirus/DOS for Windows. Valid values: N Do not install IBM AntiVirus/DOS for Windows (default) Y Install IBM AntiVirus/DOS for Windows Compression=value Specifies whether or not to copy the SuperStor/DS files to the target drive. Valid values: N Do not copy the SuperStor/DS files (default) Y Copy the SuperStor/DS files CountryCode=value Specifies which country support should be installed. This causes all country information to be installed. Valid values: 1 Albania 2 Australia 3 Belgium 4 Bosnia/Herzegovina 5 Brazil 6 Bulgaria 7 Canada (French) 8 Croatia 9 Czechoslovakia 10 Denmark 11 Finland 12 France 13 Germany 14 Greece 15 Hungary 16 Iceland 17 International English 18 Italy 19 Japan 20 Latin America 21 Macedonian FYR 22 Netherlands 23 Norway 24 Poland 25 Portugal 26 Romania 27 Serbia/Montenegro 28 Slovakia 29 Slovenia 30 Spain 31 Sweden 32 Switzerland 33 Turkey 34 United Kingdom 35 United States of America (default) 36 Yugoslavia CountryKeyboard=value Specifies which country keyboard should be installed. This causes all keyboard information to be installed. Valid values: 1 Albanian 2 Australian 3 Belgian 4 Bosnian 5 Brazilian 6 Bulgarian 7 Canadian French 8 Croatia 9 Czech 10 Danish 11 Dutch 12 Finnish 13 French (120) 14 French (189) 15 German 16 Greek 17 Hungarian 18 Icelandic 19 Italian (141) 20 Italian (142) 21 Japanese (English) 22 Latin American 23 Macedonian FYR 24 Norwegian 25 Polish 26 Portuguese 27 Romanian 28 Serbian 29 Slovak 30 Slovenian 31 Spanish 32 Swedish 33 Swiss (French) 34 Swiss (German) 35 Turkish (179) 36 Turkish (440) 37 United Kingdom English 38 United States Default (default) 39 United States English 40 Yugoslavian CPBackup=value Specifies whether or not to install Central Point Backup. Valid values: N Do not install Central Point Backup (default) Y Install Central Point Backup CPBackupforWindows=value Specifies whether or not to install Central Point Backup for Windows. Valid values: N Do not install Central Point Backup for Windows (default) Y Install Central Point Backup for Windows CPUndeleteforWindows=value Specifies whether or not to install Central Point Undelete for Windows. Valid values: N Do not install Central Point Undelete for Windows (default) Y Install Central Point Undelete for Windows DOSSHELL=value Specifies whether or not to install IBM DOS Shell. Valid values: N Do not install IBM DOS Shell Y Install IBM DOS Shell (default) ErrorLogFile=value Specifies the file name (including drive and path, if required) where USETUP will log any errors and warnings that occur. Valid value: Any valid path and file name. Default = do not create an error log file. ExitIfCompression=value Specifies if the install program should exit when disk compression is detected on the target machine. Valid values: N Do not exit when disk compression is detected (default) Y Exit when disk compression is detected HistoryLogFile=value Specifies the file name (including drive and path, if required) where USETUP will log history and status messages. Valid value: Any valid path and file name. Default = do not create a history log file. Include=value Specifies another response file to process along with the current one. There can be multiple occurrences of this keyword. Valid value: Any valid path and file name. ISOFonts=value Specifies whether or not to install ISO font support. Valid values: N Do not install ISO fonts (default) Y Install ISO fonts PCMCIA=value Specifies whether or not to install Phoenix PCMCIA support. Valid values: N Do not install PCMCIA support (default) Y Install PCMCIA support PenDOS=value Specifies whether or not to install IBM PenDOS support. Valid values: N Do not install IBM PenDOS support (default) Y Install IBM PenDOS support PenDOSDriver=value Specifies the file name of the PenDOS driver to be installed if PenDOS=Y is specified. If PenDOS=Y is specified and PenDOSDriver is not specified, PenDOS will not be installed. Valid values: 1 AceCAD Acecat Opaque . 2 CalComp DisplayPad 3 Dauphin 4 Digitizing Pad Emulation via Mouse 5 IBM ThinkPad 710T 6 IBM ThinkPad 700T 7 Kurta XTG Opaque 8 NCR 3125 9 NCR 3130 10 Samsung PenMaster 11 Seiko D-SCAN 12 Wacom 510C Opaque 13 Wacom HD648A 14 Wacom PL100V PreviousDOSPath=value Specifies the drive and directory of the previous version of PC DOS. This path is used to access the files containing existing PC DOS configuration information. The install will migrate any configuration files that are found. Valid value: Drive and path. Default = directory where a previous version of PC DOS is installed. ProgressIndication=value Specifies whether or not to display screens during installation. Disabling will cause a blank screen to be displayed while the install is operating in an unattended environment. Valid values: N Do not display screens during installation Y Display screens during installation (default) TargetPath=value Specifies the target path where DOS is to be installed. If a drive other than C: is specified, the files necessary to boot the machine will still be installed in C:. Valid value: Drive and path. Default = directory where PC DOS files are found. WindowsPath=value Specifies the drive and directory where Windows files are located. Valid value: Drive and path. Default = directory where Windows files are found. Example Following is a sample PC DOS response file using mostly default values. If you want to use default values, you would not have to code them in the response file. This example is shown to give you a better understanding of the coding of the file. * PC DOS response file AntiVirus = N AntiVirusforWindows = N Compression = N CountryCode = 35 CountryKeyboard = 38 CPBackup = N CPBackupforWindows = N CPUndeleteforWindows = N DOSSHELL = Y ErrorLogFile = D:\LOGS\DOSERR.LOG ExitIfCompression = N HistoryLogFile = D:\LOGS\DOSHIS.LOG Include = H:\RESPFILE\GLOBAL.RSP ISOFonts = N PCMCIA = N PenDOS = N PreviousDOSPath = C:\DOS5 ProgressIndication = Y TargetPath = C:\DOS61 ΓòÉΓòÉΓòÉ 8.2. Command Line Parameters ΓòÉΓòÉΓòÉ Command Line Parameters Several new command line parameters have been added to the PC DOS USETUP utility. The only required parameter is /R. Some of the parameters specify information that can also be included in the response file. The value specified on a command line parameter overrides any value set by a keyword in the response file. Parameters /R:X:\...\file.rsp Response file (required) This parameter specifies the drive, path, and file name of the response file to be used for this install. /R is required for an unattended install. /B Black and white mode This optional parameter causes USETUP to display all screens in monochrome mode. /E Tools only install This parameter causes USETUP to install only the selected optional tools. None of the standard PC DOS files or system files are copied to the target drive. /G:X:\...\... Include file path This parameter specifies the drive and path that will be searched for a response file specified by an Include keyword in the primary response file. /L1:X:\...\file.log Error log file This parameter specifies the drive, path, and file name of the error log file. /L2:X:\...\file.log History log file This parameter specifies the drive, path, and file name of the history log file. /P This parameter allows USETUP to install on a drive with less than three clusters per sector. /T:X:\...\... Target path This parameter specifies the drive and path where PC DOS should be installed on the workstation. /W This parameter causes USETUP to install Windows tools even though a valid copy of Windows 3.1 is not found on the system. /? This parameter causes help information for USETUP to be displayed. Example Following is a sample invocation of USETUP. This invocation uses the response file DOS.RSP found on the H:\CID\RSP\DOS directory. PC DOS is installed in the client's C:\DOS directory and error messages are logged in the DOSERR.LOG files in the H:\CID\LOG\DOS directory. No history log is created unless the HistoryLogFile keyword is specified in the DOS.RSP response file or in a response file which has been included in DOS.RSP using the Include keyword. USETUP /R:H:\CID\RSP\DOS\DOS.RSP /T:C:\DOS /L1:H:\CID\LOG\DOS\DOSERR.LOG ΓòÉΓòÉΓòÉ 8.3. Return Codes ΓòÉΓòÉΓòÉ Return Codes The PC DOS install program communicates information back to NetView DM/2 through 2-byte return codes. PC DOS returns the following return codes to NetView DM/2. 00 00 Explanation: Returned if the /? parameter is specified on the install invocation. 08 00 Explanation: Returned if the history or error file cannot be opened or created. 16 00 Explanation: Returned if an invalid command line parameter is specified or the response file is not found. 16 04 Explanation: Returned if the install is aborted. FE 00 Explanation: Returned on successful program termination. NetView DM/2 is instructed to reboot the machine just installed with PC DOS. FE 04 Explanation: Returned on successful program termination. Warning messages have been logged. NetView DM/2 is instructed to reboot the machine just installed with PC DOS. ΓòÉΓòÉΓòÉ 9. LAN Support Program Response File and Command Line Parameters ΓòÉΓòÉΓòÉ This appendix documents the response file keywords and command line parameters that have been implemented to install LAN Support Program in the DOS environment using the CID process. It also lists the return codes. ΓòÉΓòÉΓòÉ 9.1. LAN Support Program Response File ΓòÉΓòÉΓòÉ LAN Support Program Response File The LAN Support Program response file enables LAN Support Program to be installed without user intervention. This file defines all the responses which would be entered by a person during an attended installation. There can be a single response file or multiple response files that can be nested using the Include keyword. For detailed information about the functions related to the keywords and their values, refer to the READCID.001 (or READCID.ccc, where ccc is the DOS country code for other languages) file on CSD UR40349. Syntax The LAN Support Program response file is a text file containing keywords and comments. The general format is as follows: * This is a comment Keyword = 10 ; Another comment AnotherKeyword = some string of characters Comments begin with an asterisk (*) or semicolon (;) as the first non-blank character on the line. All text up to and including the new line character are part of the comment. Comments are not allowed on the same line as a keyword. Only one keyword is allowed per line. The keyword must be the first non-blank character on the line. Following the keyword is an equal sign (=), which is followed by either a number or a string of characters. Blanks can be inserted between the keyword, equal sign, and number or character string. The case of the keyword is not significant. For example, all of these are the same keyword: Include, INCLUDE, and InClude. If there are multiple occurrences of a keyword in the response file, then the value of the last keyword is used. The response file is processed from beginning to end, so last refers to the keyword closest to the end of the file. Keywords The LAN Support Program response file contains two sections plus two additional keywords which control the inclusion of other files during response file processing. The INST_SECTION is optional. It is used to specify control information used during the overall LAN Support Program installation. The INST_SECTION defines source and target paths along with migration and adapter check information. One PROT_SECTION is required for each NDIS or non-NDIS driver to be installed. The PROT_SECTION defines information specific to the driver. INST_SECTION AdapterCheck=value Specifies whether or not installed adapters should be checked. LAN Support Program installation checks only for shared RAM token-ring adapters, PC Network adapters, and a few Micro Channel* adapters. Checking for the following Micro Channel adapters is supported: o IBM FDDI adapter o IBM Ethernet adapter o SMC** Micro Channel Ethernet adapter o Ungermann-Bass** Micro Channel Ethernet adapter o 3Com** Micro Channel Ethernet adapter Additional information about supported adapters can be found in Local Area Network Support Program Version 1.33 User's Guide. If AdapterCheck is set to a non-zero value, then any NDIS MAC drivers specified in Bindings for LAN Support Program protocol drivers have precedence over installed adapters. Valid values: non-zero Check for installed adapters (default) 0 Do not check for installed adapters Note: This parameter should be set to 0 when creating a seed diskette. ControlFilePath=value Path where the source and target CONFIG.SYS and AUTOEXEC.BAT files are located. Valid values: Any valid path specification. Default = root directory of the drive specified in TargetPath. Note: For an attended installation, the maximum length of the argument to this parameter is six characters. DriverDiskPath=value Path where the MAC driver disks are installed. If DriverDiskPath is specified, then the same path is used as the source location for all files specified by PROT_SECTION keywords. Valid values: Any valid path specification. The path specification can be fully qualified or not. If the path specification is not fully qualified, then the current directory is searched for the specified path. If the specified path is not found in the current directory, then the path specified in SourcePath is searched for the path. If DriverDiskPath is not specified, then driver diskette processing is not done and the path specified by SourcePath is used as the source location of all files specified by PROT_SECTION keywords. MigrateControlFiles=value Specifies whether or not to use existing installed control files in configuring this installation of LAN Support Program. Valid values: non-zero Migrate existing control information to the LAN Support Program release being installed (default) 0 Do not migrate control information Remove=value Used to remove LAN Support Program from a target workstation using the CID process. The following must be considered for NDIS and non-NDIS drivers: o NDIS: TargetPath must be specified so that LAN Support Program installation can locate NIFs for any NDIS MAC drivers in the configuration. If the target system CONFIG.SYS contains statements for NDIS MAC drivers for which no NIFs are available, then, in addition to specifying a non-zero value for Remove, you must code a PROT_SECTION with the appropriate DriverFile. One PROT_SECTION is required for each NDIS MAC driver without a NIF in the existing configuration. Note: If the response file also contains one or more PROT_SECTIONkeywords with NDIS protocol drivers DXME0MOD.SYS or DXMJ0MOD.SYS, then the last Bindings keyword must be null for LAN Support Program to be removed from the target system. o Non-NDIS: If the target system CONFIG.SYS contains only non-NDIS LAN Support Program drivers (for example, DXMC0MOD.SYS or DXMT0MOD.SYS), then you only need to specify a non-zero value for Remove to remove LAN Support Program from the target system. Valid values: non-zero Remove LAN Support Program from the target system 0 Do not removed LAN Support Program from the target system Note: The Remove keyword should not be used in NetView DM/2 environments. SourcePath=value Specifies the path to the LAN Support Program source files, other than DXMAID.EXE and DXMAID.ccc. If DriverDiskPath is not specified, then the path specified by SourcePath is used as the source path for all files specified by PROT_SECTION keywords. Valid values: Any valid path specification. Default = path where DXMAID.EXE is located. The location of DXMAID.EXE and DXMAID.ccc is specified on the command line that invokes the program, either by a user or by the NetView DM/2 client. The drive and path information from the command line is available in a defined area from PC DOS for the invoked program to use. TargetPath=value Specifies the path where the LAN Support Program files (other than CONFIG.SYS and AUTOEXEC.BAT) are to be installed. Valid values: Any valid path specification. Default = C:\LSP if target system contains a hard drive, or A:\LSP if the target system does not contain a hard drive. Note: For an attended installation, the maximum length of the argument to this parameter is 20 characters. PROT_SECTION Following are the PROT_SECTION keywords used by LAN Support Program installation for all drivers. One PROT_SECTION is required for each driver. Any other parameter specified in the PROT_SECTION are treated as PROTOCOL.INI or CONFIG.SYS command line parameters for the particular driver being installed. See Local Area Network Support Program Version 1.33 User's Guide for information about additional parameters for LAN Support Program drivers. Refer to the adapter documentation for information about NDIS MAC driver parameters. Note: A response file should never contain a PROT_SECTION for DXMA0MOD.SYS, NETBIND.COM, or PROTMAN.DOS. These files are automatically added to the configuration as needed. DriverName=value Specifies the driver name for the adapter as described in the 3Com/Microsoft LAN Manager Network Driver Interface Specification. To select the appropriate value for your hardware for DriverName, use the following list of LAN Support Program drivers and their associated driver names: DRIVER DRIVERNAME DXME0MOD.SYS DXME0$ DXMJ0MOD.SYS NETBEUI$ DXMC0MOD.SYS DXMC0MOD$ DXMC1MOD.SYS DXMC1MOD$ DXMT0MOD.SYS DXMT0MOD$ DXMG0MOD.SYS DXMG0MOD$ DXMG1MOD.SYS DXMG1MOD$ DXMG2MOD.SYS DXMG2MOD$ Bindings=value Specifies the bindings statement for the protocol driver as described in the 3Com/Microsoft LAN Manager Network Driver Interface Specification. Bindings must be specified for all protocol drivers. If the protocol driver is a non-NDIS driver, then Bindings= with no value must be specified. Non-NDIS drivers are DXMC0MOD, DXMC1MOD, DXMG0MOD, DXMG1MOD, and DXMG2MOD. Bindings to the appropriate NDIS driver must be specified for DXME0MOD and DXMJ0MOD. Section_Name=value Specifies the bracketed module name within PROTOCOL.INI containing configuration information. The configuration information is used by the protocol manager and NETBIND to establish communication with the adapter. The Section_Name keyword performs two functions: 1. It is used to match with the target specified by the Bindings keyword in PROTOCOL.INI within the PROT_SECTION. 2. For NDIS_SNGL MAC drivers, it is used to distinguish between the first (primary) and second (alternate) sections of the PROTOCOL.INI file for that MAC driver. Note: For other types of MAC drivers, the DriverName keyword differs between the two sections, so the value specified on DriverName is used to distinguish between the two sections. The default component type is NDIS_SNGL. DriverFile=value Specifies the name of the driver to copy to the path specified by TargetPath and load into CONFIG.SYS. Note: The DriverFile keyword is not allowed for LAN Support Program drivers. This keyword is used only for NDIS MAC drivers for which no IBM format NIF is available. CopyFile=value Specifies ancillary files needed by the drivers, such as message files that should be copied to the LAN Support Program target directory. This keyword is used only for NDIS. The value is adapter-specific. NIF=value Specifies the Network Information File (NIF) for the section. This keyword is used only for NDIS MAC drivers. This parameter needs to be specified only when there are multiple NIFs present that use the same driver name. NIF is a useful keyword when configuring SMC adapters using SMCMAC.DOS (SMCMAC.DOS has three different NIFs which use the same DriverName). LSP_Primary=value Specifies whether this driver is added to the configuration for the primary (CCB 0) adapter. This keyword is valid only for non-NDIS LAN Support Program drivers: o DXMC0MOD.SYS o DXMC1MOD.SYS o DXMG0MOD.SYS o DXMG1MOD.SYS o DXMG2MOD.SYS o DXMT0MOD.SYS LSP_Primary needs to be specified for DXMCnMOD.SYS and DXMGnMOD.SYS only if the desired configuration does not reflect the installed LAN adapters. LAN Support Program installation can detect shared RAM token-ring and PC Network adapters. If LSP_Primary is not specified in the PROT_SECTION, then the driver parameters for the driver specified by DriverName on the target system are updated, but the driver is not added to the configuration. Valid values: non-zero Install this driver to the configuration for the primary (CCB 0) adapter. 0 Do not install this driver to the configuration. Remove this driver from the configuration for the primary (CCB 0) adapter if it has already been installed. (default) Note: 1. DXMT0MOD.SYS is a protocol stack module which supports one or more LAN Support Program drivers. Only one instance of LSP_Primary or LSP_Alternate needs to be specified to remove DXMT0MOD.SYS support from all adapters in the target system. 2. If the AdapterCheck keyword has a non-zero value and an adapter is present, then a driver is installed even if LSP_Primary = 0. LSP_Alternate=value Specifies whether this driver is added to the configuration for the alternate (CCB 1) adapter. This keyword is valid only for non-NDIS LAN Support Program drivers: o DXMC0MOD.SYS o DXMC1MOD.SYS o DXMG0MOD.SYS o DXMG1MOD.SYS o DXMG2MOD.SYS o DXMT0MOD.SYS If LSP_Alternate is not specified in the PROT_SECTION, then the driver parameters for the driver specified by DriverName on the target system are updated, but the driver is not added to the configuration. Valid values: non-zero Install this driver to the configuration for the alternate (CCB 1) adapter. 0 Do not install this driver to the configuration. Remove this driver from the configuration for the alternate (CCB 1) adapter if it has already been installed. (default) Note: 1. DXMT0MOD.SYS is a protocol stack module which supports one or more LAN Support Program drivers. Only one instance of LSP_Alternate or LSP_Primary needs to be specified to remove DXMT0MOD.SYS support from all adapters in the target system. 2. If the AdapterCheck keyword has a non-zero value and an adapter is present, then a driver is installed even if LSP_Alternate = 0. Other Response File Parameters In addition to the INST_SECTION and the PROT_SECTION, a LAN Support Program response file can contain two additional keywords. These keywords are used to control the inclusion of additional files during the response file processing. PINIFILE=value If the target system contains a PROTOCOL.INI file and the current configuration is being used to compute the new configuration (MigrateControlFiles=1), then the target system's PROTOCOL.INI is used during LAN Support Program installation. If a PROTOCOL.INI file does not exist on the target system, or MigrateControlFiles=0 is specified, then the PROTOCOL.INI file in the LAN Support Program source directory is used. PINIFILE allows you to specify an additional PROTOCOL.INI file to be used during LAN Support Program installation. The system PROTOCOL.INI is processed before the PINIFILE PROTOCOL.INI is processed. If the same parameter is in both files, however, then the one in the PINIFILE PROTOCOL.INI overrides the system PROTOCOL.INI. Bracketed module names and driver names in each PROTOCOL.INI file must match. For this reason, the user may need to specify that the existing configuration not be used (MigrateControlFiles=0) when an additional PROTOCOL.INI is used. Valid values: Any valid file specification. The file specification can be fully qualified or not. If the file specification is not fully qualified, then the current directory is searched for the specified file. If the specified file is not found in the current directory, then the path specified in SourcePath or on the /S command line parameter of DXMAID is searched for the file. Include=value Specifies another response file to process along with the current one. There can be multiple occurrences of this keyword. There is a limit of six nested response files. However, the sixth response file cannot contain a PINIFILE keyword. Processing of the response file is terminated if a file specified by Include cannot be found. Valid values: Any valid file specification. The file specification can be fully qualified or not. If the file specification is not fully qualified, then the current directory is searched for the specified file. If the specified file is not found in the current directory, then the path specified in the /G command line parameter of DXMAID is searched for the file. Examples This section lists sample response files for LAN Support Program. ΓòÉΓòÉΓòÉ 9.1.1. DXMC0MOD.SYS and DXMT0MOD.SYS, One Adapter ΓòÉΓòÉΓòÉ * ---------------------------------------------------------------------- * EXAMPLE1.RSP * This response file installs DXMC0MOD.SYS and DXMT0MOD.SYS. * CONFIG.SYS and AUTOEXEC.BAT will be placed in the root of the C drive. * INST_SECTION = ( ; Do not use the input configuration for LSP driver parameters MigrateControlFiles = 0 ; Do not check the LAN adapters installed AdapterCheck = 0 ; Define target location for LSP files TargetPath = c:\lsp135 ) ; Add 802.2 support for the shared RAM token ring adapter PROT_SECTION = ( DriverName = DXMC0MOD$ lsp_primary = 1 ; Uncomment the next line and change for your LAA. ; NetAddress = "400000121212" ; Uncomment the next line and change for ISA-bus to change ; Shared RAM addr. ; RAM = 0xD800 ; Uncomment the next line to turn off Early Token Release on 16MB. ; EarlyRelease = 1 ; Uncomment the next line and change to set minimum link stations. ; MinLink = 2 ; Uncomment the next line and change to set minimum SAPs. ; MinSAP = 12 ) ; Add NETBIOS driver to the configuration PROT_SECTION = ( DriverName = DXMT0MOD$ lsp_primary = 1 ; Set the parameters needed by DLR. c = 14 st = 14 s = 14 ; Set the parameters needed by PC3270. es = 2 est = 2 ; Set the parameter needed in memory manager ; or Windows* environments. cf = y ; Turn off piggy-backed acknowledgments. PBA = 0 ) *** End of Response file EXAMPLE1 ΓòÉΓòÉΓòÉ 9.1.2. DXMC0MOD.SYS and DXMT0MOD.SYS, Two Adapters ΓòÉΓòÉΓòÉ * ---------------------------------------------------------------------- * EXAMPLE2.RSP * This response file installs DXMC0MOD.SYS and DXMT0MOD.SYS, 2 adapters. * It is just to illustrate setting parameters for two adapters with non- * NDIS LSP drivers. * CONFIG.SYS and AUTOEXEC.BAT will be placed in the root of the C drive. * INST_SECTION = ( ; Do not use the input configuration for LSP driver parameters. MigrateControlFiles = 0 ; Do not check the LAN adapters installed. AdapterCheck = 0 ; Define target location for LSP files. TargetPath = c:\lsp135 ) ; Add 802.2 support for the shared RAM token ring adapter. PROT_SECTION = ( DriverName = DXMC0MOD$ ; Specify that two adapters will be supported. lsp_primary = 1 lsp_alternate = 1 ; Set some parameters for primary and for alternate. minlink = 2,4 ) ; Add NETBIOS driver to the configuration PROT_SECTION = ( DriverName = DXMT0MOD$ ; DXMT0MOD.SYS is automatically added for both adapters. lsp_primary = 1 ; Set some parameters for primary and for alternate. c = 14,12 st = 14, 12 s = 14, 12 ; Set the parameters needed by PC3270. es = 2 est = 2 ; Set the parameter needed in memory manager ; or Windows* environments. cf = y ; Turn off piggy-backed acknowledgments. PBA = 0 ) *** End of Response file EXAMPLE2 ΓòÉΓòÉΓòÉ 9.1.3. DXMJ0MOD.SYS and IBMTOK.DOS, One Adapter ΓòÉΓòÉΓòÉ * ---------------------------------------------------------------------- * EXAMPLE3.RSP * This response file installs IBMTOK.DOS and DXMJ0MOD.SYS and does * not migrate any existing LSP parameters. * CONFIG.SYS and AUTOEXEC.BAT will be placed in the root of the C drive. * INST_SECTION = ( ; Do not use the input configuration for LSP driver parameters. MigrateControlFiles = 0 ; Do not check the LAN adapters installed. AdapterCheck = 0 ; Define target location for LSP files. TargetPath = c:\lsp135 ; DriverDiskPath specifies where the files normally found on the ; Driver Diskette (Option Diskette) are located. ; Change DRIVERS to the location of your NIF, NDIS MAC driver, etc. ; Note: DRIVERS is not fully qualified, so it will be searched for ; 1) in the current directory ; 2) as a subdirectory off of the LSP source path DriverDiskPath = DRIVERS ) ; Specify bindings. The protocol stack is DXMJ0MOD.SYS. PROT_SECTION = ( ; The following statement specifies the DXMJ0MOD.SYS driver name. DriverName = NETBEUI$ ; Change IBMTOK_MOD to the bracketed module name for the PROTOCOL.INI ; section for the NDIS MAC driver you are using. bindings = IBMTOK_MOD ; Turn off piggy-backed acknowledgments. PiggyBackAcks = 0 ) *** End of Response file EXAMPLE3 ΓòÉΓòÉΓòÉ 9.1.4. DXME0MOD.SYS, DXMT0MOD.SYS and IBMTOK.DOS, One Adapter ΓòÉΓòÉΓòÉ * ---------------------------------------------------------------------- * EXAMPLE4.RSP * This response file installs IBMTOK.DOS, DXME0MOD.SYS and DXMT0MOD.SYS * and does not migrate any existing LSP parameters. * CONFIG.SYS and AUTOEXEC.BAT will be placed in the root of the C drive. * INST_SECTION = ( ; Do not use the input configuration for LSP driver parameters. MigrateControlFiles = 0 ; Do not check the LAN adapters installed AdapterCheck = 0 ; Define target location for LSP files TargetPath = c:\lsp135 ; Change DRIVERS to the location of your NIF, NDIS MAC driver, etc. ; Note: DRIVERS is not fully qualified, so it will be searched for ; 1) in the current directory ; 2) as a subdirectory off of the LSP source path DriverDiskPath = DRIVERS ) ; Specify bindings. The protocol stack is DXME0MOD.SYS. PROT_SECTION = ( ; The following statement specifies the DXME0MOD.SYS driver name. DriverName = DXME0$ ; Change IBMTOK_MOD to the bracketed module name for the PROTOCOL.INI ; section for the NDIS MAC driver you are using. bindings = IBMTOK_MOD ; Uncomment the next line to use 'Original Ethernet Adapter Type'. ; X ; It is not recommended that the NetAddress parameter be used. ; The equivalent parameter for the MAC driver should be used instead. ; Uncomment the next line and change for LAA. ; NetAddress = "400000123456" ; Uncomment the next line and change for work space. ; WorkSpace = 8 ; Uncomment the next line and change for ethernet type ; Transmit = 0 ; Uncomment the next line and change for minimum SAPs. ; MinSAP = 2 ; Uncomment the next line and change for minimum Link Stations. ; MinLink = 12 ) PROT_SECTION = ( ; The following statement specifies the DXMT0MOD.SYS driver name. DriverName = DXMT0MOD$ ; The following statement adds this driver to the configuation. lsp_primary = 1 ; Turn off piggy-backed acknowledgments. PBA = 0 ) PROT_SECTION = ( DriverName = IBMTOK$ ; The following statement would be needed if the sample protocol.ini ; did not contain a section for the MAC driver. In that case, ; uncomment the statement and change the keyword value to match the ; target of the bindings= in the DXME0$ PROT_SECTION section (above). ; Section_Name = IBMTOK_MOD ; The following two statements would cause the MAC driver and message ; file to be copied to the target location for LSP files (c:\lsp135). ; They are only needed if there is no NIF file for the MAC driver in ; the DriverDiskPath. In that case, uncomment the statements and ; change the keyword values to match those for your MAC driver. ; DriverFile = ibmtok.dos ; CopyFile = lt2.msg ) *** End of Response file EXAMPLE4 ΓòÉΓòÉΓòÉ 9.1.5. Migration to DXMJ0MOD.SYS and IBMTOK.DOS ΓòÉΓòÉΓòÉ * ---------------------------------------------------------------------- * EXAMPLE5.RSP * This response file migrates to DXMJ0MOD.SYS with IBMTOK.DOS. * This response file migrates LSP parameters where possible. * If the existing configuration contains DXME0MOD.SYS, DXMT0MOD.SYS and * IBMTOK.DOS, then the resulting configuration will contain DXME0MOD.SYS * DXMJ0MOD.SYS and IBMTOK.DOS. * NOTE: This example ASSUMES that the existing configuration contains * IBMTOK.DOS. * INST_SECTION = ( ; Use the input configuration for LSP driver parameters. MigrateControlFiles = 1 ; Do not check the LAN adapters installed. This effectively removes ; any non-NDIS LSP drivers from the configuration. AdapterCheck = 0 ; Define target location for LSP files TargetPath = c:\lsp135 ; Change DRIVERS to the location of your NIF, NDIS MAC driver, etc. ; Note: DRIVERS is not fully qualified, so it will be searched for ; 1) in the current directory ; 2) as a subdirectory off of the LSP source path ; DriverDiskPath is not necessary if the MAC driver is already in ; target path. DriverDiskPath = DRIVERS ) PROT_SECTION = ( ; The following statement specifies the DXMJ0MOD.SYS driver name. DriverName = NETBEUI$ ; The following statement specifies that the MAC driver is IBMTOK.DOS ; Notice that it uses IBMTOK_NIF instead of IBMTOK_MOD. ; This is because the PROTOCOL.INI file on the workstation has '_NIF' ; appended to the driver file names (to generate the bracketed module ; names); whereas the sample PROTOCOL.INI shipped with LSP has '_MOD' ; appended to the driver file names. Contrast with EXAMPLE3.RSP and ; EXAMPLE4.RSP. bindings = IBMTOK_NIF ; Turn off piggy-backed acknowledgments. PiggyBackAcks = 0 ) *** End of Response file EXAMPLE5 ΓòÉΓòÉΓòÉ 9.1.6. DXMJ0MOD.SYS and IBMTOK.DOS, Two Adapters ΓòÉΓòÉΓòÉ * ---------------------------------------------------------------------- * EXAMPLE6.RSP * This response file installs IBMTOK.DOS and DXMJ0MOD.SYS for two * adapters and does not migrate any existing LSP parameters. * It illustrates using a PINIFILE parameter. * CONFIG.SYS and AUTOEXEC.BAT will be placed in the root of the C drive. * INST_SECTION = ( ; Do not use the input configuration for LSP driver parameters. MigrateControlFiles = 0 ; Do not check the LAN adapters installed AdapterCheck = 0 ; Define target location for LSP files TargetPath = c:\lsp135 ; Change DRIVERS to the location of your NIF, NDIS MAC driver, etc. ; Note: DRIVERS is not fully qualified, so it will be searched for ; 1) in the current directory ; 2) as a subdirectory off of the LSP source path DriverDiskPath = DRIVERS ) ; The following statement causes the protocol.ini file, named ; PROTOCOL.CFG (in path RSP) to be processed. ; Since RSP\PROTOCOL.CFG is not fully qualified, it will be searched for ; 1) in the current directory ; 2) as a subdirectory off of the LSP source path ; The bindings and driver parameters are specified in PROTOCOL.CFG. ; See below for PROTOCOL.CFG. PINIFILE = RSP\PROTOCOL.CFG *** End of Response file EXAMPLE6 ;----------------------------------------------------------------------- ; PROTOCOL.CFG ; Configuration with DXMJ0MOD.SYS and IBMTOK.DOS for two adapters. [PROTMAN_MOD] DriverName = PROTMAN$ [DXMJ0MOD_MOD] DriverName = NETBEUI$ ; We are using IBMTOK_MOD instead of IBMTOK_NIF because we set ; MigrateControlFiles to 0 in the INST_SECTION, therefore we are ; using the sample LSP PROTOCOL.INI as the base PROTOCOL.INI (rather ; than using a PROTOCOL.INI from an existing configuration which ; would have '_NIF' instead of '_MOD' in the bracketed module names). Bindings = IBMTOK_MOD, IBMTOK2_MOD ; Turn off piggy-backed acknowledgments. PiggyBackAcks = 0 [IBMTOK_MOD] DriverName = IBMTOK$ EARLYRELEASE MAXTRANSMITS = 6 RECVBUFS = 2 RECVBUFSIZE = 256 XMITBUFS = 1 XMITBUFSIZE = 2040 [IBMTOK2_MOD] DriverName = IBMTOK2$ EARLYRELEASE ALTERNATE MAXTRANSMITS = 6 RECVBUFS = 2 RECVBUFSIZE = 256 XMITBUFS = 1 XMITBUFSIZE = 2040 ; End of PROTOCOL.CFG ΓòÉΓòÉΓòÉ 9.2. Command Line Parameters ΓòÉΓòÉΓòÉ Command Line Parameters Several command line parameters have been added to the LAN Support Program DXMAID utility. Some of the parameters specify information which can also be included in the response file. The value specified on a command line parameter overrides any like semantic value set by a keyword in the response file. Parameters /R:X:\...\file.rsp Response file This parameter specifies the drive, path, and file name of the response file to be used for this install. The file name does not need to be fully qualified if the file is contained in the current directory. /G:X:\...\... Include file path This parameter specifies the drive and path that will be searched for a response file specified by an Include keyword in the primary response file. /L1:X:\...\file.log Log file This parameter specifies the drive, path, and file name of the log file. The file name does not need to be fully qualified if the file is contained in the current directory. If /L1: is not specified, no logging is done. If the log file exists, additional log entries will be appended to it. The log file contains configuration and error information. /S:X:\...:\... This parameter specifies the drive and path where the LAN Support Program installation files are found. /S takes precedence over any SourcePath keyword in the response file. Default = path where DXMAID.EXE is located. /T:X:\...\... Target path This parameter specifies the drive and path where the LAN Support Program configuration information, other than CONFIG.SYS and AUTOEXEC.BAT, are to be copied. /T takes precedence over any TargetPath keyword in the response file. Default = x:\LSP where x is the lowest alphabetical hard drive designator, or A:\LSP on target systems without a hard drive. /TU:X:\...\... This parameter specifies the drive and path where the source and target CONFIG.SYS and AUTOEXEC.BAT files are located. /TU takes precedence over any ControlFilePath keyword in the response file. Default = root directory of the drive onto which LAN Support Program is to be installed. Example Following is a sample invocation of DXMAID. This invocation uses the response file LSP.RSP found on the H:\CID\RSP\LSP directory. LAN Support Program is installed in the client's C:\LSP directory and error messages are logged in the LSPERR.LOG files in the H:\CID\LOG\LSP directory. DXMAID /R:H:\CID\RSP\LSP\LSP.RSP /T:C:\LSP /L1:H:\CID\LOG\LSP\LSPERR.LOG ΓòÉΓòÉΓòÉ 9.3. Return Codes ΓòÉΓòÉΓòÉ Return Codes The LAN Support Program install program communicates information back to NetView DM/2 through 2-byte return codes. LAN Support Program returns the return codes only if the CID environment variable RemoteInstallState is present. This variable should be set by NetView DM/2 or another SDM agent. LAN Support Program returns the following return codes to NetView DM/2. 08 00 Explanation: NIF files were missing from the LAN Support Program source path. 12 00 Explanation: Storage medium exception (I/O error). 12 04 Explanation: Device not ready. 16 00 Explanation: Incorrect program invocation. 16 04 Explanation: Unexpected condition. FE 00 Explanation: Returned on successful program termination. NetView DM/2 is instructed to reboot the machine just installed with LAN Support Program. FE 04 Explanation: Returned on successful program termination. Warning messages have been logged. NetView DM/2 is instructed to reboot the machine just installed with LAN Support Program. ΓòÉΓòÉΓòÉ 10. NetView DM/2 Response File and Command Line Parameters ΓòÉΓòÉΓòÉ This appendix documents the new response file keywords and command line parameters that have been implemented to install NetView DM/2 2.0 DOS CC Client using the CID process. A full listing of response file keywords and command line parameters can be found in NetView Distribution Manager/2 Installation and Customization Guide. ΓòÉΓòÉΓòÉ 10.1. NetView DM/2 Response File ΓòÉΓòÉΓòÉ NetView DM/2 Response File The NetView DM/2 response file allows NetView DM/2 to be installed without user intervention. This file defines all the responses which would be entered by a person during an attended installation. Note: The Include keyword is not supported in NetView DM/2. Syntax The NetView DM/2 response file is a text file containing keywords and comments. The general format is as follows: // This is a comment Keyword = 10 // Another comment AnotherKeyword = some string of characters Comments begin with a double slash (//) as the first non-blank character on the line. All text up to and including the new line character are part of the comment. Comments are not allowed on the same line as a keyword. Only one keyword is allowed per line. The keyword must be the first non-blank character on the line. Following the keyword is an equal sign (=), which is followed by either a number or a string of characters. Blanks can be inserted between the keyword, equal sign, and number or character string. The case of the keyword is not significant. For example, all of these are the same keyword: rebootaction, REBOOTACTION, and RebootAction. Keywords can be defined in any order, but the same keyword cannot be defined more than once. If there are multiple occurrences of a keyword in the response file, then the installation does not work. Also, the installation will not work when two keywords that have the same meaning are specified, such as with RebootAction and ActionTaken. Keywords ActionTaken=value This is the same as RebootAction. ActionTaken indicates the action taken by the product when a Change Management request is pending. ActionTaken and RebootAction are mutually exclusive keywords. A response file with both specified will result in an error message. Valid values: Accept Process the request by rebooting the workstation after 10 seconds (default) Resume Reissue this message after xxx minutes (where xxx is the timeout value specified in the /T parameter of the CDM agent device driver) Defer Process the request at the next IPL of the workstation ActionTimeout=value This is the same as RebootTimeout. ActionTimeout indicates the time after which the reboot is executed. It is also used by the product as the display time for the pop-up. ActionTimeout and RebootTimeout are mutually exclusive keywords. A response file with both specified will result in an error message. Valid value: A number in the range of 5 to 32 767 seconds. Default = 300. RebootAction=value This is the same as ActionTaken. RebootAction indicates the action taken by the product when a Change Management request is pending. RebootAction and ActionTaken are mutually exclusive keywords. A response file with both specified will result in an error message. Valid values: Accept Process the request by rebooting the workstation after 10 seconds (default) Resume Reissue this message after xxx minutes (where xxx is the timeout value specified in the /T parameter of the CDM agent device driver) Defer Process the request at the next IPL of the workstation RebootTimeout=value This is the same as ActionTimeout. RebootTimeout indicates the time after which the reboot is executed. It is also used by the product as the display time for the pop-up. RebootTimeout and ActionTimeout are mutually exclusive keywords. A response file with both specified will result in an error message. Valid value: A number in the range of 5 to 32 767 seconds. Default = 300. RestoreRuleFiles=value Specifies whether or not a rules files installed on the target system will be migrated to the new NetView DM/2 installation. This keyword is only significant during reinstallation or configuration of the target system. For new installations it is ignored. Valid values: NO Do not restore rules files (migrate rules files) (default) YES Restore rules files (restore the default set of rules) ResumeTimeout=value Indicates the time after which the pop-up is displayed again by the product. Valid value: A number in the range of 1 to 200 minutes. Default = 10. Example Following is a sample NetView DM/2 response file, showing the coding of the new keywords. // NetView DM/2 response file . . . ActionTaken = ACCEPT ActionTimeout = 300 RestoreRuleFiles = YES ResumeTimeout = 10 . . . ΓòÉΓòÉΓòÉ 10.2. Command Line Parameters ΓòÉΓòÉΓòÉ Command Line Parameters A new command line parameter has been added to NetView DM/2. Other valid NetView DM/2 command line parameters can be found in NetView Distribution Manager/2 Installation and Customization Guide. Parameters /RRF This parameter specifies that the default NetView DM/2 rules files are to be restored during the new installation; that is, any existing rules will not be migrated. Specifying /RRF on the command line is the same as specifying RestoreRuleFiles=YES in the response file. ΓòÉΓòÉΓòÉ 11. Product Enablement ΓòÉΓòÉΓòÉ This appendix describes the interfaces and file formats supported by software distribution managers (SDMs) in accordance with IBM's strategic plan to produce a common distribution platform. Although any technical strategy is dynamic, products conforming to the guidelines and suggestions presented in this appendix will likely be able to exploit forthcoming SDM enhancements with little or no change. ΓòÉΓòÉΓòÉ 11.1. CID Requirements ΓòÉΓòÉΓòÉ To be CID enabled, products must provide for: o Transfer of diskette images to a hard drive The product should have a documented method for storing the images of product diskettes in a way that can be used by both the SDM and the product's CID program. The methods used for this may vary. One method could be a section in the product documentation detailing the layout of the directory structure and any directory naming conventions. This would include a series of instructions telling the user how to copy the files using a command such as XCOPY. In more complex products, developers may want to supply a utility program that automates the process. The directory and drive to which the images are stored should have a default as well as an option for user definition to accommodate the SDM. o Command line parameters A product operation (transfer of product diskettes, installation, configuration, and maintenance updates) should be able to be executed from the command line with parameters that are defined by the product/program. The SDM uses information entered by an administrator to interface to the product/program via a command line. See Product Code Interface for CID Enablement and SDM Interfaces for more details about the type of information that should be passed via these parameters. o Redirected drives A CID-enabled product must be able to be installed or updated from any drive or any device that can be represented by a disk drive letter. Products that support being installed or updated only from the A: or B: drives need to expand their support to cover any logical drive. This allows for software to be distributed in a LAN environment by using file redirection to a code server. o Return codes to the SDM A CID-enabled product must be able to pass the status of its installation or configuration processes to a software distribution manager through the use of return codes. See Return Codes for more information about the architected return codes that should be used. CID enablement might also require: o Generation of response files Response file support is required if a user dialog is required during a non-CID installation. During a product installation, configuration, or maintenance update, users are typically required to answer questions that affect the outcome of the process. A CID-enabled product operation must be able to receive the user responses, which are normally entered from the keyboard, or be able to make the product operational after installation from a response file (for example, CONFIG.SYS updates). This response file should be an ASCII file that contains all the answers to the questions that are asked, or that defines the actions to be taken during the operation (for example, the target drive, adapter address, and so on). This file should be generated by the user, either by using an editor or a utility supplied with the product. Sample response files should also be supplied with the product. For more information about response files, see Response Files. o Progress information (error and history logs) A CID-enabled product should define log files to be used to store information about the progress of the product installation, configuration, or maintenance. These files contain information such as installation/maintenance/configuration update history and error information. The user/administrator should be able to use command line parameters to define the path/location to which these files are written. ΓòÉΓòÉΓòÉ 11.2. Response Files ΓòÉΓòÉΓòÉ A response file is an ASCII flat file consisting of a series of lines separated by carriage return (X'0D') or new line (X'0A') characters. No line in the file can exceed 255 characters. The lines of a response file fall into two categories: comment lines and response lines. ΓòÉΓòÉΓòÉ 11.2.1. Comment Lines ΓòÉΓòÉΓòÉ Comment lines are lines that contain only white space characters, or have either an asterisk (*) or semicolon (;) as the first non-white space character on the line. White space characters are defined as tabs, blanks or spaces, and new lines. For example, a line that contains only tab characters followed by a new line sequence should be interpreted as a comment line because the line contains no characters other than white space characters. Similarly, if a line contains only a carriage return or line feed sequence, then this line should also be interpreted as a comment line. Examples of valid comment lines are: * This line has an asterisk in column 1 * This line has an asterisk in column 10 ; This line uses a semicolon to indicate a comment * The line above uses a new line sequence *** This line is also a valid comment line Asterisks and semicolons have special meanings in a response file only when they are the first printable character on the line. If the characters occur anywhere else on the line, then they are interpreted as part of the string to be assigned to the keyword. kwd1 = response * this was intended to be a comment about response The keyword in this example is assigned everything to the right of the equal sign as its value string. Therefore, comments must always appear as separate lines within a response file. ΓòÉΓòÉΓòÉ 11.2.2. Response Lines ΓòÉΓòÉΓòÉ Response lines are the lines in a response file which are used by the product installation, configuration, or maintenance program to determine the options and configuration to install on the target system. Response lines use the following syntax: keyword [= [value]] where keyword is one of a series of string values recognized by the product installation, configuration, or maintenance routines, and value, if present, is the user-assigned value given to that keyword. Note that a value can actually be a list of values. See Values. ΓòÉΓòÉΓòÉ 11.2.3. Keywords ΓòÉΓòÉΓòÉ The keyword, or reserved word, used in a response line is a string that follows these rules: o It begins with an alphanumeric character that is not an asterisk or semicolon. o It must not contain any embedded blanks or spaces. o It does not contain an embedded or trailing equal sign (=). o It should not be case sensitive. Examples of valid keywords are: include Include inCLude INCLUDE X1Y23 1abc A_long_and_drawn_out_but_very_descriptive_keyword All four Include examples constitute the same keyword because response files should not be case sensitive. Keyword combinations that are not valid include: =bad_name = 3 NO Space = y Silly=Mistake = 0 The first keyword is not valid because the first equal sign has been used incorrectly. The second keyword is invalid because of the space included in the name of the keyword. The third keyword includes an equal sign in the keyword Silly_Mistake instead of the underscore. A further complication is that if a keyword called Silly existed, then that keyword would be given a value of Mistake = 0. Developers should try to ensure that they use unique keyword tokens that would not allow this type of error to occur. ΓòÉΓòÉΓòÉ 11.2.4. Values ΓòÉΓòÉΓòÉ A keyword does not need to have a value associated with it to be valid in a response file. In some cases, the existence of a keyword can carry significance, and there is no additional benefit to assigning it a value. Implementers can choose to define a keyword as having no value associated with it. In most cases, however, keywords have a values associated with them. If present, the value associated with a keyword must be preceded by an equal sign (=). It can be separated from the equal sign by zero or more blanks or spaces. The equal sign itself is a syntax-defined constant. An equal sign is optional; if present, however, then it is separated from the keyword by zero or more spaces or blanks. The equal sign must be placed on the same line as the keyword and, if present, must be followed by a value also on the same line. Keywords can have a single value (or value_string) or a list of values associated with them. A value_string is an arbitrary string that begins with the first printable character following the equal sign and ends with the last printable character of the line. A value_string cannot be a one-character string consisting of the left parenthesis ("("). A value_string can be a null string. Examples of are valid value strings are: kw1 = kw2=john kw3 = 8 If the value_string consists of a one-character string consisting of the left parenthesis, then this signifies the start of a list. The following example shows an invalid value_string but a value that would be valid as the start of a list: kw4 = ( A list of values is a list of response file lines delimited by parentheses. A value is a list when the value_string to the right of the equal sign is a one-character string that consists of the left parenthesis. The equal sign and the left parenthesis character must be on the same line. To avoid any requirement for the use of an escape character, the response file syntax requires that the bracketing parentheses be on separate lines. The syntax used for a list is: keyword = ( keyword [= [value]] [keyword [= [value]]] ) A valid response file showing a list is shown here: kw5 = ( kw5.1 = This is kw5.2 = a little kw5.3 = list ) Lists can also be nested if required. This is a valid response file where the value consists of a nested list: kw6 = ( kw6.1 = This is kw6.2 = a response kw6.3 = file kw6.4 = ( kw6.4.1 = with a kw6.4.2 = nested list ) ) ΓòÉΓòÉΓòÉ 11.2.5. Including Other Response Files ΓòÉΓòÉΓòÉ Response files can be designed so that they can support the inclusion of other response files. (See Standard Keywords for a detailed discussion of the Include keyword.) Included response files are files that are read in and processed during the processing of another response file. This provides a means of nesting response files. A response file should never call itself either directly or indirectly. Because a response file (including its nested includes) can contain multiple occurrences of the same keyword or no occurrence of a keyword, the user should know in which order the specified keywords are processed and how they are interpreted. ΓòÉΓòÉΓòÉ 11.3. Response File Style Recommendations ΓòÉΓòÉΓòÉ There are few limitations imposed on the semantics and processing of a response file. This provides developers with the most flexibility in designing their programs and response file formats. However, there is a risk that different implementations can result in different interfaces that are confusing and contradictory. This section attempts to provide some guidelines that can provide additional consistency across products. ΓòÉΓòÉΓòÉ 11.3.1. Keyword Guidelines ΓòÉΓòÉΓòÉ Keywords are used to represent actions or a combination of actions and objects. For example, the keyword Include represents an action indicating that another response file should be loaded and parsed. Another keyword (ScreenSize, for example) might represent a combination of an action and an object-the action being SET and the object being a screen size parameter. Keywords that represent both actions and objects are always interpreted in the context of the response file processor. In other words, each product can interpret the same keyword and its associated value in a different way. Similarly, a keyword can be interpreted in different ways depending on whether or not it appears in a list in the response file. To avoid these types of problems and difficulties for the administrator, developers should attempt to ensure that their keyword identifiers are unique. Keyword-value pairs are specified to produce the response file required to install, configure, or maintain a product. The keywords used can also be specified in ways that are interpreted differently by different products. The following rules enable the developer to ensure that the interpretation of the various keyword conditions are implemented consistently from product to product. o For keyword-value pairs that are replicated in a response file, where replicated keywords are not specifically permitted by the product installation program, the last value assigned to the keyword should be taken as the value to be used. o If replicated keywords are permitted by the product installation routine, then the multiple keywords should be interpreted on an individual basis as items that are unrelated to each other. o For keywords that have no value specified, for example: Keyword = or Keyword a conforming product might interpret this condition in one of three ways: 1. The product default for the keyword should be used. 2. The specification of a null value is acceptable and its meaning has been sufficiently documented to remove any possible ambiguity between its meaning and the product default. 3. An error condition has occurred. o When keywords are missing from the response file, then the rules described in Response File Hierarchy should be used. Note: Response file keyword-value statements that are valid in a given version/release of a particular product must be supported in future versions/releases of that product. When a function changes, the product must provide migration of the old format to the new format as an integrated part of response file processing. ΓòÉΓòÉΓòÉ 11.3.2. Standard Keywords ΓòÉΓòÉΓòÉ There are certain actions that are common across many products. When implementing keywords that represent these actions, developers should attempt to make the syntax and processing consistent. IBM has defined three standard functions that are used across several of its CID-enabled products. This section addresses these keywords and suggests guidelines for their implementation. The standard keywords defined by IBM are as follows: Keyword Description Include Used to include other response files for processing Copy Used to copy one file to another UserExit Used to provide a method of performing general user exits ΓòÉΓòÉΓòÉ 11.3.2.1. Include ΓòÉΓòÉΓòÉ The Include keyword accepts a file specification as its value string: ΓöîΓöÇΓöÇΓöÇ INCLUDE KEYWORD SYNTAX ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇInclude =ΓöÇΓöÇd:\path\filename.extΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ where the drive, path, and filename can be any valid file specification. The file specification used may be ambiguous because of the inclusion of wildcard characters. If the file specification is ambiguous, then only the first file found that matches the file specification criteria should be opened and processed. When attempting to locate the file, the search for the file should take place in the following sequence: 1. Use the fully qualified file specification, if present. 2. Search the current directory for a matching file. 3. Use the file name together with the /G: parameter path. 4. If the file specification is not fully qualified, look on each element of the PATH environment variable. 5. If the file specification is not fully qualified, look on each element of the DPATH environment variable. The handling code should always process this keyword as soon as it is detected and every time it is detected. The contents of the included response file should be logically embedded at that point of the including file. When the end of the include file has been reached, processing should resume at the next line of the response file that contained the Include keyword. Implementers should log any I/O errors and any failure to find the include file. If an include file cannot be located, then the implementer should decide whether to abandon processing or to attempt to continue from the next line of the response file. Implementers should also support at least six levels of nesting. A response file should never call itself either directly or indirectly. Note: The Include keyword is not a valid keyword specification within a value list, that is, a list of keyword-value pairs delimited by parentheses. ΓòÉΓòÉΓòÉ 11.3.2.2. Copy ΓòÉΓòÉΓòÉ The Copy keyword accepts two file specifications, as expected by the copy function, as its value string: ΓöîΓöÇΓöÇΓöÇ COPY KEYWORD SYNTAX ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇCopy =ΓöÇΓöÇsource targetΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ where source is the file specification of the source file to be copied and target is the file specification of the target file. Each implementation should determine when in the process the Copy is actually carried out and should document it. There are no constraints on developers regarding how they should actually perform the copy. ΓòÉΓòÉΓòÉ 11.3.2.3. UserExit ΓòÉΓòÉΓòÉ The UserExit keyword accepts a file specification as its value string: ΓöîΓöÇΓöÇΓöÇ USEREXIT KEYWORD SYNTAX ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Γöé Γöé >>ΓöÇΓöÇUserExit =ΓöÇΓöÇfile_specificationΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>< Γöé Γöé Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ where file_specification indicates any valid program file. The file specification may ambiguous because of the inclusion of wildcard characters. If the file specification is ambiguous, then only the first file found that matches the file specification criteria should be opened and processed. When attempting to locate the file, the search should take place in the following sequence: 1. Use the fully qualified file specification, if present. 2. Search the current directory for a matching file. 3. If the file specification is not fully qualified, look on each element of the PATH environment variable. 4. If the file specification is not fully qualified, look on each element of the DPATH environment variable. Developers should execute the specified command from a CMD.EXE shell for OS/2 or a DOS command prompt (COMMAND.COM) for DOS to ensure that any OS/2 command files (.CMD) and DOS command files (.COM and .EXE) specified are executed correctly. This keyword is intended for use with general user exits. Developers can also have specific user exits that are specified with other keywords. It is up to the individual implementation to determine when a UserExit is processed and to explain this to the user in the product documentation. ΓòÉΓòÉΓòÉ 11.3.3. Order of Response File Execution ΓòÉΓòÉΓòÉ In general, response file lines should be processed in the same order as they appear in the response file. However, each implementation can have its own requirements, and developers can process the files in a different order. Implementers should try to ensure that the response file processing is done in an order that is intuitive to the user. Any exceptions to this should be documented. ΓòÉΓòÉΓòÉ 11.3.4. List Implementation ΓòÉΓòÉΓòÉ There is no requirement for lists to be implemented in any particular environment. If a developer chooses to implement lists, then the lists should be used to group data together in a manner that makes things simpler for the user. For example, if there is a function to delete sections of an INI file, then the developer might implement this as shown: INI_delete = ( [section1] [section2] [section3] ) ΓòÉΓòÉΓòÉ 11.3.5. Response File Processing Sequence ΓòÉΓòÉΓòÉ Response files contain sequences of keyword-value pairs which are interpreted during the installation, configuration, or maintenance process of a product. Because a response file can contain multiple occurrences of the same keyword or no occurrence of a keyword, the user should know in which order the specified keywords are processed and how they are interpreted. To facilitate this, a set of rules has been drawn up to assist developers in providing a consistent interpretation and processing structure for keywords that are missing or replicated within a response file. ΓòÉΓòÉΓòÉ 11.3.5.1. Response File Hierarchy ΓòÉΓòÉΓòÉ A number of different scenarios have to be considered when processing a response file. The developer must decide when to use: o The default value for a keyword o A migration value o A value from an included response file The set of rules listed here are designed to aid the implementer in making these decisions. Value Usage Product Default Should be used only when there is no existing value to migrate and no keyword-value exists in any of the referenced response files. Migration Value Used when there is no keyword value in any referenced response file and the installation process is one that is migrating between product releases. In this environment, the value from the current configuration is used. Keyword Value Always used as the value when specified. Multiple Keyword Instances If multiple instances of the same keyword appear, the last value specified should take precedence if only one instance is valid. These rules help the designer decide which keyword should be used at a particular time. The following example shows a representation of the hierarchy depicted in these rules. Highest Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé Γöé Γöé Γöé Γöé Specific Response File and Included Response Files Γöé Γöé Γöé Γöé Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé Γöé Γöé Γöé Γöé Migration of Existing Values Γöé Γöé Γöé Γöé Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé Γöé Γöé Γöé Γöé Product Default Γöé V Γöé Γöé Lowest Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ If multiple instances of the same keyword appear within the same response file, the last value specified should be used. In the following example, the same keyword (Format) is specified twice, each time with a different value. In this case, the end result is a Format of type FAT. FORMAT = HPFS SYSTEM_EDITOR=yes GAMES = cat_&_mouse solitaire scramble FORMAT = FAT PRODUCTIVITY=seek_&_scan epm sticky_pad ΓòÉΓòÉΓòÉ 11.3.5.2. Included Response File Hierarchy ΓòÉΓòÉΓòÉ The following rules apply to nested response files: o For a given nesting level of included response files, the rule of inheritance applies. The rule of inheritance states that a keyword-value pair within a given response file is inherited from its including response file unless it is specified in the included file. The last keyword-value pair within a given include hierarchy becomes the active parameter if only one instance is valid. o If multiple include hierarchies exist within a given specific response file, then the last keyword-value pair is the "active" parameter. The rule for multiple keyword instances in an included response file states that the last value specified should always be used. For example, in the following example, the user receives the same result as that shown previously. Both FORMAT = HPFS and FORMAT = FAT have been specified. Because the include file was listed after the FORMAT = HPFS statement, the installation program should format the disk with the FAT file system. FORMAT = HPFS INCLUDE john.rsp ******************** * john.rsp SYSTEM_EDITOR = yes GAMES = cat_&_mouse solitaire scramble FORMAT = FAT ******************** PRODUCTIVITY = seek_&_scan epm sticky_pad In the next example, the only change has been to swap the positions of the Include and Format keywords. This change has a major impact on the result produced by the installation program. In this case, the keyword specified in the included response file would be encountered first, which would result in a format for an HPFS file system. INCLUDE john.rsp ******************** * john.rsp SYSTEM_EDITOR = yes GAMES = cat_&_mouse solitaire scramble FORMAT = FAT ******************** FORMAT = HPFS PRODUCTIVITY = seek_&_scan epm sticky_pad These examples highlight the need for a product to have clear documentation about the processing sequence of response files, especially when multiple occurrences of the same keyword can exist. ΓòÉΓòÉΓòÉ 11.3.5.3. Response File and Command Line Hierarchy Rule ΓòÉΓòÉΓòÉ Products that permit the specification of a command line parameter possessing the same semantics as a response file parameter must adhere to the CID precedence rule that states the command line value overrides the like response file parameter. ΓòÉΓòÉΓòÉ 11.3.6. Generation of Response Files ΓòÉΓòÉΓòÉ The source of the data used in building a response file for use in a CID operation on a product varies by implementing product. Following are examples of ways in which a response file can be generated: o A model response file can be shipped to the user as part of a product's installation diskettes. The file should be shipped as a flat ASCII file that can be altered by an editor. A model response file can be used as the source response file for use in a lightly attended or unattended installation to install a product's default values. A model response file can also be used as a template and tailored to reflect a specific set of keyword-value pairs that an administrator has chosen to assign to a particular workstation or group of workstations. Model response files can be used as group response files. That is, the file can be merged with a client response file through Include keywords during the CID operation to provide the desired end result. o A panel-driven source of response file data is created when the product provides a facility to capture the activity during product installation. For example, a response file can be built by capturing an administrator's answers to an "attended panel driven" product installation. This type of response file source data is sometimes referred to as recording and is used in the context of saving panel response data. Panel recording occurs for IBM LAN Server V3.0 when a LAN Server/Requester installation response file is built at an OS/2 image preparation site. o Extracted source response file data is created from files that contain existing configuration information and reflects the characteristics of an installed product. Extended Services is an example of a product that provides this capability. Extended Services provides a utility that generates a response file based on configuration files from a previously installed system. ΓòÉΓòÉΓòÉ 11.4. SDM Interfaces ΓòÉΓòÉΓòÉ This section provides information about interfacing between a CID-enabled product and a software distribution manager (SDM). ΓòÉΓòÉΓòÉ 11.4.1. SDM Re-IPL ΓòÉΓòÉΓòÉ Certain installation programs require a re-IPL to occur before the installation process can be completed correctly. If a CID-enabled product requires a re-IPL to complete its operation, then the product's installation, configuration, or maintenance program should support the generation of certain return codes. There are two types of re-IPLs that can be requested: o Callback o No callback Callback is used when a product requires the installation program to continue after an IPL. No callback is used when an installation program requires a re-IPL for the product to function, but the installation program does not have to be restarted. The SDM interface furnishes a "Reboot" function to maintain the known state of the workstation and to provide a single implementation of this capability for CID products. The following steps describe SDM Reboot: 1. Product installation programs communicate to an SDM that a Reboot is required by specifying a return code: o Reboot with callback: X'FFxx' is specified upon exit to the SDM o Reboot with no callback: X'FEyy' is specified upon exit to the SDM The xx byte is the install state of the client installation program. The return code format is two hexadecimal bytes. 2. This product installation return code is used by the SDM to set the state variable, RemoteInstallState (ASCII format). This variable is saved by the SDM in its code server request/reply file before the SDM causes a physical re-IPL of the workstation to occur. The value of the variable RemoteInstallState is in the range of 0-255, represented by one to three ASCII characters. 3. The SDM client gains control after the re-IPL through a command placed into the OS/2 STARTUP.CMD file or the DOS CONFIG.SYS and AUTOEXEC.BAT files to reactivate the SDM client agent. 4. The saved state variable is subsequently interrogated by the SDM agent so that product installation programs can determine their execution state. The SDM agent also uses the information to detect infinite loops in an installation, configuration, or maintenance process. ΓòÉΓòÉΓòÉ 11.4.2. Return Codes ΓòÉΓòÉΓòÉ Each CID installation, configuration, or maintenance program should return to the SDM upon: o Successful completion o Inability to access a data resource o Disk error o Unexpected condition There is a defined set of return codes that are also mapped to SNA sense codes for reporting to the MVS-NetView DM host site. Note: The definition of the SDM return codes is an evolutionary process which will continue to be reviewed and updated based on product requirements. The currently supported codes and their descriptions are defined in the following list. FE 00 Explanation: Successful program termination-Reboot and do not invoke again. FE 04 Explanation: Successful program termination, but warning messages logged-Reboot and do not invoke again. FE 08 Explanation: Successful program termination, but error messages logged-Reboot and do not invoke again. FE 12 Explanation: Successful program termination, but severe error messages logged-Reboot and do not invoke again. FF xx Explanation: Successful program execution-Reboot with callback. SDM manages the state of the install product by validating its state returned by the installation client. Note that: o When a product installation, configuration, or maintenance program requests a Reboot with a callback, it is the responsibility of the exiting program to set the correct byte (xx can vary from 00 to FF) of the return code to its next install state. For example, on the initial call from SDM, the state variable is X'00', and it can be incremented (by one) by the program for each Reboot request that is returned. o SDM validates that the product installation state value is different than the last time the CID operation was invoked. o SDM re-IPLs the workstation, retrieves the product's install state parameter from the SDM code server, and passes it to the invoked CID program via the RemoteInstallState state variable. FD 00 Explanation: SDM reserved. 00 00 to FC xx Explanation: Installation program final return codes with xx varying from 00 to FF. Return Code Description 00 00 Successful program termination-No reboot 00 04 Successful program termination, but warning messages logged-No reboot [*] 00 08 Successful program termination, but error messages logged-No reboot [*] 00 12 Successful program termination, but severe error messages logged-No reboot [*] 08 00 Data resource not found 08 04 Data resource access denied because already in use 08 08 Data resource access denied because missing authorization 08 12 Data path not found 08 16 Product not configured 12 00 Storage medium exception (I/O error) 12 04 Device not ready 12 08 Not enough disk space 16 00 Incorrect program invocation 16 04 Unexpected condition [*] Not supported in initial OS/2 releases of the SDM agent (NetView DM/2 and NTS/2 [LCU]). These rules should be used for interpreting return codes for CID-conforming agents: o All Reboot return codes are to be interpreted as "successful" by the SDM agent (NetView DM/2). o Non-Reboot return codes that are to be interpreted as "successful" are as follows: 00 00 00 04 00 08 00 12 CID-enabled programs must correlate their use of return codes with SDM versions that support the set of return codes that are requested by a CID-enabled install program. o All other non-Reboot return codes are to be interpreted as "unsuccessful" by the SDM agent (NetView DM/2). o The return code reserved for NetView DM/2 (FD 00) is to be interpreted as "unsuccessful." ΓòÉΓòÉΓòÉ 11.4.3. Resolution of Product Installation PATH Assignments from an SDM ΓòÉΓòÉΓòÉ The SDM agent at the code server workstation translates "variable" file paths into "real" file paths that are accessible by a product's CID programs. This translation occurs for: o Source image files o Client response files o Group response files o Log files The translation is necessary because the drive paths for potential code servers can be different. ΓòÉΓòÉΓòÉ 11.4.4. SDM Interface to Product Installation Programs ΓòÉΓòÉΓòÉ The general format of an SDM's command line interface to product installation, configuration, or maintenance procedures is the name of the product's procedure followed by parameters. The parameter passing convention used by CID products is to prefix each path assignment with a nonpositional keyword (that is, /S:, /R:, /G:, /L(1-5):, /T:, and /TU:). For example: INSTPROC /S:<source> /R:<specific response file> /G:<group response file> /L<1-5>:<log file> /T:<target> /TU:<CONFIG.SYS path> In the following keyword descriptions, the term optional means that support of the parameter is at the discretion of the conforming CID product. Products can implement or not implement particular parameters. It is the responsibility of each CID product to describe which parameters are optional on the invocation of its CID program. Note: In the descriptions of the following parameters, some product-specific information is given. The intent is to provide some examples of how specific products have used the individual parameters. The descriptions of the common CID parameters follow: Parameter Description /S: This parameter is optional and specifies the drive and path to the product image files existing on the SDM code server. Product source images are created at the image preparation site by the specific product image preparation utility. Note that the LAN Server product retrieves its source files from the same redirected drive that contains its installation code, and therefore does not use this parameter. /R: This parameter is optional and specifies the drive, path, and name to the client response file existing on the SDM code server. /G: This parameter is optional and specifies the drive and path to the group response file existing on the SDM code server. A group response file is activated by an Include keyword within a client response file. See Response File Processing Sequence for information about how included response files are processed. /L1: to /L5: These parameters (/L1:, /L2:, /L3:, /L4:, and /L5:) are optional and specify the drive, path, and name of product-specific log files that can exist on the SDM code server. Products can also maintain log files at the client workstation. The product program can either copy the log files to the code server at the completion of the operation or dynamically update them at the code server during the operation. The parameters /L1 and /L2 are recommended for error and history log files, respectively. /T: This parameter is optional and specifies the target drive and path for the product installation, configuration, or maintenance at the client workstation. /TU: This parameter indicates the drive or path of target control files such as CONFIG.SYS, *.INI, STARTUP.CMD (for OS/2), and AUTOEXEC.BAT (for DOS) for updating during the process. For instance, the various path statements may require updating, or DEVICE= statements may need to be added. Note: It is recommended that products not require or add more parameters than necessary because of the restrictiveness of command line lengths (for example, in DOS, where the length is less than 128 characters). The following list describes some additional parameters that have been defined by individual products for their unique requirements. Product designers might want to use these same parameters for similar requirements within their own products. Parameter Description /SRV This parameter indicates that the IBM LAN Server V3.0 product is to perform a LAN Server installation. /REQ This parameter indicates that the IBM LAN Server V3.0 product is to perform a LAN Requester installation. /E: This parameter indicates the installation environment for LAPS. LAPS uses different installation procedures depending on whether OS/2 Presentation Manager is available. For example, when installing from a maintenance system, PM may not be available; the LAPS installation procedure needs to take this into account. /B: This parameter indicates the target boot drive for the OS2KRNL, OS2LDR, *.SYS, and *.BIO. files of OS/2 Version 2.0 during SEMAINT and SEINST execution. /Q: This parameter indicates the "quiet" mode, which enables Start program installation to be a non-interactive process. Default action is taken where user intervention is normally required. /CMD: This parameter indicates the drive and path for the command files on the code server which is executed for OS/2 LAN CID Utility clients. ΓòÉΓòÉΓòÉ 11.4.5. NetView DM/2 Exit Interface to Product Install Programs ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 11.4.5.1. OS/2 Exit Interface ΓòÉΓòÉΓòÉ The 2-byte CID return codes architected for OS/2 CID installs are communicated to the NetView DM/2 agent by the normal DosExit function. ΓòÉΓòÉΓòÉ 11.4.5.2. DOS Exit Interface ΓòÉΓòÉΓòÉ The 2-byte CID return codes architected for OS/2 CID installs are compatible with the DOS CID return information. On DOS, INT 2F is used to send/receive 2-byte CID return codes between the CID install application and the listening NetView DM/2 agent. For example: CID Application Installation ------------------------------------ main( ) { ... // Do whatever app install does // ... ... AX = CID_signature // Send 16-bit CID return // BX = ret_code // code via INT 2F to // INT 2Fh // NVDM/2 Listening Agent // exit( ret_code ) // Now exit (only 8-bits returned) // } On DOS, the INT 2F signature "CFFF" is reserved for this purpose. ΓòÉΓòÉΓòÉ 11.4.6. CID SDM NetBIOS Naming Requirements ΓòÉΓòÉΓòÉ An SDM addresses target workstations on a LAN using a 16-byte NetBIOS name. The SDM requires that all of its client workstations have unique NetBIOS names even if they are located on different LAN segments. The SDM requires all of its target NetBIOS names to be unique within the scope addressed by the host code distribution site. The scope can include LANs not directly connected to each other (via the NetBIOS transport protocol). The SDM preparation site administrator must therefore allocate a unique name (that is, an 8-byte NetBIOS name) for each target workstation serviced by the host distribution site. The 8-byte NetBIOS name is augmented at the SDM code server, which appends another 8 bytes to the preparation-site-generated workstation ID to avoid name conflicts with other users of the NetBIOS facility on the LAN. Note: This naming convention applies only to NetView DM/2. Other SDMs might not use this convention. In a non-CID environment, an "administrator" must similarly specify addresses for LAN adapters for each LAN workstation that is to be locally administered. These addresses must be unique within a LAN or bridged LAN configuration. ΓòÉΓòÉΓòÉ 11.4.7. CID File Naming Recommendations ΓòÉΓòÉΓòÉ Suggested file name qualifiers for CID products are: o .RSP for response files o .LOG for log files residing on the code server machine ΓòÉΓòÉΓòÉ 11.4.8. Other Design Considerations ΓòÉΓòÉΓòÉ When enabling products for the CID environment, developers should o Determine how an installation program reacts when the product being installed or upgraded is already installed and in use. The installation program could: - Shut down the currently running version of the product - End the installation with an error return code - Provide a message to the user asking whether or not to continue o Design the installation procedure for both unattended and lightly attended environments. One consideration would be the type of information presented on the client workstation. For instance, progress indicators are useful; however, pop-up message boxes that require user interaction to continue might not be appropriate. o Under certain circumstances, an installation program may discover that certain files that it needs to replace are locked by the operating system and cannot be replaced at installation time. Product installation routines should be designed to handle this possibility. A discussion of how some IBM programs handle locked files is in Handling of Locked Files. ΓòÉΓòÉΓòÉ 11.5. Additional CID Install Guidelines ΓòÉΓòÉΓòÉ The following list itemizes additional functions that would benefit a CID installation. Although these items are not required to be CID compliant, it is suggested that install procedures or administrative setup consider the benefits of each guideline. ΓòÉΓòÉΓòÉ 11.5.1. DASD Space Checking ΓòÉΓòÉΓòÉ DASD space checking at the beginning of the installation program prevents a partial install of a particular product. This eliminates install cleanup functions related to an aborted product install. Considerations include: o Whether the installation overlays a previous version of the same product versus installing the new version under a different directory, then deleting the old directory version o Data compaction of the target install drive ΓòÉΓòÉΓòÉ 11.5.2. Minimize Storage Fragmentation ΓòÉΓòÉΓòÉ To preserve DASD space and to reduce storage fragmentation, CID-enabled products should delete files/directories that are not needed after the program is successfully installed. This should also be done for partial installs that are aborted for some reason. ΓòÉΓòÉΓòÉ 11.5.3. Real-Time Update of Log Files ΓòÉΓòÉΓòÉ Updating code server log files should be done in "real time" to capture error/history data for an aborted install. ΓòÉΓòÉΓòÉ 11.5.4. CID Product Feature Additions and Deletions ΓòÉΓòÉΓòÉ CID-enabled products should provide for "additions" and "deletions" on a feature basis so that a complete product removal or re-install can be avoided. ΓòÉΓòÉΓòÉ 11.5.5. CID Product Fixes Additions and Deletions ΓòÉΓòÉΓòÉ CID-enabled products should provide for "additions" and "deletions" on a fix basis to install only the fixes an installation requires and to roll back to a fix level if the installed fix does not work. ΓòÉΓòÉΓòÉ 11.5.6. CID Product Customization ΓòÉΓòÉΓòÉ Via the response file feature of CID, products should provide an administrator with the ability to customize program features that are normally associated with a fully attended installation. ΓòÉΓòÉΓòÉ 11.5.7. Data Compression ΓòÉΓòÉΓòÉ CID-enabled products should ship their image data in compressed form to reduce both server DASD space and LAN transport time. ΓòÉΓòÉΓòÉ 11.5.8. Response File Processing ΓòÉΓòÉΓòÉ CID-enabled products should validate the response file syntax and semantics at the start of their install program. This method is preferred because response file checking after some install files have been copied, or after shared configuration files have been modified, complicates the restoration of the workstation to a prior valid state. ΓòÉΓòÉΓòÉ 11.5.9. Unpacking Location at Client Site ΓòÉΓòÉΓòÉ Product image files should be unpacked at the client's workstation to decrease LAN data transfer time between the client and server. ΓòÉΓòÉΓòÉ 11.5.10. Client Transfer Only What Is to Be Installed ΓòÉΓòÉΓòÉ Optional product features that are not requested to be part of a particular product's CID installation should not be transferred to the client's workstation and then deleted. CID products should not transfer data that will not be installed. ΓòÉΓòÉΓòÉ 11.5.11. Product Icon Placement ΓòÉΓòÉΓòÉ Screen placement of a product's icon should be specifiable as an installation/configuration parameter. ΓòÉΓòÉΓòÉ 11.5.12. Minimize Client DASD Space ΓòÉΓòÉΓòÉ To reduce client DASD disk space, new CID-enabled product versions should either overlay their prior version files during install or delete them before installation to reduce DASD space requirements for client workstations. ΓòÉΓòÉΓòÉ 11.5.13. Use of the Response File INCLUDE Keyword to Eliminate Redundancy ΓòÉΓòÉΓòÉ Use of the Include keyword in client-unique product response files eliminates redundant specification of common parameters for a set of clients. The Include keyword refers to the common response file. ΓòÉΓòÉΓòÉ 11.5.14. Code Server File System ΓòÉΓòÉΓòÉ Use HPFS for code server workstations. ΓòÉΓòÉΓòÉ 11.5.15. Maximize Physical Block Size for Client/Server Data Transmission ΓòÉΓòÉΓòÉ CID-enabled install programs should transfer large rather than small blocks of product images from the code server. ΓòÉΓòÉΓòÉ 11.5.16. Network Product Install ΓòÉΓòÉΓòÉ CID-enabled products should consider installing their product on a network server to remove the administrative burden of maintaining the same product image files on each client workstation. This CID product attribute feature is known as "network awareness." There is a set of CID guidelines that details the items that need to be adhered to in order to be "network aware." ΓòÉΓòÉΓòÉ 11.5.17. Error Processing of Install Command Line Input Parameters ΓòÉΓòÉΓòÉ When a CID install procedure encounters an error in its command line input parameters, do not stop entering subsequent command line parameters because: o The /L: parameter for logging errors may occur after the parameter in error o All errors associated with command line parameters should become known with a single invocation of the CID install procedure This item is also applicable to response file parameters. ΓòÉΓòÉΓòÉ 11.5.18. CID Enablement of Product Service ΓòÉΓòÉΓòÉ Product servicing (for example, CSDs) should be CID enabled. In addition, service should be capable of being directly applied to product images residing on the code server. This procedure eliminates the two-step process of first installing the product on a client workstation and then applying the service at the client workstation. ΓòÉΓòÉΓòÉ 11.6. Handling of Locked Files ΓòÉΓòÉΓòÉ During a product installation in a multitasking platform such as OS/2, there is the possibility that certain files that are to be replaced by the installation procedure are already in use by another application running on the client. In this case, the file is locked by the operating system and cannot be directly replaced. In a CID environment, this is a condition that needs to be taken into account. This is because the installation can be initiated by an administrator or software distribution manager that is not aware of the current state of the target system. Even if they are aware, there may be no way to avoid dealing with files that are locked by the operating system. This section discusses one method of handling locked files that was developed by IBM. The IBM LAN Server V3.0 and Extended Services products share many common functions and, as a result, use many of the same files. The solution outlined here was specifically designed for the IBM LAN Server V3.0 product, but it provides a model that can be used by developers to design a more generic solution. ΓòÉΓòÉΓòÉ 11.6.1. IBM LAN Server V3.0 Locked File Solution ΓòÉΓòÉΓòÉ The solution that is used by the IBM LAN Server V3.0 install/remove code process is outlined in the following list. If, during the install or remove process, a file is unable to be replaced or deleted, the following items are done: o If deleting the file, then the name of the file is saved along with an indication that it is to be deleted. This information is written to the file \OS2\INSTALL\IBMLANLK.LST. o If trying to replace a file, then the file is saved under a temporary directory (\IBMLANLK). The subdirectory structure under \IBMLANLK in which the file is saved is the same as the subdirectory structure where the file is to be replaced. For example, if the file SAMPLE.FIL was supposed to be copied to the D:\IBMLAN\NETPROG subdirectory, then it would be copied to the D:\IBMLANLK\IBMLAN\NETPROG subdirectory. For every logical drive where locked files need to be replaced, the temporary subdirectory (\IBMLANLK) is created. The name of the file placed in the temporary subdirectory is also written to \OS2\INSTALL\IBMLANLK.LST. o At the end of the installation process, a device driver statement is added as the first device driver in CONFIG.SYS. The statement added is: DEVICE=X:\OS2\INSTALL\IBMLANLK.SYS X:\OS2\INSTALL\IBMLANLK.LST where X is the OS/2 boot drive. The next time the system is IPLed, this device driver is initialized and carries out its specialized function. The parameter passed to the device driver is the name of the locked file list generated by the installation program. IBM LAN Server V3.0 uses the name specified above; however, any name is acceptable to the Locked File Device Driver. The Locked File Device Driver (during its initialization phase) deletes any files that are in the list and copies the files from the temporary subdirectories to the subdirectories where they should have been installed. The Locked File Device Driver runs prior to any Local Security being activated and before loading the LAN system; therefore, the files are not currently locked while the Locked File Device Driver is running. Once the initialization phase is complete, the IPL is allowed to continue. The main part of the Locked File Device Driver performs no additional functions. The next time the system is IPLed, the Locked File Device Driver is not loaded. There is no requirement for this second IPL to take place in any specific time frame because the Locked File Device Driver has no ongoing function and will not affect the operation of the system. During the next IPL, the references to the Locked File Device Driver are removed from CONFIG.SYS, and other cleanup functions are performed. See note IBM LAN Server V3.0 Locked File Solution. By designing the Locked File Device Driver in this manner, the locked file problem can be resolved with a single re-IPL. Note: 1. The Locked File Device Driver is also used to install code that cannot be installed while running the main installation/configuration program. Code such as User Profile Management is installed in this manner. The User Profile Management code can be used by Extended Services or even by the installation/configuration program. It should not be deleted or replaced while in use. During installation of IBM LAN Server V3.0, all of the User Profile Management code is unpacked under the subdirectory \IBMLANLK. Within the \IBMLANLK subdirectory, it will be in the same structure as if installing User Profile Management in its permanent location. The Locked File Device Driver then installs the User Profile Management code on the re-IPL of the workstation. All code that is common to Extended Services and IBM LAN Server is treated in this manner. Code such as the installation/configuration program is also treated this way. 2. When the Locked File Device Driver runs, a program called IBMLANLK.EXE is also executed after the Locked File Device Driver has completed. The IBMLANLK.EXE program is started by the following RUN statement in CONFIG.SYS: RUN=X:\OS2\INSTALL\IBMLANLK.EXE X:\OS2\INSTALL\IBMLANLK.LST where X is the OS/2 boot drive and the parameter is the name of the locked file list generated by the main installation/configuration program. This statement is added to CONFIG.SYS at the same time as the device driver statement. The IBMLANLK.EXE program cleans up any requests that the Locked File Device Driver is unable to handle. The device driver is unable to delete subdirectories; this is done by the IBMLANLK.EXE program. In addition, IBMLANLK.EXE is capable of doing a DosExecPgm based on the contents of the IBMLANLK.LST file. This is used to run programs that must be executed after the IPL. The IBMLANLK.EXE program also removes the Locked File Device Driver and RUN= statements from CONFIG.SYS. This step is accomplished on the second IPL. 3. Because the Locked File Device Driver and the IBMLANLK.EXE program are responsible for the final deletion of files during a removal, they remain on the hard file. 4. The following commands are valid in the IBMLANLK.LST file: DEL (processed by Locked File DD if possible, else attempted by IBMLANLK.EXE) DELETE (processed by Locked File DD if possible, else attempted by IBMLANLK.EXE) ERASE (processed by Locked File DD if possible, else attempted by IBMLANLK.EXE) MOVE (processed by Locked File DD if possible, else attempted by IBMLANLK.EXE) COPY (processed by Locked File DD if possible, else attempted by IBMLANLK.EXE) REN (processed by Locked File DD if possible, else attempted by IBMLANLK.EXE) RENAME (processed by Locked File DD if possible, else attempted by IBMLANLK.EXE) RMDIR (processed by IBMLANLK.EXE) RD (processed by IBMLANLK.EXE) MKDIR (processed by IBMLANLK.EXE) MD (processed by IBMLANLK.EXE) DOSX (this is a non-DOS function and results in a DosExecPgm being done). It is executed only by IBMLANLK.EXE. RMTREE (this removes the subdirectory and all subdirectories and files under the subdirectory). It is executed only by IBMLANLK.EXE. This command will not be executed if Local Security is in the process of being set up (i.e., SETSECUR is in STARTUP.CMD). SETSECUR causes a reboot and the RMTREE is executed after Local Security has been set up. Following is an example of how IBMLANLK.LST looks when reinstalling the LAN Server. Each command (that is, MOVE) is a single line in IBMLANLK.LST. RMTREE C:\IBMLANLK MOVE C:\IBMLANLK\IBMLAN\SERVICES\WKSTAHLP.EXE C:\IBMLAN\SERVICES\WKSTAHLP.EXE MOVE C:\IBMLANLK\IBMLAN\SERVICES\LSCLIENT.EXE C:\IBMLAN\SERVICES\LSCLIENT.EXE MOVE C:\IBMLANLK\IBMLAN\NETLIB\LRSE.DLL C:\IBMLAN\NETLIB\LRSE.DLL MOVE C:\IBMLANLK\IBMLAN\NETLIB\LRNO.DLL C:\IBMLAN\NETLIB\LRNO.DLL MOVE C:\IBMLANLK\IBMLAN\NETLIB\LRSD.DLL C:\IBMLAN\NETLIB\LRSD.DLL MOVE C:\IBMLANLK\IBMLAN\NETLIB\LRRS.DLL C:\IBMLAN\NETLIB\LRRS.DLL MOVE C:\IBMLANLK\IBMLAN\SERVICES\WKSTA.EXE C:\IBMLAN\SERVICES\WKSTA.EXE MOVE C:\IBMLANLK\IBMLAN\SERVICES\MSRV.EXE C:\IBMLAN\SERVICES\MSRV.EXE MOVE C:\IBMLANLK\IBMLAN\SERVICES\NETPOPUP.EXE C:\IBMLAN\SERVICES\NETPOPUP.EXE DOSX C:\IBMLAN\NETPROG\ADDSVRIN.EXE LANCESRV 2 C:\IBMLAN RMTREE C:\IBMLAN\INSTALL\IBMLAN\INSTALL\IBMCOM RMTREE C:\IBMLAN\INSTALL\IBMLAN RMDIR C:\IBMLAN\INSTALL Note: IBMLANLK.LST is first processed from top to bottom by the Locked File Device Driver. Any commands that it is capable of executing are executed and removed from the list. Next, the file is processed from top to bottom by IBMLANLK.EXE to clean up any commands that the Locked File Device Driver was unable to process. This explains why the line: RMTREE C:\IBMLANLK was valid in specifying the MOVEs. ΓòÉΓòÉΓòÉ 11.7. CID Enablement Considerations ΓòÉΓòÉΓòÉ The following flowcharts represent the CID enablement environment and the product code interfaces that need to be considered when enabling a product/program for the CID environment. The first chart should be read from top to bottom while focusing on the six enablement requirements. The second chart describes the interface parameter requirements of the program. ΓòÉΓòÉΓòÉ 11.7.1. CID Enablement Installation/Maintenance Scenario (LAN) ΓòÉΓòÉΓòÉ CID Enablement Installation/Maintenance Scenario (LAN) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ITEMS IN BOLD WITH UNDERLINE NEED PRODUCT SUPPORT FOR CID ENABLEMENT * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * PRODUCT / MAINTENANCE DISKETTES Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇ ΓöÉ Γöî Γö┤ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé CODE INSTALLED Γöî Γö┤ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé Γöé - SOFTWARE DISTRIBUTION MGR ( SDM ) ON SERVER AND CLIENT Γöé PRODUCT CODE Γöé Γöé Γöé - OS / 2 ON SERVER AND CLIENT Γöé - - - - - - - - - - - - - - - - - - - Γöé Γöé Γöé - SEE SDM DOCUMENTATION FOR ADDITIONAL PREREQs Γöé CODE THAT SUPPORTS Γöé Γöé Γöé Γöé THE UNATTENDED Γöé Γöé Γöé Γöé INSTALLATION OF THE Γöé Γö£ ΓöÇ Γöÿ Γöé APPLICATION / PROGRAM Γö£ ΓöÇ Γöÿ Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ TRANSFER PRODUCT DISKETTES TO ANY DIRECTORY FOR INSTALL ( PER PRODUCT INSTRUCTIONS / UTILITY ) " SERVER " Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö¼ ΓöÇΓöÇΓöÇ ΓöÉ Γöé Γöé Γöé Γöé Γöé S Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ D Γöé Γöé INSTALL CODE Γöé M Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé Γöé PRODUCT Γöé Γöé Γöé DISKETTES Γöé Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö┤ ΓöÇΓöÇΓöÇ Γöÿ USER CUSTOMIZES RESPONSE FILE ( RF ) AND ( PRODUCT SHOULD SHIP SAMPLE LOADS IN ANY DIRECTORY TO SUPPORT INSTALL RESPONSE FILES FOR EDITING ( PRODUCT SHOULD VERIFY RESPONSE FILE BY USER OR HAVE A SIMULATED FORMAT AND CONTENT ) INSTALL TO GENERATE RF ) Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö¼ ΓöÇΓöÇΓöÇ ΓöÉ Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé Γöé RESPONSE FILE Γöé S Γöé AT SERVER * OR CLIENT Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ D Γöé THE USER ISSUES START Γöé INSTALL CODE Γöé M Γöé PRODUCT INSTALL AS " CLIENT " ( MEMORY ) Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé DEFINED BY THE Γöî ΓöÇΓöÇΓöÇ Γö¼ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé PRODUCT Γöé Γöé SDM PROCEDURES Γöé Γöé COMMAND LINE Γöé Γöé DISKETTES Γöé Γöé Γöé S Γöé INSTALL IS Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö┤ ΓöÇΓöÇΓöÇ Γöÿ * SERVER CMD FLOWS TO CLIENT Γöé D Γöé ISSUED TO THE Γöé Γöé M Γöé PRODUCT AS A Γöé Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö¼ ΓöÇΓöÇΓöÇ ΓöÉ Γöé DOS EXEC PGM . Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé REQUEST PRODUCT CODE FROM Γöé Γöé START INSTALL Γöé Γöé RESPONSE FILE Γöé S Γöé THE DEFINED DIRECTORY Γöé Γöé REDIRECTED . Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ D Γöé Γöö ΓöÇΓöÇΓöÇ Γö┤ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ Γöé INSTALL CODE Γöé M Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé PRODUCT CODE IS INSTALLED ( HARDFILE ) Γöé PRODUCT Γöé Γöé USING INPUT FROM RF Γöî ΓöÇΓöÇΓöÇ Γö¼ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé DISKETTES Γöé Γöé Γöé Γöé PRODUCT CODE Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö┤ ΓöÇΓöÇΓöÇ Γöÿ Γöé S Γöé INSTALLED ON Γöé Γöé D Γöé TARGET DRIVE Γöé Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö¼ ΓöÇΓöÇΓöÇ ΓöÉ Γöé M Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé INFORM SDM OF COMPLETION Γöé Γöé < < < RETURN CODE Γöé Γöé RESPONSE FILE Γöé S Γöé Γöé Γöé COMPLETION Γöé Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ D Γöé SEND RETURN CODES AND Γöé Γöé ( DOS EXIT ) Γöé Γöé INSTALL CODE Γöé M Γöé LOGS AS DEFINED IN Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ Γö£ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöñ Γöé START INSTALL COMMAND Γöé PRODUCT Γöé Γöé Γöé DISKETTES Γöé Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γö┤ ΓöÇΓöÇΓöÇ Γöÿ ΓòÉΓòÉΓòÉ 11.7.2. Product Code Interface for CID Enablement ΓòÉΓòÉΓòÉ Product Code Interface for CID Enablement SDM Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé Start client Γöé Γöé operation is Γöé Γöé issued to the Γöé Γöé SDM . The SDM Γöé Γöé passes the CMD Γöé Γöé information to Γöé Γöé product program . Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ THE FOLLOWING PARAMETERS ARE PASSED TO THE INSTALL PROGRAM WHEN THE DOS EXEC PGM IS ISSUED / S : ( source ) / R : ( specific response file ) / G : ( general response file ) / L ( 1 - 5 ) : ( log file ) / T : ( target ) ( could include product unique parameters if required ) Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé PROGRAM Γöé Γöé INSTALL Γöé / L ( 1 - 5 ) : ( optional ) Γöé CODE Γöé Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ / S : ( optional ) Γöé Γöé Γöé This defines the Γöé A product might Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé Γöé Γöé path / file where Γöé define : Γöé This defines the Γöé Γöé Γöé Γöé product defined Γöé L1 = install Γöé path to get to Γöé Γöé Γöé Γöé logs will be sent Γöé history Γöé the product code Γöé Γöé Γöé Γöé during install . Γöé L2 = error info Γöé that will be Γöé Γöé Γöé Γöé Γöé Γöé installed . Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ Γöé Γöé Γöé Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ Γöé Γöé Γöé Γöé / T : ( optional ) Γöé / R : ( optional ) Γöé Γöé Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé / G : ( optional ) Γöé Γöé Γöé This describes Γöé Γöé Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé Γöé Γöé the subdirectory Γöé Γöé Γöé / R : defines the Γöé Γöé Γöé Γöé where the product Γöé Γöé Γöé path and name of Γöé Γöé Γöé Γöé will be installed Γöé Γöé Γöé response file Γöé Γöé RC TO Γöé Γöé in the target Γöé Γöé Γöé / G : defines the Γöé Γöé SDM Γöé Γöé workstation . Γöé Γöé Γöé path to the Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ Γöé Γöé Γöé Γöé general response Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ Γöé Γöé file ( optional ) Γöé Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ RETURN TO SDM UPON : Γöé - SUCCESSFUL COMPLETION Γöé - INABILITY TO ACCESS A DATA RESOURCE Γöé - DISK ERROR / UNEXPECTED CONDITION Γöé - REBOOT REQUIRED Γöé - ETC . Γöé Γöé SDM Γöî ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γö¼ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÉ Γöé control is given Γöé logs are passed back to Γöé Γöé back to initiator Γöé SDM for user action Γöé Γöö ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Γö┤ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇ Γöÿ 
(.txt)