
  CONTENTS
  ________

  1.0 ...PREFACE
  2.0 ...INTRODUCTION
  3.0 ...CODE SERVER SETUP
    3.1 ...LOADING THE DISKETTE IMAGES ON THE CODE SERVER
      3.1.1 ...LOADING THE DISKETTE IMAGES ON THE CODE SERVER FROM CDROM
      3.1.2 ...LOADING THE DISKETTE IMAGES ON THE CODE SERVER FROM DISKETTE
        3.1.2.1 ...LAYOUT OF THE INSTALLATION DISKETTES
        3.1.2.2 ...USING AN OS/2 2.x CODE SERVER
        3.1.2.3 ...OBTAINING THE SEIMAGE PROGRAM FROM THE OS/2 DISKETTES
        3.1.2.4 ...COPYING THE DISKETTE IMAGES TO THE CODE SERVER USING SEIMAGE
    3.2 ...EXTRACTING THE CID UTILITIES FROM THE OS/2 IMAGES
    3.3 ...EXTRACTING THE SETBOOT AND XCOPY PROGRAMS FROM THE OS/2 IMAGES
    3.4 ...EXTRACTING THE REXX FILES FROM THE OS/2 IMAGES
  4.0 ...CREATING CID BOOT DISKETTES
  5.0 ...CREATING HARD DISK BASED MAINTENANCE ENVIRONMENTS
  6.0 ...INSTALLING OS/2 ON THE CLIENT
  7.0 ...SVGA CID UTILITY
  8.0 ...CID ENABLED MULTIMEDIA
  9.0 ...NEW VERSIONS OF THE GET UTILITIES
 10.0 ...USING A RESPONSE FILE TO INSTALL OS/2
   10.1 ...RSPINST RETURN CODES
 11.0 ...CID INSTALL BONUSPACK USING CLIFI NOTES
 12.0 ...TME 10 NETFINITY CID NOTES
 13.0 ...Installing Network SignON Coordinator (NSC/2) via NVDM/2
 14.0 ...TRADEMARKS

*** 1.0 ...PREFACE ***

This readme file will reference several IBM* products that support the
execution of  OS/2* CID installs:

o LAN CID Utility -- a lightly attended installation mechanism that ships
  with Network Transport Servers/2 (NTS/2) and the Multi-Protocol Transport
  Services (MPTS) program available with LAN Server 4.0.

o NetView* Distribution Manager (NetView DM) OS/2 Products -- the NetView DM
  family of products provides a cross platform software distribution
  mechanism.  The OS/2 components of NetView DM are NetView Distribution
  Manager/2 (NVDM/2) and NetView Distribution Manager Agent/2 (NVDMA/2).
  NVDM/2 provides for software distribution from OS/2 code servers and
  NVDMA/2 provides for software distribution from AIX* or NetWare code
  servers.


*** 2.0 ...INTRODUCTION ***

It is possible to do a redirected or CID installation of OS/2 to
a client workstation from a code server.  There are three basic
steps that are needed to facilitate this:

1. Code server setup.
2. Boot diskette or maintenance environment creation.
3. CID installation of OS/2.


The first step, "Code server setup" can be further broken
down into the following steps:

1. Copy the diskette images to the code server.
2. Extract the CID utilities from the OS/2 images.
3. If LAN CID Utility is being used:
     a) Extract the SETBOOT and XCOPY programs from the OS/2 images
     b) Extract the REXX files from the OS/2 images


*** 3.0 ...CODE SERVER SETUP ***

*** 3.1 ...LOADING THE DISKETTE IMAGES ON THE CODE SERVER

In order to CID install OS/2, the OS/2 installation diskette images must be
accessible to the client workstations from the code server.

If you have OS/2 only on diskettes, then you must copy the diskettes to the
code server using the procedures outlined in "LOADING THE DISKETTE IMAGES ON
THE CODE SERVER FROM DISKETTE" and its accompanying sub-sections.

If you have OS/2 on a CDROM, then you can either share the CDROM directly
to the client workstations or use the procedures outlined in "LOADING THE
DISKETTE IMAGES ON THE CODE SERVER FROM CDROM" to copy the diskette images
from the CDROM to the hard disk of the code server.


*** 3.1.1 ...LOADING THE DISKETTE IMAGES ON THE CODE SERVER FROM CDROM

To load the diskette images on the code server from a CDROM, run
the following command:

    XCOPY  source_path  target_path  /S

Parameters:

    source_path - the path to the "root" of the OS/2 diskette images on the
                  CDROM.  For example, if the files from the OS/2
                  installation diskette #1 are in the directory
                  G:\OS2DISKS\DISK_1 on the CDROM, then this parameter
                  would be G:\OS2DISKS.

    target_path - the path to the target subdirectory to which the OS/2
                  diskette images are to be copied.


Example:

    XCOPY G:\OS2V40 C:\CID\IMG\OS2V40 /S


Note:  The /S parameter means to copy everything including the files
       and subdirectories residing within subdirectories of the source
       path.


*** 3.1.2 ...LOADING THE DISKETTE IMAGES ON THE CODE SERVER FROM DISKETTE ***

*** 3.1.2.1 ...LAYOUT OF THE INSTALLATION DISKETTES ***

Most of the OS/2 Warp Version 4 installation diskettes use a high capacity diskette
format called XDF to reduce the number of diskettes and time needed for
OS/2 installation.  The diskettes that use the XDF format have a software
write protection.  XDF format diskettes can only be read or backed up;
you cannot erase, modify, or add files to the XDF format diskettes.

Only the INSTALLATION diskette, Diskette #1, and Diskette #2 are NOT XDF
format diskettes.  Since these diskettes are not XDF format, you can modify,
add, and delete files on these diskettes using standard commands
(DIR, COPY, DISKCOPY, etc.).

Note:  The XDFCOPY utility on the INSTALLATION diskette can be used
       to backup the XDF format diskettes.  To back up an XDF format
       diskette with XDFCOPY, run the following command:

           XDFCOPY <diskette_drive> <backup_file_name>

       Example:

           XDFCOPY A: DISK2.XDF


*** 3.1.2.2 ...USING AN OS/2 2.x CODE SERVER ***

If you are using an OS/2 2.x system for your code server, you must
make some modifications to your system in order to read the
OS/2 Warp Version 4 XDF format installation diskettes.  OS/2 Warp Version 4
systems will read these diskettes without any modification.

To modify your OS/2 2.x system so that it can read the OS/2 Warp Version 4
XDF format installation diskettes, do the following:

o ISA-bus Systems:

  1. Rename IBM1FLPY.ADD to IBM1FLPY.OLD in the \OS2 directory.
  2. Copy XDFLOPPY.FLT and IBM1FLPY.ADD from diskette #1 to the \OS2 directory.
  3. Add the following line to your CONFIG.SYS file:

         BASEDEV=XDFLOPPY.FLT

o Micro Channel*-bus Systems:

  1. Rename IBM2FLPY.ADD to IBM2FLPY.OLD in the \OS2 directory.
  2. Copy XDFLOPPY.FLT and IBM2FLPY.ADD from diskette #1 to the \OS2 directory.
  3. Add the following line to your CONFIG.SYS file

         BASEDEV=XDFLOPPY.FLT


Note: OS/2 1.x systems cannot be used to read the OS/2 Warp Version 4
XDF format installation diskettes.


*** 3.1.2.3 ...OBTAINING THE SEIMAGE PROGRAM FROM THE OS/2 DISKETTES ***

