Tivoli Workload Scheduler Planning and Installation Guide Version 7.0

Transcription

1 Tivoli Workload Scheduler Planning and Installation Guide Version 7.0

2

3 Tivoli Workload Scheduler Planning and Installation Guide Version 7.0

4 Tivoli Workload Scheduler Planning and Installation Guide (May 2000) Copyright Notice Copyright 2000 by Tivoli Systems Inc., an IBM Company, including this documentation and all software. All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of Tivoli Systems. Tivoli Systems grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the Tivoli Systems copyright notice. No other rights under copyright are granted without prior written permission of Tivoli Systems. The document is not intended for production and is furnished as is without warranty of any kind. All warranties on this document are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation. Trademarks The following product names are trademarks of Tivoli Systems or IBM Corporation: AIX, IBM, OPC, OS/390, and Tivoli. Tivoli is a registered trademark or trademark of Tivoli Systems Inc. in the United States, other countries or both. In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S. Microsoft, Windows, Windows NT, and the Windows logo are trademarks or registered trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. Java and all Java-based trademarks or logos are trademarks of Sun Microsystems, Inc. in the Unite States, other countries, or both. Other company, product, and service names mentioned in this document may be trademarks or service marks of others. Notices References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to Tivoli System s or IBM s valid intellectual property or other legally protectable right, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York , U.S.A.

5 Contents Preface... ix Who Should Read This Guide... ix Prerequisite and Related Documents... ix What This Guide Contains... ix Platform-specific Information... x Contacting Customer Support... xi Chapter 1. Introduction... 1 Tivoli Workload Scheduler What is New with Tivoli Workload Scheduler Network Planning... 8 TWS Network Overview... 8 Domain Functionality... 9 Localized Processing in Your Domain Network Considerations A Single Domain Network A Multiple Domain Network Switching to a Backup Domain Manager Expanded Database and Long Object Names Workstation Names Installation Overview Product Groups Components File Netman s Home Directory After Installation Chapter 2. Installing the TWS Engine on Windows NT 23 Tivoli Workload Scheduler Planning and Installation Guide iii

6 System Requirements Preparing for an Update Unlinking and Stopping TWS Backup Files Installing the Software The Setup Program Running Setup Following Installation and Update Completing an Update Setting the PATH Variable TWS Directories and Services Setting Up Decentralized Administration Creating the TWS Account Manually Types of TWS Administration Uninstalling TWS Using the Windows NT Add/Remove Tool The Uninstal.exe Program Chapter 3. Installing the TWS Engine on UNIX System Requirements Installation Procedure Installing the Tivoli Workload Scheduler Engine Configuration Steps Updating Tivoli Workload Scheduler Preparation-Stop TWS Backup Update Software and Run Customize Update Security Profile Restore Your Files iv Version 7.0

7 Restart TWS The Customize Script Uninstalling TWS Chapter 4. Setting TWS Security Editing the Security File Chapter 5. Installing the TWS Connector Prior to Installation System Requirements Supported Platforms Installation Procedure Installing the Job Scheduling Services (JSS) Installing the TWS Connector Installing JSS and TWS Connector Patches Updating TWS Security Uninstalling the TWS Connector Uninstalling the JSS Server Useful Framework Commands Chapter 6. Installing the Tivoli Job Scheduling Console System Requirements Supported Platforms Prerequisites for HP-UX and AIX Installing the Job Scheduling Console Starting the Job Scheduling Console Uninstalling the Job Scheduling Console UNIX Uninstall Tivoli Workload Scheduler Planning and Installation Guide v

8 Windows Uninstall Chapter 7. Optional TWS Customization Topics Setting Global Options Setting Local Options Automating the Production Cycle Customizing the final Job Stream Adding the final Job Stream Starting a Production Cycle Managing the Production Environment Choosing the TWS Start of Day Changing the Start of Day Creating a Plan for Future or Past Dates Appendix. Migrating to TWS The Tivoli Management Framework for non-tivoli users Installation Considerations Where Can The JS Console Client Be Installed Where Should The TWS Connectors Be Installed Backup Master Considerations Dealing with Non-tier 1 Masters in an Existing Maestro Network Moving the Backup Master Creating a Backup Master Mounting MDM Databases Dealing with Non-tier 1 Backup Masters in an Existing Maestro Network 128 Running Multiple Windows in the JS Console Making an Existing Security File Work Adding TME Administrators Managing Security vi Version 7.0

9 Stopping Connectors to Implement Changes Legacy GUI Limitations Using the Legacy GUI on AIX Timezone Considerations Propagating User Preferences to Other Users (Custom Views/Queries) Backing Out of an Expanded Database Migrating on Windows NT Migrating from Maestro 5.2 on Windows NT Agents Appendix. Networking with MPE Network Considerations Scheduling Considerations Installation Setup and Configuration Setting Up a UNIX agent with MPE Master Setting Up an MPE FTA with UNIX or Windows NT Operational Differences Between Platforms On the MPE Master On UNIX Fault-Tolerant Agents On the UNIX or Windows NT Master On the MPE Slaves Glossary Index Tivoli Workload Scheduler Planning and Installation Guide vii

10 viii Version 7.0

11 Preface The Tivoli Workload Scheduler Planning and Installation Guide provides information on installing a Tivoli Workload Scheduler 7.0 network. This includes information on how to plan a network, install the TWS engine, connector software, and the graphical user interface.it also provides instructions to customize TWS options and security in order to start a TWS network. Finally, it gives tips and information on migrating from previous versions of Maestro. Who Should Read This Guide This book is intended for the following audience: TWS administrators - those who plan the layout of the TWS network. Installers - those who install the various software packages on the computers that make up the TWS network. Prerequisite and Related Documents The following are related documents: Tivoli Workload Scheduler User s Guide Provides information about configuring and using Tivoli Workload Scheduler. It contains information on TWS networks, security, global and local options files, an overview of the production cycle, and descriptions of database and plan tasks. Tivoli Workload Scheduler Reference Manual Provides information about the Tivoli Workload Scheduler command line interfaces, including composer, conman, the scheduling language, and utility commands. What This Guide Contains The Tivoli Workload Scheduler Planning and Installation Guide contains the following: Chapter 1, Introduction Tivoli Workload Scheduler Planning and Installation Guide ix

12 Provides planning information to set up a TWS network and an overview of the installation process. Chapter 2, Installing the TWS Engine on Windows NT Explains how to install the TWS engine on Windows NT. Chapter 3, Installing the TWS Engine on UNIX Explains how to install the TWS engine on UNIX. Chapter 4, Setting TWS Security Explains how to customize the Security file. Chapter 5, Installing TWS Connector Explains how to install the TWS Connector. Chapter 6, Installing the Job Scheduling Console Explains how to install the Job Scheduling Console. Chapter 7, Optional TWS Customization Topics Describes customization options for a TWS network. Appendix A, Migrating to TWS 7.0 Provides useful information for migrating from Maestro 5.x and 6.x. Platform-specific Information The following table identifies the supported versions for each of the listed platforms known at the time of publication. For more detailed and up-to-date information, please see the Tivoli Workload Scheduler Release Notes. Platform TWS Engine TWS JS Console Connector AIX 4.2 X X X AIX 4.3 X X X HP-UX X X X HP-UX 11.0 X X X Solaris 2.6 X X X Solaris 2.7 X X X x Version 7.0

13 Platform TWS Engine TWS JS Console Connector Windows NT 4.0 X X X w/ SP 4 or higher Windows 2000 X Digital UNIX X Intel ABI compliant X platforms MIPS ABI compliant platforms X Note: On AIX 4.3, you must install the bos.rte.commands bff patch. To determine whether or not this patch is already installed on your system, run the following command: lslpp -l bos.rte.commands If the command returns a value below , then you must install the patch. Contacting Customer Support If you are entitled to Tivoli customer support, you can find frequently updated information about configuring and using Tivoli products from the Tivoli Customer Support home page at support/. This site includes the following links: Updated versions of these release notes: Updated versions of Tivoli documentation: Searchable support databases: Tivoli Workload Scheduler Planning and Installation Guide xi

14 Access to product patches: Access to training schedules: Access to Tivoli documentation survey: Visit the Tivoli Customer Support site for this information and additional customer services. These URLs do require a password and ID. If you do not have access privileges or are unsure of your ID or password, send to Customer_Support_Web_Registration@tivoli.com. Include your name and your company name in this correspondence. You can order additional copies of product documentation by sending or calling one of the following locations: U.S. Customer swdist@tivoli.com U.S. Telephone: Canada Telephone: International Telephone: (770) Please provide the title and version number of the document that you are ordering. xii Version 7.0

15 1 1. Introduction Introduction This guide contains instructions for installing and updating Tivoli Workload Scheduler 7.0. Tivoli Workload Scheduler 7.0 Tivoli Workload Scheduler 7.0 is composed of three parts: Tivoli Workload Scheduler Engine The legacy Maestro product. Install the Engine on the Master and on all the physical Agent CPUs. TWS Connector Maps Job Scheduling Console commands to the TWS Engine. Install the TWS Connector on the Master and on any of the fault-tolerant agents (FTA) that you will use as backup machines for the Master CPU. The Connector pre-requires the Tivoli Management Framework (TMF) configured for a Tivoli Management Region (TMR) server or managed node. Job Scheduling (JS) Console A Java based graphical user interface (GUI) for TWS. Install the JS Console on any machine from which you want to manage TWS plan and database objects. The JS Console does not require the TWS Engine or the TWS Connector to be installed in the same machine. You can use the JS Console from any machine as long as it has a TCP/IP link with the machine running the TWS Connector. Tivoli Workload Scheduler Planning and Installation Guide 1

16 Tivoli Workload Scheduler 7.0 A TWS network is made up of the workstations, or CPUs, on which jobs and job streams are executed. Primarily, workstation definitions refer to physical workstations. However, in the case of extended and network agents the workstations are logical definitions that must be hosted by a physical TWS workstation. A Tivoli Workload Scheduler 7.0 network is made up of the following types of workstation: Master Domain Manager (MDM) The domain manager in the topmost domain of a TWS network. It contains the centralized database files used to document scheduling objects. It creates the Production plan at the start of each day, and performs all logging and reporting for the network. Backup Master A fault-tolerant agent capable of assuming the responsibilities of the master domain manager. Domain Manager The management hub in a domain. All communications to and from the agents in a domain are routed through the domain manager. Backup Domain Manager A fault-tolerant agent capable of assuming the responsibilities of its domain manager. Fault-tolerant Agent (FTA) A workstation capable of resolving local dependencies and launching its jobs in the absence of a domain manager. Standard Agent A workstation that launches jobs only under the direction of its domain manager. Extended Agent A logical workstation definition that enables you to launch 2 Version 7.0

17 Tivoli Workload Scheduler 7.0 and control jobs on other systems and applications, such as Baan, Peoplesoft, Oracle Applications, SAP, and MVS JES2 and JES3. Network Agent A logical workstation definition for creating dependencies between jobs and job streams in separate TWS networks. JS Console Client Any workstation running the graphical user interface from which schedulers and operators can manage TWS plan and database objects. 1. Introduction The following table summarizes which TWS 7.0 component goes into what type of workstation: Workstation type TWS Engine TMF/TWS Connector JS Console Master Domain Manager Yes Yes Optional Backup Master Yes Yes Optional Domain Manager Yes Optional Optional Backup Domain Manager Yes Optional Optional Fault-tolerant Agent Yes Optional Optional Standard Agent Yes No Optional Extended Agent Not Applicable Not Applicable Not Applicable Network Agent Not Applicable Not Applicable Not Applicable JS Console Client No No Yes What is New with Tivoli Workload Scheduler 7.0 TWS 7.0 includes the following new features: Integration with the Tivoli Management Region Use of a new graphical user interface Auditing Internationalization Time Zones Tivoli Workload Scheduler Planning and Installation Guide 3

18 Tivoli Workload Scheduler 7.0 The Tivoli Management Framework The new TWS version requires that you install the Tivoli Management Framework at least on the Master CPU and on the FTA designed as its backup. This has two main reasons: 1. The Connector is a Framework-based product. It is based on the Job Scheduling Services (JSS), which provides a common framework interface to job scheduling applications. Connectors for TWS and for OPC share a common JSS foundation, which is in turn based upon the Tivoli Management Framework. This enables users of TWS and of OPC to access their job scheduling engines through a common interface, the JS Console. 2. Since the Master and at least one backup FTA must be installed on machines running TMF, the TWS network partakes in the benefits of Framework-based enterprise management. You may choose to install the Master on a stand alone TMR server, or on a managed node that belongs to a larger Tivoli Management Region. In this case, the managed node can be the client of a number of other Tivoli services in the areas of deployment, administration, or availability. In any case, the Master and the backup FTA will benefit from the security and administrative capabilities of the Tivoli Management Framework. The Job Scheduling Console The Job Scheduling Console is a graphical user interface from which you can manage plan and database objects. It provides, through the TWS Connector, Conman and Composer functionality. It can run both independently or simultaneously with the command line interfaces (CLI). While usage of CLI commands is confined to TWS CPUs, you can install the JS Console on machines outside of the TWS network. To run the JS Console, you only have to be able to log into a TWS CPU running the Connector. This means that you can manage plan and database objects not only from the Master or Agent CPUs, but also from any system, including a laptop, on which the JS Console is installed and from which you can reach via TCP/IP the Master or the FTA running the Connector. 4 Version 7.0

