0% found this document useful (0 votes)
133 views44 pages

TWS Overview

The document is a training material for IBM Tivoli Workload Scheduler (TWS) prepared for ABCR, detailing its general concepts, terminology, and operational procedures. It covers topics such as scheduling applications, managing workstations and calendars, and handling operations and errors within TWS. The document serves as a comprehensive guide for users to effectively utilize TWS for workload management.

Uploaded by

SaKetGupTa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
133 views44 pages

TWS Overview

The document is a training material for IBM Tivoli Workload Scheduler (TWS) prepared for ABCR, detailing its general concepts, terminology, and operational procedures. It covers topics such as scheduling applications, managing workstations and calendars, and handling operations and errors within TWS. The document serves as a comprehensive guide for users to effectively utilize TWS for workload management.

Uploaded by

SaKetGupTa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd

Software Migration Project Office

IBM Tivoli Workload Scheduler


Skill Transfer Material
Prepared for ABCR
TWS Overview

August, 2010

Prepared By:

Athie Moore
Brent Newhouse

Version 1.0
Topics

General Concepts of TWS


Terminology

TWS Dialogs - Main Menu


Navigation

Scheduling - Building an Application


Workstations
Calendars
Periods
Applications
Operations
Runcycle
Daily Planning

Operations - View and Modify


Ready List
Adding an Occurrence
Listing an Occurrence
Listing an Operation
Listing Errors
Error Handling
Job and Step Level Restarts
Reference

1
General TWS Concepts
TWS stands for Tivoli Workload Scheduler

TWS consists of two basic started tasks, a Controller and a Tracker


Additional tasks may also be started on the mainframe (Trackers,
Servers and Data Store)

The Tracker(s) monitor and log the status of work, then pass the
status information to the controller via shared DASD, XCF, or
ACF/VTAM.

The Controller is the focal point of TWS control and information. It


contains the controlling functions, the dialogs, and TWS' own batch
programs.

