5.9 CID Installation Parameters

5.10 Preparation Phase

This section describes the steps required in the preparation phase.

5.10.1 Create LCU Boot Diskettes

In a pristine installation, it is necessary to create LCU boot diskettes for the system that will be installed. This is not necessary in a migration scenario.

For more information about the creation of boot diskettes, please refer to the redbook titled The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010,&CID. and also to the README.CID on the OS/2 Warp Server for e-business Server Pak CD-ROM.

We briefly describe the steps necessary to create some client boot diskettes for a pristine installation. We assume that you followed the instructions to set up the code server as described in 5.7 Preparing the Code Server.

  1. Create Original Boot Diskettes from Server Pak CD-ROM images:
    To create the three OS/2 boot diskettes, type at the code server:
    X:\SHAREA\EXE\SEDISK /S:X:\SHAREA\IMG\OS2IMAGE /T:A:

  2. Add LAN Transport and Adapter Support to the diskettes:
    To create a thin transport system on boot diskette #3, type at the code server:
    X:\SHAREA\IMG\MPTS\THINLAPS X:\SHAREA\IMG\MPTS A: IBMTOK.NIF
    This command assumes you are using an IBM Token-Ring adapter on the system to be migrated. Be sure to specify the correct NIF file for the adapter you are using.

    Add LCU Client Support to the diskettes:
    We will enable the system to use SRVIFS to connect twice, one time for the read-only area of images, and a second time for the read-write area of log files. Type the following command at the code server:
    X:\SHAREA\IMG\SRVIFS\THINIFS /S:X:\SHAREA\IMG\SRVIFS /T:A: /SRV:\\WSCID\IMG /REQ:CLIENT1 /D:X:
    In the first line in the command above, the X: is the drive on the code server where the SRVIFS files are located, and the X: in the /D parameter specifies the local drive letter on the client to be used when connecting to the code server.
    To specify the connection for log files, type the following command:
    X:\SHAREA\IMG\SRVIFS\THINIFS /S:X:\SHAREA\IMG\SRVIFS /T:A: /SRV:\\WSCID\LOG /REQ:CLIENT1 /D:Y:
    In this case, the /D parameter specifies Y:, which is the local drive letter on the client (server to be migrated) that will access the log files.
    On the last boot diskette, we use the CASINSTL command to create the STARTUP.CMD file and invoke the correct starting procedures:

    X:\SHAREA\DLL\CASINSTL /TU:A: /CMD:X:\CLIENT /D /PA:X:\DLL /PL:X:\DLL /L2:Y:\CLIENT\CLIENT1.LOG /0

  3. Create a Startup Script

  4. Clean up the CONFIG.SYS on DISK 1

  5. Make Disk 2 unbootable using DBOOT

When you have prepared your code server, you will be ready to boot with client diskettes and start your pristine installation.

5.10.2 Create Maintenance System (SEMAINT)

The update of the base OS/2 operating system is the most complicated part of the installation. It is not simply a case of executing the installation program. Some preliminary steps are required.

SEMAINT creates a maintenance system on your bootable partition or on another partition that will be booted in order to install OS/2. It copies a minimal version of the operating system to a new directory on a designated drive. When booted from the maintenance system, only text-mode programs can run.

SEMAINT also alters the boot sector of that drive. On the next reboot, the system does not load the previously installed version of the operating system but the newly-created maintenance system.

SEMAINT Syntax

SEMAINT /S:<Source_Path> /S2:<Service_Pak> /T:<Target_Path> /B:<Boot_Drive> /L1:<Path><Log_File_Name>

For full details of the syntax of SEMAINT, refer to &CID.The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010 or OS/2 Installation Techniques: The CID Guide, SG24-4295.

5.10.2.1 SEMAINT LCU Command File Syntax

We have implemented procedures in order to execute SEMAINT for various reasons. If you want to execute the program in a simple LCU command file, we recommend that you refer to the books cited above.

However, if you would like to review our implementation, please refer to Section 5.10.3 Migration Implementation for SEMAINT.

Note

Following successful execution of SEMAINT (if executed on the boot drive), the previous version of OS/2 will no longer work since SEMAINT replaced some hidden files on the boot drive (OS2KRNL) with a newer version. If the installation fails at this point, it is probably wise to restore the system from the backup taken before the installation.

Some administrators plan their disk partitioning prior to the initial installation, creating a small partition to be used for maintenance and in recovery situations. We implement this in our environment. Our standard installation uses a small primary C: drive for the maintenance partition with logical drive D: as our boot partition.

If you have a bootable partition (or maintenance partition) other than the system boot partition on your server, we recommend that you install the maintenance system onto it. That way, if SEMAINT fails, your original system partition will be unaffected, and there should be no need for restoration.

5.10.2.2 PREPMNT Utility for SEMAINT

If you will run SEMAINT or CHKINST on a system where you have never installed OS/2 Warp Server for e-business, then you must run the PREPMNT.CMD utility. This utility updates the device drivers in the \OS2\BOOT directory.

You must copy a new version of the device drivers from the OS/2 Warp Server for e-business CD-ROM. These drivers are located in the \OS2IMAGE\DISK_1 directory on the CD-ROM and need to be copied to the \OS2\BOOT directory of the partition from which you have booted up.

This step can be done manually or by running the PREPMNT.CMD REXX utility available in the \CID\EXE\OS2 directory of the OS/2 Warp Server for e-business Server Pak CD-ROM. PREPMNT will back up the current device drivers to the \OS2\BOOT\BKP and then copy the new drivers to \OS2\BOOT. PREPMNT uses an executable called FINDBOOT.EXE (in \OS2IMAGE\DISK_0 on the OS/2 Warp Server for e-business Server Pak CD-ROM) to determine the boot drive.

PREPMNT can be run from LCU or a Software Distribution Manager environment. After PREPMNT is run successfully, the system will reboot and you can now run CHKINST or SEMAINT.

The syntax for PREPMNT is
PREPMNT <Source_path> [Logfile]

where:

Source_path
The fully qualified path to the OS/2 images. This parameter is required.
Logfile
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 optional.

Example: prepmnt f:\os2image W:\logs\prepmnt.log

Depending on the level of REXX your system supports, you might see error messages appear when running PREPMNT, especially if you specify a log file. This is because the utility uses the LINEOUT function which gives a return code (usually a 0) that is not processed. As a result, the REXX interpreter tries to execute 0 as a command, which fails, and produces the error.

PREPMNT will still function correctly in copying files, but some lines might not be logged into the file you specify. You can correct this by copying the PREPMNT.CMD file to your hard drive and add q= directly before each LINEOUT function call (such as q=lineout(logfile, "<error msg>")). This will set the variable q to the value of the return code.

5.10.3 Migration Implementation for SEMAINT

