8.4 tws small

TIVOLI WORKLOAD SCHEDULER

Version 8.4

Tivoli Workload Scheduler

2

Contents Introduction TWS Introduction TWS Architecture TWS Network TWS Workstation Types TWS Requirements TWS Installation TWS Configuration TWS User Interfaces TWS Workstation Processes TWS Workstation Interprocess Communication TWS Network Communication TWS Scheduling Objects Definition TWS Final Job Stream TWS Job Scheduling through CLI TWS Job Scheduling through JSC TWS Troubleshooting


3

Introduction SCHEDULER:

The arrangement of a number of related operations in time. There are workload management tools to automate the tasks.

Those tools automate the scheduling and allocation of hundreds or thousands of interactive and batch jobs among the various computers on the network. This scheduling and allocation may be based on such criteria as time deadlines, the completion of other jobs, the needs of particular applications. Workload management tools must also monitor job completion status and allow systems administrators to establish job or application priorities in order to optimize network performance. IBM Tivoli Workload Scheduler is one of Workload Management tool to automate the jobs.

Tivoli Workload Scheduler Introduction

IBM Tivoli Workload Scheduler is a family of IBM products that plan, execute and track job on several platforms and environments. But IBM Tivoli Workload Scheduler does not belong to the original Tivoli product line, it is rebranded and modified from product called Maestro form Unison Inc. When IBM acquired Tivoli in 1996, the program was renamed IBM Tivoli Workload Scheduler.

Tivoli Workload Scheduler is a tool for modeling, planning, executing, and controlling the various phases of batch workload processes occurring on z/OS, UNIX, Windows, and Linux platforms. It is monitored from a single point of control with the use of java console called JSC (Job Scheduling Console).

Tivoli Workload Scheduler architecture

Tivoli Workload Schedulers scheduling features help us to plan every phase of production. During the processing day, the Tivoli Workload Scheduler production control programs manage the production environment and automate most operator activities. Tivoli Workload Scheduler prepares jobs for execution, resolves interdependencies, launches and tracks each job. Because jobs start running as soon as their dependencies are satisfied, idle time is minimized, and throughput improves significantly. Jobs never run out of sequence, and, if a job fails, Tivoli Workload Scheduler handles the recovery process with little or no operator intervention.


4

Tivoli Workload Scheduler is composed of three major parts: Tivoli Workload Scheduler engine

This is installed on every computer that should participate in a Tivoli Workload Scheduler network. The engine is a complete Tivoli Workload Scheduler installation, which means all Tivoli Workload Scheduler services and components are installed on the computer.

When doing installation, the engine is configured for the role that the computer with the engine is going to play within the Tivoli Workload Scheduler scheduling network, such as master domain manager, domain manager, or fault tolerant agent. The configuration of the engine role is done in two places: In parameter files (localopts and globalopts), and in database definition for the Tivoli Workload Scheduler workstation that represents the engine on the physical computer. This is also called as scheduling engine. Tivoli Workload Scheduler connector

Maps Job Scheduling Console commands to the Tivoli Workload Scheduler engine. The Tivoli Workload Scheduler connector runs on the master and on any of the fault tolerant agents (FTA) that you will use as backup machines for the master workstation. The connector we use here is Web Sphere Application Server. Job Scheduling Console (JSC)

A Java-based graphical user interface (GUI) for the Tivoli Workload Scheduler suite. The Job Scheduling Console runs on any machine from which we want to manage Tivoli Workload Scheduler plan and database objects. The Job Scheduling Console need not be required that it should be installed on the same machine with the Tivoli Workload Scheduler engine or connector installed. We can use the Job Scheduling Console from any machine as long as it has a TCP/IP link with the machine running the Tivoli Workload Scheduler connector.


5

Tivoli Workload Scheduler network

A Tivoli Workload Scheduler network is made up of the workstations on which jobs and job streams are run.

A Tivoli Workload Scheduler network contains at least one Tivoli

Workload Scheduler domain, the master domain, in which the master domain manager is the management hub. It is the master domain manager that manages the databases and it is from the master domain manager that we define new objects in the databases. Additional domains can be used to divide a widely distributed network into smaller, locally managed groups.

In a single domain configuration, the master domain manager maintains

communication with all of the workstations (fault tolerant agents) in the Tivoli Workload Scheduler network