19 Tivoli Workload Scheduler 7.0 From the same Job Scheduling Console you can also manage Tivoli Operations Planning and Control (OPC) plan and database objects, provided that you can log into a machine running the OPC Connector. Installation of the JS Console is explained in detail in Installing the Tivoli Job Scheduling Console on page Introduction The following picture shows the relationships between the Tivoli Management Framework, the Job Scheduling Services, the TWS and OPC job scheduling engines, and the JS Console. JS Console Terminology The terminology used in the Job Scheduling Console differs from that used in the command line and earlier versions of Workload Scheduler. The following table lists the old terms and their Job Scheduling Console equivalents. Refer to the glossary for more definitions. Command Line Job Scheduling Definition Console Schedule Job Stream A unit of work consisting of a set of jobs and their dependencies. Job Stream Instance The occurrence of a job stream in the plan. Tivoli Workload Scheduler Planning and Installation Guide 5

20 Tivoli Workload Scheduler 7.0 Command Line Job Scheduling Definition Console Job Job An executable file, task or command, and its attributes. It is scheduled to run as part of a job stream. Job Instance The occurrence of a job in the plan. Cpu Workstation A logical processor typically a computer that runs jobs. Types of workstations include Domain Managers, Backup Domain Managers, Fault-Tolerant Agents, Standard Agents, and Extended Agents. Mozart Files Database A collection of scheduling objects including jobs, job streams, parameters, calendars, and resources. It is accessed by composer, formerly known as gcomposer. Symphony File Plan The scheduled activity for a period, typically 24-hours. The plan is continuously updated to show the current status of all Workload Scheduler activities. It is accessed by conman, formerly known as gconman. AT Time Start Time The earliest time a job or job stream will begin. UNTIL Time Deadline Time The latest time a job or job stream will begin execution. ON and EXCEPT Dates Run Cycles The dates on which a job stream runs or is excluded from running. Auditing An auditing option has been implemented to track changes to the database and the plan: For the database, all user modifications are logged. However, the delta of the modifications, or before image and after image, will not be logged. If an object is opened and saved, the action will be logged even if no modification has been done. 6 Version 7.0

21 Tivoli Workload Scheduler 7.0 For the plan, all user modifications to the plan are logged. Actions are logged whether they are successful or not. The auditing logs are created in the following directories: TWShome/audit/plan TWShome/audit/database Audit files are logged to a flat text file on individual machines in the TWS network. This minimizes the risk of audit failure due to network issues and allows a straightforward approach to writing the log. The log formats are the same for both plan and database in a general sense. The logs consist of a header portion which is the same for all records, an action ID, and a section of data which will vary according the action type. All data is kept in clear text and formatted to be readable and editable from a text editor such as vi or notepad. 1. Introduction See the TWS User s Guide for details on setting the auditing feature. Internationalization TWS 7.0 is translated into several languages other than English. They are: German, French, Italian, Spanish, Brazilian Portuguese, Chinese, Korean, and Japanese. Time Zone Considerations Time zone support is a feature that can be either enabled or disabled. Time zones are enabled if the timezone enable flag in the globalopts file is set to yes and if the master workstation has a time zone definition. Time zones are disabled by default on installation of the product. If time zones are enabled, the time zone fields in the Job Scheduling Console are enabled. If you leave a workstation definition time zone blank, it will default to the time zone of the master domain manager workstation. If time zones are disabled, then all the time zone fields are disabled throughout the application. In composer and conman, you get an error if you try to specify a time zone along with a time. In the Job Tivoli Workload Scheduler Planning and Installation Guide 7

22 Tivoli Workload Scheduler 7.0 Network Planning Scheduling Console, the time zone fields are disabled for both the database and the plan. The only exception to this are workstations in the database, which have time zones enabled at all times. When enabling the time zone for the master workstation, it is recommended that you enter a time zone for any FTAs not in the same time zone as the master. A blank FTA time zone is assumed to be the same as the master time zone. When time zones have been enabled, you can enter a time zone along with a time in conman, composer or the Job Scheduling Console. If you enter a time with no time zone, the time zone will be taken from the workstation on which the job or job stream executes, or from the master workstation time zone if the executing workstation time zone is blank. Before you begin installing Tivoli Workload Scheduler, determine the answers to the following questions. The next sections provide information to help you in determining the answers that best suit your needs. 1. Will you use multiple domains or a single domain network structure? 2. If you use multiple domains, how will you divide your domains: by geographical locations, for example, London and Paris domains? by timezone, for example Pacific Standard Time (pst) and Eastern Standard Time (est)? by business unit, for example marketing and accounting? 3. Will you use expanded or non-expanded databases? 4. Will you activate the timezone feature? TWS Network Overview A Workload Scheduler network contains at least one Workload Scheduler domain, the master domain, in which the master domain 8 Version 7.0

23 Network Planning manager is the management hub. Additional domains can be used to divide a widely distributed network into smaller, locally managed groups. Using multiple domains reduces the amount of network traffic by reducing the communications between the master domain manager and other computers. 1. Introduction In a single domain configuration, the master domain manager maintains communications with all of the workstations in the Workload Scheduler network. In a multi-domain configuration, the master domain manager communicates with the workstations in its domain, and subordinate domain managers. The subordinate domain managers, in turn, communicate with the workstations in their domains and subordinate domain managers. Multiple domains also provide fault-tolerance by limiting the problems caused by losing a domain manager to a single domain. To limit the effects further, you can designate backup domain managers to take over if their domain managers fail. Domain Functionality When you define a new domain, you must identify the parent domain and the domain manager. The parent domain is the domain directly above the new domain in the domain hierarchy. All communications to and from a domain are routed through the parent domain manager. Before the start of each new day, the master domain manager creates a production control file, named Symphony. Tivoli Workload Scheduler is then restarted in the network, and the master domain manager sends a copy of the new Symphony file to each of its automatically linked agents and subordinate domain managers. The domain managers, in turn, send copies to their automatically linked agents and subordinate domain managers. Once the network is started, scheduling messages like job starts and completions are passed from the agents to their domain managers, through the parent domain managers to the master domain manager. Tivoli Workload Scheduler Planning and Installation Guide 9

24 Network Planning The master domain manager then broadcasts the messages throughout the hierarchical tree to update the Symphony files of domain managers and fault tolerant agents running in Full Status mode. Localized Processing in Your Domain A key to choosing how to set up your Tivoli Workload Scheduler domains is the concept of localized processing. The idea is to separate or localize your scheduling needs based on a common set of characteristics. Common characteristics are things such as geographical locations, business functions, and application groupings. Grouping related processing can limit the amount of interdependency information that needs to be communicated between domains. The benefits of localizing processing in domains are: Decreased network traffic. Keeping processing localized to domains eliminates the need for frequent interdomain communications. Provides a convenient way to tighten security and simplify administration. Security and administration can be defined at, and limited to, the domain level. Instead of network-wide or workstation-specific administration, you can have domain administration. Network and workstation fault tolerance can be optimized. In a multiple domain Tivoli Workload Scheduler network, you can define backups for each domain manager, so that problems in one domain do not disrupt operations in other domains. Network Considerations The following questions will help in making decisions about how to set up your Tivoli Workload Scheduler network. Some questions involve aspects of your network, and others involve the applications controlled by Tivoli Workload Scheduler. You may need to consult with other people in your organization to resolve some issues. 10 Version 7.0

25 Network Planning How large is your Tivoli Workload Scheduler network? How many computers does it hold? How many applications and jobs does it run? The size of your network will help you decide whether to use a single domain or the multiple domain architecture. If you have a small number of computers, or a small number of applications to control with Tivoli Workload Scheduler, there may not be a need for multiple domains. 1. Introduction How many geographic locations will be covered in your Tivoli Workload Scheduler network? How reliable and efficient is the communication between locations? This is one of the primary reasons for choosing a multiple domain architecture. One domain for each geographical location is a common configuration. If you choose single domain architecture, you will be more reliant on the network to maintain continuous processing. Do you need centralized or decentralized management of Tivoli Workload Scheduler? A Tivoli Workload Scheduler network, with either a single domain or multiple domains, gives you the ability to manage Tivoli Workload Scheduler from a single node, the master domain manager. If you want to manage multiple locations separately, you can consider the installation of a separate Tivoli Workload Scheduler network at each location. Note that some degree of decentralized management is possible in a stand-alone Tivoli Workload Scheduler network by mounting or sharing file systems. Do you have multiple physical or logical entities at a single site? Are there different buildings, and several floors in each building? Are there different departments or business functions? Are there different applications? These may be reasons for choosing a multi-domain configuration. For example, a domain for each building, department, business function, or each application (manufacturing, financial, engineering, etc.). Tivoli Workload Scheduler Planning and Installation Guide 11

26 Network Planning Do you run applications, like SAP R/3 or Baan, that will operate with Tivoli Workload Scheduler? If they are discrete and separate from other applications, you may choose to put them in a separate Tivoli Workload Scheduler domain. Would you like your Tivoli Workload Scheduler domains to mirror your Windows NT domains? This is not required, but may be useful. Do you want to isolate or differentiate a set of systems based on performance or other criteria? This may provide another reason to define multiple Tivoli Workload Scheduler domains to localize systems based on performance or platform type. How much network traffic do you have now? If your network traffic is manageable, the need for multiple domains is less important. Do your job dependencies cross system boundaries, geographical boundaries, or application boundaries? For example, does the start of Job1 on CPU3 depend on the completion of Job2 running on CPU4? The degree of interdependence between jobs is an important consideration when laying out your Tivoli Workload Scheduler network. If you use multiple domains, you should try to keep interdependent objects in the same domain. This will decrease network traffic and take better advantage of the domain architecture. What level of fault-tolerance do you require? An obvious disadvantage of the single domain configuration is the reliance on a single domain manager. In a multi-domain network, the loss of a single domain manager affects only the agents in its domain. A Single Domain Network A single domain Tivoli Workload Scheduler network consists of a master domain manager and any number of agents. The diagram 12 Version 7.0

27 Network Planning below shows an example of the single domain network. A single domain network is well suited to companies that have few locations and business functions. All communications in the network are routed through the master domain manager. With a single location, you are concerned only with the reliability of your local network, and the amount of traffic it can handle. 1. Introduction It is important to note that single domain networks can be combined with other networks, single or multiple domain, to meet multiple site requirements. Tivoli Workload Scheduler supports inter-network dependencies between jobs running on different Tivoli Workload Scheduler networks. Tivoli Workload Scheduler Planning and Installation Guide 13

28 Network Planning The example on the left above shows a single domain network. The master domain manager is located in Atlanta, along with several agents. There are also agents located in Denver. The agents in Denver depend on the master domain manager in Atlanta to resolve all inter-agent dependencies, even though the dependencies may be on jobs that run in Denver. An alternative would be to create separate single domain TWS networks in Atlanta and Denver, as shown on the right. Advantages of single domain networks are: Simpler architecture. Centralized control and management. Disadvantages of single domain networks are: All communications must pass through the master domain manager. This can result in a heavy load on a widely distributed network. Failure of the master domain manager impacts the entire Tivoli Workload Scheduler network. 14 Version 7.0

29 Network Planning A Multiple Domain Network Multiple Domain networks are especially suited to companies that span multiple locations, departments, or business functions. A multiple domain Tivoli Workload Scheduler network consists of a master domain manager, any number of lower tier domain managers, and any number of agents in each domain. Agents communicate only with their domain managers, and domain managers communicate with their parent domain managers. 1. Introduction The diagram shows an example of a multiple domain network. This diagram builds on the example shown for single domain networks. The master domain manager is located in Atlanta; it contains the database files used to document the scheduling objects, and distributes the Symphony file to its agents and the domain managers in Denver and Los Angeles. The Denver and Los Angeles domain managers then distribute the Symphony file to their agents and subordinate domain managers in Boulder, Aurora and Burbank. The master domain manager in Atlanta is responsible for broadcasting inter-domain information throughout the network. Tivoli Workload Scheduler Planning and Installation Guide 15