TWS is predecessor based (when scheduling a job, you state which


job(s) precede it.

TWS may be optionally configured to schedule production workload


on distributed platforms (E2E)

2
TWS Terminology

Application An application is a group of related operations (jobs). I.e. a schedule. A


group of related Payroll jobs running on the same day would be considered
an application.

Operation An operation is a unit of work scheduled through TWS. The majority of work
will be batch jobs. In addition dummy jobs, manual holds, JCL setups,
started tasks and other types of events may be scheduled. Each is
considered an Operation

Workstation A workstation defines to TWS the task that an operation is to perform.


Examples:CPU1 = Batch Jobs NONR = Dummy Jobs MAN1 = Manual Hold

External When a predecessor Job is defined in a different Application, that


Dependency predecessor is considered an external dependency. TWS will always make
the external dependency connection to the closest "same time or earlier"
occurrence of that application.

Runcycle Defines when an Application and its related operations will be scheduled.

IAT Input Arrival Time - Defines the time of day to be associated with each run of
an application. The input arrival time forms part of the key that uniquely
identifies each occurrence on the current plan or long term plan. It is not
necessarily the time TWS attempts to start the first operation in the
occurrence.

Freeday A "non working" day (e.g., holidays, Saturday, Sunday...)

Current Plan This is where your daily workflow will be stored. One time changes are made
to the current plan. The CP is usually extended every workday for 24 work
hours.

Long Term The LTP contains the high level plan of applications to be scheduled. It is
Plan built from the Applications Description database and then serves as input to
the Current Plan. The typical LTP length is 4 to 8 weeks into the future.
Occurrence An application on the current plan or long term plan is referred to as an
occurrence. When adding applications, each one added is considered a
unique occurrence of that application.
(i.e. date and time are unique for a each occurrence of an application)

3
TWS Main Menu

The following can all be reached directly from the main menu:

0 Options
Set System and user preferences

=1.1 Workstations
Create or Modify Workstations assigned to an operation

=1.2 Calendars
Create or Modify Calendars assigned to Applications

=1.3 Periods
Create or Modify definitions for special date(s) processing

=1.4 Applications
Create or Modify an application

=1.5 Operator Instructions


Create or Modify Operator Instructions

=1.6 Special Resources


Create or Modify Special Resources

=1.7 ETT
Define Event Trigger Tracking - adds an application to the Current Plan

=1.9 JCL Variable Table


Create or modify a JCL Variable table - Global Variable substitution

4
=2 Long Term Planning

=3 Daily Planning

Options 0
Before you can access TWS you will need to set your subsystem to point to the correct
TWS Controller.

This can be done by entering 1 on the option line as shown in the example below.

You will then receive the following screen

Update the controller name to OPCB for BRAC. You can also update the description as
has been done in this example.

Please note that other user preferences may also be updated from this screen such
as date and time format.

5
Workstations =1.1

Workstations are usually defined at installation time.

A workstation is not necessarily hardware. It is a stage in the processing that is controlled by


TWS.

Examples of commonly used workstations:

MAN1 Insert a manual hold in your job stream.


CPU1 Assigned to your zOS batch processing
JCL1 A JCL edit is required before the next job can process
NONR The operation is considered a dummy job (use as a place holder)

Reporting Attributes:

A - Automatic
The status change of operations is normally reported automatically, in response to event records
created by the TWS JES and SMF exits.

C - Completion Only
This reporting attribute is normally used for general workstations that are not used for JCL
preparation.

N - Nonreporting
Operations on a nonreporting workstation are set to complete as soon as they become eligible to
be started.

6
S - Start and Complete
This reporting attribute is normally used for general workstations that are used for JCL
preparation

Calendars = 1.2

The calendar specifies normal working days and public holidays. Tivoli Workload
Scheduler for z/OS uses the calendar to determine when applications are
scheduled, and to calculate dates for JCL tailoring.

A calendar is created only if it contains at least one work day.

Consider creating a calendar called DEFAULT.

If no calendar is specified when creating an Application, it will use the default


calendar specified in the BATCHOPT CALENDAR parm for Daily Planning.

If you do not specify the BATCHOPT CALENDAR parm, TWS looks for a
calendar called DEFAULT.

If you do not define a Calendar called DEFAULT, TWS assumes all days are
workdays.

The calendar database may contain multiple calendar definitions.

Calendars may be modified at any time.

7
Periods =1.3

Periods can be CYCLIC or non-CYCLIC.

A CYCLIC period starts on a specific date and has the same number of days in
each interval. There are two kinds of CYCLIC periods:

W - work-days-only cyclic periods where only work days are counted

A - all-days cyclic periods where all the days are counted.

A non-CYCLIC period is defined by specifying the start (and optionally end) of


each interval.

TWS will NOT schedule any applications after the last non-CYCLIC interval start
date you specify, unless you also code an interval end date for that last interval.

8
Building an Application =1.4.3

Predefine your Workstations, Calendars and periods.

Use the OPER command to define you operations (Jobs) (WHAT and WHERE).

Use the RUN command to create a Run Cycle (WHEN it will be loaded to the
Current Plan).

When a Run Cycle is left blank, the application is considered an "on request"
schedule.

Input fields in red are required fields.

Owner ID: consider a standard for the owner id field. Used for security purposes
as well as mass updating.

Use a priority of '5' for applications. The TWS Priority field is NOT the JES job
priority.

Valid From: can be used with a copied application (with modifications) to replace
the existing application on a specific date or range of dates.

Application types:

A- This type of application contains one or more operations. Optionally, it may


have one or more Run Cycles or point to an Application GROUP DEFINITION.

9
G- Group applications contain ONLY Run Cycle definition(s).

Defining Operations

Schedule up to 255 Operations max in one application IF they are numbered


1,2,3 etc..

Use the PRED/TEXT command to toggle between the Operation Text view and
Predecessor view.

Consider setting a standard for operation numbers (003,006,009,012, etc.)

Operation numbers are used to set prececessors. TWS will fill in the leading
zeros: (3) to (003)

Repeating an operation will repeat ALL operation details EXCEPT operator


instructions.

Predecessors:

Internal: Operation(s) found internally within this application


External: Operations in another application that has been defined

Use the "S.1" row command to define additional internal or external


predecessors.

TWS will validate the predecessor operation numbers.

When exiting this panel, duplicate or missing preds will be identified.

Note: If you delete an Application, any external predecessors that reference that
application will show as *NOTFND* (Pred Not Found).

10
Operation Details "Options" S.4 Row Command

Set Time Dependent =Y in Details Options (S.4) to have this operation wait until
the IAT set at the application level.

11
Operation Details "Time" S.6 Row Command

You can override the application IAT as the submit time by updating the
Operation input arrival day and time in (S.6). These "Time / Day Specifications"
override the Application's Run Cycle IAT and Deadline.

Note: The Operation submit time should be later than the Application IAT.

12
Restart Cleanup Options S.9 Row Command
Specify the Restart and Cleanup options for each operation defined in an
Application

You can specify the cleanup action to be taken on specific operations running on
z/OS. Restart and Cleanup is not available for operations running on non-z/OS
platforms.

A - Automatic: the controller automatically finds the cleanup actions to be


taken and also inserts them as first step in the JCL of the restarted job.
Note: This does not automatically restart the job it prepares the job for operator
resubmission.

I - Immediate: dataset cleanup will be immediately performed if the operation


ends in error. The operation is treated as if it had the automatic option when
it is rerun. Assumes JOB RESTART.

M - Manual: dataset cleanup actions are deferred for the operation. They will be
performed when initiated manually from the dialog.

N - None: dataset cleanup actions are not possible for the operation if it ends
in error or is rerun (no dataset info is maintained by TWS.)

Expanded JCL: Specify if TWS will use the JCL extracted from JESJCL sysout:
Y - Use the fully Expanded JCL.
N - Use the JCL contained in OPC libraries.

User Sysout : Specify if User Sysout support is needed


Y - retrieve "Unstructured" data from Data Store (i.e., joblog, etc.)
N - do not retrieve "Unstructured" data from Data Store

13
Suggested values: Cleanup Type = A, Expanded JCL = N, User Sysout =N

Define a Run Cycle

The Run Cycle "Rule Text" name is determined by the production control staff.

Each Run Cycle within an Application must have a unique "Rule text" label (no
dupes.)

Multiple Runcycles may be defined.

Deadline day (00 - today, 01 - tomorrow (over midnight), etc...)

Rule Based - you define the run days based on Frequency, Day, and Cycle
criteria

Offset Based - older technology - uses a period to determine the offset from the
start of the period

Freeday rules are used to determine how an application schedules in the Current
Plan if it's a non-working day. The Freeday rule will check the calendar defined to
this application.

TWS will automatically insert the "In effect" and "out of Effect" date fields if you
press enter

Consider placing meaningful text in the Run Cycles text field.

Defaults: Type = R ; F day rule = 4 ; In Effect date = today ; Out of Effect date = 2071/12/31

FreeDay Rules
1 - Run Before (prior workday)
2 - Run After (next workday)
14
3 - Run on Free (Run on the free day / holiday)
4 - Don't schedule on freeday (do not run on free day / holiday)

Modify a Rule

Use the Gendays command to see a graphical calendar display (current plus 3
years in future.)

Use the "E" command line command to set up interval processing for the
Application

15
Gendays result

Days the application will be scheduled are highlighted in Blue


(Press PF8 to page forward to see next page)

16
Daily Planning
LTP Extend - This is a batch process that reads the TWS Application
Database and rebuilds the long term plan database selecting those
applications that are eligible for its defined time period. The plan can
be extended to a period of time from 1day up to 4 years. Most plans
are extended out 45 days.

17
Daily Planning Cont.

CP Extend - This is a batch process that reads the TWS LTP


database and selects the applications that are eligible for its defined
time period. The current plan is typically extended out 24 hours
Monday – Thursday and 72 hours on Friday. Your site may opt to
extend the plan seven days a week, therefore only extending out 24
hours at a time.

18
Status of the Current Plan =6.6

Use option 6.6 to list the general status of the Current Plan. The
Current Plan is considered expired if the Planning Period End Time
has passed.

19
Helpful screens for Op’s and Scheduling

=4.1 Ready List


View Operations that are (Ready)

=5.1 Add an Occurrence


Adding an Application to the Current Plan

=5.2 List Occurrences


View or Modify Applications on the Current Plan

=5.3 List Operations


Find or Modify Operations on the Current Plan

=5.4 List Errors


Restarts - Job or Step Level

=5.5 List Workstations


View or modify Workstation status

=5.7 Special Resources


View or modify Special Resources on the Current Plan

=6.6 General
View General information about the Current Plan

20
Ready List =4.1

The ready list is used to monitor day to day operations. The layout ID
will allow you to switch between multiple headings.

The ready list is used to view operations that are (ready). You will not
see any batch jobs that have completed or jobs that are waiting on
predecessors.

The ready list displays one Workstation (CPU1,NONR...) at a time.


Use the Layout ID to view different headings. You may create your
own ready list layout for personal use. Copy into the layouts file if you
would like others to have access to your customized layout. A
systems programmer can make the copy.

The ready list is basically a VIEW dialog. You can change the status
of operation in the ready list but, it is suggested that you make
modifications to CPU type operations in =5.3

This is the only dialog that you will see both the status and extended
status on the same panel. Browse the operation for details of each
status.

The "N" next logical status should only be used for NON-CPU type
workstations.

You cannot handle error conditions from the Ready List

21
Operation Details I Row Command

Selecting an Operation for more detail will display the dialog above.
Additional information regarding the operation can be found here. If a
list of all related operations is desired, select option 9. The status and
extended status are displayed here.

22
Adding an Occurance =5.1

You may add an application to the Current Plan via the 5.1 option.
The application may contain one or more operations. An application
on the current plan is referred to as an Occurrence.

Automatic Dep:Y/N - Y will enforce pred/succ connections to existing


operations on the current plan. N will ignore the connection.

If you receive a request to "DEMAND/ADD a JOB", use a predefined


application with a job defined as XXXXXXXX. Change the X's to the
job that has been requested.

The occurrence is added when you PF3 out. You will also receive a
message stating that the occurrence has been added.

If an application is predefined with multiple operations, Type: OPER


to remove any unwanted operations prior to the occurrence being
added.

When operations are removed from the application, remaining jobs


connect back to the closest predecessor.

23
Adding an Occurrence Cont.

The date and time fields are filled in for you when the production
scheduler has created a Runcycle for the application you are adding.

Resolve required means that TWS must find a predecessor prior to


adding the Occurrence to the Current Plan.

Occurrence's must have a unique Input Arrival Date and Time. When
adding an Application Occurrence, it cannot pre-exist at the same
date and time on the Current Plan.

24
Listing Occurences =5.2

The "List Occurrence" dialog may be used to view the status of the
whole application.

This will give you a high level overview of your daily workflow.

You can View or Modify operations found in the individual


applications.

List Occurrences gives you control at the application level. Be careful


that you don't accidentally delete an occurrence. It will delete all
operations/jobs found within that application.

Using either =5.2 List Occurrence or =5.3 List Operations is personal


preference.

Status
C All operations in the occurrence are complete
E One or more operations in the occurrence are in error
S One or more operations have been submitted
U Undecided (the status is not known)
W No operations in the occurrence have started.
25
Listing Operations =5.3

Use option 5.3 if you prefer a more global view of all operations on the current
plan. Many filters are in place to see only desired information. Example: only
operations that begin with PAY*, only completed operations, etc.. One
consideration, the DEL command will delete the entire application.

Use the "Listing Operations" panel to view or modify operations. You have full
control over an operation defined to the current plan.

Any changes to an operation are considered a one time temporary change to that
operation.

Use the "M" row command to make modifications to the operation. You can
change the time, dependencies, JCL or special resources for that particular
operation.

Use the "B" row command to view operations detail. The browse command gives
you additional options such as viewing internal dependencies (found within that
application) as well as external dependencies (found in other applications).

Row commands can be fast pathed, example: B.9 row command to list all
dependencies

Use the "SORT" primary line command to display your results according to your
personal preferences

26
Error Handling =5.4

Note: A LAYOUT ID determines the headings used on the error list. A


default LAYOUT ID (OPCESA) is provided.

27
Error Handling Cont.

Note: Type the EXTEND command to expand the row command


descriptions.

Restart Types

SJR - Simple Job restart


Use the SJR row command to restart a job from the first step. SJR can be used
when specific restart and cleanup actions are not required. Enter (Y) at the
confirmation dialog to initiate the restart. If Cleanup type is set to (Automatic),
then dataset cleanup occurs.

RC - Restart Cleanup
Step Level (option 1) Use the Step Level restart option if the job requires you to
restart at a specific step. TWS will provide a Best Step suggestion that can be
overridden if required. Dataset cleanup (EQQCLEAN) will occur based on the
step selected and the restart cleanup definition for the operation.

Job Level (option 2) Use the Job Level restart option if your job requires a
restart from the first step. Dataset cleanup (EQQCLEAN) will occur before the job
restarts based on the restart cleanup definition for the operation.

FSR - Fast Path Step Restart


Use the FSR option to bypass all restart panels and resubmit the job
immediately. The BEST STEP restart selection (set by TWS) will be used to
determine the step to be restarted. You may need to issue FSR twice, the first
time retrieves the job log, the second time submits the restart.

FJR - Fast Path Job


Use the FJR option to bypass all restart panels and resubmit the job immediately.
Default values are used during the restart. The job will restart from the first step
and perform dataset catalog cleanup actions. You may need to issue FJR twice;
the first time retrieves the joblog, the second time submits the restart.

28
Job and Step Level Restarts Key Points
You are editing a copy of the JCL from the original execution of the
job. This JCL is stored in a VSAM dataset called the JS (JCL
Repository) dataset.

If you receive a request to use JCL from a different JCL Library, enter
"D999" in the editor to delete the existing JCL that resides in the JS
file. Enter the COPY command to pull the JCL from a user defined or
requested library. If a fresh copy of the Production JCL is required,
issue the "D999" row command, PF3 out. If you want to review the
JCL before the rerun, then issue a "J" row command once again.

Ensure that the Job name/Member name match, if the JCL was
copied from another source. If the Job name/member name are a
mismatch you will receive an OSUF error code.

From time to time, an end user may indicate that they have taken
care of the abend or request that the job be bypassed. In this case,
go to the error list (=5.4), find the abended job and complete it with a
"C" row command.

Warning - A CMP row command will not only complete the abended
job but complete the entire application.

If the restart fails a second time, the JCL found in the JS Dataset is a
copy of the restarted Job.

29
Restart Cleanup =5.4

This view shows all jobs that are in abend status. You will notice that the
extend command was issued to expand the details of all the available
commands.

NOTE: RC has been entered on the row command line for job BANTEST6.
This will begin the restart cleanup process for that job.

30
Restart Cleanup Cont.

Points:
Restart and cleanup are basically two tasks:
Restarting an operation at the job-level or the step-level
Cleaning up the associated data sets

When you restart an operation at step-level, you select a step range:


the starting step, the ending step, and any steps to exclude from the
re-run.

In this example we will select 1 for a step restart

Edit JCL: Specify if you want to edit the JCL before restarting the
operation.

Y - Edit the JCL before restart.


N - Do not edit the JCL before restart.

Action taken in this example:


Update Edit JCL to ‘Y” then Select 1 and press enter for a step
restart

31
Restart Cleanup Cont.

Once 1 is entered for step restart you will receive the following message in the
Upper right corner of the screen. Joblog Info Requested.

Once you receive the a message stating the joblog has been retrieved place a
1 in the option field and press enter

32
Restart Cleanup Cont.

The step restart screen will be received. One item of note is the message in the
upper right hand corner. ‘STEPRESCHK(NO) USED.’ This will allow you to
restart the job in any step, not just the step the job failed in.

Once you have located the step you want to restart in enter ‘S’ in the user select
column and the word ‘GO’ in the command field and press enter.

Notes:
The additional steps of the job can be view by pressing PF8 prior to entering go

Restart Cleanup will also flag the best step for restart with a ‘B’ in the restart
column. You are not required to use this step; it is just the most logical step for
the restart.

33
Restart Cleanup Cont.

The edit JCL screen is then received. Modify the JCL on this screen.
Once you have completed your changes type ‘GO’ on the command line and
press enter.

Note: PF8 to page down to view the rest of the JCL.

34
Restart Cleanup Cont.

The confirm restart screen is displayed. Enter a ‘Y’ on the command line to
proceed. You may also enter any comment in the reason for restart field. This is
a free form text field.

35
Restart Cleanup Cont.

Once the cleanup restart process has end you will receive a Completed message
in the Cleanup Result field. You may then press PF3 to exit the restart cleanup
process.

36
Step by Step list of Restart Cleanup
Step Level Restart

Step 1: Determine the reason for the error.

Step 2: Enter the "RC" row command for a step level restart

Step 3: Select the Edit JCL (Y)

Step 4: Select Option 1 to retrieve the joblog - when retrieved, select


option 1 again.

Step 5: Review the Step Level Restart panel (S - starting step E -


Ending step X - exclude)

Step 6: Select the Best Step for restart

Step 7: Enter "GO" to confirm your step selections

Step 8: Modifying the cleanup actions - Enter GO after verifying the


cleanup actions

Step 9: Review or modify the JCL for restart (resolve the error if JCL
related)

Step 10: Enter "GO" to save and continue

Step 11: Enter "Reason for Restart", then "Y" to confirm the step
restart

Step 12: PF3 to exit the Restart and Cleanup panel

Note: The dataset display (Modifying the cleanup actions) noted in


step 8 will only appear if Cleanup Check Option (=0.7) has been
changed to (Y). The default is (N)

37
Job Level Restart Cleanup
Note: Use the Simple Job Restart "SJR" row command to set an
operation status to Ready. Use SJR ONLY when you get a
syntactical JCL error and the job did not execute ANY steps on
the original run.

Simple Job Restart

Step 1: Correct the cause of the error ,select the "J" row command
to edit the JCL if required

Step 2: Determine if this will be a Simple Job Restart - Issue the


"SJR" row command

Step 3: Enter "Reason for restart", then enter "Y" to confirm the
restart

Job Restart

Step 1: Enter the "RC" row command next to the failed job

Step 2: Select Edit JCL (Y)

Step 3: Select Option 2 to retrieve the joblog - when retrieved, select


option 2 again.

Step 4: Modifying the cleanup actions - Enter GO after verifying the


cleanup actions

Step 5: Review the JCL (modify the JCL if required)

Step 7: Enter "GO" to save the JCL and continue forward

Step 8: Enter "Reason for Restart", then enter "Y" to confirm the
restart

Note: The dataset display (Modifying the cleanup actions) noted in


step 4 will only appear if Cleanup Check Option (=0.7) has been
changed to (Y). The default is (N)
38
Quick Reference Material

Short cuts to Key Panels

=1.4.3 - APPLICATION DESCRIPTIONS- This will allow you to select (using a


filter dialog) an existing application to browse, modify or to create a new
application.

=4.1 - READY LIST - The ready list contains operations that have NO
outstanding predecessors. Operations
on the ready list may be waiting for time or a resource.
The ready list also shows operations that have started or have ended in error.

=5.1 - ADDING OCCURRENCES TO THE CURRENT PLAN - Use this dialog to


add an occurrence to the Current Plan.

=5.2 - MODIFYING OCCURRENCES IN THE CURRENT PLAN - Use this dialog


to either browse or modify existing applications on the current plan. The status of
an application may be viewed here.

C – all operations complete.


E - one or more operations ended in error.
W - No operation has started.

=5.3 - MODIFYING OPERATIONS IN THE CURRENT PLAN - Use this dialog to


either browse or modify at the Operation level. Multiple options at the operations
level are available in this dialog.

=5.4 - ERROR LIST - Use this dialog to perform all rerun/restarts. Multiple
options are available to the user at both the Operations level and Occurrence
level.

39
Scheduling Tips

External Dependency

Understanding External Dependency Resolution is KEY

External Dependency Resolution is done based on an Operation's IAT

External Dependency Resolution is ALWAYS done to the CLOSEST External


Occurrence. CLOSEST means "Same time or EARLIER"

An Operation's IAT defaults to the Application Occurrence IAT

To set a specific operation IAT, use the details TIME selection (s.6)

Scheduling database suggestions

Always specify a Calendar in the Application - don't let it default

Set Calendar WDETs (Work Day End Times) to 00.00

Place meaningful text in the operation text field for MANUAL operations

Scheduling database KEY points

To make an operation Time Dependent, use the details AUTOMATIC OPTIONS


selection (s.4)

The default Job Submission flag is Yes (s.4)

To make an operation with at least ONE Internal predecessor Time Dependent,


you must provide both an Operation IA Date and Time (s.6) and set the Time
Dependency flag (s.4)

Copy copies EVERYTHING defined in an Application (except Operator


Instructions - s.7)

Repeating an operation repeats EVERYTHING defined for that operation (except


Oper Instructions – s.7)

40
Operator Tips
Operation statuses

READY means "No uncompleted predecessors"

WAITING means "Has one or more uncompleted predecessors"

WAITING operations will not appear on the WS Ready List (opt4.1)

Monitoring and Controlling Sugestions

Don't Delete Occurrences on the CP; Complete them instead


(You cannot get back a Deleted Occurrence)

Don't Delete Operations in the CP; either change to NONR or use the NP cmd

Monitoring and Controlling points

TWS will not cancel jobs once submitted to JES - i.e., setting an operation to
Complete does NOT cancel the job in JES

TWS will not update the JCL libraries (EQQJBLIB DD)

NP of a Ready NONR completes immediately (ignores Time Dependency)

The correct startup sequence is Tracker(s) tasks first and then the Controller
Note: If Data Store is used the sequence is Tracker(s), Data Store, Controller

The correct shutdown sequence is Controller task first then the Tracker(s)
Note: If Data Store is used the sequence is Controller, Data Store, Tracker(S)

Always stop TWS, never cancel

It is possible to have the Tracker tasks up and available without the Controller.
This scenario will allow job tracking but no job submission.

With TWS you don't add a job, you add an Application. You may add an
operation to an existing application on the Current Plan.

41
Operation Status Codes

Operation status codes:

A Arriving--the operation is ready for processing; no predecessors were defined

R Ready for processing; all predecessors are completed

S Started

C Complete

D Deleted

I The operation is interrupted

* Ready--at least one predecessor is defined on a non reporting workstation; all


predecessors are complete

E The operation has ended-in-error

W The operation is waiting for a predecessor to complete

U Undecided--the operation status is not known

Extended status codes:

X Waiting for resource

H A dialog user has used the HOLD command on the operation

N A dialog user has used the NOP command on the operation

M The status of the operation has been manually set by a dialog

T Waiting until a particular time

E An error occurred during job submission or release

D Closedown in progress.

Q The job has been added to the JES job queue

S The job or started task is executing

U Submit in progress

42
TWS Error Codes
CAN - The job or started task was canceled by the operator or by a
TSO user before execution. This code is also possible if the
job-termination event (type 3P) is missing.

CCUN - The completion code is unknown. The job or started task has
ended, but no completion code is available. This code is also
possible if the job-end event (type 3J) is missing.

OJCV - An error occurred during JCL-variable substitution when the


job or started task was submitted, or the scheduler detected an
error in the RECOVER statement during automatic recovery. Browse
the JCL for the operation or the EQQMLOG data set to find more
information about the failure.

OSEQ - A job or started task began to execute before all its


predecessors had completed. This can occur only if the job was
not submitted by the scheduler and if either HOLDJOB(NO) or
HOLDJOB(USER) is specified for the scheduler event writer
options. For fault-tolerant workstations, the OSEQ code can
indicate that a dependency on another operation or a special
resource was added after the job started, but before the event
reached the controller

OSUB - A failure occurred when the scheduler attempted to submit a


job or start a started task. In the case of a started task, it could
be that the started task is a subsystem that is not started by
JES, or the scheduler subsystem EQQSTC ddname is not allocated
to a JES-defined procedure library. The operation should be
marked as ended-in-error.

OSUF - A failure occurred when the scheduler attempted to retrieve


the JCL for a job or started task. This code is set if the
SUBFAILACTION keyword of the JTOPTS initialization statement
specifies that the operation should be marked as ended-in-error.
This code is also caused if you have JOBCHECK(SAME) and the job
name in the application description does not match the one on
the job card.

Refer to the TWS Manual for additional error codes


43

You might also like