Before the start of each new day, the master domain manager creates a plan for the next 24 hours. This plan is placed in a production control file, named Symphony. Tivoli Workload Scheduler is then restarted in the network, and the master domain manager sends a copy of the Symphony file to each of its automatically linked agents and subordinate domain managers. The domain managers, in turn, send copies of the Symphony file to their automatically linked agents and subordinate domain managers.

Once the network is started, scheduling messages like job starts and completion are passed from the agents to their domain managers, through the parent domain managers to the master domain manager. The master domain manager then broadcasts the messages throughout the hierarchical tree to update the Symphony files of domain managers and fault tolerant agents running in full status mode.


6

Using multiple domains reduces the amount of network traffic by reducing the communications between the master domain manager and other computers in the network. The following figure shows a Tivoli Workload Scheduler network with three domains. It is not necessary that MDM, Domain Manager and FTA be installed in the same platforms.

Tivoli Workload Scheduler workstation types

For most cases, workstation definitions refer to physical workstations. However, in the case of extended and network agents, the workstations are logical definitions that must be hosted by a physical Tivoli Workload Scheduler workstation. Tivoli Workload Scheduler workstations can be of the following types: Master domain manager (MDM)

The master domain manager in the topmost domain of a Tivoli Workload Scheduler network. It contains the centralized database files used to document scheduling objects. It creates the plan at the start of each day, and performs all logging and reporting for the network. The plan is distributed to all subordinate domain managers and fault tolerant agents. Backup master

A fault tolerant agent or domain manager capable of assuming the responsibilities of the master domain manager for automatic workload


7

recovery. The copy of the plan on the backup master is updated with the same reporting and logging as the master domain manager plan. Domain manager

All communications to and from the agents in a domain are routed through the domain manager. The domain manager can resolve dependencies between jobs in its subordinate agents. The copy of the plan on the domain manager is updated with reporting and logging from the subordinate agents. Backup domain manager

A fault tolerant agent capable of assuming the responsibilities of its domain manager. The copy of the plan on the backup domain manager is updated with the same reporting and logging information as the domain manager plan.

Fault tolerant agent (FTA)

A workstation capable of resolving local dependencies and launching its jobs in the absence of a domain manager. It has a local copy of the plan generated in the master domain manager. It is also called workstation tolerant agents.

Standard agent

A workstation that launches jobs only under the direction of its domain manager. Extended agent

A logical workstation definition that enables you to launch and control jobs on other systems and applications, such as Peoplesoft, Oracle Applications, SAP, and MVS, JES2, and JES3. Network agent

A logical workstation definition for creating dependencies between jobs and job streams in separate Tivoli Workload Scheduler networks. Job Scheduling Console client

Any workstation running the graphical user interface from which schedulers and operators can manage Tivoli Workload Scheduler plan and database objects. Actually this is not a workstation in the Tivoli Workload Scheduler network; the Job Scheduling Console client is where you work with the Tivoli Workload Scheduler database and plan.


8

TWS Requirements Hardware Requirements: The following lists the hardware requirements for Tivoli Workload Scheduler: Engine

The engine may be Master Domain Manager Backup Master Domain Manager Fault Tolerant Agent Connector for distributed engine Command line client

Disk Space Requirements: Operating System MDM with DB2

server FTA CONN

IBM AIX 1375 210 330 HP-UX 1595 275 280 Linux 1245 180 350 Solaris 1525 210 390 Temporary Storage: Temporary file space is needed during the installation of Tivoli Workload Scheduler Operating System MDM/BKM FTA UNIX 170 40 Microsoft Windows 70 20 Memory Requirements: Recommended and Minimum memory requirements are given in the following table Memory MDM/BKM FTA Recommended 2048 256 Required 1024 256


9

Job Scheduling Console Disk Space Requirements: Operating System JSC IBM AIX 100 HP-UX 250 Linux 110 Solaris 120 Microsoft Windows 100 Temporary disk space requirements Operating System JSC IBM AIX 65 HP-UX 210 LINUX 75 Solaris 90 Microsoft Windows 60 Where MDM Master Domain Manager BKM Backup Master Domain Manager FTA Fault Tolerant Agent CONN Connector JSC Job Scheduling Console


10

TWS Installation Tivoli Workload Scheduler - V 8.4 DB2 Database - V 9.1 Job Scheduling Console - V 8.4