30 Network Planning All communications to and from the Boulder domain manager are routed through its parent domain manager in Denver. If there are schedules or jobs in the Boulder domain that are dependent on schedules or jobs in the Aurora domain, those dependencies are resolved by the Denver domain manager. Most inter-agent dependencies are handled locally by the lower tier domain managers, greatly reducing traffic on the WAN (Wide Area Network). Advantages of multiple domain networks: Ad hoc schedules and jobs can be submitted from the master domain manager, or from any other domain manager or agent that has access to the database files on the master domain manager. Reduced network traffic due to localized processing. Local resolution of inter-agent dependencies. Localized security and administration. Flexible topology that maps to your business model. On the fly switchover to backup domain manager. Switching to a Backup Domain Manager Each domain has a domain manager and, optionally, one or more backup domain managers. A backup domain manager must be in the same domain as the domain manager it is backing up. The backup domain managers must be fault-tolerant agents running Tivoli Workload Scheduler 7.x, and must have the Resolve Dependencies and Full Status options enabled in their workstation definitions. If a domain manager fails during the production day, you can use either the Job Scheduling Console, or the switchmgr command in the Console Manager command line (conman), to switch to a backup domain manager. A Switch Manager action can be executed by anyone with start and stop access to the domain manager and backup domain manager workstations. A switch manager operation stops the backup manager, then restarts it as the new domain manager, and converts the old domain manager 16 Version 7.0

31 Network Planning to a fault-tolerant agent. The identities of the current domain managers are carried forward in the Symphony file from one processing day to the next, so any switch remains in effect until you switch back to the original domain manager. Expanded Database and Long Object Names Tivoli Workload Scheduler databases and the Symphony file have been expanded to accommodate more records and longer object names. This allows more flexibility when naming scheduling objects, especially with packages such as SAP R/3, Baan, etc. Expanded databases is the default in Tivoli Workload Scheduler 7.0. It permits the use of long names for scheduling objects -- for example, job names can contain up to forty characters instead of eight as in earlier versions. Non-expanded databases are used to remain backward compatible to Maestro 5.x workstations which do not support expanded databases. Notes: 1. It is suggested that the master be running an equal or lower TWS version than the FTAs in the domain. 2. If you have MPE (HP3000) agents, be sure you run non-expanded databases. 1. Introduction Database Creation For new installations, Tivoli Workload Scheduler databases are created on the master domain manager the first time you run the TWS engine. The type of databases created, expanded or non-expanded, is determined by checking the Global Option expanded version = [yes no]. This option is set by the customize script when you installed the TWS Engine. The default is expanded set to yes. You can select non-expanded databases when you first install TWS 7.0, and expand the databases later. To expand the databases, run the dbexpand command on the master domain manager. The program sets the Global Option expanded version to yes, makes backup copies of the existing databases, and expands the databases to accept Tivoli Workload Scheduler Planning and Installation Guide 17

32 Network Planning long object names. Only run dbexpand one time, otherwise the backup copy of the existing databases will be lost. The backup copies are placed in a directory named mozart.old in the mozart directory. Workstation Names Job scheduling in a Tivoli Workload Scheduler network is distributed across multiple computers. To accurately track jobs, schedules, and other objects, each computer is given a unique workstation name. The names can be the same as network node names, as long as they comply with Tivoli Workload Scheduler s naming rules: For unexpanded networks, the workstation names can contain up to eight alphanumeric, dash (-), and underscore (_) characters starting with a letter. For expanded networks, the maximum length is sixteen alphanumeric, dash (-), and underscore (_) characters starting with a letter. Installation Overview Below is a summary of the installation process for TWS 7.0. This guide provides detailed instructions for each step. 1. On all Domain Managers (including Master and Backup), follow this order: a. If you are installing over a previous version of Maestro or TWS, unlink the other workstations in the domain and stop Maestro or TWS. See Unlinking and Stopping TWS on page 24 for NT and Updating Tivoli Workload Scheduler on page 53 for UNIX. Install the TWS 7.0 Engine. See Installing the TWS Engine on Windows NT on page 23 or Installing the TWS Engine on UNIX on page 47.You can actually reverse the order in which you perform this and the next step. b. Install the Tivoli Management Framework. If you do not already have a Tivoli Management Region in your enterprise, install as a TMR server. If a TMR already exists, you can 18 Version 7.0

33 Installation Overview choose to install as a managed node. See the TMF installation documentation for details. c. Install the Job Scheduling Services and the TWS Connector on the Tivoli Framework. See Installing the TWS Connector on page 77. d. From the Tivoli Desktop, create a Tivoli Administrator for TWS. In other words, either add the TWS or Maestro user as a login for the TMF administrator, or create a new TMF administrator with the TWS or Maestro login. e. Update TWS security to include the Tivoli Administrator. On NT, you must stop TWS before you run the makesec command. On UNIX, you can run makesec without previously stopping TWS, but you must stop and restart TWS to activate the security feature. f. Optionally, install the Job Scheduling Console. See Installing the Tivoli Job Scheduling Console on page Install the following on each workstation you want to include as an agent in the TWS network: TWS 7.0 Engine. The Job Scheduling Console (optional). You can install the JS Console also on workstations not in the TWS network that have a TCP/IP connection with a Domain Manager running the TWS Connector. 3. Log into the Job Scheduling Console, and define the workstations in your TWS network to the TWS database. 4. Now you can use the Job Scheduling Console to define your jobs, job streams and other scheduling objects. 1. Introduction Tivoli Workload Scheduler Planning and Installation Guide 19

34 Product Groups Product Groups Tivoli products are organized into product groups. Each group has a Netman process to handle the services required by all products in the group. This also permits multiple copies of a product to be installed on a single computer by designating a different group for each copy. Components File Product groups are defined in the components file. If the file does not exist prior to installation, it is created by the customize script on UNIX, or the Setup program on Windows NT. A UNIX sample follows: <product> <version> <home directory> <product group> Maestro Destiny Netman /opt/maestro /opt/destiny /opt/netman production production production Entries in the file are automatically made and updated by customize or Setup. The product group workstation_user is used as default on NT if you do not specify a group. On UNIX, the file name of the components file is defined in the variable: UNISON_COMPONENT_FILE If the variable is not set, customize uses the file name: /usr/unison/components On Windows NT, the name of the components file, netmanhome\components, is recorded in the registry the first time this version of Workload Scheduler is installed. See Netman s Home Directory on page 21. Viewing the Components File Following installation or update, you can view the contents of the components file by running the ucomp program as follows: ucomp -l 20 Version 7.0

35 Product Groups Netman s Home Directory An option in the customize script on UNIX, and a Setup screen on Windows NT, allows you to specify a home directory for Netman. If skipped, the default on UNIX is Workload Scheduler s home directory, and on Windows NT the default is: c:\win32app\unison\netman. Netman Local Options If Netman s home directory is not the same as Workload Scheduler s home directory, the following local options are moved from Workload Scheduler s localopts file to a separate localopts file in the Netman directory: nm mortal nm port nm read nm retry merge stdlists stdlist width syslog local 1. Introduction After Installation And, the following option can be added, if desired: nm ipvalidate See section 2 in the Tivoli Workload Scheduler Administrator s Guide for more information about Local Options. After installing Workload Scheduler, refer to the Tivoli Workload Scheduler User s Guide for configuration and set up information. Tivoli Workload Scheduler Planning and Installation Guide 21

36 22 Version 7.0

37 2 Installing the TWS Engine on Windows NT This chapter describes the installation process for Tivoli Workload Scheduler (TWS) on Windows NT systems and networks. System Requirements The following are TWS system requirements for Windows NT systems. Windows NT version 4.0 with Service Pack 4 or higher. CD-ROM drive for installation. NTFS partition to install TWS. Approximately 100 MB of free disk space for domain managers, and fault-tolerant agents. Approximately 40 MB for standard agents. In addition, TWS produces log files, and temporary files, that are placed on the local hard drive. The amount of space required depends on the number of jobs managed by TWS, and the amount of time you choose to retain log files. 128 MB RAM and 128 MB swap space for domain managers and fault-tolerant agents. Standard agents require less. TCP/IP network communications. A TWS user account is required for proper installation. You can create the account beforehand, or have the Setup program create it for you. 2. Installing the TWS Engine on Windows NT Tivoli Workload Scheduler Planning and Installation Guide 23

38 System Requirements Before continuing, see the Tivoli Workload Scheduler Release Notes for information about the latest system requirements, and platform-specific issues. Preparing for an Update If this is an update of an existing installation of TWS, follow the steps below before running the Setup program. After Setup is complete, refer to Completing an Update on page 37 for important post-setup steps. Note: The standard approach to updating a TWS network is to update the fault-tolerant and standard agents first, and then the master domain manager. However, before deciding how to update your TWS network, refer to the Tivoli Workload Scheduler Release Notes for the latest information about migrating to a new software version. Unlinking and Stopping TWS Before starting an update of TWS, follow these steps to unlink workstations and stop TWS processes. Note that this procedure is for updating from a previous version of TWS, either Maestro 6.x or 5.x. 1. On the target workstation, login as maestro if you are updating from Maestro 5.2, or as Administrator if you are updating from Maestro 6.x. Run the Console Manager. 2. Click the workstation icon, or select CPUs from the Objects menu. 3. In the Showcpus window: a. If you are updating the master domain manager, select all of the fault-tolerant and standard agents, and choose Unlink from the Actions menu. b. If you are updating a fault-tolerant or standard agent workstation, select the master domain manager, and choose Unlink from the Actions menu. 4. Select the workstation you are updating and choose Stop from the Actions menu. 24 Version 7.0

39 5. Exit the Console Manager. 6. At a command prompt, run the command line from TWShome and enter the following command to stop TWS services: conman shutdown;wait Backup Files TWS s Setup program will move your copies of Sfinal, Jnextday, NetConf, StartUp and the methods directory to a directory named: TWShome\config.old Preparing for an Update These files are often customized to meet your specific needs, and you can use the saved copies to incorporate your changes following the update. The Setup program will not overwrite any files in the mozart directory, stdlist directory, or unison directory that were modified after TWS was installed. If there are any other files you want to protect during the update, copy or rename them now. As an added precaution, you should also backup the entire TWShome directory. You are now ready to run the Setup program. See Installing the Software. 2. Installing the TWS Engine on Windows NT Installing the Software Use the Setup program to install the TWS engine on Windows NT. The Setup Program The Setup program installs or updates TWS. It will perform the following functions: New TWS installation: Install TWS and Netman. Create a components file with new entries. First-time update of TWS version 6.x and earlier: Update TWS and Netman, if necessary. Create a components file with new entries. Subsequent updates of TWS: Update TWS and Netman, if necessary. Update entries in components file. Tivoli Workload Scheduler Planning and Installation Guide 25

40 Installing the Software Running Setup 1. Be sure that you have local administrator privileges on the workstation on which you are about to install TWS. 2. Close any other open Windows applications, including Windows NT Explorer. 3. Insert the TWS CD. 4. Run the TWS Setup program: d:\tivoli\i386\maestro\setup.exe where dis your CD drive letter. 5. The Choose Setup Language window is displayed. Select your setup language and click OK. 26 Version 7.0

41 Installing the Software 6. The Welcome window is displayed. 7. Click Next > on the Welcome window to continue. The Process Warning window is displayed. To continue click Next >. If you are updating TWS, make certain that all TWS processes are stopped, including the Tivoli services. If you uninstalled TWS before running Setup, you must restart your computer before continuing (see Uninstalling TWS on page 43 for details on how to uninstall). To accomplish these tasks, exit Setup by clicking Cancel. 2. Installing the TWS Engine on Windows NT Tivoli Workload Scheduler Planning and Installation Guide 27

42 Installing the Software 8. On the Installation Options window, select the type of installation and click Next >. Copy files and Customize Copy Netman files from the CD and customize the installation. This must be selected for new installations and updates. Customize only Customize existing files. This resets permissions on files back to default permissions. 28 Version 7.0

43 Installing the Software 9. In the Account Infomation window, enter the following information and click Next >: Account The name of the TWS user (usually twsuseror maestro). The software is installed, or updated, in this user s home directory. You can include the domain, if applicable - for example: hqtrs\twsuser. If you omit the domain, Setup looks for a matching account: 1) locally, 2) in the domain, or 3) in a trusted domain. Setup will automatically create the account and home directory, if necessary, and grant the necessary rights. Password The account password. Confirm Password Re-enter the account password. 2. Installing the TWS Engine on Windows NT Note: If you are installing more than one instance of TWS on a computer, note that each installation will attempt to place files in the directory TWShome\..\unison. Make sure that the parent directories are different to avoid conflict. For example, c:\apps\maestro, and c:\apps1\maestro. Tivoli Workload Scheduler Planning and Installation Guide 29

44 Installing the Software 10. Select the destination directory where you want TWS to be installed. If you do not like the default, click Browse to specify a different choice. When you have finished, click Next to proceed. 11. On the Determine Database Expansion window, choose one of the following and click Next >: 30 Version 7.0

