═══ 1. Corrective Service Facility Overview ═══ Corrective Service Facility (CSF) is a utility program that you can use to apply service updates to the OS/2* operating system and to OS/2-based subsystems and applications. You can use CSF to apply either a full service package (ServicePak) or a fix service package (FixPak). A ServicePak contains all code fixes that have been developed since the last product release. Applying a ServicePak updates the corrective service level (current CSD level) of the product. (You can display the current CSD level by entering the SYSLEVEL command from an OS/2 command prompt.) A FixPak replaces or updates a subset of product files. Applying a FixPak updates the fix level of the product but does not affect the current CSD level. (You can view the fix level of the product in the service log, described in Viewing the Service Log.) CSF simplifies the process of applying service to a product because CSF: o Lets you apply service to either a single system or to multiple systems in a LAN environment o Prevents you from applying service that is inappropriate for your system o Allows you to "back out" of the service you applied, which restores your system to a previous level o Allows you to "commit" to the level of service you applied, which frees disk space on your system used by CSF o Creates a service log that tracks all service applied to a product o Handles unexpected conditions while continuing to apply service The sections that follow define CSF terms and explain the CSF process. The steps to use CSF are described in Using CSF. ═══ 1.1. Applying Service in Single System and LAN Environments ═══ CSF provides an interface for applying service to a single system and an interface for applying service in a LAN environment: The SERVICE facility is a graphical interface for updating a single system without restarting the system. SERVICE prompts you to enter information in service windows and enables you to choose the products you want to update with service or restore to an earlier level. The FSERVICE facility is a command-oriented interface. You can use FSERVICE in a minimal OS/2 environment, such as when you start CSF from diskette, and in attended or unattended configuration, installation, and distribution (CID) environments and NetView* Distribution Manager/2 (NetView DM/2) environments, in which service is applied to multiple remote systems attached to a local area network (LAN). You submit your service request to FSERVICE using command line parameters and a response file in which you code your service request using FSERVICE keywords and parameters. ═══ 1.2. Ensuring That Service is Appropriate ═══ Whether you use SERVICE or FSERVICE, CSF ensures that the country code, version, release level, and current CSD level of your product are compatible with the service updates, and will not proceed with service if there is a mismatch. Information about the level of the products on your system is contained in the SYSLEVEL.xxx file on the OS2 directory of the boot drive. ═══ 1.3. Restoring a Product to a Previous Level ═══ Occasionally, even a service package that is compatible with a product can cause problems when it interacts with the other products on your system. CSF enables you to remove a service package and restore your product to its previous level without requiring you to reinstall the product. Removing a service package is called "backing out" of a ServicePak or a FixPak. CSF enables you to restore a product in either of two ways: o You can remove all service applied to the product since it was installed or last committed, which restores the product to its base level. (Committing a Product with Service Applied explains what it means to "commit" a product.) o You can remove the most recent service package applied to the product, which restores the product to its previous fix level. ═══ 1.3.1. Restoring a Product to Its Base Level ═══ Depending on the product you are servicing, CSF might save a copy of your product files before applying service to the product. This copy of your "base" (installed or committed) level files is called an archive. You can use an archive to restore your product to its base level at any time during service. In general, an archive is required by products that take considerable time and multiple diskettes to install, and not required by products that can be reinstalled easily with few diskettes. When a product requires an archive, neither the SERVICE nor FSERVICE facilities will apply service to it until you specify a location for the archive. When a product does not require an archive, the SERVICE facility will not allow you to specify an archive location. The FSERVICE facility will return the error message "Archiving is disabled for the product" and provide the path to the SYSLEVEL file for the product. When an archive is required, CSF copies the product files that are at the base level and are to be updated by a service package. CSF saves these copies in the archive before applying service. The first time you apply a service package to a base-level product, all files to be updated by the service package are copied into the archive. Each time you apply a subsequent service package to the product, CSF copies into the archive only the product files that were not serviced previously (the product files that are still at the base level.) If service has been applied to the file before, the file is not copied into the archive. In this way, CSF saves a copy of your base-level product that you can restore even after you have applied multiple service packages. For example, FixPak 1 updates product files A, B, and C, and FixPak 2 updates product files C and D. The product to which they are being applied is at the base level. Before applying FixPak 1, CSF copies files A, B, and C to the archive location you provide. When you later apply FixPak 2, CSF copies file D into the archive, because file D is still at base level. File C was updated by FixPak 1 and is no longer at base level, so CSF does not copy it into the archive. When a product requires an archive, you must specify an archive location when you: o Apply service to a product for the first time o Apply service to your product for the first time after committing the product with a service package applied You can save an archive on diskette or on a local or remote hard disk. You should provide 5 to 10 megabytes of disk space for a product archive. After an archive has been created for a product, CSF uses that archive until you: o Redirect CSF to an archive at another location (described in Redirecting CSF to a Different Archive.) o Commit the product with a ServicePak applied to it CSF saves only one archive per product. It adds to the archive each time a service package updates a base-level file. You can save copies of product files with service applied by creating a backup of your product files each time you apply a new service package. ═══ 1.3.2. Restoring a Product to a Previous Fix Level ═══ A backup is a copy of product files to which service has been applied at least once. At your request, CSF saves a copy of your current product files before applying the next level of service to the product. The backup enables you to restore your product to its level of service before the most recent service was applied. You request a backup by specifying a path and directory in which CSF is to create the backup. The directory can be located on either a local drive or diskette but cannot be on a network drive. If both the archive and the backup are located on diskette, they must be on separate diskettes. Creating a backup is optional. However, if you do not create a backup when you apply service, the only way to back out of the current service package is to restore the product to the archive level. You cannot use a backup created when you applied an earlier service package to back out of the current service package. If a product has one or more FixPaks applied to it, it is a good idea to create a backup before applying a new FixPak. The backup enables you to restore the product with any previously-applied service intact. You can have only one backup of a product at a time. If a backup already exists when you request a backup, the older backup is deleted. You cannot create a backup before an archive has been saved. ═══ 1.3.3. Redirecting CSF to a Different Archive ═══ At some time after CSF has created an archive, you might want to move the archive to another location, such as a drive with more free disk space, or a LAN server where multiple systems with identical product levels can share the archive. After you (or your LAN administrator) have copied the archive to the new location, you can redirect CSF to use the new archive location. (The archive files must be present at the new archive location before you redirect CSF, and the system level and files of the archive in the new location must match those of the archive in the old location.) Redirecting CSF changes the reference to the archive location but does not copy the files. After you ensure that the archive files exist in the new location, you can use the Redirect window of the SERVICE facility or the REDIRECT keyword of the FSERVICE facility to redirect CSF to the new archive location. ═══ 1.4. Committing a Product with Service Applied ═══ After you apply service to a product, you will probably spend some time testing it to see how the service affects your system. When you are satisfied with a service package, you no longer need the ability to restore your previous level system. At this point, you can commit the product with the service installed. Committing the product with a FixPak applied frees the disk space used by your backup files. Committing a product with a ServicePak applied frees the disk space used by the backup files and also removes the reference to the archive. To free the disk space used by the archive, you must manually delete the archive files. CSF does not delete archive files because they can be used by multiple systems or products. After a product is committed, you cannot restore the product to an earlier fix level. When you commit a product with a ServicePak applied, you cannot restore the product to an earlier fix level or to the archive level. After applying a ServicePak to a product, you must commit the product before you can apply additional service to it. The SERVICE facility identifies the products that must be committed before you can apply additional service. It also enables you to commit those products from a single window. Committing a product before applying additional service makes it easier to identify which service package to back out of, should a fix be incompatible with your system. ═══ 1.5. Viewing the Service Log ═══ CSF creates a service log in which it tracks all service applied to a product. The service log is named SERVICE.LOG, and is located by default on the OS2\INSTALL directory of the boot drive. (The FSERVICE utility enables you to specify a different location for the service log.) The service log contains the following information: o The name and level of the product that was updated. o The specific identity and level of the FixPak that was installed. o The date and time the FixPak was installed. o The type of CSF operation (for example, the application of a FixPak or a back out to a previous service level). o The new files that have been copied to the disk. Copy operations are logged with lines that are labelled "Copying" and include the full path name of the file on the disk. o The existing files that have been updated on the disk. Updates are considered to be either full file replacements or file patches. Update operations are logged with lines that are labelled "Updating" and that include the full path name of the target file on the disk. o The files that have been copied to an archive. Archive operations are logged with lines that are labelled "Archiving" and that include the full path name of the file in the archive path. o The files that have been copied to the backup. Backup operations are logged with lines that are labelled "Backing up" and include the full path name of the file in the backup path. CSF also creates and maintains the following files for its own use. Do not modify the following files: ARCHIVE_.xxx FIXSTART All files in the IBMCSFLK directory IBMCSFLK.DLL IBMCSFLK.EXE IBMCSFLK.LST IBMCSFLK.LOG IBMCSFLK.MGT IBMCSFLK.SYS LOGF0000.xxx LOGSTART.xxx ═══ 1.6. Handling Unexpected Conditions ═══ CSF handles unexpected conditions, such as locked files and service interruptions. When CSF encounters a locked file that is to be updated or replaced, it postpones the processing of that file until the next time you restart the system, and it continues applying service. To process the locked files, you must restart the system before you can apply another service package to it; however, you can delay restarting until a convenient time, such as the end of the work day. If you are using the SERVICE facility and CSF finds that there is not enough free disk space on your system to process locked files, you will be prompted to use the FSERVICE facility. The response file CSF_SEL.000 (on the root directory of the first boot drive) contains the tags generated by your input to the SERVICE facility up until CSF attempted to process the locked files. Complete the response file using the syntax described in Using the FSERVICE Response File and restart CSF from diskette. If a service interruption such as a power outage or a cable disconnection occurs while you are using SERVICE or FSERVICE in an attended CID environment, you can allow CSF to continue to apply service or discontinue applying service temporarily. When you resume the service, CSF begins at the point when the interruption occurred and continues to apply service. If you are using FSERVICE in an unattended CID or NetView DM/2 environment when a service interruption occurs, CSF returns an error to the host and you cannot apply subsequent service packages until you successfully reapply the interrupted service package. A message in the log file indicates that recovery is pending for a particular service package. Note: If a service interruption occurs, it is a good idea to issue the OS/2 command CHKDSK with the /F parameter before resuming service. CHKDSK analyzes files and cleans up file fragments that might result from a service interruption. See "OS/2 Command Reference" for information about the CHKDSK command. ═══ 2. Using CSF ═══ Your interface to CSF depends on the environment in which your system is running. You use the graphical SERVICE facility to update a single running system or the command-oriented FSERVICE response file to update multiple systems in a LAN environment. ═══ 2.1. Using the SERVICE Facility ═══ The SERVICE facility is a graphical interface that uses service windows to prompt you for input when applying service to one or more products on your system. Follow the steps below to start CSF and use the SERVICE facility. 1. Open an OS/2 window. 2. Insert "CSF Diskette 1" into drive A 3. Change the directory to drive A. 4. Type SERVICE at the command prompt, and press Enter. 5. In the OS/2 Corrective Service Facility window, select Ok to display the Serviceable Products window. ═══ 2.1.1. Applying Service ═══ The Serviceable Products window displays the products on your system to which service can be applied. The serviceable products displayed in the Products field: o Are installed on your system o Have updates in the FixPak or ServicePak that you are applying o Have SYSLEVEL files that are compatible with the SYSLEVEL files of the service you are applying. All serviceable products are initially selected and highlighted in the Products field. If you do not want to apply service to one or more products listed, deselect those products that you do not want to service. The products that you deselect will no longer be highlighted and service will not be applied to them. If this is the first time that service is being applied to a selected product, you must specify in the Archive field the path and directory for the archive of the product. If an archive already exists for the product, you cannot modify the path that appears in the Archive field. See Restoring a Product to Its Base Level for more information on archives and archive paths. If service has been applied previously to a selected product, you can optionally specify in the Backup field the path and directory for a backup of the product. If an archive has not yet been saved for the product, you will not be able to modify the Backup field. See Restoring a Product to a Previous Fix Level for more information on backups and backup paths. When only the products to which you are applying service are highlighted, select Service to apply service to the products. To display a list of products that have archives, backups, or a list of products that can be committed, select Change Product List. ═══ 2.1.2. Changing the Product List ═══ The Change Product List push button displays a window in which you can select one of the four product lists that CSF maintains. The type of product list that you select determines the actions you can perform on the selected products. If you select a product list that does not exist, such as when no products on the system have backups, CSF issues a message. CSF maintains the following product lists: Serviceable Products A list of products on your system to which you can apply service. When you select Serviceable Products, you can use the window that is displayed to apply service to the selected products. Archived Products A list of products on your system that have archives. When you select Archived Products, you can use the window that is displayed to restore the selected products to the archive level or to redirect CSF to a different archive location. Backed Up Products A list of products on your system that have backups. When you select Backed Up Products, you can use the window that is displayed to restore the selected products to the backup level. Uncommitted Products A list of products on your system that can be committed. When you select Uncommitted Products, you can use the window that is displayed to commit the selected products. ═══ 2.1.3. Redirecting CSF to Another Archive ═══ Use this window to direct CSF to an archive in a location that is different from the one specified in the Source directory field. To display the Redirect Service window: 1. Select the Change Product List push button. 2. Select the Archived products radio button. 3. In the Archived Products window, all products are initially selected. Deselect the products with archives that are to remain unchanged, and then select the Redirect pushbutton. When the Redirect Service window is displayed, you can view the list of products that have archives (in the Product field) and the location of the archives (in the Source directory field). Enter the new archive path in the Target directory field. The archive path can be on a diskette, on a local drive, or a network drive, and the archive files must be in place in the new location before you select Ok. ═══ 2.1.4. Backing Out of a Service Package ═══ Use the Back Out Service window to restore a product to its archive level or backup level. To display the Back Out Service window: 1. Select the Change Product List push button. 2. Do one of the following: o To restore a product to its archive level, select the Archived Products radio button. In the Archived Products window, all products are initially selected. Deselect the products that are not to be restored to the archive level, and then select the Back Out push button. o To restore a product to its backup level, select the Backed Up Products radio button. In the Backed Up Products window, all products are initially selected. Deselect the products that are not to be restored to the backup level, and then select the Back Out push button. When the Back Out Service window is displayed, you can view the selected products (in the Products field) and the level to which they will be backed out (in the Target Level field). Select Ok to restore the product to the target level. ═══ 2.1.5. Committing a Product ═══ Use this window to commit a product with either a FixPak or a ServicePak applied. Committing a product with a FixPak applied frees the disk space used by the backup for that product and removes the ability to restore the product to the backup level. You can still restore the product to the archive level. Committing a product with a ServicePak applied frees the disk space used by the backup for that product and removes the reference to the archive. You cannot restore the product to either the backup or archive level. To display the Commit Service window: 1. Select the Change Product List push button. 2. Select the Uncommitted Products radio button. 3. In the Uncommitted Products window, all products are initially selected. Deselect the products you do not want to commit, and then select the Commit push button. When the Commit Service window is displayed, you can view the product list, archive level, and back up level, and select Ok to commit the products. ═══ 2.2. Using the FSERVICE Response File ═══ This section provides a detailed look at the tags and syntax used in the FSERVICE response file. High-level examples follow the syntax descriptions. It also describes the FSERVICE command and parameters. Code your service request in the response file before starting the FSERVICE facility. Sample response files are included on: "CSF Diskette 2" if you have 3.5-inch diskettes "CSF Diskette 3" if you have 5.25-inch diskettes You can edit the sample file and customize the tags for your request. If you want to create a new response file, open a file named RESPONSE.FIL and code your FSERVICE request in it. Specify the location of the new response file in the CONFIG.SYS file or on the command line when you invoke FSERVICE. (See FSERVICE Command for information about the FSERVICE command and parameters, and the location of the CONFIG.SYS file.) Follow the steps below to start the FSERVICE facility. 1. Open an OS/2 window. 2. Insert "CSF Diskette 1" into drive A. 3. Change the directory to drive A. 4. Type FSERVICE at the command prompt, and press Enter. 5. Follow the instructions on your screen. ═══ 2.2.1. Applying Service to Multiple Systems ═══ The method of submitting your response file to CSF and applying service to multiple systems varies by the type of environment and how it has been set up. Review the documentation for your client-server environment before attempting to apply service in a LAN environment, and refer to the information in README.CID on the OS/2 Warp installation diskettes as well as the information in this document. ═══ 2.2.2. Response File Syntax ═══ You use two kinds of tags to code CSF requests in your response file. "General" tags specify how CSF is to process all the service requests in the response file. "Keyword" tags indicate the actions that CSF is to take and the products against which CSF is to take them. The following sections describe the general and keyword tags. ═══ 2.2.3. General Tags ═══ General tags indicate how CSF is to process the service requests in a response file. There are four general tags. The general tags describe: o The location of an alternate log file to contain the service history o Whether CSF is to issue or bypass certain verification messages o The location of the service package or the source path o The location of the archive or backup The following summary describes the optional and required general tags, and with which keyword tags they are coded. General Tag Keyword Requirements :LOGFILE Optional - can be coded with any keyword :FLAGS Optional - if coded, must be coded with :SERVICE :SOURCE Optional - if coded, must be coded with :SERVICE :TARGET Required with :BACKOUT Code any required general tags before their keyword tags in the response file. If a required general tag appears after its keyword in a file, FSERVICE will fail. If a general tag that is not required follows a keyword tag in the response file, the general tag will be ignored. A general tag is not position-dependent with other general tags, but each general tag must occur only once in a response file. :LOGFILE drive\path\filename Specifies that a log file other than the default log file is to be used. (The default log file is named SERVICE.LOG and is located on the directory of the SYSLEVEL file for the product.) Specify the drive, directory, and name of the alternate log file. CSF creates the alternate log file if it does not exist and appends the service history to the log file after it has been created. :LOGFILE is optional. :FLAGS flag1 │ flag2 │ flag3 Indicates that CSF is to bypass the specified verification messages while applying service. Code :FLAGS only when you code the :SERVICE keyword tag. If you specify :FLAGS in a response file that does not have the :SERVICE tag, the flags will be ignored. :FLAGS is optional. When you code :FLAGS, you must specify one or more of the following flags: REPLACE_NEWER Specifies that CSF is to replace product files that have more recent dates than the corresponding files on the service package. If REPLACE_NEWER is not specified, each time CSF finds a file with a more recent date than those in the service package, you must verify that the file can be replaced or cancel the replacement of the file. REPLACE_NEWER is coded in the sample response file on CSF diskette 2. Specify REPLACE_NEWER to avoid multiple verification messages when applying service to multiple products. REPLACE_PROTECTED Specifies that CSF is to replace files that are read-only, hidden, or system files. If REPLACE_PROTECTED is not specified, each time CSF finds a protected file, you must verify that the file can be replaced or cancel the replacement of the file. REPLACE_PROTECTED is coded in the sample response file on CSF diskette 2. Specify REPLACE_PROTECTED to avoid multiple verification messages when applying service to multiple products. EXIT_WHEN_DONE Tells FSERVICE to stop if any errors are encountered and to report the errors. :SOURCE drive\path Specifies the drive and directory of the service package you are applying to a product. :SOURCE is optional. You can specify :SOURCE in a response file that contains a :SERVICE tag, or on the command line when submitting a response file that contains the :SERVICE tag. If :SOURCE is omitted when :SERVICE is specified, the default source drive is drive A. If :SOURCE is coded in a response file that does not contain the :SERVICE tag, it is ignored. :TARGET ARCHIVE │ BACKUP Specifies that a product is to be backed out of a service package and restored to either the backup or archive level. You can specify only one :TARGET keyword per response file. All back out requests (specified by the :BACKOUT keyword tag) in the response file restore products to the level (either ARCHIVE or BACKUP) specified on :TARGET. To restore one product to the archive level and another product to the backup level, code the requests in separate response files. :TARGET is required in response files that contain the :BACKOUT keyword. When you code :TARGET, it must appear in the response file before the :BACKOUT keyword, and it must specify either ARCHIVE or BACKUP. If :TARGET appears in the response file after the :BACKOUT keyword, FSERVICE will fail. If :TARGET appears in a response file that does not contain the :BACKOUT tag, it is ignored. * Specifies that a comment follows. ═══ 2.2.4. Keyword Tags ═══ Keyword tags indicate the action to be taken against a specific product. Because the same product can be installed multiple times or in multiple partitions on a system, all keyword tags include a :SYSLEVEL tag to identify the specific occurrence of the product being updated or restored. You can use a single response file to take action against multiple products or multiple occurrences of the same product. However, you cannot code conflicting actions for the same product occurrence (represented by the same SYSLEVEL file), such as simultaneously committing a product and restoring it to its backup level. Similarly, you cannot duplicate requests against the same product occurrence. Conflicting or duplicate requests against a single product occurrence will cause FSERVICE to fail. :SERVICE Specifies that a service package is to be applied to a product. :SERVICE has two position-dependent parameter tags that must follow it and one optional parameter tag. Each tag must be on a line by itself. The parameter tags are: :SYSLEVEL drive\path\SYSLEVEL.xxx Specifies the drive and directory of the SYSLEVEL file of the product being serviced. This tag must follow the :SERVICE keyword in the response file. If you do not specify a drive, CSF applies service to all partitions. :ARCHIVE drive\path Specifies the drive and directory of the archive of the product being serviced. This tag must follow the :SERVICE keyword in the response file if this is the first time that service is being applied to the product. If you do not specify a drive, CSF will create an archive on all partitions to which service is being applied. :BACKUP drive\path Specifies the drive and directory of the BACKUP of the product being serviced. This tag can optionally follow the :SERVICE keyword in the response file if an archive for the product already exists. If you do not specify a drive, CSF will create a backup on all partitions to which service is being applied. :BACKOUT Specifies that the product is to be backed out of a FixPak or ServicePak to the level specified on the :TARGET tag. :BACKOUT has one position-dependent parameter tag, which must follow it on a line by itself. The parameter tag is: :SYSLEVEL drive\path\SYSLEVEL.xxx Specifies the drive, directory, and file name of the SYSLEVEL file of the product being backed out of a service package. This tag must follow the :BACKOUT keyword in the response file. :REDIRECT Specifies that CSF is to be redirected to a product archive other than the current product archive. :REDIRECT has two position-dependent parameter tags that must follow it, each of which must be on a line by itself. The parameter tags are: :SYSLEVEL drive\path\SYSLEVEL.xxx Specifies the drive, directory, and file name of the SYSLEVEL file of the product associated with the archive being redirected. This tag must follow the :REDIRECT keyword in the response file. :ARCHIVE drive\path Specifies the drive and directory of the new archive location. This tag must follow the :REDIRECT keyword in the response file. :COMMIT Specifies that a product is to be committed with either a FixPak or a ServicePak applied to it. :COMMIT has one position-dependent parameter tag, which must follow it on a line by itself. The parameter tag is: :SYSLEVEL drive\path\SYSLEVEL.xxx Specifies the drive, directory, and file name of the SYSLEVEL file of the product being committed. This tag must follow the :COMMIT keyword in the response file. ═══ 2.2.5. Applying Service ═══ The following example illustrates the FSERVICE response file syntax for applying service to a product and creating an archive on drive D. The :SOURCE general tag must appear before the keywords in the response file. If coded, the :FLAGS general tag must also appear before the keywords in the response file and must specify at least one of the three flags. :SOURCE A:\ :FLAGS REPLACE_NEWER REPLACE_PROTECTED :SERVICE :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2 :ARCHIVE D:\ARCHIVE ═══ 2.2.6. Redirecting CSF to Another Archive ═══ The following example illustrates the FSERVICE response file syntax for redirecting CSF to an archive on a LAN. There are no required general tags and no optional tags. Both :SYSLEVEL and :ARCHIVE must follow the :REDIRECT tag. :REDIRECT :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2 :ARCHIVE X:\CSD\OS2V3\ARCHIVE ═══ 2.2.7. Backing Out of a Service Package ═══ The following example illustrates the FSERVICE response file tags for backing out of a fix service package or a ServicePak to the previous fix level. There are no optional tags. You must specify BACKUP on the TARGET general tag to return to the previous fix level. :TARGET BACKUP :BACKOUT :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2 ═══ 2.2.8. Committing a Product ═══ The following example illustrates the FSERVICE response file tags for committing a product to a FixPak or a ServicePak. There are no required general tags and no optional tags. :COMMIT :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2 ═══ 2.2.9. FSERVICE Command ═══ You can use the FSERVICE command and parameters to provide additional input to FSERVICE about your service request, or to override the information specified in your response file. The FSERVICE command can be used in two ways: o When you have a command prompt available, such as when you invoke SEMAINT in a CID environment, you can specify the FSERVICE command at the command prompt. o You can modify the FSERVICE parameters in the CONFIG.SYS file. The CONFIG.SYS file is on "CSF Diskette 2" if you have 3.5-inch diskettes and "CSF Diskette 3" if you have 5.25-inch diskettes. The parameters that you specify on the command line override the response file tags. The parameters that you specify in the CONFIG.SYS file override those specified on the command line. ? Displays the FSERVICE command syntax and parameter descriptions on your computer screen. /S:drive\path Specifies the fully-qualified path to the ServicePak images. The path can specify either a local hard disk or a redirected drive on the code server. The path depends on the directory structure you have set up. If you use the directory structure recommended in the "LAN Configuration, Installation, and Distribution Utility Guide" and an OS/2 2.0 ServicePak, the path is \CSD\OS2V20\CSD01. This parameter is required. /T:drive\path Specifies the fully-qualified path to the directory from which the system was started. If the system was started from a maintenance system on the hard disk, this path matches the /T: parameter specified on the SEMAINT command. FSERVICE restores the CONFIG.SYS, STARTUP.CMD, and AUTOEXEC.BAT files from backups located in this directory. This parameter is optional. If you specify /T:drive\path when CSF is started from diskette, CSF does not validate the path specified on this parameter. /R:path\filename.ext Specifies the fully-qualified path to the FSERVICE response file. If you use the directory structure recommended in the "LAN Configuration, Installation, and Distribution Utility Guide" and an OS/2 2.0 ServicePak, the response file is located on \CSD\OS2V20\CSD01. This parameter is required. /L1:path\filename.ext /L:path\filename.ext Specifies the fully-qualified path to the service log. This parameter is optional. /CID Specifies that FSERVICE is to restore the following files from the backups made by SEMAINT: o OS2BOOT o OS2KRNL o OS2LDR o OS2DASD.DMD o OS2SCSI.DMD o OS2LDR.MSG This parameter is optional. Specify /CID only when FSERVICE is running under a maintenance system created by SEMAINT. /LARGE Specifies that the service package is on CD-ROM. /B:boot-drive-letter Specifies a boot drive letter for substitution of the %BOOTDRIVE% parameter in the directory list. ═══ 3. Notices ═══ References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any of IBM's intellectual property rights or other legally protectable rights may be used instead of the IBM product, program, or service. Evaluation and verification of operation in conjunction with other products, programs, or services, except those expressly designated by IBM, are the user's responsibility. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood NY 10594, U.S.A. IBM DISCLAIMS ALL WARRANTIES, WHETHER EXPRESSED OR IMPLIED, INCLUDING WITHOUT LIMITATION, WARRANTIES OF FITNESS AND MERCHANTABILITY WITH RESPECT TO THE INFORMATION IN THIS DOCUMENT. BY FURNISHING THIS DOCUMENT, IBM GRANTS NO LICENSES TO ANY RELATED PATENTS OR COPYRIGHTS. ═══ 3.1. Trademarks ═══ The following terms, denoted by an asterisk (*) in this publication, are trademarks of the IBM Corporation in the United States or other countries. NetView OS/2