Autoinstall - SH Utility Script Redp4296

Redpaper
Pete Soto Vasfi Gucer
Autoinstall.sh Utility Script

This IBM Redpaper explains the functions of the autoinstall.sh utility script, its requirements, operation, implementation, and procedures, to facilitate UNIX FTA fixpack installations that are initiated from the Tivoli Workload Scheduler master workstation. We provide two scenarios along with discussions about the various menus and options. Initial first time execution Subsequent executions Utility menus
Utility overview
The autoinstall.sh utility script is designed to run from the Tivoli Workload Scheduler Version 8.2.0, or greater, master workstation to install fixpacks on UNIX FTA (fault-tolerant agent) workstations with the following UNIX operating systems: AIX HPUX Linux_i386 Solaris The autoinstall.sh utility script, in conjunction with Tivoli Workload Scheduler (UNIX 8.2.0 or greater), reduces the amount of operations and hours required to
Copyright IBM Corp. 2007. All rights reserved.
ibm.com/redbooks
maintain FTA workstations that are current on maintenance fixpacks. This is accomplished by automating and monitoring UNIX FTA fixpack installations from a central location. Note: Lowercase should be used for all inputs, except for passwords, because they are case sensitive. The script uses existing UNIX tools, ssh and scp, to perform tasks between UNIX master and UNIX FTA workstations. The ssh protocol is used to provide a secure protocol between the master and FTA. SSH certificates may be created to eliminate the need to provide a password when connecting to a remote system. Refer to Configuring OPENSSH on page 77 for more details. Some operating systems may require that these tools be configured or installed, if they were not part of the initial operating system installation. Please consult with your UNIX administrator for configuration or installation assistance. The script is designed to work on AIX, HPUX, Linux_i386 and Solaris platforms. It must reside on the UNIX master and may only patch UNIX FTA workstations. The script must be run as root user, because the Tivoli Workload Scheduler fixpack installations require that root user execute the patch installation. Although written for Tivoli Workload Scheduler fixpack installation, the script may be customized to schedule and install or patch any application that has a UNIX command line installation option. Note: Any customizing is the responsibility of the user and will not be supported by Tivoli Level 2 support. The script may be placed in any directory. It will create temporary files in the /tmp directory. Any created temporary files will have an extension .#####, where ##### is the process ID for the script when executed. The temporary files will be removed when exiting the script normally.
Features
The following are the features of autoinstall.sh utility: The script runs on the server, and: Gathers and stores client installation information for patch installations or new product installations. Transfers installation scripts from the server to the client. Can be customized by the user to patch or install any product with a command line interface.
Uses Tivoli Workload Scheduler to: Schedule, launch and monitor the Tivoli Workload Scheduler patch installation or a new installation of any product with a command line interface from a central location.
Requirements
Here are the requirements of the solution.
System requirements
The autoinstall.sh utility script is designed to run from the Tivoli Workload Scheduler Version 8.2, or greater, master workstation on the following UNIX platforms and may only install fixpacks on UNIX FTA workstations. AIX HPUX Linux_i386 Solaris The .profile for the twsuser must have the TWSHome and TWSHome/bin directory in PATH variable for the master and FTA. You should be able to invoke Tivoli Workload Scheduler commands without having to specify the path. The FTA must be able to issue ssh and scp commands. The ssh protocol is used to provide a secure protocol between the master and FTA. Some operating systems may require that these tools be configured or installed, if they were not part of the initial operating system install. Please consult with your UNIX administrator for ssh and ssl configuration or installation assistance.
Autoinstall.sh script information and requirements

The autoinstall.sh script must run on a AIX, HPUX, Linux_i386 or Solaris master to patch AIX, HPUX, Linux_i386 or Solaris FTA workstations. The script may be run by multiple users to create or update files. Temporary files will be generated in the /tmp directory each time the script is run and will be removed when exiting normally from the script.
Attention: There is a known issue with the autoinstall.sh when it is run on Liniux_i386. The carriage return, which is not visible in AIX, HPUX and Solaris, appear as /c on Linux_i386 when running the autoinstall.sh script. The script functionality is not affected. A master domain manager (MDM) definition directory will be created when the script is executed using information from the Tivoli Workload Scheduler master user. This directory will be used to store information for applying fixpacks on FTA workstations that it manages. The /etc/TWS/APPL.tws directory, which will be the repository for utility scripts, will be created on the master the first time the script is run. The utility scripts for the FTA workstations will exist locally on the FTA in the /etc/TWS directory. The utility script can be used to copy (via scp) the utility scripts from the master to the FTA. The Tivoli Workload Scheduler utility scripts, patch_install.sh, and patch must be placed in the /etc/TWS/APPL.tws directory for the master workstation. The Tivoli Workload Scheduler fixpack installation scripts, patch_install.sh and patch_lau.sh, must be copied from the repository on the master (/etc/TWS/APPS.tws directory) to the /etc/TWS directory on FTA and should be executable by the Tivoli Workload Scheduler user, specified during the initial FTA Tivoli Workload Scheduler installation. If the master and FTA workstation exist on same node then the utility scripts must exist in both directories. Other applications directories, /etc/TWS/APPL.xxxx, may be created with the autoinstall.sh script to serve as a utility repository for other application scripts but the autoinstall.sh script must be customized by the user. The directory for these must be APPL.name where name is the name of the application in lowercase. Customizing will be the users responsibility and will not be supported by Tivoli Workload Scheduler level 2 support. Contact IBM Services for assistance with customizing. The autoinstall.sh script requires basic FTA information that is stored for future fixpack installations. The script extracts the node/ip, Tivoli Workload Scheduler version and operating system for FTA, provided FTA exists, in the current Symphony file and is linked. The user will need to provide the Tivoli Workload Scheduler user, specified at FTA installation and base path directory for fixpack repository. The FTA specific base path should include the Tivoli Workload Scheduler version and operating system in the path to facilitate user fixpack maintenance. Ideally the fixpack path should be an NFS mounted file system which is mounted on all FTA workstations using the following naming convention. The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os). Refer to Example 1.
Example 1 Fixpack base naming convention
Example: Base path directory for AIX FTA currently on TWS 8.3 /images/patches/8.3.0/aix Where: patchesbasepath = /images/patches twsverison = is 8.3.0 (use 3 digit format) os = aix (aix, hpux,linux_i386 or solaris) The FTA workstation information will be written to FTA.ftaname file, where FTA text is in uppercase and ftaname is the FTA workstation name in lowercase, as shown in Example 2.
Example 2 FTA.workstation file
Example: Information on FTA Borg will exist in a file called: FTA.borg The FTA file will exist in a sub-directory of its workstation master. The name of the directory is /etc/TWS/MDM.masteruser.mastername, where text MDM is in uppercase, masteruser is the Tivoli Workload Scheduler user for the master and the mastername is the workstation name of the master (lowercase). Refer to Example 3.
Example 3 MDM.masteruser.mastername definition directory
Example: TWS user m821 for master workstation Data will have the following directory for FTAs that it manages: MDM.m821.data The autoinstall.sh script will request specific patch information when patching an FTA. The patches must be in a sub directory named fp##. Refer to Example 4.
Example 4 Fixpack directory convention
The patches must be in a sub directory named fp##, where fp is in lowercase and ## is the two digit patch number for fixpack (fp01, fp02, fp10, fp11 etc...). Example: The following path must exist for patching a TWS 8.3 AIX FTA with fixpack FP01. /images/patches/8.3.0/aix/fp01 The autoinstall.sh script will verify that untarred fixpack files exist in the fp## sub directory. If only the fixpack tar file exists, it will suggest that it be untarred prior to
running the autoinstall script. It will also verify that the Tivoli Workload Scheduler version and patch level, specified in the menu, match the Tivoli Workload Scheduler version and patch level of the fixpack files. Patching will only be permitted if the specified fixpack is the same level or greater than the current fixpack level on the FTA workstation. After the information has been gathered and verified, a job definition will be created and added to the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. The job created will be unique to the FTA, because it will be for a specific fixpack. Note: Because each fixpack includes all fixes for previous fixpacks, entering multiple fixpacks for the same FTA workstation is not required. Concurrent autoinstall.sh scripts can be executed to add to the patch_job_def file. Duplicate job definitions in the patch_job_def file will be ignored when the job stream is created. The autoinstall.sh script will create the patch_lau_sch_def and patch_succ_sch_def files in the /etc/TWS/MDM.masteruser.mastername directory. These files will contain the definitions for the TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams. These definitions will run on the master once added to the Tivoli Workload Scheduler database. Unique job definitions created by the autoinstall.sh that exist in patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory will be added to the TWSPATCH_LAUNCH job stream. Multiple job definitions with the exact same name that exist in the patch_job_def file will exist only once in the TWSPATCH_LAUNCH job stream. The creation of the job stream operation may be run several times, because it will overwrite the previous job stream files. The autoinstall.sh script will be used to add the completed job and job stream definition files to the Tivoli Workload Scheduler database. Caution: Adding the job stream definitions to the Tivoli Workload Scheduler database will replace the existing job stream definition for TWSPATCH_LAUNCH and TWSPATCH_SUCC. After adding the job and job stream definitions files to Tivoli Workload Scheduler database, remove the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. This file may be removed using the autoinstall.sh script.
Attention: The fixpack job definitions should be removed from the Tivoli Workload Scheduler jobs database after the fixpack job has installed the fixpack. This is suggested to limit the number of jobs that will no longer be used, because the fixpack jobs are unique to the FTA and fixpack. The TWSPATCH_SUCC job stream will not have defined jobs, but will contain ad-hoc submitted jobs from FTA workstations when FTA fixpack jobs have completed successfully. The ad-hoc job will be submitted from the FTA when the fixpack installation completes successfully. Example 5 shows the naming convention for the job name of a successful fixpack installation.
Example 5 TWSPACTH_SUCC jobs
ftaname_twsver_FP_xx_jobnum_SUCC where: ftaname is the FTA workstation patched twsver is the TWS version xx is fixpack number (2 digit format) jobnum is the job number of FTA fixpack install job Example: Fixpack install job for TWS version 8.2 Fixpack 10, job number 5767 installed on FTA M82A successfully will have the this jobname in the TWSPATCH_SUCC job stream on master workstation: M82A_820_FP_10_5767_SUCC The provided scripts use variables for specific information. The debug option is the only customizable option in the autoinstall.sh script. DO NOT edit or modify any variables. Changes to the variables will cause script and installation problems and will not be supported by Tivoli Workload Scheduler Level 2 support. The patch_install.sh script executes the patch_lau.sh script after verifying that the information provided by the job is valid. The patch_lau.sh will inherit the values for variables that were defined in the patch_install.sh script. The patch_install.sh script executes patch_lau.sh, which initiates the fixpack install. This script, which requires four options: -uname, -patchdir, -version and patch, makes up the job definition created by the autoinstall.sh script. We recommend that autoinstall.sh script is used to create and add the job and job stream definitions. The patch_lau.sh script will create the ftaname_fp_fp##_jobnum.stdlog file in the /tmp directory. This will log procedures prior to executing the twspatch install. Once the twspatch installation launches, the fixpack installation will write to the log specified the fixpack readme file.
Tivoli Workload Scheduler requirements