Before starting installation of TWS 8.4 in Linux, add soft link for a library file libstdc++-libc6.1-2.so.3 with the source file libstdc++-3-libc6.2-2-2.10.0.so as ln s libstdc++-libc6.1-2.so.3 libstdc++-3-libc6.2-2-2.10.0.so DB2 database can be installed while installing TWS MDM. It can also be installed separately. Tivoli Workload Scheduler Installation Step-by-step Installation: Untar the TWS source file & run setup.sh


11

Choose Install an instance of Tivoli Workload Scheduler

Choose Master Domain Manager while installing MDM, if it is FTA choose Agent or domain manager.


12

On UNIX system, user name must exist. So create TWSUser and proceed installation.

If it is MDM, leave Master domain manager name, if it is FTA type the MDM name


13

The default installation directory is users home directory to install TWS.

The Database selection window will be displayed, Select DB2 Universal Database


14

The Database installation action window will be displayed. Select Install DB2 UDB Enterprise Server Edition and Administration Client, version 9.1.

If DB2 already installed separately, then select Check that an existing instance of DB2 UDB satisfies Tivoli Workload Scheduler and map the installed DB2 then.

If the DB2 server administrator doesnt exist it will be created automatically.


15

The DB2 installation directory will be displayed. Insert the preferred path.

The DB2 database configuration window will be displayed.

The Summary window will be displayed. This window contains all the information that provided in previous steps.


16

The DB2 install script is needed to complete the installation. Select the path where the script is located.


17

The Installation completed window will be displayed. Click Finish to end the InstallShield Wizard.

The installation log file will be in tmp directory as shown in the screenshot.


18

Fix Pack After installation and configuration, we schedule jobs in TWS. At that time, we may face some errors while scheduling (for ex: error AWSJPL506E). This errors are fixed by installing the fixpack 8.4.0-TIV-TWS-FP0001 in TWS V 8.4.

So download the fixpack and install the same after installing TWS 8.4.

Job Scheduling Console Installation: Job Scheduling Console can be installed in any machine which has TCP/IP connection with MDM. Fault Tolerant Agent Installation: Fault Tolerant Agent can be installed with the same source installed for MDM, select Agent or Domain Manager instead of Master Domain Manager.


19

TWS Configuration CONFIGURING MASTER DOMAIN MANAGER WORKSTATION: After Tivoli Workload Scheduler master domain manager has been installed, it should be configured and able to produce a new production plan on daily basis. The production plan is handled and extended automatically by jobs in a job stream named FINAL. When the FINAL job stream has been added to the database and JnextPlan run once, the FINAL job stream will be placed in the production plan every day and will run the jobs required to generate new plan. Sfinal file will be created automatically when we install TWS. It will be in TWS home directory on the server where TWS master domain manager has been installed. The following steps describe how to add FINAL job stream to the database and run JnextPlan command manually for the first time.

1. Login as TWS user.

2. Set the system variables. Run tws_env.sh,. Set PATH & TWS_home.

3. Run the composer command.

4. Add the final job stream definition to the database by running the following command:

add Sfinal where Sfinal is the name of the final job stream file.

5. Exit the composer command line and run JnextPlan job.

JnextPlan for 0000. This extends the production plan by 0 hours and 0 minutes.

6. When JnextPlan completes, check the status of Tivoli Workload

Scheduler: conman status. If Tivoli Workload Scheduler started

correctly the status will be Batchman=LIVES.

7. Raise the limit to allow jobs to run. The default job limit after

installation is 0, so no job runs. Raise the job limit to allow jobs to run.

conman lc hostname; job limit


20

CONFIGURING AN AGENT

1. Login to the master domain manager as TWSuser.

2. Set the system variables. Run tws_env.sh & add PATH for TWS home

directory & bin directory in TWS home, export TWS home directory as

TWS_home

3. Create FTA workstation definition in TWS database.

Type composer new to open a text editor. Type the workstation definition in the text editor.

CPUNAME TEST.SERVER DESCRIPTION "fault tolerant agent"

OS UNIX NODE TCS.TEST TCPADDR 31111

DOMAIN MASTERDM FOR MAESTRO TYPE FTA AUTOLINK ON BEHINDFIREWALL OFF

FULLSTATUS OFF END If it is windows OS, type OS WNT

Run JnextPlan with the option -for 0000.

4. Issue the link command from the master domain manager to link the agent and to download the Symphony file to it and set job limit:

conman link ftaname Note: In order to establish a two-way link between a fault tolerant agent and master domain manager, the following must be satisfied. The master domain manager should resolve fault tolerant agents node information. The NODE option in the workstation definition contains the server hostname or ip-address for the fault tolerant agent. When FTA receives the Symphony file it will look after the MDM workstation and try to establish upward link to the master domain manager using the server hostname or ip-address specified in the NODE keyword for master domain manager workstation. The NODE together with TCPADDR specifies hostname and port number that the fault tolerant agent and master domain manager will use to establish two-way network link.


21

User Definition:

Users needed to be defined in database prior to the scheduling of a job only for windows workstations.

USERNAME CPUNAME#USERNAME

PASSWORD "**********" CONFIGURING DOMAIN WORKSTATION

1. Login to the master domain manager as TWSuser.

2. Set the system variables. Run tws_env.sh,. Set PATH & TWS_home.

3. Create FTA workstation definition in TWS database. Type composer new to open a text editor.

Type the workstation definition in the text editor.

DOMAIN DOMAIN1 DESCRIPTION DOMAIN1 PARENT MASTERDM END CPUNAME TEST.SERVER

DESCRIPTION "fault tolerant agent" OS UNIX NODE TCS.TEST TCPADDR 31111

DOMAIN DOMAIN1 FOR MAESTRO TYPE MANAGER AUTOLINK ON BEHINDFIREWALL OFF

FULLSTATUS OFF END

Automatically starting Tivoli Workload Scheduler on UNIX


22

Make sure that Tivoli Workload Scheduler workstation to be automatically started upon the server booting. Tivoli Workload Scheduler installion program does not perform action to do this. In UNX & LINUX, Tivoli Workload Scheduler can be started automatically by invoking the TWS StartUp command from /etc/inittab file. Processes Involved in TWS if [-x TWShome/StartUp] then echo "netman started..." /bin/su - TWSuser -c " TWShome/StartUp" fi Note: Startup script is run by TWSuser. The Startup script will start netman process and if installed on master domain manager, it will also start WebSphere Application Server for TWS. The remaining Tivoli Workload Scheduler process tree can be started with: Conman start

On windows workstations, Netman process and WAS are started when server is booted. Manually Starting & Stopping TWS & DB2 Starting TWS StartUp Conman start Stopping TWS Conman stop Conman shut DB2 Login as DB2 user, type DB2.. DB2 prompt will be opened type DB2 start To start DB2 DB2stop To stop DB2 Managing Production Plan:


23

How you manage production scheduling activities with Tivoli Workload Scheduler Each time a new production plan is generated; Tivoli Workload Scheduler selects the job streams that run in the time window specified for the plan, and carries forward uncompleted job streams from the previous production plan. All the required information are written in a file, named Symphony, which is continually updated while processing to indicate work completed, work in progress, and work to be done. The Tivoli Workload Scheduler conman (Console Manager) command-line program is used to manage the information in the Symphony file. The conman command-line program can be used to

Start and stop Tivoli Workload Scheduler control processes. Display the status of jobs and job streams. Alter priorities and dependencies. Alter the job fence and job limits. Rerun jobs. Cancel jobs and job streams. Submit new jobs and job streams. Reply to prompts. Link and unlink workstations in the Tivoli Workload Scheduler network. Modify the number of available resources.

These actions can also be carried through Job Scheduling Console (JSC) Tivoli Workload Scheduler user interfaces composer A command-line program used to define and manage scheduling objects in the database. conman A command-line program used to monitor and control the Tivoli Workload Scheduler production plan processing. Job Scheduling Console An interactive graphical interface used to create, modify, and delete objects in the product database and in the plan. Tivoli Workload Scheduler workstation processes


24

Netman Monman Writer Mailman Batchman Jobman

Netman

Netman is the Network Management process. It is started by the Startup command and it behaves like a network listener program which receives start, stop, link, or unlink requests from the network. Netman examines each request received and spawns a local Tivoli Workload Scheduler process. Monman

Monman is a process started by netman and used in event management. Starts monitoring and ssmagent services that have the task of detecting the events defined in the event rules deployed and activated on the specific workstation. When these services catch any such events, after a preliminary filtering action, they send them to the event processing server that runs usually in the master domain manager. If no event rule configurations are downloaded to the workstation, the monitoring services stay idle.