SEIMAGE is the program that loads the OS/2 diskette images onto
the code server from diskette.  SEIMAGE.EXE resides in the CID pack file on
diskette 7.  The following steps are required to unpack this program from the
CID pack file on diskette 7 into the proper directory.  Substitute
the desired path for C:\CID\EXE\V400.

1. Insert diskette 2 in drive A: and run the following command:

   COPY A:UNPACK* C:\CID\EXE\V400

2. Insert diskette 7 in drive A: and run the following command:

   C:\CID\EXE\V400\UNPACK A:\CID C:\CID\EXE\V400 /N:SEIMAGE.EXE


Note: The C:\CID\EXE\V400 is the convention used under the LAN CID Utility
      for the versions specific executable files. The NetView DM family
      conventions place the version specific executables in the root image
      directory for that product, such as D:\SHAREA\IMG\OS2V40.


*** 3.1.2.4 ...COPYING THE DISKETTE IMAGES TO THE CODE SERVER USING SEIMAGE ***

Once the SEIMAGE program has been unpacked from the CID pack file,
it can be used to copy the OS/2 diskette images to the code server.
SEIMAGE can be run from an OS/2 command line.

Following is the SEIMAGE syntax:

   SEIMAGE /S:source_path  /T:target_path

   The following describes the SEIMAGE parameters:

        /S:source_path - The fully qualified path from which the
                         product images are loaded.  This parameter
                         is required and is usually A:\.

        /T:target_path - The fully qualified path to the target
                         subdirectory to which the product images are
                         to be loaded.  This parameter is required.

   Example:

        SEIMAGE /S:A: /T:D:\CID\IMG\OS2V40


    *** Windows Support -


 *****IMPORTANT** READ BEFORE USING THE UTILITY *****

 THIS NEW FEATURE HAS BEEN PROVIDED TO ASSIST
 THE DOWNLOADING AUTHORIZED LICENSED COPIES OF MS WINDOWS
 FOR USE WITH OS/2 WARP. YOU SHOULD ONLY DOWNLOAD THE NUMBER
 OF COPIES OF WINDOWS FOR WHICH YOU ARE LICENSED. IN PROVIDING
 YOU THIS UTILITY IBM DOES NOT AUTHORIZE YOU TO MAKE ANY
 ADDITIONAL COPIES OF WINDOWS FOR WHICH YOU HAVE NOT BEEN AUTHORIZED
 TO MAKE BY THE MICROSOFT CORPORATION.


        If the OS/2 system is an OS/2 for Windows product,
        then the user will be prompted for handling Windows
        diskettes after the OS/2 product images are loaded.
        The user responds Y or N.  If the response is yes,
        then the user is asked to supply a subdirectory name.
        This subdirectory name will be appended to the target
        subdirectory where the OS/2 product images were loaded.

        For example, if the target subdirectory is D:\OS2V40
        and the Windows subdirectory supplied in response to
        the prompt is WIN31, then the path where the the Windows
        images will be loaded will be D:\OS2V40\WIN31.  So the
        final Directory structure will look like this:

        D:\
         |
         |-- OS2V40\
                |
                |------DISK_1
                |
                |------DISK_2
                |
                |------DISK_3
                |
                |------ ...
                |
                |------PMDD_3
                |
                |------WIN31\
                         |
                         |------DISK_W1
                         |
                         |------DISK_W2
                         |
                         |------ ...
                         |
                         |------DISK_WN


        Note that if the user does not type in a Windows
        subdirectory name to be appended to the the target
        subdirectory, then the Windows diskette images will be
        placed directly in the target subdirectory.

        Also, the user may load the diskette images for more than
        one set of Windows Diskettes.  After a set of Windows
        diskettes is copied, the user will be prompted as to
        whether another set of Windows diskettes need to be copied.
        If the response is yes, then the user will be prompted again
        for a subdirectory name and the process starts over.


*** 3.2 ...EXTRACTING THE CID UTILITIES FROM THE OS/2 IMAGES ***

The programs and files that are required for the redirected installation
of OS/2 are packed in files on the diskettes that were copied to the
code server in "LOADING THE DISKETTE IMAGES ON THE CODE SERVER ".  The
GETOSCID command file is provided to unpack the following and files
from the OS/2 diskette images:

        RSPINST.EXE
        SAMPLE.RSP
        SEDISK.EXE
        SEIMAGE.EXE
        SEINST.EXE
        SEMAINT.EXE
        UNPACK.EXE
        UNPACK2.EXE

Following is the syntax of GETOSCID:

   GETOSCID  source_path  <target_path>

   The following describes the GETOSCID parameters:

        source_path    - The path where the OS/2 product images have
                         been placed.  This parameter is required.

        <target_path>  - The path to the subdirectory where the files
                         should be placed.  This path must be accessible
                         to the client through a redirector such as SRVIFS.
                         This parameter is optional and defaults to the
                         current directory.

   Example:

        GETOSCID D:\CID\IMG\OS2V40 D:\CID\EXE\V400


Note: The GETOSCID command file can be found in "NEW VERSIONS OF THE GET
      UTILITIES".  You can also use the GETOSCID.CMD provided with
      the LAN CID Utility 2.0 program that ships with MPTS.  If you are
      using NVDM or the LAN CID Utility program that ships with NTS/2,
      then you should use the GETOSCID provided in this readme.


*** 3.3 ...EXTRACTING THE SETBOOT AND XCOPY PROGRAMS FROM THE OS/2 IMAGES ***

If you will be using LAN CID Utility to install OS/2 on your client
workstations, then it is necessary to obtain the SETBOOT and XCOPY programs
from the OS/2 diskette images on the code server.  The GETBOOT command file
is provided to unpack the following and files from the OS/2 diskette
images:

        SETBOOT.EXE
        XCOPY.EXE

Following is the syntax of GETBOOT:

   GETBOOT  source_path  <target_path>

   The following describes the GETBOOT parameters:

        source_path    - The path where the OS/2 product images have been
                         placed.  This parameter is required.

        <target_path>  - The path to the subdirectory where the files should be
                         placed.  This path must be accessible to the client
                         through a redirector such as SRVIFS or LAN Requester.
                         This parameter is optional and defaults to the current
                         directory.

   Example:

        GETBOOT D:\CID\IMG\OS2V40 D:\CID\EXE\V400


Note: The GETBOOT command file can be found in "NEW VERSIONS OF THE GET
      UTILITIES".  You can also use the GETBOOT.CMD provided with
      the LAN CID Utility 2.0 program that ships with MPTS.  If you are
      using the LAN CID Utility program that ships with NTS/2, then you
      should use the GETBOOT provided in this readme.


*** 3.4 ...EXTRACTING THE REXX FILES FROM THE OS/2 IMAGES ***

If you will be using LAN CID Utility to install OS/2 on your client
workstations, then it is necessary to obtain the REXX files
from the OS/2 diskette images on the code server.  The GETREXX command file
is provided to unpack the following files from the OS/2 diskette images:

        INSCFG32.DLL
        OSO001.MSG
        SHPIINST.DLL
        REX.MSG
        REXH.MSG
        REXX.DLL
        REXXAPI.DLL
        REXXINIT.DLL
        REXXTRY.CMD
        REXXUTIL.DLL
        RXQUEUE.EXE