45 Installing the Software Expanded Databases (Supports Long Object Names) Use the expanded databases available only in Maestro 6.0 and above. Non-Expanded Databases (Compatible with Maestro 5.x) Use the non-expanded databases. This should be used to install TWS on the master domain manager of a network that contains workstations running a version lower than 6.0, or any version of Maestro for MPE. The databases can be expanded later using the dbexpand command. Refer to the Tivoli Workload Scheduler User s Guide for more information on the dbexpand command. Note: If your network includes MPE workstations, you must use unexpanded mode. MPE workstations cannot be included in expanded TWS networks. 12. On the Configuration Information window, enter the following information and click Next >: 2. Installing the TWS Engine on Windows NT Company Your company s name. This CPU The TWS name of this workstation. For the Tivoli Workload Scheduler Planning and Installation Guide 31

46 Installing the Software non-expanded version of TWS, this can be up to eight alphanumeric, dash (-), or underscore (_) characters starting with a letter. For the expanded version, the length is sixteen characters. This name must be used later to formally define the workstation in TWS. Master CPU The TWS name of the master domain manager. If this is the master domain manager, or a stand-alone workstation, the name is the same as This CPU. For the non-expanded version of TWS, this can be up to eight alphanumeric, dash (-), or underscore (_) characters starting with a letter. For the expanded version, the length is sixteen characters. If you are installing on the master domain manager, Setup creates its workstation definition automatically. Product Group The name of the product group for this installation or update. The default is workstation_user. Note: If Netman is not installed in the product group, you are prompted to install it now. Netman is required in the product group before you can successfully run TWS. If Netman is already installed in the product group, the prompt, and the following Netman Setup steps are skipped. 32 Version 7.0

47 Installing the Software 13. Netman Setup. On the Welcome window, Click Next > to install Netman. Note: If the Welcome window does not appear, use the Windows NT task bar to bring it forward. 14. Netman Setup. On the Installation Options window, select the type of installation and click Next >. 2. Installing the TWS Engine on Windows NT Tivoli Workload Scheduler Planning and Installation Guide 33

48 Installing the Software Copy files and Customize Copy Netman files from the CD and customize the installation. This must be selected for new installations and updates. Customize only Customize existing files. This resets permissions on files back to default permissions. 15. Netman Setup. On the Destination Directory window, select the directory to install Netman and click Next >. The default is: c:\win32app\unison\netman To select a different directory, click Browse and select a directory. If the directory does not exist, you are prompted to have it created. In addition, if the components file does not exist, it is created in this directory. 34 Version 7.0

49 Installing the Software 16. Netman Setup. On the Netman Port window, enter the Netman port number and click Next >. The default is Netman Setup. The Setup Information window summarizes the information Setup will use to install Netman. Click < Back to review or change the information, or click Next > to continue. 2. Installing the TWS Engine on Windows NT After you click Next, a progess indication window displays the installation of the Netman files. Tivoli Workload Scheduler Planning and Installation Guide 35

50 Installing the Software 18. Finally, the Setup Information window summarizes the information Setup will use to install TWS. Click < Back to review or change the information, or click Next > to install or update TWS and exit. 19. You have now finished installing the TWS engine and Netman. The Reboot window prompts you to restart your workstation. 36 Version 7.0

51 Installing the Software Running Netman Setup Separately You can run the Netman Setup program independent of the TWS product to install or update the Netman files. To run the Netman Setup program: 1. Insert the TWS CD. 2. Run the Netman Setup program: d:\maestro\i386\netman\setup.exe Following Installation and Update Perform the following tasks after installing or updating TWS. Completing an Update If this is an update of an existing installation, do the following: 1. On each updated workstation, using the files you protected in Preparing for an Update on page 24 as a reference, apply your changes to the new versions of the files. 2. On the master domain manager, restart TWS. The TWS update process is now complete. Setting the PATH Variable Log in as a user in the Local Administrators group or Domain Administrators group. In the system environment, add the TWShome and TWShome\bin directories to the PATH variable. For example: other_directories;c:\win32app\maestro;c:\win32app\maestro\bin TWS Directories and Services Setup installs TWS files in TWShome, and TWShome\..\unison, which is also used by other Tivoli products. For example, if TWShome is c:\win32app\maestro, then the directory c:\win32app\unison is also created. 2. Installing the TWS Engine on Windows NT Setup also registers the following services with the Service Control Manager: Tivoli MAESTRO for user Tivoli Netman for wkstn_user Tivoli Workload Scheduler Planning and Installation Guide 37

52 Following Installation and Update Tivoli Token Service for user Note that the Service Control Manager maintains its own user password database. Therefore, if the TWSuser password is changed following installation, you must use the Services applet in the Control Panel to assign the new password for the Token Service and Netman. The JOBMON Service The Jobmon service runs in the SYSTEM account with the right Allow Service to Interact with Desktop granted to it. You can remove the right for security reasons. However, this will prevent the service from launching interactive jobs that run in a window on the user s desktop. These jobs are not accessible and do not have access to desktop resources. As a result, they may run forever or abend due to lack of resources. Setting Up Decentralized Administration You can administer TWS scheduling objects from computers other than the TWS master domain manager where the databases exist. If you intend to administer scheduling objects in this manner, you must create shares for the directories in the master domain manager and define a set of local options on the other computers. Sharing the Master Directories Make the following directories shareable on the master domain manager, and set the permissions to give the domain user, TWS or maestro, full control: TWShome\mozart TWShome\..\unison\network Sharing TWS Parameters The TWS substitution parameters are normally computer-specific and administered separately on each computer. If you want the parameters to be common to all computers, and administered from any computer, you can either share the TWShome directory as described above for other directories, or copy the parameters database, each time it changes, from the master domain manager to each of the other computers. The database files are: 38 Version 7.0

53 Following Installation and Update TWShome\parameters TWShome\parameters.KEY Using a Single Share As an alternative to sharing different directories, you can move all of the database files to a common directory, share the directory, and then set the local options, discussed below, to the share name. The database files are listed below. In TWShome\..\unison\ : cpudata cpudata.key userdata userdata.key In TWShome\mozart\ : calendars calendars.key job.sched job.sched.key jobs jobs.key mastsked mastsked.key prompts prompts.key resources resources.key 2. Installing the TWS Engine on Windows NT In TWShome : parameters parameters.key The files are created as needed by TWS. If they do not exist, you can simply set the local options to the shared directory as described below. Setting Local Options To access the shared master databases, set the local options on each of the computers from which you want to administer TWS scheduling objects. The options are described here followed by the procedure for modifying them. Tivoli Workload Scheduler Planning and Installation Guide 39

54 Following Installation and Update Note that each option can be set to a conventional name (drive:\share) or a UNC name (\\node\share). If set to a conventional name, the maestro user must explicitly connect to the share. If set to a UNC name, an explicit connection is not required. The local options are: mozart directory Defines the name of the master s shared mozart directory. unison network directory Defines the name of the master s shared unison directory. parameters directory Defines the name of the master s shared TWShome directory. On each of the computers, set the options as follows: 1. Use an editor of your choice to open and modify the file TWShome\localopts. 2. The options exist as comments in the Tivoli-supplied file. To set an option, remove the # sign in column 1 and change the value to the point to the correct directory. For example, to access all objects except parameters: mozart directory = \\hub\mozart unison network directory = \\hub\unison # parameters directory = d:\maestro 3. Save the file and exit. 4. Stop and restart TWS (including Netman) to make the changes operative. If an option is not set or does not exist, the TWS Composer program attempts to access the database files on the local computer. Setting Local Options on the Master If the database files have been moved from the default directories, as listed above under Using a Single Share, then you must set the local options on the master domain manager to the new location. See Setting Local Options above. 40 Version 7.0

55 Creating the TWS Account Manually Creating the TWS Account Manually New TWS installations require a user account with specific permissions in which to install the software. The setup program creates this user automatically. If you want to create the account manually, follow the steps below. Note: The following procedures require a knowledge of Windows NT account management, including the ability to create accounts, and assign user rights. If you do not possess this knowledge, consult with your Windows NT administrator, or refer to your Microsoft documentation and Windows NT online help. Types of TWS Administration The databases containing the TWS scheduling objects reside on the computer you define as the master domain manager. You can administer the scheduling objects in either of two ways: 1) centralized, from the master domain manager only, or 2) decentralized, from more than one TWS computer. 2. Installing the TWS Engine on Windows NT Choose the appropriate procedure below based on the way you want to administer the TWS scheduling objects. Centralized Administration If you will administer scheduling objects from the master domain manager only, use the following procedure to create the TWS or maestro user. 1. Create a local user account named TWSor maestro on the computer you will use as the TWS master domain manager. Note that this name must be used on all computers in the TWS network, including UNIX computers. Note: You can also use an existing user account. Make sure, however, that this user is in the NT Administratorsgroup. 2. Assign a home directory to the TWS or maestro user. For example: Tivoli Workload Scheduler Planning and Installation Guide 41

56 Creating the TWS Account Manually C:\win32app\maestro Do not specify the root directory of a drive. The TWS software will be installed in this user s home directory. This is referred to in the documentation as TWShome. 3. Grant the TWSor maestro user the following advanced user rights: Act as part of the operating system Increase quotas Log on as batch job Log on as a service Log on locally Replace a process level token You are now ready to run the Setup program. Refer to Installing the Software on page 25. Decentralized Administration If you will administer scheduling objects from more than one TWS computer, in addition to the master domain manager, use the following procedure to create the TWS or maestro user. Note: After installing the software it will be necessary to create shares to permit access to the databases on the master domain manager. This is discussed in Sharing the Master Directories on page Create a domain account named TWS or maestro in the domain of the computer you will use as the TWS master domain manager. Note that this name must also be used on any UNIX computers in the TWS network. Note: You can also use an existing user account. Make sure, however, that this user is in the NT Administratorsgroup. 2. Assign a home directory to the TWS or maestro user. For example: C:\win32app\maestro 42 Version 7.0

57 Creating the TWS Account Manually Do not specify the root directory of a drive. The TWS software will be installed in this user s home directory. This is referred to in the documentation as TWShome. 3. On each computer from which TWS will be managed, grant the TWSor maestro user the following advanced user rights: Uninstalling TWS Act as part of the operating system Increase quotas Log on as batch job Log on as a service Log on locally Replace a process level token You are now ready to run the Setup program. Refer to Installing the Software on page 25. The uninstall programs will remove product files, registry keys, services, and program groups. Note that uninstall will not remove files created after TWS was installed, nor files that are open at the time of uninstall. 2. Installing the TWS Engine on Windows NT You have two ways to uninstall the TWS Engine and Netman from a Windows NT machine: Using the Windows NT Add/Remove tool Using the Uninstall program from a command prompt Both methods are described in the following sections. Using the Windows NT Add/Remove Tool To uninstall TWS, or the Netman service, on Windows NT 4.0, you must be a TWS or maestro user with Windows NT administrator rights. Use the following procedure: 1. Stop TWS and all TWS services. See Unlinking and Stopping TWS on page 24 for details. Tivoli Workload Scheduler Planning and Installation Guide 43

58 Uninstalling TWS 2. From the Control Panel folder, run Add/Remove Programs. 3. On the Install/Uninstall tab, select Tivoli Maestro (User=username) to remove Maestro, or Tivoli Netman (Group=group) to remove the Netman service. 4. Click the Add/Remove button. In the dialog box, click Yes. 5. Exit Add/Remove Programs. 6. Shutdown and restart your computer. This will remove Maestro and Netman services. Note: The uninstall process will not remove some files, folders and registry entries. The files created when the products were installed are removed by uninstalling. However, any files you created or modified since installation are not removed. You may wish to retain these files for use with a later installation of TWS. Uninstalling Netman Netman is a product independent of TWS. Although it can be installed and updated along with TWS, it must be uninstalled separately. To uninstall Netman, DO NOT delete the files. Always use the Add/Remove Program facility in the Windows NT Control Panel. The following files are used by other products, and are not removed when Netman is uninstalled: netmanhome\components netmanhome\bin\ucomp.exe The Uninstal.exe Program The Uninstal program is used to remove an installation of Tivoli Workload Scheduler or the Netman service. It is located in the <maestro home>\setup directory. Syntax Uninstal.exe -V -U Uninstal.exe -p product [-r version] [-l user] [-s ][-g group] 44 Version 7.0

59 Uninstalling TWS Variables Examples -V Display the program patch level. -U Display program usage information. -p The product name: maestro The TWS product. netman The Netman service. -r The product version; for example: l The user account for which the product was installed. This is valid only with -p maestro. -s Run in silent mode. If omitted, the program issues prompts and progress messages. -g The product group. The default group is DEFAULT. This is valid only with -p netman. 1. Remove TWS software: uninstal -p maestro 2. Remove TWS software installed for the user twsuser: uninstal -p maestro -l twsuser 3. Silently remove the Netman installed in the test group: uninstal -p netman -s -g test 2. Installing the TWS Engine on Windows NT Tivoli Workload Scheduler Planning and Installation Guide 45

60 Uninstalling TWS 46 Version 7.0