The autoinstall.sh script must be run from Tivoli Workload Scheduler 8.2.0, or greater, UNIX master. The script may be placed in any directory. It will create temporary files in the /tmp directory. Any created temporary files will have a extension .#####, where ##### is the process ID for script when executed. The temporary files will be removed when exiting the script normally. The TWSRegistry.dat file must be correct and up to date, because the script extracts Tivoli Workload Scheduler FTA instance information, including fixpacks currently installed, from the file. Root user on the master must have access to Tivoli Workload Scheduler files and databases and must exist in the Tivoli Workload Scheduler Security file, because fixpack installations must be run as root. The root user on FTA must be able to submit ad-hoc jobs that logon as the root user on the master. The master must have a current Symphony file and be linked to FTA workstations that will be patched, because information will be extracted when the script is executed. The script uses the cpuinfo command to validate master and FTA workstations. The thiscpu= field in TWSHome/localopts and the master= field in TWSHome/mozart/globalopts file must be valid and correct on both master and FTA workstations, or Tivoli Workload Scheduler user validation issues may occur when the script is run. The autoinstall.sh script is used to add the job and job stream definitions to the Tivoli Workload Scheduler database. The definitions should be reviewed prior to adding them to the database. Duplicate job definitions will not be included in the job stream but will be added to the jobs database. If duplicate job definitions exist, the last one added to the jobs database will be used. Multiple fixpack installation jobs that install different fixpacks on the same FTA workstation should be avoided, because installing the latest fixpack includes all previous fixes. The script does not prevent this action.
Patching procedures
The autoinstall.sh script may be used to provide information for a fixpack install or create FTA.workstation definitions files for future fixpack installs.
Creating FTA.workstation definition files for future fixpack installations will speed up the process when applying a fixpack to an FTA. This option is useful if the master manages a large number of FTA workstations and is part of the utilities menu options. To perform either of these options requires the creation of specific files or directories which is accomplished by the initial execution of the autoinstall.sh script. This section discusses the first time execution and subsequent patching procedures using the patch option of the autoinstall.sh script.
Patching procedures - First time execution

The initial execution of the autoinstall.sh script will create files and directories with FTA specific information that will be used in future executions of the autoinstall.sh script. Certain tasks must be performed before executing the script. 1. Create patch repository for each FTA (refer to Autoinstall.sh Script Information and Requirements section). This is necessary, because this information will be requested when creating a FTA.workstation definition file (discussed later). 2. Verify that the localopts and globalopts on FTA and Master are correct. Incorrect information will cause problems in extracting or validating information. 3. Verify that the .profile for FTA TWSuser includes the TWSHome and TWSHome/bin directory in the PATH variable. The script issues remote Tivoli Workload Scheduler commands from the master to the FTA workstation, and errors might occur if the TWSuser .profile does not include the Tivoli Workload Scheduler path in the PATH variable. 4. Verify that all FTA workstations that will be patched are linked, active and have current Symphony file. FTA information is gathered from the Symphony file, this requires that the master be linked to the FTA workstation. The script may not be able to extract or validate information if they are not linked and have a current Symphony file. 5. Logon to the master workstation as root user. This is required, because gathering information and applying the fixpack must be executed as the root user. 6. Execute the autoinstall.sh script as the root user. The script will display message about location of temporary files and their extension, information about the master workstation, current master instance(s) that exist and ask that a master user name be provided to create the MDM definition directory for FTA workstations that it will manage. Refer to Figure 1.
Current system OS is HPUX The current process id is 18671, Temporary created files will be created in the /tmp directory and have a .18671 extension. No existing MDM definition file exists You will need to create a mdm definition file. This is a list of defined MDM users in the TWSRegistry.dat file for this workstation. m821a m83rtm Enter TWS User for master cpu or press enter to obtain a list of MDM users listed in the TWSRegistry.dat file -> Figure 1 MDM definition directory
7. Provide the Tivoli Workload Scheduler user for the MDM that will be used to manage FTA workstations that will be patched. The script will determine if the provided user is valid and display information about the provided user.
10
Enter TWS User for master cpu or press enter to obtain a list of
MDM users listed in the TWSRegistry.dat file -> m821a

Agent type for user m821a is MDM. m821a is a valid TWS user for a master cpu. TWSPATH for m821a user is: /tws/m821a TWS Master workstation m821a for TWS master user m821a on this workstation will be used to schedule installs. Will create MDM definition file for TWS user -> m821a on TWS master workstation -> m821a. /etc/TWS/MDM.m821a.m821a No existing APPL definition file exists Will need to create a APPL definition file. Will create the tws APPL definition directory /etc/TWS/APPL.tws Application tws will be used. The current process id is 18671, Temporary created files will be created in the /tmp directory and have a .18671 extension. Main Menu To patch a workstation enter (p). To access FTA or job and job stream utilities enter (u). To exit utility enter (e). Enter p, u or e -> Figure 2 Create TWS MDM and application definition directories
The application will create the directory MDM.masteruser.mastername which will serve as the repository for FTA.workstationname files that contain specific FTA information. It will also create the APPL.tws directory, if it does not exist. The APPL.tws directory will serve as the repository for utility scripts that will be sent to FTA workstations.
11
8. Reply to the prompt that asks the type of task to perform. Enter p to proceed to patch installation tasks. Refer to Figure 3. The following prompt, as shown in Figure 3, will appear asking you to provide a valid FTA to patch. Pressing <Enter> will list all workstations that exist in the Symphony file. Only UNIX FTA workstations may be patched.
Enter p, u or e -> p
Enter a valid FTA workstation name to patch. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->
Figure 3 FTA patch installation prompt
Pressing <Enter> will display all workstations that exist on the current master. Refer to Figure 4. Note: Only UNIX FTA workstations may be patched.
Enter a valid FTA workstation name to patch. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> <enter> Below is a list of valid FTAs for m821a master user:
M821A HORBLM82 M82A XA-FUEGO M821A HORBLM82 M82A M82A AF T A AT AFAT A AT 38211 31822 31822 31822 taos testmaster taos fuego.tivlab.austin.ibm.com
Figure 4 FTA Listing
9. Provide an FTA to patch. The script will determine if workstation is a UNIX FTA, and then gather some basic FTA workstation information from the Symphony file and display as shown in Figure 5.
12
Enter a valid FTA workstation name to patch. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> m82a Input value is M82A TWS workstation M82A on node/ip taos is a UNIX FT-AGENT ie.. an FTA. TWS workstation M82A on node taos is valid, will patch. Will determine if basic information for FTA m82a on master m821a exists. Will need to create information file for m82a: /etc/TWS/MDM.m821a.m821a/FTA.m82a since the above file does not exist. Additional information is required for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. -> Figure 5 Extracted FTA workstation information
10.Provide the TWSuser specified when the FTA was installed. The application will attempt to verify the specified user. If an SSH certificate file does not exist between the master and FTA, the user will be prompted for root password for the FTA workstation. Refer to Figure 6. Will try to validate TWS user m82a and that it manages TWS workstation m82a. You may need to provide root password for node/ip taos more than once. Password:
Figure 6 Validate TWS FTA user
If <Enter> is depressed, it will ask if you want to extract list of users on node/ip for FTA. Replying y will then prompt for root password for the node/ip of FTA. Refer to Figure 7.
13
Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. -> <enter> Do you want to extract list of TWS users on node/ip taos? (Enter y or n) ->
Figure 7 Prompt to extract Tivoli Workload Scheduler users for FTA workstation
Replying y to extract list of TWS users will then prompt for the password for the FTA workstation. A list of Tivoli Workload Scheduler users for instances on FTA will be displayed. Refer to Figure 8.
Do you want to extract list of TWS users on node/ip taos? (Enter y or n) -> y Will attempt to connect to node/ip taos and extract list of TWS users. You may need to provide root password for node/ip taos. Password: fta2nd83 fta83rtm m82a m82b mae001 The above is a list of TWS users for FTA workstations listed in the TWSRegistry.dat file on node/ip taos. You will need to specify the correct TWS user for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. ->
Figure 8 Extracted list of TWS users for FTA workstation
Provide TWSuser specified when the FTA was installed. The application will attempt to verify the specified user. If a SSH certificate file does not exist
14
between the master and FTA, the user will be prompted for root password for the FTA workstation. Refer to Figure 6. If the script is unable to validate the user, it will ask if you want to still use the specified user. Refer to Figure 9. This warning could be caused by: An invalid user FTA workstation this cpu field in the localopts file is incorrect Master workstation is unable to connect to FTA workstation Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. -> pete /localopts: No such file or directory The extracted value in the "thiscpu" field of localopts for user pete is: <empty> or localopts file does not exist. Warning: Unable to validate user. Enter y to use user pete or n to specify another user ->
Figure 9 Unable to validate TWS FTA user
Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, FTA localopts, and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 10.
15
The extracted value in the "thiscpu" field of localopts for user m82a is: m82a Logon user m82a exists. The TWS user m82a will be used for TWS workstation m82a. Will try to determine OS and current TWS version for FTA m82a. FTA m82a should be linked, this may take a few seconds. Extracted TWS version for m82a is 8.2 Will use TWS version 8.2.0. Extracted OS for m82a is HP-UX. OS HPUX will be used for m82a. Provide base path for patches for FTA m82a on taos on current TWS version. Path should start with slash / -> Figure 10 Validate user and prompt for fixpack base path
11.Provide the fixpack base path for FTA (see base path requirements shown in Example 6). Note: The base path provided must be valid, because it will be used to determine the fixpack directory path.
Example 6
Suggested naming convention. The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os). Example: Base path directory for AIX FTA currently on TWS 8.3 /images/patches/8.3.0/aix Where: patchesbasepath = /images/patches twsverison = is 8.3.0 (use 3 digit format) os = aix (aix, hpux,linux_i386 or solaris
16
/images/patches/8.2.0/hpux You may need to provide the root password for taos. Password:
Figure 11 Password prompt
12.Provide the root password for FTA; it may prompt for root password if an SSH certificate does not exist. Refer to Figure 11. Once the path has been validated it will ask if you want to use specified path. Refer to Figure 12. Path /images/patches/8.2.0/hpux exists Enter y, to use this path or enter n to specify another path. ->
Figure 12 Fixpack path validation and prompt
Once the base path has been confirmed, the FTA definition file will be created for the FTA. Refer to Figure 13. Enter y, to use this path or enter n to specify another path. -> y Base patch path /images/patches/8.2.0/hpux will be used for m82a User m82a, TWS current version 8.2.0, OS HPUX and base patch path /images/patches/8.2.0/hpux for FTA workstation m82a on node/IP taos basic information will be used for TWS FTA and will be added to: /etc/TWS/MDM.m821a.m821a/FTA.m82a Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02, 03 Enter TWS patch level->
Figure 13 FTA.ftaworkstation file creation and fixpack prompt
13.You must then provide the fixpack number to install. The fixpack must be a two digit number. The fixpack number will be verified that it exists locally on the FTA, and that it is the same or greater than what is currently installed on the FTA before proceeding. Refer to Figure 14.
17
Note: When fixpack path for fixpacks is created in the base patch path, it must be fp##, where fp text is in lowercase and ## is fixpack number in two digit format. Provide the two digit fixpack number when replying to fixpack prompt. Because each fixpack includes all fixes for previous fixpacks, entering multiple fixpacks for the same FTA workstation is not required.
Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02, 03 Enter TWS patch level of patch -> 10 Level entered is 10 10 TWS patch level 10 will be verified. Base patch path is /images/patches/8.2.0/hpux. Will verify that patch files exist in /images/patches/8.2.0/hpux/fp10 directory. You may need to provide root password for node/ip taos Password:
Figure 14 Fixpack verification
14.Provide the root password for FTA if an SSH certificate does not exist. Once the fixpack number has been entered it will determine if fixpack may be applied. The script will install fixpacks that are at same level or higher than current or the last fixpack applied to FTA workstation, or if FTA workstation has no previous fixpacks. It will ask if you want to use a specified fixpack if it meets the requirement. Refer to Figure 15.
18
You may need to provide root password for node/ip taos Password: Lasted installed version is 8.2.0, Lasted installed fixpack level is 10 Untarred patch files exist for patch 8.2.0-TIV-TWS-FP0010.TAR WARNING: Specified patch level to install is same level as currently installed on workstation. Do you want to use the specified information? (Enter y or n) ->
Figure 15 Fixpack installation confirmation
15.Reply to prompt asking if the specified fixpack number should be used. If the reply is n, you will need to provide another fixpack number. If it is y, a job definition will be created in the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. This file will contain the information required to install the specified fixpack on the FTA workstation. Refer to Figure 16. Do you want to use the specified information? (Enter y or n) -> y WARNING: Current specified patch file will be used Patch install job definition file patch_job_def will be created in the /etc/TWS/MDM.m821a.m821a directory.
FTA Patch Menu
Do you want to enter another FTA to patch? To patch another FTA enter (p) To go back to Main Menu enter (b) To exit utility enter (e) Enter p, b or e) ->
Figure 16 Apply fixpack to another FTA prompt
19
16.Reply to above prompt to provide information to apply the fixpack to another FTA workstation, go back to Main Menu, or exit the autoinstall.sh script. Refer to Figure 17. Temporary files generated by the script will be removed when exiting normally from the script. Enter p, b or e) -> e Will exit patch FTA mode. The current process id is 28525, removing all temporary files with .28525 extension in the /tmp directory. Exiting ./autoinstall.sh script.
Figure 17 Exit autoinstall.sh utility
Patching procedures- Subsequent executions

