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

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

The following describes the GETOSCID parameters:

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

- 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

The following describes the GETBOOT parameters:

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

- 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

The following describes the GETREXX parameters:

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

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:

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: - 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: /P:

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:
- 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: - 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: /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: - 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: /R:

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: - 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: - 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:
(ie. Z:\OS2IMAGE)

/b:
(ie. C:)

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

/f:
(ie. Z:\LOG\OS2V40\BASE.ERR)

/l2:
(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: /s: /r:

Parameters (to update an existing installation only):
/a:u /X /L1: /s: /r:

*** 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.