Following is the syntax of GETREXX:

   GETREXX  source_path  <target_path>

   The following describes the GETREXX parameters:

        source_path    - The path where the OS/2 product images have
                         been placed.  This parameter is required.

        <target_path>  - The path to the subdirectory where the files
                         should be placed.  This path must be accessible
                         to the client through a redirector such as SRVIFS.
                         This parameter is optional and defaults to the
                         current directory.

   Example:

        GETREXX D:\CID\IMG\OS2V40 D:\CID\DLL\V400


Note: The GETREXX command file can be found in "NEW VERSIONS OF THE GET
      UTILITIES".  Use this version of GETREXX.



*** 4.0 ...CREATING CID BOOT DISKETTES ***

When installing OS/2 it is often necessary to create boot diskettes for
use at the client workstation.  There are several steps required
for creating the CID boot diskettes.  The first step is to run
the SEDISK program provided with OS/2.  This command must be run on
a system with of same version.  Following is the SEDISK syntax:

   SEDISK /S:source_path  /T:target_path /P:<pcmcia_id#>

   The following describes the SEDISK parameters:

        /S:source_path   - The fully qualified path to the OS/2 images.
                           This parameter is required.

        /T:target_path   - The drive indicator of the diskette drive where
                           the boot diskettes will be created.  This parameter
                           is required.

        /P:<pcmcia_id#>  - This optional parameter is used when pcmcia driver
                           support is needed.  When the /P: option is used,
                           the PCMCIA.SYS driver (as well as the appropriate
                           socket driver) will be copied over to diskette
                           one.  The pcmcia_id# represents a number associated
                           with the computer desired.  Look at the default
                           response file at the keyword PCMCIA to figure out
                           what number to put in here.  For example /P:1 would
                           be used if you need to boot on an AMBRA486 SN425C.
                           pcmcia_id# must be a number representing a valid
                           parm of keyword PCMCIA in the default response file.
                           pcmcia_id# can not be 0.


   Example:

        SEDISK /S:D:\CID\IMG\OS2V40 /T:A:

Note: Since boot diskettes are specific to the software distribution manager
      being used, to complete the boot diskette creation, follow the
      instructions provided by your software distribution manager.


*** 5.0 ...CREATING HARD DISK BASED MAINTENANCE ENVIRONMENTS ***

The SEMAINT command installs a minimal version of the OS/2 program on a
workstation hard disk.  This minimal OS/2, also known as a maintenance system,
does not contain the Presentation Manager* or Workplace Shell* features of the
OS/2 program.  When booted on a maintenance system, the normal system files
are not locked.  The OS/2 install program (SEINST) and Service Pak install
program (FSERVICE) run under the maintenance system created by SEMAINT or on
boot diskettes created by SEDISK.  Following is the SEMAINT syntax:

   SEMAINT /S:source_path /T:target_path /B:boot_drive /L1:log_file
           /S2:<service_pak_path> /P:<pcmcia_id#>

   The following describes the SEMAINT parameters:

        /S:source_path   - The fully qualified path to the OS/2 images.
                           This parameter is required.

        /T:target_path   - The fully qualified target directory name.
                           The maintenance system will be installed in
                           this directory.  This must be on one of the
                           workstation's local drives.  This parameter is
                           required.

        /B:boot_drive    - The drive from which the seed system will boot.
                           This must be on a local drive.  This parameter is
                           required.

        /L1:log_file     - The fully qualified name of the file into which
                           log information is to be placed.  The directory
                           in which the log file is to be placed must
                           already exist.  This parameter is required.

        /S2:<service_pak_path>
                         - The fully qualified path to the OS/2 Service Pak
                           images.  This parameter is used to apply Service Pak
                           fixes to the maintenance system being created.

                           This parameter is optional.  When used, the /S2:
                           parameter should point to the same version of the
                           Service Pak as was previously applied to the
                           workstation.  This is especially important when
                           applying a Service Pak other than an OS/2 Service
                           Pak, such as LAN Server Service Pak, when running
                           under the maintenance system created by SEMAINT.
                           If the /S2:  parameter is not supplied in this
                           case, you run the risk of the OS2KRNL and OS2LDR
                           being the wrong level when the system is returned
                           to its normal environment.

                           Refer to the following notes for some guidelines
                           on the use of this parameter.

        /P:<pcmcia_id#>  - This optional parameter is used when pcmcia driver
                           support is needed.  When the /P: option is used,
                           the PCMCIA.SYS driver (as well as the appropriate
                           socket driver) will be copied over to the boot
                           drive.  The pcmcia_id# represents a number associated
                           with the computer desired.  Look at the default
                           response file at the keyword PCMCIA to figure out
                           what number to put in here.  For example /P:1 would
                           be used if you need to boot on an AMBRA486 SN425C.
                           pcmcia_id# must be a number representing a valid
                           parm of keyword PCMCIA in the default response file.
                           pcmcia_id# can not be 0.


        Notes:

          1. If the target directory (/T:) is an HPFS drive, then the boot drive
             (/B:) must also be an HPFS drive.

          2. Service Pak fixes need to be applied to the maintenance system with
             the /S2: parameter when:

               o Installing an OS/2 Service Pak (XR06200, XR06300, etc.)
               o Installing a non-OS/2 Service Pak, such as LAN Server, on a
                 client that already has an OS/2 Service Pak applied.

          3. Service Pak fixes should NOT be applied to the maintenance system
             with the /S2: parameter when:

               o Migrating to a new base OS/2 Release.
               o Installing a non-OS/2 Service Pak on a client that has OS/2 at
                 a base level (ie, no Service Pak applied).

          4. Usage of the SEMAINT /S2: parameter with OS/2 Warp Version 4
             will not be needed until the first Service Pak for OS/2 Warp Version 4
             is released.


   Example for building a maintenance system for installing OS/2 Warp Version 4:

        X:\EXE\V400\SEMAINT /S:X:\IMG\OS2V40 /T:C:\SERVICE /B:C:
                            /L1:X:\LOG\OS2V40\CLIENT.LOG

   Example for building a maintenance system for applying an OS/2 V4
   Service Pak to a client, where XR0nnnn is the Service Pak number
   being applied:

        X:\EXE\V400\SEMAINT /S:X:\IMG\OS2V40 /T:C:\SERVICE /B:C:
                            /L1:X:\LOG\OS2V40\CLIENT.LOG
                            /S2:X:\CSD\OS2V40\XR0nnnn

   Example for building a maintenance system for applying a non-OS/2
   Service Pak to a client that has OS/2 V4 Service Pak XR0nnnn installed
   on it:

        X:\EXE\V400\SEMAINT /S:X:\IMG\OS2V40 /T:C:\SERVICE /B:C:
                            /L1:X:\LOG\OS2V40\CLIENT.LOG
                            /S2:X:\CSD\OS2V40\XR0nnnn


Note:  Since complete maintenance systems are specific to the software
       distribution manager being used, to complete the maintenance system
       creation, follow the instructions provided by your software distribution
       manager.


*** 6.0 ...INSTALLING OS/2 ON THE CLIENT ***

The SEINST program installs the OS/2 program on the client workstation.  SEINST
is normally run under a maintenance system created by SEMAINT or on boot
diskettes created by SEDISK.

SEINST runs RSPINST.EXE, which reads the named response file and performs
the installation.  If SEINST is run under a maintenance system created by
SEMAINT, SEINST also cleans up the directory from which the system was booted.