Further to the generic description of SEMAINT given in 5.10.2 Create Maintenance System (SEMAINT), we now describe our implementation for the migration scenario.

The OS/2 Warp Server for e-business beta code we originally used during the creation of this document had problems that required intervention in order for the CID installation to work successfully. We believe these problems were addressed in the final release for general availability (GA), but we include our workaround for completeness.

Important: SEMAINT and VCU

Logical Volume Manager relies on the utility Volume Conversion Utility (VCU) to have been run and to have created LVM compatibility volumes on disk. These are volumes that LVM is aware of. Since VCU is called from CDBOOT (on the boot diskettes) or from RSPINST (which itself is called from SEINST), this presents a problem. In a maintenance environment for migration, VCU will not yet have been called. The effect of this is that no drive letters are assigned, and the installation fails. Furthermore, the time or writing drive letter assignment from the command line was not possible. We now discuss how we overcame these problems.

5.10.3.1 Worst Case Scenario

In determining how to overcome this problem, there were many possibilities open to us. We decided to choose the worst case scenario. That is, we assumed that no remote management software was available, and that the remote server was inaccessible (in a locked room, remote branch, or another country).

The only prerequisite was that the code server was accessible to the remote server on which the procedure would be run over NetBIOS or TCPBEUI.

We felt that should we be able to overcome this problem simply by using the functions and features of the products we are using (LCU, REXX, LAN Server and OS/2). With systems management software, the task would be even easier.

Prerequisite Knowledge

In describing our procedures, some knowledge of REXX is assumed. If you are new to the CID environment or have limited REXX knowledge, then these procedures may be difficult to understand. Our intent is to provide a technique that the experienced CID administrators will be able to use.

5.10.3.2 The Temporary Solution

We wrote some powerful REXX procedures that perform the following functions remotely and unattended in a migration scenario.

Note

All procedures are included on the CD ROM in the \SEMAINT directory.

The procedures execute the following tasks:

  1. Copy the REXX procedures and required files to the remote server

  2. Set up installation environment for SEMAINT

  3. Create an icon for the REXX program and launch it

  4. Create a maintenance system on the remote server using SEMAINT

  5. Create a seed LAN transport system

  6. Install SrvIFS redirection files on the hard disk

  7. Create Compatibility Volumes on the server with VCU

It also provides a means for querying the disk layout; so, the administrator can verify the events that should have occurred.

When all of the above have been verified, the system can be rebooted to the maintenance partition.

5.10.3.3 The Temporary Solution in Detail

These procedures are somewhat limited in that they do not provide a high degree of error checking. Also, administrator-level access from the workstation initiating the procedures is required. In addition, some advanced configuration of INI files is necessary.

Step 1

The first command file that is executed is SE.CMD (see Figure 43). This copies the REXX procedures and other files needed for the REXX procedures to the target system. The SE.CMD procedure accepts three parameters:

Step 2

After the files have been copied, you will notice that SE.CMD runs a NET ADMIN command to invoke the next REXX procedure, MSEOBJ.CMD (see Figure 44).



/*--------------------------------------------------------------------------*\
!   Create an object & start the object          (C) A.Rykaert - NOV98-NOV98 !
\*--------------------------------------------------------------------------*/
    Version = '1.02'

    Parse Upper Arg PWSName NICType TargetDisk
    If PWSName = '' | TargetDisk = '' | NICType = ''
      Then Do
             Say '! Invalid syntax' '07'x
             Say  '*'
             Say  '* Usage: MSEOBJ {WorkStationName} {NICType} {TargetDisk}'
             Say  '*'
             Say  '* Sample: MSEOBJ DC01 IBMMPC.NIF C:'
             Exit
           End
      Else Nop

 /*================================================*/
    ObjectID = '<CID_OS2_MAKEDISK>'
    Title    = 'Maintenance Partition^Creator'
    InstProg = 'msemaint.cmd'
 /*================================================*/

    If RxFuncQuery('SysLoadFuncs')
      Then Do
             Call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
             Call SysLoadFuncs
           End
      Else Nop

    Say '* Creating object' ObjectID 'in the Desktop'

    Class    = 'WPProgram'
    Title    = Title
    Location = '<WP_DESKTOP>'
    Setup    = 'OBJECTID='ObjectID';'                     ||,
               'EXENAME='InstProg';'                      ||,
               'PROGTYPE=windowablevio;'                  ||,
               'PARAMETERS='PWSName NICType TargetDisk';' ||,
               'OPEN=Default;'                            ||,
               'NOAUTOCLOSE=yes'
    Update   = 'Replace'

    RC = SysCreateObject(Class, Title, Location, Setup, Update)
    If RC <> 1
      Then '! Error while creating object, ReturnCode:' RC
      Else Nop

    Exit

Figure 44: MSEOBJ.CMD

Our reason for implementing this REXX procedure is that it is not possible to invoke MSEMAINT.CMD remotely by using NET ADMIN. By running MSEMAINT and creating a Program Reference Object for MSEMAINT.CMD with the property <OPEN=DEFAULT>, it is launched on creation.

Step 3

The MSEMAINT.CMD procedure (see Figure 45) is included on the CD-ROM as already discussed. MSEMAINT.CMD executes the following actions:

SEMAINT, THINLAPS, and THINIFS use the parameters passed to SE.CMD to execute correctly. The commands themselves are described in Section 5.8.1 Preparation Phase; so, they will not be discussed further.

The main procedure, MSEMAINT.CMD, is shown in Figure 45. The main steps in the procedure are as follows:

  1. Read the MSEMAINT.INI file and store the parameter values in memory.

  2. Display these values on the workstation screen (usability feature).

  3. Verify all required files are available before proceeding.

  4. Extract existing system environment data.

  5. Check that required local files are present.

  6. Invoke SEMAINT to install maintenance system using INI file parameters.

  7. Invoke THINLAPS to install a seed LAN transport system.

  8. Invoke THINIFS to provide drive redirection.

  9. Copy LVM related files and VCU.EXE to the Server.

    Note

    The LVM-related files are found on DISK 6, and the VCU executable is found on Disk 2.



  10. Update CONFIG.SYS on maintenance partition to transfer control to our own LCU procedure CID.CMD when rebooted to the maintenance partition.

  11. Execute VCU to generate compatibility volumes and assign drive letters.

The MSEMAINT.CMD procedure follows:



/*---------------------------------------------------------------------------*\
|  Make SEMAINT partition            (C) A Rykaert + JP Cabanie - NOV98-NOV98 |
\*---------------------------------------------------------------------------*/
    Version = '1.02'
    Say '* MSEMAINT Version' Version

    Parse Upper Arg PWSName NICType TargetDisk .

    If PWSName = '' | NICType = '' | TargetDisk = ''
      Then Do
             Say '! Error: Invalid parameters'
             Say '*'
             Say '* Usage: MSEMAINT {WorkStationName} {NIC Type} {TargetDisk}'
             Exit X2D('1600')
           End
      Else Nop

    Call ReadIni                                      /* Read the .INI file*/

