Tivoli Workload Scheduler - IBMpublib.boulder.ibm.com/tividd/td/TWS/GC32-0422-00/en_US/...Tivoli Workload Scheduler User’s Guide Provides information about configuring and using

Tivoli WorkloadSchedulerPlanning and Installation GuideVersion 7.0

Tivoli WorkloadSchedulerPlanning and Installation GuideVersion 7.0

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 rightsreserved. May only be used pursuant to a Tivoli Systems Software License Agreement or Addendum for Tivoli Products toIBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in aretrieval 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 youlimited 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 aregranted 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 warrantiesof merchantability and fitness for a particular purpose.

Note to U.S. Government Users—Documentation related to restricted rights—Use, duplication or disclosure is subject torestrictions 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. InDenmark, 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 Corporationin 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, orboth.

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 beavailable in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services isnot intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to TivoliSystem’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 inconjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of theuser.

Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in this document. Thefurnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to theIBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.

Contents

Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWho 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Tivoli Workload Scheduler 7.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

What is New with Tivoli Workload Scheduler 7.0 . . . . . . . . . . . . . . . . . 3

Network Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

TWS Network Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Domain Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Localized Processing in Your Domain . . . . . . . . . . . . . . . . . . . . . . . . . 10

Network Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

A Single Domain Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

A Multiple Domain Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Switching to a Backup Domain Manager . . . . . . . . . . . . . . . . . . . . . . . 16

Expanded Database and Long Object Names . . . . . . . . . . . . . . . . . . . . 17

Workstation Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Installation Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Product Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Components File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Netman’s Home Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

After Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 2. Installing the TWS Engine on Windows NT 23

iiiTivoli Workload Scheduler Planning and Installation Guide

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Preparing for an Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Unlinking and Stopping TWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Backup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Installing the Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

The Setup Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Running Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Following Installation and Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Completing an Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Setting the PATH Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

TWS Directories and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Setting Up Decentralized Administration . . . . . . . . . . . . . . . . . . . . . . . 38

Creating the TWS Account Manually. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Types of TWS Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Uninstalling TWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Using the Windows NT Add/Remove Tool. . . . . . . . . . . . . . . . . . . . . . 43

The Uninstal.exe Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Chapter 3. Installing the TWS Engine on UNIX . . . . . . . . . 47System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Installing the Tivoli Workload Scheduler Engine . . . . . . . . . . . . . . . . . 48

Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Updating Tivoli Workload Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Preparation-Stop TWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Update Software and Run Customize . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Update Security Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Restore Your Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

iv Version 7.0

Restart TWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

The Customize Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Uninstalling TWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Chapter 4. Setting TWS Security . . . . . . . . . . . . . . . . . . . . . . . . 63Editing the Security File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapter 5. Installing the TWS Connector . . . . . . . . . . . . . . . 77Prior to Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77


Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Installing the Job Scheduling Services (JSS) . . . . . . . . . . . . . . . . . . . . 79

Installing the TWS Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Installing JSS and TWS Connector Patches . . . . . . . . . . . . . . . . . . . . . 93

Updating TWS Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Uninstalling the TWS Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Uninstalling the JSS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Useful Framework Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Chapter 6. Installing the Tivoli Job SchedulingConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97


Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Prerequisites for HP-UX and AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Installing the Job Scheduling Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Starting the Job Scheduling Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Uninstalling the Job Scheduling Console . . . . . . . . . . . . . . . . . . . . . . . . . . 108

UNIX Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

vTivoli Workload Scheduler Planning and Installation Guide

Windows Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Chapter 7. Optional TWS Customization Topics. . . . . . . 111Setting Global Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Setting Local Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Automating the Production Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Customizing the final Job Stream. . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Adding the final Job Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Starting a Production Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Managing the Production Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Choosing the TWS Start of Day. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Changing the Start of Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Creating a Plan for Future or Past Dates . . . . . . . . . . . . . . . . . . . . . . 118

Appendix. Migrating to TWS 7.0 . . . . . . . . . . . . . . . . . . . . . . . 121The Tivoli Management Framework for non-Tivoli users . . . . . . . . . . . . . . 121

Installation Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Where Can The JS Console Client Be Installed . . . . . . . . . . . . . . . . . 123

Where Should The TWS Connectors Be Installed. . . . . . . . . . . . . . . . 123

Backup Master Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Dealing with Non-tier 1 Masters in an Existing Maestro Network. . . . . . . . 125

Moving the Backup Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Creating a Backup Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Mounting MDM Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Dealing with Non-tier 1 Backup Masters in an Existing Maestro Network 128

Running Multiple Windows in the JS Console . . . . . . . . . . . . . . . . . . . . . . 128

Making an Existing Security File Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Adding TME Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Managing Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

vi Version 7.0

Stopping Connectors to Implement Changes. . . . . . . . . . . . . . . . . . . . 132

Legacy GUI Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Using the Legacy GUI on AIX 4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Timezone Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Propagating User Preferences to Other Users (Custom Views/Queries) . . . . 135

Backing Out of an Expanded Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Migrating on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Migrating from Maestro 5.2 on Windows NT Agents . . . . . . . . . . . . . 138

Appendix. Networking with MPE . . . . . . . . . . . . . . . . . . . . . . . 141Network Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Scheduling Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Setup and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Setting Up a UNIX agent with MPE Master. . . . . . . . . . . . . . . . . . . . 144

Setting Up an MPE FTA with UNIX or Windows NT . . . . . . . . . . . . 145

Operational Differences Between Platforms . . . . . . . . . . . . . . . . . . . . . . . . 146

On the MPE Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

On UNIX Fault-Tolerant Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

On the UNIX or Windows NT Master . . . . . . . . . . . . . . . . . . . . . . . . 147

On the MPE Slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

viiTivoli Workload Scheduler Planning and Installation Guide

viii Version 7.0

Preface

The Tivoli Workload Scheduler Planning and Installation Guideprovides information on installing a Tivoli Workload Scheduler 7.0network. This includes information on how to plan a network, installthe TWS engine, connector software, and the graphical userinterface.It also provides instructions to customize TWS options andsecurity in order to start a TWS network. Finally, it gives tips andinformation on migrating from previous versions of Maestro.

Who Should Read This GuideThis book is intended for the following audience:

¶ TWS administrators - those who plan the layout of the TWSnetwork.

¶ Installers - those who install the various software packages onthe computers that make up the TWS network.

Prerequisite and Related DocumentsThe following are related documents:

¶ Tivoli Workload Scheduler User’s Guide

Provides information about configuring and using TivoliWorkload Scheduler. It contains information on TWS networks,security, global and local options files, an overview of theproduction cycle, and descriptions of database and plan tasks.

¶ Tivoli Workload Scheduler Reference Manual

Provides information about the Tivoli Workload Schedulercommand line interfaces, including composer, conman, thescheduling language, and utility commands.

What This Guide ContainsThe Tivoli Workload Scheduler Planning and Installation Guidecontains the following:

¶ Chapter 1, “Introduction”

ixTivoli Workload Scheduler Planning and Installation Guide

Provides planning information to set up a TWS network and anoverview 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 and6.x.

Platform-specific InformationThe following table identifies the supported versions for each of thelisted platforms known at the time of publication. For more detailedand up-to-date information, please see the Tivoli Workload SchedulerRelease Notes.

Platform TWS Engine TWSConnector

JS Console

AIX 4.2 X X X

AIX 4.3 X X X

HP-UX 10.20 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

Platform TWS Engine TWSConnector

JS Console

Windows NT 4.0w/ SP 4 or higher

X X X

Windows 2000 X

Digital UNIX X

Intel ABI compliantplatforms

X

MIPS ABI compliantplatforms

X

Note:

On AIX 4.3, you must install thebos.rte.commands.4.3.1.1.bff patch. To determine whether ornot this patch is already installed on your system, run thefollowing command:lslpp -l bos.rte.commands

If the command returns a value below 4.3.1.1, then you mustinstall the patch .

Contacting Customer SupportIf you are entitled to Tivoli customer support, you can findfrequently updated information about configuring and using Tivoliproducts from the Tivoli Customer Support home page athttp://www.tivoli.com/ support/. This site includes the followinglinks:

¶ Updated versions of these release notes:http://www.tivoli.com/support/Prodman/html/RN.html

¶ Updated versions of Tivoli documentation:http://www.tivoli.com/support/documents/

¶ Searchable support databases:http://www.tivoli.com/tivoli.ww.reg/rform?lang=english

xiTivoli Workload Scheduler Planning and Installation Guide

¶ Access to product patches:http://www.tivoli.com/support/patches/

¶ Access to training schedules:http://www.tivoli.com/services/education/

¶ Access to Tivoli documentation survey:http://www.tivoli.com/support/survey/

Visit the Tivoli Customer Support site for this information andadditional customer services. These URLs do require a password andID. If you do not have access privileges or are unsure of your ID orpassword, send e-mail [email protected]. Include your nameand your company name in this correspondence.

You can order additional copies of product documentation bysending e-mail or calling one of the following locations:

¶ U.S. Customer E-mail: [email protected]

¶ U.S. Telephone: 1-800-879-2755

¶ Canada Telephone: 1-800-426-4968

¶ International Telephone: (770) 863-1234

Please provide the title and version number of the document that youare ordering.

xii Version 7.0

Introduction

This guide contains instructions for installing and updating TivoliWorkload Scheduler 7.0.

Tivoli Workload Scheduler 7.0Tivoli Workload Scheduler 7.0 is composed of three parts:

Tivoli Workload Scheduler EngineThe legacy Maestro product. Install the Engine on theMaster and on all the physical Agent CPUs.

TWS ConnectorMaps Job Scheduling Console commands to the TWSEngine. Install the TWS Connector on the Master and onany of the fault-tolerant agents (FTA) that you will use asbackup machines for the Master CPU. The Connectorpre-requires the Tivoli Management Framework (TMF)configured for a Tivoli Management Region (TMR) server ormanaged node.

Job Scheduling (JS) ConsoleA Java™ based graphical user interface (GUI) for TWS.Install the JS Console on any machine from which you wantto manage TWS plan and database objects. The JS Consoledoes not require the TWS Engine or the TWS Connector tobe installed in the same machine. You can use the JSConsole from any machine as long as it has a TCP/IP linkwith the machine running the TWS Connector.

1

1Tivoli Workload Scheduler Planning and Installation Guide

1.In

trod

uctio

n

A TWS network is made up of the workstations, or CPUs, on whichjobs and job streams are executed.

Primarily, workstation definitions refer to physical workstations.However, in the case of extended and network agents theworkstations are logical definitions that must be hosted by a physicalTWS workstation.

A Tivoli Workload Scheduler 7.0 network is made up of thefollowing types of workstation:

Master Domain Manager (MDM)The domain manager in the topmost domain of a TWSnetwork. It contains the centralized database files used todocument scheduling objects. It creates the Production planat the start of each day, and performs all logging andreporting for the network.

Backup MasterA fault-tolerant agent capable of assuming theresponsibilities of the master domain manager.

Domain ManagerThe management hub in a domain. All communications toand from the agents in a domain are routed through thedomain manager.

Backup Domain ManagerA fault-tolerant agent capable of assuming theresponsibilities of its domain manager.

Fault-tolerant Agent (FTA)A workstation capable of resolving local dependencies andlaunching its jobs in the absence of a domain manager.

Standard AgentA workstation that launches jobs only under the direction ofits domain manager.

Extended AgentA logical workstation definition that enables you to launch

Tivoli Workload Scheduler 7.0

2 Version 7.0

and control jobs on other systems and applications, such asBaan, Peoplesoft, Oracle Applications, SAP, and MVS JES2and JES3.

Network AgentA logical workstation definition for creating dependenciesbetween jobs and job streams in separate TWS networks.

JS Console ClientAny workstation running the graphical user interface fromwhich schedulers and operators can manage TWS plan anddatabase objects.

The following table summarizes which TWS 7.0 component goesinto 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.0TWS 7.0 includes the following new features:

¶ Integration with the Tivoli Management Region

¶ Use of a new graphical user interface

¶ Auditing

¶ Internationalization

¶ Time Zones



1.In

trod

uctio

n

The Tivoli Management FrameworkThe new TWS version requires that you install the TivoliManagement Framework at least on the Master CPU and on the FTAdesigned as its backup. This has two main reasons:

1. The Connector is a Framework-based product. It is based on theJob Scheduling Services (JSS), which provides a commonframework interface to job scheduling applications. Connectorsfor TWS and for OPC share a common JSS foundation, which isin turn based upon the Tivoli Management Framework. Thisenables users of TWS and of OPC to access their job schedulingengines through a common interface, the JS Console.

2. Since the Master and at least one backup FTA must be installedon machines running TMF, the TWS network partakes in thebenefits of Framework-based enterprise management. You maychoose to install the Master on a stand alone TMR server, or ona managed node that belongs to a larger Tivoli ManagementRegion. In this case, the managed node can be the client of anumber of other Tivoli services in the areas of deployment,administration, or availability. In any case, the Master and thebackup FTA will benefit from the security and administrativecapabilities of the Tivoli Management Framework.

The Job Scheduling ConsoleThe Job Scheduling Console is a graphical user interface from whichyou can manage plan and database objects. It provides, through theTWS Connector, Conman and Composer functionality. It can runboth independently or simultaneously with the command lineinterfaces (CLI).

While usage of CLI commands is confined to TWS CPUs, you caninstall the JS Console on machines outside of the TWS network. Torun the JS Console, you only have to be able to log into a TWSCPU running the Connector. This means that you can manage planand database objects not only from the Master or Agent CPUs, butalso from any system, including a laptop, on which the JS Console isinstalled and from which you can reach via TCP/IP the Master or theFTA running the Connector.


4 Version 7.0

From the same Job Scheduling Console you can also manage TivoliOperations Planning and Control (OPC) plan and database objects,provided that you can log into a machine running the OPCConnector.

Installation of the JS Console is explained in detail in “Installing theTivoli Job Scheduling Console” on page 97.

The following picture shows the relationships between the TivoliManagement Framework, the Job Scheduling Services, the TWS andOPC job scheduling engines, and the JS Console.

JS Console TerminologyThe terminology used in the Job Scheduling Console differs fromthat used in the command line and earlier versions of WorkloadScheduler. The following table lists the old terms and their JobScheduling Console equivalents. Refer to the glossary for moredefinitions.

Command Line Job SchedulingConsole

Definition

Schedule Job Stream A unit of work consisting of a set ofjobs and their dependencies.

Job Stream Instance The occurrence of a job stream in theplan.



1.In

trod

uctio

n

Command Line Job SchedulingConsole

Definition

Job Job An executable file, task or command,and its attributes. It is scheduled to runas part of a job stream.

Job Instance The occurrence of a job in the plan.

Cpu Workstation A logical processor –typically acomputer–that runs jobs. Types ofworkstations include DomainManagers, Backup Domain Managers,Fault-Tolerant Agents, StandardAgents, and Extended Agents.

Mozart Files Database A collection of scheduling objectsincluding jobs, job streams,parameters, calendars, and resources. Itis accessed by composer, formerlyknown as gcomposer.

Symphony File Plan The scheduled activity for a period,typically 24-hours. The plan iscontinuously updated to show thecurrent status of all WorkloadScheduler activities. It is accessed byconman, formerly known as gconman.

AT Time Start Time The earliest time a job or job streamwill begin.

UNTIL Time Deadline Time The latest time a job or job stream willbegin execution.

ON and EXCEPT Dates Run Cycles The dates on which a job stream runsor is excluded from running.

AuditingAn auditing option has been implemented to track changes to thedatabase and the plan:

¶ For the database, all user modifications are logged. However, thedelta of the modifications, or before image and after image, willnot be logged. If an object is opened and saved, the action willbe logged even if no modification has been done.


6 Version 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 theTWS network. This minimizes the risk of audit failure due tonetwork issues and allows a straightforward approach to writing thelog. The log formats are the same for both plan and database in ageneral sense. The logs consist of a header portion which is thesame for all records, an “action ID”, and a section of data which willvary according the action type. All data is kept in clear text andformatted to be readable and editable from a text editor such as vi ornotepad.

See the TWS User’s Guide for details on setting the auditing feature.

InternationalizationTWS 7.0 is translated into several languages other than English.They are: German, French, Italian, Spanish, Brazilian Portuguese,Chinese, Korean, and Japanese.

Time Zone ConsiderationsTime zone support is a feature that can be either enabled or disabled.Time zones are enabled if the timezone enable flag in the globaloptsfile is set to yes and if the master workstation has a time zonedefinition.

Time zones are disabled by default on installation of the product.

If time zones are enabled, the time zone fields in the Job SchedulingConsole are enabled. If you leave a workstation definition time zoneblank, it will default to the time zone of the master domain managerworkstation.

If time zones are disabled, then all the time zone fields are disabledthroughout the application. In composer and conman, you get anerror if you try to specify a time zone along with a time. In the Job



1.In

trod

uctio

n

Scheduling Console, the time zone fields are disabled for both thedatabase and the plan. The only exception to this are workstations inthe database, which have time zones enabled at all times.

When enabling the time zone for the master workstation, it isrecommended that you enter a time zone for any FTAs not in thesame time zone as the master. A blank FTA time zone is assumed tobe the same as the master time zone.

When time zones have been enabled, you can enter a time zonealong with a time in conman, composer or the Job SchedulingConsole. If you enter a time with no time zone, the time zone willbe taken from the workstation on which the job or job streamexecutes, or from the master workstation time zone if the executingworkstation time zone is blank.

Network PlanningBefore you begin installing Tivoli Workload Scheduler, determinethe answers to the following questions. The next sections provideinformation to help you in determining the answers that best suityour needs.

1. Will you use multiple domains or a single domain networkstructure?

2. If you use multiple domains, how will you divide your domains:

¶ by geographical locations, for example, London and Parisdomains?

¶ by timezone, for example Pacific Standard Time (pst) andEastern 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 OverviewA Workload Scheduler network contains at least one WorkloadScheduler domain, the master domain, in which the master domain


8 Version 7.0

manager is the management hub. Additional domains can be used todivide a widely distributed network into smaller, locally managedgroups.

Using multiple domains reduces the amount of network traffic byreducing the communications between the master domain managerand other computers.

In a single domain configuration, the master domain managermaintains communications with all of the workstations in theWorkload Scheduler network.

In a multi-domain configuration, the master domain managercommunicates with the workstations in its domain, and subordinatedomain managers. The subordinate domain managers, in turn,communicate with the workstations in their domains and subordinatedomain managers. Multiple domains also provide fault-tolerance bylimiting the problems caused by losing a domain manager to a singledomain. To limit the effects further, you can designate backupdomain managers to take over if their domain managers fail.

Domain FunctionalityWhen you define a new domain, you must identify the parentdomain and the domain manager. The parent domain is the domaindirectly above the new domain in the domain hierarchy. Allcommunications to and from a domain are routed through the parentdomain manager.

Before the start of each new day, the master domain manager createsa production control file, named Symphony. Tivoli WorkloadScheduler is then restarted in the network, and the master domainmanager sends a copy of the new Symphony file to each of itsautomatically linked agents and subordinate domain managers. Thedomain managers, in turn, send copies to their automatically linkedagents and subordinate domain managers.