61 3 Installing the TWS Engine on UNIX This section explains the Tivoli Workload Scheduler installation process for UNIX systems and networks. System Requirements The following are TWS system requirements for UNIX computers. CD-ROM drive for installation. Approximately 120 MB of free disk space for domain managers, and fault-tolerant agents. Approximately 80 MB for standard agents. In addition, TWS produces log files, and temporary files, that are placed on the local hard drive. The amount of space used depends on the number of jobs managed by TWS, and the amount of time you choose to retain log files. 32 MB RAM and 48MB swap space for domain managers, and fault-tolerant agents. Standard agents require less. TWS fault-tolerant agents can, optionally, mount directories from the master domain manager. This requires Network File System (NFS). Consult with your system and network administrators and refer to the Tivoli Workload Scheduler User s Guide for more information. 3. Installing the TWS Engine on UNIX Tivoli Workload Scheduler Planning and Installation Guide 47

62 System Requirements Before continuing, see the Tivoli Workload Scheduler Release Notes for additional information. Installation Procedure Follow these instructions on UNIX computers if you are installing TWS for the first time, or if TWS has been completely uninstalled. For Windows NT computers, refer to Installing the TWS Engine on Windows NT on page 23. Installing the Tivoli Workload Scheduler Engine Perform the following steps to install TWS on a UNIX computer. 1. Create the TWS user. The software is installed in the user s home directory, referred to as twshome. User: maestro Group: tivoli Home: twshome (for example: /opt/maestro) Note: If you are installing more than one instance of TWS on a computer, note that each installation will attempt to place files in the directory twshome/../unison. Make sure that the parent directories are different to avoid conflict. For example, /opt/maestro, and /opt/maestro2. 2. Mount the installation tape or CD, and restore the software. a. Log in as root, and change your directory to twshome. b. Extract the software: tar -xvf cd/tivoli/platform/maestro.tar where: cd The pathname of your CD drive. platform Your platform type. One of the following: 48 Version 7.0

63 Installation Procedure AIX (for IBM) DECUX (for Digital UNIX) DGUX (for Data General UNIX) HPUX (for Hewlett Packard UNIX) INTEL (for Intel-based UNIX) MIPS (for MIPS-based UNIX) SOLARIS (for Sun Solaris) 3. Execute the customize script. For example, a sample customize script for a Master Domain Manager workstation: /bin/sh customize -new -thiscpu mdm -master mdm [other_opts] For example, a sample customize script for an FTA workstation: /bin/sh customize -new -thiscpu dm1-master mdm [options] If you are using an HP-UX 10.x system, your bourne shell may be in the /usr directory. In this case use the following syntax: /usr/bin/sh customize -new -thiscpu mdm -master mdm [other_opts] For more information on the customize arguments and more examples, refer to The Customize Script on page Create a.profile file for the maestro user, if one does not already exist (twshome/.profile). Edit the file and modify the PATH variable to include twshome and twshome/bin. For example: PATH=/bin:/usr/bin:/usr/local/bin:/opt/maestro:/opt/maestro/bin If the PATH statement ends with a period (.), we recommend replacing the period with the above paths, or inserting the paths before the period. If there is no period in the PATH statement, simply add the paths to the end. 3. Installing the TWS Engine on UNIX 5. To start the TWS network management process, Netman, automatically as a daemon each time you boot your system, add one of the following to the /etc/rc file, or the proper file for your system: To start Netman only: Tivoli Workload Scheduler Planning and Installation Guide 49

64 Installation Procedure if [-x twshome/startup] then echo "netman started..." /bin/su - maestro -c " twshome/startup" fi Or, to start the entire TWS process tree: if [-x twshome/bin/conman] then echo "Workload Scheduler started..." /bin/su - maestro -c " twshome/bin/conman start" fi The TWS installation process is now complete. Configuration Steps For UNIX installations execute the following configuration tasks. These tasks must be executed from the TWS Composer and Conman command line interfaces. Once you have configured the Master Domain Manager in this way you can use the Job Scheduling Console to configure the other workstations, and job scheduling objects in your TWS network. Refer to the Tivoli Workload Scheduler Reference Guide for details on the commands used below. Refer to the Tivoli Workload Scheduler User s Guide for information on using the Job Scheduling Console to configure other workstations in the network. Configuring a Master Domain Manager After Installation 1. Login to the Master Domain Manager workstation as maestro. This is the tws_user ID variable, which defaults on UNIX to maestro. The UNIX tws_user ID can be modified using the -uconfig argument. 2. Create the Master Domain Manager workstation definition in TWS database by using the TWS composer command line. Open a command line window in UNIX and enter the following commands: composer new 50 Version 7.0

65 Installation Procedure 3. This opens a text editor where you can create the Master Domain Manager workstation definition in the TWS database. Below is an example workstation definition for a Master Domain Manager. For more information on workstation defintions, refer to the Tivoli Workload Scheduler Reference Manual. cpuname MDM os UNIX node master.santaclara.tivoli.com description "Master Domain Manager" for Maestro autolink on resolvedep on fullstatus on end 4. Create a new Symphony file that includes the Master Domian Manager workstation definition. To do this add the final job stream to production cycle. This job stream contains the Jnextday job which automates the creation of the Symphony file. composer add Sfinal 5. Startup the TWS processes. conman start 6. Run the Jnextday job: Jnextday 7. When the Jnextday job completes, check the status of TWS: conman status If TWS started correctly the status should be Batchman=LIVES. 8. Raise the limit to allow jobs to execute. The default job limit after installation is set to zero. This means no jobs will execute, so you may want to raise the job limit now: conman limit;10 3. Installing the TWS Engine on UNIX You can now begin defining additional scheduling objects in the CLI, including workstations, jobs and job streams or you can Tivoli Workload Scheduler Planning and Installation Guide 51

66 Installation Procedure continue to install the Job Scheduling Console, and the connector. Note that new objects are not recognized until the Jnextday job runs in the final job stream. By default, the final job stream runs at 5:59am (you can change this default; see Changing the Start of Day on page 117 for details). If you want to incorporate new scheduling objects sooner, you can run Jnextday manually as in step 6 above or use the conman submit command. For information about defining your scheduling objects, refer to the Tivoli Workload Scheduler User s Guide. Configuring a Fault Tolerant Agent After Installation 1. Login to the FTA workstation as maestro. This is the tws_user ID variable, which defaults on UNIX to maestro. The UNIX tws_user ID can be modified using the -uconfig argument. 2. Create the FTA workstation definition in TWS database by using the TWS composer command line. Open a command line window in UNIX and enter the following commands: composer new 3. This opens a text editor where you can create the FTA workstation definition in the TWS database. Below is an example workstation definition for a FTA. For more information on workstation defintions, refer to the Tivoli Workload Scheduler Reference Manual. cpuname DM1 os UNIX node domain1.santaclara.tivoli.com description "Domain Manager" for Maestro autolink on end 4. Run the StartUp command to start Netman. conman StartUp 5. Create a new Symphony file that includes the FTA workstation definition. To do this run the Jnextday job on the Master Domain Manager which automates the creation of a new Symphony file: 52 Version 7.0

67 Jnextday 6. Issue the link command from the Master Domain Manager to link the FTA and to download the Symphony file to it: conman link ftaname Updating Tivoli Workload Scheduler Installation Procedure Use this procedure to update existing TWS installations on UNIX computers. The recommended sequence for updating a TWS network is to update all agent workstations first, and then update the master domain manager. Note: Be sure to read the Tivoli Workload Scheduler Release Notes for additional information about updating existing software. The update topics below are presented in the sequence they should be performed. Preparation-Stop TWS Backup 1. From the Job Scheduling Console, unlink the target workstation from the other workstations in the network. Otherwise, from the command line use the following command: conman "unlink workstationname;noask" 2. From the Job Scheduling Console, stop and shutdown the target workstation. From the command line, use the following commands: conman shut;wait 3. If you are updating an agent, remove (umount) any NFS mounted directories from the master domain manager. TWS s customize script will move your working copies of Sfinal, Jnextday, NetConf and StartUp to a directory named twshome/config.old. These files are often customized to meet your specific needs, and you can use the saved copies to incorporate your changes following the update. The customize script will not overwrite any files in the mozart directory, stdlist directory, or unison directory that were modified after TWS was installed. 3. Installing the TWS Engine on UNIX Tivoli Workload Scheduler Planning and Installation Guide 53

68 Updating Tivoli Workload Scheduler If there are any other files you want to protect during the update, copy or rename them now. As an added precaution, you should also backup the following: The twshome directory. The Netman home directory (twshome/../unison) The components file (generally, /usr/unison/components) Update Software and Run Customize 1. Mount the installation tape or CD, and restore the software. a. Log in as root, and change your directory to twshome. b. Extract the software: tar xvf cd/tivoli/platform/maestro.tar where: cd The pathname of your CD drive. platform Your platform type. One of the following: AIX (for IBM) DECUX (for Digital UNIX) HPUX (for Hewlett Packard UNIX) INTEL (for Intel ABI-based UNIX) MIPS (for MIPS ABI-based UNIX) SOLARIS (for Sun Solaris) 2. Execute the customize script. For example, a sample customize script for a Master Domain Manager workstation: /bin/sh customize -update -thiscpu mdm [other_opts] For example, a sample customize script for an FTA workstation: /bin/sh customize -update -thiscpu dm1[options] 54 Version 7.0

69 Updating Tivoli Workload Scheduler If you are using an HP-UX 10.x system, your bourne shell may be in the /usr directory. In this case use the following syntax: /usr/bin/sh customize -update -thiscpu mdm [other_opts] For more information on the customize arguments and more examples, refer to The Customize Script on page 57. Update Security Profile For migration from 6.0 to 7.0 an additional Maestro User definition must be added to the security file. The tme_region_administrator ID must be added to the security file. 1. Login as Maestro. 2. Execute the dumpsec command to create a temporary editable copy of the security file: dumpsec >tempsec 3. Edit the security file. Under the section USER MAESTRO add the TME Region administrator ID: USER MAESTRO root, maestro, administrator, tme_region_admin 4. Execute the makesec command to compile the temporary file into a new security file: makesec tempsec For more information on Makesec and Dumpsec commands refer to the Tivoli Workload Scheduler User s Guide. Restore Your Files Using the files you protected as a reference, apply your changes to the new versions of the files. Restart TWS To restart Tivoli Workload Scheduler: 1. Log in as TWSor maestro user. 2. Run the start command: conman start 3. Run the linkcommand: 3. Installing the TWS Engine on UNIX Tivoli Workload Scheduler Planning and Installation Guide 55

70 Updating Tivoli Workload Scheduler For a Master Domain Manager: conman For an FTA workstation: conman link domainname The software update is now complete on this workstation. 56 Version 7.0

71 The Customize Script The Customize Script Use the customize script to install and update Tivoli Workload Scheduler on UNIX platforms. Synopsis customize -new -thiscpu wkstationname -masterwkstationname [-company companyname ] [-group groupname] [-nmhome netmanhome] [-noexp] [-nolinks -execpath pathname] [-unameusername] customize -update[-company companyname ] [-group groupname] [-nmhome netmanhome] [-unameusername] Description The customize script installs or updates TWS. Use it to perform the following functions: New TWS installation: Install TWS and Netman. Create a components file with new entries. First-time update of pre-7.0 TWS: Update TWS and Netman, if necessary. Create a components file with new entries. Subsequent updates of TWS: Update TWS and Netman, if necessary. Update entries in components file. Use it also to reset permissions to their default values provided that the original MAESTRO.TAR file is not in the twshome directory. Arguments -new This is a new installation. -update This is an update of an existing installation. Note that updating the software will not change the type of databases in use by TWS. -thiscpu The name of this workstation. For the non-expanded version of TWS, the name can be up to eight alphanumeric, dash (-), 3. Installing the TWS Engine on UNIX Tivoli Workload Scheduler Planning and Installation Guide 57

72 The Customize Script or underscore (_) characters starting with a letter. For the expanded version, the length is sixteen characters. This name must be used later to formally define the workstation in TWS. -master The name of the master domain manager. For the non-expanded version of TWS, the name can be up to eight alphanumeric, dash (-), or underscore (_) characters starting with a letter. For the expanded version, the length is sixteen characters. If this computer is the master domain manager, or a stand-alone workstation, enter the same name as -thiscpu. This name must be used later to formally define the workstation in TWS. -company The name of the company, enclosed in double quotation marks (up to 40 characters). The name appears in program headers and reports. -group The name of the product group in which you want to install or update TWS. This can contain up to 36 characters, starting with a letter. If omitted for a new installation or a first-time update of an earlier version of TWS, the name defaults to DEFAULT. If included for an update, other than a first-time update of an earlier version of TWS, this name is overridden with the group from the components file, using the home directory of the user as a reference. For more information, see Product Groups on page 20. -nmhome The Netman home directory. If omitted, Netman is installed in TWS s home directory (twshome). See Netman s Home Directory on page 21 for more information. For updates, this option is useful only for first-time updates of pre-6.0 versions of TWS. In subsequent updates, it is ignored. -noexp Use the non-expanded databases. This sets the global option expanded version to no and creates the non-expanded 58 Version 7.0