/* Display the curent values as extracted from our .INI file               */
    Say '* PWSName :' PWSName
    Say '* NICType :' NICType
    Say '* TargetDisk :' TargetDisk
    Say '* UserID :' UserID
    Say '* Domain :' Domain
    Say '* Alias :' Alias
    Say '* DriveLetter :' DriveLetter
    Say '* SeMaintCmd :' SeMaintCmd
    Say '* SeMaint Source:' SeMaintSrc
    Say '* Thin386 Command:' Thin386Cmd
    Say '* ThinLaps Command:' ThinLapsCmd
    Say '* ThinLaps Source :' ThinLapsSrc
    Say '* ThinIfs Command:' ThinIfsCmd
    Say '* ThinIfs Source :' ThinIfsSrc
    Say '* Alias 1 :' CIDAlias1
    Say '* Drive 1 :' CIDDrive1
    Say '* Alias 2 :' CIDAlias2
    Say '* Drive 2 :' CIDDrive2
    Say '* CID Command :' CIDCmd

   '@echo off'                          /* Avoid display of issued commands*/
    ESC = '1B'x                      /* Declare some ANSI control sequences*/
    Red = ESC'[0;1;41m'
    Blue = ESC'[0;1;44m'
    Reset = ESC'[0m'

    BootDrive = Left(Value('ComSpec',,'OS2Environment'),2)
    Say Blue '* BootDrive :' BootDrive Reset
/*                                                      This is for Futher Use

Figure 45: MSEMAINT.CMD (Part 1 of 5)




        Say Blue '* Check if the Target disk is bootable' Reset
    Call ChkFile BootDrive'\os2\fdisk.com'
    RQ = RxQueue('Create')
    Call RXQueue 'Set', RQ
   'fdisk /query | RxQueue' RQ
    Check = 0
    Do While Queued() > 0
      Pull LLine
      Parse Var LLine . . Drive . . Status .
      If Drive = TargetDisk & (Status = '1' | Status = '5' | Status = '6')
        Then Check = 1
        Else Nop
    End
    Call RXQueue 'Delete', RQ
    If Check = 1
      Then Nop
      Else Do
             Say '! Error: Drive' TargetDisk 'is not bootable'
             Exit X2D('1204')
           End
  */
    Say Blue '* Check Resources' Reset
    Call ChkResource

    Say Blue '* Check Files' Reset
    Call ChkFile BootDrive'\os2\format.com'
    Call ChkFile BootDrive'\os2\label.com'
    Call ChkFile SeMaintCmd
    Call ChkFile Thin386Cmd
    Call ChkFile ThinLapsCmd
    Call ChkFile CidCmd

    If FormatSeMaintDisk = 1
      Then Do
             Say Red '* Formatting the disk' TargetDisk Reset
            'label' TargetDisk || 'semaint'
             FormatRSP = BootDrive'\os2\format.rsp'
            'if exist' FormatRSP 'del' FormatRsp
             Call LineOut FormatRsp, 'semaint'
             Call LineOut FormatRsp, 'yes'
             Call Stream  FormatRsp, 'C', 'Close'
             Call Doit 'format' TargetDisk '/FS:fat /V:semaint <' FormatRsp
           End
      Else Nop
Say Blue '* Add Minimum Base OS/2 support' Reset
    Call Doit SeMaintCmd '/S:'SeMaintSrc,
                         '/T:'TargetDisk'\SEMAINT /B:'TargetDisk,
                         '/L1:'TargetDisk'\SEMAINT.LOG'
/*                                             It's not supported with Aurora
    Say Blue '* Add the Thin386 support' Reset
    Call Doit Thin386Cmd '/B:'TargetDisk,
                         '/T:'TargetDisk'\SEMAINT',
                         '/L1:'TargetDisk'\THIN386.ERR',
                         '/L2:'TargetDisk'\THIN386.LOG'
*/
    Say Blue '* Add the ThinLaps support' Reset
    Call Doit ThinlapsCmd ThinLapsSrc TargetDisk'\SEMAINT' NICType

Figure 46: MSEMAINT.CMD (Part 2 of 5)




Say Blue '* Add the SRVIFS support' Reset
    Call Doit ThinIfsCmd '/S:'ThinIfsSrc '/TU:'TargetDisk,
                         '/T:'TargetDisk'\semaint /SRV:'CIDAlias1,
                         '/REQ:'PWSName '/D:'CIDDrive1
    Call Doit ThinIfsCmd '/S:'ThinIfsSrc '/TU:'TargetDisk,
                         '/T:'TargetDisk'\semaint /SRV:'CIDAlias2,
                         '/REQ:'PWSName '/D:'CIDDrive2

    Say Blue '* Copy CID Command File' CIDCmd 'to' TargetDisk'\cid.cmd' Reset
    Call Doit 'copy' CIDCmd TargetDisk'\cid.cmd'

    Say Blue '* Add the CID Command to' TargetDisk'\config.sys' Reset
    Call LineOut TargetDisk'\config.sys',,
                           'set os2_shell=\semaint\cmd.exe /k cid.cmd'
    Call Stream TargetDisk'\config.sys', 'C', 'Close'

    Say Blue '* Add LVM & VCU Support' Reset
/* By chance, these Lan Server for e-business utilities run on Warp 3.0 */
   'copy' SeMaintSrc'\disk_2\vcu.ex*'  TargetDisk'\semaint'
   'copy' SeMaintSrc'\disk_2\vcu.ms*'  TargetDisk'\semaint'
   'copy' SeMaintSrc'\disk_6\lvm.ex*'  TargetDisk'\semaint'
   'copy' SeMaintSrc'\disk_6\lvm.dl*'  TargetDisk'\semaint'
   'copy' SeMaintSrc'\disk_6\lvm.ms*'  TargetDisk'\semaint'
   'copy' SeMaintSrc'\disk_6\lvmh.ms*' TargetDisk'\semaint'

    Say Red Copies('*', 40) Reset
    Say Red '* REBOOT THE SYSTEM FROM DRIVE' TargetDisk Reset
    Say Red Copies('*', 40) Reset

    Say Blue '* Execute VCU to get the drive letters for LVM' Reset
    TargetDisk                                      /* Change default drive*/
   'cd\semaint'                                 /* Change default directory*/
   'VCU'