Once the network is started, scheduling messages like job starts andcompletions are passed from the agents to their domain managers,through the parent domain managers to the master domain manager.

Network Planning


1.In

trod

uctio

n

The master domain manager then broadcasts the messagesthroughout the hierarchical tree to update the Symphony files ofdomain managers and fault tolerant agents running in Full Statusmode.

Localized Processing in Your DomainA key to choosing how to set up your Tivoli Workload Schedulerdomains is the concept of localized processing. The idea is toseparate or localize your scheduling needs based on a common set ofcharacteristics.

Common characteristics are things such as geographical locations,business functions, and application groupings. Grouping relatedprocessing can limit the amount of interdependency information thatneeds to be communicated between domains. The benefits oflocalizing processing in domains are:

¶ Decreased network traffic. Keeping processing localized todomains eliminates the need for frequent interdomaincommunications.

¶ Provides a convenient way to tighten security and simplifyadministration. Security and administration can be defined at,and limited to, the domain level. Instead of network-wide orworkstation-specific administration, you can have domainadministration.

¶ Network and workstation fault tolerance can be optimized. In amultiple domain Tivoli Workload Scheduler network, you candefine backups for each domain manager, so that problems inone domain do not disrupt operations in other domains.

Network ConsiderationsThe following questions will help in making decisions about how toset up your Tivoli Workload Scheduler network. Some questionsinvolve aspects of your network, and others involve the applicationscontrolled by Tivoli Workload Scheduler. You may need to consultwith other people in your organization to resolve some issues.

Network Planning

10 Version 7.0

¶ How large is your Tivoli Workload Scheduler network? Howmany computers does it hold? How many applications and jobsdoes it run?

The size of your network will help you decide whether to use asingle domain or the multiple domain architecture. If you have asmall number of computers, or a small number of applications tocontrol with Tivoli Workload Scheduler, there may not be a needfor multiple domains.

¶ How many geographic locations will be covered in your TivoliWorkload Scheduler network? How reliable and efficient is thecommunication between locations?

This is one of the primary reasons for choosing a multipledomain architecture. One domain for each geographical locationis a common configuration. If you choose single domainarchitecture, you will be more reliant on the network to maintaincontinuous processing.

¶ Do you need centralized or decentralized management of TivoliWorkload Scheduler?

A Tivoli Workload Scheduler network, with either a singledomain or multiple domains, gives you the ability to manageTivoli Workload Scheduler from a single node, the masterdomain manager. If you want to manage multiple locationsseparately, you can consider the installation of a separate TivoliWorkload Scheduler network at each location. Note that somedegree of decentralized management is possible in a stand-aloneTivoli Workload Scheduler network by mounting or sharing filesystems.

¶ Do you have multiple physical or logical entities at a single site?Are there different buildings, and several floors in eachbuilding? Are there different departments or business functions?Are there different applications?

These may be reasons for choosing a multi-domainconfiguration. For example, a domain for each building,department, business function, or each application(manufacturing, financial, engineering, etc.).

Network Planning


1.In

trod

uctio

n

¶ Do you run applications, like SAP R/3 or Baan, that will operatewith Tivoli Workload Scheduler?

If they are discrete and separate from other applications, youmay choose to put them in a separate Tivoli Workload Schedulerdomain.

¶ Would you like your Tivoli Workload Scheduler domains tomirror your Windows NT domains?

This is not required, but may be useful.

¶ Do you want to isolate or differentiate a set of systems based onperformance or other criteria?

This may provide another reason to define multiple TivoliWorkload Scheduler domains to localize systems based onperformance or platform type.

¶ How much network traffic do you have now?

If your network traffic is manageable, the need for multipledomains is less important.

¶ Do your job dependencies cross system boundaries, geographicalboundaries, or application boundaries? For example, does thestart of Job1 on CPU3 depend on the completion of Job2running on CPU4?

The degree of interdependence between jobs is an importantconsideration when laying out your Tivoli Workload Schedulernetwork. If you use multiple domains, you should try to keepinterdependent objects in the same domain. This will decreasenetwork traffic and take better advantage of the domainarchitecture.

¶ What level of fault-tolerance do you require?

An obvious disadvantage of the single domain configuration isthe reliance on a single domain manager. In a multi-domainnetwork, the loss of a single domain manager affects only theagents in its domain.

A Single Domain NetworkA single domain Tivoli Workload Scheduler network consists of amaster domain manager and any number of agents. The diagram

Network Planning

12 Version 7.0

below shows an example of the single domain network. A singledomain network is well suited to companies that have few locationsand business functions. All communications in the network arerouted 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.

It is important to note that single domain networks can be combinedwith other networks, single or multiple domain, to meet multiple siterequirements.

Tivoli Workload Scheduler supports inter-network dependenciesbetween jobs running on different Tivoli Workload Schedulernetworks.

Network Planning


1.In

trod

uctio

n

The example on the left above shows a single domain network. Themaster domain manager is located in Atlanta, along with severalagents. There are also agents located in Denver. The agents inDenver depend on the master domain manager in Atlanta to resolveall inter-agent dependencies, even though the dependencies may beon jobs that run in Denver. An alternative would be to createseparate single domain TWS networks in Atlanta and Denver, asshown 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 domainmanager. This can result in a heavy load on a widely distributednetwork.

¶ Failure of the master domain manager impacts the entire TivoliWorkload Scheduler network.

Network Planning

14 Version 7.0

A Multiple Domain NetworkMultiple Domain networks are especially suited to companies thatspan multiple locations, departments, or business functions. Amultiple domain Tivoli Workload Scheduler network consists of amaster domain manager, any number of lower tier domain managers,and any number of agents in each domain. Agents communicate onlywith their domain managers, and domain managers communicatewith their parent domain managers.

The diagram shows an example of a multiple domain network. Thisdiagram builds on the example shown for single domain networks.The master domain manager is located in Atlanta; it contains thedatabase files used to document the scheduling objects, anddistributes the Symphony file to its agents and the domain managersin Denver and Los Angeles. The Denver and Los Angeles domainmanagers then distribute the Symphony file to their agents andsubordinate domain managers in Boulder, Aurora and Burbank. Themaster domain manager in Atlanta is responsible for broadcastinginter-domain information throughout the network.

Network Planning


1.In

trod

uctio

n

All communications to and from the Boulder domain manager arerouted through its parent domain manager in Denver. If there areschedules or jobs in the Boulder domain that are dependent onschedules or jobs in the Aurora domain, those dependencies areresolved by the Denver domain manager. Most inter-agentdependencies 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 masterdomain manager, or from any other domain manager or agentthat has access to the database files on the master domainmanager.

¶ 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 ManagerEach domain has a domain manager and, optionally, one or morebackup domain managers. A backup domain manager must be in thesame domain as the domain manager it is backing up. The backupdomain managers must be fault-tolerant agents running TivoliWorkload Scheduler 7.x, and must have the Resolve Dependenciesand Full Status options enabled in their workstation definitions.

If a domain manager fails during the production day, you can useeither the Job Scheduling Console, or the switchmgr command inthe Console Manager command line (conman), to switch to a backupdomain manager. A Switch Manager action can be executed byanyone with start and stop access to the domain manager and backupdomain manager workstations.

A switch manager operation stops the backup manager, then restartsit as the new domain manager, and converts the old domain manager

Network Planning

16 Version 7.0

to a fault-tolerant agent. The identities of the current domainmanagers are carried forward in the Symphony file from oneprocessing day to the next, so any switch remains in effect until youswitch back to the original domain manager.

Expanded Database and Long Object NamesTivoli Workload Scheduler databases and the Symphony file havebeen expanded to accommodate more records and longer objectnames. 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 Scheduler7.0. It permits the use of long names for scheduling objects --for example, job names can contain up to forty charactersinstead of eight as in earlier versions.

¶ Non-expanded databases are used to remain backwardcompatible to Maestro 5.x workstations which do not supportexpanded databases.

Notes:

1. It is suggested that the master be running an equal or lowerTWS version than the FTAs in the domain.

2. If you have MPE (HP3000) agents, be sure you runnon-expanded databases.

Database CreationFor new installations, Tivoli Workload Scheduler databases arecreated on the master domain manager the first time you run theTWS engine. The type of databases created, expanded ornon-expanded, is determined by checking the Global Optionexpanded version = [yes|no]. This option is set by the customizescript when you installed the TWS Engine. The default is expandedset to yes.

You can select non-expanded databases when you first install TWS7.0, and expand the databases later. To expand the databases, run thedbexpand command on the master domain manager. The programsets the Global Option expanded version to yes, makes backupcopies of the existing databases, and expands the databases to accept

Network Planning


1.In

trod

uctio

n

long object names. Only run dbexpand one time, otherwise thebackup copy of the existing databases will be lost. The backupcopies are placed in a directory named mozart.old in the mozartdirectory.

Workstation NamesJob scheduling in a Tivoli Workload Scheduler network is distributedacross multiple computers. To accurately track jobs, schedules, andother objects, each computer is given a unique workstation name.The names can be the same as network node names, as long as theycomply with Tivoli Workload Scheduler’s naming rules:

¶ For unexpanded networks, the workstation names can contain upto eight alphanumeric, dash (-), and underscore (_) charactersstarting with a letter.

¶ For expanded networks, the maximum length is sixteenalphanumeric, dash (-), and underscore (_) characters startingwith a letter.

Installation OverviewBelow is a summary of the installation process for TWS 7.0. Thisguide provides detailed instructions for each step.

1. On all Domain Managers (including Master and Backup), followthis order:

a. If you are installing over a previous version of Maestro orTWS, unlink the other workstations in the domain and stopMaestro or TWS. See “Unlinking and Stopping TWS” onpage 24 for NT and “Updating Tivoli Workload Scheduler” onpage 53 for UNIX.

Install the TWS 7.0 Engine. See “Installing the TWS Engineon Windows NT” on page 23 or “Installing the TWS Engineon UNIX” on page 47.You can actually reverse the order inwhich you perform this and the next step.

b. Install the Tivoli Management Framework. If you do notalready have a Tivoli Management Region in your enterprise,install as a TMR server. If a TMR already exists, you can

Network Planning

18 Version 7.0

choose to install as a managed node. See the TMFinstallation documentation for details.

c. Install the Job Scheduling Services and the TWS Connectoron the Tivoli Framework. See “Installing the TWSConnector” on page 77.

d. From the Tivoli Desktop, create a Tivoli Administrator forTWS. In other words, either add the TWS or Maestro user asa login for the TMF administrator, or create a new TMFadministrator 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 makeseccommand.

¶ On UNIX, you can run makesec without previouslystopping TWS, but you must stop and restart TWS toactivate the security feature.

f. Optionally, install the Job Scheduling Console. See “Installingthe Tivoli Job Scheduling Console” on page 97.

2. Install the following on each workstation you want to include asan agent in the TWS network:

¶ TWS 7.0 Engine.

¶ The Job Scheduling Console (optional). You can install theJS Console also on workstations not in the TWS networkthat have a TCP/IP connection with a Domain Managerrunning the TWS Connector.

3. Log into the Job Scheduling Console, and define theworkstations in your TWS network to the TWS database.

4. Now you can use the Job Scheduling Console to define yourjobs, job streams and other scheduling objects.

Installation Overview


1.In

trod

uctio

n

Product GroupsTivoli products are organized into product groups. Each group has aNetman process to handle the services required by all products in thegroup. This also permits multiple copies of a product to be installedon a single computer by designating a different group for each copy.

Components FileProduct groups are defined in the components file. If the file doesnot exist prior to installation, it is created by the customize script onUNIX, or the Setup program on Windows NT. A UNIX samplefollows:

<product> <version> <home directory> <product group>

MaestroDestinyNetman

5.1.11.0.23.3.5

/opt/maestro/opt/destiny/opt/netman

productionproductionproduction

Entries in the file are automatically made and updated by customizeor Setup. The product group workstation_user is used as default onNT if you do not specify a group.

On UNIX, the file name of the components file is defined in thevariable: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 timethis version of Workload Scheduler is installed. See “Netman’sHome Directory” on page 21.

Viewing the Components FileFollowing installation or update, you can view the contents of thecomponents file by running the ucomp program as follows:ucomp -l

Product Groups

20 Version 7.0

Netman’s Home DirectoryAn option in the customize script on UNIX, and a Setup screen onWindows NT, allows you to specify a home directory for Netman. Ifskipped, the default on UNIX is Workload Scheduler’s homedirectory, and on Windows NT the default is:c:\win32app\unison\netman.

Netman Local OptionsIf Netman’s home directory is not the same as Workload Scheduler’shome directory, the following local options are moved fromWorkload Scheduler’s localopts file to a separate localopts file in theNetman directory:nm mortalnm portnm readnm retrymerge stdlistsstdlist widthsyslog local

And, the following option can be added, if desired:nm ipvalidate

See section 2 in the Tivoli Workload Scheduler Administrator’sGuide for more information about Local Options.

After InstallationAfter installing Workload Scheduler, refer to the Tivoli WorkloadScheduler User’s Guide for configuration and set up information.

Product Groups


1.In

trod

uctio

n

22 Version 7.0

Installing the TWS Engine onWindows NT

This chapter describes the installation process for Tivoli WorkloadScheduler (TWS) on Windows NT systems and networks.

System RequirementsThe following are TWS system requirements for Windows NTsystems.

¶ 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 standardagents. In addition, TWS produces log files, and temporary files,that are placed on the local hard drive. The amount of spacerequired depends on the number of jobs managed by TWS, andthe amount of time you choose to retain log files.

¶ 128 MB RAM and 128 MB swap space for domain managersand fault-tolerant agents. Standard agents require less.

¶ TCP/IP network communications.

¶ A TWS user account is required for proper installation. You cancreate the account beforehand, or have the Setup program createit for you.

2


2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

Before continuing, see the Tivoli Workload Scheduler Release Notesfor information about the latest system requirements, andplatform-specific issues.

Preparing for an UpdateIf this is an update of an existing installation of TWS, follow thesteps below before running the Setup program. After Setup iscomplete, refer to “Completing an Update” on page 37 for importantpost-setup steps.

Note: The standard approach to updating a TWS network is toupdate the fault-tolerant and standard agents first, and thenthe master domain manager. However, before deciding how toupdate your TWS network, refer to the Tivoli WorkloadScheduler Release Notes for the latest information aboutmigrating to a new software version.

Unlinking and Stopping TWSBefore starting an update of TWS, follow these steps to unlinkworkstations and stop TWS processes. Note that this procedure is forupdating from a previous version of TWS, either Maestro 6.x or 5.x.

1. On the target workstation, login as maestro if you are updatingfrom Maestro 5.2, or as Administrator if you are updating fromMaestro 6.x. Run the Console Manager.

2. Click the workstation icon, or select CPUs from the Objectsmenu.

3. In the Showcpus window:

a. If you are updating the master domain manager, select all ofthe fault-tolerant and standard agents, and choose Unlinkfrom the Actions menu.

b. If you are updating a fault-tolerant or standard agentworkstation, select the master domain manager, and chooseUnlink from the Actions menu.

4. Select the workstation you are updating and choose Stop fromthe Actions menu.

System Requirements

24 Version 7.0

5. Exit the Console Manager.

6. At a command prompt, run the command line from TWShomeand enter the following command to stop TWS services:conman “shutdown;wait”

Backup FilesTWS’s Setup program will move your copies of Sfinal, Jnextday,NetConf, StartUp and the methods directory to a directory named:TWShome\config.old

These files are often customized to meet your specific needs, andyou can use the saved copies to incorporate your changes followingthe update. The Setup program will not overwrite any files in themozart directory, stdlist directory, or unison directory that weremodified 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 alsobackup the entire TWShome directory.

You are now ready to run the Setup program. See “Installing theSoftware”.

Installing the SoftwareUse the Setup program to install the TWS engine on Windows NT.

The Setup ProgramThe Setup program installs or updates TWS. It will perform thefollowing functions:

¶ New TWS installation: Install TWS and Netman. Create acomponents file with new entries.

¶ First-time update of TWS version 6.x and earlier: Update TWSand Netman, if necessary. Create a components file with newentries.

¶ Subsequent updates of TWS: Update TWS and Netman, ifnecessary. Update entries in components file.

Preparing for an Update


2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

Running Setup1. 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 WindowsNT 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 yoursetup language and click OK.

Installing the Software

26 Version 7.0

6. The Welcome window is displayed.

7. Click Next > on the Welcome window to continue. The ProcessWarning window is displayed. To continue click Next >. If youare updating TWS, make certain that all TWS processes arestopped, including the Tivoli services. If you uninstalled TWSbefore running Setup, you must restart your computer beforecontinuing (see “Uninstalling TWS” on page 43 for details onhow to uninstall). To accomplish these tasks, exit Setup byclicking Cancel.



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

8. On the Installation Options window, select the type ofinstallation and click Next >.

Copy files and CustomizeCopy Netman files from the CD and customize theinstallation. This must be selected for new installationsand updates.

Customize onlyCustomize existing files. This resets permissions onfiles back to default permissions.


28 Version 7.0

9. In the Account Infomation window, enter the followinginformation and click Next >:

Account

The name of the TWS user (usually twsuseror maestro).The software is installed, or updated, in this user’shome directory. You can include the domain, ifapplicable - for example: hqtrs\twsuser. If you omit thedomain, 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 homedirectory, if necessary, and grant the necessary rights.

PasswordThe account password.

Confirm PasswordRe-enter the account password.

Note: If you are installing more than one instance of TWS on acomputer, note that each installation will attempt to placefiles in the directory TWShome\..\unison. Make sure thatthe parent directories are different to avoid conflict. Forexample, c:\apps\maestro, and c:\apps1\maestro.



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

10. Select the destination directory where you want TWS to beinstalled. If you do not like the default, click Browse to specifya different choice. When you have finished, click Next toproceed.

11. On the Determine Database Expansion window, choose one ofthe following and click Next >:


30 Version 7.0

Expanded Databases (Supports Long Object Names)Use the expanded databases available only in Maestro6.0 and above.

Non-Expanded Databases (Compatible with Maestro 5.x)Use the non-expanded databases. This should be used toinstall TWS on the master domain manager of anetwork that contains workstations running a versionlower than 6.0, or any version of Maestro for MPE. Thedatabases can be expanded later using the dbexpandcommand. Refer to the Tivoli Workload SchedulerUser’s Guide for more information on the dbexpandcommand.

Note: If your network includes MPE workstations, you mustuse unexpanded mode. MPE workstations cannot beincluded in expanded TWS networks.

12. On the Configuration Information window, enter the followinginformation and click Next >:

CompanyYour company’s name.

This CPUThe TWS name of this workstation. For the



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

non-expanded version of TWS, this can be up to eightalphanumeric, dash (-), or underscore (_) charactersstarting with a letter. For the expanded version, thelength is sixteen characters. This name must be usedlater to formally define the workstation in TWS.