The communication process between the monitoring agents and the event processing server is independent of the Tivoli Workload Scheduler network topology. It is based directly on the EIF port number of the event processor and the event information flows directly from the monitoring agents without passing through intermediate domain managers. A degree of fault-tolerance is guaranteed by local cache memories that temporarily store the event occurrences on the agents in case communication with the event processor is down. Writer

Writer is a process started by netman to pass incoming messages to the local mailman process. The writer processes (there might be more than one on a domain manager workstation) are started by link requests and are stopped by unlink requests or when the communicating mailman ends.


25

Mailman

Mailman is the Mail Management process. It routes messages to either local or remote workstations. On a domain manager, additional mailman processes can be created to divide the load on mailman due to the initialization of agents and to improve the timeliness of messages. When the domain manager starts up, it creates a separate mailman process instance for each ServerID specified in the workstation definitions of the fault-tolerant agents and standard agents it manages. Each workstation is contacted by its own ServerID on the domain manager. Batchman

Batchman is the Production Control process. It interacts directly with the copy of the Symphony file distributed to the workstations at the beginning of the production period and updates it. Batchman performs several functions:

Manages locally plan processing and updating. Resolves dependencies of jobs and job streams. Selects jobs to be run. Updates the plan with the job processing results. Batchman is the only process that can update the Symphony file.

Jobman

Jobman is the Job Management process. It launches jobs under the direction of batchman and reports job status back to mailman. It is responsible for tracking job state and for setting the environment as defined in scripts jobmanrc and .jobmanrc when requesting to launch jobs. When the jobman process receives a launch job message from batchman, it spawns a job monitor process. The maximum number of job monitor processes that can be spawned on a workstation is set using the limit cpu command from the conman command line prompt. TWS Workstation inter-process communication

Tivoli Workload Scheduler uses message queues for local inter-process communication. There are four message files, which reside in the TWS_home directory: NetReq.msg

This message file is read by the netman process for local commands. It receives messages such as START, STOP, LINK, and UNLINK.


26

Mailbox.msg This message file is read by the mailman process. It receives messages

from the local batchman and jobman processes, from both the Job Scheduling Console and the console manager conman, and from other Tivoli Workload Scheduler workstations in the network. Intercom.msg

This message file is read by the batchman process and contains instructions sent by the local mailman process. Courier.msg

This message file is written by the batchman process and read by the jobman process. These message files are present in TWS home directory & be sure that the size should not cross beyond 48 K. Tivoli Workload Scheduler Network Communication Connection initialization and two-ways communication setup These are the steps involved in the establishment of a two-ways Tivoli Workload Scheduler link between a domain manager and a remote FTA: 1. On the domain managers the mailman process reads the host name, TCP/IP address, and port number of the FTA from the Symphony file. 2. The mailman process on the domain manager establishes a TCP/IP connection to the netman process on the FTA using the information obtained from the Symphony file. 3. The netman process on the FTA determines that the request is coming from the mailman process on the domain manager, and spawns a new writer process to handle incoming connection. 4. The mailman process on the domain manager is now connected to the writer process on the FTA. The writer process on the FTA communicates the current run number of its copy of the Symphony file to the mailman process on the domain manager. This run number is the identifier used by Tivoli Workload Scheduler to recognize each Symphony file generated by JnextPlan. This step is necessary for the domain manager to check if the current plan has already been sent to the FTA. 5. The mailman process on the domain manager compares its Symphony file run number with the run number of the Symphony file on the FTA. If the run numbers are different, the mailman process on the domain manager sends to the writer process on the FTA the latest copy of the Symphony file.


27

6. When the current Symphony file is in place on the FTA, the mailman process on the domain manager sends a start command to the FTA. 7. The netman process on the FTA starts the local mailman process. At this point a one-way communication link is established from the domain manager to the FTA. 8. The mailman process on the FTA reads the host name, TCP/IP address, and port number of the domain manager from the Symphony file and use them to establish the uplink back to the netman process on the domain manager. 9. The netman process on the domain manager determines that the request is coming from the mailman process on the FTA, and spawns a new writer process to handle the incoming connection. The mailman process on the FTA is now connected to the writer on the domain manager and a full two-way communication link has been established. As a result of this, the writer process on the domain manager writes messages received from the FTA to the Mailbox.msg file on the domain manager, and the writer process on the FTA writes messages from the domain manager to the Mailbox.msg file on the FTA. During Production Period