/* The VCU utility is meant to work in an interactive way and will stay in */
/* suspend mode after having declared the compatibility volumes and        */
/* assigned drive letters to them. That means that the following lines will*/
/* never be executed unless a second install is done in which case, VCU    */
/* will just act as a nop                                                  */

    Say Red '* Done' Reset

    Exit X2D('FE00')
                /* CID Return code : Success / Reboot / Don't call me back */

 READINI:/* ---------------------------------------------------------------*/

    Parse Upper Source . . ProgName .         /* determine the INI FileName*/
    Parse Value Reverse(ProgName) With . '.' Peek
    IniFileName = Reverse(Peek) || '.INI'
    Say '* IniFileName:' IniFileName
    Call CHKFILE IniFileName
/* Initialize our FormatSemaintDisk is assigned the value 0 while all the  */
/* other ones are affected an empty string value...                        */
    Parse Value '0' With FormatSeMaintDisk UserID Domain DriveLetter   ,
                         Alias SeMaintCmd SeMaintSrc Thin386Cmd        ,
                         ThinLapsCmd ThinLapsSrc ThinIfsCmd ThinIfsSrc ,
                         CIDAlias1 CIDAlias2 CIDDrive1 CIDDrive2       ,
                         CIDCmd

Figure 47: MSEMAINT.CMD (Part 3 of 5)




/* Read the .INI file and update the previous variables with the values    */
/* specified in this file.                                                 */
    Do While Lines(IniFileName)
      LLine = Strip(LineIn(IniFileName))
      If Left(LLine, 1) = ';' | Left(LLine, 1) = '*'
        Then Iterate                                             /* Comment*/
        Else Interpret LLine
    End

    Return

 CHKFILE:/* -----------------------------------------------------------------*/

    Parse Arg File_To_Check

    If Stream(File_To_Check, 'C', 'Query Exists') = ''
      Then Do
             Text = '! File not found' File_To_Check
             Say Text '07'x
             Exit X2D('0800')
           End
      Else Nop

    Return

 DOIT:/* -------------------------------------------------------------------*/

    Parse Arg InstProg

    InstProg
    If RC = 0 | RC = -512
      Then Return
      Else Do
             Say Copies('!',40)
             Say Red '! Error:' RC '070707'x Reset
             Say Copies('!',40)
             Exit RC
           End

 CHKRESOURCE:/* ------------------------------------------------------------*/

   'logoff /y'
   'logon' UserID '/d:'Domain '/v:d /r'
    If RC = 0
      Then Nop
      Else Do
             Text = '! Error: could not logon' UserID 'to' Domain
             Say Text
             Exit X2D('1604')
           End
'net use' DriveLetter '>nul'

Figure 48: MSEMAINT.CMD (Part 4 of 5)




If RC = 0
      Then Nop
      Else Do
            'net use' DriveLetter Alias '/domain:'Domain
             If RC = 0
               Then Nop
               Else Do
                      Text = '! Error: could not find' DriveLetter
                      Say Text
                      Exit X2D('1604')
                    End
           End

    Return

Figure 49: MSEMAINT.CMD (Part 5 of 5)

The environment information is obtained from an INI file called MSEMAINT.INI (see Figure 51). As we already stated, these procedures are somewhat basic. We stored these parameters in an ASCII INI file because we felt they might not change very often.

One parameter of particular note within the INI file is FormatSEmaintDisk, which determines whether the installation partition is formatted. A value of 1 means format. A value of 0 means do not format.


*----------------------------------------------------------------------------
* This is the setup file used by the MSEMAINT Procedure (C) A.Rykaert - NOV98
*----------------------------------------------------------------------------
* Definitions for the Setup of the Maintenance Partition

  UserID = CID01                              /* UserID used during the Run*/
  Domain = D01                                     /* Domain where to Logon*/
  DriveLetter = Z:        /* DriveLetter of all the Executables and Sources*/
  Alias = ShareA                              /* Domain Alias of the Images*/

  FormatSEmaintDisk = 1                            /* 1=Format, 0=no Format*/

  SemaintCmd = z:\lcu\xr09999\semaint.exe             /* SeMaint Executable*/
  SemaintSrc = z:\img\os2\xr09999                    /* SeMaint Source Path*/

  Thin386Cmd = z:\img\lsr\ip08700\ibm500s1\Thin386.exe/* Thin386 Executable*/

  ThinLapsCmd = z:\img\mpts\WR08620\Thinlaps.exe      /* ThinLap Executable*/
  ThinLapsSrc = z:\img\mpts\WR08620

  ThinIfsCmd = z:\img\srvifs\thinifs.exe              /* ThinIfs Executable*/
  ThinIfsSrc = z:\img\srvifs                         /* ThinIfs Source Path*/

  LogFileName = \msemaint.log                               /* Log FileName*/

Figure 50: MSEMAINT.INI (Part 1 of 2)





  CIDCmd = z:\dsk\cid.cmd                             /* LCU Batch Filename*/

*----------------------------------------------------------------------------
* Definitions for the Standard CID

 CIDAlias1 = CODESERV                /* AliasName 1 during the Standard CID*/
 CIDDrive1 = Z:                    /* DriveLetter 1 during the Standard CID*/

 CIDAlias2 = CODESERV\PWS            /* AliasName 2 during the Standard CID*/
 CIDDrive2 = X:                    /* DriveLetter 2 during the Standard CID*/

* Remark: The WorkStations Name is collected via the external Parameter

*----------------------------------------------------------------------------

Figure 51: MSEMAINT.INI (Part 2 of 2)

At the end of program execution, the command window can stay open as long as necessary.

Step 4

We have provided an additional procedure in SE.CMD in the form of LVMCLI.CMD. This reports the state of the disk to the administrator, which can be helpful as a verification that all is well.


/* LVMCLI.CMD */
@echo off
    if .%1 == . goto Syntax
    echo * SEMaint Drive: %1
    if not exist %1\semaint goto DirNotFound

    %1
    cd\semaint
    lvm /query
    goto End

   :SYNTAX
    echo ! Inavlid parameter
    echo *
    echo * Usage: LVMCLI {SEMaintDrive}
    echo *
    echo * Sample: LVMCLI C:
    goto End

   :DIRNOTFOUND
    echo ! Directory %1\semaint not found

   :END

Figure 52: LVMCLI.CMD

Step 5

Lastly, the administrator remotely can issue a SETBOOT command to reboot the remote system to the maintenance partition and start the installation. For example:

NET ADMIN \\ServerName /C SETBOOT /IBD:C

and press Enter. The installation will then start from whatever maintenance partition was defined.

Step 6

The entire process is documented in a log file. Because of the length of this file, we have placed it in Figure 140.

5.10.4 386 HPFS File System Access (THIN386)

In past migrations, if you were using 386 HPFS formatted drives, THIN386 had to be run. THIN386 installed the 386 HPFS file system drivers onto the maintenance system, which ensured that the installation process had unrestricted access to all server drives, which is required during the migration process.