Master CPUThe TWS name of the master domain manager. If thisis the master domain manager, or a stand-aloneworkstation, the name is the same as This CPU. For thenon-expanded version of TWS, this can be up to eightalphanumeric, dash (-), or underscore (_) charactersstarting with a letter. For the expanded version, thelength is sixteen characters. If you are installing on themaster domain manager, Setup creates its workstationdefinition automatically.

Product GroupThe name of the product group for this installation orupdate. The default is ″workstation_user″.

Note: If Netman is not installed in the product group, you areprompted to install it now. Netman is required in theproduct group before you can successfully run TWS. IfNetman is already installed in the product group, theprompt, and the following Netman Setup steps areskipped.


32 Version 7.0

13. Netman Setup. On the Welcome window, Click Next > toinstall Netman.

Note: If the Welcome window does not appear, use theWindows NT task bar to bring it forward.

14. Netman Setup. On the Installation Options window, select thetype of installation and click Next >.



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

Copy files and CustomizeCopy Netman files from the CD and customize theinstallation. This must be selected for new installationsand updates.

Customize onlyCustomize existing files. This resets permissions onfiles back to default permissions.

15. Netman Setup. On the Destination Directory window, select thedirectory to install Netman and click Next >. The default is:c:\win32app\unison\netman

To select a different directory, click Browse and select adirectory. If the directory does not exist, you are prompted tohave it created. In addition, if the components file does notexist, it is created in this directory.


34 Version 7.0

16. Netman Setup. On the Netman Port window, enter the Netmanport number and click Next >. The default is 31111.

17. Netman Setup. The Setup Information window summarizes theinformation Setup will use to install Netman. Click < Back toreview or change the information, or click Next > to continue.

After you click Next, a progess indication window displays theinstallation of the Netman files.



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

18. Finally, the Setup Information window summarizes theinformation Setup will use to install TWS. Click < Back toreview or change the information, or click Next > to install orupdate 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

Running Netman Setup SeparatelyYou can run the Netman Setup program independent of the TWSproduct to install or update the Netman files. To run the NetmanSetup program:

1. Insert the TWS CD.

2. Run the Netman Setup program:d:\maestro\i386\netman\setup.exe

Following Installation and UpdatePerform the following tasks after installing or updating TWS.

Completing an UpdateIf 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 yourchanges 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 VariableLog in as a user in the Local Administrators group or DomainAdministrators group. In the system environment, add the TWShomeand TWShome\bin directories to the PATH variable. For example:other_directories;C:\win32app\maestro;C:\win32app\maestro\bin

TWS Directories and ServicesSetup installs TWS files in TWShome, and TWShome\..\unison,which is also used by other Tivoli products. For example, ifTWShome is c:\win32app\maestro, then the directoryc:\win32app\unison is also created.

Setup also registers the following services with the Service ControlManager:

¶ Tivoli MAESTRO for user

¶ Tivoli Netman for wkstn_user



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

¶ Tivoli Token Service for user

Note that the Service Control Manager maintains its own userpassword database. Therefore, if the TWSuser password is changedfollowing installation, you must use the Services applet in theControl Panel to assign the new password for the Token Service andNetman.

The JOBMON ServiceThe Jobmon service runs in the SYSTEM account with the right″Allow Service to Interact with Desktop″ granted to it. You canremove the right for security reasons. However, this will prevent theservice from launching interactive jobs that run in a window on theuser’s desktop. These jobs are not accessible and do not have accessto desktop resources. As a result, they may run forever or abend dueto lack of resources.

Setting Up Decentralized AdministrationYou can administer TWS scheduling objects from computers otherthan the TWS master domain manager where the databases exist.

If you intend to administer scheduling objects in this manner, youmust create shares for the directories in the master domain managerand define a set of local options on the other computers.

Sharing the Master DirectoriesMake the following directories shareable on the master domainmanager, and set the permissions to give the domain user, TWS ormaestro, full control:TWShome\mozartTWShome\..\unison\network

Sharing TWS ParametersThe TWS substitution parameters are normally computer-specific andadministered separately on each computer. If you want theparameters to be common to all computers, and administered fromany computer, you can either share the TWShome directory asdescribed above for other directories, or copy the parametersdatabase, each time it changes, from the master domain manager toeach of the other computers. The database files are:

Following Installation and Update

38 Version 7.0

TWShome\parametersTWShome\parameters.KEY

Using a Single ShareAs an alternative to sharing different directories, you can move all ofthe database files to a common directory, share the directory, andthen set the local options, discussed below, to the share name. Thedatabase files are listed below.

In TWShome\..\unison\ :cpudatacpudata.KEYuserdatauserdata.KEY

In TWShome\mozart\ :calendarscalendars.KEYjob.schedjob.sched.KEYjobsjobs.KEYmastskedmastsked.KEYpromptsprompts.KEYresourcesresources.KEY

In TWShome :parametersparameters.KEY

The files are created as needed by TWS. If they do not exist, youcan simply set the local options to the shared directory as describedbelow.

Setting Local OptionsTo access the shared master databases, set the local options on eachof the computers from which you want to administer TWSscheduling objects. The options are described here followed by theprocedure for modifying them.



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

Note that each option can be set to a conventional name(drive:\share) or a UNC name (\\node\share). If set to a conventionalname, the maestro user must explicitly connect to the share. If set toa UNC name, an explicit connection is not required. The localoptions are:

mozart directoryDefines the name of the master’s shared mozart directory.

unison network directoryDefines the name of the master’s shared unison directory.

parameters directoryDefines 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 fileTWShome\localopts.

2. The options exist as comments in the Tivoli-supplied file. To setan option, remove the # sign in column 1 and change the valueto the point to the correct directory. For example, to access allobjects except parameters:mozart directory = \\hub\mozartunison network directory = \\hub\unison# parameters directory = d:\maestro

3. Save the file and exit.

4. Stop and restart TWS (including Netman) to make the changesoperative.

If an option is not set or does not exist, the TWS Composer programattempts to access the database files on the local computer.

Setting Local Options on the MasterIf the database files have been moved from the default directories, aslisted above under Using a Single Share, then you must set the localoptions on the master domain manager to the new location. SeeSetting Local Options above.


40 Version 7.0

Creating the TWS Account ManuallyNew TWS installations require a user account with specificpermissions in which to install the software. The setup programcreates this user automatically. If you want to create the accountmanually, follow the steps below.

Note: The following procedures require a knowledge of WindowsNT account management, including the ability to createaccounts, and assign user rights. If you do not possess thisknowledge, consult with your Windows NT administrator, orrefer to your Microsoft documentation and Windows NTonline help.

Types of TWS AdministrationThe databases containing the TWS scheduling objects reside on thecomputer you define as the master domain manager. You canadminister 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.

Choose the appropriate procedure below based on the way you wantto administer the TWS scheduling objects.

Centralized AdministrationIf you will administer scheduling objects from the master domainmanager only, use the following procedure to create the TWS ormaestro user.

1. Create a local user account named TWSor maestro on thecomputer you will use as the TWS master domain manager. Notethat this name must be used on all computers in the TWSnetwork, 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. Forexample:

Creating the TWS Account Manually


2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

C:\win32app\maestro

Do not specify the root directory of a drive. The TWS softwarewill be installed in this user’s home directory. This is referred toin the documentation as TWShome.

3. Grant the TWSor maestro user the following advanced userrights:

Act as part of the operating systemIncrease quotasLog on as batch jobLog on as a serviceLog on locallyReplace a process level token

You are now ready to run the Setup program. Refer to “Installing theSoftware” on page 25.

Decentralized AdministrationIf you will administer scheduling objects from more than one TWScomputer, in addition to the master domain manager , use thefollowing procedure to create the TWS or maestro user.

Note: After installing the software it will be necessary to createshares to permit access to the databases on the master domainmanager. This is discussed in “Sharing the MasterDirectories” on page 38.

1. Create a domain account named TWS or maestro in the domainof the computer you will use as the TWS master domainmanager. Note that this name must also be used on any UNIXcomputers 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. Forexample:C:\win32app\maestro


42 Version 7.0

Do not specify the root directory of a drive. The TWS softwarewill be installed in this user’s home directory. This is referred toin the documentation as TWShome.

3. On each computer from which TWS will be managed, grant theTWSor maestro user the following advanced user rights:

Act as part of the operating systemIncrease quotasLog on as batch jobLog on as a serviceLog on locallyReplace a process level token

You are now ready to run the Setup program. Refer to “Installing theSoftware” on page 25.

Uninstalling TWSThe uninstall programs will remove product files, registry keys,services, and program groups. Note that uninstall will not removefiles created after TWS was installed, nor files that are open at thetime of uninstall.

You have two ways to uninstall the TWS Engine and Netman from aWindows 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 ToolTo uninstall TWS, or the Netman service, on Windows NT 4.0, youmust be a TWS or maestro user with Windows NT administratorrights.

Use the following procedure:

1. Stop TWS and all TWS services. See “Unlinking and StoppingTWS” on page 24 for details.



2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

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 Maestroand Netman services.

Note: The uninstall process will not remove some files, folders andregistry entries.

The files created when the products were installed are removed byuninstalling. However, any files you created or modified sinceinstallation are not removed. You may wish to retain these files foruse with a later installation of TWS.

Uninstalling NetmanNetman is a product independent of TWS. Although it can beinstalled and updated along with TWS, it must be uninstalledseparately. To uninstall Netman, DO NOT delete the files. Alwaysuse the Add/Remove Program facility in the Windows NT ControlPanel. The following files are used by other products, and are notremoved when Netman is uninstalled:netmanhome\componentsnetmanhome\bin\ucomp.exe

The Uninstal.exe ProgramThe Uninstal program is used to remove an installation of TivoliWorkload 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]

Uninstalling TWS

44 Version 7.0

Variables-V Display the program patch level.

-U Display program usage information.

-p The product name:

maestroThe TWS product.

netmanThe Netman service.

-r The product version; for example: 6.1.0

-l The user account for which the product was installed. This isvalid only with -p maestro.

-s Run in silent mode. If omitted, the program issues promptsand progress messages.

-g The product group. The default group is DEFAULT. This isvalid only with -p netman.

Examples1. 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

Uninstalling TWS


2.In

stalling

the

TW

SE

ng

ine

on

Win

do

ws

NT

Uninstalling TWS

46 Version 7.0

Installing the TWS Engine onUNIX

This section explains the Tivoli Workload Scheduler installationprocess for UNIX systems and networks.

System RequirementsThe following are TWS system requirements for UNIX computers.


¶ Approximately 120 MB of free disk space for domain managers,and fault-tolerant agents. Approximately 80 MB for standardagents.

¶ In addition, TWS produces log files, and temporary files, thatare placed on the local hard drive. The amount of space useddepends on the number of jobs managed by TWS, and theamount of time you choose to retain log files.

¶ 32 MB RAM and 48MB swap space for domain managers, andfault-tolerant agents. Standard agents require less.

¶ TWS fault-tolerant agents can, optionally, mount directories fromthe master domain manager. This requires Network File System(NFS). Consult with your system and network administrators andrefer to the Tivoli Workload Scheduler User’s Guide for moreinformation.

3


3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

Before continuing, see the Tivoli Workload Scheduler Release Notesfor additional information.

Installation ProcedureFollow these instructions on UNIX computers if you are installingTWS for the first time, or if TWS has been completely uninstalled.For Windows NT computers, refer to “Installing the TWS Engine onWindows NT” on page 23.

Installing the Tivoli Workload Scheduler EnginePerform the following steps to install TWS on a UNIX computer.

1. Create the TWS user. The software is installed in the user’shome 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 acomputer, note that each installation will attempt to placefiles in the directory twshome/../unison. Make sure that theparent directories are different to avoid conflict. Forexample, /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.

platformYour platform type. One of the following:

System Requirements

48 Version 7.0

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 DomainManager 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 maybe 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 moreexamples, refer to “The Customize Script” on page 57.

4. Create a .profile file for the maestro user, if one does not alreadyexist (twshome/.profile). Edit the file and modify the PATHvariable 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 recommendreplacing the period with the above paths, or inserting the pathsbefore the period. If there is no period in the PATH statement,simply add the paths to the end.

5. To start the TWS network management process, Netman,automatically as a daemon each time you boot your system, addone of the following to the /etc/rc file, or the proper file for yoursystem: To start Netman only:

Installation Procedure


3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

if [-x twshome/StartUp]thenecho "netman started..."/bin/su - maestro -c " twshome/StartUp"fi

Or, to start the entire TWS process tree:if [-x twshome/bin/conman]thenecho "Workload Scheduler started..."/bin/su - maestro -c " twshome/bin/conman start"fi

The TWS installation process is now complete.

Configuration StepsFor UNIX installations execute the following configuration tasks.These tasks must be executed from the TWS Composer andConman command line interfaces.

Once you have configured the Master Domain Manager in this wayyou can use the Job Scheduling Console to configure the otherworkstations, and job scheduling objects in your TWS network.Refer to the Tivoli Workload Scheduler Reference Guide for detailson the commands used below. Refer to the Tivoli WorkloadScheduler User’s Guide for information on using the Job SchedulingConsole to configure other workstations in the network.

Configuring a Master Domain Manager After Installation1. Login to the Master Domain Manager workstation as maestro.

This is the tws_user ID variable, which defaults on UNIX tomaestro. The UNIX tws_user ID can be modified using the-uconfig argument.

2. Create the Master Domain Manager workstation definition inTWS database by using the TWS composer command line. Opena command line window in UNIX and enter the followingcommands:composer

new


50 Version 7.0

3. This opens a text editor where you can create the Master DomainManager workstation definition in the TWS database. Below isan example workstation definition for a Master Domain Manager.For more information on workstation defintions, refer to theTivoli 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 DomianManager workstation definition. To do this add the final jobstream to production cycle. This job stream contains theJnextday job which automates the creation of the Symphonyfile.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 limitafter installation is set to zero. This means no jobs will execute,so you may want to raise the job limit now:conman “limit;10”

You can now begin defining additional scheduling objects in theCLI, including workstations, jobs and job streams or you can



3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

continue to install the Job Scheduling Console, and the connector.Note that new objects are not recognized until the Jnextday job runsin the final job stream. By default, the final job stream runs at5:59am (you can change this default; see “Changing the Start ofDay” on page 117 for details). If you want to incorporate newscheduling objects sooner, you can run Jnextday manually as in step6 above or use the conman submit command. For information aboutdefining your scheduling objects, refer to the Tivoli WorkloadScheduler User’s Guide.

Configuring a Fault Tolerant Agent After Installation1. Login to the FTA workstation as maestro. This is the tws_user

ID variable, which defaults on UNIX to maestro. The UNIXtws_user ID can be modified using the -uconfig argument.

2. Create the FTA workstation definition in TWS database by usingthe TWS composer command line. Open a command linewindow in UNIX and enter the following commands:composer

new

3. This opens a text editor where you can create the FTAworkstation definition in the TWS database. Below is an exampleworkstation definition for a FTA. For more information onworkstation defintions, refer to the Tivoli Workload SchedulerReference 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 workstationdefinition. To do this run the Jnextday job on the Master DomainManager which automates the creation of a new Symphony file:


52 Version 7.0

Jnextday

6. Issue the link command from the Master Domain Manager tolink the FTA and to download the Symphony file to it:conman “link ftaname”

Updating Tivoli Workload SchedulerUse this procedure to update existing TWS installations on UNIXcomputers. The recommended sequence for updating a TWS networkis to update all agent workstations first, and then update the masterdomain manager.

Note: Be sure to read the Tivoli Workload Scheduler Release Notesfor additional information about updating existing software.

The update topics below are presented in the sequence they shouldbe performed.

Preparation-Stop TWS1. From the Job Scheduling Console, unlink the target workstation

from the other workstations in the network. Otherwise, from thecommand line use the following command:conman "unlink workstationname;noask"

2. From the Job Scheduling Console, stop and shutdown the targetworkstation. From the command line, use the followingcommands:conman “shut;wait”

3. If you are updating an agent, remove (umount) any NFSmounted directories from the master domain manager.

BackupTWS’s customize script will move your working copies of Sfinal,Jnextday, NetConf and StartUp to a directory namedtwshome/config.old. These files are often customized to meet yourspecific needs, and you can use the saved copies to incorporate yourchanges following the update. The customize script will notoverwrite any files in the mozart directory, stdlist directory, orunison directory that were modified after TWS was installed.



3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

If there are any other files you want to protect during the update,copy or rename them now. As an added precaution, you should alsobackup the following:

¶ The twshome directory.

¶ The Netman home directory (twshome/../Unison)

¶ The components file (generally, /usr/unison/components)

Update Software and Run Customize1. 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.

platformYour 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 DomainManager 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]

Updating Tivoli Workload Scheduler

54 Version 7.0

If you are using an HP-UX 10.x system, your bourne shell maybe 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 moreexamples, refer to “The Customize Script” on page 57.

Update Security ProfileFor migration from 6.0 to 7.0 an additional Maestro User definitionmust be added to the security file. The tme_region_administrator IDmust be added to the security file.

1. Login as Maestro.

2. Execute the dumpsec command to create a temporary editablecopy of the security file:dumpsec >tempsec

3. Edit the security file. Under the section USER MAESTRO addthe TME Region administrator ID:USER MAESTRO

root, maestro, administrator, tme_region_admin

4. Execute the makesec command to compile the temporary fileinto a new security file:makesec

tempsec For more information on Makesec and Dumpseccommands refer to the Tivoli Workload Scheduler User’s Guide.

Restore Your FilesUsing the files you protected as a reference, apply your changes tothe new versions of the files.

Restart TWSTo restart Tivoli Workload Scheduler:

1. Log in as TWSor maestro user.

2. Run the start command:conman start

3. Run the linkcommand:



3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

¶ For a Master Domain Manager:conman “link @”

¶ For an FTA workstation:conman “link domainname”

The software update is now complete on this workstation.


56 Version 7.0

The CustomizeScript

Use the customize script to install and update Tivoli WorkloadScheduler on UNIX platforms.

Synopsiscustomize -new -thiscpu wkstationname -masterwkstationname[-company ″ companyname″] [-group groupname][-nmhome netmanhome] [-noexp] [-nolinks|-execpath pathname][-unameusername]

customize -update[-company ″ companyname″] [-groupgroupname][-nmhome netmanhome] [-unameusername]

DescriptionThe customize script installs or updates TWS. Use it to perform thefollowing functions:

¶ New TWS installation: Install TWS and Netman. Create acomponents file with new entries.

¶ First-time update of pre-7.0 TWS: Update TWS and Netman, ifnecessary. Create a components file with new entries.

¶ Subsequent updates of TWS: Update TWS and Netman, ifnecessary. Update entries in components file. Use it also to resetpermissions to their default values provided that the originalMAESTRO.TAR file is not in the twshome directory.

Arguments-new This is a new installation.

-updateThis is an update of an existing installation. Note thatupdating the software will not change the type of databasesin use by TWS.

-thiscpuThe name of this workstation. For the non-expanded versionof TWS, the name can be up to eight alphanumeric, dash (-),