Executing the autoinstall.sh script later will bypass some of the initial operations and screens. If an MDM already exists it will display information for MDM and will ask if you want to use the existing MDM definition. Refer to Figure 18. Note: Using a different MDM definition is only possible if the current workstation has multiple master instances.
Current system OS is HPUX The current process id is 20511, Temporary created files will be created in the /tmp directory and have a .20511 extension. Found an existing MDM definition for m821a user on master cpu m821a on this workstation, ok to use? (Enter y or n) ->
Figure 18 Use existing MDM definition
1. Reply to the prompt with y to use the existing MDM definition. Replying n will prompt the user to provide information for the new MDM and will use the new MDM definition. Refer to Figure 19.
20
Found an existing MDM definition for m821a user on master cpu m821a on this workstation, ok to use? (Enter y or n) -> n You will need to create a mdm definition file. This is a list of defined MDM users in the TWSRegistry.dat file for this workstation. m821a m83rtm Enter TWS User for master cpu or press enter to obtain a list of MDM users listed in the TWSRegistry.dat file ->
Figure 19 Prompt for new MDM definition
Replying y will display a message stating that the existing MDM definition for the TWS user on the master workstation will be used. The script will ask the user if they want to use the APPL.tws application definition. Refer to Figure 20. Found an existing MDM definition for m821a user on master cpu m821a on this workstation, ok to use? (Enter y or n) -> y Existing TWS user m821a for master cpu m821a on this workstation will be used. This is a list of defined MDM users in the TWSRegistry.dat file for this workstation. m821a m83rtm drwxrwxr-x 2 root /etc/TWS/APPL.tws sys 96 Feb 20 16:15
Found the tws application definition on this workstation, ok to use? (Enter y or n) ->
Figure 20 Use APPL.tws definition prompt
2. Reply to the prompt asking to use the existing APPL.tws application.
21
Reply n to use or provide another APPL.xxxx definition. This requires that the autoinstall.sh utility script be modified to include user defined functions for the new application. You will need to provide the name for the application directory. The script will precede the name with APPL., when creating the definition directory. Refer to Create a new APPL.xxxx definition on page 33 for more details. Refer to Figure 21. Found the tws application definition on this workstation, ok to use? (Enter y or n) -> n You will need to create a APPL definition. Enter name for application ->
Figure 21 Create new APPL.xxxx definition prompt
After replying y to use the APPL.tws definition, the master workstation definition will be used for managing information of FTA workstations. 3. Reply p to proceed, providing information about the FTA workstation to patch. Refer to Figure 22. The utilities option is discussed later. Temporary files generated by the script will be removed when exiting normally from the script.
22
Found the tws application definition on this workstation, ok to use? (Enter y or n) -> y Application tws definition for master cpu m821a on this workstation will be used to schedule install. Application tws will be used. logout The current process id is 20511, Temporary created files will be created in the /tmp directory and have a .20511 extension. Main Menu To patch a workstation enter (p). To access FTA or job and job stream utilities enter (u). To exit utility enter (e). Enter p, u or e ->
Figure 22 Prompt for patch or utilities operations
The following prompt as shown in Figure 23 will appear, asking that you provide a valid FTA to patch. Depressing Enter will list all of the workstations that exist in the Symphony file. Only UNIX FTA workstations may be patched. Caution: Pressing <Enter> will display all defined workstations. The displayed list will scroll on the screen as they are displayed.
Enter p, u or e -> p Enter a valid FTA workstation name to patch. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->
Figure 23 FTA patch installation prompt
Pressing <Enter> will display all of the workstations that exist on the current master. Refer to Figure 24.
23
Note: Only UNIX FTA workstations may be patched.
Enter a valid FTA workstation name to patch. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> <enter> Below is a list of valid FTAs for m821a master user: M821A HORBLM82 M82A XA-FUEGO M821A HORBLM82 M82A M82A AF T A AT AFAT A AT 38211 31822 31822 31822 taos testmaster taos fuego.tivlab.austin.ibm.com
Figure 24 FTA Listing
4. Provide an FTA to patch. The script will determine if the workstation is a UNIX FTA then gather some basic FTA workstation information from the Symphony file and display. Refer to Figure 25.
24
Enter a valid FTA workstation name to patch. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> m82a Input value is M82A TWS workstation M82A on node/ip taos is a UNIX FT-AGENT ie.. an FTA. TWS workstation M82A on node taos is valid, will patch. Will determine if basic information for FTA m82a on master m821a exists. Will need to create information file for m82a: /etc/TWS/MDM.m821a.m821a/FTA.m82a since the above file does not exist. Additional information is required for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. ->
Figure 25 Extracted FTA workstation information
5. Provide the TWSuser specified when the FTA was installed, or press <Enter> to extract a list of users for TWS instances on FTA. The application will attempt to verify the specified user. If a SSH certificate file does not exist between the master and FTA user will be prompted for root password for FTA workstation. Refer to Figure 26.
25
Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. -> m82a Will try to validate TWS user m82a and that it manages TWS workstation m82a. You may need to provide root password for node/ip taos more than once. Password:
Figure 26 Validate TWS FTA user
If <Enter> is depressed it will prompt whether you want to extract list of users on node/ip for FTA. Replying y will then prompt of root password for node/ip of FTA. Refer to Figure 27.
Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. -> enter Do you want to extract list of TWS users on node/ip taos? (Enter y or n) ->
Figure 27 Prompt to extract TWS users for FTA workstation
Replying y to extract list of TWS users will then prompt for password for the FTA workstation. A list of TWS users for instances on FTA will be displayed. Refer to Figure 28.
26
Do you want to extract list of TWS users on node/ip taos? (Enter y or n) -> y Will attempt to connect to node/ip taos and extract list of TWS users. You may need to provide root password for node/ip taos. Password: fta2nd83 fta83rtm m82a m82b mae001 The above is a list of TWS users for FTA workstations listed in the TWSRegistry.dat file on node/ip taos. You will need to specify the correct TWS user for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. ->
Figure 28 Extracted list of TWS users for FTA workstation
Provide TWSuser specified when the FTA was installed. The application will attempt to verify the specified user. If a SSH certificate file does not exist between the master and FTA, the user will be prompted for root password for the FTA workstation. Refer to Figure 26. If the script is unable to validate the user, it will ask if you want to still use the specified user. Refer to Figure 29. This warning could be caused by: An invalid user FTA workstation this cpu field in the localopts file is incorrect Master workstation is unable to connect to FTA workstation
27
Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. -> test Warning: Unable to validate user. Enter y to use user test or n to specify another user ->
Figure 29 Unable to validate TWS FTA user
Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, from the FTA localopts and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 30. The extracted value in the "thiscpu" field of localopts for user m82a is: m82a Logon user m82a exists. The TWS user m82a will be used for TWS workstation m82a. Will try to determine OS and current TWS version for FTA m82a. FTA m82a should be linked, this may take a few seconds. Extracted TWS version for m82a is 8.2 Will use TWS version 8.2.0. Extracted OS for m82a is HP-UX. OS HPUX will be used for m82a. Provide base path for patches for FTA m82a on taos on current TWS version. Path should start with slash / ->
Figure 30 Validate user and prompt for fixpack base path Example 7 Fixpack base path requirements
The following naming convention. The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os). Example: Base path directory for AIX FTA currently on TWS 8.3
28
/images/patches/8.3.0/aix Where: patchesbasepath = /images/patches twsverison = is 8.3.0 (use 3 digit format) os = aix (aix, hpux,linux_i386 or solaris) 6. Provide the fixpack base path for FTA (see base path requirements in Example 7). Provide base path for patches for FTA m82a on taos on current TWS version. Path should start with slash / -> /images/patches/8.2.0/hpux You may need to provide the root password for taos. Password:
7. Provide the root password for FTA; it may prompt for root password if an SSH certificate does not exist. Refer to Figure 31. Once the path has been validated it will ask if you want to use the specified path. Refer to Figure 32. You may need to provide the root password for taos. Password: Path /images/patches/8.2.0/hpux exists Enter y, to use this path or enter n to specify another path. ->
Once the base path has been confirmed, the FTA definition file will be created for the FTA. Refer to Figure 33.
29
Enter y, to use this path or enter n to specify another path. -> y Base patch path /images/patches/8.2.0/hpux will be used for m82a User m82a, TWS current version 8.2.0, OS HPUX and base patch path /images/patches/8.2.0/hpux for FTA workstation m82a on node/IP taos basic information will be used for TWS FTA and will be added to: /etc/TWS/MDM.m821a.m821a/FTA.m82a Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02, 03 Enter TWS patch level ->
Figure 33 FTA.ftaworkstation file creation and fixpack prompt
8. You must then provide the fixpack number to install. The fixpack must be in a two digit number. The fixpack number will be verified that it exists locally on the FTA, and that it is the same or greater than what is currently installed on the FTA before proceeding. Refer to Figure 34. Note: When the fixpack path for fixpacks is created in the base patch path, it must be fp##, where fp text is in lowercase and ## is fixpack number in two digit format. Provide the two digit fixpack number when replying to the fixpack prompt. Because each fixpack includes all fixes for previous fixpacks, entering multiple fixpacks for the same FTA workstation is not required.
30
Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02, 03 Enter TWS patch level -> 10 Level entered is 10 10 TWS patch level 10 will be verified. Base patch path is /images/patches/8.2.0/hpux. Will verify that patch files exist in /images/patches/8.2.0/hpux/fp10 directory. You may need to provide root password for node/ip taos Password:
Figure 34 Fixpack to apply and password prompt
9. Provide the root password for FTA if an SSH certificate does not exist. Once the fixpack number has been entered it will determine if the fixpack may be applied. The script will install fixpacks that are at same level or higher than current or last fixpack applied to FTA workstation or if FTA workstation has no previous fixpacks. It will ask if you want to use specified fixpack if it meets the requirement. Refer to Figure 35. Base patch path is /images/patches/8.2.0/hpux. Will verify that patch files exist in /images/patches/8.2.0/hpux/fp10 directory. You may need to provide root password for node/ip taos Password: Lasted installed version is 8.2.0, Lasted installed fixpack level is 10 Untarred patch files exist for patch 8.2.0-TIV-TWS-FP0010.TAR WARNING: Specified patch level to install is same level as currently installed on workstation. Do you want to use the specified information? (Enter y or n) ->
Figure 35 Fixpack installation confirmation
31
10.Reply to the prompt asking if the specified fixpack number should be used. If the reply is n you will need to provide another fixpack number. If the reply is y a job definition will be created in the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. This file will contain the information required to install the specified fixpack on the FTA workstation. Refer to Figure 36. Do you want to use the specified information? (Enter y or n) -> y WARNING: Current specified patch file will be used Patch install job definition file patch_job_def will be created in the /etc/TWS/MDM.m821a.m821a directory. FTA Patch Menu Do you want to enter another FTA to patch? To patch another FTA enter (p) To go back to Main Menu enter (b) To exit utility enter (e) Enter p, b or e) ->
Figure 36 Apply fixpack to another FTA prompt
11.Reply to the prompt to provide information to apply the fixpack to another FTA workstation or to exit the autoinstall.sh script. Temporary files generated by the script will be removed when exiting normally from the script. Refer to Figure 37. Enter p, b or e) -> e Will exit patch FTA mode. The current process id is 28525, removing all temporary files with .28525 extension in the /tmp directory. Exiting ./autoinstall.sh script.
Figure 37 Exit autoinstall.sh script
32
Create a new APPL.xxxx definition