You have the choice of either running THIN386 as in the past, or you can remove the access controls from the file system prior to the migration using PREPACL. If you use PREPACL, then THIN386 is not required. However, PREPACL requires that an ID with administrator privilege be logged on the system, which may be unlikely in the case of a CID installation. In this case, THIN386 is still the preferred mechanism for supporting 386 HPFS.

If 386 HPFS is not yet installed on the system, or if a pristine installation is being performed, this PREPACL step is not necessary.

Because of the fact that the installation routine removes 386 HPFS (see Section 5.11.4 386 HPFS for important installation information), THIN386 should be run twice, once before SEINST and again after running SEINST.

There are some new features included in THIN386 to help with migrating a server with the 386 HPFS file system installed. There is a new required switch called /386Path that needs one of two paths.

  1. The directory where the 386HPFS2.ZIP file resides, usually on the OS/2 LAN Server image IBM500S1 in versions previous to OS/2 Warp Server for e-business. This file can also be copied to another location. Here's an example of this usage (other required THIN386 parameters are not listed): THIN386 /386Path:e:\wssmp\cid\server\ibmls\ibm500s1

  2. If the 386HPFS2.ZIP file is not available, point to the directory where the current installed 386 HPFS files reside (usually in C:\IBM386FS). Here's and example of this usage (other required parameters are not listed): THIN386 /386Path:c:\ibm386fs

5.10.5 Logical Volume Manager (LVM) Issues

OS/2's FDISK utility has been replaced by the Logical Volume Manager (LVM). During migration, the existing partitions must be converted to LVM Compatibility Volumes.

At the time of writing, we had to implement a workaround in order that the installation completed unattended. This is described in Section 5.10.3 Migration Implementation for SEMAINT.

In a CID installation for a pristine environment, the disk must be partitioned through command line procedures using LVM. FDISK, since it is not available and no longer applies especially since FDISK doesn't know how to set up LVM and Compatibility volumes required for installation.

5.10.5.1 Disk Partitioning Using LVM during CID

If you are installing a new server from scratch (that is, pristine installation), and you want to install it unattended using CID, then you need to partition the disks and set up the volumes as required for the rest of the installation.

The supporting files for LVM are located on the OS/2 Warp Server for e-business CD-ROM in \OS2IMAGE\DISK_6. They are:

The following example illustrates the use of LVM from the command line. Your syntax may vary depending on how you want to set up your server disk. The full command-line syntax of LVM is available in A.3 LVM Command-Line Syntax.

  1. First, we delete all definitions on the hard disk by typing:
    lvm /delete:all,volumes
    lvm /delete:all,unused
    lvm /delete:all,primary
    lvm /delete:all,lvm
    lvm /delete:all,logical
    lvm /delete:all,compatibility
    

  2. Now that the disk is empty, create a Boot Manager partition:
    lvm /bootmgr:1
    

  3. Partition the hard disk and create volumes:
    lvm /create:partition,SoS,1,32,primary,bootable
    lvm /create:volume,compatibility,bootos2,c:,SoS,1,SoS
    lvm /create:partition,system,1,512,logical,bootable
    lvm /create:volume,compatibility,bootos2,d:,system,1,system
    lvm /create:partition,dump,1,129,logical,nonbootable,[ FS1 ],fromstart
    lvm /create:volume,compatibility,noboot,e:,dump,1,dump
    lvm /create:partition,data,1,512,logical,nonbootable,[ FS1 ],fromstart
    lvm /create:volume,lvm,f:,data,1,data
    

For our example, our definitions produce the following disk layout when using the lvm /query command as shown in Figure 53:



Disk                 Size (MB) Free Space:  Total Largest
                          4118               2902    2902
   Disk Partition       Size (MB) Type     Status      Logical Volume
   [ BOOT MANAGER ]             7 Primary  In use
   SoS                         39 Primary  In use      SoS
   system                     517 Logical  In use      system
   dump                       133 Logical  In use      dump
   data                       517 Logical  In use      data
   [ FS1 ]                   2902 Logical  Available

Figure 53: LVM Command Line Example Results

5.10.6 Install Base OS/2 Operating System (SEINST)

Once the machine has been booted from the maintenance system, SEINST can be called to start the first phase of installation of the base OS/2 operating system.

If an environment variable REMOTE_INSTALL_STATE exists, and if the value is 0, SEINST first copies back the saved versions of CONFIG.SYS, AUTOEXEC.BAT, and STARTUP.CMD. It then calls a program called RSPINST, which actually performs the installation.

The directory or partition that the maintenance system was installed to is specified by the /T: parameter of SEINST. After the successful installation of OS/2, SEINST cleans up this directory since it is no longer required.

SEINST Syntax
SEINST /S:<Source_Path> /T:<Target_Path> /B:<Boot_Drive> /L1:<Log_File> /R:<Response_File>

For full details of the syntax of SEINST, refer to The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010&CID. or OS/2 Installation Techniques: The CID Guide, SG24-4295.

5.10.6.1 SEINST LCU Command File Syntax

In our working example, the invocation of SEINST, as provided in our LCU client command file, is as follows:


x.seinst     = 1
x.1.name     = 'OS/2 4.0'
x.1.statevar = 'CAS_' || x.1.name
x.1.instprog = exepath'\seinst',
                ' /b:'bootdrive,
                ' /s:'OS2img,
                ' /t:'maintdir,
                ' /l1:'logdir'\'client'.OS2',
                ' /r:'
x.1.rspdir   = resdir'\OS2\'
x.1.default  = 'UNIsrv.rsp'

Figure 54: Extract of LCU File Illustrating SEINST Program Invocation

Where the variable is:

OS2img = imgdir'\OS2\XR09999'

Note

SEINST will return CID return codes 0xFF01 or 0xFF02 (reboot and call me back) upon successful completion when started from a maintenance system or from boot diskettes.

The reason for this is that &Feature. cannot be started since there is no Presentation Manager in these environments. When called again following a reboot, SEINST starts CLIFI to complete the installation process.

When you are using co-requisite groups of NetViewDM/2, this will not work correctly. Please refer to Section 5.12 NVDM/2 and SWD Implementation for further information.

We recommend that you ignore the return code and start &Feature. later whenever it is suitable during your installation process. In our environment, we have changed the REXX procedure so when SEINST returns the 0xFF01 or 0xFF02 return codes, they are ignored, the Install State is incremented regardless, and environment data is saved. Two extracts of the LCU files before and after modification are shown in Figure 55 and Figure 56.



 CheckBoot: /*------------------*/

  if QUEUE_REBOOT <> 0 then do
    if CALL_AGAIN == 0 then
      rc = SetState(OVERALL_STATE+1)
    Call SaveStates
    Call Reboot
  end
  else
    rc = SetState(OVERALL_STATE+1)
  Return