The Customize Script


3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

or underscore (_) characters starting with a letter. For theexpanded version, the length is sixteen characters. This namemust be used later to formally define the workstation inTWS.

-masterThe name of the master domain manager. For thenon-expanded version of TWS, the name can be up to eightalphanumeric, dash (-), or underscore (_) characters startingwith a letter. For the expanded version, the length is sixteencharacters. If this computer is the master domain manager, ora stand-alone workstation, enter the same name as -thiscpu.This name must be used later to formally define theworkstation in TWS.

-companyThe name of the company, enclosed in double quotationmarks (up to 40 characters). The name appears in programheaders and reports.

-groupThe name of the product group in which you want to installor update TWS. This can contain up to 36 characters,starting with a letter. If omitted for a new installation or afirst-time update of an earlier version of TWS, the namedefaults to DEFAULT. If included for an update, other thana first-time update of an earlier version of TWS, this name isoverridden with the group from the components file, usingthe home directory of the user as a reference. For moreinformation, see “Product Groups” on page 20.

-nmhomeThe Netman home directory. If omitted, Netman is installedin TWS’s home directory (twshome). See “Netman’s HomeDirectory” on page 21 for more information. For updates,this option is useful only for first-time updates of pre-6.0versions of TWS. In subsequent updates, it is ignored.

-noexpUse the non-expanded databases. This sets the global optionexpanded version to no and creates the non-expanded


58 Version 7.0

databases. Since earlier versions do not support expandeddatabases, use this keyword when you install TWS 7.0 in anetwork that contains computers running a TWS versionearlier than 6.0, or any version of TWS for MPE. After allcomputers in the network have installed TWS 6.0 or later,the databases can be expanded by running the dbexpandcommand on the master domain manager. Refer to thedbexpand command in the Tivoli Workload SchedulerReference Guide for more information. If omitted, the globaloption expanded version is set to yes and expandeddatabases are created.

[-nolinks|-execpath pathname]The link option determines the path customize uses to createlinks to TWS’s utility commands. If you include -nolinks, nolinks are created. If you include -execpath, links are createdfrom the specified path. If linkopt is omitted altogether, linksare created as follows:

usr/bin/mat twshome/bin/at

usr/bin/mbatch twshome/bin/batch

usr/bin/datecalc twshome/bin/datecalc

usr/bin/jobstdl twshome/bin/jobstdl

usr/bin/maestro twshome/bin/maestro

usr/bin/mdemon twshome/bin/mdemon

usr/bin/morestdl twshome/bin/morestdl

usr/bin/muser twshome/bin/muser

usr/bin/parms twshome/bin/parms

-unameThe name of the user for whom TWS will be installed orupdated. The software is installed or updated in this user’shome directory. If omitted, the default user name is maestro.



3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

Uninstalling TWSFollow these steps to uninstall TWS from a UNIX system:

1. Before uninstalling TWS, kill any existing TWS Connectorinstances 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. TheTWS database files are stored in the TWS user home directoryand 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 donot need to save it.

4. Review the contents of the file named /usr/unison/components. Ifthe file contains multiple entries that correspond to differentMaestro/TWS accounts (product groups), edit the file by deletingthe lines that correspond to the instance you want to remove.

For example, suppose that /usr/unison/components contains thefollowing entries:netman 1.5 /opt/maestro DEFAULT

maestro 7.0 /opt/maestro DEFAULT

netman 1.3 /home/maestro dev_test

Uninstalling TWS

60 Version 7.0

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 youwant to remove, then delete the entire file.

5. Remove the links, if applicable, to the /usr/bin directory. TheTWS installation process gives you the option to link TWSexecutables 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 thefollowing commands:rm -rf <twshome>/../unison

rm -rf <twshome>

If your system startup command was modified to include aconman ″start″ or a <twshome>/StartUp command, you mustalso remove those entries.

Uninstalling TWS


3.In

stalling

the

TW

SE

ng

ine

on

UN

IX

Uninstalling TWS

62 Version 7.0

Setting TWS Security

After you install the TWS engine and before you proceed to installthe JS Console, you must set TWS security.

Each workstation in a Workload Scheduler network (domainmanagers, fault-tolerant agents and standard agents) has its ownSecurity file.

The Security file contains one or more user definitions. Each userdefinition identifies a set of users, the objects they are permitted toaccess, and the types of actions they can perform. WorkloadScheduler programs and commands determine a user’s capabilitiesby comparing the user’s name with the user definitions in theSecurity file.

You can maintain a file on each workstation, or you can create aSecurity file on the master domain manager and copy it to eachdomain manager, fault-tolerant agent, and standard agent.

A template file named TWShome/config/Security is provided withthe software. During installation, a copy of the template is installedas TWShome/Security and a compiled, operational copy is installedas TWShome/../unison/Security.

To set TWS security:

1. Create user definitions. Provided that the default user definitionis enough to fit your requirements, you are nevertheless asked toat least add a user definition for the Tivoli Management

4


4.S

etting

TW

SS

ecurity

Framework administrator on the master or FTA running the TWSConnector. To do this, edit the Security file. It is recommendedthat you create a working copy of the Security file every timeyou add a new user definition. Do not modify the originaltemplate in TWShome or in TWShome/config. To create a userdefinition:

a. Use the dumpsec command to create an editable copy of theoperational Security file:dumpsec>mysec

b. Edit mysec to add, delete, or modify user definitions.

2. Use the makesec command to compile and install the newoperational Security file:makesec mysec

Use dumpsec and makesec every time you want to modify theSecurity file. Changes to the Security file take effect when oneof the following Workload Scheduler programs is stopped andrestarted:¶ conman¶ gconman¶ composer¶ gcomposer¶ TWS Connector

Simply exit the programs. The next time they are run, the newsecurity definitions will be recognized. For TWS Connectors, usethe wmaeutil command to stop them. They will be automaticallyrestarted with a refresh of any query in the Job SchedulingConsole.

Editing the Security FileThe default Security template installed on your machine grants everyright to every object to the user under which TWS was installed andto the UNIX root or NT administrator user. You will want to edit theSecurity file to add new users with less rights.

When editing the Security file, keep the following facts in mind:

Setting TWS Security

64 Version 7.0

¶ In qualifying users to access Workload Scheduler objects, auser’s actual attributes are compared to user definitions in theorder the definitions are entered in the Security file. The firstdefinition that matches the user determines the user’scapabilities. For this reason, it is important to order userdefinitions from most specific to least specific.

¶ In a user definition, you can use multiple statements for a singleobject type to assign different access capabilities to different setsof objects. Because the first matching statement is used, theorder of object statements is important. They must be orderedfrom most specific to least specific.

¶ The user definition of the Security file created by the TWSinstallation process grants full access to all scheduling objects.When you add new user definitions, it is easier if you copy thisuser definition to the appropriate location in the Security file.Then, you can modify the name of the definition and the userattributes, and finally you can customize or remove thescheduling objects.

The syntax of the Security file is the following:

# comment]user def-name user-attributesbegin [* comment]object-type [object-attributes] access[=action[,...]][object-type ... ][end]

The customization steps below are listed on a general basis. Refer tothe TWS User’s Guide for an example and details of Security filevariables.