During the production period, the Symphony file present on the FTA is read and updated with the state change information about jobs that are run locally by the Tivoli Workload Scheduler workstation processes. These are the steps that are performed locally on the FTA to read and update the Symphony file and to process jobs: 1. The batchman process reads a record in the Symphony file that says that job1 is to be launched on the workstation. 2. The batchman process writes in the Courier.msg file that job1 has to start. 3. The jobman process reads this information in the Courier.msg file, starts job1, and writes in the Mailbox.msg file that job1 started with its process_id and timestamp. 4. The mailman process reads this information in its Mailbox.msg file, and sends a message that job1 started with its process_id and timestamp, to both the Mailbox.msg file on the domain manager and the local Intercom.msg file on the FTA. 5. The batchman process on the FTA reads the message in the Intercom.msg file and updates the local copy of the Symphony file.


28

6. When job job1 completes processing, the jobman process updates the Mailbox.msg file with the information that says that job1 completed. 7. The mailman process reads the information in the Mailbox.msg file, and sends a message that job1 completed to both the Mailbox.msg file on the domain manager and the local Intercom.msg file on the FTA. 8. The batchman process on the FTA reads the message in the Intercom.msg file, updates the local copy of the Symphony file, and determines the next job that has to be run.


29

Definition of Scheduling Objects:

Scheduling objects are managed with the composer command-line program or JSC and are stored in the Tivoli Workload Scheduler database. The composer command-line program or JSC can be installed and used on any machine connected through TCP/IP to the system where the master domain manager & Database is installed. JOB DEFINITION: A job is an executable file, program, or command that is scheduled and launched by Tivoli Workload Scheduler. You can write job definitions in edit files and then add them to Tivoli Workload Scheduler database with the composer command line program or we can add a job through Job Scheduling Console. JOB STREAM:

A job stream consists of a sequences of jobs to be run, together with times, priorities, and other dependencies that determine the order of processing. WORKSTATION:

A workstation is a scheduling object that runs jobs. It is usually an individual computer on which jobs and job streams are run. A workstation definition is required for every computer that runs jobs in the IBM Tivoli Workload Scheduler network.

DOMAIN:

A domain is a group of workstations consisting of one or more agents and a domain manager. The domain manager acts as the management hub for the agents in the domain. You can include multiple domain definitions in the same text file, along with workstation definitions and workstation class definitions. CALENDAR:

A calendar is a list of dates which define if and when a job stream runs. TWS LOG FILES

TWS log files are present inside stdlist directory of tws home directory.


30

TWS FINAL JOB STREAM VIEW OF FINAL JOB STREAM SCHEDULE

The FINAL job stream consists of the following jobs:

Startappserver Makeplan Switchplan Createpostreports Updatestatistics


31

Each job in the FINAL job stream is responsible for particular task. STARTAPPSERVER This job attempts to start WebSphere Application Server if it not already running. By this job, the following script is executed /wastools/startWas. By this script, the following TWS utility is launched. startWas - invocation of WebSphere Application Server start method. MAKEPLAN The following Tivoli Workload Scheduler utilities are launched from this script: Planman based on the information in the database, this creates a pre-production plan (also called an intermediate plan). The pre-production plan is stored in the file called Symnew. This pre-production plan contains information about scheduling objects (jobs, job streams, calendars, prompts, resources, workstations, domains.) and their dependencies. Prints preproduction reports. SWITCHPLAN This script invokes internally the stageman command. SwitchPlan performs the following actions:

Stops Tivoli Workload Scheduler processes.

This job merges previous Symphony file and the new Symnew file. It adds carry forward job streams to the pre-production plan and thus creates the production plan.

Archievs the old plan file with the current date and time in the

schedlog directory.

Creates a copy of the Symphony file to distribute to the workstations.

Restart Tivoli Workload Scheduler processes which distribute the

copy of the Symphony file to the workstation targets for running the jobs in plan.


32

UPDATESTATS The following script is executed by this job: UpdatesStats This job performs the following tasks:

Logs job statistics (logman to update the job master with run history). Checks the policies and if necessary extends the pre-produciton plan. Updates the pre-production plan reporting the job stream instance states. CREATEPOSTREPORTS The following script is executed by this job CreatePostReports This script prints post-production reports. TWS Job SCHEDULING THROUGH CLI Tivoli Workload Scheduler COMPOSER & CONMAN commands: TWS COMPOSER commands: To Create Job Definition:

Go to composer mode


33

Open a text editor vi new

Here LINUXCOE1 CPU Name (Host Name) of the Workstation COPIES - Job Definition Name DOCOMMAND The script or command to be executed STREAMLOGON The user name TASKTYPE Operating System RECOVERY The state for the dependency job should run or stop. To create Job Stream Go to composer mode


34

Open a text editor vi new1

Here LINXCOE1 NODE or HostName of the Workstation COPIESJS Job Stream Name RUNCYCLE To describe whether the job to be run daily or weekly or

monthly.. AT - By what time the job should execute COPIES Job Definition Name that to be executed. EVERY The Repeat Range Adding Job Definition & Job Stream to the Database

Thus a job definition and a job stream are added to the database.


35

Viewing the added Job Definition and Job Stream JOB DEFINITION

JOB STREAM


36

To view the Workstation added in the Database

To Modify the added Job Definition, Job Stream, Workstation Type modi instead of display Likewise, to delete the Job Definition, Job Stream or Workstation from the database type del instead of display. To view all Job Definitions, Job Streams, Workstations added in the database type @ in the place of all CPUs, Job Definition and Job Stream

This will display job stream in all workstations.


37

TWS CONMAN COMMANDS: To schedule a job that should execute at the defined time. Go to conman mode

sbs command will schedule the job to run at the specified time. The syntax is sbs workstationname#Jobstreamname To view the status of the Job scheduled


38

sj will display the status of the scheduled job. Here it is showing as ABEND which means the job is abended. Other optional status are SUCC SUCCEED The job ran successfully FAIL FAILURE The job fails HOLD HOLDThe job is in hold READY READYThe job is ready to execute The syntax is sj workstationname#jobstreamname sj workstationname#Jobstreamname;stdlist will display the complete details of the scheduled job.


39

To schedule a job to execute immediately (adhoc submission)

sbd will schedule the job to execute immediately after submission. The syntax is sbd workstationname#script to be executed;logon=user;alias=anyname. Also we can use sbj workstationname#jobdefinitionname to execute the same.

To view the Link between the MDM & FTA. Here the integer value 33 is

the symphony file number. It will get incremented by one number during the production plan.


40

sc will show all the FTAs that connected to the MDM. Syntax is sc @!@


41

TWS Job Scheduling through Job Scheduling Console A Java-based graphical user interface (GUI) for the Tivoli Workload

Scheduler suite. The Job Scheduling Console is an interface for creating, modifying, monitoring, controlling and deleting Tivoli Workload Scheduler objects. Creating New Engine To create a new engine, click New Engine in JSC.

Engine Name Type the MDM Engine Name Specify Engine Type Select Distributed Host Name - Type the Hostname of the Engine Port Number By default connected to Port Number 31117 User Name Type MDM user name Password Type MDM user name password


42

Creating a New Workstation When you install a FTA or any other workstation, add the workstation as follows: Click New Workstation

Name Type name of the FTA Domain Type the Domain name to which FTA should connect under. Workstation Type Select Workstation-type Operation System Select the Operating System Time Zone Select the Time Zone for FTA. Node Name Type Hostname of the FTA TCP Port By default FTA connect through the port number 31111


43

Creating Job Definition: Select General tab to select OS type, give Job Definition Name, Workstation, and Login name. Select Task tab to select the script or command to run & type the command to be done.


44

Creating Job Stream

Select General Tab, Type Job Stream Name, Select workstation. Select Time Restriction Tab, specify start time, so that the job will be executed at that time.


45

After giving ok, a window opens; add job definition here to execute. Then save the file.


46

- Select this to add job definition to the job stream.

By Specifying Repeat Range the job will be executed repeatedly at mentioned time. Mentioned this in the properties of the job.


47

After defining the job stream, we have to submit it to the plan list.

Run Cycle: Run Cycle specifies when a job stream in the database is to run in the plan. Combinations of run cycles are used to include and exclude dates.

- Select this to open run cycle

- Select this to open to add a run cycle In add run cycle window, we can specify the types such as

Simple The job runs in the days specified simply Calendar Insert calendar so that the job run in specified days in calendar Daily - The job runs daily at the specified time Weekly The job runs in the days specified in weekly