Figure 55: Extract of LCU Command File before Modification for SEINST





 CHECKBOOT2: /*------------------*/

 /* Rewritten to avoid SEINST for 2nd time */

    if QUEUE_REBOOT <> 0
     then do
             RC = SetState(OVERALL_STATE+1)
             Call SaveStates
             Call Reboot
          end
     else do
             RC = SetState(OVERALL_STATE+1)
          end
    Return

Figure 56: Extract of LCU Command File after Modification for SEINST

SEINST and CLIFI share the same response file. To see a working example, please refer to Figure 59.

5.10.6.2 What if Errors Occur?

A failure of SEINST is probably one of the worst things that can happen during the installation process. In most cases, many files have already been updated resulting in an unpredictable mix of different versions on your hard disk. If this situation arises, recovery can prove very difficult.

In the case of such a failure, make sure that you check the log file. If it tells you that files were changed, you should restore the previous contents of the hard drive from your backup, correct the problem, and start the migration process from scratch. If the reason for the failure is obvious (such as insufficient hard disk space available) and nothing was changed, you may be able to fix the problem and re-invoke SEINST.

Useful Hint

When SEINST aborts, reporting that RSPINST could not be executed successfully, you might try to call RSPINST directly for testing purposes in order to view the error messages. RSPINST accepts only one parameter, the fully qualified path and name of the response file. RSPINST's return codes are listed in A.1 RSPINST Return Codes.

Remember

The maintenance system is running in this situation. Therefore, the collection of tools you can use is somewhat limited.

5.10.6.3 Base OS/2 Operating System Sample Response File

The tested, working response file used in our environment is shown in Figure 59. For a detailed explanation of all keywords, refer to SAMPLE.RSP in the \CID\EXE\OS2 of the OS/2 Warp Server for e-business CD-ROM and to 5.10.6.3.1 New Keywords in OS/2 Response File.

If you want to install the OS/2 2.11 in a CID environment, make sure that the keyword RebootRequired = 0. Otherwise, the installation will start again and run in a loop. The software distribution manager (for example NetViewDM/2 or LCU) needs to receive a return code from SEINST and do some post-processing. The software distribution manager will check the return code and then issue a reboot if applicable.

New Keywords in OS/2 Response File

There are a few new keywords in the new OS/2 response file. If you have installed OS/2 Warp 4 using CID methods, you will already know most of them but be aware that some of the keywords introduced with OS/2 Warp 4 (especially those related to Java) have changed for OS/2 Warp Server for e-business.

New keywords control the installation of components, such as MarkVision, which are installed with &Feature.. The common syntax for these keywords is:

Component.Variable = Value

All components that use the new syntax have, as a minimum, the keyword Component.Selection. A value of 0 means Do not install while a value of 1 means Install. Drives are represented, for example, as D:.

For example, the new keyword HOTPLUG.Selection=0 means that you do not want to add the support for an external floppy disk drive.

Note

It might differ from other information available to you. It is based on our experience testing the product.

A very important new keyword is FormatJFS. It allows you to format any partition (except the bootable partitions) with JFS. Just insert the drive letters to be formatted (separated by a comma) after the equal sign.

A list of all the new keywords follows.

The following new keywords are NOT included in SAMPLE.RSP but provide a way of selecting or deselecting other software that is installed based on a default setting when CLIFI is used.

Note

If the Java Samples or the Java Toolkit is selected, the Java Runtime must also be selected, or 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 or JFS since Java needs long file name support. If your boot drive is not HPFS, or you have another HPFS or JFS drive that you want to use for the Java selections, then add the following keyword on a new line after the Java11.Selection keyword.