1. Optionally, at the top of the file, enter a comment after a poundsign (#) or asterisk (*). Comments are not copied into theoperational 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.

Editing the Security File


4.S

etting

TW

SS

ecurity

3. Specify one or more attributes that identify the set of users towhom 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 musthave. Use a tilde (x) to add an attribute the user or users mustnot have. A user-attribute can be one of the following:

cpu=workstation|$framework|@ [,...]where:

workstationSpecifies the workstation or workstation class onwhich the user is logged in. Use one of thefollowing Tivoli Workload Scheduler variables:

$masterThe user is logged in on the TWS masterdomain manager.

$remotesThe user is logged in on any TWSstandard agent.

$slavesThe user is logged in on any TWSfault-tolerant agent.

$thiscpuThe user is logged in on the TWSworkstation on which the securedprogram is running.

$frameworkSpecifies that the user is accessing TWS with theTivoli Job Scheduling Console. The logon=attribute specifies the TME administrators groupin which the user is a member.

@ Specifies that the user is accessing TivoliWorkload Scheduler with the Tivoli Job


66 Version 7.0

Scheduling Console or is logged in on any TivoliWorkload Scheduler workstation.

group=groupname[,...]Apply this to UNIX users only. Do not use this argumentfor Tivoli Job Scheduling Console users. It specifies theUNIX group in which the user is a member.

logon=username|tme-admin|@ [,...]where:

usernameSpecifies the name with which the user is loggedin on a TWS workstation.The cpu= attributemust be set to a workstation name or @.

tme-adminSpecifies the name of the TME administratorsgroup in which the user is a member. The cpu=attribute must be set to $framework or @.

@ Specifies that the user is logged in with anyname or is a member of any TME administratorsgroup.

4. Between the begin and the end keywords, enter a list of theobject types to which the users specified in user are givenpermission to access. Omitting an object type prevents access toall 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.S

etting

TW

SS

ecurity

userobjUser objects.

5. Specify one or more attributes identifying each of the objects youlisted in the previous step. When no attributes are specified, allobjects that belong to that particular type are accessible. Specifyobject attributes as follows:

object-attribute[{+ | x}object-attribute[...]]

Use a plus sign (+) to add an attribute objects must have. Use atilde (x) to add an attribute objects must not have. You can usewildcard characters. When you enter multiple names for anattribute, separate them by commas. An object-attribute can beany of the following:

¶ For the object type calendar:

name=calendar-name[,...]Specifies one or more calendar names. If omitted, allcalendars qualify.

¶ For the object type cpu (workstation):

cpu=wkstation[,...]Specifies one or more workstation, domain, orworkstation class names. If omitted, all workstationsqualify. The following Tivoli Workload Schedulervariables are permitted: $master, $remotes, $slaves,and $thiscpu.

¶ For the object type file:

name=filename[,...]Specifies the names of Workload Scheduler databasefiles. If omitted, all files qualify. The file names areas follows:calendars

Contains calendars.cpudata

Contains workstation, workstation classes,and domains.

jobs Contains jobs.


68 Version 7.0

mastskedContains job streams.

parametersContains parameters.

prodskedContains the production schedule.

promptsContains prompts.

resourcesContains resources.

securityThe Security file.

SymphonyContains the production plan.

¶ For the object type job:

cpu=wkstationSpecifies the name of the workstation or workstationclass on which the job runs. If omitted, allworkstations qualify. The following Tivoli WorkloadScheduler variables are permitted: $master,$remotes, $slaves, and $thiscpu.

jcl= ’path’ | ’cmd’Specifies the command or the path name of the job’sexecutable file. The command or path must beenclosed in single quotes (‘). If omitted, all job filesand commands qualify.

logon=username[,...]Specifies the user names under which the jobs run. Ifomitted, all user names qualify. The following TivoliWorkload Scheduler variables are permitted:$jclowner, $owner, and $user.

name=[jobstream.]job[,...]Specifies the Workload Scheduler job name. Thejob’s job stream name is optional. If omitted, all jobnames qualify.

¶ For the object type parameter:



4.S

etting

TW

SS

ecurity

cpu=wkstationSpecifies the name of the workstation on which theparameters are defined. If omitted, all workstationsqualify. The following Tivoli Workload Schedulervariables 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, allprompts qualify.

¶ For the object type resource:

cpu=wkstation[,...]Specifies the name of the workstation or workstationclass on which the resources are defined. If omitted,all workstations qualify. The following TivoliWorkload Scheduler variables are permitted:$master, $remotes, $slaves, and $thiscpu.

name=resource[,...]Specifies one or more resource names. If omitted, allresources qualify.

¶ For the object type schedule (job stream):

cpu=wkstationSpecifies the name of the workstation or workstationclass on which the job streams run. If omitted, allworkstations qualify. The following Tivoli WorkloadScheduler 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

cpu=wkstationSpecifies the name of the workstation on which theuser is defined. If omitted, all workstations qualify.The following Tivoli Workload Scheduler variablesare permitted: $master, $remotes, $slaves, and$thiscpu.

logon=username[,...]Specifies one or more user names. If omitted, allusers qualify.

6. Specify what actions the users you defined in steps 2 and 3 canperform on the objects you listed in steps 4 and 5. Multipleactions must be separated by commas. If none are specified, noactions are permitted. Entering access=@, gives users the abilityto 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.

displayDisplay calendars in the database.

modifyModify 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.

consoleView and alter the Workload Scheduler console.

delete Delete workstations, workstation classes, anddomains from the database.

displayDisplay workstations, workstation classes, anddomains in the database.



4.S

etting

TW

SS

ecurity

fence Alter workstation job fences in the production plan.

limit Alter workstation job limits in the production plan.

link Open workstation links.

modifyModify and workstations, workstation classes, anddomains in the database.

shutdownShutdown Workload Scheduler processing. Thisaction is only available in the command line.

start Start Workload Scheduler processing.

stop Stop Workload Scheduler processing.

unlinkClose workstation links.

To permit a user to switch the domain manager function to aworkstation, the user must have both start and stop access tothe workstation.

¶ For the object type file:

build Build Workload Scheduler’s database files. Thisaction is only available in the command line.

delete Not yet implemented.

displayAccess the Security file with the dumpsec command.

modifyAccess the Security file with the makesec command.Also modify the calendars, parameters, prompts, andresources master files. These actions are onlyavailable in the command line.

¶ For the object type job:

add Add and save new jobs in the database.

adddepAdd dependencies to jobs in the production plan.


72 Version 7.0

altpri Alter the priority of jobs in the production plan.

cancel Cancel jobs in the production plan.

confirmConfirm the completion of jobs in the productionplan.

deldepDelete dependencies from jobs in the productionplan.

delete Delete jobs from the database.

displayDisplay jobs in the database.

kill Kill jobs in the production plan.

modifyModify jobs in the database.

releaseRelease jobs from their dependencies in theproduction plan.

reply Reply to job prompts in the production plan.

rerun Rerun jobs in the production plan.

submitSubmit 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.

displayDisplay parameters in the database.

modifyModify and replace parameters in the database.

¶ For the object type prompt:



4.S

etting

TW

SS

ecurity

add Add and save new prompts in the database.

delete Delete prompts from the database.

displayDisplay prompts in the database.

modifyModify and replace prompts in the database.

use Add prompts to job streams in the database and addprompts to jobs and job streams in the productionplan.

¶ For the object type resource:

add Add and save new resources in the database.

delete Delete resources from the database.

displayDisplay resources in the database.

modifyModify and replace resources in the database.

use Add resources to job streams in the database and addresources to jobs and job streams in the productionplan.

¶ For the object type schedule (job stream):

add Add and save new job streams in the database.

adddepAdd dependencies to job streams in the productionplan.

altpri Alter the priority of job streams in the productionplan.

cancel Cancel job streams in the production plan.

deldepDelete dependencies from job streams in theproduction plan.

delete Delete job streams from the database.


74 Version 7.0

displayDisplay job streams in the database.

limit Alter the job limit of job streams in the productionplan.

modifyModify job streams in the database.

releaseRelease job streams from their dependencies in theproduction plan.

reply Reply to job stream prompts in the production plan.

submitSubmit job streams into the production plan.

¶ For the object type userobj:

add Add new users in the database.

delete Delete users from the database.

displayDisplay users in the database.

modifyModify and replace users in the database.

altpassAlter user passwords in the database.

7. Depending on your requirements, repeat the steps above to defineas many users as necessary, the objects they can use, and thetype of access.

Note: Remember to update the security file to add the TivoliAdministrator, after you have installed the TivoliManagement Framework and TWS Connector. See“Updating TWS Security” on page 94 for details.



4.S

etting

TW

SS

ecurity


76 Version 7.0

Installing the TWS Connector

This chapter describes how to install the TWS Connector.

Prior to InstallationRead this information before proceeding with the TWS ConnectorInstallation.

The TWS Connector requires the Job Scheduling Services (JSS) tobe installed into your Tivoli environment.

The TWS Connector installation and customization will varydepending on whether your TWS Master is on a TMR Server or ona Managed Node.

¶ When the TWS Master is on a TMR Server, you must installboth the JSS and the TWS Connector on the TMR Server ofyour environment. You must also create a TWS Connectorinstance for the TMR Server. This can be done duringinstallation by using the Create Instance checkbox and filling inthe required fields.

¶ When the TWS Master is on a Managed Node, you must installJSS on TMR Server and on the Managed Node where theMaster is located. You must then install the TWS Connector onthe TMR Server and on the same Nodes where you installedJSS. Make sure not to check the Create Instance checkbox.

If you have more than one Node where you want to install theConnector (for example, if you want to access the local data of

5


5.In

stalling

the

TW

SC

on

necto

r

an FTA through the Job Scheduling Console), you can install theconnector on multiple machines. However, in this case youshould deselect the Create Instance checkbox, because eachinstance must have a unique name in the TWS network.

After you have installed the connector on the workstations inyour network, you can proceed with the creation of a TWSconnector instances on the machines you need to access TWSthrough the Job Scheduling Console. Each TWS connectorinstance name must be unique within the TWS Network, so youmust create each instance separately. We suggest you use thename of the TWS agent as the instance name.

TWS FTAs that need to be accessed through the Job SchedulingConsole in order to check local data, must have JSS and a TWSConnector installed, plus a unique TWS connector instance for everyTWS installation you need to access through the Job SchedulingConsole.

Note: Each TWS Connector Instance name must be unique withinyour TWS Network.

System RequirementsThe TWS Connector has the following system requirements:

¶ Tivoli Management Framework, Version 3.6.1 or later

¶ Tivoli Workload Scheduler 7.0 Base Engine


¶ Approximately 100 MB of free disk space for domain managers,and fault-tolerant agents. Approximately 40 MB for standardagents. In addition, TWS produces log files, and temporary files,that are placed on the local hard drive. The amount of spacerequired depends on the number of jobs managed by TWS, andthe amount of time you choose to retain log files.

¶ 128 MB RAM and 128 MB swap space for domain managersand fault-tolerant agents. Standard agents require less.


Prior to Installation

78 Version 7.0

¶ A TWS user account is required for proper installation. You cancreate the account beforehand, or have the Setup program createit for you.

Supported PlatformsThe TWS Connector is available for the following operatingsystems:

¶ Microsoft Windows NT® Version 4.0 with Service Pack 4 orlater

¶ AIX 4.2.1 or 4.3

¶ Sun Solaris 2.6 or 2.7

¶ HP-UX 10.x or 11.0

Installation ProcedureThe installation of the TWS Connector is divided into three sections:

¶ Install the Job Scheduling Services (JSS). Skip this step if youalready have the JSS installed on your Tivoli ManagementFramework. Note that the JSS must be installed before theconnector and that it must be installed on the TMR Server.

¶ Install TWS Connector. The TWS Connector must be installedon the TMR Server.

¶ Create the TWS Connector Instance. There must be one instancefor every TWS Engine you want to access through the JobScheduling Console. The TWS connector instance name must beunique within the TWS Network.

You can perform the installation in the Tivoli Desktop or from acommand 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 commandline. Both of the procedures are described here.

System Requirements


5.In

stalling

the

TW

SC

on

necto

r

Where to InstallInstall JSS Services on the TMR Server and on each managed nodewhere the TWS Connector will be installed.

Installing JSS Using the Tivoli Desktop1. 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. Thisopens the Install Product window.

Note: An error window may be displayed stating that the pathto the installation files is wrong. Ignore this window.


80 Version 7.0

Close it and proceed to the next step.

5. Click the Select Media... button to select the path or directorycontaining the CONTENTS.LST file. This opens the File



5.In

stalling

the

TW

SC

on

necto

r

Browser window.


82 Version 7.0

6. Click the Set Media & Close button. This returns to the InstallProduct window.

7. In the Select Product To Install list, select Tivoli JobScheduling Services.

8. In the Available Clients list, select the nodes to install on andmove them to the Clients to Install On list. You must installJSS on the Tivoli Management server. You will be able toinstall the TWS Connector only on managed nodes on whichthe JSS is installed.



5.In

stalling

the

TW

SC

on

necto

r

9. Click the Install & Close button. The Product Install windowopens.

10. The Product Install window shows you the progress of theinstallation. Click the Continue Install button to continue theinstallation or click the Cancel button to cancel the installation.

11. When the message Finished product installation appears, clickthe Close button.

Installing JSS Using the Command Line1. Set the Tivoli environment,



2. Do one of the following:

¶ To install on all managed nodes:


84 Version 7.0

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 installationimages files and node is the name of the managed node onwhich to perform the installation.

Installing the TWS ConnectorTo install the TWS connector, you can use the Tivoli desktop or thecommand line. Both of the procedures are described here.

Note: If you want to re-install the TWS Connector, you mustuninstall the existing one before you do. See “Uninstalling theTWS Connector” on page 95 for reference.

Where to InstallInstall the TWS Connector on the TMR Server and on the managedNode where the TWS Master is installed.

You can also install the connector on an FTA, if you want to accesslocal data on the FTA from the Job Scheduling Console.

Installing the TWS Connector Using the Tivoli Desktop1. Login as root or administrator.







5.In

stalling

the

TW

SC

on

necto

r

4. From the Desktop menu choose Install-> Install Product. Thisopens the Install Product window.

5. Click the Select Media... button to select the directorycontaining the CONTENTS.LST file. This opens the File


86 Version 7.0

Browser window.



5.In

stalling

the

TW

SC

on

necto

r

6. Click the Set Media & Close button. This returns to the InstallProduct window.

7. In the Select Product To Install list, select Tivoli TWSConnector. 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 ConnectorInstance


88 Version 7.0

9. To install the TWS Connector without creating a TWSConnector Instance, leave the Create Instance checkboxunchecked and leave the General Installation Options fieldsblank. These fields are only used during the creation of theTWS Connector Instance.

10. To install the TWS Connector and create a TWS ConnectorInstance:

a. Select the Create Instance checkbox.

b. In the TWS Directory field, specify the directory whereTWS is installed.

c. In the TWS instance name field, specify a name for theTWS instance on the managed node.

Note: This name must be unique in the TWS network.If you decide not to create the Instance at this time, you cancreate it later by using the wtwsconn utility from commandline. Refer to Creating TWS Connector Instances usingcommand line. Creating the TWS connector instance later isrecommended when installing the TWS Connector onmultiple Nodes, since you can perform the installationsimultaneously on all the Nodes while creating the instancelocally using wtwsconn.

11. Click the Set button, to close this window and go back to theInstall Product panel.



5.In

stalling

the

TW

SC

on

necto

r

12. In the Available Clients list, select the nodes to install on andmove them to the Clients to Install On list.

You must install TWS Connector on at least the Tivolimanagement server. You can only install the TWS Connector onmanaged nodes on which the JSS is installed.

Note: If you choose to create a TWS Connector Instanceduring the installation, you must select just one Nodefrom the list, since the Instance name must be uniquewithin 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 theinstallation. Click the Continue Install button to continue theinstallation or click the Cancel button to cancel the installation.

15. When the message Finished product installation appears, clickthe Close button.


90 Version 7.0

Installing the TWS Connector Using the Command Line1. Login as root or administrator.




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/maestroiname=Maestro owner=maestro

¶ To install on only one managed node:winstall -c installdir -I TWS_CONN node twsdir=/users/maestroiname=Maestro owner=maestro createinst=1

where installdir is the pathname containing the installationimages files and node is the name of the managed node onwhich to perform the installation.

Creating TWS Connector Instances Using the CommandLine

Create a TWS Connector instance for each TWS engine that youwant to access with the JS Console. To create TWS Connectorinstances, you must be a Tivoli administrator with admin, senior, orsuper authorization roles. For more information refer toAuthorization Roles below.

To create an instance, enter the following command on the TMRserver or managed node where you installed the TWS Connector thatyou need to access through the JS Console:wtwsconn -create -h [node] -n [instance_name] -t [TWS_directory]

where:



5.In

stalling

the

TW

SC

on

necto

r

-h nodeSpecifies the node where the instance is created. If notspecified it defaults to the node where the script file isexecuted.

-n instanceThe name of the new instance. This name will identify theTWS engine node in the Job Scheduling tree of the JSConsole. Note that this name must be unique within TWSNetwork.

-t twsdirSpecifies the value for the TWSdir attribute. This is the TWSinstallation directory on the specified node.

Authorization Roles Required for InstancesTo manage TWS connector instances from a TMR server ormanaged node, you must be a Tivoli administrator.

Each Tivoli administrator has one or more roles. To use or manageTWS connector instances, you need the following roles:

¶ user

To use the instances.

To view instance settings.

¶ admin, senior, or super

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 InstancesUse the wtwsconn utility to create, remove, and manage TWSconnector instances. This program is downloaded when you installthe TWS Connector.

The following table describes how to use wtwsconn in the commandline to manage TWS Connector instances.


92 Version 7.0

Action Syntax

Create an instance wtwsconn.sh -create [-h node] -n instance -t twsdir

Stop an instance wtwsconn.sh -stop -n instance | -t twsdir

Two stop actions are supported.

When -n instance is specified, the instance with that name isstopped.

When -t twsdir is specified, all the instances on this node(the node where script is executed) whose TWSdir attributematches twsdir are stopped.

Remove an instance wtwsconn.sh -remove -n instance

View the settings of aninstance.

wtwsconn.sh -view -n instance

Change the settings of aninstance

wtwsconn.sh -set -n instance -t twsdir

where:

node Specifies the node where instance is created. If not specifiedit defaults to the node where script is executed from.

instanceThe name of the new instance. This name will identify theTWS engine of node in the Job Scheduling tree of the JSConsole. Note:this name must be unique within TWSNetwork

twsdir Specifies the value for the TWS dir attribute. This is theTWS installation directory in node.

Installing JSS and TWS Connector PatchesTo install patches:

1. Login as root or administrator.





5.In

stalling

the

TW

SC

on

necto

r



4. From the Desktop menu select Install->Install Patch. This opensthe Install Patch window.

5. Follow a similar procedure to Install Product.

Updating TWS SecurityBefore you update TWS security, you must add the TWS user as aTivoli 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 forTivoli Administrators.

¶ Create a Tivoli administrator that has the logon of the TWSuser.

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 getthe Admin name, open Tivoli desktop and double-click onAdministrators. The Admin name is the Administrators group towhich your login belongs. Usually the name looks likeRoot_dallas-region. If the Admin name contains a blank, encloseit in double quotes.

5. Run wmaeutilto stop the TWS Connector.

6. Execute the makesec command as follows:makesec tempsec


94 Version 7.0

Uninstalling the TWS Connector1. Login as root or administrator.




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 toremove the TWS Connector.

This will kill TWS Connector processes and remove TWSConnector classes and installation files.

Uninstalling the JSS ServerBefore you uninstall the Job Scheduling Services, make sure thatyou have uninstalled the TWS Connector and, if applicable, the OPCConnector.





3. Run the wuninst command:

Uninstalling the TWS Connector


5.In

stalling

the

TW

SC

on

necto

r

¶ 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 toremove JSS.

This will remove JSS classes and installation files.

Useful Framework CommandsThese commands can be used to check your Frameworkenvironment. Refer to the Tivoli Framework Reference Guideformore details.

Command Description

wlookup -ar ProductInfo Lists the products installed in the TMR.

wlookup -ar PatchInfo Lists the patches installed in the TMR.

wlookup -ar MaestroEngine Shows the instances of this class type (same forthe other classes). This returns the followinginformation:

barb 1318267480.2.19#Maestro::Engine# Thenumber before the 1st . (dot) is the region # , the2nd number is the ManagedNode ID (if it’s 1 thenit’s the TMR Server). So in a multi-TMRenvironment if you need to know where aparticular instance is installed you can figure it outby looking at this number since all the TMRregions will have a unique ID.

wuninst -list Shows all the products that can be uninstalled.

wuninst {ProductName} -list Shows what Managed Nodes a product is installedon.

Uninstalling the JSS Server

96 Version 7.0

Installing the Tivoli JobScheduling Console

This chapter describes the installation process for Tivoli JobScheduling Console.

System RequirementsThe Job Scheduling Console has the following system requirements:


¶ Approximately 10 MB.

¶ 128 MB RAM.


Supported PlatformsThe Tivoli Job Scheduling Console is available for the followingoperating systems:

¶ Microsoft Windows NT® Version 4.0 with Service Pack 4 orlater

¶ Windows 2000

¶ Windows 98

¶ AIX 4.2.1 or 4.3

¶ Sun Solaris 2.6 or 2.7

6


6.In

stalling

the

Tivoli

Job

Sch

edu

ling

Co

nso

le

¶ HP-UX 10.x or 11.0

Prerequisites for HP-UX and AIXBefore you install the Job Scheduling Console on HP-UX or AIXplatforms, you are required to install Java 1.1.8 for these twoplatforms. These are available from the Hewlett-Packard or IBMwebsites. Java 1.1.8 must be installed successfully prior to installingthe Job Scheduling Console. Make note of the installation path. Youmust enter the path where you installed Java during the installationof the Job Scheduling Console.

Installing the Job Scheduling ConsolePerform the following steps to install the Job Scheduling Console:


2. Insert the Tivoli Job Scheduling Console CD-ROM into thesystem CD-ROM drive or mount the CD-ROM from a drive ona remote system. For this example, the CD-ROM drive is driveD.

3. Run the installation command:

¶ On Windows:

v From the Start menu, select the Run... option to displaythe Run dialog.

v Enter d:\jsgui\windows\install.exe in the Open field.

¶ On Sun Solaris, AIX, and HPUX: Go to the installationCD-ROM or image file repository and type:sh install.bin

Note: On AIX and HPUX, be sure that you have set theCLASSPATH variable to the location where theclasses.zip (for JDK) or the rt.jar (for JRE) fileresides before running install.bin.

Supported Platforms

98 Version 7.0

The following window is displayed.

4. In this window, click the down arrow in the language field. Thisdisplays a drop-down list containing all the available languagesin 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 toprovide the necessary information. You can use the Previous,Next or Exit button, when enabled, to move through thesewindows.

Installing the Job Scheduling Console


6.In

stalling

the

Tivoli

Job

Sch

edu

ling

Co

nso

le

6. Click the Next button to continue to the Choose Install Folderwindow, 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. Ifyou need to, edit the default location provided in the field, orselect the Choose... button to open the Select a folder windowfrom where you can specify another location.

8. For Windows and Sun Solaris only: Click Next to continue tothe Choose Shortcut Location window. The next figure showsthe Windows version of Choose Shortcut Location. The Sun


100 Version 7.0

Solaris version is similar, but it displays different choices.

9. For Windows and Sun Solaris only: Click one of the availableradio buttons to specify where the Job Scheduling Consoleicons are to be placed.

10. Click Next to continue to the Choose Install Set window,shown in the next figure.

11. In this window, choose between installing the Job SchedulingConsole in all the available languages (Full package) or only in



6.In

stalling

the

Tivoli

Job

Sch

edu

ling

Co

nso

le

the languages you select (Customized Install). In either case, theEnglish version is automatically installed.

¶ If you are choosing Full package, click Install to install theJob Scheduling Console.

¶ If you are choosing Customized install:

a. Click Customize to open the Customize Installwindow, shown in the next figure.

b. In the Customize Install window, select in whichlanguages, beside English, you want to install the JobScheduling Console and click Install.

Notes:

1) The Job Scheduling Console will display in yourselected language, only if the language matches theregional settings of your computer. If they do not,English will be the default.

2) The Job Scheduling Console will automaticallyadjust to the Country, Language and Timezonesettings of your system or UNIX shell.


102 Version 7.0

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 isdisplayed, click the Done button to close it and completeinstallation.



6.In

stalling

the

Tivoli

Job

Sch

edu

ling

Co

nso

le

13. If you installed the JS Console on AIX or HPUX, you mustupdate the AIXconsole.sh or HPconsole.sh file with the pathwhere you installed Java Development Kit (JDK) 1.1.8. To dothis:

¶ Go to the /bin/java subdirectory of the directory where youinstalled 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 1.1.8.

¶ Save your changes and exit the editor. You can now startthe Tivoli Job Scheduling Console.

Starting the Job Scheduling Console1. Depending on your platform, start the JS Console in the

following way:

¶ On Windows, depending on the shortcut location that youspecified during installation, click the JS Console icon orselect the corresponding item in the Start menu. An MS-DOSwindow, like the one shown in the next figure, opens in thebackground.


104 Version 7.0

On Windows 95 and Windows 98, you can also start the JSConsole from the command line. Just type RUNCON fromthe \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:./AIXconsole.sh

v On Sun Solaris, type:./SUNconsole.sh

v On HPUX, type:./HPconsole.sh

Starting the Job Scheduling Console


6.In

stalling

the

Tivoli

Job

Sch

edu

ling

Co

nso

le

A Tivoli Job Scheduling Console startup window, like the oneshown in the next figure, is displayed.

2. Enter the following information and click the OK button toproceed:

Host MachineThe name of the TMR server or managed nodethat runs the TWS Connector.

LoginAs The TWS username or any other login that isgranted with Tivoli administrator rights and is inthe TWS security file.

Password The password to the host machine running theTWS Connector.

3. If you are logging onto the managed node of Host Machine forthe first time, an information pop-up, like the one shown in thenext figure, is displayed that tells you how to specify a userpreference file for initialization, if it exists.


106 Version 7.0

Read the information and click OK to continue to the OpenLocation window.

4. Use this window to do one of the following:

¶ Specify a URL where user preferences are defined. Enter theURL and select the Load from URL button.

¶ Select the Get from file button to open a window fromwhere 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 nextfigure, is displayed. The Tivoli Job Scheduling Console windowis displayed in the background.

6. In the Welcome window, select a radio button and then click OKto start working with the Job Scheduling Console. Or clickCancel to close the Welcome window and work with the JobScheduling Console without online assistance.



6.In

stalling

the

Tivoli

Job

Sch

edu

ling

Co

nso

le

Uninstalling the Job Scheduling ConsoleThis section provides instructions for uninstalling the Job SchedulingConsole on UNIX and Windows.

UNIX UninstallTo uninstall the Job Scheduling Console on AIX, HP-UX, and SunSolaris, go to the /UninstallerData subdirectory of the installationpath and enter the following command:./Uninstall_JSConsole

Note: Before you run the ./Uninstall_JSConsole make sure you setthe PATH variable. For example:export PATH=$PATH:/usr/jdk1.1.8/J1.1.8

Windows UninstallTo 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. Whenuninstallation completes, it lists any files that the program wasnot able to uninstall. You will have to erase them manually.

Uninstalling the Job Scheduling Console

108 Version 7.0

3. Click Exit to close the window and to terminate the Uninstallprocess.

Note: The uninstall process does not erase the files contained in thedat subfolder.



6.In

stalling

the

Tivoli

Job

Sch

edu

ling

Co

nso

le


110 Version 7.0

Optional TWS CustomizationTopics

After installing TWS, you want to customize it to fit youroperational requirements.This chapter describes optionalcustomization steps for your TWS installation.

Setting Global OptionsGlobal options are customization parameters that specify how yourentire TWS network will work. You define them on your masterdomain manager but they apply to all the workstations in the TWSnetwork.

A Global Options file template containing Tivoli’s default settings islocated in TWShome/config/globalopts.

During the installation process, a working copy of the GlobalOptions file is installed as TWShome/mozart/globalopts. Customizethe working copy to match your needs with a text editor and save it.Then stop and restart TWS. You can make changes at any time, butthey do not take effect until Workload Scheduler is stopped andrestarted or after the start of a new production day. See the TivoliWorkstation Scheduler User’s Guide for details on customizing theglobalopts file. Some global option examples are:

¶ Automatically granting logon users for Windows NT jobs withthe right to Logon as batch job.

7


7.O

ptio

nal

TW

SC

usto

mizatio

nTo

pics

¶ Assigning a specific priority to the job streams created forunscheduled jobs.

¶ Determining the jobs, by state, to be included in job streams thatare carried forward.

¶ Determining whether or not job streams that did not completeare carried forward from the old to the new production plan.

¶ Enabling database auditing.

¶ Determining the number of days for which to save job statistics.

¶ Determining whether user calendars are copied into the newProduction Control file.

¶ Defining whether to enable or disable plan auditing.

¶ Determining whether jobs that are rerun with conman will retaintheir original job names.

¶ Changing the default start time of the TWS processing day.

¶ Defining whether to enable or disable the Time zone option.

Setting Local OptionsLocal options are customization parameters that specify how TWSwill work on a particular workstation. You define your local optionpreferences in a localopts file on the particular workstation.

A Local Options file template containing Tivoli’s default settings islocated in TWShome/config/localopts.

During the installation process, a working copy of the Local Optionsfile is installed as TWShome/localopts. Customize the working copyto match your needs with a text editor and save it. Then stop andrestart TWS. You can make changes at any time, but they do nottake effect until Workload Scheduler is stopped and restarted. Seethe Tivoli Workstation Scheduler User’s Guide for details oncustomizing the localopts file. Some local option examples are:

Setting Global Options

112 Version 7.0

¶ Defining the minimum number of seconds Batchman will waitbefore checking for the existence of a file that is used as adependency.

¶ Defining the number of seconds Batchman will wait betweenchecking the status of an internetwork dependency.

¶ Defining the maximum number of seconds Batchman will waitbefore reporting the expiration of an Until time for a job or jobstream.

¶ Defining the minimum number of seconds Batchman will waitbefore scanning and updating its Production Control file.

¶ Defining the maximum number of seconds Batchman will waitfor a message in its message file.

¶ Specifying whether Batchman will send its startup and shutdownstatistics to its standard list file.

¶ Specifying whether Batchman will send all job status messagesto its standard list file.

¶ Defining the size of the job table used by Jobman.

¶ Preventing Jobman from launching rootjobs in UNIX.

