IBM Aptiva Multimedia Exploration

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

/ IBM Aptiva Multimedia Exploration / BPCDROM.ISO / os2image / disk_0 / readme.cid < prev next >

Wrap

Text File | 1995-05-24 | 48.9 KB | 1,349 lines

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 ...NEW 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 ...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:\OS2V30 C:\CID\IMG\OS2V30 /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 3 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 and Diskette #1 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 3 XDF format installation diskettes. OS/2 Warp Version 3 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 3 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 3 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\V300. 1. Insert diskette 2 in drive A: and run the following command: COPY A:UNPACK* C:\CID\EXE\V300 2. Insert diskette 7 in drive A: and run the following command: C:\CID\EXE\V300\UNPACK A:\CID C:\CID\EXE\V300 /N:SEIMAGE.EXE Note: The C:\CID\EXE\V300 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\OS2V30. *** 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\OS2V30 *** New 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:\OS2V30 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:\OS2V30\WIN31. So the final Directory structure will look like this: D:\ | |-- OS2V30\ | |------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\OS2V30 D:\CID\EXE\V300 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\OS2V30 D:\CID\EXE\V300 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\OS2V30 D:\CID\DLL\V300 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\OS2V30 /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 3 will not be needed until the first Service Pak for OS/2 Warp Version 3 is released. Example for building a maintenance system for installing OS/2 Warp Version 3: X:\EXE\V300\SEMAINT /S:X:\IMG\OS2V30 /T:C:\SERVICE /B:C: /L1:X:\LOG\OS2V30\CLIENT.LOG Example for building a maintenance system for applying an OS/2 V3 Service Pak to a client, where XR0nnnn is the Service Pak number being applied: X:\EXE\V300\SEMAINT /S:X:\IMG\OS2V30 /T:C:\SERVICE /B:C: /L1:X:\LOG\OS2V30\CLIENT.LOG /S2:X:\CSD\OS2V30\XR0nnnn Example for building a maintenance system for applying a non-OS/2 Service Pak to a client that has OS/2 V3 Service Pak XR0nnnn installed on it: X:\EXE\V300\SEMAINT /S:X:\IMG\OS2V30 /T:C:\SERVICE /B:C: /L1:X:\LOG\OS2V30\CLIENT.LOG /S2:X:\CSD\OS2V30\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\V300\SEINST /S:X:\IMG\OS2V30 /B:C: /R:X:\RSP\OS2V30\RESPONSE.FIL /L1:X:\LOG\OS2V30\CLIENT.LOG Example when booted from maintenance system: X:\EXE\V300\SEINST /S:X:\IMG\OS2V30 /B:C: /R:X:\RSP\OS2V30\RESPONSE.FIL /L1:X:\LOG\OS2V30\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 ...NEW 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\OS2V30 /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 2.0 SETLOCAL IF %1.==. ECHO GETOSCID source (target) IF %1.==. GOTO END REM REM CHECK SOURCE DIRECTORY REM IF EXIST %1\DISK_2\UNPACK.EXE GOTO GETTAR COPY %1\DISK_2\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_2\UNPACK*.EXE %GC_TARGET% COPY %1\DISK_2\UNPACK*.EXE %GC_TARGET% > NUL IF ERRORLEVEL 1 GOTO END REM REM GET THE CID PACK FILE REM ECHO %1\DISK_2\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_2\UNPACK %1\DISK_%%I\CID %GC_TARGET% >> NUL 2>>&1 REM REM GET THE REQUIRED PACK FILE FOR RSPINST.EXE REM ECHO %1\DISK_2\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_2\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_2\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_2\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 2.0 SETLOCAL IF %1.==. ECHO GETREXX source (target) IF %1.==. GOTO END REM REM CHECK SOURCE DIRECTORY REM IF EXIST %1\DISK_2\*.* GOTO GETTAR COPY %1\DISK_2\*.* 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_2 DIRECTORY REM IF EXIST %1\DISK_2\*.* GOTO UNPACK COPY %1\DISK_2\UNPACK.EXE GOTO END :UNPACK ECHO %1\DISK_2\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_2\UNPACK %1\DISK_%%I\REXX %GR_TARGET% >> NUL 2>>&1 ECHO %1\DISK_2\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_2\UNPACK %1\DISK_%%I\BUNDLE %GR_TARGET% /N:OSO001.MSG >> NUL 2>>&1 ECHO %1\DISK_2\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_2\UNPACK %1\DISK_%%I\BUNDLE %GR_TARGET% /N:INSCFG32.DLL >> NUL 2>>&1 ECHO %1\DISK_2\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_2\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 2.0 SETLOCAL IF %1.==. ECHO GETBOOT source (target) IF %1.==. GOTO END REM REM CHECK SOURCE DIRECTORY REM IF EXIST %1\DISK_2\*.* GOTO GETTAR COPY %1\DISK_2\*.* 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_2 DIRECTORY REM IF EXIST %1\DISK_2\*.* GOTO UNPACK COPY %1\DISK_2\UNPACK.EXE GOTO END :UNPACK ECHO %1\DISK_2\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_2\UNPACK %1\DISK_%%I\BUNDLE %GB_TARGET% /N:SETBOOT.EXE >> NUL 2>>&1 ECHO %1\DISK_2\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_2\UNPACK %1\DISK_%%I\FDISK %GB_TARGET% /N:SETBOOT.EXE >> NUL 2>>&1 ECHO %1\DISK_2\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_2\UNPACK %1\DISK_%%I\BUNDLE %GB_TARGET% /N:XCOPY.EXE >> NUL 2>>&1 ECHO %1\DISK_2\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_2\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 COPYING THE RESPONSE FILE TO DISKETTE 1 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 1 into drive A. 6. Type diskcopy a: a: and press Enter. 7. When prompted to do so, remove Diskette 1 from drive A and insert a blank, formatted diskette. (This diskette will be used to make a copy of Diskette 1) 8. Make sure the copy of Diskette 1 is in drive A. Then type del a:\mouse.sys and press Enter. 9. Type del a:\sysinst2.exe and press Enter. 10. Type del a:\bundle and press enter. 11. To edit the CONFIG.SYS file on the copy of Diskette 1 type e a:\config.sys and press Enter. 12. Change the following statement from: SET OS2_SHELL=SYSINST2.EXE to the following: SET OS2_SHELL=RSPINST.EXE A:\OS2SE30.RSP. 13. Delete the following statement from the CONFIG.SYS file: DEVICE=MOUSE.SYS 14. Save and close the CONFIG.SYS file. At the prompt, type the following and press Enter after each command: CD\OS2\INSTALL COPY SAMPLE.RSP OS2SE30.RSP 15. 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. 16. At the prompt, type the following and press Enter after each command: COPY OS2SE30.RSP A: COPY C:\RSPINST.EXE A:\ 17. Remove the copy of Diskette 1 from drive A. 18. If you have a non-Micro Channel computer, go to step 20. 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. 19. When prompted for Diskette 1 during the installa- tion, insert the modified copy you made of Diskette 1 and press Enter. From this point on, the Installation program will prompt only for the insertion of diskettes. No other installation actions are necessary. 20. When prompted to insert Diskette 1 again, insert the original Diskette 1 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 ...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.