The autoinstall.sh utility script may be used to patch or install any application that uses a UNIX command line installation. The script will require that additional functions/modules be added to support this functionality. It will be the users responsibility to edit and support the new functions. TWS level 2 support will not support these changes. Contact IBM Services to provide this service. The APPL.xxxx definition is part of a MDM definition, because the master for the MDM is used to schedule the patch or installation of the APPL.xxx application. To define a new APPL.xxxx definition execute the autoinstall.sh utility script. A prompt will ask you if you want to use an existing MDM definition. 1. Reply y to the prompt asking to use the existing MDM definition. Refer to Figure 38. Current system OS is HPUX
The current process id is 18671, Temporary created files will be created in the /tmp directory and have a .18671 extension.
Found an existing MDM definition for m821a user on master cpu m821a on this workstation, ok to use? (Enter y or n) ->
2. Reply n to the prompt asking to use the APPL.tws application definition. Refer to Figure 39.
33
Found an existing MDM definition for m821a user on master cpu m821a on this workstation, ok to use? (Enter y or n) -> y Existing TWS user m821a for master cpu m821a on this workstation will be used. This is a list of defined MDM users in the TWSRegistry.dat file for this workstation. m821a m83rtm drwxrwxr-x 2 root /etc/TWS/APPL.tws sys 96 Feb 20 16:15
3. Provide the name for the new APPL.xxxx definition directory. The script will precede the name with APPL. prefix when creating the definition directory. Refer to Figure 40. Found the tws application definition on this workstation, ok to use? (Enter y or n) -> n You will need to create a APPL definition. Enter name for application ->
Figure 40 New APPL.xxxx definition directory prompt
After entering the name for the new APPL.xxxx definition you will be asked if you want to use the provided name. 4. Reply y to use this name or n to re-enter a new name. Refer to Figure 41.
34
Enter name for application -> test You specified test definition is this correct. (y or n) ->
Figure 41 Confirm new APPL.xxxx definition directory
5. Reply y to the prompt to use the new APPL.xxxx definition; the script will attempt to access the new functions or modules that should have been added to the autoinstall.sh script. If the script has not be edited for this, then it will exit after creating the new APPL.xxxx definition and displaying current the APPL.xxxx definition directories. Refer to Figure 42. You specified test definition is this correct. (y or n) -> y APPL.test directory will be created on this workstation and will be available for future installs Will create APPL definition directory test on m821a /etc/TWS/APPL.test /etc/TWS/APPL.tws Application test will be used. Application install is not TWS. The current process id is 12365, removing all temporary files with .12365 extension in the /tmp directory. Exiting ./autoinstall.sh script.
Figure 42 Creation of new APPL.xxxx definition
Utilities Operations
The utilities operations consist of FTA, or job and jobs stream, utility tasks. The FTA utilities are for FTA maintenance operations used to add, update, or delete an FTA.workstation file or to export fixpack installation utility scripts from the master to the FTA workstation.
35
The job and job stream utilities include a task that creates the job streams for fixpack installation jobs, a task to add job and job stream definitions to the TWS jobs and job stream database, or a task to rename the patch_job_def job definition file. The renamed patch_job_def file will have an extension of _mmddyy_hhmmss, where mmddyy is the month, day, and year, and hhmmss is hour, minute, and second.
Utilities - FTA Utilities

FTA maintenance will be performed from the FTA Utilities Menu. You will need to proceed past some of the general menus or prompts to get to the FTA Utilities Menu. If an MDM already exists it will display information for MDM and ask if you want to use the existing MDM definition. Refer to Figure 43. Note: Using a different MDM definition is only possible if the current workstation has multiple master instances.
1. Reply to prompt with y to use existing MDM definition. Replying y will display a message stating that existing MDM definition for TWS user on the master workstation will be used. The script will ask the user if they want to use the APPL.tws application definition. Refer to Figure 44.
36
Found an existing MDM definition for m821a user on master cpu m821a on this workstation, ok to use? (Enter y or n) -> y Existing TWS user m821a for master cpu m821a on this workstation will be used. This is a list of defined MDM users in the TWSRegistry.dat file for this workstation. m821a m83rtm drwxrwxr-x 2 root /etc/TWS/APPL.tws sys 96 Feb 20 16:15
2. Reply y to the prompt asking to use the existing APPL.tws application. Refer to Figure 45. After replying y to use the APPL.tws definition, the master workstation definition will be used for managing information of FTA workstations.
37
3. Reply u to proceed to the Main Utilities Menu. Refer to Figure 46. Enter p, u or e -> u Main Utilities Menu To access FTA utilities enter (f). To access job and job stream utilities enter (j). To go back to Main Menu enter (b). To exit utility enter (e). Enter f, j, b or e ->
Figure 46 FTA utilities menus
4. For FTA maintenance tasks, reply f to perform FTA maintenance tasks.
38
Enter f, j, b or e -> f FTA Utilities Menu To add or update an FTA file enter (a). To delete an FTA file enter (d). To export the utility scripts to an FTA enter (x). To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter a, d, x, b or e ->
Figure 47 FTA utilities menu
Proceed to one of these sections: Add or Update an FTA File on page 39 Delete an FTA file on page 51 Export Utility Scripts to FTA on page 53 Refer to Figure 47.
Add or Update an FTA File

i. At the FTA Utilities Menu screen, reply a to add or update an FTA definition file. Refer to Figure 48. Enter a, d, x, b or e -> a FTA to be added or updated must be exist in current Symphony file and linked before executing utility. Press enter l to get a list of FTA files that may be updated or any other key to bypass list. ->
Figure 48 List FTA definition prompt
Entering l will display a list of current FTA definitions that already exist in the MDM.mastername.mastername definition directory. This option should be selected it you want to see existing FTA.workstation definition files.
39
Pressing any other key will bypass this operation. ii. Press either l or any key to continue. Refer to Figure 49. Press enter l to get a list of FTA files that may be updated or any other key to bypass list. -> l Below is a list of current FTA files managed by Master cpu m821a. MDM.m821a.m821a/FTA.m82a This is the FTA add or update module. Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->
Figure 49 Existing FTA.workstation list and FTA name to add or update prompt
The script will then prompt for FTA name to add or update; pressing <Enter> will display a list of workstations that exist in the current master Symphony file. Refer to Figure 50. Caution: Pressing <Enter> will display all defined Workstations. The displayed list will scroll on the screen as they are displayed.
Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu.-> <enter> Below is a list of valid FTA's for m821a master user.
Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->
Figure 50 Workstation list from the master Symphony file
40
iii. Reply to prompt with FTA name. If FTA name exists as an FTA.workstation definition file it will update the existing file. If the file FTA.workstation definition file does not exist it will prompt for FTA specific information to add a new FTA definition. Proceed to one of these sections: Add New FTA Definition on page 41, or Update an Existing FTA.workstation File on page 46.
Add New FTA Definition