¶ Applying the nice value to jobs launched by Jobman in UNIX.

¶ Defining the maximum number of seconds Jobman will wait fora message in its message file.

¶ Specifying whether all the Workload Scheduler controlprocesses, except Netman, will send their console messages to asingle standard list file.

¶ Specifying the rate, in seconds, at which Mailman checks itsmailbox for messages.

¶ Specifying the maximum number of seconds Mailman will waitfor a response before reporting that a workstation is notresponding.

¶ Specifying the maximum number of seconds Mailman will wait,after unlinking from a non-responding workstation, before itattempts to link to the workstation again.

Setting Local Options


7.O

ptio

nal

TW

SC

usto

mizatio

nTo

pics

¶ Specifying how Mailman will respond to a conman tellop?command.

¶ Defining the maximum number of seconds Mailman will waitbefore unlinking from a workstation that is not responding.

¶ Specifying that Netman will quit when all of its child processeshave stopped.

¶ Changing the TCP port number that Netman responds to on thelocal computer.

¶ Defining the maximum number of seconds Netman will wait fora connection request before checking its message queue for stopand start commands.

¶ Specifying the maximum number of seconds Netman will waitbefore retrying a connection that failed.

¶ Defining the maximum length of TWS console messages.

¶ Defining the number of seconds the Writer process will wait foran incoming message before checking for a termination requestfrom Netman.

¶ Defining the number of seconds the Writer process will waitbefore exiting if no incoming messages are received.

Automating the Production CyclePre and post-production processing can be fully automated by addingthe Tivoli-supplied final job stream, or a user-supplied equivalent, tothe TWS database along with other job streams. A copy of theTivoli-supplied job stream can be found in TWShome/Sfinal, and acopy of the job script can be found in TWShome/Jnextday. You mayfind it helpful to have printed copies to assist in understanding theturnover process.

The final job stream is placed in production everyday, and results inrunning a job named Jnextday prior to the start of a new day. Thejob performs the following tasks:

1. Links to all workstations to ensure that the master domainmanager has been updated with the latest scheduling information.

Setting Local Options

114 Version 7.0

2. Runs the schedulr command to select job streams for the newday’s production plan.

3. Runs the compiler command to compile the production plan.

4. Runs the reptr command to print pre-production reports.

5. Stops TWS.

6. Runs the stageman command to carry forward uncompleted jobstreams, log the old production plan, and install the new plan.

7. Starts TWS for the new day.

8. Runs the reptr and the rep8 commands to print post-productionreports for the previous day.

9. Runs the logman command to log job statistics for the previousday.

In the TWS manual set, the terms final and Jnextday are used whenreferring to both the Tivoli-supplied versions, and any user-suppliedequivalents.

Customizing the final Job StreamBefore using the final job stream, you can modify it to meet yourneeds, or you can create a different job stream to use in its place.

When creating your own job stream, model it after the one suppliedby Tivoli. If you choose to do so, consider the following:

¶ If you choose to change the way stageman generates log filenames, remember that reptr and logman must use the samenames.

¶ If you would like to print the pre-production reports in advanceof a new day, you can split the Jnextday job into two jobs. Thefirst job will execute schedulr, compiler and reptr. The secondjob will stop TWS, execute stageman, start TWS, and executereptr and logman. The first job can then be scheduled to run atany time prior to the end of day, while the second job isscheduled to run just prior to the end of day.

Automating the Production Cycle


7.O

ptio

nal

TW

SC

usto

mizatio

nTo

pics

Adding the final Job StreamIf you followed the instructions explained in “Configuring a MasterDomain Manager After Installation” on page 50 on UNIX, or if youinstalled TWS via the Setup program in NT, the final job stream isalready added to the database. If not, follow these steps to add thefinal job stream, or a user-supplied equivalent.

1. Log in as the TWS or maestro user on the master domainmanager.

2. At the command prompt, execute the following command onUNIX:composer “add Sfinal”

or the following command on Windows NT:composer “add Sfinal”

To add your own job stream, use its name in place of Sfinal.

Starting a Production CycleIf it has not been started before, or if it becomes necessary to start anew production day at a time other than the defined start of day,follow these steps:

1. Log in as the maestro user on the master domain manager.

2. At a command prompt, execute the Jnextday job by entering thefollowing command:Jnextday

This will perform pre-production processing and start TWS’sproduction processes.

Managing the Production EnvironmentThis section provides information on changing the start of day forTWS and creating a plan to process future or past days processing.

Automating the Production Cycle

116 Version 7.0

Choosing the TWS Start of DayThere are three common choices for the start of the production day.

¶ early morning

¶ late afternoon

¶ midnight

These are a few of the scheduling implications:

Start and Deadline Times

Start times (AT keyword) specified are always in relationship to theTWS production day start time. You may need to add “+ 1 day” tojob streams whose jobs process across production days. Also becertain that the deadline (UNTIL keyword) time comes after the mstart time.

On keyword

Production and calendar days do not have to be the same. If yourproduction day starts at 06:00 a.m. (the default setting), 05:59 a.m.will be the last minute of the production day. A Job Stream definedto run ON MONDAY at 05:30 will be selected on Monday and willrun on the calendar day Tuesday at 5:30 a.m.

Carryforward keyword

Placing the start of day near midnight to correspond with thecalendar day will tend to produce a large number of carried forwardjob streams. This may increase the complexity of managing the datacenter.

Changing the Start of DayThe start of day for TWS is when the final Job Stream is run andthe TWS processes are stopped and restarted. To specify the start ofday for TWS:

1. Modify the start option in the Globalopts file. This is the starttime of TWS’s processing day in 24 hour format: hhmm(0000-2359). The default start time is 6:00 A.M.

Managing the Production Environment


7.O

ptio

nal

TW

SC

usto

mizatio

nTo

pics

2. Modify the start time (AT keyword) of the final job stream torun one minute before the end of day.

If you want to set the start of the production day to midnight:

1. Set the start time of the final job stream to midnight.

2. Set the start option in the Globalopts file to 0001.

Otherwise, by having the start option set to 0000 and Jnextdaysetto 2359, you risk selecting schedules or job streams for the day thatjust ended, since the schedulr command uses the system date andsmall networks can sometimes get to the schedulr run beforemidnight.

Creating a Plan for Future or Past DatesYou can create a plan that executes processing normally scheduledfor a future or past day of processing. This procedure effectivelyrecreates any specified day of processing. You may need to use thisprocedure if you lost a day of processing due to an emergency.

1. Unlink and stop all workstations in your TWS network with thefollowing commands:conman “unlink @!@;noask”

conman “stop @!@;wait”

This stops all processing in the network.

2. Run the schedulr command with the date option to create aprodskedfile:schedulr -date MM/DD/YY

With the date option you can specify to create a plan based on afuture or past day of processing.

3. Run the compiler command to create a symnew file:compiler (-date MM/DD/YY)

You can use the date option with the compiler to specify today’sdate or the date of the day you are trying to recreate. This optionmay be neccessary if you have job streams that contain datesensitive input parameters. The scheddate parameter is keyed off


118 Version 7.0

the date specified with the compiler command. If you do notspecify a date, it defaults to the date entered with the schedulrcommand.

4. Run console manager to stop TWS processes:conman stop @!@

5. Run stageman to create the new symphony file:stageman

6. Run console manager to start TWS processes:conman start



7.O

ptio

nal

TW

SC

usto

mizatio

nTo

pics

120 Version 7.0

Migrating to TWS 7.0

The information in this appendix may be useful when migratingfrom Maestro versions 5.x or 6.x to Tivoli Workload Scheduler 7.0

The Tivoli Management Framework for non-Tivoliusers

The Tivoli Management Framework is an open, object-orientedframework that includes a set of managers, brokers, and agents thatconform to the Object Management Group/Common Object RequestBroker Architecture (OMG/CORBA) specification. OMG/CORBAtechnology allows major differences between computer operatingsystems to be hidden from the user, and it allows key services to beencapsulated in objects that can be used by multiple managementapplications. The Tivoli Management Framework provides platformindependence, a unifying architecture for all applications, and a richset of application program interfaces (APIs) which have beenadopted by the Desktop Management Task Force (DMTF) and theOpen Group (formerly X/Open) as a basis for a systems managementframework. Tivoli APIs provide common network and systemsmanagement services, including scheduling, transaction support,configuration profiles, and a generic object database user facility.

The basic unit of Tivoli Management Framework functionality is theTivoli Management Region. A TMR consists of one TivoliManagement Server and the clients that the server manages. TheTMR server holds the database for that TMR. Depending on the sizeand requirements of an environment, more than one TMR may be

A


A.

Mig

rating

toT

WS

7.0

defined. If multiple TMRs are present, they can either stand alone orthey can be linked together to share information and resources.Administrators with the proper role can manage all exchangedresources in a set of connected TMRs from a single system as if theresources are all in the local system’s TMR. In general, a TMRserver can support up to 200 fully managed nodes. With the releaseof Tivoli Management Framework 3.6, new services are placed onthe TMR server and some managed nodes to allow those nodes toact as gateways for hundreds of endpoints. This significantlyincreases the scope of a single TMR.

The Tivoli Management Framework provides a server-basedimplementation of a CORBA Object Request Broker (ORB) andbasic object adapter (BOA). It also provides related object,management, and desktop services and includes an implementationof the APIs adopted by Open Group for a systems managementframework. The object dispatcher (oserv) is the main component ofthe framework runtime. It is implemented as a single multi-threadedprocess and runs in the background of each Tivoli client within aTMR and of the Tivoli Management Server for that TMR. Theobject dispatcher consists of an object request broker, the BOA, andrelated services. The object dispatcher running on the TivoliManagement Server provides additional services, including securityand implementation inheritance resolution.

A Tivoli managed node runs the same software that runs on a TMRserver. From a managed node you can run the Tivoli desktop anddirectly manage other Tivoli managed resources. A managed nodehas its own oserv service that runs continuously and communicateswith the oserv service on the TMR server. A managed node alsomaintains its own client database. The primary difference between aTMR server and a managed node is the size of the database. Also,you cannot have a managed node without a TMR server in a TivoliManagement Region.

The Tivoli Management Framework for non-Tivoli users

122 Version 7.0

Installation ConsiderationsThe Workload Scheduler engine is completely separated from theTivoli Management Framework. It is not a Tivoli ManagementFramework application. However, the TWS Connector is a TivoliManagement Framework application. The TWS Connector isrequired if you want to use the Job Scheduling Console, the newgraphical user interface. Tivoli Workload Scheduler 7.0 includes alsothe legacy GUI, but only the JS Console has Time zone support.Moreover, the JS Console is required if you want to operate bothOperations Planning and Control (OPC) and Tivoli WorkloadScheduler engines from the same user interface.

Where Can The JS Console Client Be InstalledThe Job Scheduling Console provides gcomposer and gconmanfunctionality through a true graphical user interface. It can beinstalled on Sun Solaris, AIX, HP-UX, and Windows NT, 95 and 98.It requires neither the Tivoli Management Framework nor TivoliWorkload Scheduler to be installed on the client. The onlyprerequisite is that the client system be connected via TCP/IP to atleast one of the nodes running the TWS Connector.

Where Should The TWS Connectors Be InstalledThe TWS Connector is a Tivoli Management Framework service thatenables JS Console clients to communicate with the TWS engine. ATWS Connector can be installed on a Sun Solaris, AIX, HP-UX, orWindows NT system that must also be a Tivoli Management Regionserver or managed node.

If you want to install the TWS Connector in your TWS domain, butyou have no existing TMRs and you are not interested inimplementing a full Tivoli management environment, then youshould install the Tivoli Management Framework as a unique TMR(and therefore install as a TMR server) on each node that will runthe TWS Connector.

You can install TWS Connectors on workstations other than themaster domain manager. This will enable you to view the version ofthe Symphony file of this particular workstation. This may beimportant for using the JS Console to manage the local parameters

Installation Considerations


A.

Mig

rating

toT

WS

7.0

database or the submit command directly to the workstation ratherthan submitting through the master. Your workstation must be eithera managed node or a TMR server in the management region toinstall the connectors on a workstation.

Installing TWS Connectors on FTAsNon-Tivoli environment users:

¶ When you create an FTA, be sure you install the TWS enginebefore you install the TWS Connector.

¶ Before you begin, ensure that the Tivoli ManagementFramework is installed on the FTA and that the system is in thesupported platforms list for the TWS Connector (see “SupportedPlatforms” on page 79).

¶ Follow the installation instructions described in “Installing theTWS Connector” on page 77.

Tivoli environment users:

¶ Typically, the TWS master domain manager resides on amanaged node. You must first install the Job SchedulingServices/TWS Connector classes on the TMR server.

¶ Be careful not to create an instance on a managed node thatdoes not have the TWS engine installed.

All users:

¶ Be aware that during the TWS Connector installation processyou will be prompted for a TWS instance name. This name willbe displayed in the Job Scheduling tree of the JS Console. Toavoid confusion, you should use a name that includes the nameof the FTA.

¶ If you are installing the TWS Connector on several FTAs withina network, keep in mind that the instance names must be uniqueboth within the TWS network and the Tivoli ManagementRegion.

Installation Considerations

124 Version 7.0

Backup Master ConsiderationsIf you want to install the TWS Connector on the backup master, youhave no existing TMRs, and you are not interested in implementinga full Tivoli management environment, then you may want to installa new TMR server on the backup master.

If on the backup master you install a different TMR server than themaster, be sure to enable the same entries as on the master, that is:

¶ Start

¶ Plan and database audit levels

¶ Timezone enable

Dealing with Non-tier 1 Masters in an ExistingMaestro Network

If your master domain manager does not run on a supported platformto install the Tivoli Management Framework and the TWSConnector, and you want to be able to use the Job SchedulingConsole, you can choose from the following three options:

¶ Move the master domain manager to one of the supportedplatforms.

¶ Create a backup master on a supported platform.

¶ NFS mount the master databases to an FTA.

Moving the Backup MasterTo move the master domain manager (from UNIX to UNIX):

1. Choose an existing FTA in the network or create one. If youcreate an FTA, be sure you define it with Resolve Dependenciesand Full Status enabled.