FIBASE.JavaDrive=X:
  • where X: is the drive you want to use.
  • In our working example OS/2 response file, shown Figure 57, we have included the keywords for all Feature Installer components that come with the base OS/2 operating system. Note that, although we have included all the keywords, not all are set to install.

    The keywords set in the OS/2 response file needed by Feature Installer are used during Phase Two of the installation.

    When looking at the SEINST log file after successful completion, you will see that it lists errors for some of the new keywords. Do not worry (see "Important Note" earlier in 5.10.6.3 Base OS/2 Operating System Sample Response File). SEINST ignores these keywords, and CLIFI processes them correctly later.


    
    AdditionalPrinters=0
    APM=0
    AlternateAdapter=0
    * BaseFileSystem=1
    CDROM=1
    CountryCode=001
    CountryKeyboard=US
    DefaultPrinter=0
    DisplayAdapter=0
    Documentation=1
    DOSSupport=0
    WIN-OS/2Support=0
    *WIN-OS/2Desktop=0
    *ExistingWindowsPath=
    *WindowsInstallSourcePath=\WINOS2\DISKETTES
    *ShareDesktopConfigFiles=1
    DPMI=1
    ExitOnError=1
    MousePort=0
    OptionalSystemUtilities=1
    OptionalSystemComponents=1
    *OS2IniData=/AppName/KeyName/KeyValue/
    PCMCIA=0
    
    * FormatFAT=C:,E:
    * FormatHPFS=D:
    * FormatJFS=F:
    * FormatQuick=C:,D:,E:,F:
    FormatPartition=0
    * Include=include.rsp
    * IncludeAtEnd=atend.rsp
    * IncludeInLine=inline.rsp
    MigrateConfigFiles=1
    Mouse=1
    
    
    Figure 57: OS/2 Response File with All Base and CLIFI Options (Part 1 of 3)



    
    PCMCIAOptions=0
    Optical=0
    Infrared=0
    PrimaryCodePage=1
    PrinterPort=1
    ProcessEnvironment=1
    ProgressIndication=1
    RebootRequired=0
    SCSI=1
    SerialDeviceSupport=1
    * SourcePath=D:\os2se20
    TargetDrive=D:
    *WIN-OS/2TargetDrive=D:
    SMP=0
    SMPPath=D:\OS2\BOOT
    ToolsAndGames=2,6
    * ConfigSysLine=call=D:\OS2\CMD.EXE /Q /C D:\LCUclient.CMD
    * Copy=vga D:\ /n:ini.rc
    * EarlyUserExit=T D:\config.sys
    * ExtendedInstall=PROGRAM.EXE
    * SeedConfigSysLine=REM This is a remark line in the seed CONFIG.SYS.
    * UserExit=T.EXE D:\OS2\INSTALL\INSTALL.LOG
    *DDISrc  = Z:\DDP
    *DDIDest = D:\
    *DDIDDP  = *.DDP
    MultimediaSupport=0
    ART.Selection=0
    DAXCOMP1.Selection=0
    DAXCOMP1.TarDrv=d:
    SRVDIAG.Selection=1
    SRVDOC.Selection=0
    ODSECBASE.Selection=1
    ODSECBASE.TarDrv=D:
    PRINTERUTIL.Selection=0
    PUHPJETCLIENT.Selection=0
    PUHPJETCLIENT.TarDrv=d:
    PUHPJETSERVER.Selection=0
    PUHPJETSERVER.TarDrv=d:
    PUMARKNET.Selection=0
    PUMARKNET.TarDrv=d:
    PUMARKVIS.Selection=0
    PUMARKVIS.TarDrv=d:
    HOTPLUG.Selection=0
    WARMSWAP.Selection=0
    WARMSWAP.ThinkPad=IBM ThinkPad 755CD/CDV
    WARMSWAP.ThinkPad=IBM ThinkPad 760C/CD
    WARMSWAP.ThinkPad=IBM ThinkPad 760E
    WARMSWAP.ThinkPad=IBM ThinkPad 760ED
    WARMSWAP.ThinkPad=IBM ThinkPad 760EL/ELD
    WARMSWAP.ThinkPad=IBM ThinkPad 760X/XD
    WARMSWAP.S506Parm=/A:1 /U:0
    WARMDOCK.Selection=0
    WARMDOCK.ThinkPad=IBM ThinkPad 755CD/CDV
    WARMDOCK.ThinkPad=IBM ThinkPad 755CE/CSE/CV/CX
    WARMDOCK.ThinkPad=IBM ThinkPad 760C/CD
    WARMDOCK.ThinkPad=IBM ThinkPad 760E
    WARMDOCK.ThinkPad=IBM ThinkPad 760ED
    WARMDOCK.ThinkPad=IBM ThinkPad 760EL/ELD
    WARMDOCK.ThinkPad=IBM ThinkPad 760X/XD
    
    
    Figure 58: OS/2 Response File with All Base and CLIFI Options (Part 2 of 3)




    
    Java11.RunDrv=d:
    Java11.Selection=1
    runtime.selection=1
    runtimeconfig.selection=1
    samples.selection=0
    samplesconfig.selection=0
    samples.smpdrv=d:
    samples.smppath=\JAVA11
    toolkit.selection=0
    toolkitconfig.selection=0
    toolkit.tktdrv=d:
    toolkit.tktpath=\JAVA11
    tlktdoc.selection=0
    tlktdocconfig.selection=0
    tlktdoc.tdocdrv=d:
    tlktdoc.tdocpath=\JAVA11
    debugger.selection=0
    debuggerconfig.selection=0
    debugger.dbgdrv=d:
    debugger.dbgpath=\JAVA11\ICATJAVA
    IBMFONTA.Selection=0
    IBMFONTG.Selection=0
    IBMFONTT.Selection=0
    IBMFONTJ.Selection=0
    IBMFONTC.Selection=0
    IBMFONTS.Selection=0
    IBMFONTK.Selection=0
    IBMFONTU.Selection=1
    XIBMFONT.InstDrive=d:
    LVMGUI.Selection=1
    
    
    Figure 59: OS/2 Response File with All Base and CLIFI Options (Part 3 of 3)

    Note
  • This response file installs OS/2 Warp Server for e-business without formatting the boot partition because it is a migration. If this was a pristine installation, then the following keywords could be used:
    * FormatFAT=C:,E:

  • * FormatHPFS=D:

  • * FormatJFS=F:

  • * FormatQuick=C:,D:,E:,F:
  • 5.10.7 Multi Protocol Transport Services (MPTS)

    The easiest way to upgrade MPTS is to reinstall it using the same values in the response file that were specified during the last installation. Installing MPTS immediately following the migration of the base OS/2 operating system saves one reboot in the overall installation cycle.

    During our testing, we found no significant changes in the way MPTS is installed compared to previous versions.

    MPTS CID Installation Syntax
    MPTS /E:<env> /S:<source_path> /T:<target_path> /TU:<config_path> /R:<response_file> /L1:<log_file>
    

    For full details of the syntax of MPTS, refer to The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010&CID. or &CID..

    Please Note

    Of all the parameters used, it is important to note that we are installing in maintenance mode, and, therefore, use the parameter /E:MAINT for this.

    5.10.7.1 MPTS LCU Command File Syntax

    In our working example, the invocation of MPTS, as provided in our LCU client command file, is as follows:

    
    x.mpts       = 2
    x.2.name     = 'MPTS 5.5'
    x.2.statevar = 'CAS_' || x.2.name
    x.2.instprog = MPTSimg'\mpts',
                     ' /e:maint',
                     ' /s:'MPTSimg,
                     ' /t:'mptsdrive'\',
                     ' /tu:'bootdrive'\',
                     ' /l1:'logdir'\'client'.MPTS',
                     ' /r:'
    x.2.rspdir   = resdir'\mpts\'
    x.2.default  = client'.rsp'
    
    
    Figure 60: Extract of LCU File Illustrating MPTS Invocation

    Where the variable MPTSimg is defined as:

    MPTSimg = imgdir'\MPTS\WR08620'
    

    5.10.7.2 MPTS Sample Response File

    The working response file used in our environment is shown below.

    Please Note

    No additional tuning has been done. This response file is just an example that needs to be customized.



    
    ******************************************************************
    * Model Response File for :                                      *
    *                                                                *
    * Multi Protocol Transport Services                              *
    ******************************************************************
    
    INST_SECTION = (
        Install       = Product
        Target        = D:
        Upgrade_Level = New
                   )
    
    PROTOCOL = (
    
    [PROT_MAN]
    
       DRIVERNAME = PROTMAN$
    
    [IBMLXCFG]
    
       landd_nif = landd.nif
       netbeui_nif = netbeui.nif
       tcpbeui_nif = tcpbeui.nif
       tcpip_nif = tcpip.nif
       ibmmpc_nif = ibmmpc.nif
    
    [NETBIOS]
    
       DriverName = netbios$
       ADAPTER0 = netbeui$,0
       ADAPTER1 = tcpbeui$,1
    
    [landd_nif]
    
       DriverName = LANDD$
       Bindings = ibmmpc_nif
       ETHERAND_TYPE = "I"
       SYSTEM_KEY = 0x0
       OPEN_OPTIONS = 0x2000
       TRACE = 0x0
       LINKS = 8
       MAX_SAPS = 5
       MAX_G_SAPS = 0
       USERS = 3
       TI_TICK_G1 = 255
       T1_TICK_G1 = 15
       T2_TICK_G1 = 3
       TI_TICK_G2 = 255
       T1_TICK_G2 = 25
       T2_TICK_G2 = 10
       IPACKETS = 250
       UIPACKETS = 100
       MAXTRANSMITS = 6
            MINTRANSMITS = 2
       TCBS = 64
       GDTS = 30
       ELEMENTS = 800
    
    
    Figure 61: MPTS Response File Example (Part 1 of 3)



    
    NETFLAGS = 0x0
    
    [netbeui_nif]
    
       DriverName = netbeui$
       Bindings = ibmmpc_nif
       ETHERAND_TYPE = "I"
       USEADDRREV = "YES"
       OS2TRACEMASK = 0x0
       SESSIONS = 254
       NCBS = 254
       NAMES = 40
       SELECTORS = 50
       USEMAXDATAGRAM = "NO"
       ADAPTRATE = 1000
       WINDOWERRORS = 0
       MAXDATARCV = 4168
       TI = 30000
       T1 = 1000
       T2 = 200
       MAXIN = 1
       MAXOUT = 1
       NETBIOSTIMEOUT = 500
       NETBIOSRETRIES = 1
       NAMECACHE = 1000
       RNDOPTION = 1
       PIGGYBACKACKS = 1
       DATAGRAMPACKETS = 50
       PACKETS = 300
       LOOPPACKETS = 8
       PIPELINE = 5
       MAXTRANSMITS = 6
       MINTRANSMITS = 2
       DLCRETRIES = 10
       FCPRIORITY = 5
       NETFLAGS = 0x0
    
    [tcpbeui_nif]
    
       DriverName = tcpbeui$
       Bindings = ,ibmmpc_nif
       NODETYPE = "B-Node"
       OS2TRACEMASK = 0x0
       SESSIONS = 254
       NCBS = 254
       NAMES = 40
       SELECTORS = 15
       USEMAXDATAGRAM = "NO"
       NETBIOSTIMEOUT = 500
       NETBIOSRETRIES = 1
       NAMECACHE = 1000
       PRELOADCACHE = "NO"
       NAMESFILE = 0
       DATAGRAMPACKETS = 20
       PACKETS = 50
       INTERFACERATE = 300
    
    [tcpip_nif]
    
       DriverName = TCPIP$
       Bindings = ibmmpc_nif
    
    
    Figure 62: MPTS Response File Example (Part 2 of 3)



    
    [ibmmpc_nif]
    
       DriverName = IBMMPC$
       NetAddress = "400000000163"
       MaxTransmits = 31
       MaxTxFrameSize = 18000
       MinRcvBuffs = 20
       SizWorkBuf = 2048
       MulticastNum = 16
       EnableTxEofInt = "YES"
       Enet20UTP = "NO"
       EnableHiPriTx = "NO"
       HiPriTxAccess = 5
       HiPriTxThresh = 4
       LLCOnly = "NO"
       EnableTRFDX = "YES"
    
      )
    
     MPTS = (
    
      [CONTROL]
        Local_IPC      = YES
        INET_Access    = YES
        NETBIOS_Access = NO
      [IFCONFIG]
        Interface      = 0
        Address        = 9.3.1.163
        Brdcast        =
        Dest           =
        Enable         = UP
        NetMask        = 255.255.255.0
        Metric         = 0
        Mtu            = 4096
        Trailers       = NO
        Arp            = NO
        Bridge         = NO
        Snap           = NO
        Allrs          = NO
        802.3          = NO
        Icmpred        = NO
        Canonical      = NO
      [ROUTE]
        Type           = default
        Action         = add
        Dest           =
        Router         = 9.3.1.74
        Metric         = 1
    
      )
    
     RESOLV = (
        NAME = domain itsc.austin.ibm.com
        NAME = nameserver 9.3.1.69
    )
    
    
    Figure 63: MPTS Response File Example (Part 3 of 3)

    5.10.8 File System Redirection (THINIFS)

    The SrvIFS (Server Installable File System) provides an easy means of redirection. THINIFS installs the necessary SRVIFS redirection files on the hard disk.

    We executed THINIFS twice to obtain two redirected drives for the next part of the installation having rebooted to enable Presentation Manager mode.

    THINIFS Syntax
    THINIFS /S:<Source_Path> /T:<Target_Path> /SRV:<CodeServer_Name> /REQ:<Client_Name> /D:<Drive_Letter> /TU:<ConfigSys_Path> /L1:<LogFile_Name> /NS:<NB_Sessions> /A:<IFS_Option> /W
    

    For full details of the syntax of THINIFS, refer to The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010&CID. or &CID..

    5.10.8.1 THINIFS LCU Command File Syntax

    In our working example, the invocation of THINIFS, as provided in our LCU client command file, is as follows:

    
    x.thinifs     = 16
    x.16.name     = 'SRVIFS Requester'
    x.16.statevar = ''
    x.16.instprog = imgdir'\srvifs\thinifs',
                      ' /s:'imgdir'\srvifs',
                      ' /t:'BOOTDRIVE'\srvifsrq',
                      ' /tu:'BOOTDRIVE'\',
                      ' /l1:'logdir'\'client'.thinifs',
                      ' /req:'client,
                      ' /srv:'server1'shareA',
                      ' /d:'shareA
    x.16.rspdir   = ''
    x.16.default  = ''
    
    
    Figure 64: Extract of LCU File Illustrating THINIFS Program Invocation

    Where variable imgdir has already been explained.

    Note

    Only one invocation of THINIFS is provided. The other is nearly identical. Refer to the redbooks mentioned above for further assistance.

    5.10.9 LCU Installation (CASINSTL)

    CASINSTL installs the LAN CID Utility client code, which is the actual software distribution manager that works with SRVIFS.

    CASINSTL Syntax
    CASINSTL /TU:<Boot_Drive> /CMD:<LCU_Path> /D /D:<Default_CMDFile> /L1<LogFile> /L2<LogFile2> /PL:<Path_Values> /PA:<LCU_Path> /PD /REQ:<Client_Name> /0
    

    For full details of the syntax of CASINSTL, refer to The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010&CID. or OS/2 Installation Techniques: The CID Guide, SG24-4295.

    5.10.9.1 CASINSTL LCU Command File Syntax

    In our working example, the invocation of CASINSTL, as provided in our LCU client command file, is as follows:

    
    x.casinstl    = 18
    x.18.name     = 'LAN CID Utility'
    x.18.statevar = ''
    x.18.instprog = ciddir'\locinstu\casinstl',
                      ' /cmd:'lcucmd,
                      ' /tu:'BOOTDRIVE,
                      ' /pl:'DLLPATH,
                      ' /pa:'ciddir'\locinstu',
                      ' /l1:'logdir'\'client'.cluerr',
                      ' /l2:'logdir'\'client'.clulog',
                      ' /d',
                      ' /req:'client
    x.18.rspdir   = ''
    x.18.default  = ''
    
    
    Figure 65: Extract of LCU File Illustrating CASINSTL Invocation

    5.11 Installation - Phase One