Press <Enter> to display a current list of workstations in the master Symphony file. Note: The FTA must exist in the Symphony file to be linked to the master, to extract the required information for the FTA.workstation file. iv. Enter the name of the UNIX FTA workstation that exists in the masters Symphony file. The script will extract specific information to generate the FTA.workstation file if FTA exists in the masters Symphony file and is a UNIX FTA. It will display the following and ask for the TWS user that was specified when FTA was installed. Refer to Figure 51.
41
Input value is HORBLM82. TWS workstation HORBLM82 on node/ip testmaster is a UNIX FT-AGENT ie.. an FTA. TWS workstation HORBLM82 on node testmaster is valid, will add or update. Will determine if basic information for FTA horblm82 on master m821a exists. Will need to create information file for horblm82: /etc/TWS/MDM.m821a.m821a/FTA.horblm82 since the above file does not exist. Additional information is required for TWS workstation horblm82. Enter the TWS user for workstation horblm82 (node/ip testmaster) or press enter to obtain list of TWS users on node/ip testmaster. ->
Figure 51 FTA verification and TWS user prompt
v. You may provide the TWSuser for the FTA specified or press <Enter> to obtain a list of Tivoli Workload Scheduler instance users that exist on the FTA workstation. The list of Tivoli Workload Scheduler instance users is extracted from the TWSRegistry.dat file. Pressing <Enter> to produce a list of users for Tivoli Workload Scheduler instances that exist on the FTA workstation may require the root password if an SSH certificate does not exist on FTA. Refer to Figure 52. Note: The user list displayed, will consist of users for all Tivoli Workload Scheduler instances that exist, if multiple Tivoli Workload Scheduler instances exist on the FTA node. You must use the Tivoli Workload Scheduler user for the FTA that was specified in the previous step.
42
Enter the TWS user for workstation horblm82 (node/ip testmaster) or press enter to obtain list of TWS users on node/ip testmaster. -> <enter> Do you want to extract list of TWS users on node/ip testmaster? (Enter y or n) -> y Will attempt to connect to node/ip testmaster and extract list of TWS users. You may need to provide root password for node/ip testmaster. Password: e82pdm f821 The above is a list of TWS users for FTA workstations listed in the TWSRegistry.dat file on node/ip testmaster. You will need to specify the correct TWS user for TWS workstation horblm82. Enter the TWS user for workstation horblm82 (node/ip testmaster) or press enter to obtain list of TWS users on node/ip testmaster. ->
Figure 52 List of FTA node TWS instance users
Provide the Tivoli Workload Scheduler user for the specified FTA; you may be prompted for the root password for the FTA node. Refer to Figure 53. Enter the TWS user for workstation horblm82 (node/ip testmaster) or press enter to obtain list of TWS users on node/ip testmaster. -> e82pdm Will try to validate TWS user e82pdm and that it manages TWS workstation horblm82. You may need to provide root password for node/ip testmaster more than once. Password:
Figure 53 FTA TWS user prompt and root password prompt
43
vi. Enter root password of the FTA node. Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, from the FTA localopts, and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 54. Logon user e82pdm exists. The TWS user e82pdm will be used for TWS workstation horblm82. Will try to determine OS and current TWS version for FTA horblm82. FTA horblm82 should be linked, this may take a few seconds. Extracted TWS version for horblm82 is 8.2 Will use TWS version 8.2.0. Extracted OS for horblm82 is HP-UX. OS HPUX will be used for horblm82. Provide base path for patches for FTA horblm82 on testmaster on current TWS version. Path should start with slash / ->
Figure 54 Validate user and prompt for fixpack base path Example 8 Fixpack base path requirements
The following naming convention. The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os). Example: Base path directory for AIX FTA currently on TWS 8.3 /images/patches/8.3.0/aix Where: patchesbasepath = /images/patches twsverison = is 8.3.0 (use 3 digit format) os = aix (aix, hpux,linux_i386 or solaris) vii. Provide the fixpack base path for FTA (see base path requirements in Example 8).
44
Provide base path for patches for FTA horblm82 on testmaster on current TWS version. Path should start with slash / -> /images/patches/8.2.0/hpux You may need to provide the root password for taos. Password:
Note: When the fixpack path for fixpacks is created in the base patch path, it must be fp##, where fp text is in lowercase and ## is fixpack number in two digit format. Provide the two digit fixpack number when replying to the fixpack prompt. Because each fixpack includes all fixes for previous fixpacks, entering multiple fixpacks for the same FTA workstation is not required.
viii.Provide the root password for FTA; it may prompt for root password if an SSH certificate does not exist. Once the path has been validated it will ask if you want to use the specified path. Refer to Figure 56. You may need to provide the root password for taos. Password: Path /images/patches/8.2.0/hpux exists Enter y, to use this path or enter n to specify another path. ->
ix. Reply y to use the specified path. Once the base path has been confirmed, the FTA definition file will be created for the FTA. The script will ask to add or update another FTA or to exit the utility. Refer to Figure 57.
45
Enter y, to use this path or enter n to specify another path. -> y The extracted value in the "thiscpu" field of localopts for user e82pdm is: horblm82 User e82pdm, TWS current version 8.2.0, OS HPUX and base patch path /images/patches/8.2.0/hpux for FTA workstation horblm82 on node/IP testmaster basic information will be used for TWS FTA and will be added to: /etc/TWS/MDM.m821a.m821a/FTA.horblm82 Do you want to add or update another FTA? To add or update another FTA enter (a) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) Enter a, b or e to exit ->
Figure 57 Create FTA.workstation file
x. Reply to prompt; a will prompt FTA to add or update, b will return to the FTA Utilities Menu, and e will exit the utility script. Temporary files generated by the script will be removed when exiting the script. Refer to Figure 58. Enter a, b or e to exit -> e The current process id is 28800, removing all temporary files with .28800 extension in the /tmp directory. Exiting ./autoinstall.sh script.
Figure 58 Exit script
Update an Existing FTA.workstation File

Press <Enter> to display a current list of workstations in the master Symphony file.
46
Note: The FTA must exist in the Symphony file to be linked to the master, to extract and update the required information for the FTA.workstation file. i. Enter the name of the UNIX FTA workstation, to update. The FTA must exist in the masters Symphony file. The script will extract specific information to update the FTA.workstation file. It will display existing information and ask if you want to use this information. Refer to Figure 59. Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> m82a Input value is M82A. TWS workstation M82A on node/ip taos is a UNIX FT-AGENT ie.. an FTA. TWS workstation M82A on node taos is valid, will add or update. Will determine if basic information for FTA m82a on master m821a exists. Information for m82a exists in file /etc/TWS/MDM.m821a.m821a/FTA.m82a Basic information for FTA m82a: CPUNAME=m82a NODENAME_IP=taos TWSUSER=m82a VERSION=8.2.0 OS=HPUX BASEPATCHPATH=/images/patches/8.2.0/hpux Do you want to use above information? (Enter y or n) ->
Figure 59 Display existing FTA.workstation definition file information
ii. Reply n to proceed. You will be prompted to provide the Tivoli Workload Scheduler user for the FTA workstation. Refer to Figure 60.
47
Do you want to use above information? (Enter y or n) -> n You will need to create an updated information file for TWS workstation m82a. Additional information is required for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. ->
Figure 60 Provide Tivoli Workload Scheduler user for FTA.workstation prompt
iii. Provide the Tivoli Workload Scheduler user for the FTA workstation. Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, from the FTA localopts, and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 61.
48
Enter the TWS user for workstation m82a (node/ip taos) or press enter to obtain list of TWS users on node/ip taos. -> m82a Will try to validate TWS user m82a and that it manages TWS workstation m82a. You may need to provide root password for node/ip taos more than once. Password: The extracted value in the "thiscpu" field of localopts for user m82a is: m82a Logon user m82a exists. The TWS user m82a will be used for TWS workstation m82a. Will try to determine OS and current TWS version for FTA m82a. FTA m82a should be linked, this may take a few seconds. Extracted TWS version for m82a is 8.2 Will use TWS version 8.2.0. Extracted OS for m82a is HP-UX. OS HPUX will be used for m82a. Provide base path for patches for FTA m82a on taos on current TWS version. Path should start with slash / ->
Figure 61 Validate user and prompt for fixpack base path
iv. Provide the fixpack base path for FTA (see base path requirements in Example 9).
Example 9 Fixpack base path requirements
The following naming convention. The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os). Example: Base path directory for AIX FTA currently on TWS 8.3 /images/patches/8.3.0/aix
49
Where: patchesbasepath = /images/patches twsverison = is 8.3.0 (use 3 digit format) os = aix (aix, hpux,linux_i386 or solaris)
Provide base path for patches for FTA m82a on taos on current TWS version. Path should start with slash / -> /images/patches/8.2.0/hpux You may need to provide the root password for taos. Password:
Note: When the fixpack path for fixpacks is created in the base patch path, it must be fp##, where fp text is in lowercase and ## is fixpack number in two digit format. Provide the two digit fixpack number when replying to the fixpack prompt. v. Provide the root password for FTA, it may prompt for root password if an SSH certificate does not exist. Refer to Figure 62. Once the path has been validated it will ask if you want to use specified path. Refer to Figure 63. Path /images/patches/8.2.0/hpux exists Enter y, to use this path or enter n to specify another path. ->
Once the base path has been confirmed, the FTA definition file for the FTA will be updated. The script will ask to add or update another FTA, go back to FTA Utilities Menu, or to exit the utility. Refer to Figure 64.
50
Enter y, to use this path or enter n to specify another path. -> y Base patch path /images/patches/8.2.0/hpux will be used for m82a User m82a, TWS current version 8.2.0, OS HPUX and base patch path /images/patches/8.2.0/hpux for FTA workstation m82a on node/IP taos basic information will be used for TWS FTA and will be added to: /etc/TWS/MDM.m821a.m821a/FTA.m82a Do you want to add or update another FTA? To add or update another FTA enter (a) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) Enter a, b or e to exit ->
Figure 64 Update FTA.workstation file
vi. Reply to the prompt; y will prompt FTA to add or update, b will return to FTA Utilities Menu, and e will exit the utility script. Temporary files generated by the script will be removed when exiting the script. Refer to Figure 65. Enter a, b or e to exit -> e The current process id is 28800, removing all temporary files with .28800 extension in the /tmp directory. Exiting ./autoinstall.sh script.
Figure 65 Exit script
Delete an FTA file

i. At the FTA Utilities Menu screen, enter d to delete an FTA.workstation file. Refer to Figure 66.
51
FTA Utilities Menu To add or update an FTA file enter (a). To delete an FTA file enter (d). To export the utility scripts to an FTA enter (x). To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter a, d, x, b or e -> d Enter name of FTA file (do not use *) to delete, press enter to get a list of FTA files or e to exit utility. ->
Figure 66 FTA Utilities menu
ii. Press <Enter> to get a list of the defined FTA.workstation files. Refer to Figure 67. Enter name of FTA file to delete, press enter to get a list of FTA files or e to exit utility. -> <enter> /etc/TWS/MDM.m821a.m821a/FTA.horblm82 /etc/TWS/MDM.m821a.m821a/FTA.m82a Enter name of FTA file to delete, press enter to get a list of FTA files or e to exit utility. ->
Figure 67 List of defined FTA.workstation definition files.
iii. Enter the name of the FTA to delete; there is no need to precede ftaname with FTA. text. Refer to Figure 68. Enter name of FTA file (do not use *) to delete, press enter to get a list of FTA files or e to exit utility. -> horblm82 Do you want to delete the FTA file? (Enter y, n or e to exit) ->
Figure 68 FTA name to delete
52
Note: Do not use * asterisk in the FTA name. iv. Reply y to delete the file; the script will remove FTA.workstation file. Next the prompt will ask to delete another FTA, return to the FTA Utilities Menu, or exit the utility. Refer to Figure 69. Do you want to delete the FTA file? (Enter y, n or e to exit) -> y File /etc/TWS/MDM.m821a.m821a/FTA.horblm82 exists and will be removed. Do you want to delete another FTA? To delete another FTA enter (d) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) (Enter d, b or e to exit) ->
Figure 69 FTA delete confirmation
v. Reply to the prompt.
Export Utility Scripts to FTA