2. On the master domain manager, tar maestro/mozart/* andmaestro/../unison/network/*.

3. Untar these files in the FTA in directories with the same name.

Backup Master Considerations


A.

Mig

rating

toT

WS

7.0

4. Do not copy parameters or parameters.KEY from the homedirectory or you will overwrite parameters that are unique to theFTA. Create a list of parameters from both machines, addingthe required ones to the FTA.

5. On the FTA, edit the globalopts file to change the name of themaster to that of the FTA.

6. On the old master, use the switchmgr command to switch tothe new master.

7. Cancel the existing final schedule in the current day production.

8. Add the final schedule onto the new master (usecomposer “modify sched=oldmastername#final”

and change the workstation id on the schedule line).

9. After saving and adding, delete the oldmastername#finalschedule with the command:composer “delete sched=oldmastername#final”

10. Submit the new final schedule into daily production.

11. On the old master, edit the globalopts file to reflect the name ofthe new master.

Note: It is not necessary to edit all the global options for eachworkstation in the network. The nodes will acknowledgethe new master at Jnextday time when the masterinitializes them.

Creating a Backup MasterTo create a backup master:

1. Install the Tivoli Management Framework. See the TivoliEnterprise Installation Guide for reference.

2. Install the TWS engine. See “Installing the TWS Engine onWindows NT” on page 23 or “Installing the TWS Engine onUNIX” on page 47.

3. Install the TWS Connector. See “Installing the TWS Connector”on page 77.

Dealing with Non-tier 1 Masters in an Existing Maestro Network

126 Version 7.0

4. Customize the workstation with TWS security and local options.See “Setting TWS Security” on page 63 and “Optional TWSCustomization Topics” on page 111.

5. Define the workstation in the TWS network. Either use theComposer cpuname command or the Create Workstationswindow in the Job Scheduling Console. Be sure you define itwith Resolve Dependencies and Full Status enabled. See theTivoli Workload Scheduler Reference Guide or the TivoliWorkload Scheduler User’s Guide.

Mounting MDM DatabasesYou can NFS mount the following master databases on an FTA thatruns on a supported platform:

¶ /usr/lib/maestro/mozart/globalopts (the operational copy)

¶ /usr/lib/unison/network/cpudata

The FTA must have Full Status and Resolve Dependencies enabledin its workstation definition.

Before mounting the databases, make certain that the file systemcontaining the required directories has been included in the/etc/exports file on the master workstation. If you choose to controlthe availability of the file system, make the appropriate entries in the/etc/hosts or /etc/netgroup file in the master.

The mount point on the FTA must be the same as the master. Forexample, on the FTA:

cd twshome/etc/mount mastername:mozart mozart/etc/mount mastername:../unison/network ../unison/network

To have the databases mounted automatically, you can enter themounts in the /etc/checklist file.

If you use this solution, be aware that the parameters database in theFTA is not the master’s but a local copy. This becomes an issue ifyou use parms as part of the job definitions (in the task or login



A.

Mig

rating

toT

WS

7.0

name), because at Jnextday time all the parameters referenced withthe ^(carat) symbol in job definitions are expanded from theparameters database in the master. You have two possibleworkarounds for this issue:

¶ Create a script that uploads and changes the parameter valuesfrom the FTA to the master. Run this script just before Jnextday.Making Jnextday dependent on it will make sure that the parmsare uploaded successfully before Jnextday sets up production forthe following day.

¶ On the master cpu, move the parameters database to the mozartdirectory. Create a link from the master to the home directory.Next, on the FTA create a link from the parameters database inmozart to twshome.

If you wish to enable the Timezone feature in the Job SchedulingConsole, you also need to edit the local globalopts file on the FTAto set the Timezone Enableentry.

Dealing with Non-tier 1 Backup Masters in anExisting Maestro Network

You can still keep your existing backup master if it is not in thesupported (tier 1) platforms. Keep in mind, however, that this willprevent you from using the Job Scheduling Console in thatenvironment. Follow the instructions in the preceding section, shouldyou decide to switch machines.

Running Multiple Windows in the JS ConsoleIf you require more than seven JS Console active windows on anyclient, then you need to install another instance of the JobScheduling Console on that system. During installation, be sure tochoose a unique location for the second instance. On Windows NT,the location of the shortcut must be unique as well.


128 Version 7.0

Making an Existing Security File WorkIn order to preserve an existing security structure when migrating toTWS 7.0, you need to create a Tivoli (TME) administrator in theTivoli Management Framework server for each Maestro securitydefinition you have, and then include a definition for thisadministrator in the Security file. See the Tivoli ManagementFramework documentation for details on creating a TMEadministrator. See “Setting TWS Security” on page 63 or the TivoliWorkload Scheduler User’s Guide for details on how to edit theSecurity file.

Adding TME AdministratorsAssume that you want to migrate your Maestro network to TWS 7.0and that the system currently hosting the master domain manager isone of the supported platforms. You want to install the TWSConnector on it so that you can have a number of JS Consoleclients. Therefore, you first install the Tivoli ManagementFramework. Suppose you install a TMR server.

The current Security file on your master is the following:############################################################ Security File############################################################ (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE# MASTER DOMAIN MANAGERuser mastersm cpu=$master + logon=maestro,rootbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job access=@schedule access=@resource access=@prompt access=@file access=@calendar access=@cpu access=@parameter name=@ x name=r@ access=@userobj cpu=@ + logon=@ access=@end############################################################ (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.user sm logon=maestro,rootbegin

Making an Existing Security File Work


A.

Mig

rating

toT

WS

7.0

# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job cpu=$thiscpu access=@schedule cpu=$thiscpu access=@resource cpu=$thiscpu access=@prompt access=@file access=@calendar access=@cpu cpu=$thiscpu access=@parameter cpu=$thiscpu

x name=r@ access=@end###########################################################

Suppose that you want these two users to use the JS Console. Afteryou install the TMF sofware, in the Tivoli Desktop you create anadditional TME administrator (beside the default one created by theinstallation process) for each Maestro user. You call one mastersmand the other sm. You then add the respective definitions so that theSecurity file looks like this:############################################################ Security File############################################################ (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE# MASTER DOMAIN MANAGERuser mastersm cpu=$master + logon=maestro,rootbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job access=@schedule access=@resource access=@prompt access=@file access=@calendar access=@cpu access=@parameter name=@ x name=r@ access=@userobj cpu=@ + logon=@ access=@end############################################################ (2) TME ADMINISTATOR DEFINITION FOR MAESTRO OR ROOT USERSLOGGED IN ON THE# MASTER DOMAIN MANAGERuser mastersm cpu=$framework + logon=mastersmbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job access=@


130 Version 7.0

schedule access=@resource access=@prompt access=@file access=@calendar access=@cpu access=@parameter name=@ x name=r@ access=@userobj cpu=@ + logon=@ access=@end####################################################################################################################### (3) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.user sm logon=maestro,rootbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job cpu=$thiscpu access=@schedule cpu=$thiscpu access=@resource cpu=$thiscpu access=@prompt access=@file access=@calendar access=@cpu cpu=$thiscpu access=@parameter cpu=$thiscpu

x name=r@ access=@end##############################################################(4) TME ADMINISTRATOR DEFINITION FOR MAESTRO ORROOT USERS LOGGED IN ON ANY# WORKSTATION OTHER THAN THE MASTER DOMAINMANAGER.user sm cpu=$framework + logon=smbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job cpu=$thiscpu access=@schedule cpu=$thiscpu access=@resource cpu=$thiscpu access=@prompt access=@file access=@calendar access=@cpu cpu=$thiscpu access=@parameter cpu=$thiscpu

x name=r@ access=@end##########################################################



A.

Mig

rating

toT

WS

7.0

The new Security file grants the same privileges to the original usersalso on the Job Scheduling Console.

Furthermore, on the TMR server you could add two new logins forTME administrator mastersm:

[email protected]@london.production.com

So that any authorized user who logs into rome or london asmaestro will acquire the privileges granted to mastersm.

Managing SecurityChanges to the Security file take effect when one of the followingWorkload Scheduler programs is stopped and restarted:¶ conman¶ gconman¶ composer¶ gcomposer¶ TWS Connector

Simply exit the programs. The next time they are run, the newsecurity definitions will be recognized. For TWS Connectors, use thewmaeutil command to stop them. They will be automaticallyrestarted with a refresh of any query in the Job Scheduling Console.

Stopping Connectors to Implement ChangesA TWS Connector starts up automatically when someone issues acommand from the JS Console. However, you have to stop itmanually. On Windows NT, you must stop the TWS Connectorbefore running the makesec command. On UNIX, you can stop iteither before or after running makesec.

You use the wmaeutil command to stop the TWS Connector.

Running WMAEUTILTo run the wmaeutil command:

1. Set the Tivoli environment:


132 Version 7.0

¶ From a UNIX command line: ./etc/Tivoli/setup_env.sh


2. Enter the following command:wmaeutil ALL -stop

Legacy GUI LimitationsThe legacy graphical user interface lacks time zone support. Fromthe legacy GUI, you cannot modify a workstation or a schedule thathad time zone support added from the command line interface orfrom the JS Console.

Using the Legacy GUI on AIX 4.2If you run AIX Version 4.2, you may need to install patchxlC.rte.3.6.6.0 in order to use the legacy GUI.

To know whether to install this patch, run the following command:lslpp -l xlC.rte

The command should return the following information:Fileset

Path:/usr/lib/objrepos xlC.rteLevel 3.6.6.0State COMMITTEDDescription

C Set ++ for AIX Application Runtime

If Level is below 3.6.6.0, then you need to apply the patch.

Timezone ConsiderationsThe following is the correct method of implementation:

1. Load TWS Version 7.0.

The default setting is for time zone not enabled (timezoneenable entry in globaloptions).The database will allow time

Managing Security


A.

Mig

rating

toT

WS

7.0

zones to be specified for workstations but not on start anddeadline times within job streams in the database. The plancreation (Jnextday) will ignore any time zones that are present inthe database. You will not be able to specify any time zonesanywhere in the plan.

2. Define workstation time zones.

Set the time zone of the master workstation, of the backupmaster, and of any FTAs that are in a different time zone thanthe master. No time zones will be allowed in the database forstartand deadline times. No time zones will be allowed anywherein the plan at this point, because the timezone enable entry inglobaloptions is still set to NO.

3. When workstation time zones have been set correctly, settimezone enable to YES in the globaloptions file. This setting,and the timezone definition in the master workstation, will enablethe TWS network to take advantage of timezone support.

At this point, all users will be able to use time zones anywherein the database, although they should wait for the next run ofJnextday to use them on start and deadline times. Until Jnextdayruns, they will not be able to use time zones in the plan. Thenext time Jnextday runs, time zones will be carried over to theplan, and the JS Console and the backend will allow thespecification of time zones anywhere in the plan.

4. Start to use time zones on start and until times where you needthem.

You can now use all timezone references in the database and inthe plan with both the JS Console and the CLI.

For MPE fault-tolerant agents and for AS400 LFTAs (Version6.1) you can specify timezone information only from the JSConsole.

Timezone Considerations

134 Version 7.0

Propagating User Preferences to Other Users(Custom Views/Queries)

This option, available with the Job Scheduling Console, enables afirst time JS Console user to copy another user’s preferences. It canalso be exploited to propagate a set of preferences to multiple users.

User preferences are stored in a file named GlobalPreferences.ser.The file contains the names and the details, including filters, of allthe queries (or lists) that were saved during a session. Every timeyou close the JS Console, GlobalPreferences is updated with anyqueries you saved in, or deleted from, the Job Scheduling Tree.

GlobalPreferences is saved locally in a user directory in...\JSConsole\dat\.tmeconsole on Windows or in $HOME/.tmeconsoleon UNIX. The user directory has a composite name that matches thefollowing:

¶ The name of the TME Administrator associated with the TWSConnector accessed by the user. It is followed by the at (@)sign.

¶ The name of the system running the TWS Connector followedby the undescore(_) sign.

¶ The regional settings of the operating system where the TWSConnector is installed. The id changes dynamically if the userlogs onto the same Connector and finds that the regional settingshave changed.

Note: The first two are the names you enter in the Job SchedulingConsole Startup window to start the JS Console.

For example, suppose that, to start the JS Console, you log for thefirst time to machine fta12,where the TWS Connector was installedby TME Administrator tws12adm. A user directory namedtws12adm@fta12_en (where en stands for English regional settings)is created under the path described above in your workstation.

Propagating User Preferences to Other Users (Custom Views/Queries)


A.

Mig

rating

toT

WS

7.0

Every time you log onto a different Connector, a new user directoryis added. And every time you close the JS Console, aGlobalPreferences.ser is created or updated in the user directory thatmatches your connection.

When users log onto a Connector for the first time, an OpenLocation window asks if they want to use an existingGlobalPreferences.ser file from a connected network drive or aURL. If you want to propagate a specific set of queries to new users,you first make the corresponding GlobalPreferences.ser available,and then you ask the users to specify the file or the URL in theOpen Location window. If you want to propagate a preference file toexisting users, you have them replace their ownGlobalPreferences.ser with the one you have prepared.

Note: A different GlobalPreferences.ser file exists in...\JSConsole\dat\.tmeconsole\TivoliConsole on Windows or in$HOME/.tmeconsole/TivoliConsole on UNIX. This filecontains preferences that affect JS Console presentation andshould not be propagated.

Backing Out of an Expanded DatabaseMaestro 6.0 introduced the use of expanded databases. If you stillrun Maestro 5.x networks and you want to migrate to TWS Version7.0, however, you do not have to expand your databases unless youwant to. See “Database Creation” on page 17 for an explanation ofhow to expand an existing database.

If for some reason you want to back out of an expanded database,you can choose between to methods for doing so.

¶ Use the following method if no scheduling objects were createdor modified since the database was expanded. If any schedulingobjects were created, they can be added to the database manuallyafter returning to the non-expanded state. If modifications weremade, they will need to be reapplied. Follow these steps:

1. On the master, restore the backup up files in the mozart.olddirectory to the mozart and unison/network directories:

Propagating User Preferences to Other Users (Custom Views/Queries)

136 Version 7.0

a. Move the following files to the unison/networkdirectory:

v cpudata

v cpudata.key

v userdata

v userdata.key

b. Move all the other files to the mozart directory.

2. Ensure that the Global Option expanded version is set toNO.

3. Verify that the cpu names in globalopts and localopts areeight characters maximum.

¶ Use the following method if many scheduling objects werecreated or modified since the database was expanded. Also usethis method when you want to back out of the expandeddatabase and scheduling objects have long names.

1. Enter the following composer commands to create files thatcontain all the database information for the schedulingobjects. The files will be created only if those objects existin the database:create cpu.txt from cpu=@

create jobs.txt from jobs=@#@

create sched.txt from sched=@#@

create cal.txt from calendars

create prompt.txt from prompts

create parms.txt from parms

create param.txt from parameters

2. Move the object files in the mozart and unison/mozartdirectories to a temporary directory. The globalopts file andthe runmsgno files remain in the mozart directory. Inglobalopts verify that the cpu name is maximum eightcharacters and that expanded version is set to NO. Also,verify that in localopts the cpu name is maximum eightcharacters.

3. Modify the following files you created in the first step:

Backing Out of an Expanded Database


A.

Mig

rating

toT

WS

7.0

v cpu.txt

v jobs.txt

v sched.txt

Edit all cpu, domain, job, schedule, and user names to beeight characters maximum in length. Also, verify the lengthof job file names and commands.

4. Rename the following files in the unison/network directory:

v cpudata

v cpudata.key

v userdata

v userdata.key

5. Enter the following composer commands to populate the newnon-expanded database with the scheduling objects:add cpu.txt

add jobs.txt

add sched.txt

replace cal.txt

replace prompt.txt

replace parms.txt

replace param.txt

6. Rename the Symphony file prior to executing Jnextday.

Migrating on Windows NTOn Windows NT workstations, if you are migrating to TWS 7.0from Maestro 5.2, login as the maestro user. If you are migratingfrom Maestro 6.x, login as Administrator.

Migrating from Maestro 5.2 on Windows NT AgentsIf you are migrating from Maestro 5.2, be sure that the followingprograms have the minimum revision levels indicated below:

Backing Out of an Expanded Database

138 Version 7.0

Program Revision

mailman 3.34.1.17.1.1

writer 3.31.1.11.1.1

To get this information, run the programs with the -voption as shownnext:mailman -v

writer -v

If the revision levels are less than these values, then you must applypatch 5.2-MAE-0054 (byte order fix) before you migrate to TWS7.0. This patch prevents Batchman from running into stopping errorswhen used after migration.

Migrating on Windows NT


A.

Mig

rating

toT

WS

7.0

140 Version 7.0

Networking with MPE

This appendix describes the configuration requirements and operationof Tivoli Workload Scheduler/Maestro networks containing a mix ofMPE, UNIX, and Windows NT computers. These networks conformto the TWS standard hierarchy of master, fault-tolerant agent (slave)and standard agent cpus, which are characterized as follows:

¶ The master workstation can be either an MPE iX*, UNIX, orWindows NT computer. It is the administrative hub in anetwork. It contains the Maestro master scheduling files, andperforms all post-production (end-of-day) and pre-production(start-of-day) processing for the network. When a newproduction day begins, the master processes its own schedules,as well as those of standard agent cpus. It launches its own jobsand issues launch requests to execute jobs on standard agents.When UNIX or NT masters are used, it is also known as theMaster Domain Manager. *MPEiX cannot be a master to aWindows NT computer as there is no equivalent USERDATAdatabase on the MPE product in which to store NT userpassword definitions.

¶ MPE slave cpus are the equivalent of UNIX and Windows NTfault-tolerant agents. For administrative functions, they rely onthe master workstation. When a new production day begins, theyprocess their own schedules and launch their own jobs.

¶ Standard agent cpus are UNIX or Windows NT computers. Foradministrative purposes, they rely on the master workstation.

A


A.

Netw

orkin

gw

ithM

PE

When a new production day begins, they execute jobs only inresponse to launch requests from the domain manager (MasterDomain Manager by default).

Network ConsiderationsYou should review this appendix in its entirety before deciding howto configure a mixed TWS/Maestro network. Following is asummary of basic considerations:

¶ Object definitions and scheduling for slaves and fault-tolerantagents must be done on the master domain manager if the slavesand fault-tolerant agents are not the same platform as the master.

¶ The standby master domain manager, if required, must be thesame platform as the master domain manager.

¶ Security considerations are different on each platform: MPE,UNIX and Windows NT.

¶ UNIX and NT master domain managers support hierarchicallayout where you may have several sub-domain managers witheach type of supported platform agents. MPE masters will onlysupport a ‘flat” architecture. MPE systems can be used as FTAs(slaves) in any hierarchical domain layout.

¶ An MPE master cpu can link to MPE slaves using either NS orTCP/IP. A UNIX or Windows NT master cpu uses only TCP/IP.

Scheduling ConsiderationsBe aware of the following facts:

¶ Any combination in a TWS/maestro network that includes anMPE workstation requires that the UNIX/NT counterpartsoperate in unexpanded mode (cannot use scheduling objectnames greater than eight characters).

¶ Because a UNIX or Windows NT fault-tolerant agent’s securityis independent of the MPE master, it also can be set to fullstatus mode and be used for central console management of thenetwork. This will enable users to take advantage of graphicalinterfaces, and more powerful and flexible command sets.

Networking with MPE

142 Version 7.0

However, the fault-tolerant agent is still subject to certainlimitations on some Conman commands. These limitations are asfollows:

v Unable to submit jobs using the CONMAN SUBMIT JOBcommand.

v Unable to submit schedules using the CONMAN SUBMITSCHEDULE command.

v Unable to rerun jobs using the CONMAN RERUN ;FROMand ;FILE options.

v Unable to add pre-defined (or global) prompt dependencieswith the ADDDEP command.

v Unable to use the CONMAN ADDDEP command to addglobal (pre-defined) prompt dependencies.

v Unable to use the CONMAN DISPLAY command for jobsand schedules.

¶ The docommand feature is fully-functional in UNIX andWindows NT for job definitions and for the conmansubmitcommand. This feature is not supported in MPE.

¶ UNIX and Windows NT Composer can add and modify allscheduling objects (including schedules and jobs) from a singleedit file.

¶ INET dependencies are not possible for the MPE master. INETdependencies can however reference MPE fault-tolerant-agents ifthe domain manager runs on UNIX or Windows NT.

InstallationInstallation instructions for TWS for UNIX and Windows NT arefound in this guide. To install Maestro for MPE for the first time,refer to section 2 of the Maestro User Guide for the MPE SystemUser.

Network Considerations


A.

Netw

orkin

gw

ithM

PE

Setup and ConfigurationThis section outlines the steps needed to set up TWS/Maestronetworks after installation with UNIX agents under MPE, and MPEagents under UNIX or Windows NT master workstations.

Note: For details about specific commands and transactions, see thisguide and the MaestroUser Guide for the MPE System User.

Setting Up a UNIX agent with MPE MasterOn the MPE master, use the ARRANGER program to do thefollowing:

1. Use the ACPU transaction to create a cpu definition for UNIXcpu in the network.

2. Use the CSYS transaction to define this cpu as the master.

3. Use the ALNK transaction to define the following links:

a. Master-to-master: define a link with TCP/IP commands.

b. Master-to-UNIX: define a link with TCP/IP commands.

4. After UNIX agent tasks below are complete, the agents will beinitialized and started at the next run of Jnextday on the masterdomain manager.

On each UNIX fault-tolerant agent and standard agent, do thefollowing:

1. Modify the Global and Local Options files to meet yourrequirements. Default values, suitable for most installations, areinserted by the customize and set up programs.

2. Modify and install the Security file. If you wish, you can do thison one computer and then copy the file to each of the otherUNIX systems.

3. Issue the StartUp command on each UNIX agent to start thenetman daemon (if it is not already started).

Setup and Configuration

144 Version 7.0

Setting Up an MPE FTA with UNIX or Windows NTA TWS network containing MPE computers must be installed in“unexpanded” mode. After installing the software, follow the stepsbelow to configure each cpu in the network.

On the UNIX or Windows NT master, follow these steps:

1. Use JS Console GUI or CLI composer to create workstationdefinitions for all workstations. The definitions also include linkinformation (combination of Arranger’s ACPU and ALNKtransaction).

2. Modify the Global Options files to meet your requirements. Thefollowing Global Options take the place of ARRANGER CTP1parameters for MPE slaves. These are not present in theglobalopts file by default and they will need to be added ifdesired:

rules mode={yes|no}Replaces CTP1-Complete Control Mode. If set to yes,you must also set batchman scheduleto yes.

all userjobs in userjobs schedule={yes|no}Replaces CTP1-Place all userjobs in USERJOBSschedule. You must set this to no if rules mode is set toyes.

set mpe job pri to zero={yes|no}Replaces CTP1-Force MPE priority to 0 for all userjobs.You must set this to no if all userjobs in userjobsscheduleis set to yes.

batchman schedule={yes|no}Replaces CTP1-Assign priority 10 to Batchman-createdschedules. This also affects UNIX and Windows NTworkstations.

3. After the MPE agent tasks below are complete, the agents willbe initialized and started at the next run of Jnextday on themaster domain manager.



A.

Netw

orkin

gw

ithM

PE

On each MPE slave, use the ARRANGER program to do thefollowing:

1. Use the ACPU transaction to create definitions for this cpu andthe master.

2. Use the CSYS transaction to identify this cpu and the master.

3. Use the ALNK transaction to define a slave-to-master linkcontaining TCP/IP commands.

4. Use the CTP2 and CTP3 transactions to define CONMAN andBATCHMAN parameters.

5. Mstream or stream the JBATCHMN.MAESTRO.CCC job toactivate the NETMAN process. To be successfully started andinitialized via TCP/IP, the NETMAN process must already berunning on the MPE slave.

Operational Differences Between PlatformsThis section describes the exceptions that apply in a network ofMPE, UNIX, and Windows NT workstations with an MPE, UNIX,or Windows NT workstation defined as the master. For additionalinformation about network operation refer to the Tivoli WorkloadScheduler Reference Guide, the Tivoli Workload Scheduler Planningand Installation Guide, and the Maestro User Guide for the MPESystem User (available from ROCsoftware).

On the MPE Master

Arranger and Composer¶ All object definitions and scheduling for UNIX fault-tolerant

agents and standard agents must be done with COMPOSER andARRANGER on the MPE master.

¶ The MPE COMPOSER does not support the docommandfeature in job statements for schedules that run on UNIX andWindows NT fault-tolerant agents and standard agents.

¶ Recovery options for UNIX and Windows NT jobs must bedocumented with the ARRANGER XJOB transaction.


146 Version 7.0

¶ In the MPE scheduling language, scriptname is not a validkeyword. Instead, use jobfilename to define UNIX andWindows NT job scripts. For example:jobfilename " pathname" streamlogon user

Conman¶ The docommand option is not available in the submit command

to submit commands for execution on a UNIX or Windows NTcpu.

¶ Wildcard and selectionset parameters for certain conmancommands are not supported from an MPE master but can beused from a full-status UNIX FTA.

On UNIX Fault-Tolerant Agents

ComposerYou can only use Composer to document, modify, and deleteMaestro parameters (parms), which are local to each workstation.

ConmanThe following CONMAN operations are not permitted:¶ Submit jobs using the CONMAN SUBMIT JOB command.¶ Submit schedules using the CONMAN SUBMIT SCHEDULE

command.¶ Add pre-defined (or global) prompt dependencies with the

ADDDEP command.¶ Use the ;FROM and ;FILE options in the RERUN command.¶ Display jobs and schedules using the DISPLAY command.

On the UNIX or Windows NT Master

Composer¶ All object definitions and scheduling for MPE slaves must be

done with the JS GUI Console or in the CLI composer on theUNIX or Windows NT master.

¶ For automatic job documentation, the UNIX and Windows NTscheduling language job statement accepts MPE-specifickeywords, and MPE file and user names. For example:

Operational Differences Between Platforms


A.

Netw

orkin

gw

ithM

PE

jobfilename file.grp.acct [streamlogon user.acct[, grp]]

orisuserjob [= jobname] streamlogon user.acct[, grp]

¶ The UNIX and Windows NT scheduling language openskeyword accepts MPE file names. For example:opens [ cpu#]" pathname"| file.grp.acct[( qualifiers)] [,...]

Conman¶ The showjob command displays MPE-specific information:

[userjob]

>> alias is

>> run again as

SKEL

¶ The submit docommandcommand is not valid when directed toan MPE cpu, even though the command can be executed on theUNIX or Windows NT master.

On the MPE Slaves

ArrangerThe only valid ARRANGER transactions are: CTP2, CTP3, xCPU,xLNK, xPRM, xPAS, xSYS.

ComposerYou cannot run COMPOSER successfully.

ConmanThe following CONMAN operations are not permitted:¶ Submit jobs using the CONMAN SUBMIT JOB command.¶ Submit schedules using the CONMAN SUBMIT SCHEDULE

command.¶ Add pre-defined (or global) prompt dependencies with the

ADDDEP command.¶ Use the ;FROM and ;FILE options in the RERUN command.¶ Display jobs and schedules using the DISPLAY command.

Operational Differences Between Platforms

148 Version 7.0

Glossary

A

Access methodAn executable used by extended agents to connect and control job execution onother operating systems (for example, MVS) and applications (for example, OracleApplications, Peoplesoft, and Baan). The access method must be specified in theworkstation definition for the extended agent.

B

BatchmanA process started at the beginning of each TWS processing day to launch jobs inaccordance with the information in the symphony file.

C

CalendarAn object defined in the Tivoli Workload Scheduler database that contains a list ofscheduling dates. Because it is a unique object defined in the database, it can beassigned to multiple job streams. Assigning a calendar to a job stream causes thatjob stream to be executed on the days specified in the calendar. Note that a calendarcan be used as an inclusionary or exclusionary run cycle.

ConmanA legacy command-line application for managing the production environment.Conman (console manager) performs the following tasks: start and stop productionprocesses, alter and display schedules and jobs in the plan, and control workstationlinking in a network.

ComposerA legacy command-line application for managing the definitions of your schedulingobjects in the database.

D

DatabaseA database that contains all the definitions you have created for scheduling objects(for example, jobs, job streams, resources, workstations, etc). In addition, thedatabase holds other important information such as statistics of job and job streamexecution, information on the user ID who created an object, and an object’s lastmodified date. In contrast, the plan contains only those jobs and job streams(including dependent objects) that are scheduled for execution in today’s production.


Glo

ssary

DeadlineThe last moment in time that a job or job stream can begin execution. Thiscorresponds to the Until time in legacy Maestro.

DependencyA prerequisite that must be satisfied before the execution of a job or job stream canproceed. The maximum number of dependencies permitted for a job or job stream is40. The four types of dependencies used by Tivoli Workload Scheduler are followsdependencies, resource dependencies, file dependencies, and prompt dependencies.

DomainA named group of TWS workstations consisting of one or more agents and adomain manager acting as the management hub. All domains have a parent domainexcept for the master domain.

Domain ManagerThe management hub in a Tivoli Workload Scheduler domain. All communicationsto and from the agents in the domain are routed through the domain manager.

DurationThe time you expect the job to take to complete. In the Timeline view of jobs in thedatabase, the duration is represented by a light blue bar at the center of the activitybar or by a light blue diamond.

E

Earliest start timeThe time before which the job or job stream cannot start. The earliest start time isan estimate based on previous experiences running the job or job stream. However,the job or job stream can start after the time you specify as long as all otherdependencies are satisfied. In the timeline, the start time is represented by thebeginning (left edge) of the navy blue activity bar. For job instances, the start timethat OPC calculates is represented by a light blue bar. See also “Actual start time”and “Planned start time”.

Exclusionary run cycleA run cycle that specifies the days a job stream cannot be run. Exclusionary runcycles take precedent over inclusionary run cycles.

Expanded databaseA database that allows longer names for database objects such as jobs, job streams,workstations, domains, and users. Expanded databases are configured using thedbexpand command or as an option during installation. Do not expand yourdatabase before understanding the implications and impact of this command.

150 Version 7.0

Extended agentAn agent used to integrate Tivoli Workload Scheduler’s job control features withother operating systems (for example, MVS) and applications (for example, OracleApplications, Peoplesoft, and Baan). Extended agents use scripts called accessmethods to communicate with external systems.

External jobA job from one job stream that is a predecessor for a job in another job stream. Anexternal job is represented by a place holder icon in the Graph view of the jobstream.

F

Fault-tolerant agentAn agent workstation in the Tivoli Workload Scheduler network capable ofresolving local dependencies and launching its jobs in the absence of a domainmanager.

FenceThe job fence is a master control over job execution on a workstation. The jobfence is a priority level that a job or job stream’s priority must exceed before it canexecute. For example, setting the fence to 40 prevents jobs with priorities of 40 orless from being launched.

Final Job StreamThe last job stream that is executed in a production day. It contains a job that runsthe script file Jnextday.

Follows dependencyA dependency where a job or job stream cannot begin execution until other jobs orjob streams have completed successfully.

G

Global optionsOptions that apply to all the workstations of a TWS network. They are defined inthe globalopts file on the master domain manager. See also “Local options”.

H

HostA Workload Scheduler workstation required by extended agents. It can be any TWSworkstation except another extended agent.


Glo

ssary

I

Inclusionary Run CycleA run cycle that specifies the days a job stream is scheduled to run. Exclusionaryrun cycles take precedent over inclusionary run cycles.

Interactive jobsA job that runs interactively on a Windows NT desktop.

Internal statusReflects the current status of jobs and job streams in the TWS engine. Internalstatus is unique to TWS. See also Status.

Internetwork (INET) dependenciesA dependency between jobs or job streams in separate Tivoli Workload Schedulernetworks. See also “Network agent”.

Internetwork (INET) job / job streamA job or job stream from a remote Tivoli Workload Scheduler network that is apredecessor to a job or job stream in the local network. An Internetwork job isrepresented by a place holder icon in the Graph view of the job stream. See also“Network agent”.

J

Jnextday jobA job scheduled to run at the end of each day in order to fully automate pre- andpost-production processing. A sample jnextday job is provided asTWShome\Jnextday. Jnextday does the following: sets up the next day’s processing(contained in the symphony file), prints reports, carries forward unfinished jobstreams, and stops and restarts TWS.

JobA unit of work that is processed at a workstation. The job definition consists of aunique job name in the TWS database along with other information necessary to runthe job. When you add a job to a job stream, you can define its dependencies andits time restrictions such as the estimated start time and deadline.

Job InstanceA job scheduled for a specific run date in the plan. See also “Job”.

Job statusSee “Status”.

152 Version 7.0

Job StreamA list of jobs that execute as a unit (such as a weekly backup application), alongwith times, priorities and other dependencies that determine the exact order of jobexecution.

Job stream instanceA job stream that is scheduled for a specific run date in the plan. See also “Jobstream”.

L

LimitA job limit that provides a means of allocating a specific number of job slots intowhich Tivoli Workload Scheduler is allowed to launch jobs. A job limit can be setfor each job stream, and for each workstation. For example, setting the workstationjob limit to 25 permits TWS to have no more than 25 jobs executing concurrentlyon the workstation.

ListA list that displays job scheduling objects. You must create separate lists for eachjob scheduling object. For each job scheduling object, there are two types of lists:one of definitions in the database and another of instances in the plan.

Local optionsOptions that apply only to the workstation on which they are defined. They aredefined in the localopts file on each workstation of a Tivoli Workload Schedulernetwork. See also “Global options”.

M

Master Domain ManagerThe workstation that maintains the files used to document the scheduling objects ina Tivoli Workload Scheduler network. It creates the plan at the start of each day,and performs all logging and reporting for the network.

N

Network agentA type of extended agent used to create dependencies between jobs and job streamson separate Tivoli Workload Scheduler networks. See also “Internetwork (INET)dependency”.


Glo

ssary

P

ParameterA parameter used to substitute values into your jobs and job streams. When using aparameter in a job script, the value is substituted at run time. In this case, theparameter must be defined on the workstation where it will be used. Parameterscannot be used when scripting extended agent jobs.

PlanA procedure containing all job scheduling activity planned for a period of one day.In TWS, the plan is created every 24 hours and consists of all the jobs, job streams,and dependency objects that are scheduled to execute for that day. All job streamsfor which you have created run cycles are automatically scheduled and included inthe plan. As the production cycle progresses, the jobs and job streams in the planare executed according to their time restrictions and other dependencies. Any jobs orjob streams that do not execute successfully are rolled over into the next day’s plan.

Planned Start TimeThe time that TWS estimates a job instance will start. This estimate is based onstart times of previous executions.

PredecessorA job that must complete successfully before successor jobs can begin execution.

PriorityA time preference in the TWS queuing system for running jobs and job streams inthe plan. You can assign a priority level for each job and job stream from 0 to 101.A priority of 0 will not execute.

PromptAn object that can be used as a dependency for jobs and job streams. A Promptmust be answered affirmatively for the dependent job or job stream to launch. Thereare two types of prompts: predefined and ad hoc. An ad hoc prompt is definedwithin the properties of a job or job stream and is unique to that job or job stream.A predefined prompt is defined in the TWS database and can be used by any job orjob stream.

R

ResourceAn object representing either physical or logical resources on your system. Oncedefined in Tivoli Workload Scheduler database, resources can be used asdependencies for jobs and job streams. For example, you can define a resourcenamed ″tapes″ with a unit value of two. Then, define jobs that require two availabletape drives as a dependency. Jobs with this dependency cannot run concurrentlybecause each time a job is run the “tapes” resource is in use.

154 Version 7.0

Run cycleA cycle that specifies the days that a job stream is scheduled to run. In TWS thereare three types of run cycles you can specify for a job stream: a Simple run cycle, aWeekly run cycle, or a Calendar run cycle (commonly called a calendar). Note thateach type of run cycle can be inclusionary or exclusionary. That is, each run cyclecan define the days a job stream is included in the production cycle, or the days ajob stream is excluded from the production cycle. When you define multiple runcycles to a job stream, and inclusionary and exclusionary run cycles specify thesame days, the exclusionary run cycles take precedent.

S

Simple Run CycleA specific set of user-defined days a job stream is executed. A simple run cycle isdefined for a specific job stream and cannot be used by multiple job streams. Formore information see Run Cycle.

StatusReflects the current job or job stream status within the Job Scheduling Console. TheJob Scheduling Console status is common to TWS and OPC. See also Internalstatus.

stdlist fileA standard list file created for each job launched by Tivoli Workload Scheduler.Standard list files contain header and trailer banners, echoed commands, errors, andwarnings. These files can be used to troubleshoot problems in job execution.

SuccessorA job that cannot start until all of the predecessor jobs on which it is dependent arecompleted successfully.

Symphony fileA file containing the scheduling information needed by the Production Controlprocess (batchman) to execute the plan. The file is built and loaded during thepre-production phase. During the production phase, it is continually updated toindicate the current status of production processing: work completed, work inprogress, work to be done. To manage production processing, the contents of thesymphony file (plan) can be displayed and altered with the Job Scheduling console.

T

Time restrictionsCan be specified for both jobs and job streams. A time can be specified forexecution to begin, or a time can be specified after which execution will not beattempted. By specifying both, you can define a window within which a job or jobstream will execute. For jobs, you can also specify a repetition rate. For example,


Glo

ssary

you can have Tivoli Workload Scheduler launch the same job every 30 minutesbetween the hours of 8:30 a.m. and 1:30 p.m.

Tivoli Management Framework (TMF)The base software that is required to run the applications in the Tivoli product suite.This software infrastructure enables the integration of systems managementapplications from Tivoli Systems Inc. and the Tivoli Partners. The TivoliManagement Framework includes the following: vObject request broker (oserv)vDistributed object database vBasic administration functions vBasic applicationservices vBasic desktop services such as the graphical user interface In a Tivolienvironment, the Tivoli Management Framework is installed on every client andserver. However, the TMR server is the only server that holds the full objectdatabase.

Tivoli Management Region (TMR)In a Tivoli environment, a Tivoli server and the set of clients that it serves. Anorganization can have more than one TMR. A TMR addresses the physicalconnectivity of resources whereas a policy region addresses the logical organizationof resources.

Tree viewThe view on the left side of the Job Scheduling Console that displays the TWSserver, groups of default lists, and groups of user created lists.

U

UserFor Windows NT only, the user name specified in a job definition’s “Logon” fieldmust have a matching user definition. The definitions furnish the user passwordsrequired by Tivoli Workload Scheduler to launch jobs.

Utility commandsA set of command-line executables for managing Tivoli Workload Scheduler.

W

Weekly Run CycleA run cycle that specifies the days of the week that a job stream is executed. Forexample, a job stream can be specified to execute every Monday, Wednesday, andFriday using a weekly run cycle. A weekly run cycle is defined for a specific jobstream and cannot be used by multiple job streams. For more information see RunCycle.

WildcardsThe wildcards for Tivoli Workload Scheduler are: ? Replaces one alpha character. %Replaces one numeric character. * Replaces zero or more alphanumeric characters.

156 Version 7.0

Wildcards are generally used to refine a search for one or more objects in thedatabase. For example, if you want to display all workstations, you can enter theasterisk (*) wildcard. To get a listing of workstations site1 through site8, you canenter site%.

WorkstationUsually an individual computer on which jobs and job streams are executed. Theyare defined in the Tivoli Workload Scheduler database as a unique object. Aworkstation definition is required for every computer that executes jobs or jobstreams in the Workload Scheduler network.

Workstation classA group of workstations. Any number of workstations can be placed in a class. Jobstreams and jobs can be assigned to execute on a workstation class. This makesreplication of a job or job stream across many workstations easy.

X

X-agentSee “Extended agent”.


Glo

ssary

158 Version 7.0

Index

Special Characters$framework 66$jclowner 69$master 66, 70$owner 69$remote 70$remotes 66$slaves 66, 70$thiscpu 66, 70$user 69/usr/unison/components 61

Aadddep 72AIXconsole.sh 104altpri 73AT keyword 117, 118

Bbackup master 125batchman 113

Ccalendar 67, 71calendars 68carryforward 117compiler 115, 118components file 20components file, viewing 20

connectorprerequisites 78

cpu 67, 69cpudata 68cpuname 127

Ddatabase auditing 112date

except 6on 6

deadline 117, 134deldep 73dumpsec 64, 94

Eexpanded version 137

Ffence 72file 67, 68, 72final 114, 126full status 125


Ind

ex

Ggcomposer 123gconman 123globalopts 111, 126, 137GlobalPreferences.ser 135group 67

HHPconsole.sh 104

Iinstallation overview 18

JJAVAPATH 104jcl 69Jnextday 114job 6, 67, 72job.sched database 60job scheduling console 98, 123

installationcustomized install 102full package 101

startup dialoghost machine 106LoginAs 106password 106

startup window 106job stream 5, 70jobman 113jobs 68JSconsole client 3JSS classes 96

Kkill 73

Llegacy GUI 133localopts 112, 137logman 115logon 67, 69

Mmaestro

5.x 1216.x 121

mailman 113makesec 64, 132managed node 122master domain manager 2mastsked 69mozart 128mozart.old 136

Nnetman 20, 113

home directory 21local options 21

NFS mount 125nice value 113

Oobject dispatcher 122OPC 123oserv 122

160 Version 7.0

Pparameter 67, 69, 73parameters 69, 126parameters.KEY 126plan auditing 112pre-production reports 115prodsked 69product groups 20Production Control file 112prompt 67, 70, 73prompts 69

Rrep8 115reptr 115rerun 73resource 67, 70, 74resources 69RUNCON 105runmsgno 137

Sscheddate 118schedule 67, 70, 74schedulr 115, 118security 69, 94

file 63template 63

security file 129sesolve dependencies 125setup_env 80, 84, 91Sfinal 114shutdown 72stageman 115start 117, 134submit 73, 124switchmgr 126Symphony 69, 123

TTCP port number 114tempsec 94time zone 112, 123, 133time zone support 7timezone enable 128, 134Tivoli desktop 122Tivoli Management Region 121Tivoli Management Server 121TME administrator 63, 129TWS connector 1, 123

classes 95instances 124

UUNTIL keyword 117until time 113userobj 68, 70, 75

Wwindow

Choose Install Folder 100Choose Shortcut Location 100Create Workstations 127customize install 102Install Patch 94Install Product 80, 86Open Location 107, 136

winstall 85, 91wmaeutil 94, 132wtwsconn 91wuninst 95


Ind

ex

162 Version 7.0

Printed in the United States of Americaon recycled paper containing 10%recovered post-consumer fiber.

GC32-0422-00