73 The Customize Script databases. Since earlier versions do not support expanded databases, use this keyword when you install TWS 7.0 in a network that contains computers running a TWS version earlier than 6.0, or any version of TWS for MPE. After all computers in the network have installed TWS 6.0 or later, the databases can be expanded by running the dbexpand command on the master domain manager. Refer to the dbexpand command in the Tivoli Workload Scheduler Reference Guide for more information. If omitted, the global option expanded version is set to yes and expanded databases are created. [-nolinks -execpath pathname] The link option determines the path customize uses to create links to TWS s utility commands. If you include -nolinks, no links are created. If you include -execpath, links are created from the specified path. If linkopt is omitted altogether, links are created as follows: usr/bin/mat usr/bin/mbatch usr/bin/datecalc usr/bin/jobstdl usr/bin/maestro usr/bin/mdemon usr/bin/morestdl usr/bin/muser usr/bin/parms twshome/bin/at twshome/bin/batch twshome/bin/datecalc twshome/bin/jobstdl twshome/bin/maestro twshome/bin/mdemon twshome/bin/morestdl twshome/bin/muser twshome/bin/parms -uname The name of the user for whom TWS will be installed or updated. The software is installed or updated in this user s home directory. If omitted, the default user name is maestro. 3. Installing the TWS Engine on UNIX Tivoli Workload Scheduler Planning and Installation Guide 59

74 Uninstalling TWS Uninstalling TWS Follow these steps to uninstall TWS from a UNIX system: 1. Before uninstalling TWS, kill any existing TWS Connector instances that were created on this particular UNIX system. 2. On the UNIX system, login as root. 3. Backup any TWS database files that you want to use again. The TWS database files are stored in the TWS user home directory and are the following: /parameters /parameters.key /mozart/calendars /mozart/calendars.key /mozart/jobs /mozart/jobs.key /mozart/mastsked /mozart/mastsked.key /mozart/prompts /mozart/prompts.key /mozart/resources /mozart/resources.key /../unison/network/cpudata /../unison/network/cpudata.key /../unison/network/userdata /../unison/network/userdata.key Note: The job.sched database is automatically rebuilt. You do not need to save it. 4. Review the contents of the file named /usr/unison/components. If the file contains multiple entries that correspond to different Maestro/TWS accounts (product groups), edit the file by deleting the lines that correspond to the instance you want to remove. For example, suppose that /usr/unison/components contains the following entries: netman 1.5 /opt/maestro DEFAULT maestro 7.0 /opt/maestro DEFAULT netman 1.3 /home/maestro dev_test 60 Version 7.0

75 Uninstalling TWS maestro 6.1/home/maestro dev_test If you plan to remove the TWS instance located under /home/maestro, then delete the last two lines. If /usr/unison/components contains only the instance that you want to remove, then delete the entire file. 5. Remove the links, if applicable, to the /usr/bin directory. The TWS installation process gives you the option to link TWS executables to a common directory. The default is /usr/bin. Remove the following files: /usr/bin/maestro /usr/bin/mat /usr/bin/mbatch /usr/bin/datecalc /usr/bin/morestdl /usr/bin/jobstdl /usr/bin/parms 6. Finally, remove the entire Maestro/TWS account with the following commands: rm -rf <twshome>/../unison rm -rf <twshome> If your system startup command was modified to include a conman start or a <twshome>/startup command, you must also remove those entries. 3. Installing the TWS Engine on UNIX Tivoli Workload Scheduler Planning and Installation Guide 61

76 Uninstalling TWS 62 Version 7.0

77 4 Setting TWS Security 4. Setting TWS Security After you install the TWS engine and before you proceed to install the JS Console, you must set TWS security. Each workstation in a Workload Scheduler network (domain managers, fault-tolerant agents and standard agents) has its own Security file. The Security file contains one or more user definitions. Each user definition identifies a set of users, the objects they are permitted to access, and the types of actions they can perform. Workload Scheduler programs and commands determine a user s capabilities by comparing the user s name with the user definitions in the Security file. You can maintain a file on each workstation, or you can create a Security file on the master domain manager and copy it to each domain manager, fault-tolerant agent, and standard agent. A template file named TWShome/config/Security is provided with the software. During installation, a copy of the template is installed as TWShome/Security and a compiled, operational copy is installed as TWShome/../unison/Security. To set TWS security: 1. Create user definitions. Provided that the default user definition is enough to fit your requirements, you are nevertheless asked to at least add a user definition for the Tivoli Management Tivoli Workload Scheduler Planning and Installation Guide 63

78 Setting TWS Security Framework administrator on the master or FTA running the TWS Connector. To do this, edit the Security file. It is recommended that you create a working copy of the Security file every time you add a new user definition. Do not modify the original template in TWShome or in TWShome/config. To create a user definition: a. Use the dumpsec command to create an editable copy of the operational Security file: dumpsec>mysec b. Edit mysec to add, delete, or modify user definitions. 2. Use the makesec command to compile and install the new operational Security file: makesec mysec Use dumpsec and makesec every time you want to modify the Security file. Changes to the Security file take effect when one of the following Workload Scheduler programs is stopped and restarted: conman gconman composer gcomposer TWS Connector Simply exit the programs. The next time they are run, the new security definitions will be recognized. For TWS Connectors, use the wmaeutil command to stop them. They will be automatically restarted with a refresh of any query in the Job Scheduling Console. Editing the Security File The default Security template installed on your machine grants every right to every object to the user under which TWS was installed and to the UNIX root or NT administrator user. You will want to edit the Security file to add new users with less rights. When editing the Security file, keep the following facts in mind: 64 Version 7.0

79 Editing the Security File In qualifying users to access Workload Scheduler objects, a user s actual attributes are compared to user definitions in the order the definitions are entered in the Security file. The first definition that matches the user determines the user s capabilities. For this reason, it is important to order user definitions from most specific to least specific. In a user definition, you can use multiple statements for a single object type to assign different access capabilities to different sets of objects. Because the first matching statement is used, the order of object statements is important. They must be ordered from most specific to least specific. The user definition of the Security file created by the TWS installation process grants full access to all scheduling objects. When you add new user definitions, it is easier if you copy this user definition to the appropriate location in the Security file. Then, you can modify the name of the definition and the user attributes, and finally you can customize or remove the scheduling objects. 4. Setting TWS Security The syntax of the Security file is the following: # comment] user def-name user-attributes begin [* comment] object-type [object-attributes] access[=action[,...]] [object-type... ] [end] The customization steps below are listed on a general basis. Refer to the TWS User s Guide for an example and details of Security file variables. 1. Optionally, at the top of the file, enter a comment after a pound sign (#) or asterisk (*). Comments are not copied into the operational Security file installed by the makesec command. 2. After the keyword user, specify the name of the user definition. It must start with a letter. Tivoli Workload Scheduler Planning and Installation Guide 65

80 Editing the Security File 3. Specify one or more attributes that identify the set of users to whom the definition applies. Specify user attributes as follows: user-attribute[{+ x}user-attribute[...]] Use a plus sign (+) to add an attribute the user or users must have. Use a tilde (x) to add an attribute the user or users must not have. A user-attribute can be one of the following: cpu=workstation [,...] where: workstation Specifies the workstation or workstation class on which the user is logged in. Use one of the following Tivoli Workload Scheduler variables: $master The user is logged in on the TWS master domain manager. $remotes The user is logged in on any TWS standard agent. $slaves The user is logged in on any TWS fault-tolerant agent. $thiscpu The user is logged in on the TWS workstation on which the secured program is running. $framework Specifies that the user is accessing TWS with the Tivoli Job Scheduling Console. The logon= attribute specifies the TME administrators group in which the user is a Specifies that the user is accessing Tivoli Workload Scheduler with the Tivoli Job 66 Version 7.0

81 Editing the Security File Scheduling Console or is logged in on any Tivoli Workload Scheduler workstation. group=groupname[,...] Apply this to UNIX users only. Do not use this argument for Tivoli Job Scheduling Console users. It specifies the UNIX group in which the user is a member. logon=username [,...] where: username Specifies the name with which the user is logged in on a TWS workstation.the cpu= attribute must be set to a workstation name tme-admin Specifies the name of the TME administrators group in which the user is a member. The cpu= attribute must be set to Specifies that the user is logged in with any name or is a member of any TME administrators group. 4. Between the begin and the end keywords, enter a list of the object types to which the users specified in user are given permission to access. Omitting an object type prevents access to all objects of that type. The object types are: calendar User calendars. cpu Workstations, domains, and workstation classes. file Workload Scheduler database files. job Scheduled jobs. parameter User parameters. prompt Global prompts. resource Scheduling resources. schedule Job streams. 4. Setting TWS Security Tivoli Workload Scheduler Planning and Installation Guide 67

82 Editing the Security File userobj User objects. 5. Specify one or more attributes identifying each of the objects you listed in the previous step. When no attributes are specified, all objects that belong to that particular type are accessible. Specify object attributes as follows: object-attribute[{+ x}object-attribute[...]] Use a plus sign (+) to add an attribute objects must have. Use a tilde (x) to add an attribute objects must not have. You can use wildcard characters. When you enter multiple names for an attribute, separate them by commas. An object-attribute can be any of the following: For the object type calendar: name=calendar-name[,...] Specifies one or more calendar names. If omitted, all calendars qualify. For the object type cpu (workstation): cpu=wkstation[,...] Specifies one or more workstation, domain, or workstation class names. If omitted, all workstations qualify. The following Tivoli Workload Scheduler variables are permitted: $master, $remotes, $slaves, and $thiscpu. For the object type file: name=filename[,...] Specifies the names of Workload Scheduler database files. If omitted, all files qualify. The file names are as follows: calendars Contains calendars. cpudata Contains workstation, workstation classes, and domains. jobs Contains jobs. 68 Version 7.0

83 Editing the Security File mastsked Contains job streams. parameters Contains parameters. prodsked Contains the production schedule. prompts Contains prompts. resources Contains resources. security The Security file. Symphony Contains the production plan. For the object type job: cpu=wkstation Specifies the name of the workstation or workstation class on which the job runs. If omitted, all workstations qualify. The following Tivoli Workload Scheduler variables are permitted: $master, $remotes, $slaves, and $thiscpu. jcl= path cmd Specifies the command or the path name of the job s executable file. The command or path must be enclosed in single quotes ( ). If omitted, all job files and commands qualify. logon=username[,...] Specifies the user names under which the jobs run. If omitted, all user names qualify. The following Tivoli Workload Scheduler variables are permitted: $jclowner, $owner, and $user. name=[jobstream.]job[,...] Specifies the Workload Scheduler job name. The job s job stream name is optional. If omitted, all job names qualify. For the object type parameter: 4. Setting TWS Security Tivoli Workload Scheduler Planning and Installation Guide 69

84 Editing the Security File cpu=wkstation Specifies the name of the workstation on which the parameters are defined. If omitted, all workstations qualify. The following Tivoli Workload Scheduler variables are permitted: $master, $remotes, $slaves, and $thiscpu. name=parameter[,...] Specifies one or more parameter names. If omitted, all parameters qualify. For the object type prompt: name=prompt[,...] Specifies one or more prompt names. If omitted, all prompts qualify. For the object type resource: cpu=wkstation[,...] Specifies the name of the workstation or workstation class on which the resources are defined. If omitted, all workstations qualify. The following Tivoli Workload Scheduler variables are permitted: $master, $remotes, $slaves, and $thiscpu. name=resource[,...] Specifies one or more resource names. If omitted, all resources qualify. For the object type schedule (job stream): cpu=wkstation Specifies the name of the workstation or workstation class on which the job streams run. If omitted, all workstations qualify. The following Tivoli Workload Scheduler variables are permitted: $master, $remotes, $slaves, and $thiscpu. name=jobstream[,...] Specifies one or more job stream names. If omitted, all job streams qualify. For the object type userobj: 70 Version 7.0

85 Editing the Security File cpu=wkstation Specifies the name of the workstation on which the user is defined. If omitted, all workstations qualify. The following Tivoli Workload Scheduler variables are permitted: $master, $remotes, $slaves, and $thiscpu. logon=username[,...] Specifies one or more user names. If omitted, all users qualify. 6. Specify what actions the users you defined in steps 2 and 3 can perform on the objects you listed in steps 4 and 5. Multiple actions must be separated by commas. If none are specified, no actions are permitted. Entering access=@, gives users the ability to perform all actions. The actions can be: For the object type calendar: add Add and save new calendars in the database. delete Delete calendars from the database. display Display calendars in the database. modify Modify calendars in the database. use Use calendars to schedule job streams. For the object type cpu, which includes workstations, workstation classes, and domains: add Add and save new workstations, workstation classes, and domains in the database. console View and alter the Workload Scheduler console. delete Delete workstations, workstation classes, and domains from the database. display Display workstations, workstation classes, and domains in the database. 4. Setting TWS Security Tivoli Workload Scheduler Planning and Installation Guide 71