i. At the FTA Utilities Menu screen, enter x to export the utility scripts to FTA. Refer to Figure 70.
53
FTA Utilities Menu To add or update an FTA file enter (a). To delete an FTA file enter (d). To export the utility scripts to an FTA enter (x). To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter a, d, x or e -> x This is the FTA export util scripts module. Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->
Figure 70 Export utilities FTA workstation prompt
ii. Enter the name of the FTA to receive the utility scripts (do not enter the node/ip), or press <Enter> to view a list of FTA workstations. Refer to Figure 70. Note: Use the FTA workstation name not the node/ip for workstation. Utility scripts may be sent to an FTA prior to creating the FTA.workstation file. The export uses UNIX scp, providing the root password for the FTA workstation, which may be required if an SSH certificate does not exist. Pressing <Enter> will display list of all workstations that exist on the current masters Symphony file. Refer to Figure 71.
54
Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> <enter> Below is a list of workstations for m821a master user.
Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->
Figure 71 List of workstations on the current master Symphony file
The script will verify that the provided name is an FTA workstation. Refer to Figure 72. Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> xa-fuego Input value is XA-FUEGO. TWS workstation XA-FUEGO on node/ip fuego.tivlab.austin.ibm.com is an UNIX X-AGENT, NOT a UNIX FTA. This utility may only patch UNIX FTA's. Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->
Figure 72 Invalid agent type for workstation specified
iii. Provide the name for a UNIX FTA workstation. After confirming that the provided name is for a UNIX FTA, the script will prompt for root password for FTA node/ip, if an SSH certificate does not exist. Refer to Figure 73.
55
Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> m82a Input value is M82A. TWS workstation M82A on node/ip taos is a UNIX FT-AGENT ie.. an FTA. TWS workstation M82A on node taos is valid, will receive utility scripts. You may need to provide root password for node/ip taos more that once. Will attempt to transfer files to FTA m82a on node/ip taos. Password:
Figure 73 Confirmed FTA workstation, prompt for root password
iv. Provide root password for the FTA node/ip. You may need to provide the password twice. Review the transfer messages to verify that they completed successfully. Refer to Figure 74.
56
Will attempt to transfer files to FTA m82a on node/ip taos. Password:

patch_lau.sh Password: patch_install.sh 100% 6243 100% 19KB 0.0KB/s 0.0KB/s 00:00 00:00
Review the above scp messages and verify that secure copies were successful before proceeding. Do you want to export utility scripts to another FTA? To export utility scripts to another FTA enter (x) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) Enter x, b or e to exit ->
Figure 74 Utility script transfer confirmation
v. Reply to the prompt to continue or to exit.
Job Stream Utilities

Specific steps are required after creating the job definitions for the fixpacks and must be performed in a specific order. You must create the job stream definitions files, add the job and job stream definitions and finally rename the patch_job_def file. The renamed patch_job_def file will have an extension of _mmddyy_hhmmss, where mmddyy is the month, day, and year, and hhmmss is hour, minute, and second. These maintenance operations may be performed from the Job Stream Utilities Menu. You will need proceed past some of the general menus or prompts to get to the Job Stream Utilities Menu. If an MDM already exists it will display information for MDM and ask if you want to use the existing MDM definition. 1. Reply to the prompt with y to use the existing MDM definition. Refer to Figure 75.
57
Replying y will display a message stating that the existing MDM definition for the Tivoli Workload Scheduler user on the master workstation will be used. The script will ask the user if they want to use the APPL.tws application definition. 2. Reply y to the prompt asking to use existing APPL.tws application, as shown Figure 76. Found an existing MDM definition for m821a user on master cpu m821a on this workstation, ok to use? (Enter y or n) -> y Existing TWS user m821a for master cpu m821a on this workstation will be used. This is a list of defined MDM users in the TWSRegistry.dat file for this workstation. m821a m83rtm drwxrwxr-x 2 root /etc/TWS/APPL.tws sys 96 Feb 20 16:15
Figure 76 Use existing APPL.tws definition prompt
After replying y to use the APPL.tws definition, the master workstation definition will be used for managing information of FTA workstations. The Main Menu will then be displayed. Refer to Figure 77.
58
3. Reply u to proceed to the Main Utilities Menu. Refer to Figure 77.
59
Enter p to patch a workstation, u for utilities to create patch job streams, add jobs and job streams to database or e to exit utility. (Enter p, u or e) -> u Main Utilities Menu To access FTA utilities enter (f). To access job and job stream utilities enter (j). To go back to Main Menu enter (b). To exit utility enter (e). Enter f, j, b or e -> j
Figure 78 FTA utilities menus
You will need to access the job and job stream utilities tasks. 4. Reply j to access job and job stream utilities tasks. Refer to Figure 78. The script will ask if you want to create job stream information or add job and job stream definitions to the database. Refer to Figure 79. Enter f, j, b or e -> j Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream definitions to the database enter (a). To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b).
To exit utility enter (e). Enter c, a, r, b or e ->

Figure 79 Job and Job Stream Utilities Menu
60
Create Job Stream Definition Files

At the Job and Job Stream Utilities Menu, enter c to create job stream definitions. Refer to Figure 80. The script will create the patch_lau_sch_def and patch_succ_sch_def files in the /etc/TWS/MDM.masteruser.mastername directory. Refer to Figure 80. These files will contain the definitions for the TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams. These definitions will run on the master once added to the Tivoli Workload Scheduler database. Unique job definitions created by the autoinstall.sh that exist in the etc/TWS/MDM.masteruser.mastername/patch_job_def file will be added to the TWSPATCH_LAUNCH job stream. Note: Multiple job definitions with the exact same name that exists in the patch_job_def file will exist only once in the TWSPATCH_LAUNCH job stream. This operation may be performed multiple times, because each execution will create the job stream definition files overwriting the previous files. The job stream definitions files patch_lau_sch_def and patch_succ_sch_def will be created in the etc/TWS/MDM.masteruser.mastername directory.
61
Enter c, a, r, b or e -> c The patch_succ_sch_def file in the /etc/TWS/MDM.m821a.m821a directory will have the TWSPATCH_SUCC job stream definition. 1 unique TWS patch install job definition(s) have been extracted from the patch_job_def file in the /etc/TWS/MDM.m821a.m821a directory to create the patch_lau_sch_def file. The patch_lau_sch_def file in the /etc/TWS/MDM.m821a.m821a directory will have the TWSPATCH_LAUNCH job stream definition. Review the file and verify the patch install jobs for the FTA's before adding definitions to database. Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream definitions to the database enter (a). To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter c, a, r, b or e ->
Figure 80 Job stream files creation
Add Job and Job Stream definitions to Tivoli Workload Scheduler database
When ready, proceed to adding the final job stream definitions and initiate the add procedure. At the Job and Job Stream Utilities Menu, enter a to add job and job stream definition files to the Tivoli Workload Scheduler database. Refer to Figure . Attention: Adding the job stream definitions to the Tivoli Workload Scheduler database will replace the existing job stream definition for TWSPATCH_LAUNCH and TWSPATCH_SUCC.
62
Enter c, a, r, b or e -> a Will add the following definition files to database: /etc/TWS/MDM.m821a.m821a/patch_job_def /etc/TWS/MDM.m821a.m821a/patch_lau_sch_def /etc/TWS/MDM.m821a.m821a/patch_succ_sch_def TWS for UNIX (HPUX)/COMPOSER 8.2.1 (1.18.2.21) Licensed Materials Property of IBM 5698-WKB (C) Copyright IBM Corp 1998, 2005 US Government User Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Installed for user 'm821a'. Locale LANG set to "C" -replace /etc/TWS/MDM.m821a.m821a/patch_job_def AWSBIA090E Total errors in /etc/TWS/MDM.m821a.m821a/patch_job_def: 0, warnings 0. -replace /etc/TWS/MDM.m821a.m821a/patch_lau_sch_def AWSBIA019E For M821A#TWSPATCH_LAUNCH Errors 0, warnings 0. AWSBIA016I Schedule M821A#TWSPATCH_LAUNCH replaced. AWSBIA090E Total errors in /tws/m821a/tmp/TWSEAAa22415: 0, warnings 0. -replace /etc/TWS/MDM.m821a.m821a/patch_succ_sch_def AWSBIA019E For M821A#TWSPATCH_SUCC Errors 0, warnings 0. AWSBIA016I Schedule M821A#TWSPATCH_SUCC replaced. AWSBIA090E Total errors in /tws/m821a/tmp/TWSHAAa22415: 0, warnings 0. Verify that there were no errors in the above messages when definitions were added to the database. Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream definitions to the database enter (a). To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter c, a, r, b or e ->
Figure 81 Add job and job stream definitions to TWS database
63
Rename patch_job_def file