Inclusive & Exclusive Run Cycle If Inclusive is selected, job will run those inclusive days & if Exclusive is selected, the job will run exclusive of those days.


48


49

Creating Calendar We can create calendars to specify the date and time for the job to run.


50

To view the job stream status

Symbols

- Error. It specifies the job is abended. - Hold. It specifies the job to be executed at later time. - Success. It specifies the job has executed successfully. - Ready. It specifies the job is waiting to execute within some time. - Blocked. It specifies the job blocked other dependencies to execute.

To view the link between FTA & MDM


51

TWS Job Dependency We can specify Job Dependencies so that a job will start after the completion of another job. Therefore, we are having following options for Dependencies

If the first job succeeded, second job get execute If the first job fails, second job shouldnt execute If the first job fails, second job should execute

These options are specified while defining the job definition.The Recovery options

The Possible Recovery options are STOP - If the first job fails, dependent second job will be in HOLD. CONTINUE - If the first job fails, dependent second job will get execute. RERUN - It is the option that if first job fails, it will try to execute once again.

We can specify these options while creating a job definition.


52

Therefore, we can create job dependency for two independent jobs. Likewise we can create 40 dependencies in TWS 8.4. Create this job dependency through Job Stream in JSC. Adding job dependencies: Open job stream editor, add two independent jobs, and go to explorer mode. Add the second job as successor to the first job, so that the second job will be dependent on the first one. The dependent job may run in any workstation, it is not necessary that dependencies should be in a single workstation.

For example, here two independent jobs JOB1 in LINUXCOE1 & SOLRM in SOLARIS1 are running. JOB1 is first job & SOLRM is second job. We can make the second job as dependent to first job. Click Explorer; add the second job as successor to the first one.


53

After adding the second job as successor to the first, the graphical view will be

TWS Troubleshooting Resetting the production plan ResetPlan to recover the corrupt Symphony file on the master Follow these steps on the master domain manager: 1. Set the job "limit" to 0, using conman or the Job Scheduling Console. This prevents jobs from launching. 2. Shut down all Tivoli Workload Scheduler processes on the master domain manager. 3. Run ResetPlan. 4. Run JnextPlan 5. Check the created plan and ensure that you want to run all the instances it contains, deleting those that you do not want to run. 6. Reset the job "limit" to the previous value. The Symphony file is distributed and production recommences.


54

SYNTAX: ResetPlan [-scratch]. This should be run by the root user. If executed with scratch option: ResetPlan removes all of the plan information allowing the user to create a new plan as if no plan was present before. If executed without scratch option: ResetPlan updates and preserves the information about completed (or cancelled) job stream instances.

This allows the user to create a new plan with only job stream instances in the specified time frame (-from, -to) that were not completed before.

Partially executed job streams still need to be manually modified to cancel jobs that were already executed and that cannot be executed twice.

TWS commands fail with AWSDEJ027E ... Security file is empty or corrupt

Solution:

If Tivoli Workload Scheduler (TWS) commands such as conman, makesec, and dumpsec fail due to the error above it may be necessary to restore the Security file. Cause:

If the Security file is modified by vi or is empty, then the above error will occur and the Security file will need to be recreated.


55

Resolving the Problem:

Recreate the security file: 1. Login as root 2. cd ~twsuser 3. . ./tws_env.sh 4. mv Security Security.bad 5. makesec Security.conf

About Tata Consultancy Services (TCS ) Tata Consultancy Services is an IT services, business solutions and outsourcing organization that delivers real results to global businesses, ensuring a level of certainty no other firm can match. TCS offers a consulting-led, integrated portfolio of IT and IT-enabled services delivered through its unique Global Network Delivery ModelTM recognized as the benchmark of excellence in software development. A part of the Tata Group, Indias largest industrial conglomerate, TCS has over 100,000 of the world's best trained IT consultants in 50 countries. The company generated consolidated revenues of US $5.7 billion for fiscal year ended 31 March 2008 and is listed on the National Stock Exchange and Bombay Stock Exchange in India. For more information, visit us at www.tcs.com. Contact us G.K.Ramasubramanian [email protected] V.Prakash [email protected] All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright 2008 Tata Consultancy Services Limited

TWS commands fail with AWSDEJ027E ... Security file is empty or corrupt

8.4 tws small

Documents

introduction scheduler

workload management

cli tws job scheduling

original tivoli product

jsc job scheduling console

track job

job completion status

batch jobs