86 Editing the Security File fence Alter workstation job fences in the production plan. limit Alter workstation job limits in the production plan. link Open workstation links. modify Modify and workstations, workstation classes, and domains in the database. shutdown Shutdown Workload Scheduler processing. This action is only available in the command line. start Start Workload Scheduler processing. stop Stop Workload Scheduler processing. unlink Close workstation links. To permit a user to switch the domain manager function to a workstation, the user must have both start and stop access to the workstation. For the object type file: build Build Workload Scheduler s database files. This action is only available in the command line. delete Not yet implemented. display Access the Security file with the dumpsec command. modify Access the Security file with the makesec command. Also modify the calendars, parameters, prompts, and resources master files. These actions are only available in the command line. For the object type job: add Add and save new jobs in the database. adddep Add dependencies to jobs in the production plan. 72 Version 7.0

87 Editing the Security File altpri Alter the priority of jobs in the production plan. cancel Cancel jobs in the production plan. confirm Confirm the completion of jobs in the production plan. deldep Delete dependencies from jobs in the production plan. delete Delete jobs from the database. display Display jobs in the database. kill Kill jobs in the production plan. modify Modify jobs in the database. release Release jobs from their dependencies in the production plan. reply Reply to job prompts in the production plan. rerun Rerun jobs in the production plan. submit Submit jobs into the production plan. use Add jobs to job streams in the database. For the object type parameter: add Add and save new parameters in the database. delete Delete parameters from the database. display Display parameters in the database. modify Modify and replace parameters in the database. For the object type prompt: 4. Setting TWS Security Tivoli Workload Scheduler Planning and Installation Guide 73

88 Editing the Security File add Add and save new prompts in the database. delete Delete prompts from the database. display Display prompts in the database. modify Modify and replace prompts in the database. use Add prompts to job streams in the database and add prompts to jobs and job streams in the production plan. For the object type resource: add Add and save new resources in the database. delete Delete resources from the database. display Display resources in the database. modify Modify and replace resources in the database. use Add resources to job streams in the database and add resources to jobs and job streams in the production plan. For the object type schedule (job stream): add Add and save new job streams in the database. adddep Add dependencies to job streams in the production plan. altpri Alter the priority of job streams in the production plan. cancel Cancel job streams in the production plan. deldep Delete dependencies from job streams in the production plan. delete Delete job streams from the database. 74 Version 7.0

89 Editing the Security File display Display job streams in the database. limit Alter the job limit of job streams in the production plan. modify Modify job streams in the database. release Release job streams from their dependencies in the production plan. reply Reply to job stream prompts in the production plan. submit Submit job streams into the production plan. For the object type userobj: add Add new users in the database. delete Delete users from the database. display Display users in the database. modify Modify and replace users in the database. altpass Alter user passwords in the database. 7. Depending on your requirements, repeat the steps above to define as many users as necessary, the objects they can use, and the type of access. 4. Setting TWS Security Note: Remember to update the security file to add the Tivoli Administrator, after you have installed the Tivoli Management Framework and TWS Connector. See Updating TWS Security on page 94 for details. Tivoli Workload Scheduler Planning and Installation Guide 75

90 Editing the Security File 76 Version 7.0

91 5 Installing the TWS Connector Prior to Installation This chapter describes how to install the TWS Connector. Read this information before proceeding with the TWS Connector Installation. The TWS Connector requires the Job Scheduling Services (JSS) to be installed into your Tivoli environment. 5. Installing the TWS Connector The TWS Connector installation and customization will vary depending on whether your TWS Master is on a TMR Server or on a Managed Node. When the TWS Master is on a TMR Server, you must install both the JSS and the TWS Connector on the TMR Server of your environment. You must also create a TWS Connector instance for the TMR Server. This can be done during installation by using the Create Instance checkbox and filling in the required fields. When the TWS Master is on a Managed Node, you must install JSS on TMR Server and on the Managed Node where the Master is located. You must then install the TWS Connector on the TMR Server and on the same Nodes where you installed JSS. Make sure not to check the Create Instance checkbox. If you have more than one Node where you want to install the Connector (for example, if you want to access the local data of Tivoli Workload Scheduler Planning and Installation Guide 77

92 Prior to Installation an FTA through the Job Scheduling Console), you can install the connector on multiple machines. However, in this case you should deselect the Create Instance checkbox, because each instance must have a unique name in the TWS network. After you have installed the connector on the workstations in your network, you can proceed with the creation of a TWS connector instances on the machines you need to access TWS through the Job Scheduling Console. Each TWS connector instance name must be unique within the TWS Network, so you must create each instance separately. We suggest you use the name of the TWS agent as the instance name. TWS FTAs that need to be accessed through the Job Scheduling Console in order to check local data, must have JSS and a TWS Connector installed, plus a unique TWS connector instance for every TWS installation you need to access through the Job Scheduling Console. Note: Each TWS Connector Instance name must be unique within your TWS Network. System Requirements The TWS Connector has the following system requirements: Tivoli Management Framework, Version or later Tivoli Workload Scheduler 7.0 Base Engine CD-ROM drive for installation. Approximately 100 MB of free disk space for domain managers, and fault-tolerant agents. Approximately 40 MB for standard agents. In addition, TWS produces log files, and temporary files, that are placed on the local hard drive. The amount of space required depends on the number of jobs managed by TWS, and the amount of time you choose to retain log files. 128 MB RAM and 128 MB swap space for domain managers and fault-tolerant agents. Standard agents require less. TCP/IP network communications. 78 Version 7.0

93 System Requirements A TWS user account is required for proper installation. You can create the account beforehand, or have the Setup program create it for you. Supported Platforms The TWS Connector is available for the following operating systems: Microsoft Windows NT Version 4.0 with Service Pack 4 or later AIX or 4.3 Sun Solaris 2.6 or 2.7 HP-UX 10.x or 11.0 Installation Procedure The installation of the TWS Connector is divided into three sections: Install the Job Scheduling Services (JSS). Skip this step if you already have the JSS installed on your Tivoli Management Framework. Note that the JSS must be installed before the connector and that it must be installed on the TMR Server. Install TWS Connector. The TWS Connector must be installed on the TMR Server. Create the TWS Connector Instance. There must be one instance for every TWS Engine you want to access through the Job Scheduling Console. The TWS connector instance name must be unique within the TWS Network. You can perform the installation in the Tivoli Desktop or from a command line shell with Tivoli environment variables configured. Installing the Job Scheduling Services (JSS) To install the JSS, you can use the Tivoli Desktop or the command line. Both of the procedures are described here. 5. Installing the TWS Connector Tivoli Workload Scheduler Planning and Installation Guide 79

94 Installation Procedure Where to Install Install JSS Services on the TMR Server and on each managed node where the TWS Connector will be installed. Installing JSS Using the Tivoli Desktop 1. Login as root or administrator. 2. Set the Tivoli environment, From a UNIX command line:./etc/tivoli/setup_env.sh From a Windows NT command line: %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 3. Open the Tivoli Desktop. 4. From the Desktop menu choose Install-> Install Product. This opens the Install Product window. Note: An error window may be displayed stating that the path to the installation files is wrong. Ignore this window. 80 Version 7.0

95 Close it and proceed to the next step. Installation Procedure 5. Installing the TWS Connector 5. Click the Select Media... button to select the path or directory containing the CONTENTS.LST file. This opens the File Tivoli Workload Scheduler Planning and Installation Guide 81

96 Installation Procedure Browser window. 82 Version 7.0

97 Installation Procedure 6. Click the Set Media & Close button. This returns to the Install Product window. 5. Installing the TWS Connector 7. In the Select Product To Install list, select Tivoli Job Scheduling Services. 8. In the Available Clients list, select the nodes to install on and move them to the Clients to Install On list. You must install JSS on the Tivoli Management server. You will be able to install the TWS Connector only on managed nodes on which the JSS is installed. Tivoli Workload Scheduler Planning and Installation Guide 83

98 Installation Procedure 9. Click the Install & Close button. The Product Install window opens. 10. The Product Install window shows you the progress of the installation. Click the Continue Install button to continue the installation or click the Cancel button to cancel the installation. 11. When the message Finished product installation appears, click the Close button. Installing JSS Using the Command Line 1. Set the Tivoli environment, From a UNIX command line:./etc/tivoli/setup_env.sh From a Windows NT command line: %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 2. Do one of the following: To install on all managed nodes: 84 Version 7.0

99 Installation Procedure winstall -c installdir -i TMF_JSS To install on only one managed node: winstall -c installdir -I TMF_JSS node where install-dir is the pathname containing the installation images files and node is the name of the managed node on which to perform the installation. Installing the TWS Connector To install the TWS connector, you can use the Tivoli desktop or the command line. Both of the procedures are described here. Note: If you want to re-install the TWS Connector, you must uninstall the existing one before you do. See Uninstalling the TWS Connector on page 95 for reference. Where to Install Install the TWS Connector on the TMR Server and on the managed Node where the TWS Master is installed. 5. Installing the TWS Connector You can also install the connector on an FTA, if you want to access local data on the FTA from the Job Scheduling Console. Installing the TWS Connector Using the Tivoli Desktop 1. Login as root or administrator. 2. Set the Tivoli environment, From a UNIX command line:./etc/tivoli/setup_env.sh From a Windows NT command line: %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 3. Open the Tivoli Desktop. Tivoli Workload Scheduler Planning and Installation Guide 85

100 Installation Procedure 4. From the Desktop menu choose Install-> Install Product. This opens the Install Product window. 5. Click the Select Media... button to select the directory containing the CONTENTS.LST file. This opens the File 86 Version 7.0

101 Installation Procedure Browser window. 5. Installing the TWS Connector Tivoli Workload Scheduler Planning and Installation Guide 87

102 Installation Procedure 6. Click the Set Media & Close button. This returns to the Install Product window. 7. In the Select Product To Install list, select Tivoli TWS Connector. The Install Options window is displayed. 8. This panel enables you to: Install the TWS Connector only. Install the TWS connector and create a TWS Connector Instance 88 Version 7.0

103 Installation Procedure 9. To install the TWS Connector without creating a TWS Connector Instance, leave the Create Instance checkbox unchecked and leave the General Installation Options fields blank. These fields are only used during the creation of the TWS Connector Instance. 10. To install the TWS Connector and create a TWS Connector Instance: a. Select the Create Instance checkbox. b. In the TWS Directory field, specify the directory where TWS is installed. c. In the TWS instance name field, specify a name for the TWS instance on the managed node. 5. Installing the TWS Connector Note: This name must be unique in the TWS network. If you decide not to create the Instance at this time, you can create it later by using the wtwsconn utility from command line. Refer to Creating TWS Connector Instances using command line. Creating the TWS connector instance later is recommended when installing the TWS Connector on multiple Nodes, since you can perform the installation simultaneously on all the Nodes while creating the instance locally using wtwsconn. 11. Click the Set button, to close this window and go back to the Install Product panel. Tivoli Workload Scheduler Planning and Installation Guide 89

104 Installation Procedure 12. In the Available Clients list, select the nodes to install on and move them to the Clients to Install On list. You must install TWS Connector on at least the Tivoli management server. You can only install the TWS Connector on managed nodes on which the JSS is installed. Note: If you choose to create a TWS Connector Instance during the installation, you must select just one Node from the list, since the Instance name must be unique within the TWS Network. 13. In the Install Product window, click the Install & Close button. The Product Install window opens. 14. The Product Install window shows you the progress of the installation. Click the Continue Install button to continue the installation or click the Cancel button to cancel the installation. 15. When the message Finished product installation appears, click the Close button. 90 Version 7.0

105 Installation Procedure Installing the TWS Connector Using the Command Line 1. Login as root or administrator. 2. Set the Tivoli environment, From a UNIX command line:./etc/tivoli/setup_env.sh From a Windows NT command line: %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 3. Enter the following string on a single line as one command: To install on all managed nodes: winstall -c install-dir -i TWS_CONN twsdir=/users/maestro iname=maestro owner=maestro To install on only one managed node: winstall -c installdir -I TWS_CONN node twsdir=/users/maestro iname=maestro owner=maestro createinst=1 where installdir is the pathname containing the installation images files and node is the name of the managed node on which to perform the installation. 5. Installing the TWS Connector Creating TWS Connector Instances Using the Command Line Create a TWS Connector instance for each TWS engine that you want to access with the JS Console. To create TWS Connector instances, you must be a Tivoli administrator with admin, senior, or super authorization roles. For more information refer to Authorization Roles below. To create an instance, enter the following command on the TMR server or managed node where you installed the TWS Connector that you need to access through the JS Console: wtwsconn -create -h [node] -n [instance_name] -t [TWS_directory] where: Tivoli Workload Scheduler Planning and Installation Guide 91