After the job and job stream files have been added to the Tivoli Workload Scheduler database, renaming the patch_job_def is required for future fixpack autoinstall.sh script runs. At the Job and Job Stream Utilities Menu, enter r to rename the patch_job_def. Refer to Figure 82. The renamed patch_job_def file will have an extension of _mmddyy_hhmmss, where mmddyy is the month, day, and year, and hhmmss is hour, minute, and second. The file will be renamed and ready for the future execution of the autoinstall.sh script for FTA fixpack installations. Important: The autoinstall.sh script must not be used to create and add new job and job stream definitions until the current job stream with fixpacks installation jobs have been submitted and launched.
64
Enter c, a, r, b or e -> r Will check for existence of patch_job_def_file in the /etc/TWS/MDM.m821a.m821a directory. File patch_job_def_file exists in the /etc/TWS/MDM.m821a.m821a directory and will be renamed to include extension with current date and time in hour, minute and seconds. + mv /etc/TWS/MDM.m821a.m821a/patch_job_def /etc/TWS/MDM.m821a.m821a/patch_job_def_051507_183939
Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream defintions to the database enter (a). To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter c, a, r, b or e ->
Figure 82 Delete patch_job_def file
Implementing procedures
The fixpack implementation cycle consists of: Specifying FTA(s) that need a fixpack Submitting and launching of the fixpack launch job Installation of the fixpack on spcified FTA workstations New FTA fixpack definitions (new fixpack cycle) may be added once the job and jobs stream definitions from the current fixpack cycle have been added to the
65
Tivoli Workload Scheduler database and the patch_job_def file has been renamed. The existing fixpack cycle includes submitting the job stream that includes the fixpack installation jobs and the launching of the fixpack installation jobs. Important: Because fixpack cycles can overlap, great care must be taken to make sure that definitions are not overwritten by the next fixpack cycle. The autoinstall.sh fixpack utility script may be located in any directory. The file should be owned by root and must have execute permissions. Temporary files will be created in the /tmp directory. The temporary files generated by the script will have a .##### extension, where ##### is the process ID. All temporary created files will be removed when exiting the script normally. The following procedures must be performed to install an FTA fixpack: 1. Verify that all FTAs that will be patched are linked, active, and have a current Symphony file. 2. Logon to the master workstation as root user. 3. Run the autoinstall.sh script to define new FTA.workstation definition files FTA Utilities Menu. (Not required if existing FTA.workstation definition files exist.) 4. Run the autoinstall.sh script to create FTA patch installation job definition from the patch option. 5. Run the autoinstall.sh script to export fixpack utility scripts to FTA workstations from the FTA Utilities Menu. (Not required if existing FTA workstations already have the fixpacks utility scripts. This step may be performed anytime prior to the launching of the fixpack installation job.) 6. Run the autoinstall.sh script to create the FTA fixpack installation job stream definitions from the Job and Job Stream Utilities Menu. 7. Verify that the patch_lau_sch_def and patch_succ_sch_def files in the /etc/TWS/MDM.masteruser.mastername directory were created and that the patch_lau_sch_def file includes the fixpack installation jobs for FTA(s). 8. Run the autoinstall.sh script to add FTA patch installation job and job stream definitions to the database from the Job and Job Stream Utilities Menu. 9. Run the autoinstall.sh script to rename the patch_job_def file from the Job and Job Stream Utilities Menu. This step may be performed anytime before the next fixpack installation cycle begins. We suggest that it be done at this time to prevent the combining of fixpacks from two cycles; this will cause the re-application of an existing fixpack.
66
10.Determine when to submit fixpack installation job streams. 11.Logon to the master workstation as TWSuser or connect to Job Scheduling Console. 12.Submit the TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams. This job streams will be scheduled for the master CPU. Refer to Example 10.
Example 10 Submit TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams
Example: conman command from master %sbs TWSPATCH_LAUNCH %sbs TWSPATCH_SUCC 13.Raise job stream TWSPATCH_LAUNCH limit from 0 to a non-zero number using JSC or conman when you are ready to initiate launching of fixpack installations. Refer to Example 11.
Example 11 Raise TWSPATCH_LAUNCH job stream limit
Example: conman command from master %ads TWSPATCH_LAUNCH;limit=40 14.Raise job stream TWSPATCH_LAUNCH priority from 0 to GO using JSC or conman. Refer to Example 12.
Example 12
Example: conman command from master %ads TWSPATCH_LAUNCH;priority=go 15.Determine when the FTA is ready to launch the patch installation. All Tivoli Workload Scheduler jobs must have completed on FTA. FTA must be linked and have the current Symphony file. FTA must be active; limit may be set to 0 to prevent additional jobs from launching. 16.Raise FTA patch installation job priority from 0 to GO for TWSPATCH_LAUNCH.ftaname_twsversion#_FP_patch# using JSC or conman. Refer to Example 13.
Example 13 Raise job priority
Example: conman command from master
67
%adj twspatch_launch.m82a_820_fp_10;priority=go 17.The fixpack installation job will verify job information, and if all of the information is correct, it will launch the patch_lau.sh script in the background prior to exiting successfully. The fixpack installation job should only take a few minutes to run. 18.When the fixpack installation job completes, the job will be SUCC. Refer to Figure 83.
%sj (Est) (Est) CPU Schedule Job State Pr Start Elapse Dependencies Return Code M821A #TWSPATCH_LAUNCH *LIM 40* STUCK GO 17:02 (00:01) [Carry] (HORBLM82#)HORBLM82_820_FP_07 HOLD 0 (M82A#)M82A_820_FP_10 SUCC GO 13:02 00:01 #J27860 0 Figure 83 TWSPATCH_LAUNCH job stream successful jobs
When the fixpack installation job completes, it launches the patch_lau.sh script in the background which executes the twspatch installation script. The patch_lau.sh script, which stops Tivoli Workload Scheduler processes before launching the twspatch installation script, may take several minutes to complete, because Tivoli Workload Scheduler processes on FTA must be stopped before launching the twspatch installation script to perform the fixpack installation. 19.Issue a ps -ef |grep patch from the UNIX prompt on FTA to determine that Tivoli Workload Scheduler patch installation script is running. The listing in Figure 84 shows the patch_lau.sh and the twspatch scripts running. ps -ef |grep patch root 27904 1 0 13:02:48 ? root 28264 27179 0 13:04:25 pts/28 root 27961 27904 0 13:04:02 ?
Figure 84 ps -ef |grep patch list
0:00 /bin/sh -x /etc/TWS/patch_lau.sh 0:00 grep patch 0:00 /bin/sh ./twspatch -install -uname m82a
68
20.When the fixpack installation completes successfully, a job will exist in the TWSPATCH_SUCC job stream on the master. FTA installation job name with a _jobnumber_SUCC extension as the job name will exist in the TWSPATCH_SUCC job stream on the master. Refer to Figure 85.
M821A [Carry] 0
#TWSPATCH_SUCC
*************************** SUCC 10 13:05 00:01 SUCC 10 13:05 00:01 #J28449
M82A_820_FP_10_27860_SUCC
Figure 85 Successful fixpack installation jobs
The jobnumber_SUCC text for the FTA fixpack launch will be added to the job name for the fixpack job that runs on the master.
%sj (Est) (Est) CPU Schedule Job State Pr Start Elapse Dependencies Return Code M821A #TWSPATCH_LAUNCH *LIM 40* STUCK GO 17:02 (00:01) [Carry] (M82A#)M82A_820_FP_10 #J27860 0 M821A #TWSPATCH_SUCC SUCC 10 13:05 00:01 [Carry] SUCC 10 13:05 00:01 #J28449 SUCC GO 13:02 00:01 **************************************** M82A_820_FP_10_27860_SUCC 0
Figure 86 Job stream status
The job that runs on the master is used to generate FTA fixpack installation record entry in the mdm_mastername_fixpack.log file in the /etc/TWS directory, where the mastername is the name of the master that manages the FTA. Refer to Figure 87.
69
$ pwd /etc/TWS $ ll total 160 drwxrwxr-x drwxrwxr-x -rw-rw-r-drwxrwxr-x -rw-rw-rw-rwxr-xr-x -rwxr-xr-x drwxrwxr-x
2 2 1 2 1 1 1 2
root root root root root root root root
sys sys sys sys sys sys sys sys
96 8192 5422 96 68 20312 6459 8192
May May May Feb May May May Jan
14 15 8 26 7 14 14 29
20:03 18:39 11:49 16:16 13:30 20:03 20:03 12:01
APPL.tws MDM.m821a.m821a TWSRegistry.dat appl.tws mdm_m821a_fixpack.log patch_install.sh patch_lau.sh patchutils
Figure 87 The mdm.mastername_fixpack.log file
The mdm.mastername_fixpack.log file will have a record that shows FTA name, Tivoli Workload Scheduler version, fixpack number, fixpack installation job number, and date when the fixpack was installed on the FTA. Refer to Figure 88. $ more mdm_m821a_fixpack.log HORBLM82_820_FP_07_10479_SUCC completed Mon May 7 11:20:52 CDT 2007
Figure 88 FTA fixpack installation log record
Additionally after a successful installation of the fixpack, the FTA will be restarted. It will be in a BATCHMAN LIVES state and have a job limit of 0. 21.Raise the job limit to proceed to the normal Tivoli Workload Scheduler launching of jobs on FTA. 22.Review the Tivoli Workload Scheduler job stdlist for the fixpack installation job if the job abends. The twspatch installation errors will be written to the normal fixpack log. The patch_lau.sh background script will log messages to the fp_fp##_jobnum.stdlog file in the /tmp directory. Refer to Example 14.
Example 14
Example: FTA fixpack install of fixpack 10 that had job number 27860 will create the log: fp_10_27860.stdlog
70
23.You can rerun abended fixpack installation jobs after making changes. Note: Reruns of patch installation jobs will run immediately unless priority is lowered from GO to 0.
Troubleshooting
The creation of the autoinstall.sh patch_install.sh and patch_lau.sh scripts included testing on AIX, HPUX, Linux_i386 and Solaris platforms, and using techniques that worked on these platforms and should not be customized or edited unless suggested by Tivoli Workload Scheduler Level 2 support. Before proceeding to troubleshoot problems with the autoinstall.sh script, please review the following checklist to verify that suggested requirements have been implemented. Refer to Figure 89.
71
The Autoinstall.sh script runs on the master only. The /etc/TWS/APPL.TWS directory must exist for the Tivoli Workload Scheduler patch or new installations. The utility scripts will be located on FTAs in the /etc/TWS directory. The utility scripts repository on the master will be located in the /etc/TWS/APPS.tws directory and be executable. The utility scripts patch_install.sh and patch_lau.sh must be copied from the repository on the master (/etc/TWS/APPS.tws directory) to the /etc/TWS directory on FTA. If the master and FTA exist on the same workstation/node then the utility scripts must exist in both directories. The root user on FTA must be able to submit ad-hoc jobs to the master as root. The TWSRegistry.dat must be correct and up to date. The .profile for the twsuser must have the TWSHome and TWSHome/bin directory in PATH variable for the master and FTA. You should be able to invoke TWS commands without having to specify the path. The Master and FTA workstation must have a valid Symphony file. The Master workstation must currently be linked to the FTA that will be patched. Root must be able to access Tivoli Workload Scheduler files and databases and exist in the Tivoli Workload Scheduler Security file. The patch utility script will only patch AIX, HPUX, Linux_i386 and Solaris UNIX FTAs. The patch utility script uses Tivoli Workload Scheduler cpuinfo to validate the master and FTA CPUs. The master= field in TWSHome/mozart/globalopts file must be valid and correct on the master workstation. The thiscpu= field in TWSHome/localopts file must be valid and correct on FTA workstation. User validation issues may occur if value is not correct. Ideally the patches path should be an NFS mounted filesystem which is mounted on all FTAs that will be patched using the above naming convention. The patch directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os).
Figure 89 Pre-troubleshooting checklist
72
Fixpack logs
The autoinstall.sh generates a few logs. The fixpack job execution which executes the patch_install.sh script will write output to the Tivoli Workload Scheduler job stdlist. The patch_lau.sh script includes tasks which are flagged when completed. The patch_lau.sh writes the ftaname_fp_fp##_jobnum.stdlog file in the /tmp directory. This file may be reviewed to determine the point of failure if the Tivoli Workload Scheduler job abends. These files/logs will be covered in more detail in the following sections. When the fixpack installation completes successfully, a job will exist in the TWSPATCH_SUCC job stream on the master. The job that runs on the master is used to generate FTA fixpack installation record entry in the mdm_mastername_fixpack.log file in the /etc/TWS directory, where mastername is the name of the master that manages the FTA. Refer to Figure 90. $ pwd /etc/TWS $ ll total 160 drwxrwxr-x drwxrwxr-x -rw-rw-r-drwxrwxr-x -rw-rw-rw-rwxr-xr-x -rwxr-xr-x drwxrwxr-x
2 2 1 2 1 1 1 2
root root root root root root root root
sys sys sys sys sys sys sys sys
96 8192 5422 96 68 20312 6459 8192
May May May Feb May May May Jan
14 15 8 26 7 14 14 29
20:03 18:39 11:49 16:16 13:30 20:03 20:03 12:01
APPL.tws MDM.m821a.m821a TWSRegistry.dat appl.tws mdm_m821a_fixpack.log patch_install.sh patch_lau.sh patchutils
Figure 90 The mdm.mastername_fixpack.log file
The mdm.mastername_fixpack.log file will have a record that shows FTA name, TWS version, fixpack number, fixpack installation job number, and date when the fixpack was installed on the FTA. Refer to Figure 91. $ more mdm_m821a_fixpack.log HORBLM82_820_FP_07_10479_SUCC completed Mon May 7 11:20:52 CDT 2007
Figure 91 FTA fixpack installation log record
73
Autoinstall.sh script
The script may be edited by the user to troubleshoot errors. The autoinstall.sh script has an option that places it in a debug mode. This option should be implemented if problems occur with the script. Using the debug option will produce a more verbose mode execution. The output error should be sent to Tivoli Workload Scheduler Level 2 for analysis.
Implementing autoinstall.sh in debug mode

To place the autoinstall.sh script in a debug mode, edit the autoinstall.sh script and proceed to the Debug Mode Option section of the script and change DEBUG= option to DEBUG=y. 1. Edit the autoinstall.sh script and change DEBUG= to DEBUG=y. Refer to Figure 92. #Debug Mode Option #To place in debug mode set DEBUG to y DEBUG="";export DEBUG SETVAR="vx";export SETVAR
Figure 92 Debug mode option
2. As root user, invoke the UNIX script -a command and redirect the output to a file called /tmp/autoinstall.log. Refer to Example 15.
Example 15 Script command syntax
Example: script -a /tmp/autoinstall.log 3. Repeat the steps that produced the error. 4. Enter <ctrl> d to terminate the script command. 5. Review and send the /tmp/autoinstall.log to Tivoli Workload Scheduler Level 2 support for analysis.
Patch_install.sh and patch_lau.sh scripts