Following is the SEINST syntax:

   SEINST /S:source_path /T:<target_path> /B:boot_drive /L1:log_file
          /R:response_file

   The following describes the SEINST parameters:

        /S:source_path   - The fully qualified path to the OS/2 images.
                           This parameter is required.

        /T:<target_path> - The fully qualified path to the target
                           directory from which the system was booted.
                           If the system was booted from a maintenance system
                           on the hard disk, this path matches the /T:
                           parameter passed on the previous invocation of the
                           SEMAINT program.

                           This parameter is required if booted from the hard
                           disk, but optional if booted from diskette.  If this
                           parameter is specified when booted from diskette, no
                           parameter validation is done on its value.

                           WARNING:  Because SEINST deletes all files as it
                           cleans up this subdirectory, back up the files you
                           want to save.

        /B:boot_drive    - The target boot drive from which the system
                           boots after installation.  The drive must be
                           a local drive.  This parameter is required.

        /L1:log_file     - The fully qualified name of the file into which
                           log information is to be placed.  The directory
                           in which the log file is to be placed must
                           already exist.  This parameter is required.

        /R:response_file - The fully qualified file name of the response file
                           supported by RSPINST.  This parameter is required.


   Example when booted from boot diskettes:

        X:\EXE\V400\SEINST /S:X:\IMG\OS2V40 /B:C: /R:X:\RSP\OS2V40\RESPONSE.FIL
                           /L1:X:\LOG\OS2V40\CLIENT.LOG

   Example when booted from maintenance system:

        X:\EXE\V400\SEINST /S:X:\IMG\OS2V40 /B:C: /R:X:\RSP\OS2V40\RESPONSE.FIL
                           /L1:X:\LOG\OS2V40\CLIENT.LOG /T:C:\SERVICE

NOTE:  For more information about the program RSPINST, look at the section
       "USING A RESPONSE FILE TO INSTALL OS/2".  This section describes
       running response file install from diskette and might be beneficial
       for understanding response file installation.  RSPINST error codes
       are listed in the section "RSPINST RETURN CODES".


*** 7.0 ...SVGA CID UTILITY ***

SVGA CID installation would be invoked as a post install method after
booting into a PM based environment.  DSPINSTL.EXE is found in the
OS2\INSTALL directory.

Following is the DSPINSTL syntax:

   DSPINSTL /PD:dsc_file /S:source_path /T:target_drive /RES:resolution /U

   The following describes the DSPINSTL parameters:

        /PD:dsc_file    - The fully qualified .DSC file name.

        /S:source_path  - The fully qualified path to the OS/2 images.

        /T:target_drive - The target drive or bootdrive.

        /RES:resolution - The resolution to come up in after reboot.

        /U              - Indicates unattended installation.


        Notes:

          1. If a resolution was passed in that is not supported in the
             .PMI file then an error will occur.

          2. If a resolution was passed in that is in the .PMI and not
             supported by the driver, then driver should default to low
             resolution.


Example of installing S3** CHIP 86C805 at resolution 1024x768x256 via CID:

DSPINSTL /PD:C:\OS2\INSTALL\PSS3.DSC /S:X:\IMG\OS2V40 /T:C: /RES:1024x768x256 /U



This is a list of .DSC files and the chip sets.


pshead.dsc          "Headland Technology** HT209"
VIDEO7_HT205_CHIP = 1
VIDEO7_HT208_CHIP = 2
VIDEO7_HT209_CHIP = 3

pstrid.dsc         "Trident** Microsystems TVGA8900c"
TRIDENT_8800_CHIP = 1
TRIDENT_8900_CHIP = 2


pstseng.dsc        "Tseng** Laboratories ET4000"
TSENG_ET3000_CHIP = 1
TSENG_ET4000_CHIP = 2

tliw32.dsc         "Tseng Laboratories ET4000/W32, /W32i, /W32p"
TSENG_ET4000W32_CHIP   = 3
TSENG_ET4000W32I_CHIP  = 4
TSENG_ET4000W32IB_CHIP = 5
TSENG_ET4000W32IC_CHIP = 6
TSENG_ET4000W32PA_CHIP = 7
TSENG_ET4000W32PB_CHIP = 8
TSENG_ET4000W32PC_CHIP = 9


pswd.dsc          "Western Digital** WD90C11, C30, C31 (C30 mode only)"
WESTERNDIG_PVGA1A_CHIP = 1
WESTERNDIG_WD9000_CHIP = 2
WESTERNDIG_WD9011_CHIP = 3
WESTERNDIG_WD9030_CHIP = 4
WESTERNDIG_WD9026_CHIP = 5
WESTERNDIG_WD9027_CHIP = 6



pswdc31.dsc       "Western Digital 90C31"
WESTERNDIG_WD9031_CHIP = 7

pswdc24.dsc       "Western Digital 90C24"
WESTERNDIG_WD9024_CHIP = 8

wdc33.dsc         "Western Digital 90C33"
WESTERNDIG_WD9033_CHIP = 9


psati.dsc         "ATI** Mach8, ATI 28800"
ATI_18800_CHIP = 1
ATI_28800_CHIP = 2


ATI_38800_CHIP = 3        8514 CHIP not SVGA

atim32.dsc        "ATI Mach32"
ATI_68800_CHIP = 4

atim64.dsc        "ATI Mach64"
ATI_88800_CHIP = 5


psspdw.dsc        "IBM VGA 256c "
IBM_SVGA_CHIP  = 1


pscl.dsc          "Cirrus Logic** 5422, 5424"
CIRRUS_5420_CHIP = 1
CIRRUS_5422_CHIP = 2
CIRRUS_5424_CHIP = 3


cl54x.dsc         "Cirrus Logic 5426, 5428, 5430, 5434"
CIRRUS_5426_CHIP = 4
CIRRUS_5428_CHIP = 5
CIRRUS_5429_CHIP = 6
CIRRUS_543X_CHIP = 7
CIRRUS_5434_CHIP = 8


pss3.dsc          "S3 86C801, 86C805, 86C928"
S3_86C805_CHIP = 1
S3_86C928_CHIP = 2


s3864.dsc        "S3 864"
s38641m.dsc      "S3 864 (16M colors with 1MB of Video Mem)"
#define S3_86C864_CHIP = 4
#define S3_86C964_CHIP = 5


wp9000.dsc       "Weitek** Power 9000"
WEITEK_P9000_CHIP = 1

wp9100.dsc       "Weitek Power 9100"
WEITEK_W5186_CHIP = 2
WEITEK_W5286_CHIP = 3
WEITEK_P9100_CHIP = 4


Resolutions supported by each driver depend on factors such as:

1. amount of video memory
2. resolutions supported by driver


*** 8.0 ...CID ENABLED MULTIMEDIA ***

Multimedia has been enabled for CID.  Choose MULTIMEDIASUPPORT=1 in
the OS/2 response file.  This specifies to install the multimedia files
during the install.

Multimedia CID installation would be invoked as a post install method
after booting into a PM based environment.  MINSTALL.EXE is found in the
MMTEMP directory.  MINSTALL MUST BE RUN FROM THE MMTEMP SUBDIRECTORY.

Following is the MINSTALL syntax:

   MINSTALL /M  /C:<response_file> /R:<response_file>

   The following describes the MINSTALL parameters:

        /M      - This parameter is for telling MINSTALL.EXE to
                  transfer files off of the MMTEMP directory
                  and to the directory where the files need to be
                  for multimedia IPL.  This is required for CID.

        /C:<response_file> - This parameter is used when it is desired
                             to Create a response file.  This response
                             file will be used for unattended multimedia
                             installation of other machines using the
                             /R parameter.

        /R:<response_file> - This parameter is used when you have already
                             created a response file using the /C parameter.
                             A response file should only be used with
                             multimedia install if the machines hardware
                             setup is the same as the hardware setup of
                             the machine the response file was created on.