106 Installation Procedure -h node Specifies the node where the instance is created. If not specified it defaults to the node where the script file is executed. -n instance The name of the new instance. This name will identify the TWS engine node in the Job Scheduling tree of the JS Console. Note that this name must be unique within TWS Network. -t twsdir Specifies the value for the TWSdir attribute. This is the TWS installation directory on the specified node. Authorization Roles Required for Instances To manage TWS connector instances from a TMR server or managed node, you must be a Tivoli administrator. Each Tivoli administrator has one or more roles. To use or manage TWS connector instances, you need the following roles: user To use the instances. To view instance settings. admin, senior, orsuper To perform all actions available to the user role. To create and remove instances. To change instance settings. To start and stop instances. Managing TWS Connector Instances Use the wtwsconn utility to create, remove, and manage TWS connector instances. This program is downloaded when you install the TWS Connector. The following table describes how to use wtwsconn in the command line to manage TWS Connector instances. 92 Version 7.0

107 Installation Procedure Action Create an instance Stop an instance Syntax wtwsconn.sh -create [-h node] -ninstance -t twsdir wtwsconn.sh -stop -n instance -ttwsdir Two stop actions are supported. When -n instance is specified, the instance with that name is stopped. Remove an instance View the settings of an instance. Change the settings of an instance where: node When -t twsdir is specified, all the instances on this node (the node where script is executed) whose TWSdir attribute matches twsdir are stopped. wtwsconn.sh -remove -n instance wtwsconn.sh -view -n instance wtwsconn.sh -set -n instance -t twsdir Specifies the node where instance is created. If not specified it defaults to the node where script is executed from. instance The name of the new instance. This name will identify the TWS engine of node in the Job Scheduling tree of the JS Console. Note:this name must be unique within TWS Network twsdir Specifies the value for the TWS dir attribute. This is the TWS installation directory in node. Installing JSS and TWS Connector Patches To install patches: 1. Login as root or administrator. 2. Set the Tivoli environment, From a UNIX command line:./etc/tivoli/setup_env.sh 5. Installing the TWS Connector Tivoli Workload Scheduler Planning and Installation Guide 93

108 Installation Procedure From a Windows NT command line: %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 3. Open the Tivoli Desktop. 4. From the Desktop menu select Install->Install Patch. This opens the Install Patch window. 5. Follow a similar procedure to Install Product. Updating TWS Security Before you update TWS security, you must add the TWS user as a Tivoli administrator on the Tivoli desktop. To do this: 1. Open the Tivoli desktop 2. Do one of the following: Add the TWS user logon to the Edit Logins window for Tivoli Administrators. Create a Tivoli administrator that has the logon of the TWS user. Update the TWS Security file as follows: 1. Login as the TWS user (usually, TWSuseror maestro). 2. Change directory to TWS home. 3. Execute the dumpsec command as follows: dumpsec >tempsec 4. Edit the tempsec file to contain the TMF Admin name. To get the Admin name, open Tivoli desktop and double-click on Administrators. The Admin name is the Administrators group to which your login belongs. Usually the name looks like Root_dallas-region. If the Admin name contains a blank, enclose it in double quotes. 5. Run wmaeutilto stop the TWS Connector. 6. Execute the makesec command as follows: makesec tempsec 94 Version 7.0

109 Uninstalling the TWS Connector Uninstalling the TWS Connector 1. Login as root or administrator. 2. Set the Tivoli environment, From a UNIX command line:./etc/tivoli/setup_env.sh From a Windows NT command line: %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 3. Run the wuninst command: On UNIX: wuninst TWSConnector <node> -rmfiles On Windows NT: $bash wuninst TWSConnector <node> -rmfiles Where node is the name of the system from which you want to remove the TWS Connector. 5. Installing the TWS Connector This will kill TWS Connector processes and remove TWS Connector classes and installation files. Uninstalling the JSS Server Before you uninstall the Job Scheduling Services, make sure that you have uninstalled the TWS Connector and, if applicable, the OPC Connector. 1. Login as root or administrator. 2. Set the Tivoli environment, From a UNIX command line:./etc/tivoli/setup_env.sh From a Windows NT command line: %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 3. Run the wuninst command: Tivoli Workload Scheduler Planning and Installation Guide 95

110 Uninstalling the JSS Server On UNIX: wuninst TMF_JSS node -rmfiles On Windows NT: bash wuninst TMF_JSS node -rmfiles Where node is the name of the system from which you want to remove JSS. This will remove JSS classes and installation files. Useful Framework Commands These commands can be used to check your Framework environment. Refer to the Tivoli Framework Reference Guidefor more details. Command wlookup -ar ProductInfo wlookup -ar PatchInfo wlookup -ar MaestroEngine wuninst -list wuninst {ProductName} -list Description Lists the products installed in the TMR. Lists the patches installed in the TMR. Shows the instances of this class type (same for the other classes). This returns the following information: barb #Maestro::Engine# The number before the 1st. (dot) is the region #,the 2nd number is the ManagedNode ID (if it s 1 then it s the TMR Server). So in a multi-tmr environment if you need to know where a particular instance is installed you can figure it out by looking at this number since all the TMR regions will have a unique ID. Shows all the products that can be uninstalled. Shows what Managed Nodes a product is installed on. 96 Version 7.0

111 6 Installing the Tivoli Job Scheduling Console This chapter describes the installation process for Tivoli Job Scheduling Console. System Requirements The Job Scheduling Console has the following system requirements: CD-ROM drive for installation. Approximately 10 MB. 128 MB RAM. TCP/IP network communications. Supported Platforms The Tivoli Job Scheduling Console is available for the following operating systems: Microsoft Windows NT Version 4.0 with Service Pack 4 or later Windows 2000 Windows 98 AIX or 4.3 Sun Solaris 2.6 or Installing the Tivoli Job Scheduling Console Tivoli Workload Scheduler Planning and Installation Guide 97

112 Supported Platforms HP-UX 10.x or 11.0 Prerequisites for HP-UX and AIX Before you install the Job Scheduling Console on HP-UX or AIX platforms, you are required to install Java for these two platforms. These are available from the Hewlett-Packard or IBM websites. Java must be installed successfully prior to installing the Job Scheduling Console. Make note of the installation path. You must enter the path where you installed Java during the installation of the Job Scheduling Console. Installing the Job Scheduling Console Perform the following steps to install the Job Scheduling Console: 1. Login as root or administrator. 2. Insert the Tivoli Job Scheduling Console CD-ROM into the system CD-ROM drive or mount the CD-ROM from a drive on a remote system. For this example, the CD-ROM drive is drive D. 3. Run the installation command: On Windows: v From the Start menu, select the Run... option to display the Run dialog. v Enter d:\jsgui\windows\install.exe in the Open field. On Sun Solaris, AIX, and HPUX: Go to the installation CD-ROM or image file repository and type: sh install.bin Note: On AIX and HPUX, be sure that you have set the CLASSPATH variable to the location where the classes.zip (for JDK) or the rt.jar (for JRE) file resides before running install.bin. 98 Version 7.0

113 The following window is displayed. Installing the Job Scheduling Console 4. In this window, click the down arrow in the language field. This displays a drop-down list containing all the available languages in which you can perform installation. 5. Select your language and click OK in the splash window. The Introduction window is displayed. This window will lead you through the installation process, displaying a series of option windows that enable you to provide the necessary information. You can use the Previous, Next or Exit button, when enabled, to move through these windows. 6. Installing the Tivoli Job Scheduling Console Tivoli Workload Scheduler Planning and Installation Guide 99

114 Installing the Job Scheduling Console 6. Click the Next button to continue to the Choose Install Folder window, shown in the next figure. The default installation paths are: For Windows: C:\Program Files\JSConsole For AIX, Sun Solaris, and HPUX: /JSConsole 7. Enter the path in which to install the Job Scheduling Console. If you need to, edit the default location provided in the field, or select the Choose... button to open the Select a folder window from where you can specify another location. 8. For Windows and Sun Solaris only: Click Next to continue to the Choose Shortcut Location window. The next figure shows the Windows version of Choose Shortcut Location. The Sun 100 Version 7.0

115 Installing the Job Scheduling Console Solaris version is similar, but it displays different choices. 9. For Windows and Sun Solaris only: Click one of the available radio buttons to specify where the Job Scheduling Console icons are to be placed. 10. Click Next to continue to the Choose Install Set window, shown in the next figure. 6. Installing the Tivoli Job Scheduling Console 11. In this window, choose between installing the Job Scheduling Console in all the available languages (Full package) or only in Tivoli Workload Scheduler Planning and Installation Guide 101

116 Installing the Job Scheduling Console the languages you select (Customized Install). In either case, the English version is automatically installed. If you are choosing Full package, click Install to install the Job Scheduling Console. If you are choosing Customized install: a. Click Customize to open the Customize Install window, shown in the next figure. b. In the Customize Install window, select in which languages, beside English, you want to install the Job Scheduling Console and click Install. Notes: 1) The Job Scheduling Console will display in your selected language, only if the language matches the regional settings of your computer. If they do not, English will be the default. 2) The Job Scheduling Console will automatically adjust to the Country, Language and Timezone settings of your system or UNIX shell. 102 Version 7.0

117 Installing the Job Scheduling Console An information window containing a progress indicator, shown in the next figure, is displayed. 12. When the Install Complete window shown in the next figure is displayed, click the Done button to close it and complete installation. 6. Installing the Tivoli Job Scheduling Console Tivoli Workload Scheduler Planning and Installation Guide 103

118 Installing the Job Scheduling Console 13. If you installed the JS Console on AIX or HPUX, you must update the AIXconsole.sh or HPconsole.sh file with the path where you installed Java Development Kit (JDK) To do this: Go to the /bin/java subdirectory of the directory where you installed the JS Console. Open AIXconsole.sh or HPconsole.sh in editing mode. Find the following variable and change it to read: JAVAPATH=usr/jdk1.1.8/J1.1.8 Change the JAVAPATH value with the path to JDK Save your changes and exit the editor. You can now start the Tivoli Job Scheduling Console. Starting the Job Scheduling Console 1. Depending on your platform, start the JS Console in the following way: On Windows, depending on the shortcut location that you specified during installation, click the JS Console icon or select the corresponding item in the Start menu. An MS-DOS window, like the one shown in the next figure, opens in the background. 104 Version 7.0

119 Starting the Job Scheduling Console On Windows 95 and Windows 98, you can also start the JS Console from the command line. Just type RUNCON from the \bin\java subdirectory of the installation path. On the other platforms: a. Change directory to installation path/bin/java b. Type the start command: v On AIX, type: v v./aixconsole.sh On Sun Solaris, type:./sunconsole.sh On HPUX, type:./hpconsole.sh 6. Installing the Tivoli Job Scheduling Console Tivoli Workload Scheduler Planning and Installation Guide 105

120 Starting the Job Scheduling Console A Tivoli Job Scheduling Console startup window, like the one shown in the next figure, is displayed. 2. Enter the following information and click the OK button to proceed: Host Machine LoginAs The name of the TMR server or managed node that runs the TWS Connector. The TWS username or any other login that is granted with Tivoli administrator rights and is in the TWS security file. Password The password to the host machine running the TWS Connector. 3. If you are logging onto the managed node of Host Machine for the first time, an information pop-up, like the one shown in the next figure, is displayed that tells you how to specify a user preference file for initialization, if it exists. 106 Version 7.0

121 Starting the Job Scheduling Console Read the information and click OK to continue to the Open Location window. 4. Use this window to do one of the following: Specify a URL where user preferences are defined. Enter the URL and select the Load from URL button. Select the Get from file button to open a window from where you can choose a file that contains initialization data. Select the Cancel button to use default user preferences. 5. Make your selection. The Welcome window, shown in the next figure, is displayed. The Tivoli Job Scheduling Console window is displayed in the background. 6. Installing the Tivoli Job Scheduling Console 6. In the Welcome window, select a radio button and then click OK to start working with the Job Scheduling Console. Or click Cancel to close the Welcome window and work with the Job Scheduling Console without online assistance. Tivoli Workload Scheduler Planning and Installation Guide 107

122 Uninstalling the Job Scheduling Console Uninstalling the Job Scheduling Console This section provides instructions for uninstalling the Job Scheduling Console on UNIX and Windows. UNIX Uninstall To uninstall the Job Scheduling Console on AIX, HP-UX, and Sun Solaris, go to the /UninstallerData subdirectory of the installation path and enter the following command:./uninstall_jsconsole Note: Before you run the./uninstall_jsconsole make sure you set the PATH variable. For example: export PATH=$PATH:/usr/jdk1.1.8/J1.1.8 Windows Uninstall To uninstall the Tivoli Job Scheduling Console on Windows: 1. Go to the shortcut location that you specified during installation, and click the Uninstall Tivoli Job Scheduling Console icon. The InstallAnywhere Uninstaller window is displayed. 2. Click Uninstall. A progress indicator is displayed. When uninstallation completes, it lists any files that the program was not able to uninstall. You will have to erase them manually. 108 Version 7.0