The fixpack job executes the patch_install.sh script. The patch_install.sh script requires four options, -uname, -patchdir, -version, and patch, to exist before executing the patch_lau.sh script, which initiates the twspatch fixpack installation script.
74
Because the fixpack job is launched by Tivoli Workload Scheduler, the job stdlist will log all output of the patch_install.sh script. Review the Tivoli Workload Scheduler job stdlist for the fixpack job if job abends. The patch_install.sh script will show which tasks have been completed. Review the job stdlist to determine the task that is having problems. Example 16 is the tail end of the fixpack job stdlist and shows the various tasks and their results. The script is written to display a status of all completed tasks. If the job abends, reviewing the job stdlist will assist in determining that last completed step.
Example 16
Fixpack install job stdlist Logon as root [passed] Valid OS [passed] Options used [passed] -uname option exists [passed] -patchdir option exists [passed] -patch option exists [passed] -version option exists [passed] Two digit patch format x.x [passed] Three digit version format x.x.x [passed] Valid TWS versions 8.2.0 8.2.1 8.3.0 8.4.0 [passed] Valid user specified [passed] Valid patch path specified [passed] Twspatch file exists [passed] Patch tar file exists [N/A] Change to patch directory [passed] Existence of patch files [passed] Display TWS binaries being accessed [passed] Check for existence of patch launch script [passed] /etc/TWS/patch_lau.sh Check for existence of TWS patch log [passed] directory /tmp Patch install logs will default to: /tmp directory F1le m82a_fp_10_27860.stdlog in /tmp directory will have log information. Launch patch launch script [launching] AWSBIS308I End of Job=============================================================== = Exit Status : 0 = System Time (Seconds) : 1 Elapsed Time (Minutes) : 0 = User Time (Seconds) : 0 = Mon 01/29/07 12:35:09 CST
75
The successful completion of the fixpack job (patch_install.sh script) will launch the patch_lau.sh script. The patch_lau.sh script will log which tasks have been completed.log to the ftaname_fp_fp##_jobnum.stdlog file in the /tmp directory. This file logs all procedures prior to execution of the twspatch installation script. Once the twspatch installation script launches, the fixpack install will write, to the log specified, the fixpack README file. Refer to Example 17.
Example 17
Example: FTA m82a fixpack install of fixpack 10 that had job number 27860 will create the log: m82a_fp_10_27860.stdlog A successful completion of the patch_lau.sh and twspatch fixpack installation script will restart the FTA and issue a SUCC job on the master for FTA. The log file ftaname_fp_fp##_jobnum.stdlog will show the status of all tasks performed. Refer to Figure 93. tail -15 /tmp/m82a_fp_10_27860.stdlog Extract TWS shortname Change to TWS instance home directory Stop and shut TWS processes Terminate processes accessing TWS binaries Display TWS binaries should not show active Change to directory where twspatch exists Display current path Execute the twspatch install Twspatch install FTA start and limit 0 command executed Does SUCC patch schedule exist on Master Patch SUCC job sent to SUCC schedule Patch SUCC job sent to JOBS schedule Exit script
Figure 93 Patch_lau.sh log file
[DONE] [DONE] [DONE] [DONE] [DONE] [DONE] [DONE] [DONE] [SUCC] [DONE] [YES] [YES] [N/A] [YES]
Review the log file ftaname_fp_fp##_jobnum.stdlog, if problems exist. You should be able to determine if the problem was in the patch_lau.sh script or if failure was with the twspatch installation script. Twspatch fixpack installation errors will be written to the log file specified in the fixpack README file.
76
Common issues
Here are some of the common issues when using this solution: TWSPATCH_LAUNCH job is SUCC, but TWSPATCH_SUCC job does not show up: Action: Review the /tmp/ftaname_fp_##_######.stdlog file for logging of steps. Where: ftaname = name of FTA that was patched ## = two digit fix pack number ##### = job number of patch installation launch If patch job launch is: M82A#M82A_820_FP_10 #J27860 Possible causes: Root user is not allowed to submit ad-hoc jobs to the master. Utility is unable to validate FTA user Action: Review the "thiscpu" variable for FTA localopts file. Possible causes: The value in "thiscpu" does not match the name of the defined FTA on the master. SUCC GO 13:02 00:01
Then, review log /tmp/m82a_fp_10_27860.stdlog
Configuring OPENSSH
SSH can be used instead of telnet to provide an authenticated and encrypted connection to remote computers. SSH can be configured to make connections without needing to provide a password on the remote workstation. This section will explain how to configure SSH so that connections to remote workstations, will not require passwords. SSH must be installed and enabled on local and remote workstation before it can be used.
77
Please consult your System Administrator for assistance with installation and enabling SSH on the workstations and before performing the following procedures. 1. Logon as the user that will be connecting to the remote workstation as the same user. Example: Logon as larry 2. Verify that SSH is working by connecting to the remote_workstation.domain.com as user "larry" by issuing the following: ssh larry@remote_workstation.domain.com SSH will ask if you want to keep connecting. Type yes, prompt for password, and open a shell in larry's home directory on remote_workstation.domain.com, just like a telnet session. If this fails, a problem exists somewhere. Verify that SSH is installed on the local workstation and verify that remote_workstation.domain.com is accepting SSH connections. 3. Close the remote connection by typing exit. 4. Create the .ssh directory on local workstation in the user's home directory (if the directory does not exist). mkdir .ssh 5. Change to the .ssh directory. Generated private and public SSH keys will be created and placed in this directory. cd .ssh Note: Use Windows Explorer to create the .ssh directory on Windows workstations. 6. Create private and public key pairs so that providing passwords will be not necessary. The following command will create the id_dsa (private) and id_dsa.pub (public) key files. ssh-keygen -t dsa The ssh-keygen program might prompt for the name of key files; depress Enter to accept the default id_dsa file name. The program will then prompt for a passphrase; depress the Enter key unless you want to enter a passphrase. The program will prompt you to confirm the passphrase; depress the Enter key or enter passphrase. The above command creates the keys id_dsa and id_dsa.pub and puts them in the .ssh directory.
78
Generating public/private dsa key pair. Enter file in which to save the key (/home/larry/.ssh/id_dsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/larry/.ssh/id_dsa. Your public key has been saved in /home/larry/.ssh/id_dsa.pub. The key fingerprint is: 09:28:f3:d3:8d:15:d3:8d:c9:67:84:2a:12:51:f6:26 larry@TREK
Figure 94 The ssh-keygen display and prompts
Note: Existing keys id_dsa and id_dsa.pub in the .ssh directory will be overwritten if they already exist. The user will be prompted before they are overwritten. 7. The private key id_dsa must be readable only by the user that created the files. Change permissions of the id_dsa file. chmod 600 id_dsa 8. Place a copy of the public key on the remote workstation. The remote workstation should also be running OpenSSH. You can transfer the id_dsa.pub key to the remote workstation, either by e-mail, ftp, or scp, which is included with SSH. The following example uses scp to copy file from local workstation to the remote workstation. scp .ssh/id_dsa.pub pete@remote_workstation.domain.com: Note: Include the trailing colon ":". You will be prompted for pete's password on the remote workstation before copying begins. The id_dsa.pub file will be copied to pete's home directory on the remote workstation. Copy the public key on the remote workstation to the user's home directory that will receive the connection from the source system. 9. On remote workstation, in local home directory the id_dsa.pub should be placed in the .ssh directory. Create the .ssh directory if it does not exist. 10.Move the id_dsa.pub file to the .ssh directory. 11.Make a backup copy of the authorized_keys file if it exists. cp authorized_keys authorized_keys.orig 12.Append the contents of the id_dsa.pub file to the authorized_keys file.
79
13.The .ssh folder on the remote workstation must have the correct permissions; you may set them with chmod: chmod 700 .ssh 14.Verify the password-less connection, from the original workstation, initiate a connection to the remote workstation as the specified user. ssh larry@remote_workstation.domain.com Note: A password-less connection to remote_workstation.domain.com will be established. The use of scp will not require a password either. 15.Close the remote connection by typing exit. Warning: On the local workstation do not remove the id_dsa file, as the id_dsa.pub may be removed.
Authorized_keys file
To view the defined users and workstation that are permitted to connect to the current workstation, without providing a password that exists in the authorized_keys file, execute the following command from .ssh directory: more authorized_keys|grep "="|cut -f2-3 -d "="|tr -d "^="|tr -d "^ " The sample output (Figure 95) from the above command on workstation taos means that the root user from testmaster.ibm.com and larry from TREK are permitted to connect without providing a password. root@testmaster.tivlab.austin.ibm.com larry@TREK
Figure 95 Defined users in authorized_keys file for taos workstation
The sample output (Figure 96) from the above command on the workstation testmaster means that the root user from taos.ibm.com is allowed to connect without providing a password. root@taos.ibm.com
Figure 96 Defined users in authorized_keys file for testmaster workstation
Know_hosts file
An additional file, know_hosts, may exist in the .ssh directory. This file contains the remote host names that this workstation has connected to.
80
Every time you connect to a machine, SSH stores the remote machine's public key (for public key encryption) in a configuration file (unless you chose to continue connecting without adding the host to the known hosts list). It uses this information to verify that you are connecting to the workstation you thought you were connecting to. This warning means that the host you were trying to connect to was not in your database, and so SSH could not verify that it was the right host. This will be the case if it is the first time you use SSH to connect to a remote workstation from a local workstation Connect, let SSH add the host to your list, and you should not see the warning next time you connect to that host.
81
82
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described 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: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
83
Send us your comments in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an email to: redbook@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099, 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A.
Trademarks
Redpaper
Redbooks (logo) Tivoli
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX IBM
The following terms are trademarks of other companies: Solaris, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, or service names may be trademarks or service marks of others.
84

Autoinstall - SH Utility Script Redp4296

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autoinstall - SH Utility Script Redp4296

Uploaded by

Copyright:

Available Formats

Redpaper

Pete Soto Vasfi Gucer

Autoinstall.sh Utility Script

Copyright IBM Corp. 2007. All rights reserved.

Autoinstall.sh Utility Script

Autoinstall.sh script information and requirements

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Example 1 Fixpack base naming convention

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Tivoli Workload Scheduler requirements

Autoinstall.sh Utility Script

Patching procedures - First time execution

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

MDM users listed in the TWSRegistry.dat file -> m821a

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Patching procedures- Subsequent executions

Autoinstall.sh Utility Script

2. Reply to the prompt asking to use the existing APPL.tws application.

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Note: Only UNIX FTA workstations may be patched.

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Create a new APPL.xxxx definition

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Utilities - FTA Utilities

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

4. For FTA maintenance tasks, reply f to perform FTA maintenance tasks.

Autoinstall.sh Utility Script

Add or Update an FTA File

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Add New FTA Definition

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Autoinstall.sh Utility Script

Update an Existing FTA.workstation File