Recommended invocation of MINSTALL:

MINSTALL /M


Example of invoking MINSTALL while creating a response file:

MINSTALL /M  /C:MEDIA.RSP



*** 9.0 ...NEW VERSIONS OF THE GET UTILITIES ***

The GETOSCID, GETBOOT, and GETREXX command files referenced in
earlier sections in this readme file are shipped with the
LAN CID Utility 2.0 program provided with MPTS.  Copies of the
LAN CID Utility 2.0 version of GETOSCID.CMD, GETREXX.CMD, and
GETBOOT.CMD follow for those of you who do not have LAN CID Utility 2.0.

Using an editor, copy the section of this file that applies to
the desired command file into a file with the proper name.  For
example, copy the section pertaining to GETOSCID.CMD into a
file called GETOSCID.CMD.

Please note that all three of these command files contain lines that
are over 128 characters long.  Be sure to use an editor such as
the system editor (E) or the enhanced editor (EPM) to copy this text
into the proper file.

************************ GETOSCID.CMD ****************************
@ECHO OFF
REM GETOSCID 3.0
SETLOCAL
IF %1.==. ECHO GETOSCID source (target)
IF %1.==. GOTO END
REM
REM CHECK SOURCE DIRECTORY
REM
IF EXIST %1\DISK_3\UNPACK.EXE GOTO GETTAR
COPY %1\DISK_3\UNPACK.EXE
GOTO END

:GETTAR
SET PATH=%1;%PATH%
REM
REM GET TARGET DIRECTORY
REM
SET GC_TARGET=
IF %2.==. SET GC_TARGET=.
IF NOT %2.==. SET GC_TARGET=%2
IF %GC_TARGET%.==.. GOTO GETUNPACK
SET GC_MKDIR=
DIR %GC_TARGET%\*.*  >> NUL 2>>&1
IF ERRORLEVEL 1 SET GC_MKDIR=YES
IF %GC_MKDIR%.==YES. ECHO MD %GC_TARGET%
IF %GC_MKDIR%.==YES. MD %GC_TARGET%
IF ERRORLEVEL 1 GOTO END

:GETUNPACK

ECHO COPY %1\DISK_3\UNPACK*.EXE %GC_TARGET%
COPY %1\DISK_3\UNPACK*.EXE %GC_TARGET% > NUL
IF ERRORLEVEL 1 GOTO END

REM
REM GET THE CID PACK FILE
REM
ECHO %1\DISK_3\UNPACK %1\DISK_*\CID %GC_TARGET%
FOR %%I IN (3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\CID %1\DISK_3\UNPACK %1\DISK_%%I\CID %GC_TARGET% >> NUL 2>>&1
REM
REM GET THE REQUIRED PACK FILE FOR RSPINST.EXE
REM
ECHO %1\DISK_3\UNPACK %1\DISK_*\REQUIRED %GC_TARGET% /N:RSPINST.EXE
FOR %%I IN (3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\REQUIRED %1\DISK_3\UNPACK %1\DISK_%%I\REQUIRED %GC_TARGET% /N:RSPINST.EXE >> NUL 2>>&1
REM
REM GET THE REQUIRED PACK FILE FOR SAMPLE.RSP
REM
ECHO %1\DISK_3\UNPACK %1\DISK_*\REQUIRED %GC_TARGET% /N:SAMPLE.RSP
FOR %%I IN (3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\REQUIRED %1\DISK_3\UNPACK %1\DISK_%%I\REQUIRED %GC_TARGET% /N:SAMPLE.RSP >> NUL 2>>&1
REM
REM ENSURE THAT THE FILES WERE UNPACKED
REM
IF NOT EXIST %GC_TARGET%\SAMPLE.RSP  COPY %GC_TARGET%\SAMPLE.RSP
IF NOT EXIST %GC_TARGET%\RSPINST.EXE COPY %GC_TARGET%\RSPINST.EXE
IF NOT EXIST %GC_TARGET%\SEINST.EXE  COPY %GC_TARGET%\SEINST.EXE
:END
ENDLOCAL

************************ GETREXX.CMD ****************************
@ECHO OFF
REM GETREXX 3.0
SETLOCAL
IF %1.==. ECHO GETREXX source (target)
IF %1.==. GOTO END
REM
REM CHECK SOURCE DIRECTORY
REM
IF EXIST %1\DISK_3\*.* GOTO GETTAR
COPY %1\DISK_3\*.*
GOTO END

:GETTAR
SET PATH=%1;%PATH%
REM
REM GET TARGET DIRECTORY
REM
SET GR_TARGET=
IF %2.==. SET GR_TARGET=.
IF NOT %2.==. SET GR_TARGET=%2
IF %GR_TARGET%.==.. GOTO CHKUNPACK
SET GR_MKDIR=
DIR %GR_TARGET%\*.*  >> NUL 2>>&1
IF ERRORLEVEL 1 SET GR_MKDIR=YES
IF %GR_MKDIR%.==YES. ECHO MD %GR_TARGET%
IF %GR_MKDIR%.==YES. MD %GR_TARGET%
IF ERRORLEVEL 1 GOTO END

:CHKUNPACK
REM
REM CHECK FOR UNPACK.EXE IN THE DISK_3 DIRECTORY
REM
IF EXIST %1\DISK_3\*.* GOTO UNPACK
COPY %1\DISK_3\UNPACK.EXE
GOTO END
:UNPACK
ECHO %1\DISK_3\UNPACK %1\DISK_*\REXX %GR_TARGET%
FOR %%I IN (3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\REXX %1\DISK_3\UNPACK %1\DISK_%%I\REXX %GR_TARGET% >> NUL 2>>&1
ECHO %1\DISK_3\UNPACK %1\DISK_*\BUNDLE %GR_TARGET% /N:OSO001.MSG
FOR %%I IN (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\BUNDLE %1\DISK_3\UNPACK %1\DISK_%%I\BUNDLE %GR_TARGET% /N:OSO001.MSG >> NUL 2>>&1
ECHO %1\DISK_3\UNPACK %1\DISK_*\BUNDLE %GR_TARGET% /N:INSCFG32.DLL
FOR %%I IN (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\BUNDLE %1\DISK_3\UNPACK %1\DISK_%%I\BUNDLE %GR_TARGET% /N:INSCFG32.DLL >> NUL 2>>&1
ECHO %1\DISK_3\UNPACK %1\DISK_*\BUNDLE %GR_TARGET% /N:SHPIINST.DLL
FOR %%I IN (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\BUNDLE %1\DISK_3\UNPACK %1\DISK_%%I\BUNDLE %GR_TARGET% /N:SHPIINST.DLL >> NUL 2>>&1
ECHO COPY %1\DISK_*\UHPFS.DLL %GR_TARGET%
FOR %%I IN (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\UHPFS.DLL COPY %1\DISK_%%I\UHPFS.DLL %GR_TARGET% >> NUL 2>>&1
REM
REM ENSURE THAT THE FILES WERE UNPACKED
REM
IF NOT EXIST %GR_TARGET%\*REX*.* COPY %GR_TARGET%\*REX*.*
IF NOT EXIST %GR_TARGET%\OSO001.MSG COPY %GR_TARGET%\OSO001.MSG
:END
ENDLOCAL


************************ GETBOOT.CMD ****************************
@ECHO OFF
REM GETBOOT 3.0
SETLOCAL
IF %1.==. ECHO GETBOOT source (target)
IF %1.==. GOTO END
REM
REM CHECK SOURCE DIRECTORY
REM
IF EXIST %1\DISK_3\*.* GOTO GETTAR
COPY %1\DISK_3\*.*
GOTO END

:GETTAR
SET PATH=%1;%PATH%
REM
REM GET TARGET DIRECTORY
REM
SET GB_TARGET=
IF %2.==. SET GB_TARGET=.
IF NOT %2.==. SET GB_TARGET=%2
IF %GB_TARGET%.==.. GOTO CHKUNPACK
SET GB_MKDIR=
DIR %GB_TARGET%\*.*  >> NUL 2>>&1
IF ERRORLEVEL 1 SET GB_MKDIR=YES
IF %GB_MKDIR%.==YES. ECHO MD %GB_TARGET%
IF %GB_MKDIR%.==YES. MD %GB_TARGET%
IF ERRORLEVEL 1 GOTO END

:CHKUNPACK
REM
REM CHECK FOR UNPACK.EXE IN THE DISK_3 DIRECTORY
REM
IF EXIST %1\DISK_3\*.* GOTO UNPACK
COPY %1\DISK_3\UNPACK.EXE
GOTO END

:UNPACK
ECHO %1\DISK_3\UNPACK %1\DISK_*\BUNDLE %GB_TARGET% /N:SETBOOT.EXE
FOR %%I IN (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\BUNDLE %1\DISK_3\UNPACK %1\DISK_%%I\BUNDLE %GB_TARGET% /N:SETBOOT.EXE >> NUL 2>>&1
ECHO %1\DISK_3\UNPACK %1\DISK_*\FDISK  %GB_TARGET% /N:SETBOOT.EXE
FOR %%I IN (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\FDISK  %1\DISK_3\UNPACK %1\DISK_%%I\FDISK  %GB_TARGET% /N:SETBOOT.EXE >> NUL 2>>&1
ECHO %1\DISK_3\UNPACK %1\DISK_*\BUNDLE %GB_TARGET% /N:XCOPY.EXE
FOR %%I IN (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\BUNDLE %1\DISK_3\UNPACK %1\DISK_%%I\BUNDLE %GB_TARGET% /N:XCOPY.EXE >> NUL 2>>&1
ECHO %1\DISK_3\UNPACK %1\DISK_*\REQUIRED %GB_TARGET% /N:XCOPY.EXE
FOR %%I IN (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF EXIST %1\DISK_%%I\REQUIRED %1\DISK_3\UNPACK %1\DISK_%%I\REQUIRED %GB_TARGET% /N:XCOPY.EXE >> NUL 2>>&1
REM
REM ENSURE THAT THE FILES WERE UNPACKED
REM
IF NOT EXIST %GB_TARGET%\SETBOOT.EXE COPY %GB_TARGET%\SETBOOT.EXE
IF NOT EXIST %GB_TARGET%\XCOPY.EXE COPY %GB_TARGET%\XCOPY.EXE
:END
ENDLOCAL



*** 10.0 ...USING A RESPONSE FILE TO INSTALL OS/2

This section describes how to use a response file to
install OS/2.  It is intended primarily for people
who will be setting up workstations for others to
use.

If you have installed previous versions of OS/2 or
other operating systems, you are familiar with
installation procedures that require you to insert
and remove a series of diskettes and answer screen
prompts.  When you use a response file to install, it
is not necessary to answer any screen prompts.  All
the answers are in a response file that you place on
installation Diskette 1.  The Installation program
reads the file from Diskette 1 instead of prompting
you for the installation information.

A sample response file is included on the OS/2
installation diskettes.  When you install the oper-
ating system, this response file (called SAMPLE.RSP)
is placed in the OS2\INSTALL directory.

The SAMPLE.RSP file and other files needed for a
response file installation are not automatically
installed on your system if you installed OS/2 using
the Easy Installation method.  You must add these
files to your system in order to use them.  Follow
these steps:

 1.  Open OS/2 System on your Desktop.

 2.  Open System Setup.

 3.  Open Selective Install.  The Software Configura-
     tion screen appears.

 4.  Select Optional System Utilities.

 5.  Select the More push button to the right of
     Optional System Utilities.  A  window appears
     with a list of utilities.

 6.  Place a check mark next to Installation Utili-
     ties; then select Install.

 7.  When prompted to do so, insert the requested
     installation diskettes.  Select OK when you are
     done.


Modifying the Sample Response File

After you install the SAMPLE.RSP file on your own
system, you can modify the SAMPLE.RSP file and use it
to install OS/2 on another workstation.  Use an
editor (such as the System Editor) to modify the
sample response file.

The following is an excerpt from the sample response
file:

*************************************
*AlternateAdapter
*;
*  Specifies secondary adapter for two display systems.
*  This should be a  lower or equal resolution display since
*  the highest resolution display will be primary for PM.
*
*  Valid Parms
*
*     0=None (DEFAULT)
*     1=Other than following (DDINSTAL will handle)
*     2=Monochrome /Printer Adapter
*     3=Color Graphics Adapter
*     4=Enhanced Graphics Adapter
*     5=PS/2 Display Adapter
*     6=Video Graphics Adapter
*     7=8514/A Adapter
*     8=XGA Adapter
*     9=SVGA Adapter
*************************************
AlternateAdapter=0

******** New Keywords for Warp Version 4 ************

Some new keywords have been added to SAMPLE.RSP to provide you with options
for installing the Bonus Pack software options.  These new keywords have a
slightly different syntax than earlier versions of OS/2.

The new syntax is described as
     KEYWORD.Selection=?

Where KEYWORD is the Bonus Pack software selection and ? is replaced with either
a 0 or 1 indicating do not install or install respectively.

You will also notice that some of the new keywords are followed by
     KEYWORD.TarDrv=?

This selects which drive you would like this software selection to be installed
to.  Replace the ? with a standard drive letter designator such as C: or D:
(the colon is required).  Remember that in order to install the software
selection to the specified drive that it must be previously formatted (see the
FormatFAT=/FormatHPFS= keyword in SAMPLE.RSP).

In order to install these new software selections you must run a utility
called CLIFI.  Since the Bonus Pack software requires Presentation Manager (PM)
present in order to be installed a utility named CLIFI is provided.  CLIFI is
installed when response file install is run.  CLIFI is located in the
\OS2\INSTALL directory.

Lan Configuration Utility (LCU) and Netview DM/2 users can create LCU program
definitions and Netview DM/2 program profiles that will execute CLIFI in an
unattended install.  The syntax required to execute CLIFI and install the
Bonus Pack software unattendedly is as follows:

     CLIFI /a:c

           /s:<OS/2 CID Image Directory>
              (ie. Z:\OS2IMAGE)

           /b:<OS/2 BOOTDRIVE>
              (ie. C:)

           /r:<BOOTDRIVE:\OS2\INSTALL\FIBASE.RSP>
              (ie. C:\OS2\INSTALL\FIBASE.RSP)

           /f:<BOOTDRIVE:\OS2\INSTALL
              (ie. C:\OS2\INSTALL)

           /l1:<PATH TO YOUR ERROR LOGGING DIRECTORY>
               (ie. Z:\LOG\OS2V40\BASE.ERR)

           /l2:<PATH TO YOUR PROGRESS LOGGING DIRECTORY>
               (ie. Z:\LOG\OS2V40\BASE.LOG)

If using NVDM/2/LCU and booting from diskettes, the following steps need to be
followed to successfully install bonuspack and other feature install
components:

     1. Edit the response file for a target machine, and add/modify the
        following lines:

        SeedConfigSysLine=SET RESPONSEFILENAME=C:\OS2\INSTALL\SAMPLE.RSP
        UserExit=COPY W:\RSP\OS2V40\SAMPLE.RSP C:\OS2\INSTALL\SAMPLE.RSP

   Where:
      - SAMPLE.RSP corresponds to the responsefile name on ShareA.
      - W: points to the ShareA path on the NVDM/2 server or specify the drive
        letter that is used for LCU configurations.
      - Save the response file.

     2. Install OS/2, MPTS and NVDM/2 agent as a co-requisite group on the
        target machine.
     3. Schedule CLIFI.EXE.

If using NVDM/2 or LCU and booting from the Maintainence partition, you just
need to select to install OS/2, MPTS and NVDM/2/LCU agent and the feature
install components will install.  Make sure the environment variable
RESPONSEFILENAME is not set to anything.

Users that use response file install and only install the base OS can
install the Bonus Pack software using CLIFI as well.  Since CLIFI requires
access to the OS/2 CID image tree users must either have access to there CDROM
or a networking resource as a source for CLIFI to install from.  For example,
network users might install MPTS and IBM Lan Services or THINLAPS and THINIFS.

Here is a list of the new keywords and there default values that have been
added to SAMPLE.RSP:

     External Floppy Drive (Laptop)
        HOTPLUG.Selection=0

     Floppy/CDROM swapping for Ultra Bay devices
        WARMPLUG.Selection=0

     Dock II Docking Station
        WARMDOCK.Selection=0

     AskPSP Installation
        BPASKPSP.Selection=1
        BPASKPSP.TarDrv=C:

     Compuserve
        BPCIM.Selection=1
        BPCIM.TarDrv=C:

     FaxWorks
        BPFAXWORKS.Selection=1
        BPFAXWORKS.TarDrv=C:

     HyperAccess Lite
        BPHAL.Selection=1
        BPHAL.TarDrv=C:

     IBM Works
        BPIBMWORKS.Selection=1
        BPIBMWORKS.TarDrv=C:

     Remote Support
        BPRS2.Selection=1
        BPRS2.TarDrv=C:

     VideoIn Support
        BPVIDEOIN.Selection=1
        BPVIDEOIN.TarDrv=C:

     Jet Admin Client Support
        BPHPJETCLIENT.Selection=0
        BPHPJETCLIENT.TarDrv=C:

     Jet Admin Server Support
        BPHPJETSERVER.Selection=0
        BPHPJETSERVER.TarDrv=C:

     MarkNet Port Driver Support
        BPMARKNET.Selection=0
        BPMARKNET.TarDrv=C:

     MarkVision Support
        BPMARKVIS.Selection=0
        BPMARKVIS.TarDrv=C:

Here is list of new keywords that are not included in SAMPLE.RSP but provide
a means for you to select or deselect other software selections that are
installed based on a default setting when CLIFI is used.  Note that because
the following keywords are not found in SAMPLE.RSP they will be flaged as an
"unknown keyword" when SAMPLE.RSP is processed by response file install. This
has no effect on the base install since RSPINST ignores keywords that it does
not understand.

     Application Registration
        ART.Selection=1

     Open Doc Base
        ODBASE.Selection=1
        ODBASE.TarDrv=C:

     Warp Guild
        COACHES.Selection=1

     Dax Base
        DAXCOMP1.Selection=1
        DAXCOMP1.TarDrv=C:

     Problem Determination
        SYSMGT.Selection=1

     Serviceability and Diagnostic Aids Option
        SRVDIAG.Selection=1

     Serviceability Documentation Option
        SRVDOC.Selection=1

     Security Base
        ODSECBASE.Selection=1
        ODSECBASE.TarDrv=C:

     Runtimes for Sun's Java Programming Environment
        JAVARUN.Selection=0

     Samples for Sun's Java Programming Environment
        JAVASMPLS.Selection=0

     Toolkit for Sun's Java Programming Environment
        JAVATLKT.Selection=0

     VoiceType
        VT.Selection=1
        VT.TarDrv=C:

Please note that if the Java Samples or the Java Toolkit is selected that the
Java Runtimes must also be selected.  Otherwise the Java Samples and the Java
Toolkit will not be installed correctly.  In addition, in order to install Java
support the target drive must be formatted using HPFS (see the BaseFileSystem=
keyword in SAMPLE.RSP).

COPYING THE RESPONSE FILE TO DISKETTE 2

Use the following steps to make changes to the sample
response file.  After making the changes, you will
copy the file to a copy of Diskette 1.  You must also
make some modifications to the copy of Diskette 1 to
make room on it for the response file.

 1.  Install OS/2 on a computer.

 2.  Open OS/2 System on your Desktop.

 3.  Open Command Prompts.

 4.  Open OS/2 Window.

 5.  Insert Diskette 2 into drive A.

 6.  Type diskcopy a: a: and press Enter.

 7.  When prompted to do so, remove Diskette 2 from
     drive A and insert a blank, formatted diskette.
     (This diskette will be used to make a copy of
     Diskette 2)

 8.  Use steps 5 through 7 to make a copy of
     diskette #1 too.

 9.  Make sure the COPY of Diskette 2 is in drive A.
     Then type del a:\mouse.sys and press Enter.

 10. Type del a:\sysinst2.exe and press Enter.

 11. Type del a:\bundle and press enter.

 12. At the prompt, type the following and press Enter
     after each command:

       CD\OS2\INSTALL
       COPY SAMPLE.RSP OS2SE40.RSP

 13. Use an editor (such as the System Editor) to make
     your changes to the response file so you can use
     it for installing OS/2.  Then save and close the
     file.

 14. At the prompt, type the following and press Enter
     after each command:

       COPY OS2SE40.RSP A:
       COPY C:\RSPINST.EXE A:\

 15. Remove the copy of Diskette 2 from drive A.

 16. To edit the CONFIG.SYS file on the COPY of
     Diskette 1 type e a:\config.sys and press Enter.

 17. Change the following statement from:
     SET OS2_SHELL=SYSINST2.EXE to the following:
     SET OS2_SHELL=RSPINST.EXE A:\OS2SE40.RSP.

 18. Delete the following statement from the
     CONFIG.SYS file:

       DEVICE=MOUSE.SYS

 19. Save and close the CONFIG.SYS file.

 20. If you have a non-Micro Channel computer, go to
     step 21.  If you have a Micro Channel computer and
     the Reference Diskette contains ABIOS.SYS and
     *.BIO files, you will also need to modify the
     Installation Diskette that came with OS/2.
     Follow these steps:

     a.  Insert the Installation Diskette into drive A.
     b.  Type diskcopy a: a: and press Enter.
     c.  When prompted to do so, remove the Installa-
         tion Diskette from drive A and insert a
         blank, formatted diskette.  Then press Enter.
         This makes a copy of the Installation
         Diskette, which you will use in the next
         step.
     d.  Make sure the copy you just made of the
         Installation Diskette is in drive A.  Type
         the following and press Enter after each
         command:

           DEL A:\*.BIO
           DEL A:\ABIOS.SYS

     e.  Remove the copy of the Installation Diskette
         from drive A and insert the Reference
         Diskette.
     f.  Type the following and press Enter after each
         command:

           COPY A:\*.BIO C:\
           COPY A:\ABIOS.SYS C:\

     g.  Remove the Reference Diskette from drive A
         and insert the copy of the Installation
         Diskette.  Type the following and press Enter
         after each command:

           COPY C:\*.BIO A:\
           COPY C:\ABIOS.SYS A:\

         NOTE:  This Installation Diskette copy is now
                system-specific.  You will need to
                create a modified Installation
                Diskette for each type of system on
                which you are installing OS/2.

     h.  Use this copy of the Installation Diskette
         during the installation process.

 21. When prompted for Diskette 1 and Diskette 2 while
     booting off of the diskettes, insert the modified
     copies of the diskettes and press Enter.

     From this point on, the Installation program will
     prompt only for the insertion of diskettes.  No
     other installation actions are necessary.

 22. When prompted to insert Diskettes 1 and 2 again,
     insert the original diskettes into drive A.

Response files can be used to install the same set of
options on multiple workstations.  However, be sure
that the workstations are set up with the same set of
options and hardware.


Note:  You can use a response file to direct the installation
       from a source other than a diskette in drive A.  For
       example, in a local area network (LAN), you could
       direct the installation to a drive on the server.
       This type of installation requires additional software
       (such as a LAN support product).


*** 10.1 ...RSPINST RETURN CODES ***

When RSPINST encounters an error, it returns a non-zero return code to SEINST.
SEINST displays this return code.  Following is an explanation of the RSPINST
return codes:

  Return    Definition
  Code

   702      Invalid Line in response file.
   707      Invalid Key Value.
   708      No response file found.
   710      Windows system missing or invalid.
   711      Cannot format Windows partition if you support it.
   712      Response file keyword conflict.
   901      Partition Size Error.
   905      FDISK unsuccessful.
   906      Less than xMB primary partition exists.
   907      Primary partition exists, greater than xMB available.
   908      No primary partition exists, less than xMB available.
   909      Greater than xMB primary partition exists.
   911      Could not create a file.
   914      System Installation detected an internal error.
   915      System Installation failed to initialize.
   916      System Installation failed to start the session.
   920      Load Module Error.
   921      Target Drive Error. Use FDISK to add target drive to Boot Manager
            Menu.
   932      Copy File Error.
   933      Delete File Error.
   934      Device Configuration Error while determining system configuration.
   935      Close File Error.
   936      Make Directory Error.
   937      Rename File Error.
   938      Open File Error.
   939      Read File Error.
   940      Write File Error.
   941      Format Error.
   942      Display Panel Error.
   944      Display Driver Install Error.
   945      Format Error. The target drive is not formatted and
              formatpartition option was not selected.
   946      Video System Error.
   947      System Install Internal Error
   948      Error accessing OS/2 ini file.
   949      System File Transfer Error.
   950      Unpack File Not Found
   951      Unpack Partial Copy.
   952      Unpack Ctrl+Break Error.
   953      Unpack Critical Error.
   954      Run Program Error.
   955      Get/Set file Attributes Error.
   957      Memory Allocation Error.
  1000-1020 System Installation detected an internal error(00-20).
  1060      Invalid Base Product Level, incorrect version.
  1061      Invalid Base Product Level, incorrect type.
  1062      Invalid Base Product Level, missing syslevel file.
  1063      Memory Allocation Error
  1064      CheckSum Failure, unable to OPEN or READ specified file.
  1065      CheckSum Failure, unknown CheckSum return code.
  1066      Invalid Base Product Level
  1067      Invalid File System
  1068      Microsoft** Windows** NT Files Found
  1069      The version of OS/2 on the target system is newer than
            the OS/2 Installation files.


*** 11.0 ...CID INSTALL BONUSPACK USING CLIFI ***

If using NVDM/2, the following steps need to be followed. It is
assumed that the ShareA path points to C:\ShareA on the NVDM/2 server.

Assumptions:
   1. The response files are installed on c:\ShareA\RSP\MERLIN on the NVDM/2
      server.

   2. On the target system the drive on which OS/2 is being installed is C:\

   Edit the response file for a target machine and add the following lines:

      SeedConfigSysLine = SET RESPONSEFILENAME=C:\REQXX.RSP
      UserExit = COPY W:\RSP\MERLIN\REQXX.RSP C:\REQXX.RSP

   Where:
      REQXX.RSP corresponds to the responsefile name on ShareA.
      W: points to the ShareA path on the NVDM/2 server.

   Save the response file.

To successfully install the bonuspack installable components, do the following:

   1.  Install OS/2, MPTS and NVDM/2 agent as a co-requisite group on the
       target machine.

   2. After the target system comes up, reboot the target system either
   by shutting down the system locally, or initiating a 'CDM Activate'
   command on the target machine.  Refer to the NVDM/2 manuals for details
   about activating a client.  A CDM activate can be scheduled right after
   initiating Step 1.

   3.  Schedule CLIFI.EXE after steps 1 and 2 above.


*** 12.0 ...TME 10 NETFINITY NOTES ***

If CID installing the TME 10 NetFinity services on a system which had
SystemView for OS/2 client, you must first remove the SystemView for
OS/2 Client prior to installing the TME 10 NetFinity Services.

SystemView for OS/2 Client can be removed by doing the following steps:

 1. Edit the Config.sys file and comment out all references to files in
    the sysview2 directory.
 2. Delete the sysview2 directory.

*** 13.0 ...Installing Network SignON Coordinator (NSC/2) via NVDM/2 ***

A sample response file for use with NVDM/2 in the remote client
installation of NSC/2 can found on the OS/2 Warp CD.  The
file is named nsc.rsp and is located in the \ibminst\tables directory.

NVDM/2 requires that the installation program and parameters be
specified.  When configuring for NSC/2, the following values should
be used:

     Program to be invoked:
          d:\cid\img\nsc\install.exe
          d: represents the CD-ROM drive where the Warp CD is located.

     Parameters (for new install only):
          /a:i /X /L1:<log file name> /s:<source image> /r:<response file>

     Parameters (to update an existing installation only):
          /a:u /X /L1:<log file name> /s:<source image> /r:<response file>


*** 13.0 ...TRADEMARKS ***

The following terms, denoted by an asterisk (*) in this README file,
are trademarks of the IBM Corporation in the United States or other
countries:

    AIX
    IBM
    Micro Channel
    NetView
    OS/2
    Presentation Manager
    Workplace Shell

The following terms, denoted by a double asterisk (**) in this
README file, are trademarks of other companies as follows:

   Trademark                 Owner
   ----------                 -------
   ATI                        ATI Technologies, Inc.
   Cirrus Logic               Cirrus Logic, Inc.
   Headland Technology        Headland Technology Inc.
   NetWare                    Novell, Inc.
   S3                         S3 Incorporated
   Trident                    Trident Microsystems, Incorporated
   TSENG                      Tseng Laboratories, Inc.
   Weitek                     Weitek Corporation
   Western Digital            Western Digital Corporation
   Windows                    Microsoft Corporation

THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.
IBM DISCLAIMS ALL WARRANTIES, WHETHER EXPRESSED OR IMPLIED,
INCLUDING WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF FITNESS
FOR A PARTICULAR PURPOSE AND MERCHANTABILITY WITH RESPECT TO
THE INFORMATION IN THIS DOCUMENT.  BY FURNISHING THIS DOCUMENT,
IBM GRANTS NO LICENSES TO ANY RELATED PATENTS OR COPYRIGHTS.

[C] Copyright IBM Corporation 1994.  All rights reserved.
