Tivoli Workload Scheduler

®

Version 8.4

Reference Guide

SC32-1274-06

Tivoli Workload Scheduler
®

Version 8.4

Reference Guide

SC32-1274-06

Note Before using this information and the product it supports, read the information in “Notices” on page 573.

This edition applies to version 8, release 4, of IBM Tivoli Workload Scheduler (program number 5698-WSH) and to all subsequent releases and modifications until otherwise indicated in new editions. This edition replaces SC32–1274–05. © Copyright International Business Machines Corporation 1999, 2007. All rights reserved. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents
Figures . . . . . . . . . . . . . . vii Tables . . . . . . . . . . . . . . . ix About this guide . . . . . . . . . . . xi
What is new in this release . . . . . . . . . xi What is new in this publication . . . . . . . . xi What is new in this publication for version 8.4 . . xi Who should read this guide . . . . . . . . xiii What this guide contains . . . . . . . . . xiii Publications . . . . . . . . . . . . . . xv Tivoli Workload Scheduler library . . . . . . xv Related publications . . . . . . . . . . xviii Accessing terminology online . . . . . . . xx Accessing publications online . . . . . . . xxi Ordering publications . . . . . . . . . xxii Using LookAt to look up message explanations xxii Accessibility . . . . . . . . . . . . . xxiii Tivoli technical training. . . . . . . . . . xxiii Support information . . . . . . . . . . . xxiii Conventions used in this publication . . . . . xxiii Typeface conventions . . . . . . . . . xxiv Operating system-dependent variables and paths . . . . . . . . . . . . . . . xxiv Command syntax . . . . . . . . . . . xxiv Customizing date formatting in the stdlist . . Customizing jobs processing on the workstation jobmanrc . . . . . . . . . . . . . . Customizing the MAIL_ON_ABEND section of jobmanrc . . . . . . . . . . . . . Customizing job processing for a user on UNIX workstations - .jobmanrc . . . . . . . . . . 24 . 25 . 26 . 27

Chapter 4. Setting up command-line authentication and user authorizations . 29
What is new in configuring user access . . . Setting up options for using the user interfaces Security management overview . . . . . . Centralized security management . . . . Updating the security file . . . . . . . . dumpsec . . . . . . . . . . . . makesec . . . . . . . . . . . . Configuring the security file . . . . . . . Specifying users . . . . . . . . . . Specifying objects . . . . . . . . . Specifying access . . . . . . . . . Sample security file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 29 31 32 33 34 35 36 38 40 43 51

Chapter 5. Managing the production cycle . . . . . . . . . . . . . . . 55
| What is new in managing the plan
. . . . . . Plan management basic concepts . . . . . . . Preproduction plan . . . . . . . . . . . . Identifying job stream instances in the plan . . . Managing external follows dependencies for jobs and job streams . . . . . . . . . . . . Production plan . . . . . . . . . . . . . Understanding carry forward options. . . . . Trial plan . . . . . . . . . . . . . . . Forecast plan . . . . . . . . . . . . . . Customizing plan management using global options Generating a production plan - JnextPlan . . . . Planman command line . . . . . . . . . . Creating an intermediate production plan . . . Creating an intermediate plan for a plan extension . . . . . . . . . . . . . . Retrieving the production plan information . . . Creating a trial plan . . . . . . . . . . Creating a trial plan of a production plan extension . . . . . . . . . . . . . . Creating a forecast plan . . . . . . . . . Deploying rules . . . . . . . . . . . . Unlocking the production plan . . . . . . . Resetting the production plan . . . . . . . The stageman command . . . . . . . . . . Managing concurrent accesses to the Symphony file Scenario 1: Access to Symphony file locked by other Tivoli Workload Scheduler processes . . . Scenario 2: Access to Symphony file locked by stageman . . . . . . . . . . . . . . 55 55 57 58 59 61 61 63 64 65 69 72 73 75 75 76 78 78 79 80 81 82 84 84 84

Chapter 1. Tivoli Workload Scheduler overview . . . . . . . . . . . . . . 1
Understanding basic concepts . . . . . . . . What is a Tivoli Workload Scheduler network . . How you configure your Tivoli Workload Scheduler runtime environment . . . . . . . How you define scheduling activities using Tivoli Workload Scheduler . . . . . . . . . . . How to control job and job stream processing . . How you manage production scheduling activities with Tivoli Workload Scheduler . . . . . . . How to automate workload using event rules . . Tivoli Workload Scheduler user interfaces . . . . Starting production . . . . . . . . . . . . 1 1 2 2 4 5 6 7 8

|

Chapter 2. Understanding workstation processes . . . . . . . . . . . . . 11
| What is new about workstation processes . . . . 11
Tivoli Workload Scheduler workstation processes . Starting and stopping processes on a workstation Workstation inter-process communication . . . Tivoli Workload Scheduler network communication Support for Internet Protocol version 6 . . . . 11 . 16 . 17 18 . 20

|

|

Chapter 3. Configuring the job environment . . . . . . . . . . . . 21
Job environment overview . . . . . . Environment variables exported by jobman .
© Copyright IBM Corp. 1999, 2007

. .

. .

. 21 . 22

iii

Managing follows dependencies using carry forward prompt . . . . . . . . . . The logman command . . . . . . . . Starting production plan processing . . . Automating production plan processing . .

. . . .

. . . .

. . . .

84 85 87 87

system command unlock . . . . validate . . . version . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

237 238 241 242

| | | | | | | | |

Chapter 6. Running event-driven workload automation . . . . . . . . 89
The event rule management process . . . . . . 92 Using the involved interfaces and commands . . 93 Defining event rules . . . . . . . . . . . 95 Event rule examples . . . . . . . . . . 97 Rule operation notes . . . . . . . . . . 102 Triggered rule elements . . . . . . . . . . 103 Defining custom events . . . . . . . . . . 103

Chapter 9. Managing objects in the plan - conman . . . . . . . . . . . 243
|
What is new in managing objects in production Using the conman command line program . . Setting up the conman environment . . . . Running conman . . . . . . . . . . Running commands from conman . . . . . Wildcards . . . . . . . . . . . . Delimiters and special characters . . . . . Conman commands processing . . . . . Selecting jobs in commands . . . . . . . Syntax . . . . . . . . . . . . . . Arguments . . . . . . . . . . . . Selecting job streams in commands . . . . . Syntax . . . . . . . . . . . . . . Arguments . . . . . . . . . . . . Managing jobs and job streams from back-level agents . . . . . . . . . . . . . . . Command descriptions . . . . . . . . . adddep job . . . . . . . . . . . . adddep sched . . . . . . . . . . . altpass. . . . . . . . . . . . . . altpri . . . . . . . . . . . . . . bulk_discovery . . . . . . . . . . . cancel job. . . . . . . . . . . . . cancel sched . . . . . . . . . . . . confirm . . . . . . . . . . . . . console . . . . . . . . . . . . . continue . . . . . . . . . . . . . deldep job . . . . . . . . . . . . deldep sched . . . . . . . . . . . deployconf . . . . . . . . . . . . display . . . . . . . . . . . . . exit . . . . . . . . . . . . . . . fence . . . . . . . . . . . . . . help . . . . . . . . . . . . . . kill . . . . . . . . . . . . . . . limit cpu . . . . . . . . . . . . . limit sched . . . . . . . . . . . . link . . . . . . . . . . . . . . . listsym . . . . . . . . . . . . . recall . . . . . . . . . . . . . . redo . . . . . . . . . . . . . . release job . . . . . . . . . . . . release sched . . . . . . . . . . . reply . . . . . . . . . . . . . . rerun . . . . . . . . . . . . . . resource . . . . . . . . . . . . . setsym . . . . . . . . . . . . . . showcpus . . . . . . . . . . . . showdomain . . . . . . . . . . . showfiles . . . . . . . . . . . . . showjobs . . . . . . . . . . . . . showprompts . . . . . . . . . . . showresources . . . . . . . . . . . showschedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 243 243 245 247 248 248 249 249 249 249 257 257 257 263 264 267 269 271 272 273 274 276 278 279 280 281 283 285 286 289 290 291 292 293 294 295 297 299 300 302 304 306 307 310 311 312 317 319 321 332 335 337

Chapter 7. Defining objects in the database . . . . . . . . . . . . . 105
| What is new in defining scheduling objects . . . 105
Defining scheduling objects . . . . Workstation definition . . . . . Workstation class definition . . . Domain definition . . . . . . . Job definition . . . . . . . . Windows user definition . . . . Calendar definition . . . . . . Parameter definition . . . . . . Prompt definition . . . . . . . Resource definition . . . . . . Job stream definition . . . . . . Job stream definition keyword details Event rule definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 108 115 117 119 125 127 128 130 132 133 137 178

|

Chapter 8. Managing objects in the database - composer . . . . . . . . 189
What is new in managing objects in the database Using the composer command-line program . . Setting up the composer environment . . . Running the composer program . . . . . Running commands from composer . . . . . Filters and wild cards . . . . . . . . Delimeters and special characters . . . . . Command descriptions . . . . . . . . . Referential integrity check . . . . . . . add. . . . . . . . . . . . . . . authenticate . . . . . . . . . . . . continue . . . . . . . . . . . . . create - extract . . . . . . . . . . . delete . . . . . . . . . . . . . . display . . . . . . . . . . . . . edit . . . . . . . . . . . . . . . exit . . . . . . . . . . . . . . . help . . . . . . . . . . . . . . list, print . . . . . . . . . . . . . lock . . . . . . . . . . . . . . modify . . . . . . . . . . . . . new . . . . . . . . . . . . . . redo . . . . . . . . . . . . . . rename . . . . . . . . . . . . . replace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 190 190 191 194 194 196 197 198 203 205 206 207 210 213 217 218 219 220 224 227 231 232 234 236

|

iv

IBM Tivoli Workload Scheduler: Reference Guide

| | |

| | |

|

shutdown . . . . start . . . . . . startappserver . . . starteventprocessor . startmon . . . . . status . . . . . . stop . . . . . . stop ;progressive . . stopappserver . . . stopeventprocessor . stopmon . . . . . submit docommand . submit file . . . . submit job . . . . submit sched . . . switcheventprocessor . switchmgr . . . . system . . . . . tellop . . . . . . unlink . . . . . . version . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

341 342 345 346 347 348 349 351 352 353 354 355 358 361 363 366 367 368 369 370 372

Chapter 10. Using utility commands
| What is new in using utility commands
Command descriptions . . at and batch . . . . . cpuinfo . . . . . . datecalc . . . . . . delete . . . . . . . evtdef . . . . . . . evtsize. . . . . . . jobinfo. . . . . . . jobstdl . . . . . . . maestro . . . . . . makecal . . . . . . metronome.pl . . . . morestdl . . . . . . parms . . . . . . . release . . . . . . . rmstdlist . . . . . . sendevent . . . . . showexec . . . . . . shutdown . . . . . StartUp . . . . . . version . . . . . . Unsupported commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

373
. . . . . . . . . . . . . . . . . . . . . . . 373 373 375 378 380 384 385 388 390 392 394 395 397 398 400 403 404 405 407 408 409 410 412

| | | |

Report 01 - Job Details Listing: . . . . . . Report 02 - Prompt Listing: . . . . . . . . Report 03 - Calendar Listing: . . . . . . . Report 04A - Parameter Listing: . . . . . . Report 04B - Resource Listing: . . . . . . . Report 07 - Job History Listing: . . . . . . Report 08 - Job Histogram: . . . . . . . . Report 9B - Planned Production Detail: . . . . Report 10B - Actual Production Detail: . . . . Report 11 - Planned Production Schedule: . . . Report 12 - Cross Reference Report: . . . . . Report extract programs . . . . . . . . . . jbxtract . . . . . . . . . . . . . . prxtract . . . . . . . . . . . . . . caxtract . . . . . . . . . . . . . . paxtract . . . . . . . . . . . . . . rextract . . . . . . . . . . . . . . r11xtr . . . . . . . . . . . . . . . xrxtrct . . . . . . . . . . . . . . . Additional reports available on the Tivoli Dynamic Workload Console . . . . . . . . . . . . Historical reports . . . . . . . . . . . Production reports. . . . . . . . . . .

425 428 429 430 431 432 433 434 435 436 438 440 441 443 444 445 446 447 449 454 454 458

Chapter 12. Managing time zones . . . 461
| What is new about managing time zones . . . . 461
Enabling time zone management . . . . . . How Tivoli Workload Scheduler manages time zones . . . . . . . . . . . . . . . Moving to daylight saving time on . . . . . Moving to daylight saving time off . . . . . General rules . . . . . . . . . . . . Backward compatibility time zone table . . . Complete table of time zones with variable length notation . . . . . . . . . . . . . . . 461 . . . . . 462 464 464 464 465

|

. 466

Chapter 13. The auditing feature . . . 483
Auditing overview . . . Enabling the auditing feature Audit log format . . . . Audit log header format . Audit log body format . Sample audit log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 483 484 484 484 487

|

Chapter 14. Managing extended agents . . . . . . . . . . . . . . 489
What are extended agents? . . . Workstation definition . . . Access method interface . . . . Method command line syntax . Method response messages . . Method options file . . . . Method running . . . . . . Launch job task (LJ) . . . . Manage job task (MJ) . . . . Check file task (CF) . . . . Get status task (GS) . . . . Cpuinfo command . . . . Troubleshooting . . . . . . Job standard list error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 490 490 490 492 493 494 494 495 495 495 496 496 496

Chapter 11. Getting reports and statistics . . . . . . . . . . . . . 413
| What is new in running reports and statistics. . . 413
Setup for using report commands Changing the date format . . Command descriptions . . . . rep1 - rep4b . . . . . . . rep7 . . . . . . . . . rep8 . . . . . . . . . rep11 . . . . . . . . . reptr . . . . . . . . . xref . . . . . . . . . . Sample report outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 414 414 416 417 419 421 422 424 425

Contents

v

Method not executable . . . . Console Manager messages . . . Composer and compiler messages Jobman messages . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

497 497 497 497

|

GenericAction actions

.

.

.

.

.

.

.

.

. 542

Appendix B. Web services interface

545

Chapter 15. Managing internetwork dependencies . . . . . . . . . . . 499
What is new about internetwork dependencies . Internetwork dependencies overview . . . . Understanding how an internetwork dependency is shown . . . . . . . . Configuring a network agent . . . . . . . A sample network agent definition . . . . Defining an internetwork dependency . . . . A sample internetwork dependency definition See Also . . . . . . . . . . . . . Managing internetwork dependencies . . . . States of jobs defined in the EXTERNAL job stream . . . . . . . . . . . . . . Working with jobs defined in the EXTERNAL job stream . . . . . . . . . . . . Sample internetwork dependency management scenarios . . . . . . . . . . . . . Internetwork dependencies in a mixed environment . . . . . . . . . . . . . . 499 . 499 500 501 502 503 503 . 504 . 504 . 504 . 505 . 505 . 507 . . . .

Appendix C. Quick reference for commands . . . . . . . . . . . . 547
Managing the plan . . . . . Managing objects in the database . General purpose commands . Scheduling objects . . . . . Composer commands . . . Managing objects in the plan . . Conman commands . . . . Utility commands . . . . . . Report commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547 548 548 549 553 557 557 561 563

Appendix D. Support information . . . 565
Using IBM Support Assistant . . . . . . . . Tivoli Workload Scheduler IBM Support Assistant plug-in version and upgrade issues . . Searching knowledge bases . . . . . . . . . Searching the local information center . . . . Searching the Internet . . . . . . . . . Obtaining fixes . . . . . . . . . . . . . Receiving weekly support updates . . . . . . Contacting IBM Software Support . . . . . . Determining the business impact . . . . . . Describing problems and gathering information Submitting problems . . . . . . . . . . 565 565 566 566 566 567 567 569 570 570 570

| | | | | | | | | | |

Appendix A. Event-driven workload automation event and action definitions . . . . . . . . . . . . . 509
Event providers and definitions TWSObjectsMonitor events . FileMonitor events . . . Action providers and definitions TECEventForwarder actions MailSender actions . . . MessageLogger actions . . TWSAction actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509 509 534 537 537 538 539 539

Notices . . . . . . . . . . . . . . 573
Trademarks . . . . . . . . . . . . . . 574

Glossary . . . . . . . . . . . . . 577 Index . . . . . . . . . . . . . . . 585

vi

IBM Tivoli Workload Scheduler: Reference Guide

Figures
1. 2. 3. 4. 5. 6. 7. 8. 9. Process tree in UNIX . . . . . . . . Process tree in Windows . . . . . . . Inter-process communication . . . . . . Closest preceding matching criteria . . . Within a relative interval matching criteria Within an absolute interval matching criteria Sameday matching criteria . . . . . . Closest preceding predecessor job . . . . Pending predecessor instance . . . . . . . . . 14 15 18 59 59 59 . 60 . 60 . 61 10. 11. 12. 13. 14. 15. 16. Network links . . . . . . . . Started workstations in network . . Stopped workstations in network . . Unlinked network workstations . . Example when start of day conversion applied . . . . . . . . . . Example when start of day conversion applied . . . . . . . . . . Local and remote networks . . . . . . . . is . is . . . . . . not . . . . . . . 296 343 350 371

. 463 . 463 . 502

© Copyright IBM Corp. 1999, 2007

vii

viii

IBM Tivoli Workload Scheduler: Reference Guide

Tables
| |
1. Documentation updates summary . . . . . xii 2. Command syntax . . . . . . . . . . xxiv 3. Starting and stopping Tivoli Workload Scheduler on a workstation . . . . . . . 16 4. Job environment variables for Windows 22 5. Job environment variables for UNIX . . . . 23 6. Variables defined by default in the jobmanrc file . . . . . . . . . . . . . . . 25 7. Object attributes . . . . . . . . . . . 40 8. Access keywords . . . . . . . . . . . 44 9. Carry forward global options settings . . . . 62 10. Resulting carry forward settings . . . . . 62 11. Simple event rule scenarios . . . . . . . 90 12. conman commands for managing monitoring engines . . . . . . . . . . . . . . 92 13. conman commands for managing the event processing server. . . . . . . . . . . 93 14. Interfaces and commands for managing event-driven workload automation . . . . . 94 15. Event rule definition for scenario1 . . . . . 98 16. Event rule definition for scenario2 . . . . . 99 17. Event rule definition for scenario3 . . . . 100 18. Event rule definition for scenario4 . . . . 101 19. Rule operation notes . . . . . . . . . 102 20. List of supported scheduling object keywords 106 21. List of reserved words when defining jobs and job streams . . . . . . . . . . . 106 22. List of reserved words when defining workstations . . . . . . . . . . . . 107 23. List of reserved words when defining users 107 24. Option settings for workstation types 109 25. Type of communication depending on the security level value . . . . . . . . . 112 26. Comparison operators . . . . . . . . 121 27. Logical operators . . . . . . . . . . 121 28. Recovery options and actions . . . . . . 122 29. List of scheduling keywords . . . . . . 134 30. Explanation of the notation defining the number of occurrences for a language element. . . . . . . . . . . . . . 178 31. TWSObjectsMonitor events. . . . . . . . 181 32. FileMonitor events. . . . . . . . . . 182 33. Action types by action provider. . . . . . 184 34. Scheduling objects filtering criteria . . . . 195 35. Delimeters and special characters for composer . . . . . . . . . . . . . 196 36. List of composer commands . . . . . . 197 37. Object identifiers for each type of object defined in the database . . . . . . . . 199 38. Object definition update upon deletion of referenced object . . . . . . . . . . 199 39. Referential integrity check when deleting an object from the database . . . . . . . . 200 40. Output formats for displaying scheduling objects . . . . . . . . . . . . . . 215 41. Output formats for printing scheduling objects . . . . . . . . . . . . . . 42. Delimeters and special characters for conman 43. List of conman commands . . . . . . . 44. State change after confirm command 45. Opened links . . . . . . . . . . . 46. Started workstations . . . . . . . . . 47. Stopped workstations . . . . . . . . . 48. Stopped workstations with stop ;progressive 49. Unlinked workstations . . . . . . . . 50. List of utility commands . . . . . . . . 51. Date formats . . . . . . . . . . . . 52. List of report commands . . . . . . . . 53. Report extract programs. . . . . . . . . 54. Jbxtract output fields . . . . . . . . . 55. Prxtract output fields . . . . . . . . . 56. Caxtract output fields . . . . . . . . . 57. Paxtract output fields . . . . . . . . . 58. Rextract output fields . . . . . . . . . 59. R11xtr output fields . . . . . . . . . 60. Xdep_job output fields . . . . . . . . 61. Xdep_job output fields (continued) . . . . 62. Xdep_sched output fields . . . . . . . 63. Xfile output fields . . . . . . . . . . 64. Xjob output fields . . . . . . . . . . 65. Xprompts output fields . . . . . . . . 66. Xresource output fields . . . . . . . . 67. Xsched output fields . . . . . . . . . 68. Xwhen output fields . . . . . . . . . 69. Summary of historical reports . . . . . . 70. Summary of production reports . . . . . 71. Backward compatibility time zone table 72. Variable length notation time zones list 73. Method command task options . . . . . 74. Launch job task (LJ) messages . . . . . . 75. Check file task (CF) messages . . . . . . 76. Get status task (GS) messages . . . . . . 77. Internetwork dependencies in a mixed environment . . . . . . . . . . . . 78. Parameters of JobStatusChanged event types. 79. Parameters of JobUntil event types. . . . . 80. Parameters of JobSubmit event types. 81. Parameters of JobCancel event types. 82. Parameters of JobRestart event types. 83. Parameters of JobLate event types. . . . . 84. Parameters of JobStreamStatusChanged event types. . . . . . . . . . . . . . . 85. Parameters of JobStreamCompleted event types. . . . . . . . . . . . . . . 86. Parameters of JobStreamUntil event types. 87. Parameters of JobStreamSubmit event types. 88. Parameters of JobStreamCancel event types. 89. Parameters of JobStreamLate event types. 90. Parameters of WorkstationStatusChanged event types. . . . . . . . . . . . . 222 248 264 278 296 343 350 351 371 373 414 414 440 441 443 444 445 446 447 449 449 450 450 451 451 452 452 453 454 459 465 466 491 494 495 496 507 510 511 513 515 516 518 520 522 523 525 526 527 529

| | | | | | | | | | | | |

| |

| | | | | |

| | | | | | | | | | | | | | | |

© Copyright IBM Corp. 1999, 2007

ix

| 91. Parameters of ApplicationServerStatusChanged event types. . | | 92. Parameters of ChildWorkstationLinkChanged event types. . . . . . . . . . . . . | | 93. Parameters of ParentWorkstationLinkChanged event types. . . . . . . . . . . . . | | 94. Parameters of PromptStatusChanged event types. . . . . . . . . . . . . . . | | 95. Parameters of FileCreated event types. | 96. Parameters of FileDeleted event types. | 97. Parameters of ModificationCompleted event types. . . . . . . . . . . . . . . | | 98. Parameters of LogMessageWritten event types. . . . . . . . . . . . . . . | | 99. Parameters of TECFWD action types. | 100. Parameters of SendMail action types. | 101. Parameters of MSGLOG action types. | 102. Parameters of SubmitJobStream action types.

530 531 531 532 534 535 535 536 537 538 539 539

| | | |

103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116.

Parameters of SubmitJob action types. Parameters of SubmitAdHocJob action types. Parameters of ReplyPrompt action types. Parameters of RunCommand action types. Available messages in the Web services interface . . . . . . . . . . . . . Commands used against the plan . . . . . General purpose commands . . . . . . Commands used against scheduling objects in the database . . . . . . . . . . . . Commands that can be run from conman Utility commands available for both UNIX and Windows . . . . . . . . . . . Utility commands available for UNIX only Utility commands available for Windows only Report commands . . . . . . . . . . Report extract programs . . . . . . . .

540 541 542 542 546 547 548 553 558 561 562 562 563 564

x

IBM Tivoli Workload Scheduler: Reference Guide

see Tivoli Workload Scheduling Suite: Overview. and controls the processing of your enterprise’s entire production workload. and utility commands for Tivoli Workload Scheduler.3. 1999.com/support/ docview.4.02. see the Tivoli Workload Scheduler Download Document at http://www. Tivoli Workload Scheduler plans. changed or added text is marked by a revision bar in the left margin. Note: Throughout the document.wss?rs=672&uid=swg24016672.About this guide IBM® Tivoli® Workload Scheduler simplifies systems management across distributed environments by integrating systems management functions. scheduling language. the following changes have been made to document the new features: © Copyright IBM Corp. What is new in this publication for version 8. What is new in this publication This section describes what has changed in this publication since version 8. What is new in this release For information about the new or changed functions in this release. For information about the APARs that this release addresses. automates. 2007 xi .ibm. The Tivoli Workload Scheduler Reference Guide provides detailed information about the command line interface.4 For version 8.

response to predefined events. and show the event rules deployed on an agent. download the latest monitoring configuration file. v Chapter 6. “Understanding workstation processes.” on page 55 describes the new planman deploy command for manual rule deployment. “Using utility commands. xii IBM Tivoli Workload Scheduler: Reference Guide .” on page 509 documents in detail all available event and action types and their properties.” on page 89 provides an overview of the event rule management feature. “Managing objects in the database composer. “Setting up command-line authentication and user authorizations.” on page 29 documents additional security file authorizations for defining and using event rules and for managing the event rule management agents and server v Chapter 5. and switch the event processing server. v Chapter 8. v Chapter 4. “Managing objects in the plan . start and stop the monitoring manager. “Tivoli Workload Scheduler overview.conman. v Chapter 2. “Managing the production cycle.” on page 105 provides reference for defining event rules. v Chapter 10. stop.” on page 243 provides reference for the new commands that start.What is new in this guide Table 1. “Running event-driven workload automation. “Defining objects in the database.” define and run rules that carry on page 1 includes section “How to automate out predefined actions in workload using event rules” on page 6. Documentation updates summary Feature Event-driven workload automation Description Documentation changes Provides the capability to v Chapter 1.” on page 189 provides reference for managing event rule definitions. v Appendix A. “Event-driven workload automation event and action definitions.” on page 11 describes the monman process.” on page 373 provides reference for the new commands for defining custom events and for forwarding them to the event processing server. v Chapter 9. v Chapter 7.

v Chapter 5.” on page 11 includes an overview in section “Support for Internet Protocol version 6” on page 20.conman. “Understanding workstation processes. Section “Starting and stopping processes on a workstation” on page 16 has changed to reflect changes in startup commands.” on page 29 documents additional security file authorizations for running the reports. Chapter 2. and explains the basic steps a new user should follow to begin to use the product for the first time. “Managing objects in the plan . What this guide contains This manual contains the following chapters and appendixes: v Chapter 1. “Understanding workstation processes. “Setting up command-line authentication and user authorizations.” on page 55 in section “Generating a production plan JnextPlan” on page 69 explains how the JnextPlan command and the final job stream now start WebSphere Application Server automatically as their first step. “Tivoli Workload Scheduler overview. Support for new time zones has been added.” on page 11 Describes workstation processes and network communication in a Tivoli Workload Scheduler environment during job processing.” on page 21 About this guide xiii . Documentation updates summary (continued) Feature Application server manager service (appserverman) Description Starts the embedded WebSphere Application Server and restarts it automatically if it goes down. v Chapter 3.” on page 29 documents additional security file authorizations for starting and stopping the applications server.What is new in this guide Table 1. “Understanding workstation processes. Chapter 12. v Chapter 4. eliminating the need to run the CheckPrerequisites script. “Managing the production cycle.” on page 1 Provides you with a quick introduction to Tivoli Workload Scheduler and its user interfaces. Support for Internet Protocol version 6 New time zones Support for this new version along with the previous one. v An overview of these reports is in “Additional reports available on the Tivoli Dynamic Workload Console” on page 454. Detailed online help is provided by the Tivoli Dynamic Workload Console. v Chapter 2. “Managing time zones. “Setting up command-line authentication and user authorizations. Tivoli Dynamic Workload Console history and production reports Additional reports that can be run on the Tivoli Dynamic Workload Console. v Chapter 4.” on page 11 describes the appserverman process. v Chapter 9.” on page 461 shows an updated list of all supported time zones in Table 72 on page 466.” on page 243 provides reference for the new commands that start and stop the application server. Documentation changes v Chapter 2. “Configuring the job environment. Who should read this guide This guide is intended for administrators and advanced users of Tivoli Workload Scheduler.

” on page 413 Describes how to use different types of reports. “Managing objects in the database . v Appendix A.” on page 489 Describes how to create and use extended agents.” on page 89 Provides an overview of event rule management.” on page 547 Contains a quick reference for commands. “Quick reference for commands. “Managing objects in the plan . Chapter 6.” on page 373 Describes the Tivoli Workload Scheduler utility commands that manage the environment.conman. v Chapter 12. used to perform job processing where an agent is not installed. that you can define in the Tivoli Workload Scheduler DB2 database. “Managing time zones. v Appendix B. Chapter 7. including job streams with the related keywords.” on page 545 Gives an introduction to the use of the Tivoli Workload Scheduler Web Services Interface. “Using utility commands. v Chapter 13. “Getting reports and statistics.” on page 189 Explains the usage and the syntax of the commands used in the composer command-line interface to manage scheduling objects in the database. “Defining objects in the database. v Chapter 11. that is logical definitions. “Managing extended agents. v Chapter 9.” on page 483 Describes how to enable and use the auditing option to track changes applied to the database and to the plan.” on page 105 Describes the scheduling objects. “Running event-driven workload automation. “Managing internetwork dependencies.composer. v Chapter 15. v Chapter 10. v Chapter 14.” on page 243 Describes the usage and the syntax of the commands used in the conman command-line interface to monitor and manage job and job stream instances in production. “Managing the production cycle. xiv IBM Tivoli Workload Scheduler: Reference Guide .” on page 461 Describes how to manage the time zones with Tivoli Workload Scheduler. Chapter 4.” on page 29 Describes how to set up the user environment to use command line programs and how to manage user access to objects using the security file. “The auditing feature. “Web services interface. It also includes utility and report commands.” on page 499 Describes how to create and use a network agent workstation to manage dependencies of locally defined jobs and job streams from jobs and job streams running in a remote Tivoli Workload Scheduler network. “Setting up command-line authentication and user authorizations. Chapter 5.” on page 55 Describes how Tivoli Workload Scheduler performs plan management. v v v v v Chapter 8. each hosted by a physical workstation.” on page 509 Provides a complete description of all event and action types for use when defining event rules.What this guide contains Describes how to customize the way job management is performed on a workstation. “Event-driven workload automation event and action definitions. v Appendix C.

v Tivoli Workload Scheduler: Dynamic Workload Console Installation and Troubleshooting Guide.” on page 565 Describes how to obtain support for IBM products. and the way they can be used together to provide workload management solutions for your whole enterprise.com/support/docview. IBM Tivoli Workload Scheduling suite library The following publications are available in the IBM Tivoli Workload Scheduling suite library.wss?rs=672&uid=swg24016672 This provides full information about downloading the product CD images. IBM Tivoli Workload Scheduler for Applications library This library contains all publications that apply only to IBM Tivoli Workload Scheduler for Applications. It also indicates the APARs that have been fixed in this release. Publications This section lists publications in the Tivoli Workload Scheduler library and any other related publications. SC32-1256 Provides an overview of all Tivoli Workload Scheduler products.com/support/docview.ibm. and components. About this guide xv . regardless of operating system. IBM Tivoli Workload Scheduler for Virtualized Data Centers library This library contains all publications that apply only to IBM Tivoli Workload Scheduler for Virtualized Data Centers. This library includes publications that are common to all products. Note: This manual used to be called "General Information". using a common Web-based GUI called the Dynamic Workload Console. SC32-1572 Describes how to work with Tivoli Workload Scheduler. IBM Tivoli Workload Scheduler distributed library This library contains all of the publications that refer to the use of Tivoli Workload Scheduler on operating systems other than z/OS®.What this guide contains v Appendix D. v Tivoli Dynamic Workload Console System Requirements Document at http://www. IBM Tivoli Workload Scheduler for z/OS library This library contains all publications that apply only to IBM Tivoli Workload Scheduler for z/OS.ibm.wss?rs=672&uid=swg27010503 This provides full information about the hardware and software prerequisites of the product. operating systems. v Tivoli Workload Scheduling Suite: Overview. Tivoli Workload Scheduler library Tivoli Workload Scheduler comprises several separate products available for a variety of operating systems. “Support information. It also describes how to access Tivoli publications online and how to order Tivoli publications. v Tivoli Dynamic Workload Console Download Document at http:// www. The library is divided into: IBM Tivoli Workload Scheduling suite library This library contains all cross-platform and cross-product publications for Tivoli Workload Scheduler.

Tivoli Workload Scheduler: Reference Guide. It includes help on many messages generated by the main components of Tivoli Workload Scheduler. and how to integrate Tivoli Workload Scheduler with NetView®. in the following path: TDW_enablement_pack/tdw_weps/aws/v8300/doc/itws_for_TDW.1. and how extended and network agents work. and Tivoli Enterprise Console®. in the same way that you can the other books (see “Accessing publications online” on page xxi).wss?rs=672&uid=swg24016672 This provides full information about downloading the product CD images.2 and 1.doc You cannot access it online.ibm. v Tivoli Workload Scheduler Download Document at http://www. GC23-6141 Provides information on how to get started with an installation of Tivoli Workload Scheduler on distributed operating systems. SC32-2261 Provides information about the views of the IBM Tivoli Workload Scheduler database.1 Implementation Guide for Tivoli Data Warehouse. SC32-1275 Provides information about how to administer Tivoli Workload Scheduler on distributed operating systems.3 Provides information about enabling Tivoli Workload Scheduler for Tivoli Data Warehouse. SC32-1273 Describes how to plan for and install IBM Tivoli Workload Scheduler on distributed operating systems. Tivoli Monitoring. Tivoli Workload Scheduler: Using Microsoft Cluster Service on Windows Server 2003. regardless of operating system. and what to do if things go wrong. Tivoli Workload Scheduler: Database Views. using a common GUI called the Job Scheduling Console. It also indicates the APARs that have been fixed in this release. This library contains publications that refer to using the product on distributed operating systems (all operating systems except z/OS). v v v v v xvi IBM Tivoli Workload Scheduler: Reference Guide .ibm.com/ support/docview. Tivoli Workload Scheduler: Planning and Installation Guide.Publications v Tivoli Workload Scheduler: Job Scheduling Console User’s Guide. versions 1. SC32-1274 Provides an explanation of the concepts of Tivoli Workload Scheduler and describes how the product is used. Tivoli Workload Scheduler: Administration and Troubleshooting. Tivoli Data Warehouse.3: Warehouse Enablement Pack version 1. v Tivoli Workload Scheduler System Requirements Document at http://www. v Tivoli Workload Scheduler: Quick Start Guide. Also describes the Tivoli Workload Scheduler command line used on distributed operating systems. SC23-6119 Describes how to use Tivoli Workload Scheduler with the Microsoft® Cluster service on Windows® Server 2003 to achieve high availability.wss?rs=672&uid=swg27010396 This provides full information about the hardware and software prerequisites of the product. v Tivoli Workload Scheduler. IBM Tivoli Workload Scheduler distributed library The following publications are available in the IBM Tivoli Workload Scheduler distributed library. SC32-1257 Describes how to work with Tivoli Workload Scheduler. This publication is only available on the Tivoli Workload Scheduler Engine Installation CD "TWS84_OTHER".com/support/docview. version 8.

configure. v Java™ API documentation. Provides information about using the Java Application Programming Interface (API). v Tivoli Workload Scheduler for z/OS: Programming Interfaces. Mount the CD for your platform and open the following file with your Internet browser: <CD_drive>/API/doc/index. v Tivoli Workload Scheduler for z/OS: Managing the Workload. v Tivoli Workload Scheduler for z/OS: Messages and Codes. See http://www. GI11-4209 Provides a summary of changes for the current release of the product. v Tivoli Workload Scheduler for z/OS: Installation Guide. SC32-1261 Provides information to help diagnose and correct possible problems when using Tivoli Workload Scheduler for z/OS.Publications v Tivoli Workload Scheduler: Limited Fault-tolerant Agent for i5/OS. SC32-1263 Explains how to plan and schedule the workload and how to control and monitor the current plan. SC32-1268 Provides a quick and easy consultation reference to operate Tivoli Workload Scheduler for z/OS. v Tivoli Workload Scheduler for z/OS: Memo to Users.ibm. SC32-1280 Describes how to install. SC32-1266 Provides information to write application programs for Tivoli Workload Scheduler for z/OS. v Tivoli Workload Scheduler for z/OS: Diagnosis Guide and Reference. v Tivoli Workload Scheduler for z/OS: Quick Reference. About this guide xvii . SC32-1265 Describes how to customize Tivoli Workload Scheduler for z/OS.html. controlling workload in a distributed environment from a z/OS master domain manager. and use Tivoli Workload Scheduler limited fault-tolerant agents on i5/OS. SC32-1264 Describes how to install Tivoli Workload Scheduler for z/OS. This is a set of available classes and methods running in a JAVA environment that you use to create a custom interface to manage scheduling objects in the database and in the plan. SC32-1267 Explains messages and codes in Tivoli Workload Scheduler for z/OS. Documentation for the API is provided on all distributed product CDs. They cannot be used to manage the plan or to set global options. SC32-1262 Discusses how to define your installation data for Tivoli Workload Scheduler for z/OS and how to create and modify plans. v Tivoli Workload Scheduler for z/OS: Scheduling End-to-end. SC32-1732 Provides information on how to integrate Tivoli Workload Scheduler for z/OS with Tivoli Workload Scheduler. IBM Tivoli Workload Scheduler for z/OS library The following publications are available in the Tivoli Workload Scheduler for z/OS library: v Tivoli Workload Scheduler for z/OS: Getting Started. v Tivoli Workload Scheduler for z/OS: Customization and Tuning.com/software/tivoli/products/scheduler/ for an introduction to the product.

wss?rs=673&uid=swg24013044 This provides full information about downloading the product CD images. v Tivoli Workload Scheduler for Virtualized Data Centers: Release Notes.ibm.html for an introduction to the product. SC32-1454 Describes how to extend the scheduling capabilities of Tivoli Workload Scheduler to workload optimization and grid computing by enabling the control of IBM LoadLeveler® and IBM Grid Toolbox jobs.ibm. GC32-1538 Gives an overview on how to get started with Tivoli Workload Scheduler for Applications. and use the IBM Tivoli Workload Scheduler access methods that run and control jobs of the following applications: – Oracle – PeopleSoft – R/3 – z/OS v Tivoli Workload Scheduler for Applications: Quick Start Guide.Publications v Tivoli Workload Scheduler for z/OS: Program Directory.ibm.ibm. IBM Tivoli Workload Scheduler for Virtualized Data Centers library The following publications are available in the IBM Tivoli Workload Scheduler for Virtualized Data Centers library: v Tivoli Workload Scheduler for Virtualized Data Centers: User’s Guide. See http://www.com/software/tivoli/products/scheduler-zos/ for an introduction to the product. Related publications The following publications also provide useful information: xviii IBM Tivoli Workload Scheduler: Reference Guide . SC32-1278 Provides information on how to install. set up. v Tivoli Workload Scheduler for Applications System Requirements Document at http://www.com/support/docview.wss?rs=673&uid=swg27007885 This provides full information about the hardware and software prerequisites of the product. See http://www. SC32-1453 Provides late-breaking information about Tivoli Workload Scheduler for Virtualized Data Centers.com/software/tivoli/products/scheduler-apps/ for an introduction to the product. v Tivoli Workload Scheduler for Applications Download Document at http://www.com/software/info/ecatalog/en_US/ products/ Y614224T20392S50. It also indicates the APARs that have been fixed in this release. GI11-4248 Provided with the installation tape for Tivoli Workload Scheduler for z/OS. describes all of the installation materials and gives installation instructions specific to the product release level or feature number.com/support/docview. See http://www.ibm. IBM Tivoli Workload Scheduler for Applications library The following publications are available in the IBM Tivoli Workload Scheduler for Applications library: v Tivoli Workload Scheduler for Applications: User’s Guide.

which has replaced the JnextDay process in this release.2 to Improve Performance.redbooks. it covers IBM Tivoli Workload Scheduler V8. and JnextPlan. Scheduling is a mission critical process for any company. and so on. each solution is a building About this guide xix . best practices. Clients and Tivoli professionals who are responsible for installing. This IBM Redbook documents the architecture. SG24-6648 Abstract: This IBM Redbook explains the benefits and technical merits of integrating IBM Tivoli Workload Scheduler Distributed and IBM Tivoli Workload Scheduler for z/OS with other IBM products. This Redbook can be found on the Redbooks Web site at http:// www.com/abstracts/sg247237.3.3: Best Practices and Performance Improvements. tuning for performance. comes with some important enhancements.ibm. Topics covered include: – Installation best practices – Installation verification – Started tasks – Communication – Initialization statements and parameters – Security – Exits – Restart and cleanup – Dataset triggering and event trigger tracking – Variables – Audit report facility This Redbook can be found on the Redbooks Web site at http:// www.com/abstracts/sg246352.html v IBM Redbooks: IBM Tivoli Workload Scheduler for z/OS: Best Practices. SG24-6352 Abstract: This IBM Redbook covers the techniques that can be used to improve the performance of Tivoli Workload Scheduler for z/OS (including end-to-end scheduling). The new version of the product. and migration scenarios for IBM Tivoli Workload Scheduler V8. new application programming interface (API). IBM Tivoli Workload Scheduler V8. such as relational database management system support.ibm. or using IBM Tivoli Workload Scheduler V8.html v IBM Redbooks: Customizing IBM Tivoli Workload Scheduler for z/OS V8.ibm.3 in a distributed environment. administering. when you talk about scheduling.3 will find this book a major reference.redbooks.Publications v IBM Redbooks: Getting Started with IBM Tivoli Workload Scheduler V8. application programming interface.com/abstracts/sg247156. maintaining. you are really talking about an ecosystem. This Redbook can be found on the Redbooks™ Web site at http:// www.3 security. SG24-7156 Abstract: This IBM Redbook describes best practices for using Tivoli Workload Scheduler for z/OS. deployment. Job Scheduling Console enhancements. However. SG24-7237 Abstract: IBM Tivoli Workload Scheduler is an IBM strategic scheduling product that runs on different platforms including the mainframe. troubleshooting. In addition. new advanced planning system. In this ecosystem. IBM DB2 and IBM WebSphere considerations. removal of framework requirements.redbooks. which allows the definition of plans that span more that 24 hours.html v IBM Redbooks: Integrating IBM Tivoli Workload Scheduler with Tivoli Products.

management. You can access the Terminology Web site at the following Web address: http://www. and business systems management provides greater value. This book addresses just some of these many opportunities. help desk.ibm.jsp For all types of information about the WebSphere Application Server. and architects with the knowledge to configure a WebSphere Application Server V6 runtime environment. you can collect and add data to and from each component. This book discusses all these integration points and provides detailed scenarios on how to integrate IBM Tivoli Workload Scheduler with these types of applications.com/tividd/glossary/tivoliglossarymst. In addition. With IBM Tivoli Workload Scheduler. This Redbook can be found on the Redbooks Web site at http:// www.com/abstracts/sg246451. expanding the scheduling ecosystem to include monitoring.ibm.com/software/globalization/terminology xx IBM Tivoli Workload Scheduler: Reference Guide .ibm.boulder. Because workload management is widely considered the nucleus of the data center.com/ infocenter/wasinfo/v6r0/index.redbooks.Publications block that adds value to the overall solution.ibm. do not limit yourself to the products that this book discusses. the entire series is designed to give you in-depth information about the entire range of WebSphere Application Server products.com/abstracts/sg246648. In terms of integration with IBM Tivoli Workload Scheduler. This Redbook can be found on the Redbooks Web site at http:// www.htm The IBM Terminology Web site consolidates the terminology from IBM product libraries in one convenient location. The Tivoli Software Glossary is available at the following Tivoli software library Web site: http://publib. storage. SG24-6451 Abstract: This IBM Redbook provides system administrators.html For all types of information about DB2. we provide a detailed exploration of the WebSphere Application Server V6 runtime environments and administration process.boulder.boulder.html v IBM Redbooks: WebSphere Application Server V6 System Management & Configuration Handbook.redbooks.ibm.com/infocenter/db2luw/v8//index. there are numerous opportunities for you to integrate IBM Tivoli Workload Scheduler with other products.ibm. One in a series of handbooks.jsp Accessing terminology online The Tivoli Software Glossary includes definitions for many of the technical terms related to Tivoli software. go to the WebSphere Application Server Information Center: http://publib. Integration points discussed in this book should give you an idea of the potential value that IBM Tivoli Workload Scheduler integration can provide for your company. In this book. and to perform ongoing management of the WebSphere environment. to package and deploy Web applications. developers. go to the DB2 Information Center: http://publib.

Click to access the Tivoli Workload Scheduler Information Center.tivoli.1. Click the appropriate Tivoli Workload Scheduler product link to access your product libraries at the Tivoli software information center.com/infocenter/tivihelp/v3r1/index. 5.com/infocenter/db2luw/v8//index. If the Information Center does not open automatically. consult the readme.1 is not the same as WebSphere Application Server . Note: If you print PDF publications on other than letter-sized paper.boulder. to the Tivoli software information center Web site. The Information Center is Eclipse-based.ibm. It is a runtime About this guide xxi .Express. Note: The Embedded Version of the WebSphere Application Server version 6. and z/OS library can be found under the entry Tivoli Workload Scheduler. as they become available and whenever they are updated. HTML. or both. The publications are found within a Tivoli Information Center. The Tivoli software information center page for Tivoli Workload Scheduler is displayed.jsp?toc=/ com.xml Access the IBM Tivoli Workload Scheduler Information Center from the Tivoli Technical Product Documents Web site Access the Tivoli software information center by following these steps: 1.boulder. go to the DB2 Information Center: http://publib. It gives you access to the publications relating to the latest version of the product. set the option in the File → Print window that enables Adobe Reader to print letter-sized pages on your local paper. go to the WebSphere® Application Server Information Center: http://publib. IBM posts publications for this and all other Tivoli products. distributed library. All publications in the Tivoli Workload Scheduler suite library.doc/toc.txt file in the root of the CD.itws. Go to the Tivoli library at the following Web address: http://www.jsp.ibm. For all types of information about DB2®.ibm.jsp For all types of information about the Embedded Version of the WebSphere Application Server version 6.boulder. and contains full instructions on how to use it to obtain information and search the publications for specific terms. or you require more information. There are two ways of accessing the Tivoli software information center: Directly access the IBM Tivoli Workload Scheduler Information Center Go directly to the Information Center at the following Web address: http://publib. Place the CD in the CD drive of a Windows computer and the Information Center automatically opens. In the Tivoli Technical Product Documents Alphabetical Listing window.ibm. Links are provided to the documentation of prior versions. Click Tivoli product manuals 3.com/software/tivoli/library/ 2.com/infocenter/wasinfo/v6r1/ index.Publications Accessing publications online The Tivoli Workload Scheduler documentation CD contains the publications that are in the product library. The format of the publications is PDF.ibm. click W (for Workload Scheduler) or scroll down to the W section of the product list 4.

Publications version of WebSphere Application Server. You can read the softcopy books on CD using these IBM licensed programs: v BookManager® READ/2 (program number 5601-454) v BookManager READ/DOS (program number 5601-453) v BookManager READ/6000 (program number 5765-086) All the BookManager programs need a personal computer equipped with a CD drive (capable of reading disks formatted in the ISO 9660 standard) and a matching adapter and cable. The IBM Publications Center page is displayed. refer to the publications for the specific BookManager product you are using. For additional hardware and software information.ibm. Tivoli Workload Scheduler online books All the books in the Tivoli Workload Scheduler for z/OS library are available in displayable softcopy form on CD in the IBM Online Library: z/OS Software Products Collection Kit.1 which is bundled in and managed by Tivoli Workload Scheduler.elink.com/public/applications/ publications/cgibin/ pbi. and IBM cannot guarantee that this URL will continue to be correct.elink. xxii IBM Tivoli Workload Scheduler: Reference Guide . consult the documentation of Oracle Corporation. Note: This information has been included as a courtesy. To locate the telephone number of your local representative perform the following steps: 1. Ordering publications You can order many Tivoli publications online at the following Web site: http://www. the relevant documentation could be found on http://www. When this manual was published.cgi 2.oracle. Using LookAt to find information is faster than a conventional search because in most cases LookAt goes directly to the message explanation.ibm. Click About this site in the main panel to see an information page which includes the telephone number of your local representative. contact your software account representative to order Tivoli publications. version 6.html. Updates to books between releases are provided in softcopy only.com/public/applications/ publications/cgibin/pbi. Using LookAt to look up message explanations LookAt is an online facility that lets you look up explanations for most messages you encounter. as well as for some system abends and codes.cgi You can also order by telephone by calling one of these numbers: v In the United States: 800-879-2755 v In Canada: 800-426-4968 v In other countries. 3.ibmlink. Select your country from the list and click .ibmlink. SK3T-4270. Go to the following Web site: http://www. For all types of information about the Oracle database.com/technology/ documentation/index.

see the Accessibility Appendix in the IBM Tivoli Workload Scheduler Planning and Installation Guide. “Support information. So.Using LookAt You can access LookAt from the Internet at: http://www. and margin graphics.com/eserver/zseries/zos/bkserv/lookat/ or from anywhere in z/OS or z/OS. operating system-dependent commands and paths. or Linux-based handhelds. refer to the following IBM Tivoli Education Web site: http://www. For more information about these three ways of resolving problems.ibm. command syntax. About this guide xxiii .” on page 565. You can also use the keyboard instead of the mouse to operate all features of the graphical user interface. you want to resolve it quickly. For additional information. IBM provides the following ways for you to obtain the support you need: v Searching knowledge bases: You can search across a large collection of known problems and workarounds. Tivoli technical training For Tivoli technical training information.com/software/tivoli/education Support information If you have a problem with your IBM software. Accessibility Accessibility features help users with a physical disability. to use software products successfully. z/OS UNIX® System Services running OMVS). see Appendix D. With this product. Palm OS. such as restricted mobility or limited vision. TSO/E prompt.e where you can access a TSO/E command line (for example. you can now access LookAt message information from almost anywhere. you can use assistive technologies to hear and navigate the interface. Technotes. v Contacting IBM Software Support: If you still cannot solve your problem. and other information. you can use a variety of ways to contact IBM Software Support. if you have a handheld device with wireless access and an Internet browser. The LookAt Web site also features a mobile edition of LookAt for devices such as Pocket PCs. ISPF. and you need to work with someone from IBM.ibm. v Obtaining fixes: You can locate the latest fixes that are already available for your product. Conventions used in this publication This publication uses several conventions for special terms and actions.

Command syntax Syntax Description convention Name of command Brackets ([ ]) The first word or set of consecutive characters. labels (such as Tip:. except where the context or the example path is specifically Windows. Anything not enclosed in brackets must be specified. Example conman [-file definition_file] xxiv IBM Tivoli Workload Scheduler: Reference Guide . For example. replace $variable with % variable% for environment variables and replace each forward slash (/) with a backslash (\) in directory paths. radio buttons. %TEMP% in Windows is equivalent to $tmp in UNIX environments. items inside list boxes. list boxes. property sheets). tabs. Note: If you are using the bash shell on a Windows system. menu choices. folders. fields. and Operating system considerations:) v Keywords and parameters in text Italic v v v v Words defined in text Emphasis of words (words as words) New terms in text (except in a definition list) Variables and values you must provide Monospace v Examples and code examples v File names.Conventions Typeface conventions This publication uses the following typeface conventions: Bold v Lowercase commands and mixed case commands that are otherwise difficult to distinguish from surrounding text v Interface controls (check boxes. programming keywords. push buttons. Command syntax This publication uses the following syntax wherever it describes commands: Table 2. The information enclosed in brackets ([ ]) is optional. menu names. multicolumn lists. you can use the UNIX conventions. icons. When using the Windows command line. spin buttons. and other elements that are difficult to distinguish from surrounding text v Message text and prompts addressed to the user v Text that the user must type v Values for arguments or command options Operating system-dependent variables and paths This publication uses the UNIX convention for specifying environment variables and for directory notation. The names of environment variables are not always the same in Windows and UNIX environments. containers.

file_name1 –x file_name2–x file_name3 [–x file_name. the user would replace file_name with the name of the specific file. This applies to command names and non-variable options. but you cannot enter multiple options in a single use of the command. Command syntax (continued) Syntax Description convention Braces ({ }) Braces ({ }) identify a set of mutually exclusive options.. Vertical bar Mutually exclusive options are (|) separated by a vertical bar ( | ). Bold Bold text designates literal information that must be entered on the command line exactly as shown.) An ellipsis (. Underscore An underscore (_) connects multiple (_) words in a variable. when one option is required.. In the example to the right.... composer add file_name Example {-prompts | -prompt prompt_name } prompt_name {-prompts | -prompt prompt_name } Italic file_name Ellipsis (. You can enter one of the options separated by the vertical bar....) indicates that the [–x file_name].. previous option can be repeated multiple times with different values. About this guide xxv . Italic text is variable and must be replaced by whatever it represents.] An ellipsis inside the brackets indicates that –x file_name is optional. It An ellipsis outside the brackets indicates that –x file_name is optional can be used inside or outside of and may be repeated as follows: –x brackets.. and the file variable can be repeated as follows: –x file_name1 file_name2 file_name3 –x file_name [–x file_name].Conventions Table 2. An ellipsis used with this syntax indicates that you must specify –x file_name at least once.

Conventions xxvi IBM Tivoli Workload Scheduler: Reference Guide .

idle time is minimized and throughput is significantly improved. Standard and fault-tolerant agents can be defined on UNIX and Windows computers. Tivoli Workload Scheduler manages job processing. 2007 1 . For example. each having a domain manager workstation acting as a management hub. Tivoli Workload Scheduler overview IBM Tivoli Workload Scheduler provides you with the ability to manage your production environment and automate many operator activities. resolves interdependencies. Extended agents are logical definitions. For information about workstations. and a store-and-forward technology to maintain consistency and fault-tolerance across the network. each hosted by a physical workstation. CA-7. all the information is stored in the messages file and only sent when the link is reestablished. z/OS. SAP R/3. JES. Because jobs start as soon as their dependencies are satisfied. © Copyright IBM Corp. OPC. The Tivoli Workload Scheduler network consists of one or more domains. and one or more agent workstations. There are three types of agent: standard. This chapter is divided into the following sections: v “Understanding basic concepts” v “Tivoli Workload Scheduler user interfaces” on page 7 v “Starting production” on page 8 Understanding basic concepts This section describes the basic concepts of Tivoli Workload Scheduler and is divided into the following sections: v “What is a Tivoli Workload Scheduler network” v “How you configure your Tivoli Workload Scheduler runtime environment” on page 2 v “How you define scheduling activities using Tivoli Workload Scheduler” on page 2 v “How you manage production scheduling activities with Tivoli Workload Scheduler” on page 5 What is a Tivoli Workload Scheduler network A Tivoli Workload Scheduler network consists of a set of linked workstations on which you perform batch job processing using Tivoli Workload Scheduler management capabilities. Tivoli Workload Scheduler manages the recovery process with little or no operator intervention. and launches and tracks jobs. fault-tolerant. This means that if a workstation is not linked. and VMS but you can also install them on UNIX and Windows systems. Oracle EBS. and are used to perform job processing where an agent is not installed. refer to “Workstation definition” on page 108. 1999. extended agents are available for Peoplesoft. and extended. Workstations communicate using TCP/IP links.Chapter 1. If a job fails.

and to manage user definitions inside the security file. localopts. That user ID can be used to complete the setup procedure. the Security file. the master domain manager is the domain manager of the topmost domain. “Managing the production cycle.What is a Tivoli Workload Scheduler network In the hierarchical Tivoli Workload Scheduler topology. to set properties. to determine your user capabilities. security information is read from a special file. refer to “Security management overview” on page 31. How you configure your Tivoli Workload Scheduler runtime environment This section gives you an high level overview of how you can configure your Tivoli Workload Scheduler runtime environment. A production plan contains all job management activities to be performed across the Tivoli Workload Scheduler network during a specific time frame. and the latter you define locally on the workstation by customizing the configuration files useropts. For more information about Tivoli Workload Scheduler plan management capabilities. The former are managed using the Tivoli Workload Scheduler command line program named optman. How you define scheduling activities using Tivoli Workload Scheduler To perform scheduling activities using Tivoli Workload Scheduler you need to first define the environment you want to manage in terms of scheduling objects and in 2 IBM Tivoli Workload Scheduler: Reference Guide . For more information on how to use the optman command line to manage global options and about local options defined in the localopts file. TWS_user. For more information about the local options defined in the useropts file. refer to “Setting up options for using the user interfaces” on page 29. This file contains one or more user definitions. A user definition is a group of one or more users either who are either allowed or denied to perform specific actions against specific scheduling object types. refer to Chapter 5. or invoke a Tivoli Workload Scheduler command. All production setup tasks and the generation of the production plan are performed on the master domain manager. You can modify the security file at any time to meet your system requirements. Configuring properties You can set two types of properties to configure your Tivoli Workload Scheduler runtime environment. and properties that are set locally on a workstation and affect processing on that workstation only. is defined at installation time in the security file. and jobmanrc.” on page 55. properties that are set on the master domain manager and affect processing on all workstations in the Tivoli Workload Scheduler network. For more information about managing user authorizations. refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide. A copy of the production plan is distributed from the master domain manager to the other workstations. and sends job processing status to the master domain manager. The main Tivoli Workload Scheduler user. On each workstation Tivoli Workload Scheduler launches and tracks its own jobs. Configuring security Each time you run a Tivoli Workload Scheduler program.

resources. Hereafter are described the most commonly used scheduling objects that you can define and some rules that you can apply to them. as well as information about the user who created an object and when an object was last modified. Job streams and run cycles A job streams is a sequences of jobs to be run. refer to IBM Tivoli Workload Scheduler: Database Views. it is used as a variable in job and job stream definitions. v The database views. workstations. You can manage the scheduling object definitions in the database either using the Tivoli Workload Scheduler command-line program named composer or using the graphical user interface. “Getting reports and statistics. priorities. This information is stored by Tivoli Workload Scheduler in a DB2 Relational Data Base. Tivoli Workload Scheduler overview 3 . refer to “Job stream definition” on page 133. Parameters A parameter is a mapping between a name and a value. the database also contains statistics of processed jobs and job streams. and so on. refer to Chapter 11. local or unnamed They are defined on workstations using the utility parms.How you define scheduling activities terms of rules to be applied when scheduling operations to run on these objects. For more information about report utility commands. v The Tivoli Job Scheduling Console. job streams. You can retrieve statistics about processed jobs and job streams in the database using: v The Tivoli Workload Scheduler report utilities from the command line. For more information about the Job Scheduling Console and the Tivoli Dynamic Workload Console. There are two types of parameters: global or named They are defined in the database. or repetition rates. such as jobs. represented by run cycles with type calendars. Jobs can be defined either independently from job streams or within a job stream definition. from now on called the database. and are resolved locally on the workstation when the job or job stream is Chapter 1. For more information. For more information on database views. Each job stream is assigned a time to run. set of dates. and other dependencies that determine the order of processing. refer to “Job definition” on page 119. together with times. refer to the corresponding documentation. In addition to the definitions of scheduling objects. and are replaced with the corresponding values inside the job or job stream definition when the plan is created or extended. Jobs A job is a unit of work specifying an action (such as a weekly data backup) to be performed on specific workstations in the Tivoli Workload Scheduler network. v The Tivoli Dynamic Workload Console. For more information about jobs.” on page 413. the Job Scheduling Console.

refer to “Prompt definition” on page 130 and “prompt” on page 170. refer to “opens” on page 167. 4 IBM Tivoli Workload Scheduler: Reference Guide . and “until” on page 175. dependencies can cross workstation boundaries. for example. by using the keyword until. For a specific run cycle you can specify the time that processing begins. How to control job and job stream processing You can control how jobs and job streams are processed by setting one or more rules from the following: Defining dependencies A dependency is a prerequisite that must be satisfied before processing can proceed.m. which runs on host site1. refer to “needs” on page 160. it only allows jobs and job streams whose priority exceeds the job fence to run on that workstation. You can choose from four different types of dependencies: v On completion of jobs and job streams: a job or a job stream must not begin processing until other jobs and job streams have completed successfully. You can define dependencies for both jobs and job streams to ensure the correct order of processing. Another time setting that can be specified is the schedtime. for example. You can define up to 40 dependencies for a job or job stream. or the time after which processing is no longer started. “every” on page 146.How you define scheduling activities submitted in production or at run time on the target workstation if they the job or job stream was added to the plan when the plan was created or extended. The job fence provides another type of control over job processing on a workstation. In a Tivoli Workload Scheduler network. it indicates the time that is referred to when calculating jobs and job streams dependencies. By specifying both. Both at and until represent time dependencies. v Prompt: a job or a job stream needs to wait for an affirmative response to a prompt before it can begin processing. When it is set to a priority level. For more information. which runs on host site2. For additional information refer to “Parameter definition” on page 128 and to “parms” on page 400 utility command. refer to “follows” on page 150. prevents jobs with priorities of 40 or less from being launched. For more information. v File: a job or a job stream needs to have access to one or more files before it can begin to run. you define a time window within which a job or job stream runs. For more information. Setting the fence to 40. refer to “at” on page 138. For example. “deadline” on page 142. Setting time constrains Time constraints can be specified for both jobs and job streams. you can have Tivoli Workload Scheduler launches the same job every 30 minutes between 8:30 a. “schedtime” on page 171.m. Setting job priority and workstation fence Tivoli Workload Scheduler has its own queuing system. you can make job1. For more information. You can also specify a repetition rate. consisting of levels of priority. and 1:30 p. by using the keyword at. dependent on the successful completion of job2. v Resource: a job or a job stream needs one or more resources available before it can begin to run. For more information. Assigning a priority to jobs and job streams gives you added control over their precedence and order of running.

refer to “Resource definition” on page 132. you can have Tivoli Workload Scheduler automatically run a recovery job. All the required information are written in a file. v Run the failed job again. for example. which is continually Chapter 1. If you have three tape units. In addition. You might want to check the results printed in a report. How you manage production scheduling activities with Tivoli Workload Scheduler Each time a new production plan is generated. for example. The predefined recovery options are: v Continue with the next job. Asking for job confirmation There might be scenarios where the completion status of a job cannot be determined until you have performed some tasks. For more information. Tivoli Workload Scheduler overview 5 . refer to “limit cpu” on page 293. For more information. refer to “Job definition” on page 119. Each resource is represented by a name and a number of available units. However because a resource is not strictly linked to an asset.How to control job and job stream processing For more information. for example. refer to “fence” on page 290 and “priority” on page 169. you can use a mock resource as a dependency to control job processing. you can specify the type of recovery you want performed by Tivoli Workload Scheduler if the job fails. For example. and “limit sched” on page 294. allows Tivoli Workload Scheduler to have no more than 25 jobs running concurrently on that workstation. refer to “confirm” on page 278. In this case. issue a recovery prompt that requires an affirmative response. Defining resources You can define resources to represent physical or logical assets on your system. and Tivoli Workload Scheduler waits for your response before marking the job as successful or failed. and carries forward uncompleted job streams from the previous production plan. Tivoli Workload Scheduler selects the job streams that run in the time window specified for the plan. you can set in the job definition that the job requires confirmation. For more information. v Stop and do not start the next. and then run the failed job again. Defining job recovery actions When you schedule a job. you can define a resource named tapes with three available units. For more information. You can set a limit: v In the job stream definition using the job limit argument v In the workstation definition using the limit cpu command Setting the limit on a workstation to 25. named Symphony. you can specify other actions to be taken in terms of recovery jobs and recovery prompts. Setting limits The limit provides a means of setting the highest number of jobs that Tivoli Workload Scheduler is allowed to launch. if a job fails. A job that uses two units of the tapes resource would then prevent other jobs requiring more than the one remaining unit from being launched.

any of the following actions can be triggered: v Submit a job stream.How you manage production scheduling activities updated while processing to indicate work completed. v Rerun jobs.” on page 89. More information is available on Chapter 6. 6 IBM Tivoli Workload Scheduler: Reference Guide . The objective of event rules is to carry out a predefined set of actions in response to specific events affecting Tivoli Workload Scheduler and non-Tivoli Workload Scheduler objects. or a task v Reply to a prompt v Run non-Tivoli Workload Scheduler commands v Notify users via e-mail v Send messages to Tivoli Enterprise Console You can also define and run event rules that act either on the detection of one or more of these events or on a sequence or set of these events not completing within a specific length of time. v Alter priorities and dependencies. v Submit new jobs and job streams. and work to be done. v Link and unlink workstations in the Tivoli Workload Scheduler network. v Alter the job fence and job limits. the product provides a plug-in that you can use to detect the following events: v A specific job or job stream: – Changes status – Is beyond its latest start time – Is submitted – Is cancelled – Is restarted – Becomes late v A certain workstation: – Changes status – Changes its link status from its parent workstation – Changes its link status from its child workstation v A specific prompt is displayed or replied to v The embedded application server on a certain workstation is started or stopped When any of these events takes place. v Modify the number of available resources. v Display the status of jobs and job streams. With respect to Tivoli Workload Scheduler objects. you can automate workload based on demand with the aid of event rules. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | How to automate workload using event rules Beside doing plan-based job scheduling. v Cancel jobs and job streams. a job. The Tivoli Workload Scheduler conman (Console Manager) command-line program is used to manage the information in the Symphony file. v Reply to prompts. work in progress. “Running event-driven workload automation. The conman command-line program can be used to: v Start and stop Tivoli Workload Scheduler control processes.

This API cannot be used to create your custom interface to set global options. Job Scheduling Console An interactive graphical interface used to create. This interface program and its use are described in Chapter 7. Tivoli Workload Scheduler overview 7 . optman A command-line program used on the master domain manager to manage the settings that affect the entire Tivoli Workload Scheduler environment. Tivoli Dynamic Workload Console A web-based user interface available for viewing and controlling scheduling activities in production on both the Tivoli Workload Scheduler distributed and z/OS environments. modify. “Managing objects in the database .composer.User interfaces Tivoli Workload Scheduler user interfaces A combination of graphical and command-line and API interface programs are provided to work with Tivoli Workload Scheduler.html.conman.” on page 105 and Chapter 8. conman A command-line program used to monitor and control the Tivoli Workload Scheduler production plan processing. the command-line interface is available for certain advanced features which are not available in the graphical user interface.” on page 189. Mount the CD for your platform and open the following file with your Internet browser: CD_drive/API/doc/ index. With the Tivoli Dynamic Workload Console you can use any supported browser to access the Tivoli Workload Scheduler environment from any location in your network. and delete objects in the product database and in the plan. This interface is described in the IBM Tivoli Workload Scheduler Job Scheduling Console: User’s Guide. | | | | | | | | | | | | | | | | | | | | | | | | | | | Java API A set of available classes and methods running in a JAVA environment that you use to create your custom interface to manage scheduling objects in the database and in the plan. Click on the Help topic in the page header to learn more about how the documentation is structured. Documentation for the API is provided on all product CDs. See the Tivoli Dynamic Workload Console Installation and Troubleshooting guide for information. “Defining objects in the database. Chapter 1. You can use the Tivoli Dynamic Workload Console to: v Browse and manage scheduling objects involved in current plan activities v Create and control connections to Tivoli Workload Scheduler environments v Submit jobs and job streams in production v Set user preferences v Create and manage event rules Tivoli Dynamic Workload Console must reside on a server that can reach the Tivoli Workload Scheduler nodes using network connections. This interface program is described in Chapter 9. The available Tivoli Workload Scheduler user interface programs are: composer A command-line program used to define and manage scheduling objects in the database. In particular. “Managing objects in the plan .” on page 243.

csh for C shells in UNIX TWS_home\tws_env. For information on how to set the options needed to allow a user to access the command-line interfaces. This interface program is described in the Tivoli Workload Scheduler Planning and Installation Guide. For more information refer to Appendix B. Refer to the corresponding product documentation for more information. You might start. with two or three of your most frequent applications. planman A command-line program used to manage the Tivoli Workload Scheduler planning capability. If you are not familiar with Tivoli Workload Scheduler you can follow the non-optional steps to define a limited number of scheduling objects. You must install the Tivoli Workload Scheduler Command Line Client feature on fault-tolerant agents and systems outside the Tivoli Workload Scheduler network to use the composer and optman command-line programs and to run planman showinfo and planman unlock commands. refer to “Setting up options for using the user interfaces” on page 29. The first activity you must perform is to access the Tivoli Workload Scheduler database and to define the environment where you want to perform your scheduling activities using the Tivoli Workload Scheduler scheduling object types.” on page 545. to set global options./TWS_home/tws_env. Starting production This section provides you with a step-by-step path of basic operations you can perform quickly implement Tivoli Workload Scheduler in your environment using the command-line interface. to manage objects in the database.User interfaces These settings. This interface program is described in “Planman command line” on page 72. defining scheduling objects to meet their requirements only. “Web services interface. It is assumed that: v These steps are performed on the master domain manager immediately after successfully installing the product on the systems where you want to perform your scheduling activities. It does not allow you to manage the plan. v The user ID used to perform the operations is the same as the one used for installing the product. are stored in the database.sh for Bourne and Korn shells in UNIX . you can use the Job Scheduling Console or the Tivoli Dynamic Workload Console to perform the same tasks.cmd in Windows 8 IBM Tivoli Workload Scheduler: Reference Guide . Web Services Interface An interface that provides you with a Web Services based access mechanism to a subset of functionality used to manage jobs and job streams in the plan. for example. and add more as you become familiar with the product./TWS_home/tws_env. . To do this perform the following steps: 1. Alternatively. also called global options. . Set up the Tivoli Workload Scheduler environment variables Run one of the following scripts: .

Optionally add in the database the definitions to describe the topology of your scheduling environment in terms of: v Domains Use this step if you want to create a hierarchical tree of the path through the environment. For additional information. You can use them to include or exclude days and times for processing.Starting production in a system shell to set the PATH and TWS_TISDIR variables. Optionally define jobs and job streams For additional information refer to “Job definition” on page 119. and resources For additional information refer to “Parameter definition” on page 128. They can be: v Resource dependencies v File dependencies v Job and job stream follow dependencies v Prompt dependencies You can define time settings for jobs and job streams to run in terms of: Chapter 1. refer to “Domain definition” on page 117. 2. Note: If you want to perform this step and the following ones from a system other than the master domain manager you must specify the connection parameters when starting composer as described in “Setting up options for using the user interfaces” on page 29. For additional information. 3. v Workstations Define a workstation for each machine belonging to your scheduling environment with the exception of the master domain manager which is automatically defined during the Tivoli Workload Scheduler installation. There can be up to 40 dependencies for a job stream. You can define dependencies for jobs and job streams. Using multiple domains decreases the network traffic by reducing the communications between the master domain manager and the other workstations. 8. Optionally define parameters. The master domain manager is automatically defined in the database at installation time. Optionally define calendars Calendars allow you to determine if and when a job or a job stream has to run. prompts. 6. For additional information refer to “Calendar definition” on page 127. Optionally define restrictions and settings to control when jobs and job streams run. and “Resource definition” on page 132. refer to “Windows user definition” on page 125. Optionally define the users allowed to run jobs on Windows workstations Define any user allowed to run jobs using Tivoli Workload Scheduler by specifying user name and password. 4. 5. Connect to the Tivoli Workload Scheduler database You can use the following syntax to connect to the master domain manager as TWS_user: composer -user <TWS_user> -password <TWS_user_password> where TWS_user is the user ID you specified at installation time. 7. Tivoli Workload Scheduler overview 9 . and to “Job stream definition” on page 133. refer to “Workstation definition” on page 108. For additional information. “Prompt definition” on page 130.

conman. you only need to run the JnextPlan command the first time. see the section “limit cpu” on page 293 for more details.” on page 243 for more details about the conman program and the operations you can perform on the production plan in process. Consider however that these modifications will only be used if you submit the modified jobs or job streams. so make sure that you increase this value by changing the limit cpu to allow job execution on that workstation. the number of jobs that can run simultaneously on a workstation is zero. By default. on a workstation which has already received the plan. While the production plan is processing across the network you can still continue to define or modify jobs and job streams in the database. “Managing objects in the plan . See Chapter 9. refer to “Automating production plan processing” on page 87. If you want to modify anything while the production plan is already in process. 10 IBM Tivoli Workload Scheduler: Reference Guide . with batch processing of an ordered sequence of jobs and job streams being performed against resources defined on a set of workstations. if defined. use the conman program. When you complete this step-by-step process. your scheduling environment is up and running. Generate the plan Run the JnextPlan command to generate the production plan. If you automated the plan generation as described in the previous step. 10. or after a new production plan is generated using JnextPlan.Starting production v Run cycles v Time constraints You can tailor the way jobs run concurrently either on a workstation or within a job stream by setting: v Limit v Priority 9. Automate the plan extension at the end of the current production plan processing Add the final job stream to the database to perform automatic production plan extension at the end of each current production plan processing by running the following command: add Sfinal For additional information. This command starts the processing of the scheduling information stored in the database and creates the production plan for the time frame specified in the JnextPlan command. The default time frame is 24 hours. using the command sbj for jobs or sbs for job streams. the first time you run the JnextPlan command.

For information on how to start and stop both WebSphere Application Server infrastructure and Tivoli Workload Scheduler processes on a workstation refer to “Starting and stopping processes on a workstation” on page 16. containing the records describing the job processing activities to be performed across Tivoli Workload Scheduler network during the current production plan. The master domain manager then updates its copy of the Symphony file.Chapter 2. The enhancement involves the addition of the following workstation processes: v The appserverman process is in charge of starting and stopping the embedded Websphere application server. locally on each workstation a group of specialized scheduling processes performs job management and sends back the information about job processing throughout the hierarchical tree until the master domain manager is reached. such as command-line programs. This chapter describes both the job processing performed at each workstation and the network communication established across the hierarchical tree. v Manage authentication mechanisms for remote clients. Tivoli Workload Scheduler workstation processes The management of communication between workstations and local job processing together with update state notification is performed on each Tivoli Workload Scheduler workstation by a series of management processes active while the engine is running. It is divided into the following sections: v “What is new about workstation processes” v “Tivoli Workload Scheduler workstation processes” v “Starting and stopping processes on a workstation” on page 16 v “Workstation inter-process communication” on page 17 v “Tivoli Workload Scheduler network communication” on page 18 | | | | | | | | What is new about workstation processes This section gives you a quick reference to the enhancements about workstation processes included in Tivoli Workload Scheduler version 8. connecting to the master domain manager using HTTP or HTTPS protocol. On fault-tolerant agents and domain managers these processes are based on a WebSphere Application Server infrastructure. with the information received from the workstations and sends the updates on the activities to be performed to the workstations involved. v The monman process is in charge of running monitoring services to detect locally events defined in event rules. 2007 11 . 1999. the WebSphere Application Server infrastructure is transparent when using Tivoli Workload Scheduler. Out of starting and stopping of processes on a workstation and managing connection parameters when communicating across the Tivoli Workload Scheduler network. This infrastructure is automatically installed with the workstation and allows Tivoli Workload Scheduler to: v Communicate across the Tivoli Workload Scheduler network. © Copyright IBM Corp.4. Understanding workstation processes In a multi-tier Tivoli Workload Scheduler network.

It interacts directly with the 12 IBM Tivoli Workload Scheduler: Reference Guide . It routes messages to either local or remote workstations. For additional information. If no event rule configurations are downloaded to the workstation. after a preliminary filtering action. Netman examines each request received and spawns a local Tivoli Workload Scheduler process. 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. mailman Mailman is the Mail Management process. When the domain manager starts up. link. in the following order: netman Netman is the Network Management process. On a domain manager. 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. refer to “Workstation definition” on page 108. or unlink requests from the network. | | | | | | | | | | | | | | | | | monman Monman is a process started by netman and used in event management. The communication process between the monitoring agents and the event processing server is independent of the Tivoli Workload Scheduler network topology.Workstation processes In this guide Tivoli Workload Scheduler processes or workstation processes are used to identify the following processes: | | | | | | netman monman writer mailman batchman jobman These processes are started on a workstation. 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. It is started by the Startup command and it behaves like a network listener program which receives start. 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. A degree of fault-tolerance is guaranteed by local cash memories that temporarily store the event occurrences on the agents in case communication with the event processor is down. batchman Batchman is the Production Control process. the monitoring services stay idle. writer Writer is a process started by netman to pass incoming messages to the local mailman process. When these services catch any such events. Each workstation is contacted by its own ServerID on the domain manager. stop. they send them to the event processing server that runs usually in the master domain manager. The writer processes (there might be more than one on a domain manager workstation) are started by link requests (see “link” on page 295) and are stopped by unlink requests (see “unlink” on page 370) or when the communicating mailman ends. that is not a standard agent workstation.

if it exists in the home directory of the user launching the job. it spawns a job monitor process. see Chapter 3. v Updates the plan with the job processing results Batchman is the only process that can update the Symphony file. For information about these scripts. the batchman process is not launched because this type of workstation does not manage job scheduling. Jobman runs as root.jobmanrc is launched. When the jobman process receives a launch job message from batchman. JOBMON. For additional information on standard agent workstations refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide. Understanding workstation processes 13 . Locally on the workstation the management processes wait for a request to launch a job from the domain manager in LISTEN mode. run as the TWS_user. v Resolves dependencies of jobs and job streams. job monitor (jobman on UNIX. Batchman performs several functions: v Manages locally plan processing and updating. refer to “Job definition” on page 119. It launches jobs under the direction of batchman and reports job status back to mailman.exe on Windows operating system) The job monitor process first performs a set of actions to set the environment before the job is launched. These workstations only launch jobs under the direction of their domain manager. “Configuring the job environment. jobman Jobman is the Job Management process. | | | | | | | | The setup activities consist of launching the standard configuration file (TWS_home/jobmanrc in UNIX and TWS_home/jobmanrc.jobmanrc when requesting to launch jobs. the job ends in the FAIL state. It is responsible for tracking job state and for setting the environment as defined in scripts jobmanrc and . Chapter 2.exe and joblnch. on UNIX workstations a local configuration script TWS_user/. In addition. except jobman. For additional details on how to specify the script file or the command launched with the job. When the request is received the job is launched locally and the result is sent back to the domain manager.” on page 21.Workstation processes copy of the Symphony file distributed to the workstations at the beginning of the production period and updates it.cmd in Windows) which contains settings that apply to all jobs running on the workstation. and then launches the job by running the script file or command specified in the job definition. 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 (see “limit cpu” on page 293). If any of these steps fail. v Selects jobs to be run. On standard agent workstations. This local configuration file contains settings that apply only to jobs launched by the specific user. All processes.

jobmanrc . installed on a UNIX operating system: netman monman batchman writer ssmagent mailman serverA (mailman) jobman job monitor (jobman) job monitor (jobman) job monitor (jobman) jobmanrc jobmanrc jobmanrc . other than a standard agent workstation.jobmanrc . Process tree in UNIX job file job file 14 IBM Tivoli Workload Scheduler: Reference Guide .jobmanrc job file Figure 1.Workstation processes Figure 1 shows the processes tree on an workstation.

exe jobmanrc.exe joblnch.Workstation processes Figure 2 shows the processes tree on a workstation.exe serverA (mailman.cmd jobmanrc. other than a standard agent workstation.exe monman.exe joblnch.exe batchman.exe mailman. Process tree in Windows job file job file Chapter 2. installed on a Windows operating system: netman.exe jobmon.exe) jobman.exe ssmagent.cmd jobmanrc.cmd job file Figure 2.exe writer. Understanding workstation processes 15 .exe joblnch.

Starting and stopping Tivoli Workload Scheduler on a workstation Action Commands used on UNIX platform Commands used on Windows platform conman start conman startappserver conman startmon Start all Tivoli Workload conman start Scheduler processes including conman startappserver WebSphere Application Server conman startmon and the event monitoring engine./stopWas. Starting and stopping processes on a workstation How processes are started on a workstation from the Tivoli Workload Scheduler command line depends on the operating system installed. Stop all Tivoli Workload Scheduler processes with the exception of Websphere Application Server.sh or conman stopappserver conman startmon conman stopmon Refer to “StartUp” on page 409 for more information on the StartUp utility command. the Tivoli Token Service./startWas. Start WebSphere Application Server Stop WebSphere Application Server Start the event monitoring engine Stop the event monitoring engine conman shutdown conman shutdown -appsrv shutdown -appsrv conman shutdown shutdown conman start conman start conman stop conman stop conman shutdown conman shutdown shutdown startWas or conman startappserver stopWas or conman stopappserver conman startmon conman stopmon . 16 IBM Tivoli Workload Scheduler: Reference Guide . On Windows starts also the Tivoli Token Service . Start all Tivoli Workload Scheduler processes with the exception of Websphere Application Server and the event monitoring engine. Start netman and Websphere Application Server. Stop all Tivoli Workload Scheduler processes (including netman).sh StartUp Stop all Tivoli Workload conman shutdown Scheduler processes and .Workstation processes On Windows operating systems there is an additional service.sh or conman startappserver . which enable Tivoli Workload Scheduler processes to be launched as if they were issued by the Tivoli Workload Scheduler user. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 3.sh Websphere Application Server./stopWas. Table 3 explains how you can start and stop both the WebSphere Application Serverinfrastructure and Tivoli Workload Scheduler processes on a workstation based on the operating system installed. Stop all Tivoli Workload Scheduler processes but netman./StartUp.

msg This message file is written by the batchman process and read by the jobman process. WebSphere Application Server and the netman processes can be automatically started at start time by adding a statement invoking Startup in the /etc/inittab file. WebSphere Application Server and the netman processes are automatically started at start time as services together with the Tivoli Token Service. and UNLINK. Refer to “shutdown” on page 341 for more information on the conman shutdown command. Refer to “startmon” on page 347 for more information on the conman startmon command. | | | | | | | | | | | | | | Refer to “startappserver” on page 345 for more information on the conman startappserver command. Refer to “start” on page 342 for more information on the conman start command. Workstation inter-process communication Tivoli Workload Scheduler uses message queues for local inter-process communication. Courier.msg This message file is read by the batchman process and contains instructions sent by the local mailman process. STOP. If the agent is installed on a UNIX system.msg This message file is read by the mailman process. Intercom.msg This message file is read by the netman process for local commands. Refer to IBM Tivoli Workload Manager: Planning and installation guide for more information on startWas and stopWas commands. which reside in the TWS_home directory: NetReq. It receives messages such as START.Starting and stopping processes Refer to “shutdown” on page 408 for more information on the shutdown utility command. Mailbox. If the agent is installed on a Windows system. from both the Job Scheduling Console and the console manager conman. and from other Tivoli Workload Scheduler workstations in the network. It receives messages from the local batchman and jobman processes. Refer to “stop” on page 349 for more information on the conman stop command. Refer to “stopmon” on page 354 for more information on the conman stopmon command. Refer to “stopappserver” on page 352 for more information on the conman stopappserver command. Understanding workstation processes 17 . Chapter 2. LINK. There are four message files.

When the TCP/IP communication is established between systems. When a link is closed. Links are controlled by the autolink flag set in the “Workstation definition” on page 108. The node name and the port number used to establish the TCP/IP connection are set for each workstation in its workstation definition. start or shutdown NetReq. the sending workstation stores messages in a local message file and sends them to the destination workstation as soon as the link is re-opened. A store-and-forward technology is used by Tivoli Workload Scheduler to maintain consistency and fault tolerance across the network at all times by queuing messages in message files while the connection is not active. Tivoli Workload Scheduler network communication Tivoli Workload Scheduler uses the TCP/IP protocol for network communications. and by the “link” on page 295 and “unlink” on page 370 commands issued from the conman command-line program. There are basically two types of communication that take place in the Tivoli Workload Scheduler environment. When a link is opened. The maximum size can be changed using the evtsize utility (see “evtsize” on page 388). Inter-process communication These files have a default maximum size of 10MB. connection initialization and scheduling event 18 IBM Tivoli Workload Scheduler: Reference Guide .msg batchman Courier.msg jobman Figure 3.msg mailman Intercom. messages are passed between two workstations.Workstation inter-process communication Operator input conman stop. refer to “Workstation definition” on page 108 for additional details.msg netman writer netman spawns writer for each incoming connection From remote mailman To remote mailman JSC or conman Mailbox. Tivoli Workload Scheduler provides bi-directional communications between workstations using links.

This step is necessary for the domain manager to check if the current plan has already been sent to the FTA. These two types of communication are now explained in detail. The mailman process on the domain manager compares its Symphony file run number with the run number of the Symphony file 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. TCP/IP address.msg file on the domain manager. the writer process on the domain manager writes messages received from the FTA to the Mailbox. and spawns a new writer process to handle incoming connection. 9. and the writer process on the FTA writes messages from the domain manager to the Mailbox. On the domain managers the mailman process reads the host name. the mailman process on the domain manager sends to the writer process on the FTA the latest copy of the Symphony file. If the run numbers are different. The netman process on the domain manager determines that the request is coming from the mailman process on the FTA. Job processing and scheduling event delivery in the form of change of state messages during the processing day performed locally by the FTA During the production period. This run number is the identifier used by Tivoli Workload Scheduler to recognize each Symphony file generated by JnextPlan. The mailman process on the FTA reads the host name. 2. and spawns a new writer process to handle the incoming connection. 4. As a result of this. 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. These are the steps that are performed locally on the FTA to read and update the Symphony file and to process jobs: Chapter 2. 7. The netman process on the FTA starts the local mailman process. 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.msg file on the FTA. Understanding workstation processes 19 . 8. When the current Symphony file is in place on the FTA. 6. At this point a one-way communication link is established from the domain manager to the FTA. 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. The netman process on the FTA determines that the request is coming from the mailman process on the domain manager. 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. the mailman process on the domain manager sends a start command to the FTA. 3. 5. TCP/IP address. The mailman process on the domain manager is now connected to the writer process on the FTA. and port number of the FTA from the Symphony file.Network communication delivery in the form of change of state messages during the processing 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.

The getaddrinfo function handles both name-to-address and service-to-port translation. 6.msg file. When job job1 completes processing. The mailman process reads this information in its Mailbox.msg file.msg file on the domain manager and the local Intercom. The jobman process reads this information in the Courier. which is where they belong.msg file on the domain manager and the local Intercom.Network communication 1. starts job1. In other terms. the jobman process updates the Mailbox.msg file on the FTA.msg file on the FTA. 7. and sends a message that job1 started with its process_id and timestamp. They are replaced by the new getaddrinfo API that makes the client-server mechanism entirely protocol independent. The batchman process reads a record in the Symphony file that says that job1 is to be launched on the workstation.msg file and updates the local copy of the Symphony file.msg file that job1 started with its process_id and timestamp.msg file. In this way. the gethostbyname and the gethostbyaddr functions were dropped from Tivoli Workload Scheduler as they exclusively support IPv4.msg file with the information that says that job1 completed. 20 IBM Tivoli Workload Scheduler: Reference Guide . The mailman process reads the information in the Mailbox. For information on how to tune job processing on a workstation. Tivoli Workload Scheduler provides IP dual-stack support. The batchman process on the FTA reads the message in the Intercom. 4. to both the Mailbox. and determines the next job that has to be run. and returns sockaddr structures instead of a list of addresses These sockaddr structures can then be used by the socket functions directly. 5.msg file. To this end. 3. 8. getaddrinfo hides all the protocol dependencies in the library function.msg file that job1 has to start. refer to the IBM Tivoli Workload Scheduler: Administration and Troubleshooting Guide. the product is designed to communicate using both IPv4 and IPv6 addresses simultaneously with other applications using IPv4 or IPv6. The batchman process on the FTA reads the message in the Intercom. 2. The application deals only with the socket address structures that are filled in by getaddrinfo. To assist customers in staging the transition from an IPv4 environment to a complete IPv6 environment. updates the local copy of the Symphony file. | | | | | | | | | | | | | | | | | Support for Internet Protocol version 6 Tivoli Workload Scheduler supports Internet Protocol version 6 (IPv6) in addition to the legacy IPv4. and sends a message that job1 completed to both the Mailbox. and writes in the Mailbox. The batchman process writes in the Courier.

profile. 2007 21 . and then runs a standard configuration script named TWS_home/jobmanrc which can be customized. retain the user name recorded with the logon of the job. This customization is made by assigning locally on each workstation values to variables that have an impact on jobman processing.Chapter 3. In case it does. jobs are launched by the production control process batchman. Each of the processes launched by jobman. in turn. if the user is allowed to use a local configuration script. add in the . and the script USER_HOME/. © Copyright IBM Corp. On UNIX workstations. and then queues a job launch message to the jobman process. To have jobs run with the user’s environment. including the configuration scripts and the jobs. 1999.jobmanrc exists.jobmanrc is also run.profile in the .. they retain the submitting user’s name. This chapter is divided into the following sections: v “Job environment overview” v “Environment variables exported by jobman” on page 22 v “Customizing jobs processing on the workstation . The jobman process starts a job monitor process that begins by setting a group of environment variables. The job is then run either by the standard configuration script.jobmanrc” on page 25 v “Customizing job processing for a user on UNIX workstations . Configuring the job environment This chapter describes how to customize the way job management is performed on a workstation.jobmanrc” on page 27 Job environment overview On each workstation. $USER_home/.jobmanrc file make sure that it does not contain any stty setting or any step that requires an user manual intervention. add the following instruction in the local configuration script: . In case of submitted jobs. or by the local one. The results of job processing are reported to jobman which.profile Note: Before adding the . The batchman process resolves all job dependencies to ensure the correct order of job processing. updates the Mailbox.msg file with the information on job completion status. regardless of the user. The jobmanrc script sets variable that are used to configure locally on the workstation the way jobs are launched.jobmanrc file only the necessary steps contained in the . the local configuration script .

its value is set to C. The absolute job identifier: worktation#sched_id. The value of the TEMP set in the user environment. if it was set in the operating system environment. The value of the HOMEPATH set in the user environment. Job environment variables for Windows Variable Name COMPUTERNAME HOMEDRIVE HOMEPATH LANG LOGNAME MAESTRO_OUTPUT_STYLE SystemDrive SystemRoot TEMP TIVOLI_JOB_DATE TMPTEMP TMPDIR Value The value of the COMPUTERNAME set in the user environment. The scheduled date for a job. If not specified. The setting for output style for long object names. The job number (parent process identifier. If not specified. The login user’s name. TZ UNISON_CPU UNISON_DIR UNISON_EXEC_PATH UNISONHOME UNISON_HOST | | UNISON_JOB UNISON_JOBNUM UNISON_MASTER UNISON_RUN UNISON_SCHED UNISON_SCHED_DATE 22 IBM Tivoli Workload Scheduler: Reference Guide . its value is set to c:\temp. The name of the host CPU. its value is set to c:\temp. The value of the HOMEDRIVE set in the user environment. The value of the TMP set in the user environment. The job stream name. The value of the UNISONHOME set in the user environment. The Tivoli Workload Scheduler current production run number. ppid). its value is set to c:\temp. The value of the SYSTEMROOT set in the user environment. The value of the UNISON_DIR set in the user environment. The value of the SYSTEMDRIVE set in the user environment. The name of the master workstation. The Tivoli Workload Scheduler’s production date (yymmdd) reported in the header of the Symphony file. If not specified. The jobmanrc fully qualified path. If not specified. The value of the LANG set in the user environment. its value is set to the home directory of the user running the job. The value of the TMPDIR set in the user environment.job. The time zone. The name of this workstation.Environment variables exported by jobman Environment variables exported by jobman The variables listed in Table 4 are set locally on the workstation and exported by jobman on Windows operating systems: Table 4. If not set.

If not specified. The value of the USERDOMAIN set in the user environment. The value of the UNISON_DIR set in the user environment. The value of the USERNAME set in the user environment. The value of the TWS_TISDIR set in the user environment.Environment variables exported by jobman Table 4. /bin:/usr/bin The scheduled date for a job.jobmanrc fully qualified path. The time zone set. Job environment variables for Windows (continued) Variable Name UNISON_SCHED_ID UNISON_SCHED_IA UNISON_SCHED_EPOCH UNISON_SHELL UNISON_STDLIST UNISON_SYM USERDOMAIN USERNAME USERPROFILE Value The jobstreamID of the job stream containing the job in process. Configuring the job environment 23 . Job environment variables for UNIX Variable Name HOME LANG LD_LIBRARY_PATH LD_RUN_PATH LOGNAME MAESTRO_OUTPUT_STYLE PATH TIVOLI_JOB_DATE TWS_TISDIR TZ UNISON_CPU UNISON_DIR UNISON_EXEC_PATH UNISONHOME Value The home directory of the user. its value is set to the home directory of the user. The setting for output style for long object names. The Symphony record number of the launched job. The name of this workstation. The name of the master workstation. UNISON_HOST Chapter 3. The login shell of the user running the job. The value of the LD_RUN_PATH set in the user environment. The StartTime of the job stream containing the job in process. The Tivoli Workload Scheduler’s production date expressed in epoch form. The variables listed in Table 5 are set locally on the workstation and exported by jobman on UNIX operating systems: Table 5. The value of the LD_LIBRARY_PATH set in the user environment. The path name of the standard list file of the job. The value of the USERPROFILE set in the user environment. The value of the LANG set in the user environment. The . The login user name. The value of the UNISONHOME set in the user environment.

This variable can be set on both UNIX and Windows workstations and must be set before starting Tivoli Workload Scheduler processes on that workstation to become effective. The Symphony record number. 2. To set this variable follow these steps: On UNIX workstations 1.job.profile file. The job number (parent process identifier. 2. Run the . The job stream name.profile file. The Tivoli Workload Scheduler’s production date. | | UNISON_JOB UNISON_JOBNUM UNISON_MASTER UNISON_RUN UNISON_SCHED UNISON_SCHED_DATE UNISON_SCHED_EPOCH UNISON_SHELL UNISON_STDLIST UNISON_SYM Customizing date formatting in the stdlist You can use an environment variable named UNISON_DATE_FORMAT to specify the date format that is used for the date in the header and in the footer of the stdlist file. These are some examples of the settings used to display the year format in the date field in the header and footer of the stdlist file. The Tivoli Workload Scheduler’s current production run number. 3. ppid). The path name of the standard list file of the job. Add the statement to export the UNISON_DATE_FORMAT variable in the root . Job environment variables for UNIX (continued) Variable Name Value The absolute job identifier: worktation#sched_id.sh. From the System Properties set the UNISON_DATE_FORMAT in the System Variable. The setting: UNISON_DATE_FORMAT = "%a %x %X %Z %Y" produces an output with the following format: Fri 15/10/04 11:05:24 AM GMT 2004 The setting: UNISON_DATE_FORMAT = "%a %x %X %Z" produces an output with the following format: Fri 15/10/04 11:05:24 AM GMT 24 IBM Tivoli Workload Scheduler: Reference Guide . Run conman shutdown and then StartUp.Environment variables exported by jobman Table 5. Run conman shutdown and then StartUp. The Tivoli Workload Scheduler’s production date (yymmdd). On Windows workstations 1. The login shell of the user. The name of the master workstation. expressed in epoch form.

To alter the script. the job ends immediately if any command returns a nonzero exit code. the presence of a local configuration script is ignored. If set to no. Customizing jobs processing on the workstation . make your modifications in the working copy (TWS_home/jobmanrc). This script can be used by the system administrator to set the desired environment before each job is run. If set to no. Table 6 describes the jobmanrc variables. Chapter 3.jobmanrc” on page 27 for more information. the standard 2-digit format is used.jsp?name=strftime§=3 to see the available settings that can be assigned to the UNISON_DATE_FORMAT variable. LOCAL_RC_OK yes | no If set to yes. If omitted. The path name of the job’s standard list file. leaving the template file unchanged. The user might be allowed or denied this option.Customizing date formatting in the stdlist Set this variable locally on every workstation for which you want to display the 4-digit year format. passing $UNISON_JCL as the first argument. and $UNISON_JCL is run. and comments to help you understand the methodology. It is installed automatically as TWS_home/jobmanrc. Any other setting is interpreted as no.com. the job continues to run if a command returns a nonzero exit code. Table 6.hk/PenguinWeb/manpage. the user’s local configuration script is run (if it exists). Variables defined by default in the jobmanrc file Variable Name UNISON_JCL UNISON_STDLIST UNISON_EXIT Value The path name of the job’s script file. Configuring the job environment 25 . You can refer to the following link: http://linux. yes | no If set to yes. See “Customizing job processing for a user on UNIX workstations .. The file contains variables which can be configured. Any other setting is interpreted as no.jobmanrc A standard configuration script template named TWS_home/config/jobmanrc is supplied with Tivoli Workload Scheduler.

For an explanation of how to do this. If the first line does not start with #!. ″root mis sam mary″. no messages are mailed if the job abends. see “Customizing the MAIL_ON_ABEND section of jobmanrc. Commands are echoed to the job’s standard list file. If set to no. Abend messages have the following format: cpu#sched. This can also be set to one or more user names. the local configuration script or $UNISON_JCL is run directly. Customizing the MAIL_ON_ABEND section of jobmanrc You can modify the wording used in the message sent to the users specified in the MAIL_ON_ABEND field of the TWS_home/jobmanrc configuration file by accessing that file and changing the wording in the parts highlighted in bold: 26 IBM Tivoli Workload Scheduler: Reference Guide . in which case the job or local configuration script is run by another shell process. the first line of the JCL file is read to determine which shell to use to run the job. USE_EXEC yes | no If set to yes. Variables defined by default in the jobmanrc file (continued) Variable Name MAIL_ON_ABEND Value yes | no For UNIX operating systems: If set to yes. and commands are not echoed unless the local configuration script or $UNISON_JCL contains a set -x command. or the user’s local configuration script is run using the exec command.jobmanrc Table 6. For example. the job. Commands are echoed to the job’s standard list file.job jcl-file failed with exit-code Please review standard-list-filename You can change the wording of the message or translate the message into a another language. a message is mailed to the login user’s mailbox if the job ends with a non zero exit code. If set to user. separated by spaces so that a message is mailed to each user.” SHELL_TYPE standard | user | script If set to standard. If set to script. Any other setting is interpreted as no. the local configuration script or $UNISON_JCL is run by the user’s login shell ($UNISON_SHELL). This option is overridden if MAIL_ON_ABEND is also set to yes. thus eliminating an extra process. Any other setting is interpreted as standard. then /bin/sh is used to run the local configuration script or $UNISON_JCL.

the local configuration script .jobmanrc permits users to establish a desired environment when processing their own jobs. The . Chapter 3. and it has execute permission.jobmanrc: v Use eval if you want to launch a command.jobmanrc script is an extra step that occurs before the job is actually launched. the command or script is launched differently.jobmanrc).deny. Depending on the type of process activity you want to perform. the user’s name must appear in the file.jobmanrc script to perform pre. If neither of these files exists.jobmanrc. TWS_home/localrc. Unlike the jobmanrc script. jobmanrc. Each user defined as tws_user can customize in the home directory the . the user’s name must not appear in the file.jobmanrc On UNIX workstations.allow exists. is installed.allow file does not exist.Customizing the MAIL_ON_ABEND # Mail a message to user or to root if the job fails.and post-processing actions. the user is permitted to use a local configuration script. the . and the environment variable LOCAL_RC_OK is set to yes (see Table 6).jobmanrc script runs only under the following conditions: v The standard configuration script. Jobs are not automatically run. Follow these general rules when launching scripts from inside .jobmanrc script can be customized to perform different actions for different users. the command or script must be launched from inside the . If the TWS_home/localrc. The . if [ "$MAIL_ON_ABEND" = "YES" ] then if [ $UNISON_RETURN -ne 0 ] then mail $LOGNAME <<-! $UNISON_JOB \’$UNISON_JCL\’ failed with $UNISON_RETURN Please review $UNISON_STDLIST ! fi elif [ "$MAIL_ON_ABEND" = "ROOT" ] then if [ $UNISON_RETURN -ne 0 ] then mail root <<-! $UNISON_JOB \’$UNISON_JCL\’ failed with $UNISON_RETURN Please review $UNISON_STDLIST ! fi elif [ "$MAIL_ON_ABEND" != "NO" ] then if [ $UNISON_RETURN -ne 0 ] then mail $MAIL_ON_ABEND <<-! $UNISON_JOB \’$UNISON_JCL\’ failed with $UNISON_RETURN Please review $UNISON_STDLIST ! fi fi Customizing job processing for a user on UNIX workstations . v The local configuration script is installed in the user’s home directory (USER_home/. Configuring the job environment 27 . v If the file TWS_home/localrc.

jobmanrc that does processing based on the exit code of the user’s job: #!/bin/sh # PATH=TWS_home:TWS_home/bin:$PATH export PATH /bin/sh -c "$UNISON_JCL" #or use eval "$UNISON_JCL" and the quotes are required RETVAL=$? if [ $RETVAL -eq 1 ] then echo "Exit code 1 . Please page the admin" fi 28 IBM Tivoli Workload Scheduler: Reference Guide . variables that are defined. otherwise it is null. or command. v EXECIT is set to exec if the variable USE_EXEC is set to yes (see Table 6 on page 25). however. run the job’s script file ($UNISON_JCL).Non Fatal Error" exit 0 elif [ $RETVAL -gt 1 -a $RETVAL -lt 100 ] then conman "tellop This is a database error . The following example shows how to run a job’s script file. Tivoli Workload Scheduler provides you with a standard configuration script. All the variables exported into jobmanrc are available in the . v Use eval if you want to launch a script that requires post processing activities..jobmanrc shell. v IS_COMMAND is set to yes if the job was scheduled or submitted in production using submit docommand. If you intend to use a local configuration script.jobmanrc v Use either eval or exec if you want to launch a script that does not need post processing activities. it must. which runs your local configuration script as follows: $EXECIT $USE_SHELL $USER_home/. jobmanrc. but not exported. at a minimum. in your local configuration script: #!/bin/ksh PATH=TWS_home:TWS_home/bin:$PATH export PATH /bin/sh -c "$UNISON_JCL" The following is an example of a .jobmanrc "$UNISON_JCL" $IS_COMMAND where: v The value of USE_SHELL is set to the value of the jobmanrc SHELL_TYPE variable (see Table 6 on page 25).page the dba" elif [ $RETVAL -ge 100 ] then conman "tellop Job aborted. are not available.

Note that complete authorization to event rule objects and to display reports on the Tivoli Dynamic Workload Console is already defined for TWSuser in the default security file upon installation of version 8. which are: – actions – events – eventrules v Start and stop the WebSphere Application Server. The chapter is divided into the following sections: v “What is new in configuring user access” v “Setting up options for using the user interfaces” v “Security management overview” on page 31 v “Updating the security file” on page 33 v “Configuring the security file” on page 36 v “Sample security file” on page 51 What is new in configuring user access This Tivoli Workload Scheduler version features the security settings necessary to: v Regulate the access and use of the new event rule objects. v The proxy hostname used in the connection with the HTTP protocol. and the Tivoli Dynamic Workload Console). © Copyright IBM Corp. the event processing server. 2007 29 . however. of the TWS_user. Setting up command-line authentication and user authorizations This chapter describes how to set up the options required to allow users to work with the product user interfaces (the command-line programs. username and password. the Job Scheduling Console.4. v The port number used when establishing the connection with the master domain manager. and monman. you need to provide the following setup information to connect to the master domain manager via HTTP/HTTPS using the WebSphere Application Server infrastructure: v The hostname of the master domain manager. v The credentials. v Force update of the monitoring configuration file for the event monitoring engine. v Display reports on the Tivoli Dynamic Workload Console. the Job Scheduling Console. 1999. and the Tivoli Dynamic Workload Console) and how to manage the authorizations to access scheduling objects assigned to Tivoli Workload Scheduler users. v Switch the event processing server. you must edit the file to grant TWSuser these permissions. v The proxy port number used in the connection with the HTTP protocol.Chapter 4. Setting up options for using the user interfaces To use the Tivoli Workload Scheduler user interfaces (the command-line programs. and run the logman command and the JnextPlan script. If you migrate from previous versions.

v The timeout indicating the maximum time the connecting user interface program can wait for the master domain manager response before considering the communication request as failed. if two Tivoli Workload Scheduler instances are installed on a machine and a system user named operator is defined as user in both instances. The user specified in the username field is defined in the security file on the master domain manager. Because Tivoli Workload Scheduler supports multiple product instances installed on the same machine. In addition to the username and password this file can also contain other settings which. This means that. | | | | Note: On Windows workstations.TWS directory to connect to that installation instance. if your password is tws11"tws. This file is first read when the user connects to a Tivoli Workload Scheduler command-line program. The file containing the user credential is the useropts file. This can be HTTP with basic authentication. is stored in the TWS_home/localopts properties file. PROTOCOL = https # Protocol used to establish a connection with the Master. if this label does not appear. This is the sample content of a useropts file: # # Tivoli Workload Scheduler useropts file defines attributes of this Workstation. For example. # #---------------------------------------------------------------------------# Attributes for CLI connections USERNAME = MDMDBE4 # Username used in the connection PASSWORD = "ENCRYPT:YEE7cEZs+HE+mEHCsdNOfg==" # Password used in the connection #HOST = # Master hostname used when attempting a connection. provides the ability to specify different sets of connection settings for users defined on more than one instance of the product installed on the same machine. make sure that the character is escaped. write it as "tws11\"tws" in useropts. The possibility to have more useropts files. PORT = 3111 # Protocol port #PROXY = #PROXYPORT = TIMEOUT = 120 # Timeout in seconds to wait a server response #DEFAULTWS = The # symbol is used to comment a line. when you specify a password that contains double quotation marks (") or other special characters. For information about this configuration file. then in the localopts file of the first instance the local option useropts = 30 IBM Tivoli Workload Scheduler: Reference Guide . or HTTPS with certificate authentication. #PROTOCOL = http # Protocol used to establish a connection with the Master. The ENCRYPT label in the password field indicates that the specified setting has been encrypted. having a different name each. refer to IBM Tivoli Workload Scheduler: Planning and installation guide.Setting up options for using the user interfaces v The protocol used during the communication. All this information. In the localopts file of each instance of the installed product the option named useropts identifies the file name of the useropts file that has to be accessed in the user_home/. if defined. overwrite those set in the localopts file. If the username and password are not specified in this file then they must be specified when invoking the command-line program. there can be more than one useropts file instances. except username and password. you must exit and access the interface program again to allow the encryption of that field.

The connection_parameteres are used when invoking either a command-line program. A template file named TWS_home/config/Security.Setting up options for using the user interfaces useropts1 identifies the operator_home/. a copy of the template file is installed as TWS_home/Security. As you continue to work with the product you might want to add more users with different roles and authorization to perform specific operations on a defined set of objects. If a parameter is not specified either in the connection parameters when invoking the command or inside the useropts and localopts files. If any of these parameters is omitted when invoking a command. in the security file you might add a user definition named operators that includes users oper1 and oper2.conf. and a compiled. or planman. an error is displayed. | | | | Do not edit the original TWS_home/config/Security. who are authorized to display and list job streams whose names begin with N* only from the master domain manager. Immediately after installing Tivoli Workload Scheduler on a workstation.conf template. Tivoli Workload Scheduler searches for the value first in the useropts file and then in the localopts file. optman. the user who installed the product. Chapter 4. in the localopts file of the second Tivoli Workload Scheduler instance the local option useropts = useropts2 identifies the operator_home/.conf is provided with the product. During installation. or when using the logman command or the JnextPlan scripts. On the other hand.TWS/useropts2 file containing the connection parameters settings that user operator needs to use to connect to that Tivoli Workload Scheduler instance. On UNIX-based workstations you can limit the access to scheduling objects allowed to the root user by creating a security file with a user definition for the root user. and the system administrator (root on UNIX or Administrator on Windows) are the only users defined and allowed to connect to the user interfaces and to perform all operations on all scheduling resources. The system administrator has unrestricted access to all scheduling resources even if the security file does not exist on that workstation. such as composer. TWS_user. but follow the steps described in “Updating the security file” on page 33 to make your modifications on the operational copy of the file. For example.TWS/useropts1 file containing the connection parameters settings that user operator needs to use to connect to that Tivoli Workload Scheduler instance. Setting up command-line authentication and user authorizations 31 . using the security file you can make a distinction between local root users and the root user on the master domain manager by allowing local root users to perform operations affecting only their login workstations and providing the master root user the authorizations to perform operations affecting any workstation across the network. Within the Tivoli Workload Scheduler network. operational copy is installed as TWS_home/Security. Security management overview The way Tivoli Workload Scheduler manages security is controlled by a configuration file named security file. The set of values described in this section is named connection_parameteres.

When the JnextPlan command is run. By default the value assigned to the enCentSec option is NO. commands. either with conman or the 32 IBM Tivoli Workload Scheduler: Reference Guide . the product compares the name of the user with the user definitions in the security file to determine if the user has permission to perform those activities on the specified scheduling objects. To set central security management. the Tivoli Workload Scheduler administrator must run the following steps on the master domain manager: 1. when a link is established or when a user connects to a user interface or attempts to issue commands on the plan. the value of the checksum of the newly compiled security file is encrypted and loaded into the Symphony file and distributed to all the workstations in the Tivoli Workload Scheduler network. Update the information in the security file using the dumpsec command. 3. refer to IBM Tivoli Workload Manager: Planning and Installation Guide. Each time a user runs Tivoli Workload Scheduler programs. For information refer to “dumpsec” on page 34. This can be configured with the enCentSec global option. By default. v Accessing command-line interface programs. Run JnextPlan to update the security information distributed with the Symphony file. 5. v Performing operations on scheduling objects in the database or in the plan. For information refer to “makesec” on page 35. Centralized security management A Tivoli Workload Scheduler environment where centralized security management is enabled is an environment where all workstations share the same security file information contained in the security file stored on the master domain manager and the Tivoli Workload Scheduler administrator on the master domain manager is the only one who can add. Compile the security file using the makesec command. and delete entries in the security file valid for the entire Tivoli Workload Scheduler environment. You can modify the value assigned to this property. to manage how security is handled in your environment. to set the value assigned to the enCentSec global property to YES. modify. On each workstation. This means that the system administrator or the TWS_user who installed the product on that system can decide which Tivoli Workload Scheduler users defined on the system can access which scheduling resources in the Tivoli Workload Scheduler network and how. For information on how to manage the global properties using optman. 2. Use the optman command line program. the Job Scheduling Console.Security management overview | | The security file controls activities such as: v Linking workstations. Distribute the compiled security file to all the workstations in the environment and store it in the TWS_home directory. 4. and user interfaces. using the optman command line program on the master domain manager. As an option. and the Tivoli Dynamic Workload Console. the security on scheduling objects is managed locally on each workstation. the master domain manager can centralize control of how objects are managed on each workstation.

See “dumpsec” on page 34. In a network with centralized security management. a run-number mechanism associated with the creation process of the Symphony file ensures prevention from tampering with the file. The activation of the new security definitions does not require that you stop and restart either the Tivoli Workload Scheduler processes or the WebSphere Application Server infrastructure. perform the following steps: 1. Run makesec to upload the security file and apply the modifications. Close any open conman user interfaces using the exit command. used to modify or display the local parameters database. Run the dumpsec command to download the security file. the operation is allowed. The next two sections contain the command reference information for the dumpsec and makesec commands. Updating the security file Every workstation in a Tivoli Workload Scheduler network (domain managers. you can create a security file on the master domain manager and copy it to each domain manager.Centralized security Job Scheduling Console. even if centralized security is active and the local security file differs from the centralized security rules. and standard agents) has its own security file. You can maintain a file on each workstation. Centralized security does not apply to Tivoli Workload Scheduler operations for which the Symphony file is not required. copy it on the backup master domain manager as soon as possible. Setting up command-line authentication and user authorizations 33 . Chapter 4. fault-tolerant agents. 4. For information about Tivoli Workload Scheduler processes refer to “Tivoli Workload Scheduler workstation processes” on page 11. The only exception to the security file matching criteria introduced by the centralized security management mechanism is that a workstation must always accept incoming connections from its domain manager. See “makesec” on page 35. or. the operation fails and a security violation message is issued. Modify the contents of the dumped security file using the syntax described in “Configuring the security file” on page 36. the parms command. In addition. fault-tolerant agent. regardless of the result of the security file matching process. For example. if you enabled centralized security management. If the values are equal. Commands that do not require the Symphony file to run. If the values are different. 2. two workstations are unable to establish a connection if one of them has enCentSec turned off in its Symphony file or if their security file information does not match. To modify the security file. Tivoli Workload Scheduler compares the value of the checksum in the security file delivered with the Symphony file with the value of the checksum of the security file stored on the workstation. and standard agent. After you modify the master domain manager security file. If a workstation’s security file is deleted and recreated. Ensure that all Tivoli Workload Scheduler users are assigned the required authorization in the security file. use the local security file. the checksum of the new security file will not match the value in the Symphony file. continues to work according to the local security file. 3.

the operational security file is dumped. security-file Specifies the name of the security file to dump. as shown in the examples below.dumpsec dumpsec Writes in textual mode the information contained in the compiled security file and sends the output to a specific file. Syntax dumpsec -v | -u dumpsec security-file Comments If no arguments are specified. To create an editable copy of a security file. Examples The following command dumps the operational security file (TWS_home/Security) to a file named mysec: dumpsec > mysec The following command dumps a security file named sectemp to stdout: dumpsec sectemp 34 IBM Tivoli Workload Scheduler: Reference Guide . The user must have display access to the security file and write permission in the directory where the command is being run. This file can be edited and then used as input for the makesec command which compiles and activates the modified security settings. Arguments -v -u Displays command version information only. redirect the output of the command to another file. Displays command usage information only.

Arguments -v -u -verify in-file Displays command version information only.. The user definitions are modified with a text editor: edit tempsec 3. the file is checked for correct syntax. An editable copy of the operational security file is created in a file named tempsec with the dumpsec command: dumpsec > tempsec 2. The file is then compiled and installed with the makesec command: makesec tempsec The following command compiles user definitions from the fileset userdef* and replaces the operational security file: makesec userdef* Chapter 4.makesec makesec Compiles security definitions and installs the security file. Syntax checking is performed automatically when the security file is installed. you must have modify access to the security file. Syntax makesec -v | -u makesec [-verify] in-file Comments The makesec command compiles the specified file and installs it as the operational security file (. Displays command usage information only. The file is not compiled and installed as the security file. Changes to the security file are recognized as soon as conman is stopped and restarted. If the -verify argument is specified. Specifies the name of a file or set of files containing user definitions. but it is not compiled and installed. Note: The makesec command does not run successfully on Windows operating systems until the connectors are stopped. To use the makesec command./TWS_home/Security). Setting up command-line authentication and user authorizations 35 . Examples The following example shows how to modify the security file definitions: 1. Only checks the syntax of the user definitions in in-file.

Configuring the security file Configuring the security file In the security file you can specify which scheduling objects a user can manage and how. user def-name Specifies the name of the user definition. A user definition is an association between a name and a set of users. Arguments: [# | *] comment All text following a pound sign or an asterisk and at least one space is treated as a comment.. The type of access the user has on these objects (action) Each of these parts is described in this section... Comments are not copied into the operational security file installed by the makesec command. the objects they can access. ] [end] Description: Each user definition can be divided into the following three parts: 1... domains and workstation classes 36 IBM Tivoli Workload Scheduler: Reference Guide . begin . For more information.. A list of the objects on which the user has rights (object-type and object-attributes) 3. The user's specifications (def-name and user-attributes) 2. refer to “Specifying users” on page 38.]] [object-type . and the actions they can perform on the specified objects. object-type Specifies the type of object the user is allowed to access. You define these settings by writing user definitions.. The name can contain up to 36 alphanumeric characters and must start with an alphabetic character. The object types are the following: | action calendars cpu Actions defined in scheduling event rules User calendars Workstations. The syntax described in this section is used to represent a user definition in the security file. user-attributes Contains one or more attributes that identify the users to whom the definition applies. Syntax: [# comment] user def-name user-attributes begin [* comment] object-type [object-attributes] access[=action[. [end] Delimit the part containing object statements and accesses within the user definition.

refer to “Specifying access” on page 43. For more information. If access=@ then all access capabilities are assigned to the specified users.. the objects to which the definition applies. access[=action[. Setting up command-line authentication and user authorizations 37 .. If none is specified then no access is given. For more information. These objects are ordered by object type.4 installations.Configuring the security file | | event eventrule file job parameter prompt | | | | | | | | | | | | | | | | | resource schedule userobj report Event conditions in scheduling event rules Scheduling event rule definitions Tivoli Workload Scheduler database file Scheduled jobs and job definitions User parameters Global prompts The following reports on the Tivoli Dynamic Workload Console: RUNHIST Job Run History RUNSTATS Job Run Statistics WWS Workstation Workload Summary WWR Workstation Workload Runtimes SQL Custom SQL ACTPROD Actual production details (for current and archived plans) PLAPROD Planned production details (for trial and forecast plans) Permission to use these reports is granted by default to the tws_user on fresh Version 8. among all objects of the same type. Omitting an object type prevents access to all objects of that type. | | | | | | object-attributes Specifies one or more attributes that identify.. Wildcard characters: The following wildcard characters are permitted in user definition syntax: ? Replaces one alphanumeric character. If no attributes are specified.]] Describes the list of access capabilities to the specified objects given to the selected users. refer to “Specifying objects” on page 40. the actions defined with the access keyword for the user apply to all the objects of that type defined in the domain. Scheduling resources Job streams User objects You can include multiple object types in a user definition. Chapter 4.

Refer to “Sample security file” on page 51 for an example on how to use variables. For information about variables supplied with the product that can be used in object attributes.]] Use a plus sign (+) to add an attribute the user or users must have.] where: workstation Specifies the workstation on which the user is logged in. Means that the user is logged in on any Tivoli Workload Scheduler standard agent. A user-attribute is defined as: cpu=workstation|@ [. refer to “Specifying objects” on page 40. Specifies that the user is accessing Tivoli Workload Scheduler with the Job Scheduling Console or is logged in on any Tivoli Workload Scheduler workstation. The following Tivoli Workload Scheduler variables can be used: $master $remotes $slaves $thiscpu Means that the user is logged in on the Tivoli Workload Scheduler master domain manager. When defining user authorization consider that: v When commands are issued from the composer command line program.. v When commands are issued from the conman command line program. Means that the user is logged in on any Tivoli Workload Scheduler fault-tolerant agent.Configuring the security file @ Replaces zero or more alphanumeric characters. Wildcard characters are permitted. Therefore the user must be defined: – As system user on the machine where the master domain manager is installed. – In security file on the master domain manager with the authorizations needed to run the allowed commands on the specific objects.. Means that the user is logged in on the Tivoli Workload Scheduler workstation on which the security check is running.. Specifying users Specify user attributes as follows: user-attribute[{+ | ~}user-attribute[. @ 38 IBM Tivoli Workload Scheduler: Reference Guide . Use a tilde (~) to add an attribute the user or users must not have. the user authorizations are checked in the security file of the master domain manager since the methods used to manage the entries in the database are invoked on the master domain manager. the user must be authorized to run the specific commands in the security file both on the connecting workstation and on the master domain manager where the command actually runs...

refer to IBM Tivoli Workload Scheduler: Planning and installation guide. then each user name defined in the security file must have the format realm/username at least when exercising the product from one of the following: v composer v Job Scheduling Console v logman v optman v planman For more information on WebSphere Application Server security configuration.. Available for both Unix and Windows users. For example: #Incorrect: #First User Definition in the Security File USER First CPU=@+LOGON=TWSUser Begin .. logon=username|@ [. or Windows 2003 system.. | | | Order of user qualification Tivoli Workload Scheduler scans the user definitions set in the security file stored on the workstation where the user is connected to check which actions on which objects that user is allowed to perform. meaning that the first user definition that matches the user name determines the capabilities of the user. or Windows XP Service Pack 2 (SP2). Setting up command-line authentication and user authorizations 39 . it is important to order user definitions from most specific to least specific.Specifying users group=groupname[. Do not use this argument for Job Scheduling Console users.] Specifies the name of the group of which the user is a member. @ Specifies that the user is logged in with any name or is a member of any Tivoli administrators group.. The cpu= attribute must be set to a workstation name or @. or when upgrading the Windows operating system from an older version to one of those mentioned above. End Chapter 4. Wildcard characters are permitted. 2...] where: username Specifies the user ID with which the user is logged in on a Tivoli Workload Scheduler workstation. The way the security file is scanned is top-down. make sure you add the Impersonate a client after authentication right to the user settings. For this reason.. If the user is defined on a Windows 2000 Service Pack 4 (SP4).. Notes: 1. Wildcard characters are permitted. If the useDomainQualifiedUserNames is set to true in the WebSphere Application Server security configuration.

See “Sample security file” on page 51 for more information. End #Correct: | | | | | | #First User Definition in the Security File USER First CPU=@+LOGON="TWSDomain\\TWSUser"1 Begin . This means that the character must be repeated and the entire value must be wrapped by double quotes. If you specify the object type but no attributes.. do not come into effect until Tivoli Workload Scheduler (and WebSphere Application Server) are restarted. For example. End | | | | | | 1.. the authorized actions defined for the user with the access keyword apply to all the objects of that type defined in the Tivoli Workload Scheduler domain. and to their access rights. Specifying objects | | | | Specify one or more attributes that identify a set of objects that the user of the user definition is authorized to access. Backslash (\) characters must be escaped on Windows... Table 7.. End #Second User Definition in the Security File USER Second CPU=@+LOGON=TWSUser Begin . Updates to users and user groups..Specifying users #Second User Definition in the Security File USER Second CPU=@+LOGON=TWSDomain\TWSUser Begin . Object attributes Type of object name yes yes no yes yes yes yes yes yes yes yes cpu no no yes no no no yes yes no no yes custom no no no yes no no no no no no no jcl no no no no no no yes no no no no logon no no no no no no yes no no no no provider yes no no yes no no no no no no no type yes no no yes no no no no no no no host yes no no no no no no no no no no port yes no no no no no no no no no no | action calendar cpu | | event eventrule file job parameter prompt report resource 40 IBM Tivoli Workload Scheduler: Reference Guide . Table 7 lists object attributes that are used to identify a specific object within the set of objects of the same type. a resource object is characterized by a name and the workstation where the resource is defined.

]] where: object-attribute Can be any of the following: name=name[. security Allows to manage the security file. or workstation class names.. The following Tivoli Workload Scheduler variables are permitted: Chapter 4. v For the action object type use one or more of the action type names listed in table 33. v The following values apply to the file object type: globalopts Allows to set global options with the optman command. extend. or reset the production plan. Note that users who have restricted access to files should be given at least the following privilege to be able to display other objects (ie.. calendars and cpus): file name=globalopts access=display | | | | | | | | | | | | | | v For the event object type use one or more of the event type names listed in tables 31 and 32. Specify object attributes as follows: object-attribute[{+ | ~}object-attribute[. Multiple names must be separated by commas. Gives the following access types: – Display access for optman ls and optman show – Modify access for optman chg prodsked Allows to create.. Wildcard characters are permitted. cpu=workstation[. domain. trialsked Allows to create trial and forecast plans or to extend trial plans.. In addition.] Specifies one or more names for the object type.. Multiple names must be separated by commas. Symphony Allows to run stageman and JnextPlan. Wildcard characters are permitted.Specifying objects Table 7. If this attribute is not specified.] Specifies one or more workstation. Setting up command-line authentication and user authorizations 41 .... Object attributes (continued) Type of object schedule userobj name yes no cpu yes yes custom no no jcl no no logon no yes provider no no type no no host no no port no no Note: A parameter is characterized by a CPU only when it represents a local parameter defined on the workstation using the parms utility. all defined workstations and domains can be accessed. – Define your own security attribute for your custom-made event providers. you can use the custom attribute to: – Specify different rights for different users based on SAP R/3 event names when defining event rules for SAP R/3 events.

Multiple names must be separated by commas. is the actionType. If omitted. the user is denied access. The Tivoli Workload Scheduler master domain manager.. For event object types... all user names qualify. type=type[. The creator of a job stream and its jobs. If the program is being run on a different workstation. and $user.] Specifies the user names. Wildcard characters are permitted.. For event object types. All fault-tolerant agent workstations. The command or path must be enclosed in double quotes (″). the following variables are permitted: $jclowner. Note: The variables $jclgroup and $jclowner can only be verified if the user is running a Tivoli Workload Scheduler program on the workstation where the job’s executable file resides. this field must be empty. no defined objects can be accessed. specifies the TEC or SNMP host name (used for some types of actions.. or sending SNMP). specifies the TEC or SNMP port number (used for 42 IBM Tivoli Workload Scheduler: Reference Guide . $owner. Multiple names must be separated by commas. specifies the name of the event provider. all defined job files and commands qualify.] For action object types. jcl=″path″ | ″cmd″ Specifies the command or the path name of a job object’s executable file.. The owner of a job’s executable file. If omitted. logon=username[. For the job type object. If type is not specified. Wildcard characters are permitted.Specifying objects The variables supplied with the product that can be used in object attributes are as follows: $jclgroup $jclowner $master $owner $remotes $slaves $thiscpu $user The group name of a job’s executable file. Wildcard characters are permitted.. such as sending TEC events. host=hostname For action object types. is the eventType.] For action object types. The user running the Tivoli Workload Scheduler command or program. all defined objects are accessed for the specified providers. port=portnumber For action object types.. If it does not apply. Multiple names must be separated by commas.. specifies the name of the action provider. All standard agent workstations. The workstation on which the user is running the Tivoli Workload Scheduler command or program. Wildcard characters are permitted. provider=providername[. If provider is not specified.

Because the first matching statement is used. Chapter 4.. Specifying access Specify the type of access the selected users are allowed to perform on the specified objects as follows: access[=action[. Table 8 on page 44 lists the available access keywords for each object type.. They must be ordered from most specific to least specific. no actions are permitted. the order of object statements is important. you can use multiple statements for a single object type to assign different access capabilities to different sets of objects. or sending SNMP). Indicates an attribute that objects must not have. For example: #Incorrect: job name=@ access=display job name=ar@ access=@ #Correct: job name=ar@ access=@ job name=@ access=display See “Sample security file” on page 51 for more information. such as sending TEC events.]] If none are specified. and the capabilities given to users in the Tivoli Workload Scheduler command line. Setting up command-line authentication and user authorizations 43 . Entering access=@ gives users the ability to perform all actions.Specifying objects some types of actions. + ~ Indicates an attribute that objects must have.. this field must be empty. If it does not apply. Order of object qualification In a user definition.

Note: For actions with provider TWSAction and types sbj. For actions with provider TWSAction and type reply. CLI command allowed Tivoli Dynamic Workload Console user interface Tivoli Dynamic Workload Console user interface | | | | | | | | | | | | | | | | | | | | | | | | | action delete display modify unlock use composer delete composer display. new. the event processing server will not be able to run this type of actions. The user needs add access to the old object and modify access the new object. Delete calendar definitions from the database. modify. Either display or extract calendar definitions from the database. The tws_user of the workstation running the event processing server should not be revoked these submit and reply authorizations. create/extract. lock. replace. Use calendars to schedule job streams. use Use specific action types in event rule definitions. replace composer rename Action allowed Display action instances on Tivoli Dynamic Workload Console. new. List action instances on Tivoli Dynamic Workload Console. Unlock calendar definitions locked by other users in the database. print composer add. or sbs. or unlock calendar definitions owned by the user in the database. you must set this keyword in combination with the submit access keyword set for the specific jobs and job streams (schedules) specified in the action. unlocks composer unlock composer . calendar add add modify Add new calendar definitions in the database. Access keywords Object type Access keyword display list submit Note: This keyword has no effect in the current release. Rename calendar definitions in the database. or lock. you must set this keyword in combination with the reply access keyword set for the specific prompts specified in the action. Modify.use calendar in schedules 44 IBM Tivoli Workload Scheduler: Reference Guide .Specifying access Table 8. sbd. If this happens. modify. list. composer add.

Use the event in an event rule definition. stopappserver composer unlock shutdown | | | | | | | | | start stop unlock unlink conman unlink switchmgr. Access keywords (continued) Object type cpu (Includes workstations. unlocks conman shutdown conman deployconf. stop. View and send messages to the Tivoli Workload Scheduler conman console. new. Close workstation links. list. print Allows the user to display workstations. modify. lock. Switch the domain manager functionality to a workstation. or lock. Switch the event processor server from the master domain manager to the backup master or vice versa. create/extract. switcheventprocessor | | | | | event start and stop use Chapter 4. Shut down Tivoli Workload Scheduler processing. Alter workstation job fences in the production plan. Modify. composer list.progressive. Stop Tivoli Workload Scheduler processing. Open workstation links. start. Setting up command-line authentication and user authorizations 45 . starteventprocessor. new. Stop the event processor server.Specifying access Table 8. Delete definitions for workstations. or unlock definitions for workstations. and domains in the database. Force update of the monitoring configuration file for the event monitoring engine. composer display. workstation classes. startappserver Startup utility conman stop. and domains from the database. conman console composer delete console delete display list fence limit link modify Either display or extract definitions for workstations. modify. domains. workstation composer rename classes. Start Tivoli Workload Scheduler processing. workstation classes. Start the application server. workstation classes. stopeventprocessor. workstation classes and domains locked by other users in the database. and domains owned by the user in the database. Stop the event monitoring engine. domains and links in the plan. startmon. stopmon. and workstation classes) Access keyword add add modify Action allowed Add new definitions for workstations. Alter workstation job limits in the production plan. conman showcpus conman fence conman limit cpu conman link composer add. and domains in the database. The user needs add access to the old object and modify access the new object. replace Rename definitions for workstations. CLI command allowed composer add. and domains from the database. Start the event monitoring engine. Unlock definitions for workstations. Stop the application server. Start the event processor server. replace. workstation classes.

Edit global options. Compile the security file to update security settings on a workstation. Unlock event rules locked by other users in the database. lock. optman show makesec. list. Display global options. dumpsec. Display information about event rules in the database and in log records. optman change CLI command allowed composer add. extract composer list composer modify. Dump the settings contained in the compiled security file. Action allowed Add a new event rule in the database. Access keywords (continued) Object type Access keyword add delete display list modify unlock file (valid only build for CLI) delete You must specify the file display names to which the type of modify access applies. stageman. new. rename. Generate the production plan. print. Modify event rules in the database. trial plans and forecast plans. create. Delete objects from the database. new. replace composer unlock JnextPlan. replace composer delete composer display. modify. rename. Delete a event rule from the database. Display and extract event rules from the database and from log records. prodsked. planman deploy | | | | | | | | | | | | | | | | | | | | eventrule 46 IBM Tivoli Workload Scheduler: Reference Guide . Deploy rules.Specifying access Table 8. optman ls.

Display job from the plan. Not valid for workstations in end-to-end environment. Unlock job definitions locked by other users in the database. Add dependencies to jobs in the production plan. Delete dependencies from jobs in the production plan. Use job definition as dependency in a job stream. or lock. Not valid for workstations in end-to-end environment. or commands. Access keywords (continued) Object type job Access keyword add add modify Action allowed Add new job definitions in the database. conman adddep adddep altpri cancel confirm conman altpri conman cancel job conman confirm deldep conman deldep job delete display composer delete composer display. modify. or unlock job definitions owned by the user in the database. The user composer rename needs add access to the old object and modify access the new object. submit file. list. new. replace. Kill running jobs. Alter the priority of jobs in the production plan. Delete job definitions from the database. print. Confirm completion of jobs in the production plan. Reply to job prompts in the production plan. submit job composer unlock composer . Modify. lock. Not valid for workstations in end-to-end environment. Display information about jobs in the production plan. CLI command allowed composer add. new. Cancel jobs in the production plan. Not valid for workstations in end-to-end environment. modify. Not valid for workstations in end-to-end environment.use job in job stream unlock use Chapter 4. unlocks conman release job list kill modify release reply rerun submit conman reply conman rerun conman submit docommand.Specifying access Table 8. create/extract. Release jobs from dependencies in the production plan. Not valid for workstations in end-to-end environment. replace Rename job definitions in the database. conman display conman showjobs conman kill composer add. Not valid for workstations in end-to-end environment. Submit jobs. Either display or extract job definitions from the database. Setting up command-line authentication and user authorizations 47 . or files as jobs into the production plan. Rerun jobs in the production plan. Not valid for workstations in end-to-end environment.

modify. utility parms composer add.use prompt in job and job stream. Modify.Specifying access Table 8. print. Display reports on Tivoli Dynamic Workload Console. or unlock prompt definitions owned composer add. list. Either display or extract prompt definitions from the database. replace composer rename delete display composer delete composer display. Rename parameter definitions in the database. Display prompts waiting for a response. file. or lock. Unlock parameter definitions locked by other users in the database. replace modify unlock prompt add add modify Rename prompt definitions in the database. The user needs add access to the old object and modify access the new object. unlocks Reply to a job or job stream prompt. Delete prompt definitions from the database. conman reply composer unlock composer . Delete parameter definitions from the database. new. submit docommand. or unlock parameters definitions owned by the user in the database. Use prompts when defining or submitting jobs and job streams and when adding dependencies from prompts. and conman add dependencies. new. new. new. sched Tivoli Dynamic Workload Console user interface | | report display 48 IBM Tivoli Workload Scheduler: Reference Guide . replace. modify. job. Add new prompt definitions in the database. modify. modify. The user composer rename needs add access to the old object and modify access the new object. create/extract. unlocks composer unlock composer add. conman recall conman showprompts delete display list modify reply unlock use Modify. Either display or extract parameter definitions from the database. list. lock. Unlock resource definitions locked by other users in the database. composer delete composer display. CLI command allowed composer add. replace. or lock. by the user in the database. Access keywords (continued) Object type parameter Access keyword add add modify Action allowed Add new parameter definitions in the database. create/extract. Display information about prompts. lock. print.

add dependencies. replace composer rename delete display list modify resource use composer delete composer display.use resource in job and job stream. modify. Setting up command-line authentication and user authorizations 49 . lock. and conman .Specifying access Table 8. Either display or extract resource definitions from the database. Displays information about resources. new. Use resources when defining or submitting jobs and job streams and when adding dependencies from resources. new. unlocks conman resource composer . print conman showresources composer add. Change the number of units of a resource on a workstation. Access keywords (continued) Object type resource Access keyword add add modify Action allowed Add new resource definitions in the database. create/extract. sched Chapter 4. The user needs add access to the old object and modify access the new object. or lock. Delete resource definitions from the database. Rename resource definitions in the database. Modify. submit docommand. or unlock resource definitions owned by the user in the database. CLI command allowed composer add. replace. job. list. file. modify.

Displays information about job streams. or unlock user definitions owned by composer add. Delete user definitions from the database. Not valid for workstations in end-to-end environment. Add new user definitions in the database. new. Not valid for workstations in end-to-end environment. lock. conman display conman showschedules conman limit sched composer add. new. Delete job stream definitions from the database. Either display or extract user definitions from the database. or unlock job stream definitions owned by the user in the database. Either display or extract job stream definitions from the database. replace composer rename adddep conman adddep altpri conman altpri cancel deldep conman cancel sched conman deldep sched delete display composer delete composer display. or lock. Alter user passwords in the database.Specifying access Table 8. composer unlock 50 IBM Tivoli Workload Scheduler: Reference Guide . or lock. Rename job stream definitions in the database. Display job streams from the plan. create/extract. The user needs add access to the old object and modify access the new object. modify. Release job streams from dependencies. Modify. list. create/extract. conman altpass composer delete composer display. new. Submit job streams in the current production. Not valid for workstations in end-to-end environment. replace. Not valid for workstations in end-to-end environment. modify. CLI command allowed composer add. Reply to a job stream prompts. lock. Modify the limit for job concurrently running within a job stream. print. Delete dependencies from job stream in the production plan. Cancel job stream in the production plan. unlocks conman release sched conman reply conman submit sched composer unlock composer add. Access keywords (continued) Object type schedule Access keyword add add modify Action allowed Add new job stream definitions in the database. modify. The user composer rename needs add access to the old object and modify access the new object. list. new. the user in the database. replace list limit modify release reply submit unlock userjob add add modify Rename user definitions in the database. replace. Alter the priority of job stream in the production plan. modify. unlocks Unlock user definitions locked by other users in the database. Unlock job stream definitions locked by other users in the database. print altpass delete display modify unlock Modify. Add dependencies to job stream in the production plan.

list.modify.submit.unlock access=display.root | | | | | | | | | | | | | | | | | | end ########################################################### # (2) APPLIES TO TWS_users AND ROOT USERS LOGGED IN ON ANY # WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.RUNSTATS access=display file name=globalopts access=display end ########################################################### # (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE # MASTER DOMAIN MANAGER.Sample security file Sample security file The following is a sample security file.--------------------------------job cpu=@ + logon="TWS_domain\\TWS_user" access=@ Chapter 4. Setting up command-line authentication and user authorizations 51 .--------------------------------job cpu=$thiscpu access=@ schedule cpu=$thiscpu access=@ resource cpu=$thiscpu access=@ prompt access=@ calendar access=@ cpu cpu=$thiscpu access=@ parameter cpu=$thiscpu ~ name=r@ access=@ action provider=@ access=display.-----------MASTER DOMAIN MANAGER.delete. user mastersm cpu=$master + logon=TWS_user. user masterop cpu=$master + group=sys begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------.use.display. A description of the file follows the listing.root begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------.list event provider=@ access=use report name=RUNHIST.list access=use access=display # ---------.use. user sm logon=TWS_user.submit. ########################################################### # Sample Security File ########################################################### | | # (1) APPLIES TO TWS_users AND ROOT USERS LOGGED IN ON THE # begin # OBJECT job schedule resource prompt file calendar cpu parameter name=@ ~ name=r@ userobj cpu=@ + logon=@ eventrule name=@ action event report provider=@ provider=@ name=@ ATTRIBUTES ACCESS CAPABILITIES ---------------------access=@ access=@ access=@ access=@ access=@ access=@ access=@ access=@ access=@ access=add.

limit.Sample security file | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | job cpu=@ + logon=root access=adddep. confirm.adddep. resource.resource.cancel.altpri. confirm.release. rerun.release.$jclowner ~ logon=root access=add.release.use prompt access=add.display. deldep.cancel. link.use job cpu=$thiscpu ~ logon=root access=adddep.cancel.--------------------------------job cpu=$thiscpu + logon=$user access=@ job cpu=$thiscpu + logon=root access=adddep.use schedule cpu=$thiscpu access=@ resource access=add. reply.limit.rerun.display. submit access=add.deldep.use name=globalopts access=display name=prodsked access=display name=symphony access=display name=trialsked access=build. modify.deldep.display. reply. display access=display.start.altpri.submit.unlink parameter name=@ ~ name=r@ access=@ end ########################################################### # (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON # ANY WORKSTATION.cancel.altpri.confirm.use calendar access=use cpu cpu=$thiscpu access=console.reply.use schedule cpu=$thiscpu access=add.reply.stop. user misusers group=mis begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------.submit.rerun.display parameter name=r@ access=@ parameter name=@ access=display cpu=@ + logon=$user. cancel.use cpu=@ access=@ name=@ ~ name=r@ access=@ name=RUNHIST.altpri. confirm. reply.altpri.use cpu=$thiscpu access=@ cpu=@ access=adddep.submit.release.use job schedule schedule resource file file file file calendar cpu parameter report end ########################################################### # (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY # WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER user op group=sys begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------. deldep.release.deldep.submit.--------------------------------job cpu=$thiscpu + logon=$user access=@ job cpu=$thiscpu + logon=$jclowner ~ logon=root access=submit.RUNSTATS access=display 52 IBM Tivoli Workload Scheduler: Reference Guide .fence.submit.rerun.

and delete event rule definitions. They are the only ones who can generate all kinds of plans and who can create. They can use event rules. which are those who are logged in on any workstation other than the master domain manager. Setting up command-line authentication and user authorizations 53 . which is the least specific. files.display parameter name=u@ access=@ parameter name=@ ~ name=r@ access=display end ########################################################### Note that the order of definitions is from most to least specific. | | | | | | | | | | | | | | | | | | | # (1) APPLIES TO TWS_users AND ROOT USERS LOGGED IN ON THE MASTER DOMAIN MANAGER. TWS_users and root users are matched first.root This user definition applies to TWS_users and root users to whom definition (1) does not apply. They are given unrestricted access to all objects. except parameters that have names beginning with r. # (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE MASTER DOMAIN MANAGER. All other users are matched with the last definition.--------------------------------job cpu=$thiscpu + logon=$user access=@ job cpu=$thiscpu + logon=$jclowner ~ logon=root access=submit. but are not allowed to create. Because of the order. Multiple object statements are used to give these users specific types of access to different sets of objects. user default logon=@ begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------. Access to the r parameters is given only to users in the mis group. update. user masterop cpu=$master + group=sys This user definition applies to users logged into the sys group on the master domain manager. and then users in the mis group.use schedule cpu=$thiscpu access=add. Chapter 4. They are given a unique set of access capabilities. They are given unrestricted access to all objects on their login workstation. Note that prompts. or delete event rule definitions. user mastersm cpu=$master + logon=TWS_user. and calendars are global in nature and are not associated with a workstation. user sm logon=maestro.Sample security file | | | | | | | | | | | | | | | | | | | end ########################################################### # (6) APPLIES TO ALL OTHER USERS LOGGED IN ON ANY # WORKSTATION.submit. followed by users in the sys group. # (2) APPLIES TO TWS_users AND ROOT USERS LOGGED IN ON ANY WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. modify. there are three job statements: v The first job statement permits unrestricted access to jobs that run on any workstation (@) under the user’s name ($user).root This user definition applies to GUI and CLI access for TWS_users and root users logged into a master domain manager. For example. update.

user misusers group=mis This user definition applies to users logged into the mis group on any workstation. Jobs that run as root are excluded. # (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON ANY WORKSTATION. # (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. Resources. They are given a set of access capabilities similar to those in definition (3).Sample security file v The second job statement permits specific types of access to jobs that run on any workstation and that run as root. prompts. They are the only users defined on the master domain manager. v The third job statement permits specific types of access to jobs that run on any workstation. who can generate trial and forecast plans. user op group=sys This user definition applies to sys group users to whom definition (3) does not apply. which prevents access to these objects. which are those who are logged in on any workstation other than the master domain manager. different from maestro or root. No access is permitted to parameters with names that begin with r. These users are given unrestricted access to parameters with names that begin with r. files. but can only display other parameters. They are given a limited set of access capabilities. but can only display other parameters. These users are given unrestricted access to parameters with names that begin with u. # (6) APPLIES TO ALL OTHER USERS LOGGED IN ON ANY WORKSTATION. user default logon=@ This user definition gives a set of default capabilities to users other than those covered by the preceding definitions (1 to 5). The exception is that access is restricted to objects on the user’s login workstation ($thiscpu). 54 IBM Tivoli Workload Scheduler: Reference Guide . calendars. and workstations are omitted. The jobs must run under the user’s name ($user) or under the name of the owner of the job file ($jclowner).

You use the JnextPlan script on the master domain manager to generate the production plan and distribute it across the Tivoli Workload Scheduler network.JnextPlan” on page 69 v “Planman command line” on page 72 v “Starting production plan processing” on page 87 v “Automating production plan processing” on page 87 | | | | | | | | | | | | What is new in managing the plan The following enhancements are new in plan management: v The JnextPlan command and the final job stream now start WebSphere Application Server automatically as their first step. The preproduction plan is automatically created and managed by the product. © Copyright IBM Corp. v A new planman deploy command can be used to manually deploy all event rules that are not in draft state. on which fault-tolerant agent. For additional information on the JnextPlan script. v A new planning process (independent from JnextPlan and from the Symphony file creation and deployment processes) activates event rules and deploys event management configuration to the agents. The process is described in “The event rule management process” on page 92. Managing the production cycle The core part of a job management and scheduling solution is the creation and management of the production plan. and what dependencies must be satisfied before each job is launched. 2007 55 .Chapter 5. This chapter describes how Tivoli Workload Scheduler manages plans. and is unlocked when the generation completes or if an error condition occurs. To avoid problems the database is locked during the generation of the plan.JnextPlan” on page 69. refer to “Generating a production plan . The production plan is the to-do list that contains the actions to be performed in a stated interval of time on the workstations of the scheduling network using the available resources and preserving the defined relationships and restrictions. Plan management basic concepts The production plan contains information about the jobs to run. The preproduction plan is used to identify in advance the job stream instances and the external follows job stream dependencies involved in a specified time-window. The chapter is divided into the following sections: v “What is new in managing the plan” v “Plan management basic concepts” v “Customizing plan management using global options” on page 65 v “Generating a production plan . Tivoli Workload Scheduler creates the production plan starting from the modeling data stored in the database and from an intermediate plan called preproduction plan. 1999. There is no longer a need to run the CheckPrerequisites script to ensure that the application server is up before running final.

are updated accordingly. Access the copy of the Symphony file and read the instructions about which jobs to run. The processing that occurs on each workstation involved in the current production plan activities is described in more detail in “Tivoli Workload Scheduler workstation processes” on page 11. Logs all the statistics of the previous production plan into an archive 7. Update its copy of the Symphony file with the job processing results and send notification back to the master domain manager and to all full status fault-tolerant agents. In this way the Symphony file on the master domain manager is kept up to date with the jobs that need to be run. any changes you make to the plan using conman do not affect the definitions in the database.Plan management basic concepts To generate and start a new production plan Tivoli Workload Scheduler performs the following steps: 1. Updates the job stream states in the preproduction plan. 2. Updates to objects in the database do not affect instances of those objects already in the production plan. Each fault-tolerant agent that receives the production plan can continue processing even if the network connection to its domain manager goes down. Updates the preproduction plan with the objects defined in the database that were added or updated since the last time the plan was created or extended. Changes to the objects in the database do not affect the plan until the production plan is extended or created again using the JnextPlan script or planman command-line interface. the ones that are running. if defined. Retrieves from the preproduction plan the information about the job streams to run in the specified time period and saves it in an intermediate production plan. 6. The copy of the newly generated Symphony file is deployed starting from the top domain's fault-tolerant agents and domain managers of the child domains and down the tree to all subordinate domains. At each destination fault-tolerant agent the Tivoli Workload Scheduler processes perform the following actions to manage job processing: 1. Includes in the new production plan the uncompleted job streams from the previous production plan. 2. 5. 4. The original copy of the Symphony file stored on the master domain manager and the copies stored on the backup master domain managers. 3. Creates the new production plan and stores it in a file named Symphony. Distributes a copy of the Symphony file to the workstations involved in the new product plan processing. Also the master domain manager (and backup master domain manager if defined) has the copy of the Symphony file that contains all updates coming from all fault-tolerant agents. each fault-tolerant agent has its own copy of the Symphony file updated with the information about the jobs it is running (or that are running in its domain and child domains if the fault-tolerant agent is full-status or a domain manager). and the ones that have completed. 56 IBM Tivoli Workload Scheduler: Reference Guide . Note: While the current production plan is in process. Make calls to the operating system to launch jobs as required. 3. This means that during job processing.

according to the defined matching criteria. the preproduction plan by performing the following steps: v Removes the job stream instances in COMPLETE and CANCEL states. All the remaining information about the job streams and the other scheduling objects (calendars. At this stage only the job streams with the time they are scheduled to start and their dependencies are highlighted. The criteria used in removing these instances takes into account this information: v The first job stream instance that is not in COMPLETE state at the time the new plan is generated (FNCJSI). but are retrieved from the database as soon as the production plan is generated. and a job stream instance submitted from the command line during production using the conman sbs command. files. v Resolves all job and job stream dependencies.Preproduction plan Preproduction plan The preproduction plan is used to identify in advance the job stream instances and the job stream dependencies involved in a specified time period. v The time period between the time FNCJSI is planned to start and the end time of the old production plan. domains. v The external follows dependencies that exist between the job streams and jobs included in different job streams. old job stream instances are automatically removed. the algorithm used to calculate which job stream instances are removed from the preproduction plan is the following: if T < 7 All job stream instances older than 7 days from the start time of the new production plan are removed from the preproduction plan. To avoid any conflicts the database is locked during the generation of the preproduction plan and unlocked when the generation completes or if an error condition occurs. resources. prompts. The preproduction plan contains: v The job stream instances to be run during the covered time interval. This improves performance when generating the production plan by preparing in advance a high-level schedule of the anticipated production workload. all job stream instances closer than 7 days to the start time of the new production plan are kept regardless of their states. and windows users) that will be involved in the production plan for that time period are not included. Assuming T is this time period. if necessary. Managing the production cycle 57 . When the production plan is extended. workstations. An external job or job stream that must complete successfully before the successor job or job stream can start is named predecessor. including external follows dependencies. This job stream instance can be both a planned instance. expands. that is an instance added to the plan when the production plan is generated. Chapter 5. and updates. Tivoli Workload Scheduler automatically generates. v Selects all the job streams scheduled after the end of the current production plan and generates their instances. A job or job stream that cannot start before another specific external job or job stream is successfully completed is named successor.

refer to “Selecting job streams in commands” on page 257. 58 IBM Tivoli Workload Scheduler: Reference Guide . jobstreamname Corresponds to the job stream name used in earlier versions of Tivoli Workload Scheduler. For more information about these keywords refer to “on” on page 161. workstation#jobstreamname and scheddateandtime instead of workstation#jobstream_id. scheddateandtime Represents when the job stream instance is planned to start in the preproduction plan. to ensure that no job stream instance that is a potential predecessor of a job stream newly added to the new preproduction plan is deleted. the schedtime keyword is used only to order chronologically the job stream instances in the preproduction plan while. Tivoli Workload Scheduler generates and assigns a unique alphanumeric identifier to each job stream instance.3 the plan had a fixed duration of one day. It corresponds to the day specified in the run cycle set in the job stream definition by an on clause and the time set in the job stream definition by an at or schedtime keyword. “at” on page 138 and “schedtime” on page 171. For more information on how to specify a job stream instance in a command using conman. Identifying job stream instances in the plan In earlier versions than 8.3 the plan can cover a period lasting several days or less than one day. is the one that uses workstation#jobstreamname and scheddateandtime. all job stream instances younger than FNCJSI are kept. both in this guide and in the command-line interfaces of the product. The default convention used to identify a job stream instance. Together with these two values that you can set in the job stream definition. and also the need to define a new convention to uniquely identify each job stream instance in the plan. for its internal processing. Each job stream instance is identified in the plan by the following values: workstation Specifies the name of the workstation on which the job stream is scheduled to run. This change has added the possibility to have in the same plan more than one instance of the same job stream with the same name. the jobstream_id. This algorithm is used to ensure that the preproduction plan size does not increase continuously and. to uniquely identify a job stream instance when managing job streams in the plan using the conman command-line program. For more information on the format of the jobstream_id refer to “showjobs” on page 321. at the same time. You can use any of the two types of identifiers. Note: In the Tivoli Workload Scheduler for z/OS terminology the concept that corresponds to the preproduction plan is long term plan (LTP).Preproduction plan if T > 7 All job stream instances older than FNCJSI are removed from the preproduction plan. the at keyword also represents a dependency for the job stream. If set. Since version 8. if set.

m.relative to clause is set in the object definition.m. Figure 5 shows a job stream Js1 which has an external follows dependency on the job stream instance of Js2 that starts with an offset of 2 hours with respect to Js1. In this case the follows .. Js2 Js1 Figure 4. Within a relative interval matching criteria Within an absolute interval Using only the job or job stream instances defined in a range. for example from today at 6:00 a. In this case the follows. all external follows dependencies to job streams and jobs are resolved using four different possible matching criteria: Closest preceding Using the closest earlier job or job stream instance.previous clause is set in the object definition.m.m.Managing external follows dependencies Managing external follows dependencies for jobs and job streams During the creation of the preproduction plan. for example from -25 hours before the dependent job stream start time to -5 hours after the dependent job stream start time.. Figure 6..m. Closest preceding matching criteria Within a relative interval Considering the job or job stream instances defined in a range with an offset relative to the start time of the dependent job or job stream.. Figure 6 shows a job stream Js1 which has an external follows dependency from the instance of job stream Js2 that is positioned in the preproduction plan between 7 a. and 9 a. Figure 4 shows a job stream Js1 which has an external follows dependency from the closest earlier instance of job stream Js2 The time window where the predecessor is searched is greyed out in the figure. In this case the follows. absolute to clause is set in the object definition. Managing the production cycle 59 . to the day after tomorrow at 5:59 a. Js2 -2h Js1 +2h Figure 5. Within an absolute interval matching criteria Same day Considering the job or job stream instances planned to run on the same Chapter 5. Js2 Js1 7a...m. 9a.

Figure 7 shows a job stream Js1 which has an external follows dependency from the instance of job stream Js2 that is positioned to start on the same day. this is the predecessor instance. if multiple instances of potential predecessor job streams exist in the specified time interval. 2. This behavior applies for external follows dependencies between job streams. If there is no preceding instance.sameday is set in the object definition. If such an instance exists. but that cannot be resolved in the current production plan because the predecessor’s start time is not 60 IBM Tivoli Workload Scheduler: Reference Guide . Js2 startOfDay Js1 1 minute before the next startOfDay Figure 7. Tivoli Workload Scheduler considers the correct predecessor instance as the closest instance that starts after the depending job or job stream start time. is called a pending predecessor. Closest preceding predecessor job External follows dependencies are identified between jobs and job streams stored in the database whose instances are added to the preproduction plan when the preproduction plan is automatically created or extended... In this case the clause follows. but that can be a potential predecessor of instances of jobs and job streams added to the production plan as the production plan is extended. A job or job stream not yet included in the production plan.Managing external follows dependencies day. Sameday matching criteria Regardless of which matching criteria are used. Tivoli Workload Scheduler searches for the closest instance that precedes the depending job or job stream start time. Figure 8 shows in bold the instances of job1 the successor job or job stream is dependent on. For external follows dependencies of a job stream or job from another job the criteria are matched by considering by the start time of the job stream hosting the predecessor job instead of the start time of the predecessor job itself. Js1 job1 Js1 job1 Successor job or job stream Figure 8. the rule used by the product to identify the correct predecessor instance is the following: 1. Job and job stream instances submitted in production from the conman command line are written in the preproduction plan but they are not used to recalculate predecessors of external follows dependencies already resolved in the preproduction plan. A pending predecessor is like a dummy occurrence created by the planning process to honor a dependency that has been resolved in the preproduction plan.

Chapter 5. Production plan After having created or updated the preproduction plan. For information about the conman sj command refer to “showjobs” on page 321. This can happen. Tivoli Workload Scheduler completes the information stored in the preproduction plan with the information stored in the database about the operations to be performed in the selected time period and the other scheduling objects involved when processing the plan and copies it in a new Symphony file. The way in which pending predecessors are managed is strictly linked to whether Pending predecessor Successor End of Production Plan Figure 9.JnextPlan” on page 69. Pending predecessor instance or not the successor job or job stream is carried forward: v If the successor is carried forward when the production plan is extended. Managing the production cycle 61 . the successor is carried forward and the pending predecessor is not added to the plan because it was flagged as draft in the database. the predecessor is included in the new production plan. if. When dealing with an orphaned dependency you must verify if it can be released and if so cancel it. In the security file the user authorization required to generate the production plan is the build access keyword on the prodsked and Symphony files. such as job streams carried forward from the production plan already processed. A copy of the new Symphony file is distributed to all the workstations involved in running jobs or job streams for that production plan. Note: To avoid running out of disk space. but the dependency becomes orphaned. Understanding carry forward options Job streams are carried forward when the production plan is generated. See “carryforward” on page 139. and archives the old Symphony file in the schedlog directory. keep in mind that each job or job stream instance increases the size of the Symphony file by 512 bytes. It also adds in this file the cross-plan dependencies. when extending the production plan. For information on how to generate the production plan refer to “Generating a production plan . The orphaned dependencies are marked with a [O] in the Dependencies column in the output of the conman sj command. How the job stream is carried forward depends on: v The carryforward keyword in the job stream. for example. At the end of this process the newSymphony file contains all the information implementing the new production plan.Managing external follows dependencies within the current production plan end time. Figure 9 shows how a pending predecessor and its successor are positioned in the preproduction plan. the predecessor is included in the new production plan and the dependency becomes current. v If the successor is not carried forward when the production plan is extended.

Job streams are carried forward only if they have both jobs in the specified states and the carryforward keyword set in the job stream definition. See IBM Tivoli Workload Scheduler Planning and Installation Guide.Understanding carry forward options v The enCarryForward global option. See “The stageman command” on page 82. See IBM Tivoli Workload Scheduler Planning and Installation Guide. Table 9 shows how the carry forward global options work together. Only the jobs in the specified states are carried forward with the job streams. enCarryForward=yes carryStates=() enCarryForward=all carryStates=(states) Table 10 shows the result of the carry forward setting based on how the enCarryForward global option and the stageman -carryforward keywords are set. v The stageman -carryforward command-line keyword. No job streams are carried forward. This is the default setting. v The carryStates global option. This means that an unsuccessful job stream that is marked as carryforward. Only jobs in the specified states are carried forward with the job streams. Table 9. Job streams are carried forward only if they did not complete and have the carryforward keyword set in the job stream definition. 62 IBM Tivoli Workload Scheduler: Reference Guide . All jobs are carried forward with the job streams. Carry forward global options settings Global options enCarryForward=all carryStates=() enCarryForward=no enCarryForward=yes carryStates=(states) Carry forward operation Job streams are carried forward only if they did not complete. Table 10. continues to be carried forward until one of the following occurs: v It ends in a SUCC state v Its UNTIL time is reached v It is cancelled. Resulting carry forward settings enCarryForward NO NO YES ALL ALL YES YES stageman -carryforward YES ALL NO NO YES ALL YES Resulting carry forward setting NO NO NO NO ALL ALL YES The carry forward option set in the job stream definition is persistent. Job streams are carried forward only if they have jobs in the specified states. All jobs are carried forward with the job streams.

For example. v It cannot be run to manage production. the database is locked and only unlocked when the operation completes. refer to “Customizing plan management using global options” on page 65. Note: Regardless of how carry forward options are set. READY If they are free from dependencies and their start time has elapsed. job streams that do not contain jobs are not carried forward. but you want to know what the plan would be if it covered three days you can generate a trial plan. This depends on the settings of the minLen and maxLen global options. – The file name starts with a leading T. v It can be managed by users with access build on trialsked file object type set in the security file on the master domain manager. – The production plan end date. the preproduction plan does not contain the instances of job streams that ended successfully. so all the job streams it contains are in one of these two states: HOLD If they are dependent on other job streams or if their start time is later than the start of plan time. This happens because. Trial plan A trial plan is a projection of what a production plan would be if it covered a longer period of time. When this happens. but the size of the resulting file containing all trial plan information must be taken into account. it does not take into account any dynamic updates made to the Symphony file while the production plan is being processed. if you generate a production plan that covers two days.Understanding carry forward options The carried forward job stream naming convention is affected by the value assigned to the global option enLegacyId. then the next time you run JnextPlan there will be misalignment between the preproduction plan and the new Symphony file. The result of this misalignment is that dependencies are not resolved according to carried forward successful job stream instances because they no longer exist in the preproduction plan. but the new Symphony file does. Managing the production cycle | | | 63 . There is no restriction on the time period selected for a trial plan. v It is based on the static information stored in the current preproduction plan. For more information on the different settings for this option. These are the characteristics of a trial plan: v Its start date matches: – The preproduction plan start date. Trial plan generations may result in the extension of the preproduction plan end time. Chapter 5. v It produces a file stored in the schedlog directory with these properties: – The same format as the Symphony file. If you set carryStates=(succ) and either enCarryForward=all or enCarryForward=yes. Because the trial plan is based on the static information stored in the preproduction plan.

extension Used to create a trial plan of the extension of the current production plan to have an overview of how production evolves in the future. Forecast plan The forecast plan is a projection of what the production plan would be in a chosen time frame. in the future. Because the forecast plan is based on the static information stored in the database. v It is based on a sample preproduction plan covering the same time period selected for the forecast plan. v It cannot be run to manage production. While creating a forecast plan the database is locked. These are the characteristics of a forecast plan: v It covers any time frame. so all the job streams it contains are in one of these two states: HOLD If they are dependent on other job streams or if their start time is later than the start of plan time. This sample preproduction plan is deleted after the forecast plan is created. There is no restriction on the time period selected to generate a forecast plan. and only unlocked when the operation completes. if you generated a production plan that covers two days and you want to know what the plan would be for the next week you can generate a forecast plan. in the past or even partially overlapping the time period covered by the current production plan. For information on how to create or extend a trial plan.Trial plan The operations that can be performed on a trial plan on the master domain manager are: creation Used to create a trial plan to have an overview of production when a production plan does not yet exist. The operation that can be performed on a forecast plan on the master domain manager is: 64 IBM Tivoli Workload Scheduler: Reference Guide . v It can be managed by users with access build on trialsked file object type set in the security file on the master domain manager. READY If they are free from dependencies and their start time has elapsed. v It produces a file stored in the schedlog directory with these properties: – The same format as the Symphony file. For example. but the size of the resulting file containing all forecast plan information must be taken into account. it does not take into account any dynamic updates made to the Symphony file while the production plan is being processed or the preproduction plan. refer to “Planman command line” on page 72. – The file name starts with a leading F.

Managing the production cycle 65 . based on their state. no. You need to generate the plan again to activate the new settings. The available settings for enCarryForward are yes.Forecast plan creation It is used to create a forecast plan to have an overview of production in a chosen time frame. Its setting determines. Enter yes to have all EXTERNAL job Chapter 5. For information on how to create a forecast plan. The default setting is 0600. calculated in days. as a buffer. 8 days. maxLen It is the maximum length. after the end of the newly generated production plan. carryStates This is an option that affects how the stageman command manages jobs in carried forward job streams. Customizing plan management using global options You can customize some criteria for Tivoli Workload Scheduler to use when managing plans by setting specific options on the master domain manager using the optman command-line program. and all. of the preproduction plan which is left. The default setting is: carryStates=null that means that all jobs are included regardless of their states. Properties impacting the generation or extension of the production plan: startOfDay It represents the start time of the Tivoli Workload Scheduler processing day in 24-hour format: hhmm (0000-2359). as a buffer. or hold are included in carried forward job streams. Its setting determines whether or not job streams that did not complete are carried forward from the old to the new production plan. The default setting for this property is the lowest value that can be assigned to it. 14 days. refer to “Planman command line” on page 72. The default setting for this option is the lowest value that can be assigned to it. The value assigned to this option is used when the script UpdateStats is run from within JnextPlan. exec. calculated in days. enCFInterNetworkDeps This is an option that affects how the stageman command manages internetwork dependencies. The default setting is all. of the preproduction plan which is left. The options you can customize are: Properties impacting the generation of the preproduction plan: minLen It is the minimum length. after the end of the newly generated production plan. For example if : carryStates=’abend exec hold’ then all jobs that are in states abend. the jobs to be included in job streams that are carried forward. enCarryForward This is an option that affects how the stageman command carries forward job streams.

v A resource used by one or more job streams carried forward from the previous production plan is referenced by job or job stream instances added to the new production plan. enPreventStart This is an option to manage. The available settings are: yes no The jobs streams that do not contain jobs are marked as SUCC as their dependencies are resolved. no enLegacyId This is an option that affects how job streams are named in the plan and its aim is to keep consistency in identifying job streams in 66 IBM Tivoli Workload Scheduler: Reference Guide . The default setting is yes. If enCFResourceQuantity is set to NO The quantity of the resource is obtained from the resource definition stored in the database. In this case the quantity of the resource is obtained from the old Symphony file. for multiple day production plan. In this case the quantity of the resource is obtained from the resource definition stored in the database. enCFResourceQuantity This is an option that affects how the stageman command manages resources. one of the following situations occurs: v A resource not used by any of the job streams carried forward from the previous production plan is referenced by new job or job stream instances added to the new production plan. The default setting is yes. any job streams without an at time constraint set. The available settings are: yes A job stream cannot start before the startOfDay of the day specified in its scheduled time even if free from dependencies. v A resource used by one or more job streams carried forward from the previous production plan is not referenced by job or job stream instances added to the new production plan.Customizing plan management streams carried forward . Enter no to completely disable the carry forward function for internetwork dependencies. When the production plan is extended. It is used to prevent job stream instances not time dependent from starting all at once as the production plan is created or extended. The jobs streams that do not contain jobs remain in READY state. In this case the quantity of the resource that is taken into account is based on the value assigned to the enCFResourceQuantity option: If enCFResourceQuantity is set to YES The quantity of the resource is obtained from the old Symphony file. enEmptySchedsAreSucc This option rules the behavior of job streams that do not contain jobs. A job stream can start immediately as the production plan starts if all its dependencies are resolved.

or less than the existing minimum. and they report between braces {} the date when they were carried forward. is greatly affected by system activity. and it does Chapter 5. it is set to null if only one instance of that job stream exists in the plan. The values are updated only if the latest job run has an elapsed time greater than the existing maximum.3 master domain manager. The available settings are: yes The jobstream_id of job stream named jobstream_name is set to jobstream_nameN where N is an incremental number assigned by an internal counter. This is expressed as a percentage. and yet use no more CPU time than in periods of low system activity. The maximum and minimum run times and dates that are logged are based only on a job's CPU time. using conman when logged on a Tivoli Workload Scheduler 8.Customizing plan management the plan in mixed environments with a Tivoli Workload Scheduler version 8.3 master domain manager. expressed in minutes. The available settings for the logmanMinMaxPolicy option are: elapsedtime The maximum and minimum run times and dates that are logged are based only on a job’s elapsed time. which means that this property is not enabled. the backward compatibility.2. a job might have a long elapsed time. of the actual time a job used the CPU. if the production period is one day and no multiple instances of the same job stream are submitted. It includes both the amount of time a job used the CPU and the time the job had to wait for other processes to release the CPU. for example.In particular. is complete.x agent. Elapsed time. no The job stream identifier jobstream_id is generated as described in “showjobs” on page 321. expressed in seconds. Carried forward job streams keep their original names and identifiers. even those carried forward. If the job stream named jobstream_name is then carried forward. The default setting is -1. Managing the production cycle cputime 67 . its identifier is set to CFjobstream_nameN. when managing job streams in production from a Tivoli Workload Scheduler version 8. logmanMinMaxPolicy This option defines how the minimum and maximum job run times are logged and reported by logman. This setting is useful to keep consistency when managing job streams. logmanSmoothPolicy This is an option that affects how the logman command handles statistics and history.x agent in a Tivoli Workload Scheduler network with an 8. In periods of high system activity.2. The CPU time is a measure. The value assigned to this option is read either when the production plan is created or extended or when submitting job streams in production using conman. It sets the weighting factor that favors the most recent job run when calculating the normal (average) run time for a job.

The value assigned to the startOfDay option on the master domain manager is converted to the local time zone set on each workstation across the network. enLegacyStartOfDayEvaluation This option affects the way the startOfDay variable is managed across the Tivoli Workload Scheduler network. yes Refer to“Enabling time zone management” on page 461 for more information about the enTimeZone variable. 68 IBM Tivoli Workload Scheduler: Reference Guide . This option is introduced with Tivoli Workload Scheduler version 8. but the run dates correspond only to the elapsed time values. of the run dates for maximum and minimum CPU times. refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide. For information on how to set options using the optman command-line program. The default setting is both. Enable time zone management. This means that the values assigned to all timezone keywords in the definitions are ignored.3 Fix Pack 01 and it requires the enTimeZone variable set to yes to become operational. The available settings for the enLegacyStartOfDayEvaluation option are: no The value assigned to the startOfDay option on the master domain manager is not converted to the local time zone set on each workstation across the network. in this case. yes Refer to “How Tivoli Workload Scheduler manages time zones” on page 462 for more information about the enLegacyStartOfDayEvaluation variable. This means that the values assigned to the timezone settings are used to calculate the time when the jobs and jobs streams will run on the target workstations. enTimeZone By setting the option you enable or disable the management of time zones across the Tivoli Workload Scheduler network. or less than the existing minimum. The values are updated only if the latest job run has a CPU time greater than the existing maximum.Customizing plan management not include the intervals when the job was waiting. both The elapsed time and CPU time values are updated independently to indicate their maximum and minimum extremes. No record is kept. The available settings for the enTimeZone option are: no Disable time zone management.

the workstation processes are stopped and restarted on all the workstations across the Tivoli Workload Scheduler network. where hhmm identifies the hours and the minutes and tz is the time zone.JnextPlan Generating a production plan . depending on the operating system installed on that machine. Managing the production cycle 69 . including its activation across the Tivoli Workload Scheduler network. Check the IBM Tivoli Workload Scheduler: Administration and Troubleshooting guide for information on specific scenarios that might require JnextPlan customization. v Either root or Administrator. “Understanding workstation processes. refer to Chapter 2. v Any Tivoli Workload Scheduler user authorized in the security file on the master domain manager as follows: file name=prodsked. This flag is used only if a production plan does not already exist.” on page 11. Notes: 1. If the -from argument is not specified the default value is the "today +startOfDay". The new production plan that is generated is immediately activated on the target workstations regardless the time set in the startOfDay variable.Symphony access=build JnextPlan can be run at any time while the production plan is in process to update in the production plan the topology of the Tivoli Workload Scheduler network in terms of workstation. if you created a new workstation definition in the database and you want to add that workstation definition into the plan to later submit jobs or job streams on that workstation you run the command: JnextPlan -for 0000 Note: Make sure the enCarryForward option is set to ALL before running: JnextPlan -for 0000 Syntax JnextPlan [-from mm/dd/[yy]yy[hhmm[tz | timezone tzname]]] {-to mm/dd/[yy]yy[hhmm[tz | timezone tzname]] | -for [h]hhmm [-days n] | -days n} Arguments -from Sets the start time of the production plan. The format of the date is specified in the localopts file. Authorization The JnextPlan command is issued from a command prompt shell on the master domain manager and can be invoked by one of the following users: v The TWS_user user who installed the product on that machine. For example.Generating a production plan . if not disabled by the settings defined in the security file.JnextPlan The entire process of moving from an old to a new production plan. For more information about workstation processes. workstation class and domain object definitions. if not disabled by the settings defined in the security file. is managed by the JnextPlan script. 2. Chapter 5. When you run the JnextPlan script. You can run JnextPlan at any time during the processing day.

MakePlan performs the following actions: 1. The format for the date is the same as that used for the -from argument. The JnextPlan script is composed of the following sequence of commands and specialized scripts. -for. Note: Assuming that the value assigned to startOfDay is 6:00 a. and that the date format set in the localopts file is mm/dd/yyyy. if the values set are -from 05/07/2005 and -to 07/07/2005 then the plan is created to span the time frame from 07/05/2005 at 6:00 to 07/07/2005 at 5:59 and not to 08/07/2005 at 5:59. Windows users. 70 IBM Tivoli Workload Scheduler: Reference Guide . Is the plan extension expressed in time. domains. The -to argument is mutually exclusive with the -for and -days arguments. Prints preproduction reports. The format is hhhmm. Its syntax is: MakePlan [-from mm/dd/[yy]yy[hhmm[tz | timezone tzname]]] {-to mm/dd/[yy]yy[hhmm[tz | timezone tzname]] | -for [h]hhmm [-days n] | -days n} MakePlan invokes internally the planman command line.Generating a production plan .JnextPlan -to Is the production plan end time. If no -to. dependencies) defined in the selected time period. Creates a new plan or extends the current plan and stores the information in an intermediate production plan containing: v All the scheduling objects (jobs. v All dependencies between new instances of jobs and job streams and the jobs and job streams existing in the previous production plan.m. each managing a specific aspect of the production plan generation: | | | conman startappserver This command is invoked to start the WebSphere Application Server if it is not already running. resources. files. or -days arguments are specified then the default production plan length is one day. 2. job streams. calendars. Is the number of days you want to create or extend the production plan for. If you want to run JnextPlan using different connection parameter settings you can edit the MakePlan script and modify the invocation to the planman statement as it is described in “Planman command line” on page 72. The -days parameter is mutually exclusive with the -to parameter. prompts. -for -days n Comments The JnextPlan script is run using the default connection parameters defined in either localopts or useropts files. workstations. The -for argument is mutually exclusive with -to. where hhh are the hours and mm are the minutes. MakePlan This script inherits the flags and the values assigned to them from JnextPlan.

Note: Make sure no conman start command is run while the production plan is been processed. Restarts Tivoli Workload Scheduler processes which distribute the copy of the Symphony file to the workstation targets for running the jobs in plan. UpdateStats This script invokes internally the logman command. 3. Chapter 5.JnextPlan SwitchPlan This script invokes internally the stageman command. 2. Managing the production cycle 71 . Creates a copy of the Symphony file to distribute to the workstations. Stops Tivoli Workload Scheduler processes. Updates the preproduction plan reporting the job stream instance states. SwitchPlan performs the following actions: 1. CreatePostReports This script prints postproduction reports. 2. 5. Archives the old plan file with the current date and time in the schedlog directory. Logs job statistics. 4. 3. Checks the policies and if necessary extends the preproduction plan. For more information refer to “The stageman command” on page 82. For more information refer to “The stageman command” on page 82. UpdateStats performs the following actions: 1.Generating a production plan . Generates the new Symphony file starting from the intermediate production plan created by MakePlan.

planman running on the master domain manager in this case. It is also used to have information about the currently active production plan. proxy_name Is the proxy hostname used in the connection with HTTP protocol. make sure that the character is escaped. For example. user_password Is the password of the user that is used to run planman. trial plans. expressed in seconds. when you specify a password that contains double quotation marks (") or other special characters. port_number Is the port number used when establishing the connection with the master domain manager. the connecting Note: On Windows workstations. protocol_name Is the protocol used during the communication. and the WebSphere Application Server infrastructure using HTTP or HTTPS. connection_parameters Represents the set of parameters that rule the interaction between the product interface. write it as "tws11\"tws". 72 IBM Tivoli Workload Scheduler: Reference Guide . if your password is tws11"tws. or HTTPS with certificate authentication. and to deploy scheduling event rules.Planman command line Planman command line | | | | | The planman command line is used to manage intermediate production plans. to unlock the database entries locked by the plan management processes. The command runs on the master domain manager. It can be HTTP with basic authentication. Use the following syntax when running planman: planman -U planman -V planman [connection_parameters] command where: -U -V Displays command usage information and exit. Displays the command version and exit. and forecast plans. Use this syntax to specify the settings for the connection parameters: [-host hostname] [-port port_number] [-protocol protocol_name] [-proxy proxy_name] [-proxyport proxy_port_number] [-password user_password] [-timeout timeout] [-username username] where: hostname Is the hostname of the master domain manager. proxy_port_number Is the proxy port number used in the connection with HTTP protocol. | | | | | timeout Is the maximum time.

These are the actions you can perform against plans: v “Creating an intermediate production plan” v “Creating an intermediate plan for a plan extension” on page 75 v “Retrieving the production plan information” on page 75 v “Creating a trial plan” on page 76 v “Creating a trial plan of a production plan extension” on page 78 v “Creating a forecast plan” on page 78 v “Unlocking the production plan” on page 80 v “Resetting the production plan” on page 81 | | | | You can also use planman to deploy scheduling event rules. Tivoli Workload Scheduler searches for that value first in the useropts file and then in the localopts file. Refer to “Setting up options for using the user interfaces” on page 29 for information on useropts and localopts files. username Is the username of the user running planman. The result of running this command is the creation of a new intermediate production plan.Planman command line command-line program can wait for the master domain manager response before considering the communication request as failed. If a setting for the parameter is not found an error is displayed. v When generating a production plan after having reset the production plan using the ResetPlan command. named Symnew. The command is explained in: “Deploying rules” on page 79. file name=@ access=build To perform commands against all types of plan.Symphony access=build To perform commands against the production plan. Creating an intermediate production plan The planman with the crt option is invoked from within the JnextPlan command in one of these two situations: v The first time the JnextPlan command is run after having installed the product. command Represents the command you run against plans using the planman interface. covering the whole time the new production plan that is being generated will cover. Refer to the related subsections for additional details on these commands. file name=trialsked access=build To perform commands against the trial and forecast plans. The following syntax is used: planman [connection_parameters] crt [-from mm/dd/[yy]yy [hhmm [tz | timezone tzname]]] Chapter 5. Make sure this username is specified in the security file on the master domain manager with the following authorization: file name=prodsked. If any of these parameters is omitted when invoking planman. Managing the production cycle 73 .

If the -from argument is omitted. For more information refer to “Planman command line” on page 72. Is the number of days you want to create the production plan for.Creating an intermediate production plan {-to mm/dd/[yy]yy[hhmm[tz | timezone tzname]] | -for [h]hhmm [-days n] | -days n} where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. or -days arguments are specified then the default production plan length is one day. This command creates a production plan from 03/21/2005 at 18:05 to 03/24/2005 at 23:00 in the time zone of Europe\Paris: planman crt –from 03/21/2005 1805 tz Europe\Rome –to 03/24/2005 2300 tz Europe\Rome 74 IBM Tivoli Workload Scheduler: Reference Guide . These are some examples of using the planman command assuming the date format set in the localopts file is mm/dd/yyyy: 1. Make sure you run the planman command from within the JnextPlan command. then: v The default date is today. If no -to. -for. v The default hour is the value set in the startOfDay global option using optman on the master domain manager. The -days argument is mutually exclusive with the-to argument. The format is hhhmm. The format for the date is the same as that used for the -from argument. The -to argument is mutually exclusive with the -for and -days arguments. this command creates the production plan from 03/21/2005 at 6:00 to 03/25/2005 at 5:59: planman crt –to 03/25/2005 4. The -for argument is mutually exclusive with -to argument. -from Sets the start time of the new production plan. -for -days n Notes: 1. If today is 03/21/05 and the value set for the startOfDay variable stored in the database is 0600. -to Is the new production plan end time. 2. Is the plan extension expressed in time. This command creates the production plan from 03/21/2005 at 09:00 to 03/21/2005 at 15:00: planman crt –from 03/21/2005 0900 for 0600 3. This command creates the production plan from 03/21/2005 at 23:07 to 03/22/2005 at 23:06 in the local time zone: planman crt –from 03/21/05 2307 2. where hhh are the hours and mm are the minutes. The format used for the date depends on the value assigned to the date format variable specified in the localopts file.

-to -for Sets the end time of the extended production plan. Managing the production cycle 75 . v A production plan. 3. If no -to. already exists. -for. The result of running this command is the creation of a new intermediate production plan. represented by the Symphony file on the master domain manager. When the production plan is extended the numbers associated to prompts already present in the plan are modified. For more information refer to “Planman command line” on page 72. Sets the length of the production plan extension. Retrieving the production plan information The following syntax is used to show information about the current production plan: planman [connection_parameters] showinfo where: Chapter 5. 2. The format is hhhmm. named Symnew. Make sure you run the planman command from within the JnextPlan command. where hhh are the hours and mm are the minutes. -days n Notes: 1. or -days arguments are specified then the production plan is extended by one day. The -for argument is mutually exclusive with the -to argument. The format used for the date depends on the value assigned to the date format variable specified in the localopts file. covering the extra time the new production plan that is being generated will span. The following syntax is used: planman [connection_parameters] ext {-to mm/dd/[yy]yy[hhmm[tz | timezone tzname]] | -for [h]hhmm [-days n] | -days n} where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. The -to argument is mutually exclusive with the -for and -days arguments.Creating an intermediate plan for a plan extension Creating an intermediate plan for a plan extension The planman command with the ext option is invoked from within the JnextPlan command when: v JnextPlan is invoked. The -days argument is mutually exclusive with the-to argument. Sets the number of days you want to extend the production plan for.

v The date and time of the last plan update. Installed for user ’STEFANO03\maestro830’. duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. v The run number. Note: You can install the Tivoli Workload Scheduler Command Line Client feature on fault-tolerant agents and systems outside the Tivoli Workload Scheduler network to issue from those systems the planman showinfo command. v The start time of the production plan.0) Licensed Materials Property of IBM 5698-WKB (C) Copyright IBM Corp 1998. if extended. that is the number of times the plan was successfully generated. v The end time of the preproduction plan. v The end time of the production plan. A sample output of this command is the following: C:\TWS\maestro830>bin\planman showinfo TWS for WINDOWS/PLANMAN 8. The start and end times of the production and preproduction plans are displayed using the format specified in the date format variable set in the localopts file and the time zone of the local machine. after the last plan extension. The output of this command shows: v The installation path.3 (1. that is the total number of times the plan was generated. done either using JnextPlan or planman. v The start time of the first not completed job stream instance.Retrieving the production plan information connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. v The confirm run number. v The duration of the production plan. Locale LANG set to the following: "en" Plan Creation Start Time: 01/03/2006 06:00 TZ CST Production Plan End time: 01/05/2006 05:59 TZ CST Production Plan Time Extention: 048:00 Plan Last Update: 01/03/2006 12:24 TZ CST Pre-Production Plan End Time: 01/19/2006 06:00 TZ CST Start Time of first incomplete JobStream Instance: 01/03/2006 23:00 TZ CST Run Number: 5 Confirm Run Number: 5 C:\TWS\maestro830> Creating a trial plan The following syntax is used to create a trial plan: planman [connection_parameters] crttrial file_name [ -from mm/dd/[yy]yy [hhmm [tz | timezone tzname]]] {-to mm/dd/[yy]yy[hhmm[tz | timezone tzname]] | 76 IBM Tivoli Workload Scheduler: Reference Guide . 2006 US Government User Restricted Rights Use. For more information refer to “Planman command line” on page 72.

or -days arguments are specified then the default trial plan length is one day. where hhh are the hours and mm are the minutes. The -days argument is mutually exclusive with the -to argument. -for.Creating a trial plan -for [h]hhmm [-days n] | -days n} where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. Sets the number of days you want the trial plan to last for. Sets the length of the trial plan. If the -from argument is omitted. then: v The default date is today. If no -to. The -to argument is mutually exclusive with the -for and -days arguments. This means that if the value assigned to file_name is myfile then the file name that contains the generated trial plan is Tmyfile. -to -for Sets the end time of the trial plan. Managing the production cycle 77 . -from -days n Note: The format used for the date depends on the value assigned to the date format variable specified in the localopts file. file_name Assigns a name to the file to be created under the directory TWS_home/schedTrial and that contains the trial plan. The -for argument is mutually exclusive with the -to argument. For more information refer to “Planman command line” on page 72. The format is hhhmm. Chapter 5. Sets the start time of the trial plan. The file name of the file containing the trial plan is Tfilename. v The default hour is the value set in the startOfDay global option using optman on the master domain manager.

The -to argument is mutually exclusive with the -for and -days arguments. For more information refer to “Planman command line” on page 72. or -days arguments are specified then the default production plan extension contained in the trial plan is one day. -for. -to -for -days n Note: The format used for the date depends on the value assigned to the date format variable specified in the localopts file. where hhh are the hours and mm are the minutes. Sets the end time of the trial plan containing the production plan extension. The -for argument is mutually exclusive with the -to argument. Sets the length of the trial plan containing the production plan extension.Creating a trial plan of a production plan extension Creating a trial plan of a production plan extension The following syntax is used to create a trial plan with the extension of the current production plan: planman [connection_parameters] exttrial file_name {-to mm/dd/[yy]yy[hhmm[tz | timezone tzname]] | -for [h]hhmm [-days n] | -days n} where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. The format is hhhmm. Sets the number of days you want the trial plan containing the production plan extension to last for. Creating a forecast plan The following syntax is used to create a forecast plan: planman [connection_parameters] crtfc file_name [ -from mm/dd/[yy]yy [hhmm [tz | timezone tzname]]] {-to mm/dd/[yy]yy[hhmm[tz | timezone tzname]] | -for [h]hhmm [-days n] | -days n} 78 IBM Tivoli Workload Scheduler: Reference Guide . If no -to. This means that if the value assigned to file_name is myfile then the file name that contains the generated trial plan is Tmyfile. The -days argument is mutually exclusive with the -to argument. The file name of the file containing the trial plan is Tfilename. file_name Assigns a name to the file to be created under the directory TWS_home/schedTrial and that contains the trial plan.

The name of the file containing the forecast plan is Ffilename. or in replacement of. The format is hhhmm. or -days arguments are specified then the default forecast plan length is one day. -to -for Sets the end time of the forecast plan. The command operates as follows: 1. 2. The new configuration files update the event rules running on each monitoring engine in terms of: v New rules v Changed rules v Rules deleted or set back to draft state You can use this command in addition to. Chapter 5. This means that if the value assigned to file_name is myfile then the file name that contains the generated forecast plan is Fmyfile. which periodically checks event rule definitions for changes to deploy (see the Planning and Installation guide for details on this option). If no -to. The -to argument is mutually exclusive with the -for and -days arguments. the deploymentFrequency (df) optman configuration option. Builds event rule configuration files. | -days n Note: The format used for the date depends on the value assigned to the date format variable specified in the localopts file. where hhh are the hours and mm are the minutes. Sets the number of days you want the forecast plan to last for. The maximum length of file_name can be 148 characters. The -for argument is mutually exclusive with the -to argument. Managing the production cycle 79 . -from Sets the start time of the forecast plan. -for. 3. file_name Assigns a name to the file to be created under the directory TWS_home/schedForecast and that contains the forecast plan. For more information refer to “Planman command line” on page 72. You can use it to manually deploy all rules that are not in draft state (the isDraft property is set to NO in their definition). | | | | | | | | | | | | | | | | | | Deploying rules The planman deploy command is used in event management. v The default hour is the value set in the startOfDay global option using optman on the master domain manager. If the -from argument is omitted. Deploys the configuration files to the monitoring engines running on the Tivoli Workload Scheduler agents.Creating a forecast plan where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. Selects all event rule definitions not in draft state from the Tivoli Workload Scheduler database. The -days argument is mutually exclusive with the -to argument. Sets the length of the forecast plan. then: v The default date is today.

Only users with build access on the prodsked file object type specified in the security file on the master domain manager are allowed to unlock the database. the event rule environment is reset and the tracked events are lost. the command affects only the rules that have been added. The command may cause the loss of any rule instances in progress at the time you issue it. The command syntax is: planman [connection_parameters] deploy [-scratch] where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. The command used to perform this action is: planman [connection_parameters] unlock where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. Use of this option results in a complete reset of the event processor and should be used with caution. The lock is applied to prevent object definitions from being modified when the production plan in generated or extended. If the processing ends abnormally the database entries might remain locked. 80 IBM Tivoli Workload Scheduler: Reference Guide . deleted. the command deploys all the non-draft rules existing in the database. The typical case is a sequential rule that has been triggered and is waiting for additional events to take place: if you use the option at this time. changed. For more information refer to “Planman command line” on page 72. or set back to draft state . Unlocking the production plan When Tivoli Workload Scheduler starts to create the production plan. you need build access on the prodsked file. it locks the definitions of scheduling objects in the database and then unlocks them either when the creation of the production plan is finished or if an error condition occurs. With this option. To run this command. including the ones that are already in deployment and have not changed.Deploying rules | | | | | | | | | | | | | | | | | | | | | | | The changes applied to the event rule definitions in the database become effective only after deployment has taken place. For more information refer to “Planman command line” on page 72. -scratch Without this option. Note: You can install the Tivoli Workload Scheduler Command Line Client feature on fault-tolerant agents and systems outside the Tivoli Workload Scheduler network to issue from those systems the planman unlock command.

2. This means that the new production plan will contain all job stream instances scheduled to run in the time frame covered by the plan regardless of whether or not they were already in COMPLETE state when the plan was scratched. make sure you run dbreorg and dbrunstats before the JnextPlan script. The preproduction plan is scratched. 3. The difference between resetting and scratching the production plan is the following: v If you reset the production plan. and it is used later to generate a new production plan. 3. Chapter 5. the preproduction plan is scratched too. This means that when you create a new production plan. 4. it is updated with job statistics. The job statistics are updated. Note: If you use the -scratch option. All Tivoli Workload Scheduler processes are stopped on the master domain manager. it will contain all job stream instances which were not in COMPLETE state when you run the ResetPlan. The current Symphony file is archived. All Tivoli Workload Scheduler processes are stopped on the master domain manager. the preproduction plan is kept. v If you scratch the production plan. For more information refer to “Planman command line” on page 72. The steps performed by the product when scratching the production plan are the following: 1. Managing the production cycle 81 . The job statistics are updated. The current Symphony file is archived. The steps performed by the product when resetting the production plan are the following: 1. The preproduction plan will be created again based on the modeling information stored in the database when you later generate a new production plan.Resetting the production plan Resetting the production plan The following script is used to either reset or scratch the production plan: ResetPlan [connection_parameters] [-scratch] where: connection_parameters Defines the settings to use when establishing the connection using HTTP or HTTPS through WebSphere Application Server to the master domain manager. 2.

is sent to domain managers and agents as part of the initialization process for the new production plan. Carries forward only the uncompleted job streams whose definition contains the keyword carryforward. If you omit this keyword. Carries forward all uncompleted job streams. A copy of Symphony. and installs the new production plan. minutes the old production plan is archived. Syntax stageman -v | -U stageman [-carryforward{yes|no|all}] [-log log_file| -nolog] [symnew] Arguments -v -U Displays the command version and exits. Refer to “Understanding carry forward options” on page 61 to have information on the resulting carry forward setting when both the enCarryForward global option and the -carryforward keywords are set. stageman is invoked from within the SwitchPlan script. 82 IBM Tivoli Workload Scheduler: Reference Guide . Note: Be sure to monitor the disk space in the schedlog directory and remove older log files on a regular basis. You must have build access to the Symphony file to run stageman. day. The archived production plans can then be listed and selected using the commands “listsym” on page 297 and “setsym” on page 311. -log Archives the old production plan in the directory TWS_home/schedlog with file name log_file. The available settings are: no yes all Does not carry forward any job streams. Displays command usage information and exits. regardless whether or not contain the keyword carryforward in the job stream definition.stageman The stageman command The stageman command carries forward uncompleted job streams. by default it is set to the value specified globally using optman for the enCarryForward option. Tivoli Workload Scheduler archives the old production plan using the following naming convention: Myyyymmddhhtt where yyyymmddhhtt corresponds to the year. hour. -carryforward Defines how uncompleted job streams are managed when moving to a new production plan. If you generate the production plan using JnextPlan you can customize this naming convention in the SwitchPlan script. When running JnextPlan. archives the old production plan. month. If neither -log nor -nolog keywords are specified.

Note: In UNIX only. Run the following command: conman "link @" before running stageman. the master domain manager’s production plan file. stageman also determines which executable files associated to jobs submitted using the at and batch utility commands can be deleted when Tivoli Workload Scheduler is started for the new production period. Comments To allow carry forward procedures to work properly in a network. do not log the old Symphony file.msg file are sent back to the master domain manager to update the Symphony file. stageman uses the file name Symnew. log the old Symphony file. Managing the production cycle 83 . must be updated with the latest job stream status from its agents and subordinate domain managers. Examples Carry forward all uncompleted job streams (regardless of the status of the Carry Forward option). and create an intermediate production plan named mysym: stageman -nolog mysym Chapter 5. and create the new Symphony file: DATE=’datecalc today pic YYYYMMDDHHTT’ stageman -carryforward all -log schedlog/M$DATE Carry forward uncompleted job streams as defined by the carryforward global option. Symphony. If not specified. symnew The name assigned to the intermediate production plan file created by planman.stageman -nolog Does not archive the old production plan. These jobs are not carried forward. This command links any unlinked workstations so that messages about job processing status queued in the Mailbox.

The dependency is not satisfied.Managing concurrent accesses to Symphony Managing concurrent accesses to the Symphony file This section contains two sample scenarios describing how Tivoli Workload Scheduler manages possible concurrent accesses to the Symphony file when running stageman. Schedule mm/dd/yyyy (nnnn) on cpu. ASKED The prompt has been issued. stop Tivoli Workload Scheduler and rerun stageman. and is awaiting a reply. Managing follows dependencies using carry forward prompt To retain continuity when carrying forward job streams. The possible states are: INACT The prompt has not been issued and the dependency is not satisfied. Either a ″yes″ reply was received. To continue. Scenario 2: Access to Symphony file locked by stageman If you try to access the plan using the command-line interface while the Symphony is being switched. or it was determined before carry forward occurred that the followed job stream SKED3 had not completed successfully. The dependency is satisfied. The following is an example of a carry forward prompt: INACT 1(SYS2#SKED2[(0600 01/11/06). Symphony switched. NO Either a ″no″ reply was received. These prompts are issued after the new processing period begins. The dependency is not satisfied. Switching to new Symphony. For information on the syntax used to indicate the carried forward job stream refer to “Selecting job streams in commands” on page 257. you must rerun both planman and stageman. Shutdown batchman and mailman. The state of the prompt. the following message is displayed: Unable to get exclusive access to Symphony. YES 84 IBM Tivoli Workload Scheduler: Reference Guide . when Tivoli Workload Scheduler checks to see if the job or job stream is ready to launch. Scenario 1: Access to Symphony file locked by other Tivoli Workload Scheduler processes If Tivoli Workload Scheduler processes are still active and accessing the Symphony file when stageman is run. or it was determined before carry forward occurred that the followed job stream SKED3 had completed successfully. you get the following message: Current Symphony file is old. INACT in this case. If stageman aborts for any reason. and are replied to as standard prompts. which is carried forward from the previous production plan.(0AAAAAAAAAAAAA2Y)]) follows SYS1#SKED1. defines the state of the corresponding follows dependency. stageman generates prompts for each job stream that is carried forwarded and has a follows dependency on another job stream which is not carried forward. (SYS2#SKED2[(0600 01/11/06). has a follows dependency from a job stream named SYS1#SKED1 which was not carried forward.(0AAAAAAAAAAAAA2Y)]). satisfied? This prompt indicates that a job stream.

Displays the command version and exits. port_number Is the port number used when establishing the connection with the master domain manager. proxy_name Is the proxy hostname used in the connection. Use this syntax to specify the settings for the connection parameters: [-host hostname] [-port port_number] [-protocol protocol_name] [-proxy proxy_name] [-proxyport proxy_port_number] [-password user_password] [-timeout timeout] [-username username] where: hostname Is the hostname of the master domain manager. | | | | | timeout Is the maximum time. and the WebSphere Application Server infrastructure using HTTP or HTTPS. or HTTPS with certificate authentication. Managing the production cycle Note: On Windows workstations. write it as "tws11\"tws".logman The logman command The logman command logs job statistics from a production plan log file. Syntax logman -v|-u logman [connection_parameters] [-prod symphony-file] [-minmax setting] [-smooth weighting] Arguments -u -v Displays command usage information and exits. when you specify a password that contains double quotation marks (") or other special characters. expressed in seconds. the connecting Chapter 5. user_password Is the password of the user that is used to run logman. protocol_name Is the protocol used during the communication. It can be HTTP with basic authentication. make sure that the character is escaped. For example. connection_parameters Represents the set of parameters that control the interaction between the product interface. logman running on the master domain manager in this case. 85 . proxy_port_number Is the proxy port number used in the connection. if your password is tws11"tws.

symphony-file The name of an archived symphony file from which job statistics are extracted. Comments Jobs that have already been logged. When the logman command is run by JnextPlan. the setting used is the one specified in the logmanMinMaxPolicy global option. username Is the username of the user running logman. Refer to “Setting up options for using the user interfaces” on page 29 for information on useropts and localopts files. job streams already completed in the previous production period. the setting used is the one specified in the logmanSmoothPolicy global option. If any of these parameters is omitted when invoking logman. Examples Log job statistics from the log file M199903170935: logman schedlog/M199903170935 86 IBM Tivoli Workload Scheduler: Reference Guide . and 60% to the existing average.logman command-line program can wait for the master domain manager response before considering the communication request as failed. This is expressed as a percentage. This setting is used when the logman command is run from the command line and not by the JnextPlan script. -prod Updates the preproduction plan with the information on the job streams in COMPLETE state in production. Base the minimum and maximum run times on CPU time. -smooth weighting Uses a weighting factor that favors the most recent job run when calculating the normal (average) run time for a job. The available settings are: elapsed cpu Base the minimum and maximum run times on elapsed time. This avoids the possibility of the new production plan running again. By doing so the preproduction plan is kept up-to-date with the latest processing information. If a setting for the parameter is not found an error is displayed. -smooth 40 applies a weighting factor of 40% to the most recent job run. When the logman command is run by JnextPlan. -minmax setting Defines how the minimum and maximum job run times are logged and reported. cannot be logged again. The default is 0%. For example. Attempting to do so generates a 0 jobs logged error message. Tivoli Workload Scheduler searches for a value first in the useropts file and then in the localopts file. This setting is used when the logman command is run from the command line and not by the JnextPlan script.

for example. You can use either this Sfinal file or create and customize a new one. A copy of this job stream is in the Sfinal file in the TWS_home/config/Sfinal directory. The processing day will start at the time specified on the master domain manager in the variable startOfDay. then run the JnextPlan job by entering./TWS_home/tws_env. The final job stream runs the sequence of script files described in JnextPlan to generate the new production plan. A copy of the job script is in the TWS_home/JnextPlan directory. At a command prompt. 2. The default job limit after installation is zero.m. See “Generating a production plan . These are the details about the two steps you need to follow to do this.cmd in Windows to set up the environment. Tivoli Workload Scheduler includes a sample job stream named final that helps you automate plan management. . Log in as TWS_user on the master domain manager. to make the final job stream run every three days: Chapter 5. This means no jobs will run. 3. for example on a UNIX workstation. As soon as the ongoing activities complete. check the status of Tivoli Workload Scheduler: conman status If the Tivoli Workload Scheduler started correctly. for example every week. Managing the production cycle 87 . After the interval defined in the mm retry link parameter set in the TWS_home/localopts configuration file elapses.sh -from 05/03/06 0400 -to 06/06/06 This creates a new production plan that starts on the third of May 2006 at 4:00 a. the following command: JnextPlan. Increase the limit to allow jobs to run. This happens because the workstation needs to complete any ongoing activities involving the mailman process before re-initializing. refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide.10" Automating production plan processing If you want to extend your production plan at a fixed time interval. the status is Batchman=LIVES If mailman is still running a process on the remote workstation. follow these steps: 1.sh in UNIX or TWS_home\tws_env. the activities for the next day are initialized. This section explains how you can do this. You can modify the time it runs by modifying two settings in the final job stream definition. 4.m. conman "limit. For information about the localopts configuration file. run the script command .Starting production plan processing Starting production plan processing To start a production cycle.JnextPlan” on page 69 for reference. you might see that the remote workstation does not initialize immediately. the domain manager tries again to initialize the workstation. and stops on the sixth of June 2006 at 3:59 a. the final job stream is set to run once a day. By default. you have the option to automate the extension. When the JnextPlan job completes.

. 4.csh v UNIX: on Korn shells launch . use its name in place of Sfinal. Note: Even if you decided to automate the production plan extension you can still run JnextPlan at any time. Run the tws_env script to set the Tivoli Workload Scheduler environment as follows: v UNIX: on C shells launch . In this way the final job stream will be included in the current production plan. v In the statement that invokes MakePlan inside the final job stream./TWS_home/tws_env. 2. 3. .sh v From a Windows command line: launch TWS_home\tws_env. 88 IBM Tivoli Workload Scheduler: Reference Guide . Start the production cycle by running the JnextPlan script. 5. Log in as TWS_user.cmd where TWS_home represents the product installation directory. Add the final job stream definition to the database by running the following command: composer add Sfinal If you did not use the Sfinal file provided with the product but you created a new one.Automating production plan processing v Modify the run cycle by setting inside the final job stream definition to schedule the job stream to run every three days. set the production plan to last for three days by specifying -for 72./TWS_home/tws_env. Then you need to add the final job stream to the database by performing the following steps: 1. Run the composer command.

Running event-driven workload automation Event-driven workload automation adds the capability to perform on-demand workload automation in addition to plan-based job scheduling. External events They are events not directly involving Tivoli Workload Scheduler that may nonetheless impact workload submission. 2007 89 . you can specify validity dates. you specify one or more events. and a common time zone for all the time restrictions that are set. It provides the capability to define rules that can trigger on-demand workload automation. Moreover. The correlation attributes provide a way to direct the rule to create a separate rule (or copy of itself) for each group of events that share common characteristics. However. or a file being created.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Chapter 6. Events of this category can be job or job stream status changes. The events that Tivoli Workload Scheduler can detect for action triggering can be: Internal events They are events involving Tivoli Workload Scheduler internal application status and changes in the status of Tivoli Workload Scheduler objects. which are often related to different groups of © Copyright IBM Corp. This implies the capability to submit workload and run commands on the fly. Within a rule two or more events can be correlated through correlation attributes such as a common workstation or job. events sent by third party applications. a correlation rule. The object of event-driven workload automation in Tivoli Workload Scheduler is to carry out a predefined set of actions in response to events that occur on nodes running Tivoli Workload Scheduler (but also on non-Tivoli Workload Scheduler ones. or deleted. or send messages to Tivoli Enterprise Console. when you use the sendevt command line). Typically. sometimes the same rule is needed for different groups of events. each active rule has one copy that is running in the event processing server. updated. v Reply to prompts v Notify users when anomalous conditions occur in the Tivoli Workload Scheduler scheduling environment or batch scheduling activity. notify users via e-mail. and workstation status changes. In Tivoli Workload Scheduler an event rule is a scheduling object that includes the following items: v Events v Event-correlating conditions v Actions When you define an event rule. 1999. a daily time interval of activity. v Invoke an external product when a particular event condition occurs. The main tasks of event-driven workload automation are: v Trigger the execution of batch jobs and job streams based on the reception or combination of real time events. Event-driven workload automation is based upon the concept of event rule. and the one or more actions that are triggered by those events. critical jobs or job streams being late or canceled. Events of this category can be messages written in log files.

The administrator defines the following event rule: v If workstation CPU1 becomes unlinked and does not link back within 10 minutes. Simple event rule scenarios Scenario 1: Send e-mail notification 1.com. Scenario 2: Monitor that workstation links back 1. Table 11. If the CPU1 linked event is not received within 10 minutes. logging the event in an internal auditing database. The actions that Tivoli Workload Scheduler can run when it detects any of these events can be: Operational actions They are actions that cause the change in the status of scheduling objects. or running a non-Tivoli Workload Scheduler command. Rick Jones receives the e-mail. 90 IBM Tivoli Workload Scheduler: Reference Guide . The scheduler starts monitoring CPU1. If the workstation status becomes unlinked. Notification actions They are actions that have no impact on the status of scheduling objects. send a notification e-mail to chuck. John Smith is sent an e-mail so that he can check the job and take corrective action. Using one or more correlation attributes is a method for directing a rule to create a separate rule copy for each group of events with common characteristics. and from there navigates to the CPU1 instance and runs a first problem analysis. Tivoli Workload Scheduler starts the 10 minute timeout. 3. or command. the scheduler sends the notification e-mail to Chuck Derry. 2.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | resources. The event rule is valid from December 1st to December 31st in the 12:00-16:00 EST time window. It has no impact on how they are handled by the event-driving mechanism. 3. Table 11 lists some simple scenarios involving the use of event rules. forwarding the event to Tivoli Enterprise Console. The administrator defines the following event rule: v When any of the job123@ jobs terminates in error. Actions of this category are submitting a job. job stream. The subject of the e-mail includes the names of the job instance and of the associated workstation. queries the actions/rules that were triggered in the last 10 minutes. The administrator saves the rule as non-draft in the database and it is readily deployed by Tivoli Workload Scheduler. The administrator saves the rule as non-draft in the database and it is readily deployed by Tivoli Workload Scheduler. 2. The corresponding XML coding is shown in Table 15 on page 98. send an e-mail to operator john.com. or replying to a prompt. This classification of events and actions is conceptual.smith@mycorp. Actions belonging to this category are sending an e-mail. The scheduler starts monitoring the jobs and every time one of them ends in error.derry@mycorp. 4.

Chapter 6. 3. Scenario 4: Start long duration jobs based on timeout 1. Simple event rule scenarios (continued) Scenario 3: Submit job stream when FTP has completed 1. 2. Tivoli Workload Scheduler must: a. the administrator sets the event rule in draft status. Tivoli Workload Scheduler sends the e-mail.com alerting that the job is late. it submits job stream calmonthlyrev. Scenario 5: Integration with SAP R/3 (in combination with Tivoli Workload Scheduler for Applications) 1. The rule is deployed. Every time the status of job-x becomes exec. It can be deployed again when needed. submit the calmonthlyrev job stream.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 11. Tivoli Workload Scheduler starts monitoring the status of SAP R/3 events activated on the Billing system. After a few days he edits the rule. The operator can check the logs to find if the event rule or the job stream were run. The administrator defines the following event rule: v When an event called ID3965 is generated on SAP R/3 server Billing. otherwise it should send an e-mail to twsoper@mycompany. The administrator defines the following event rule: v When the job-x=exec event and the job-x=succ/abend event are received in 5 minutes. The scheduler starts monitoring the SFoperation directory. 2. the scheduler should reply Yes to prompt-1 and start the jobstream-z job stream. Tivoli Workload Scheduler runs the specified help desk command and sends an event to TEC. The administrator saves the rule as non-draft in the database and it is readily deployed by Tivoli Workload Scheduler. 4. changes the e-mail recipient and saves it as non-draft. 3. As soon as file daytransac* is created and is no longer in use. Tivoli Workload Scheduler starts the 5 minutes timeout. Run the command: “/usr/apps/helpDesk –openTicket –text ‘Processing error $parameter on SAP system $wsname’” to open a service desk ticket b. and modifications to the file have terminated. Send an event to Tivoli Enterprise Console. otherwise it replies Yes to the prompt and submits jobstream-z. When the ID3965 event is detected. 3. The administrator saves the rule as non-draft and it is readily deployed. The event rule is valid year-round in the 18:00-22:00 EST time window. Running event-driven workload automation 91 . The rule is automatically deactivated. If the internal state of job-x does not change to succ or abend within 5 minutes and the corresponding event is not received. The administrator saves the event rule in draft status. After some time. 2. The administrator defines the following event rule: v When file daytransac* is created in the SFoperation directory in workstation system1. 4.

This command can be used remotely to get the information of the configuration file in another agent of the network Starts monman on an agent. 6. All new and modified non-draft rules saved in the database are periodically (by default every five minutes) found. Rule definitions can be saved as draft or non-draft. subsystems. 8. Can be issued from a different agent. and internal mechanisms. and deployed by an internal process named rule builder. which is normally located in the master domain manager. 5. Meanwhile. The event-driven workload automation feature is automatically installed with the product. Each Tivoli Workload Scheduler agent runs a component named monman that manages two services named monitoring engine and ssmagent that are to catch the events occurring on the agent and perform a preliminary filtering action on them. The following ones are significant because they can be managed: monman Is installed on every Tivoli Workload Scheduler agent where it checks for all local events. It is an optional command since the configuration is normally deployed automatically. 7. At this time they become active. built. Event-driven workload automation is based on a number of services. All detected events are forwarded to the event processing server. The administrator or the operator reviews the status of event rule instances and actions in the database and logs. An event rule definition is created or modified with the Tivoli Dynamic Workload Console or with the composer command line and saved in the objects database. receives all events from the agents and processes them. 2. 4. an event processing server. Returns the list of event rules defined for the monitor running on an agent.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The event rule management process Event-driven workload automation is an ongoing process and can be reduced to the following steps: 1. The updated monitoring configurations are downloaded to the Tivoli Workload Scheduler agents and activated. 3. You can at any time change the value of the enEventDrivenWorkloadAutomation global option if you do not want to use it in your Tivoli Workload Scheduler network. The event processing server receives the events and checks if they match any deployed event rule. Each monman detects and sends its events to the event processing server. The following conman commands are available to manage monman: Table 12. showcpus getmon startmon 92 IBM Tivoli Workload Scheduler: Reference Guide . If an event rule is matched. conman commands for managing monitoring engines Command deployconf Purpose Updates the monitoring configuration file for the event monitoring engine on an agent. The action helper creates an event rule instance and logs the outcome of the action in the database. the event processing server calls an actions helper to carry out the actions.

Note that there might be some transitory situations while deployment is under course. if a rule is pending deactivation. Event processing server Can be installed on the master domain manager. For example. Table 14 summarizes the ones you need: Chapter 6. monman starts up automatically each time a new Symphony is activated (on Windows also when Tivoli Workload Scheduler is restarted). and notifies the agents to download the new configurations. the agents might be sending events in the time fraction that the new configuration files have not been deployed yet. The following conman commands are available to manage the event processing server: Table 13. Following each rule deployment cycle. creates configuration files for the agents. conman commands for managing the event processing server Command starteventprocessor stopeventprocessor switcheventprocessor Purpose Starts the event processing server Stops the event processing server Switches the event processing server from the master domain manager to the backup master or vice versa The event processing server starts up automatically with the master domain manager. It can be active on only one node in the network. Using the involved interfaces and commands Running and managing event-driven workload automation calls for the following tasks: v Edit configuration settings v Model event rules v Manually deploy or undeploy event rules v Manage monitoring and event processing devices v Monitor and manage event rule instances You must be ready to utilize several Tivoli Workload Scheduler interfaces and commands to do them. Can be issued from a different agent.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 12. conman commands for managing monitoring engines (continued) Command stopmon Purpose Stops monman on an agent. It receives and correlates the events sent by the monitoring engines and runs the actions. the backup master. but the event processor already discards them. or on any fault-tolerant agent installed as a backup master. It builds the rules. This is determined by the autostart monman local option that is set to yes by default (and that you can disable if you do not want to monitor events on a particular agent). updated monitoring configurations are automatically distributed to the agents hosting rules that have been changed since the last deployment. Running event-driven workload automation 93 . It runs in the embedded application server.

print. event.” on page 189 for command reference. smtpServerPort. Modified definitions are deployed in the Tivoli Workload Scheduler domain v The EIF port number where the event processing server receives events (eventProcessorEIFPort). and action properties – jobs and job streams involved with the rule action v event rule instances. action run. actions run. delete. Change the default values of global options associated with event management. display. v Tivoli Enterprise Console server properties if you deploy rules implementing actions that forward events to TEC (TECServerName. list. and message log records See “Event rule definition” on page 178 to learn how to define event rules. v The possibility to disable the event rule management mechanism (enEventDrivenWorkloadAutomation) which is installed by default with the product. Interfaces and commands for managing event-driven workload automation Interface or command optman Use to. composer Run modeling and management tasks of event rule definitions like add. Query the Tivoli Workload Scheduler relational database for: v event rule definitions filtered by: – rule. and message log data (logCleanupFrequency). Global options are used to configure: v The frequency with which rule definitions are checked for updates (deploymentFrequency). TECServerPort). unlock. Event rules are defined in XML. modify.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 14. See Chapter 8. 94 IBM Tivoli Workload Scheduler: Reference Guide . v Management of the cleanup policies of rule instance. new. smtpUserName. See the Planning and Installation guide for a list of global options. extract. “Managing objects in the database . smtpUseAuthentication. smtpUseTLS ). validate. v SMTP server properties if you deploy rules implementing actions that send e-mails via an SMTP server (smtpServerName. smtpUserPassword.composer... lock. smtpUseSSL. create.

modify. actions. The explanation of how you use composer to define event rules is in “Event rule definition” on page 178. create.” on page 243 for command reference.. See “Deploying rules” on page 79 for details.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 14. actions run. Have a graphical user interface to: v Model and manage event rule definitions (browse. See “evtdef” on page 385 and “sendevent” on page 405 for details on these commands. and their instances.. See Chapter 9. See “Configuring the security file” on page 36 for reference. delete. conman Manage the monitoring devices.rule. Interfaces and commands for managing event-driven workload automation (continued) Interface or command Tivoli Dynamic Workload Console Use to. as described in tables 12 and 13 See the Tivoli Dynamic Workload Console online documentation. query. you specify one or more events. and action properties . You can save them as: Draft The rule is saved in the database but is not ready yet to be deployed and activated. as described in tables 12 and 13. Event rule definitions are saved in the Tivoli Workload Scheduler database like all other scheduling objects.conman. “Managing objects in the plan . and message log records v Manage the event processing server and monitoring engines. while the explanation of how you use the Tivoli Dynamic Workload Console can be found in its online help. To define event rules you can use: v The composer command line v The Tivoli Dynamic Workload Console v A set of APIs described in a separate document In composer. a correlation rule. namely the event processing server and monitoring engines.jobs and job streams involved with the rule action – event rule instances. Chapter 6. planman Defining event rules When you define an event rule. Running event-driven workload automation 95 . and one or more actions. you edit the rules with an XML editor of your choice (preferable but not mandatory) since event rule definitions are made using XML syntax. unlock) v Query the Tivoli Workload Scheduler relational database for: – event rule definitions filtered by: . utility commands Create custom event definitions and manually send custom events to the event processing server. events. event. Security file Set security authorizations to manage event rules. Manually deploy new and changed rules.

sequence The rule is activated when an ordered group of events is detected or fails to complete within a specific time interval. a Tivoli Workload Scheduler workstation going down. Based on their characteristics. As an additional feature. Set and sequence rules are based on the detection of more events. This state is determined by the isDraft=no attribute. set The rule is activated when an unordered group of events is detected or fails to complete within a specific time interval. You can deploy and undeploy rules as you need by setting the isDraft attribute to no or to yes with composer or with the Tivoli Dynamic Workload Console. A rule times out when the first event(s) in a sequence or part of the events in a set are received. but not all the events are received within a specified time interval counted from when the first event was received. a job stream completing its run successfully. Filter rules are based on the detection of one event such as a job being late. Non-draft rules are ready to be activated. Rule definitions may include attributes that specify a validity period and an activity time window within each day of validity. Optionally.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This state is determined by the isDraft=yes attribute. the rule is active perpetually at all times once it is deployed and until it is changed back to draft status or deleted from the database. 96 IBM Tivoli Workload Scheduler: Reference Guide . a planman deploy command is available to deploy rules manually at any time. rules are classified as: filter The rule is activated upon the detection of a single specific event. If you do not specify these attributes. The new monitoring configurations are downloaded to the agents (each agent gets its own configuration file containing strictly the rules it is to run) only if there have been changes since the previous configuration files. The rule builder calculates the status of each rule. they can be based on a time out condition. a file being modified. The status can be: v active v not active v update pending v update error v activation pending v activation error v deactivation pending v deactivation error The scheduler periodically (every five minutes or in accordance with a time set in the deploymentFrequency global configuration option) scans the database for non-draft rules and builds rule configuration files for deployment. and so on. Not draft This rule is being deployed or is ready to be deployed in the scheduling environment.

Note that you can use variable substitution also if no attributeFilter was specified for an attribute and also if the attribute is read-only. Event rule examples The following tables describe the event rule definitions that apply to the scenarios described in table 11. property Is the attributeFilter name in the filtering predicate of the triggering event condition. You can see the use of variable substitution in some of the following sample definitions. This means that when you define action parameters. for example to format the schedTime of a job stream in the body of an e-mail. you can use attributes of occurrences of events that trigger the event rule in either of these two forms: v ${event. This is useful to pass the information to an action that works programmatically with that information. where attribute filter values are replaced in e-mail subject and body matters. The value taken by the attribute filter when the rule is triggered is replaced as a parameter value in the action definition before it is performed. for example the schedTime of a job stream.property} Replaces the value as is. This is useful to pass the information to an action that forwards that information to a user. Chapter 6. v %{event.| | | | | | | | | | | | | | | | | | | | | | | | | | You can use variable substitution.property} Replaces the value formatted in human readable format. Where: event Is the name you set for the triggering eventCondition. Running event-driven workload automation 97 .

com/xmlns/prod/tws/1.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 15.smith@mycorp.smith@mycorp.ibm.JobName} on agent ${event1. The subject of the e-mail includes the names of the job instance and of the associated workstation.0" encoding="UTF-8"?> <eventRuleSet xmlns:xsi="http://www.xsd"> <eventRule name="scenario1_rule" ruleType="filter" isDraft="no"> <description>This is the definition for scenario1</description> <timeZone>America/Indianapolis</timeZone> <validity from="2007-12-01" to="2007-12-31" /> <activeTime start="12:00:00" end="16:00:00" /> <eventCondition name="event1" eventProvider="TWSObjectsMonitor" eventType="JobStatusChanged"> <filteringPredicate> <attributeFilter name="JobName" operator="eq"> <value>job123@</value> </attributeFilter> <attributeFilter name="Status" operator="eq"> <value>Error</value> </attributeFilter> </filteringPredicate> </eventCondition> <action actionProvider="MailSender" actionType="SendMail" responseType="onDetection"> <description>Send email to John Smith including names of job and associated workstation </description> <parameter name="To"> <value>john.Workstation} ended in error</value> </parameter> </action> </eventRule> </eventRuleSet> 98 IBM Tivoli Workload Scheduler: Reference Guide . Event rule definition for scenario1 When any of the job123@ jobs terminates in error.ibm.w3.com</value> </parameter> <parameter name="Subject"> <value>Job ${event1. The event rule is valid from December 1st to December 31st in the 12:00-16:00 EST time window.0/event-management/rules EventRules.com. send an e-mail to operator john.com/xmlns/prod/tws/1.0/event-management/rules" xsi:schemaLocation="http://www.org/2001/XMLSchema-instance" xmlns="http://www. <?xml version="1.

w3.0" encoding="UTF-8"?> <eventRuleSet xmlns:xsi="http://www.derry@mycorp.com/xmlns/prod/tws/1.com.com/xmlns/prod/tws/1.UnlinkReason}</value> </parameter> </action> </eventRule> </eventRuleSet> Chapter 6.ibm.ibm. send a notification e-mail to rick. Running event-driven workload automation 99 .xsd"> <eventRule name="scenario2_rule" ruleType="filter" isDraft="no"> <description>This is the definition for scenario2</description> <timeZone>America/Anchorage</timeZone> <timeInterval amount="10" unit="minutes" /> <eventCondition name="WSevent" eventProvider="TWSObjectsMonitor" eventType="ChildWorkstationLinkChanged"> <filteringPredicate> <attributeFilter name="Workstation" operator="eq"> <value>CPU1</value> </attributeFilter> <attributeFilter name="LinkStatus" operator="eq"> <value>Unlinked</value> </attributeFilter> </filteringPredicate> </eventCondition> <action actionProvider="MailSender" actionType="SendMail" responseType="onTimeOut"> <description>Send email to Chuck Derry with name of unlinked workstation </description> <parameter name="To"> <value>chuck.org/2001/XMLSchema-instance" xmlns="http://www.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 16. <?xml version="1.jones@mycorp.0/event-management/rules" xsi:schemaLocation="http://www. Event rule definition for scenario2 If workstation CPU1 becomes unlinked and does not link back within 10 minutes.0/event-management/rules EventRules.com</value> </parameter> <parameter name="Subject"> <value>Agent CPU1 has been unlinked for at least 10 minutes</value> </parameter> <parameter name="Body"> <value>The cause seems to be: ${WSevent.

com/xmlns/prod/tws/1.xsd"> <eventRule name="scenario3_rule" ruleType="filter" isDraft="no"> <description>This is the definition for scenario3</description> <timeZone>America/Louisville</timeZone> <validity from="2007-01-01" to="2007-12-31" /> <activeTime start="18:00:00" end="22:00:00" /> <eventCondition eventProvider="FileMonitor" eventType="ModificationCompleted"> <filteringPredicate> <attributeFilter name="FileName" operator="eq"> <value>daytransac*</value> </attributeFilter> </filteringPredicate> </eventCondition> <action actionProvider="TWSAction" actionType="SubmitJobStream" responseType="onDetection"> <description>Submit the calmonthlyrev job stream.ibm.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 17.0/event-management/rules" xsi:schemaLocation="http://www. The event rule is valid year-round in the 18:00-22:00 EST time window.w3. submit the calmonthlyrev job stream.org/2001/XMLSchema-instance" xmlns="http://www.0/event-management/rules EventRules. and modifications to the file have terminated. Event rule definition for scenario3 When file daytransac* is created in the SFoperation directory in workstation system1. <?xml version="1.com/xmlns/prod/tws/1.0" encoding="UTF-8"?> <eventRuleSet xmlns:xsi="http://www.ibm.</description> <parameter name="JobStreamName"> <value>calmonthlyrev</value> </parameter> <parameter name="JobStreamWorkstationName"> <value>act5cpu</value> </parameter> <parameter name="priority"> <value>high</value> </parameter> </action> </eventRule> </eventRuleSet> 100 IBM Tivoli Workload Scheduler: Reference Guide .

0/event-management/rules" xsi:schemaLocation="http://www. Running event-driven workload automation 101 . Save as draft. otherwise it should send an e-mail to twsoper@mycompany.w3.com alerting that the job is late.com</value> </parameter> <parameter name="Subject"> <value>Job-x is late by at least 5 minutes</value> </action> <action actionProvider="TWSAction" actionType="ReplyPrompt" responseType="onDetection"> <description>Reply Yes to prompt-1</description> <parameter name="PromptName"> <value>prompt-1</value> </parameter> <parameter name="PromptAnswer"> <value>Yes</value> </parameter> </action> <action actionProvider="TWSAction" actionType="SubmitJobStream" responseType="onDetection"> <description>Submit jobstream-z</description> <parameter name="JobStreamName"> <value>jobstream-z</value> </parameter> <parameter name="JobStreamWorkstationName"> <value>act23cpu</value> </parameter> </action> </eventRule> </eventRuleSet> Chapter 6.com/xmlns/prod/tws/1.ibm.xsd"> <eventRule name="scenario4_rule" ruleType="sequence" isDraft="yes"> <description>This is the definition for scenario2</description> <timeZone>America/Buenos_Aires</timeZone> <timeInterval amount="5" unit="minutes" /> <eventCondition eventProvider="TWSObjectsMonitor" eventType="JobStatusChanged"> <filteringPredicate> <attributeFilter name="JobName" operator="eq"> <value>job-x</value> </attributeFilter> <attributeFilter name="InternalStatus" operator="eq"> <value>Exec</value> </attributeFilter> </filteringPredicate> </eventCondition> <eventCondition eventProvider="TWSObjectsMonitor" eventType="JobStatusChanged"> <filteringPredicate> <attributeFilter name="JobName" operator="eq"> <value>job-x</value> </attributeFilter> <attributeFilter name="InternalStatus" operator="eq"> <value>Abend</value> <value>Succ</value> </attributeFilter> </filteringPredicate> </eventCondition> <action actionProvider="MailSender" actionType="SendMail" responseType="onTimeOut"> <description>Send email to operator saying that job-x is late</description> <parameter name="To"> <value>twsoper@mycorp. the scheduler should reply Yes to prompt-1 and start the jobstream-z job stream. Event rule definition for scenario4 When the job-x=exec event and the job-x=succ/abend event are received in 5 minutes.org/2001/XMLSchema-instance" xmlns="http://www.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 18.0" encoding="UTF-8"?> <eventRuleSet xmlns:xsi="http://www.0/event-management/rules EventRules. <?xml version="1.ibm.com/xmlns/prod/tws/1.

the rule is completed and resets. Typically. You define a sequence rule with two events. it activates the rule and waits for the second event (event B). A and B. waiting for event A to occur again. Rule operation notes Topic Lack of persistence in rule instance status Note If the event processor is stopped or crashes. copy that runs in the event processing server. Using one or more correlation attributes is a method for directing a rule to create a separate rule copy when another event A arrives. 2. any additional event A events that may arrive are ignored. Once event B occurs. Repeating set and sequence rules 102 IBM Tivoli Workload Scheduler: Reference Guide . the status of rule instances that are only partially matched is lost. and only one. The mechanism of set and sequence rules is such that any additional occurrences of an already detected event are ignored and discarded if the other defined events have not arrived. Once the rule is active.Set and sequence rules use the mechanism explained in the following example: 1. 3. each active rule has one.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rule operation notes The following table contains critical information on event rule behavior that might help you understand the reason for unexpected results: Table 19. You can prevent this problem by using correlation attributes. No additional rules are created for any newly detected event A events as long as the rule is waiting for event B. When the first event that matches the sequence occurs (event A).

that were run as a result of the matching event conditions. An event rule instance includes information like event rule name. Actions carried out by a triggered rule are collected in a history log of action runs.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 19. then the whole rule instance will be reported in error. date and time when it was matched. They remain in an idle state. The tools supplied to define custom event types are: Chapter 6. If on January 1 the first event is received at 8 AM. The rule is valid from January 1 to January 10. If the second event is received at 11 AM (which is out of the activity time window). and stays alive beyond 10 AM if the event is not detected. For example. the rule waits for the second event to take place. or time out. Defining custom events In addition to the already defined event types and event classes (known as providers) listed in detail in “Event providers and definitions” on page 509. If the second event is received again at 7 AM of January 2. you define a set rule that includes two events. the rule is triggered and the actions are implemented. If at least one action ends in error. it is discarded. waiting to receive the remaining events in the following days. as opposed to successful ones. and their status. As part of the information tracked in action runs. Rule operation notes (continued) Topic Set and sequence rule types with shorter than 24 hours activity time windows Note Occurrences of set or sequence rules that were defined to be active for only a few hours of every day. an event rule instance is created. and queries can be executed to look for action runs based on these fields (the rule instance identifier is also available). rule fields are also maintained. Triggered rule elements Every time the event conditions listed in a deployed event rule are matched. The provided information includes action runs that have been completed with errors or warnings. and the list of action instances. but the rule keeps on staying alive. are not purged when the activity period within each day expires if only part of the events arrive. Running event-driven workload automation 103 . The RuleInstance object is used to collect information about triggered rules in a history log of rule instances. If you don not want the rule to carry over to the next day. and is active daily from 6 to 10 AM. you should purge it. Tivoli Workload Scheduler supplies the template of a generic event provider named GenericEventPlugIn that programmers with specific application and XML programming skills can modify to define custom event types that might be of use to the organization.

3. They also contain online guidelines to aid in the programming task. it can be sent to the event processing server in one of the following ways: v By the sendevent command. With the evtdef command. Downloads the generic event provider as a local file. This is the flow for defining and using custom events: 1. it triggers the rule. the programmer: a. Follows the schema definitions to add custom event types and to define their properties and attributes in the file with an XML editor. Uploads the local file as the modified generic event provider containing the new custom event type definitions. The rule builder. the event rules that are to be triggered by these custom events. v The sendevent utility command with which the custom events can be sent to the event processing server to trigger rules from any agent or any workstation running simply the Tivoli Workload Scheduler remote command line client. b. 104 IBM Tivoli Workload Scheduler: Reference Guide . When the occurrence of a custom event takes place. such as Tivoli Enterprise Console or Tivoli Monitoring As soon as the event is received by the event processing server. Deploy the rules. c.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v The GenericEventPlugIn event provider in XML v The evtdef utility command with which a programmer can download the GenericEventPlugIn event provider as a local file to define the custom events v The XML schema definition (XSD) files necessary to validate the modified generic event provider. The modified generic event provider is saved in an XML file on the master domain manager. run from a script or from the command line v By another application. specifying: v The generic event provider as the event provider v The custom event types as the event types v The custom event type properties (or attributes) defined for the custom events in the generic event provider with the particular values that will trigger the rules. with either composer or the Tivoli Dynamic Workload Console. defines. 4. 2. or the administrator.

It does not require the installation of a Tivoli Workload Scheduler workstation as a prerequisite. and other users have read only access to that object. Defining scheduling objects Scheduling objects are managed with the composer command-line program and are stored in the Tivoli Workload Scheduler database.Chapter 7. enter its definition in an edit file. transforms the object definition into XML language and then sends the request through HTTP/HTTPS to the master domain manager. The composer command-line program checks for correct syntax inside the edit file. Another feature introduced with this new version is the object locking mechanism. Scheduling objects are: v calendars v domains v event rules v jobs v job streams v prompts v parameters v resources v workstations v workstation classes This chapter is divided into the following sections: v “What is new in defining scheduling objects” v “Defining scheduling objects” | | | What is new in defining scheduling objects The major enhancement is the addition of the event rule scheduling object. The composer program uses edit files to update the scheduling database. Defining objects in the database Tivoli Workload Scheduler is based on a set of object definitions that are used to map your scheduling environment into the database. For example. 1999. The HTTP/HTTPS communication setup and the authentication check are managed by the WebSphere Application Server infrastructure. With this version of the product all entries are managed individually. if correct. The composer command-line program can be installed and used on any machine connected through TCP/IP to the system where the master domain manager is installed. The format of the edit file used to define a specific object is described later in this chapter. © Copyright IBM Corp. semantic and integrity checks are performed. For additional information refer to “lock” on page 224 and “unlock” on page 238. and then use composer to add it to the database by specifying the edit file containing the definition. to create a new object. It communicates through HTTP/HTTPS with the master domain manager where the DB2 database is installed. On the master domain manager the XML definition is parsed. Scheduling objects defined in the database are locked while accessed by a user to prevent concurrent accesses. and then the update is stored in the database. 2007 105 . This means that only the user locking the object has write permission to that object. and.

workstations. the use of such keywords can result in errors. so avoid using the keywords listed in Table 21 when defining jobs and job streams: Table 21. workstation classes and domains: 106 IBM Tivoli Workload Scheduler: Reference Guide . The first two columns on the left list the long and short keyword formats currently supported by Tivoli Workload Scheduler.Defining object in the database | | | | | | | | | | | | | | | | | | | | | | You can use short and long keywords when issuing commands from composer. The rightmost column lists the backward compatible formats you want to use if your network includes pre-version 8.3 installations calendars cpu — jobs sched parms prompts resources users cpu cpu Long keywords calendar domain eventrule jobdefinition jobstream parameter prompt resource user workstation workstationclass Short keywords cal dom erule | er jd js parm prom res user ws wscl Note: The cpu keyword is maintained to represent domains. List of reserved words when defining jobs and job streams abendprompt after at autodocoff autodocon canc carryforward confirmed continue dateval day(s) day_of_week deadline description tasktype runcycle docommand end every everyday except extraneous fdignore fdnext fdprev filename follows freedays go hi after validfrom i18n_id i18n_priority interactive isuserjob jobfilename keyjob keysched limit needs nextjob notempty number on onuntil abendprompt validto op opens order prompt qualifier rccondsucc recovery request rerun sa schedule scriptname stop streamlogon draft schedtime su timezone token_in until weekday(s) workday(s) jobs priority as matching previous sameday relative from to Avoid using the keywords listed in Table 22 on page 107 when defining workstations. List of supported scheduling object keywords backward compatible keywords with pre-version 8. Table 20. The composer program does not issue specific warnings if scheduling language keywords are used as names of scheduling objects. and workstation classes for backward compatibility. as Table 20 shows. However.3 installations.

List of reserved words when defining workstations access AIX® agent_type autolink behindfirewall command cpuclass cpuname description domain parent enabled end extraneous for force fullstatus host hpux ignore type linkto maestro manager master members mpeix mpexl mpev mpix fta node number off on os other parent posix tz access server secureaddr securitylevel tcpaddr timezone tzid UNIX using wnt timezone Avoid using the keywords listed in Table 23 when defining Windows users: Table 23. Defining objects in the database 107 .Defining object in the database Table 22. List of reserved words when defining users username password end Chapter 7.

] Arguments Table 24 on page 109 gives you an overview about specifying settings for the different types of workstations that can be defined. You can include multiple workstation definitions in the same text file. Primarily workstation definitions refer to physical workstations.] [domain .. the workstations are logical definitions that must be hosted by a physical workstation. 108 IBM Tivoli Workload Scheduler: Reference Guide .. Each workstation definition has the following format and arguments: Syntax cpuname workstation [description ″description″] os os-type node hostname [tcpaddr port] [secureaddr port][timezone|tz tzname] [domain domainname] [for maestro [host host-workstation [access method]] [type fta | s-agent | x-agent | manager] [ignore] [autolink on | off] [behindfirewall on | off] [securitylevel enabled | on | force] [fullstatus on | off] [server serverid]] end [cpuname . For additional details about the mentioned options refer to the options descriptions that follow. along with workstation class definitions and domain definitions. It is usually an individual computer on which jobs and job streams are run. However. A workstation definition is required for every computer that runs jobs in the IBM Tivoli Workload Scheduler network..Workstation definition Workstation definition A workstation is a scheduling object that runs jobs.. in the case of extended agents.] [cpuclass .. Mandatory settings are written in bold..

This option depends on the security needs of the site. Manager Optional Manager fault-tolerant agent fault-tolerant agent S-agent Not Applicable Not Applicable Not applicable X-agent Not Applicable Usually OFF. Access Method Not Applicable Select the appropriate access method file name. Refer to the selected access method specifications. Defining objects in the database 109 . for supported operating systems. It can contain up to 16 characters. ON Not Applicable ON ON Optional OFF Not Applicable Not Applicable Not Applicable 0-9. enter an unused port number) Operating System Domain (the default value is MASTERDM) Time Zone Description UNIX or WNT. Firewall Secure Port Type Autolink Ignore Full Status Server This option depends on the security needs of the site. Node System’s hostname or IP address TCP Port Default Value 31111. Note: Workstation names must be unique and cannot be the same as workstation class names. Existing domain Mutually exclusive with Host setting Not used. This is just a comment Host’s time zone SSL This option depends on the security needs of the site. See Table 21 on page 106 for a list of words to avoid using when specifying the cpuname. OTHER for AS/400 systems as OTHER fault-tolerant agent or standard agent. A-Z. Chapter 7. (For multiple workstations on a system. dashes. Used to create multiple mailman processes on parent. Mutually The host exclusive with workstation. The value must match the value set on the operating system. and underscores. turn ON if you do not want this workstation to appear in the next plan. Domain setting Host Not Applicable cpuname workstation Specifies the name of the workstation. The value must match nm port number in the localopts file.Workstation definition Table 24. It is not applicable for Communications AS/400 workstations. The name must start with a letter. Option settings for workstation types Options Master Domain Manager Domain Manager Backup Domain Manager Fault-tolerant Agent Standard Agent Extended Agent Must be set to NULL for some extended agent. MASTERDM The name of the managed Domain. The name of the managed Domain. and can contain alphanumeric characters. Not Applicable The time zone in which the system is located.

Its value must match with the value assigned in the localopts file for variable nm port number. if the domain is not set then its default is the domain of the hosting workstation. domain domainname Specifies the name of Tivoli Workload Scheduler domain of the workstation. The default is 31111. node hostname Specifies the host name or the TCP/IP address of the workstation. 31113 is used as the default value. in this case if the master 110 IBM Tivoli Workload Scheduler: Reference Guide . The default for a domain manager is the domain in which it is defined as the manager. host host-workstation Specifies the name of the agent’s host workstation. os os_type Specifies the operating system of the workstation. WNT. See the IBM Tivoli Workload Scheduler Planning and Installation Guide for information about SSL authentication and local options set in the TWS_home/localopts configuration file. timezone|tz tzname Specifies the time zone of the workstation. usually named MASTERDM. secureaddr Defines the port used to listen for incoming SSL connections. “Managing time zones. The text must be enclosed within double quotes. WNT For supported Windows operating systems. See Chapter 12. To ensure the accuracy of scheduling times. It must be different from the nm port local option that defines the port used for normal communications. Valid values are UNIX. Note that the host cannot be another extended agent. OTHER Used in connection with extended agents. This is required for extended agents. and OTHER. You can use the key $MASTER to indicate that the agent’s host workstation for the extended agent or the standard agent is the master domain manager. In a standard agent workstation definition the domain and the host settings are mutually exclusive. Use: UNIX For supported operating systems running on UNIX-based systems. The host is the workstation with which the extended agent communicates and where its access method resides. this time zone must be the same as the computer’s operating system time zone. The default for fault-tolerant is the master domain.” on page 461 for valid time zone names. Fully-qualified domain names are accepted. tcpaddr port Specifies the TCP/IP port number that Tivoli Workload Scheduler uses for communicating between workstations. If securitylevel is specified but this attribute is missing. Tivoli Workload Scheduler ignores domain setting when defined for extended agents. Note: Refer to the IBM Tivoli Workload Scheduler Release Notes for an up-to-date list of supported operating system. This value must match the one defined in the nm SSL port local option of the workstation.Workstation definition description ”description” Provides a description of the workstation.

These are the specific settings when defining a domain manager: v Server . If the value of autolink is off for an agent. autolink Specifies whether to open the link between workstations at startup. including backup domain managers and backup master domain manager. For the domain manager. the agent. The information about whether a workstation is a manager is also set in the manager field in the “Domain definition” on page 117. Only a direct connection Chapter 7.Workstation definition domain manager name is modified later on. This must be the name of a file that resides in the TWS_home/methods directory on the agent’s host workstation. and all workstations are stopped and restarted. If autolink is also turned on for the domain manager. it is initialized when you run a conman link command on the agent’s domain manager or the master domain manager. the domain manager automatically sends a copy of the new production plan and starts the agent. type Specifies the type of workstation. in turn. Tivoli Workload Scheduler automatically updates the value assigned to the $MASTER key. Autolink is useful primarily during the startup sequence when activating a new production plan. Enter one of the following: fta s-agent Standard agent. For more information. a new production plan is created and compiled on the master domain manager. refer to IBM Tivoli Workload Scheduler for Applications. 111 . At that time. the host setting is used only to determine the setting of the domain keyword. An extra check on the consistency of the values set in these two fields is automatically made by Tivoli Workload Scheduler. access method Specifies an access method for extended and network agents. it means there is a firewall between the workstation and the master domain manager.if different from MASTERDM it corresponds to the name of the domain it manages ignore Specifies that this workstation definition must not be added to the production plan. For fault-tolerant and standard agents. x-agent Extended agent. For each agent with autolink turned on. behindfirewall If this attribute is set to ON. In a standard agent workstation definition the domain and the host settings are mutually exclusive and. Note: For some access methods you must set the Node Name to NULL. opens a link back to the domain manager. Defining objects in the database Fault-tolerant agent. manager Domain manager.NULL v Domain . enter on to have its agents open links to the domain manager when they are started. enter on to have the domain manager open the link to the agent when the domain manager is started. if set.

the agent is updated with the status of jobs and job streams running on all other workstations in its domain and in subordinate domains. For all the workstations with behindfirewall set to ON.Workstation definition between the workstation and its domain manager is allowed. set fullstatus to on. If this attribute is omitted. It refuses any incoming connection that is not an SSL connection. the start workstation. instead of making the master domain manager or the domain manager open a direct connection with the workstation. force The workstation uses SSL authentication for all of its connections and accepts connections from both parent and subordinate domain managers. the agent is informed only about the status of jobs and job streams on other workstations that affect its own jobs and job streams. The FTA refuses any incoming connection from its domain manager if it is not an SSL connection. This is for FTAs only. Type of communication depending on the security level value Fault-tolerant Agent (Domain Manager) Domain Manager (Parent Domain Manager) Connection Type TCP/IP Enabled On Force On Enabled On TCP/IP No connection No connection TCP/IP TCP/IP 112 IBM Tivoli Workload Scheduler: Reference Guide . To keep an agent’s production plan at the same level of detail as its domain manager. any value for secureaddr is ignored. for domain managers this keyword is automatically set to on. Table 25. See the IBM Tivoli Workload Scheduler Planning and Installation Guide for information about SSL authentication. stop workstation. but not on peer or parent domains. the workstation is not configured for SSL connections. It can have one of the following values: enabled The workstation uses SSL authentication only if its domain manager workstation or another FTA below it in the domain hierarchy requires it. You should also set the nm ssl port local option to 0 to be sure that this port is not opened by netman. In this mode. This can improve performance by reducing network activity. fullstatus Specifies whether the agent is updated with full or partial status. The domain manager uses SSL authentication when it connects to its parent domain manager. This setting automatically sets accordingly the resolve dependencies option. securitylevel Specifies the type of SSL authentication for the workstation. If the value of fullstatus is off. In this case. Table 25 describes the type of communication used for each type of securitylevel setting. on The workstation uses SSL authentication when it connects with its domain manager. and showjobs commands are sent following the domain hierarchy. Enter on to have the agent operate in Full Status mode.

Note: You can add workstation definitions to the database at any time but you need to run JnextPlan -for 0000 again to be able to run jobs on newly created workstations. This setting is used for fault-tolerant agents. When the domain manager starts. If the same ID is used for multiple agents. Using servers can reduce the time required to initialize agents and improve the timeliness of messages. and a fault-tolerant agent named hdq-2 in the master domain. consider dividing it into two or more domains. a single server is created to handle their communications. because the master domain defaults to masterdm. cpuname hdq-1 description “Headquarters master DM” os unix tz America/Los_Angeles node sultan.com domain masterdm Chapter 7. If you are defining a fault-tolerant agent that can work as backup domain manager. If more than 36 server IDs are required in a domain. Type of communication depending on the security level value (continued) Fault-tolerant Agent (Domain Manager) On Force Domain Manager (Parent Domain Manager) On On Enabled Enabled On Force Enabled Enabled Enabled Force Enabled On Force Force Force Force Connection Type SSL SSL TCP/IP TCP/IP SSL SSL No connection SSL SSL SSL server ServerID Specifies a mailman server on the domain manager to handle communications with the fault-tolerant agent. it creates a separate server for each unique ServerID. Note that a domain argument is optional in this example. Every time you run JnextPlan all workstations are shut down and restarted. Within the ServerID. Examples The following example creates a master domain manager named hdq-1. the ServerID set is used when the workstation works as fault-tolerant agent. the setting is ignored when the workstation works as a backup domain manager. so you can use the same IDs in other domains without conflict. The IDs are unique to each domain manager. For information on how to switch domain managers in a domain. the ID is a single letter or a number (A-Z and 0-9). communications with the agent are handled by the main mailman process on the domain manager. If a ServerID is not specified.Workstation definition Table 25.ibm. Define extra servers to prevent a single server from handling more than eight agents. Defining objects in the database 113 . refer to “switchmgr” on page 367.

ibm.ibm.com tz America/New_York domain distr-a for maestro type s-agent end The following example creates a workstation with SSL authentication.ibm. see ″Creating a z/OS Workstation″ and ″Creating a Distributed Workstation″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. cpuname ENNETI3 os WNT node apollo tcpaddr 30112 secureaddr 32222 for maestro autolink off fullstatus on securitylevel on end See also For the equivalent Job Scheduling Console task. Port 32222 is reserved for listening for incoming SSL connections. The securitylevel security definition specifies that the connection between the workstation and its domain manager can be only of the SSL type.Workstation definition for maestro type manager autolink on fullstatus on end cpuname hdq-2 os wnt tz America/Los_Angeles node opera.com domain distr-a for maestro type manager autolink on fullstatus on end cpuname distr-a2 os wnt node quatro. 114 IBM Tivoli Workload Scheduler: Reference Guide .com domain masterdm for maestro type fta autolink on end The following example creates a domain named distr-a with a domain manager named distr-a1 and a standard agent named distr-a2: domain distr-a manager distr-a1 parent masterdm end cpuname distr-a1 description “District A domain mgr” os wnt tz America/New_York node pewter.

] Arguments cpuclass workstationclass Specifies the name of the workstation class. and can contain alphanumeric characters. and underscores. Defining objects in the database 115 . workstation classes..Workstation class definition Workstation class definition A workstation class is a group of workstations for which common jobs and job streams can be written.] [domain . It can contain up to 16 characters... and domains. The @ wildcard character means that the workstation class includes all workstations. Examples The following example defines a workstation class named backup: cpuclass backup members main site1 site2 end The following example defines a workstation class named allcpus that contains every workstation: cpuclass allcpus members @ end Chapter 7. Each workstation class definition has the following format and arguments: Syntax cpuclass workstationclass [description ″description″] [ignore] members [workstation | @] [.. along with workstation definitions and domain definitions. The text must be enclosed within double quotes.. Note: You cannot use the same names for workstations.. The name must start with a letter. You can include multiple workstation class definitions in the same text file. members workstation Specifies a list of workstation names. that are members of the class.] [cpuclass . dashes.. separated by spaces. description ”description” Provides a description of the workstation class.. ignore Specifies that Tivoli Workload Scheduler must ignore all workstations included in this workstation class when generating the production plan.] end [cpuname .

116 IBM Tivoli Workload Scheduler: Reference Guide . see ″Creating a Workstation Class″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.Workstation class definition See also For the equivalent Job Scheduling Console task.

indicates that the domain is the top domain of the Tivoli Workload Scheduler network. ismaster If specified. workstation classes. The domain manager acts as the management hub for the agents in the domain.Domain definition Domain definition A domain is a group of workstations consisting of one or more agents and a domain manager. and two subordinate domains named northeast and southeast: domain east description “The Eastern domain” * manager cyclops end domain northeast description “The Northeastern domain” Chapter 7...3 the information about whether a workstation is a domain manager is set in the type field in the “Workstation definition” on page 108. * manager workstation This is a commented field used only to show. The text must be enclosed within double quotes. It is kept for backward compatibility..] [domain . Defining objects in the database 117 .] [cpuclass . If set it cannot be removed later. Examples The following example defines a domain named east. and can contain alphanumeric characters. and domains. The default is the master domain. You cannot use the same names for workstations.. With Tivoli Workload Scheduler version 8. and underscores. It must start with a letter. which does not require a domain definition. parent domainname The name of the parent domain to which the domain manager is linked. along with workstation definitions and workstation class definitions. dashes. description “description” Provides a description of the domain. It can contain up to 16 characters. Each domain definition has the following format and arguments: Syntax domain domainname[description “description”] * manager workstation [parent domainname | ismaster] end [cpuname . with the master domain as its parent. the name of the workstation that has the role of domain manager for that domain. when displaying the domain definition.. You can include multiple domain definitions in the same text file. The master domain is defined by the global options master and master domain..] Arguments domain domainname The name of the domain. Make sure this field remains commented.

see ″Creating a Domain″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.Domain definition * manager boxcar parent east end domain southeast description “The Southeastern domain” * manager sedan parent east end See also For the equivalent Job Scheduling Console task. 118 IBM Tivoli Workload Scheduler: Reference Guide .

It can contain up to 40 characters. jobname Specifies the name of the job. scriptname filename Chapter 7. This means that if you modify the job definition of job1 in job stream definition js1 and job1 is used also in job stream js2. Note: Wrongly typed keywords used in job definitions lead to truncated job definitions stored in the database. If you specify a workstation class. Each job definition has the following format and arguments: Syntax $jobs [workstation#]jobname {scriptname filename | docommand “command”} streamlogon username [description “description”] [tasktype tasktype] [interactive] [rccondsucc ″Success Condition″] [recovery {stop | continue | rerun} [after [workstation#]jobname] [abendprompt “text”] ] A job itself has no settings for dependencies. Arguments workstation# Specifies the name of the workstation or workstation class on which the job runs. The name must start with a letter. Usually this misinterpretation causes also a syntax error or an inexistent job definition error for the additional job definition. dashes. The pound sign (#) is a required delimiter. these must be added to the job when it is included in a job stream definition. and underscores.Job definition Job definition A job is an executable file. and can contain alphanumeric characters. also the definition of job1 in js2 definition is modified accordingly. You can write job definitions in edit files and then add them to Tivoli Workload Scheduler database with the composer command line program. You can include multiple job definitions in a single edit file. Modifications to jobs definitions made in job streams definitions are reflected in the job definitions stored in the database. In fact the wrong keyword is considered extraneous to the job definition and so it is interpreted as the job name of an additional job definition. The default is the workstation specified for defaultws when starting the composer session. For more information on how to start a composer session refer to “Running the composer program” on page 191. Defining objects in the database 119 . Refer to section “Job stream definition” on page 133 for information on how to write job streams definitions. You can add or modify job definitions from within job stream definitions. it must match the workstation class of any job stream in which the job is included. or command that is scheduled and launched by Tivoli Workload Scheduler. program.

A command is run directly and. Note: Refer to IBM Tivoli Workload Scheduler for Applications: User's Guide for information on customized task types for supported third party applications. It can have one of the following values: UNIX WINDOWS OTHER For jobs that run on UNIX platforms. Use scriptname for UNIX and Windows jobs. If the file path or the file name of the scriptname argument contain spaces. the command is treated as a job. 120 IBM Tivoli Workload Scheduler: Reference Guide . Enter a valid command and any options and arguments enclosed in double quotes (″). is not run. interactive | | Specifies that the job runs interactively on the user's desktop. The text must be enclosed in double quotes. If the name contains special characters it must be enclosed in double quotes (″). For jobs that run on Windows platforms. and all job rules apply. You can also use Tivoli Workload Scheduler parameters. include the file extensions.The maximum number of characters allowed is 120. The length of command plus the length of Success Condition (of the rccondsucc keyword) must not exceed 4095 characters. the entire string must be enclosed in quotes (″). This feature is available only on Windows environments. Universal Naming Convention (UNC) names are permitted.Job definition Specifies the name of the file the job runs. description “description” Provides a description of the job. For an executable file. For jobs that run on extended agents. unlike scriptname. For Windows jobs. other than slashes (/) and backslashes (\). enter the file name and any options and arguments. You can also enter Tivoli Workload Scheduler parameters. Specify a user that can log on to the workstation on which the job runs. You can also enter Tivoli Workload Scheduler parameters. the configuration script. jobmanrc. The length of filename plus the length of Success Condition (of the rccondsucc keyword) must not exceed 4095 characters. See “Using parameters in job definitions” on page 123 for more information.cmd\"" If special characters are included. For Windows jobs. docommand command Specifies a command that the job runs. See “Windows user definition” on page 125 for user requirements. Do not specify files on mapped drives. tasktype tasktype Specifies the job type. See “Using parameters in job definitions” on page 123 for more information. Otherwise. streamlogon username The user name under which the job runs. The name can contain up to 47 characters. See “Using parameters in job definitions” on page 123 for more information. the entire string must be enclosed between "\" and \" " as shown below: scriptname "\"C:\Program Files\tws\myscript. the user must also have a user definition.

operator Comparison operator. You can use parentheses to assign a priority to the expression evaluation. Logical operators Example expr_a and expr_b expr_a or expr_b Not expr_a Operator And Or Not Result TRUE if both expr_a and expr_b are TRUE. For example. The success condition can be a maximum of 256 characters. Defining objects in the database 121 .Job definition rccondsucc ″Success Condition″ An expression which determines the return code (RC) required to consider a job successful. The syntax is: (RC operator operand) RC The RC keyword. operator Logical operator. you can define a successful job as a job that ends with a return code less than or equal to 3 as follows: rccondsucc "(RC <= 3)" Boolean expression Specifies a logical combination of comparison expressions. Chapter 7. The syntax is: comparison_expression operator comparison_expression comparison_expression The expression is evaluated from left to right. Comparison operators Example RC<a RC<=a RC>a RC>=a RC=a RC!=a RC<>a Operator < <= > >= = != <> Description Less than Less than or equal to Greater than Greater than or equal to Equal to Not equal to Not equal to operand An integer between -2147483647 and 2147483647. TRUE if either expr_a or expr_b is TRUE. This expression can contain a combination of comparison and Boolean expressions: Comparison expression Specifies the job return codes. It can have the following values: Table 27. It can have the following values: Table 26. TRUE if expr_a is not TRUE.

job1 and job2. The default is stop with no recovery job and no recovery prompt. If reply is yes. the prompt is displayed. The table is based on the following criteria from a job stream called sked1: v Job stream sked1 has two jobs. rerun If the job abends.Job definition For example. continue with the next job. the prompt is displayed. enclosed in double quotes. but no reply is required to continue processing. Not all jobs are eligible to have recovery jobs run on a different workstation. v job2 is dependent on job1 and does not start until job1 has completed. If job1 is successful. The default is the parent job’s workstation. Enter one of the recovery options. stop If the job abends. to be displayed if the job abends. Table 28. v If the recovery job workstation is a FTA. do not continue with the next job. v If selected for job1. abendprompt “text” Specifies the text of a recovery prompt. a recovery prompt or both. This can be followed by a recovery job. stop. Recovery jobs are run only once for each abended instance of the parent job. If job1 abends. after [workstation#]jobname Specifies the name of a recovery job to run if the parent job abends. Continue Run job2. The text can contain up to 64 characters. If the text begins with a colon (:). it must have a value of on for fullstatus. Table 28 summarizes all possible combinations of recovery options and actions. it must be hosted by a domain manager or a FTA with a value of on for fullstatus. Follow these guidelines: v If either workstation is an extended agent. you can define a successful job as a job that ends with a return code less than or equal to 3 or with a return code not equal to 5. v The recovery job workstation can be in the same domain as the parent job workstation or in an upper domain. Recovery options and actions Stop Recovery prompt: No Recovery job: No Intervention is required. issue a prompt. or rerun. continue If the job abends. If the text begins with an exclamation mark (!). the recovery job is jobr. repeat above. You can specify the recovery job’s workstation if it is different from the parent job’s workstation. run job2. rerun the job. continue. but it is not recorded in the log file. 122 IBM Tivoli Workload Scheduler: Reference Guide . and less than 10 as follows: rccondsucc "(RC=3) OR ((RC>=5) AND (RC<10))" recovery Recovery options for the job. Rerun Rerun job1.

v Enclose parameter names in carets (^). run jobr. run job2. use the name of the original job (job1 in the scenario above. v Ensure that caret characters are not preceded by a backslash in the string. Notes®: 1. If jobr is successful. For additional examples. This prevents the job stream from being carried forward to the next production plan. Using parameters in job definitions: Parameters have the following uses and limitations in job definitions: v Parameters are allowed in the streamlogon. If reply is yes. If jobr abends. Run jobr. 4. Only one recovery jobs is run for each abend. repeat above. Run jobr. Intervention is required. intervention is required. not jobr). and enclose the entire string in quotation marks. If job1 is successful. If reply is yes. If job1 abends. v A parameter can be used as an entire string or as part of it. run job2. Tivoli Workload Scheduler generates its own prompt. Issue recovery prompt. Defining objects in the database 123 . include the backslash in the definition of the parameter. repeat above. intervention is required. If you select the rerun option without supplying a recovery prompt. Recovery prompt: Yes Recovery job: Yes Issue recovery prompt. In the example below a parameter named mis is used in the streamlogon value. If job1 abends. If reply is yes. run jobr. and therefore must be released by the operator. If job1 is successful. Rerun Issue recovery prompt. run jobr. If it abends. run job2. ″Intervention is required″ means that job2 is not released from its dependency on job1. Refer to “Parameter definition” on page 128 for additional information and example. which might cause the job stream containing the abended job to be marked as successful. Recovery options and actions (continued) Stop Recovery prompt: Yes Recovery job: No Issue recovery prompt. repeat above. If job1 is successful. and docommand values. If reply is yes. If reply is yes. intervention is required. issue a prompt. If jobr is successful. run job2. rerun job1. If it is successful. If jobr abends. intervention is required. If it is successful. rerun job1. If job1 abends. If reply is yes. scriptname. 3. run job2. If necessary. The continue recovery option overrides the abend state. Recovery prompt: No Recovery job: Yes Run jobr. v Multiple parameters are permitted in a single variable. Run job2. To reference a recovery job in conman. Run job2. rerun job1. Examples The following is an example of a file containing two job definitions: Chapter 7. If it abends. Continue Issue recovery prompt.Job definition Table 28. 2. see “Parameter definition” on page 128. Issue recovery prompt. run job2.

124 IBM Tivoli Workload Scheduler: Reference Guide .Using parameters in job definitions $jobs cpu1#gl1 scriptname "/usr/acct/scripts/gl1" streamlogon acct description "general ledger job1" bkup scriptname "/usr/mis/scripts/bkup" streamlogon "^mis^" recovery continue after recjob1 See also For the equivalent Job Scheduling Console task. see ″Creating a Job Definition″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

you cannot read the password. The default is blank. Users with appropriate security privileges can modify or delete a user. The workstation name is optional. in that order. or a trusted domain user.Windows user definition Windows user definition The user names used as the streamlogon value for Windows job definitions must have user definitions. you must create a user definition [workstation#]username for each workstation running on Windows where the user username is defined. To indicate a null password. a domain user. it is taken to mean a local user. and must be enclosed in quotes. The pound sign is required. This is not required for users who run jobs on other operating system.. The password can contain up to 29 characters.. and the user name can contain up to 31 characters. meaning all workstations. password Specifies the user password. If the name is not unique in Windows. The instance [workstation#]username uniquely identifies the Windows user in the Tivoli Workload Scheduler environment. workstation Specifies the workstation on which the user is allowed to launch jobs. Each user definition has the following format and arguments: Syntax username[workstation#][domain\]username password “password”end [username . its absence indicates that the user named username defined on all the Windows workstations in the Tivoli Workload Scheduler network. and have the permission to Log on as batch. Chapter 7. Note: Windows user names are case-sensitive. The domain name can contain up to 16 characters (including the backslash). but password information is never displayed. Defining objects in the database 125 . [domain\]username Specifies the Windows domain of the user and the name of the user. Using the Tivoli Workload Scheduler user and streamlogon definitions: In Windows. use two consecutive double quotes with no blanks in between.] Arguments username [workstation#]username Specifies the name of a Windows user. ””. the user must be able to log on to the workstation on which Tivoli Workload Scheduler launches jobs. Also. When a user definition has been compiled. to avoid inconsistencies. If the user named username is only defined on some Windows workstations in the Tivoli Workload Scheduler network. user definitions are specified using composer in the form [workstation#]username.

v In Domain1 on the computers where jobs are launched. v In Domain1. you must specify both a workstation and a valid user logon for the workstation. follow these guidelines when defining the user accounts. you must use the user definition in the format workstation#username For this command. For example. Trusted domain user: If Tivoli Workload Scheduler is to launch jobs for a trusted domain user. Assuming Tivoli Workload Scheduler is installed in Domain1 for user account maestro. when you use the altpass command. maestro must be a domain user. you can omit the workstation name only when changing the password of the workstation from where you are running the command. sue must have the right to Log on as batch. the following must be true: v There must be mutual trust between Domain1 and Domain2. and user account sue in Domain2 needs to launch a job. in the following job definition: $JOB workstation job01 docommand "dir" streamlogon username the value for streamlogon is username and not workstation#username. without the workstation name. However. maestro must have the right to Access this computer from network. The logon is just a valid user name for Windows. see ″Creating a Windows User″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.Using the Tivoli Workload Scheduler user and streamlogon definitions When you define or submit a job using composer. 126 IBM Tivoli Workload Scheduler: Reference Guide . Examples The following example defines four users: username joe password "okidoki" end # username server#jane password "okitay" end # username dom1\jane password "righto" end # username jack password "" end See also For the equivalent Job Scheduling Console task. v On the domain controllers in Domain2.

semi-colon (. date [. colon (:). plus (+). “description” Provides a description of the calendar. Chapter 7.. Each calendar definition has the following format and arguments: Syntax $calendar calendarname [“description”] date [.Calendar definition Calendar definition A calendar is a list of dates which define if and when a job stream runs. Defining objects in the database 127 . and ampersand (&). It can contain the following characters: comma (. dash (-).). and equal (=). and must start with a letter. including dashes (-) and underscores (_). period (. The format is mm/dd/yy. paydays. and holidays: $calendar monthend "Month 01/31/2005 paydays 01/15/2005 03/15/2005 05/14/2005 holidays 01/01/2005 end dates 1st half 2005" 02/28/2005 03/31/2005 04/30/2005 05/31/2005 06/30/2005 02/15/2005 04/15/2005 06/15/2005 02/15/2005 05/31/2005 See also For the equivalent Job Scheduling Console task. It can contain alphanumeric characters as long as it starts with a letter. It cannot contain double quotes (″) other than the enclosing ones.] [calendarname .). separated by spaces... The name can contain up to eight alphanumeric characters... see ″Creating a Calendar″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.] Specifies one or more dates.] Arguments calendarname Specifies the name of the calendar. It must be enclosed in double quotes. Examples The following example defines three calendars named monthend.). single quote (’)..

They can be used in job and job stream definitions to specify the keywords scriptname and opens. They can be used in job and job stream definitions to specify the keywords scriptname. v At submission time on the workstation where the job or job stream is submitted from the conman command line. Syntax $parm parametername “value” [parametername . the name reported unresolved in the Symphony file. An example of global parameter used with the docommand keyword is: docommand "ls ^MY_HOME^" local parameters These are the parameters that you can define in a database locally on a workstation using the utility command “parms” on page 400. docommand. Do not include the names of other parameters..” on page 243. when the production plan is generated or extended. including dashes (-) and underscores (_). streamlogon and in prompts definitions by enclosing the parametername between carets ^ ^. “Managing objects in the plan conman. that is replaced with their assigned value. They are resolved. In Tivoli Workload Scheduler you can use two different types of parameter: global parameters These are the parameters defined as scheduling objects in the database. They are resolved using the definitions stored in the local PARMS database as follows: v At run time on the workstation where job processing occurs. value Specifies the value assigned to the parameter. The name can contain up to eight alphanumeric characters. For example.] Arguments parametername The name of the parameter. If a parameter with name parametername is not defined in the database. if you add to the database the following job definition: 128 IBM Tivoli Workload Scheduler: Reference Guide . For more information on how to submit jobs and job streams in production from the conman command line refer to Chapter 9. and must start with a letter..Parameter definition Parameter definition Parameters are values which substitute variables in job and job stream definitions when the new production plan is created or extended. opens. An example of a local parameter used with the opens keyword is: opens "/usr/home/tws_99/`/usr/home/tws_99/bin/parms MY_FILE`" When defining a job or job stream in the database you can enclose to parametername between ) ) to ensure the parameter is solved at run time on the workstation even if a parameter with the same name is defined as a global parameter in the Tivoli Workload Scheduler database. A local parameter is defined within these keywords or from within the invoked job script using the following syntax )bin\parms PARAMETERNAME).

When you use a parameter enclose it in carets (^).cmd" Examples Two parameters. see ″Creating a Parameter″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. instead of entering the following parameters definition: $PARM MYDIR "scripts" job01 scriptname "c:\operatorid\home\^MYDIR^\test. You can use multiple parameters in a single variable. If the parameter contains a portion of a path. If you define in the database myjob as follows: $jobs myjob docommand "ls )bin\parms\ MYDIR)" streamlogon ")bin\parms\ MYUSER)" then as the production plan is created or extended the only action that is performed against the two parameters in the definition of myjob is the removal of the ) ). For example. and then enclose the entire string in quotation marks. Chapter 7. are defined as follows: $parm glpath gllogon "/glfiles/daily" "gluser" The glpath and gllogon parameters are used in the gljob2 job of theglsched job stream: schedule glsched on weekdays : gljob2 scriptname "/usr/gl^glpath^" streamlogon "^gllogon^" opens "^glpath^/datafile" prompt ":^glpath^ started by ^gllogon^" end See also For the equivalent Job Scheduling Console task. If necessary. then as the production plan is created or extended the two parameters are resolved using the definitions contained in the database and their corresponding values are carried with the Symphony file.Parameter definition $jobs myjob docommand "ls ^MYDIR^" streamlogon "^MYUSER^" and two parameters named MYDIR and MYUSER are defined in the database. glpah and gllogon. ensure that the caret characters are not immediately preceded by a backslash (\) because. the parameters are carried in the Symphony file unresolved and then are resolved at run time locally on the target workstation using the value stored in the PARMS database.cmd" you enter: $PARM MYDIR "\scripts" job01 scriptname "c:\operatorid\home^MYDIR^\test. move the backslash into the definition of the parameter between carets to avoid bad interpretation of the backslash character. in that case. the sequence \^ could be wrongly interpreted as an escape sequence and resolved by the parser as caret character. Defining objects in the database 129 .

You can use prompts as dependencies in jobs and job streams. carets (^) not identifying a parameter. Examples The following example defines three prompts: 130 IBM Tivoli Workload Scheduler: Reference Guide . the parameter string must be enclosed in carets (^). the prompt can behave differently: v If the text begins with a colon (:). it pauses the job or job stream processing and requires an affirmatively answer to allow processing to continue. the prompt is displayed.] Arguments promptname Specifies the name of the prompt. text Provides the text of the prompt. the prompt is displayed. and must start with a letter. There are two types of prompts: local or unnamed prompts An unnamed prompt is a prompt defined within a job or job stream definition using the keyword prompt. You can use one or more parameters as part or all of the text string for a prompt. carets do not have to be preceded by a backslash. it has no name assigned and is not defined as a scheduling object in the database therefore it cannot be used by other jobs or job streams. it is identified by an unique name and it can be used by any job or job stream. You can include backslash n (\n) within the text to create a new line. Based on the character preceding the text. must be preceded by a backslash (\) to prevent them from causing errors in the prompt. v If the text begins with an exclamation mark (!). See “Parameter definition” on page 128 for an example. For more information on local prompts refer to “Job definition” on page 119 and “Job stream definition” on page 133. If you use a parameter. The name can contain up to eight alphanumeric characters. but no reply is required to continue processing. Within global prompts.Prompt definition Prompt definition A prompt identifies a textual message which is presented to the operator. global or named prompts A global prompt is defined in the database as a scheduling object... including dashes (-) and underscores (_). Syntax $prompt promptname “[: | !]text” [promptname . This section describes global prompts. Note: Within local prompts. Note: Predefined or global prompt definitions are reset each time the JnextPlan job is run. but it is not recorded in the log file.

Defining objects in the database 131 . Chapter 7.Prompt definition $prompt prmt1 "ready for job4? (y/n)" prmt2 ":job4 launched" prmt3 "!continue?" See also For the equivalent Job Scheduling Console task. see ″Creating a Prompt″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

] Arguments workstation Specifies the name of the workstation or workstation class on which the resource is used. Syntax $resource workstation#resourcename units [“description” ] [workstation#resourcename . and must start with a letter. including dashes (-) and underscores (_).. The only exception to this behavior is when the job or job stream is GO. The resource units involved in needs dependencies for a job or for a job stream remain busy until the job or job stream is completed (successfully or not). Examples The following example defines four resources: $resource ux1#tapes 3 ux1#jobslots ux2#tapes 2 ux2#jobslots "tape units" 24 "job slots" "tape units" 16 "job slots" See also For the equivalent Job Scheduling Console task. When multiple jobs and job streams depend on the same resource. see ″Creating a Distributed Resource″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.Resource definition Resource definition Resources represent physical or logical scheduling resources that can be used as dependencies for jobs and job streams. in which case it starts regardless of the value set for limit CPU. units Specifies the number of available resource units. The name can contain up to eight alphanumeric characters. 132 IBM Tivoli Workload Scheduler: Reference Guide . It must be enclosed in double quotes. it waits in READY state. resourcename Specifies the name of the resource. Values can be 0 through 1024.. “description” Provides a description of the resource. The resource units are released as soon as the job or job stream is completed. If the limit CPU set on the workstation does not allow it to run at the moment. The status of a job or job stream becomes READY as soon as all its dependencies are resolved. if not enough resource units are currently available for all of them it is assigned according to the job or job stream priority.

.]}] [follows {[netagent::][workstation#]jobstreamname[... Job streams created using the graphical user interface..] [{at time [timezone|tz tzname] [+n day[s]] | schedtime time [timezone|tz tzname] [+n day[s]]}] [until time [timezone|tz tzname] [+n day[s]] [onuntil action]] [deadline time [timezone|tz tzname] [+n day[s]]] [carryforward] [matching {previous|sameday|relative from [+ | −] time to [+ | −] time| from time [+ | −n day[s]] to time [+ n day[s]] [. Each job has its own attributes and dependencies.. and other dependencies that determine the order of processing.] [fdignore|fdnext|fdprev] [({at time [+n day[s]] | schedtime time [+n day[s]]} [until time [+n day[s]] [onuntil action]] [deadline time [+n day[s]]])]] [. The colon delimiter introduces the jobs invoked by the job stream.] [fdignore|fdnext|fdprev] [{(at time [+n day[s]])] | (schedtime time [+n day[s]])}]] [......]] [opens [workstation#]″filename″ [(qualifier)] [. together with times.]]} [keysched] [limit joblimit] [needs [n] [workstation#]resourcename [.... even though they do not reference the keywords listed in this chapter.. Syntax schedule [workstation#]jobstreamname # comment [validfrom date] [timezone|tz tzname] [description ”text”] [draft] [freedays calendarname [-sa] [-su]] [on [runcycle name] [validfrom date] [validto date] [description ”text”] {date|day|calendar|request|”icalendar”} [..... Defining objects in the database 133 .jobname |@] [previous| sameday|relative from [+|−] time to [+|−] time| from time [+|−n day[s]] to time [+|−n day[s]] [.] [except [runcycle name] [validfrom date] [validto date] [description ”text”] {date|day|calendar|request|”icalendar”} [. priorities.....Job stream definition Job stream definition A job stream consists of a sequences of jobs to be run.]] [priority number | hi | go] [prompt {promptname|”[:|!]text”}] Chapter 7.. A job stream begins with a schedule keyword followed by attributes and dependencies.. are saved using the same scheduling language syntax and keywords.

]] [opens [workstation#]″filename″ [(qualifier)] [.] [until time [timezone|tz tzname] [+n day[s]] [onuntil action] [deadline time [timezone|tz tzname] [+n day[s]]] [.Job stream definition : job-statement # comment [{at time [timezone|tz tzname] [+n day[s]] | schedtime time [timezone|tz tzname] [+n day[s]]}][..] [every rate] [follows {[netagent::][workstation#]jobstreamname{. Table 29.. The maximum length of this field is 120 characters. Marks the end of a job stream... Launches the job repeatedly at a specified rate. List of scheduling keywords Keyword at Description Defines the earliest time a job stream or a job run can be launched.... Specifies dates that are exceptions to the on dates the job stream is selected to run.jobname @} [previous| sameday|relative from [+|−] time to [+|−] time | from time [+|−n day[s]] to time [+|−n day[s]] [. Includes comments in the definition of a job stream or in a job contained in the job stream. Carries the job stream forward if it is not completed...]]} [confirmed] [keyjob] [needs [n] [workstation#]resourcename [. Page 138 carryforward comment confirmed deadline 139 140 141 142 description draft end every except 143 144 145 146 148 134 IBM Tivoli Workload Scheduler: Reference Guide .. When defined in a run cycle specifies the earliest time a job or a job stream can be launched for that specific run cycle. When defined in a run cycle specifies the time within which a job or a job stream must complete in that specific run cycle.]] [priority number | hi | go] [prompt {promptname |”[:|!]text”}] [job-statement... A detailed description of each scheduling keyword is provided in the next subsections.] end Arguments Table 29 contains a brief description of the job stream definition keywords.. Specifies that the plan generation process must ignore this job stream.. Contains a description of the job stream. Specifies the time within which a job or job stream should complete.... Specifies that the completion of this job requires confirmation.

Job stream definition
Table 29. List of scheduling keywords (continued) Keyword follows Description Specifies jobs or job streams that must complete successfully before the job or the job stream that is being defined is launched. Page 150

freedays

Specifies a freeday calendar for calculating workdays 152 for the job stream. It can also set Saturdays and Sundays as workdays. Defines a job and its dependencies. 154

job statement keyjob

Marks a job as key or critical in both the database 156 and in the plan for monitoring by applications, such as IBM Tivoli Business Systems Manager or IBM Tivoli Enterprise Console. Marks a job stream as key or critical in both the database and in the plan for monitoring by applications, such as IBM Tivoli Business Systems Manager or IBM Tivoli Enterprise Console. Sets a limit on the number of jobs that can be launched concurrently from the job stream. 157

keysched

limit matching

158

Defines the matching criteria used when a matching 159 criteria is not specified in the follows specifications in the job stream definition or in the job definition within the job stream. Defines the number of units of a resource required 160 by the job or job stream before it can be launched. The highest number of resources the job stream can be dependent from is 1024. Defines the dates on which the job stream is selected to run. Defines files that must be accessible before the job or job stream is launched. Specifies the action to take on a job or job stream whose until time has been reached. Defines the priority for a job or job stream. Defines prompts that must be replied to before the job or job stream is launched. Assigns a name to the job stream. Specifies the time used to set the job stream in the time line within the plan to determine successors and predecessors. 161 167 175 169 170 173 171

needs

on opens onuntil priority prompt schedule schedtime

until

Defines a latest time a job or a job stream can be 175 launched. When defined in a run cycle specifies the latest time a job or a job stream can be launched for that specific run cycle. Defines the date from which the job stream instance 177 starts.

validfrom

Notes: 1. Job streams scheduled to run on workstations marked as ignored are not added to the production plan when the plan is created or extended.

Chapter 7. Defining objects in the database

135

Job stream definition
2. Wrongly typed keywords used in job definitions lead to truncated job definitions stored in the database. In fact the wrong keyword is considered extraneous to the job definition and so it is interpreted as the job name of an additional job definition. Usually this misinterpretation causes also a syntax error or an inexistent job definition error for the additional job definition.

Examples
This is an example of job stream definition:
SCHEDULE M235062_99#SCHED_FIRST1 VALIDFROM 06/30/2005 ON RUNCYCLE SCHED1_PREDSIMPLE VALIDFROM 07/18/2005 "FREQ=DAILY;INTERVAL=1" ( AT 1010 ) ON RUNCYCLE SCHED1_PRED_SIMPLE VALIDFROM 07/18/2005 "FREQ=DAILY;INTERVAL=1" CARRYFORWARD PROMPT "parto o no?" PRIORITY 55 : M235062_99#JOBMDM PRIORITY 30 NEEDS 16 M235062_99#JOBSLOTS PROMPT PRMT3 B236153_00#JOB_FTA FOLLOWS JOBMDM END

See also
For the equivalent Job Scheduling Console task, see the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

136

IBM Tivoli Workload Scheduler: Reference Guide

Job stream definition

Job stream definition keyword details
This section describes the job stream definition keywords listed in table 29.

Chapter 7. Defining objects in the database

137

job stream keywords - at

at
Specifies a time dependency. If the at keyword is set then the job or job stream cannot start before the time set in this keyword. Syntax: at time [timezone|tz tzname][+n day[s]] [,...] Arguments: time Specifies a time of day. Possible values can range from 0000 to 2359.

tzname Specifies the time zone to be used when computing the start time. See Chapter 12, “Managing time zones,” on page 461 for time zone names. The default is the time zone of the workstation on which the job or job stream is launched. Note: If an at time and an until or deadline time are specified, the time zones must be the same. n Specifies an offset in days from the scheduled start date and time.

Comments: If an at time is not specified for a job or job stream, its launch time is determined by its dependencies and priority and its position in the preproduction plan is determined by the value assigned to the schedtime keyword. For more information about the schedtime keyword refer to “schedtime” on page 171. The time value in the at option is considered as follows: v If the time value is less than the value set in the startOfDay global option, it is taken to be for the following day. v If the time value is greater than the value set in the startOfDay global option, it is taken to be for the current day. If neither the at nor the schedtime keywords are specified in the job stream definition then, by default, the job or job stream instance is positioned in the plan at the time specified in the startOfDay global option. Examples: The following examples assume that the Tivoli Workload Scheduler processing day starts at 6:00 a.m. v The following job stream, selected on Tuesdays, is launched no sooner than 3:00 a.m. Wednesday morning. Its two jobs are launched as soon as possible after that time.
schedule sked7 on tu at 0300: job1 job2 end

v The time zone of workstation sfran is defined as America/Los_Angeles, and the time zone of workstation nycity is defined as America/New_York. The following job stream is selected to run on Friday. It is launched on workstation sfran at 10:00 a.m. America/Los_Angeles Saturday. job1 is launched on sfran as soon as possible after that time. job2 is launched on sfran at 2:00 p.m. America/New_York (11:00 a.m. America/Los_Angeles) Saturday. job3 is launched on workstation nycity at 4:00 p.m. America/New_York (1:00 p.m. America/Los_Angeles) Saturday.
sfran#schedule sked8 on fr at 1000 + 1 day: job1 job2 at 1400 tz America/New_York nycity#job3 at 1600 end

138

IBM Tivoli Workload Scheduler: Reference Guide

job stream keywords - carryforward

carryforward
Makes a job stream eligible to be carried forward to the next production plan if it is not completed before the end of the current production plan. Syntax: carryforward Examples: The following job stream is carried forward if its jobs have not completed before preproduction processing begins for a new production time frame.
schedule sked43 on th carryforward : job12 job13 job13a end

Chapter 7. Defining objects in the database

139

job stream keywords - comment

comment
Includes comments in a job stream definition and the jobs contained in a job stream. Syntax: # text Comments: Inserts a comment line. The first character in the line must be an pound sign #. You can add comments in a job stream definition immediately after the line with the schedule keyword, or in a job contained in a job stream definition immediately after the job statement line. Examples: The following example includes both types of comments:
schedule wkend on fr at 1830 ########################## # The weekly cleanup jobs ########################## # carryforward : job1 # final totals and reports job2 # update database end

140

IBM Tivoli Workload Scheduler: Reference Guide

job stream keywords - confirmed

confirmed
Specifies that a job’s completion must be confirmed by running a conman confirm command. See “confirm” on page 278 for more information. Syntax: confirmed Examples: In the following job stream, confirmation of the completion of job1 must be received before job2 and job3 are launched.
schedule test1 on fr: job1 confirmed job2 follows job1 job3 follows job1 end

Chapter 7. Defining objects in the database

141

job stream keywords - deadline

deadline
Specifies the time within which a job or job stream must complete. Jobs or job streams that have not yet started or that are still running when the deadline time is reached, are considered late in the plan. When a job (or job stream) is late, the following actions are performed: v Job is shown as late in conman and Job Scheduling Console. v An event is sent to the Tivoli Enterprise Console and the IBM Tivoli Business Systems Manager. v A message is issued to the stdlist and console logs. Note: When using the deadline keyword, ensure the bm check deadline variable is set to a value higher than 0 in the localopts configuration file on the target workstations for the job or job stream. For information, refer to IBM Tivoli Workload Scheduler Planning and Installation Guide. Syntax: deadline time [timezone|tz tzname][+n day[s] [,...] Arguments: time Specifies a time of day. Possible values range from 0000 to 2359.

tzname Specifies the time zone to be used when computing the deadline. See Chapter 12, “Managing time zones,” on page 461 for time zone names. The default is the time zone of the workstation on which the job or job stream is launched. n Specifies an offset in days from the scheduled deadline time.

Note: If a deadline time and an until or at time are specified, the time zones must be the same. Examples: The following example launches job stream sked7 every day and job jobc to start running at 14:30 and to be completed by 16:00.
schedule sked7 on everyday : jobc at 1430 deadline 1600 end

142

IBM Tivoli Workload Scheduler: Reference Guide

job stream keywords - description

description
Includes a description for the job stream. Syntax: description ”text” Comments: The maximum length of this field is 120 characters. Examples:
schedule test1 description ”Revenue at the end of the month” on monthend : job1 job2 job3 end

Chapter 7. Defining objects in the database

143

job stream keywords - draft

draft
Marks a job stream as draft. A draft job stream is not added to the preproduction plan. Syntax: draft Comments: A draft job stream is not considered when resolving dependencies and is not added to the production plan. After removing the draft keyword from a job stream you need to run JnextPlan command to add the job stream to the preproduction plan and so to the production plan. Examples:
schedule test1 on monthend draft : job1 job2 job3 end

144

IBM Tivoli Workload Scheduler: Reference Guide

job stream keywords - end

end
Marks the end of a job stream definition. Syntax: end Examples:
schedule test1 on monthend : job1 job2 job3 end << end of job stream >>

Chapter 7. Defining objects in the database

145

job stream keywords - every

every
Defines the repetition rate for a job. The job is launched repeatedly at the specified rate. If the job has a dependency that is not satisfied, the iteration is started only when the dependency is satisfied. Syntax: every rate Arguments: rate The repetition rate expressed in hours and minutes, in the format: hhmm. (The rate can be greater than 24 hours.)

Comments: If an every job abends , the iteration continues. If the every option is used without the at dependency, the rerun jobs scheduled respecting the every rate specified, starting from the time when the job actually started. IF AND ONLY IF the every option is used with the at dependency AND one rerun is delayed (for a dependency or for any other reason) THEN, while Tivoli Workload Scheduler realigns to the at time, there might one or two iterations that do not respect the every rate. For all other cases the every rate is always respected. In the example2 it is explained how Tivoli Workload Scheduler realigns to the at time if the job starts later than the at time set and a some iterations get lost. Examples: 1. The following example runs the job testjob every hour:
testjob every 100

2. The following example shows the job testjob1 that is stated to run every 15 minutes, between the hours of 6:00 p.m. and 8:00 p.m.:
testjob1 at 1800 every 15 until 2000

The job is supposed to run at 1800, 1815, 1830, and so on. If the job is submitted adhoc at 1833, the reruns are at 1833, 1834, 1845 and so on. Here it follows the explanation of the reason why the job iterations runs at 1833, 1834, 1845 and so on. At first notice that in a job there are two time values to consider: v the start_time, that is the time when the job is expected to run, it is set to the at time specified for the job or to the time when the rerun should be launched. This value can be viewed using conman showjobs before the job iteration starts. v the time_started, that is the time when the job actually starts, for example 1833. This value can be viewed it is displayed by using conman showjobs after the job iteration started. Because the job testjob1 was submitted adhoc at 1833, these are the information that you see immediately after the submission occurred: using conman showjobs TESTJOB1 HOLD 1800 in the Symphony file start_time=1800 (because the job is expected to run at 1800)

146

IBM Tivoli Workload Scheduler: Reference Guide

the job testjob1 will start immediately and the updated information become: using conman showjobs TESTJOB1 SUCC 1833 in the Symphony file start_time=1800 (because the job was expected to run at 1800) time_started=1833 (because the job started at 1833) When batchman calculates the time for the next iteration. after the job starts. it uses the following data: start_time=1800 rate=0015 current_time=1833 since the next iteration time (1800+0015=1815) would still be sooner than the current_time value (1833). batchman calculates again the time the next iteration has to start using these updated values: start_time=1830 rate=0015 current_time=1834 The fact that the next iteration time (1830+0015=1845) is later than the current_time value (1834). 3. Defining objects in the database 147 . indicates to batchman that the iteration is recovered and so the iteration time starting from 1845 on can be realigned with the planned iteration times set in the job definition by the keyword at and every.every time_started=NULL (because the job has not yet started) Since the start_time (1800) is smaller that the current time (1833). become the following: using conman showjobs TESTJOB1 SUCC 1834 in the Symphony file start_time=1830 (because that job iteration was expected to run at 1830) time_started=1834 (because that job iteration started at 1834) After this job iteration completed.job stream keywords . Assumed that this iteration is run at 1834 the information. batchman identifies the last planned iteration that was not run by adding to the start_time as many every_rate as possible without exceeding the current_time 1800 + 0015 + 0015 = 1830 < 1833 and then issues to run that iteration. The following example does not start the job testjob2 iteration until the job testjob1 has completed successfully: testjob2 every 15 follows testjob1 Chapter 7.

05/23/2005 The following example selects job stream testskd4 to run every day except two weekdays prior to any date appearing on a calendar named monthend: schedule testskd4 on everyday except monthend-2 weekdays 148 IBM Tivoli Workload Scheduler: Reference Guide . For explanation about remaining keywords contained in the except syntax refer to “on” on page 161.] [fdignore|fdnext|fdprev] Arguments: fdignore|fdnext|fdprev Specifies a rule that must be applied when the date selected for exclusion falls on a freeday. It can be one of the following: fdignore Do not exclude the date. Each instance of the keyword can contain any of the values allowed by the except syntax. 2005: schedule testskd3 on weekdays except 05/15/2005. fdnext Exclude the nearest workday after the freeday. See “on” on page 161 for more information. Examples: The following example selects job stream testskd2 to run every weekday except those days whose dates appear on calendars named monthend and holidays: schedule testskd2 on weekdays except monthend... 2005 and May 23. Each instance is equivalent to a run cycle to which you can associate a freeday rule. Comments: You can define multiple instances of the except keyword for the same job stream.except except Defines the dates that are exceptions to the on dates of a job stream. Multiple except instances must be consecutive within the job stream definition.holidays The following example selects job stream testskd3 to run every weekday except May 15. Syntax: except [runcycle name] [validfrom date] [validto date] [description ”text”] {date|day|calendar|request|”icalendar”} [.. fdprev Exclude the nearest workday before the freeday.job stream keywords .

except Select job stream sked4 to run on Mondays.job stream keywords . Defining objects in the database 149 . schedule sked4 on mo on tu. Tuesdays. schedule testskd2 on weekdays except MONTHEND fdprev Chapter 7. If the run date is a freeday. run the job stream on the nearest following workday. the freedays are Saturdays. If a date in monthend falls on a freeday. Do not run the job stream on Wednesdays. and 2 weekdays prior to each date listed in the monthend calendar. In this example. and all the dates listed in the default holidays calendar . exclude the nearest workday before it. MONTHEND -2 weekdays fdnext except we Select job stream testskd2 to run every weekday except for the days listed in monthend. Sundays.

The default is the same workstation as the dependent job or job stream. jobstreamname time jobname The name of the job stream that must have completed. the default is the same job stream as the dependent job. Comments: Dependency resolution criteria define how the job stream or job referenced by an external follows dependency is matched to a specific job stream or job instance in the plan. Specifies a time of day.jobname |@] [previous|sameday|relative from [+⁄−] time to [+⁄−] time|from time [+⁄−n day[s]] to time [+⁄−n day[s]] Use the following syntax for jobs: [follows {[netagent::][workstation#]jobstreamname{. the default is the workstation to which the network agent is connected. which is defined relatively to the scheduled start time of the dependent instance. The name of the job that must have completed. Same Day The job or job stream instance that resolves the dependency is the closest one in time scheduled to start on the day when the instance that includes the dependency is scheduled to run. Because the plan allows the inclusion of multiple instances of the same job or job stream. you can identify the instance that resolves the external follows dependency based on the following resolution criteria: Closest Preceding The job or job stream instance that resolves the dependency is the closest preceding the instance that includes the dependency.follows follows Defines the other jobs and job streams that must complete successfully before a job or job stream is launched. An at sign (@) can be used to indicate that all jobs in the job stream must complete successfully. The workstation on which the job or job stream that must have completed runs. Possible values range from 0000 to 2359. If a workstation is not specified with netagent. Comments: Use the following syntax for job streams: [follows {[netagent::][workstation#]jobstreamname[.job stream keywords . 150 IBM Tivoli Workload Scheduler: Reference Guide . For a job. Within a Relative Interval The job or job stream instance that resolves the dependency is the closest one in a time interval of your choice.jobname | @} [previous|sameday|relative from [+⁄−] time to [+⁄−] time | from time [+⁄−n day[s]] to time [+⁄−n day[s]] Arguments: netagent workstation The name of the network agent where the internetwork dependency is defined.

jobx The following example specifies not to launch jobd until joba in the same job stream.site2#sked5.job stream keywords . Examples: The following example specifies to not launch job stream skedc until the closest preceding job stream instance sked4 on workstation site1 have completed successfully: schedule skedc on fr follows site1#sked4 previous The following example specifies to not launch job stream skedc until the job stream instance of sked4 on workstation site1 that run between 12:00 of 3 days before to 3:00 of the day after have completed successfully: schedule skedc on fr follows site1#sked4 from 1200 –3 days to 0300 1 day The following example specifies not to launch job stream skedc until job stream sked4 on workstation site1 and job joba in job stream sked5 on workstation site2 have completed successfully: schedule skedc on fr follows site1#sked4. 2. Tivoli Workload Scheduler searches for the closest instance that precedes the depending job or job stream start time. Tivoli Workload Scheduler considers the correct predecessor instance as the closest instance that starts after the depending job or job stream start time.joba Do not launch sked6 until jobx in the job stream skedx on network agent cluster4 has completed successfully: sked6 follows cluster4::site4#skedx. If such an instance exists.job3 Chapter 7. The time interval is not related to the scheduled start time of the dependent instance.follows Within an Absolute Interval The job or job stream instance that resolves the dependency is the closest one in a time interval of your choice. the rule used by the product to identify the correct predecessor instance is the following: 1. this is the predecessor instance. For more information and examples on how external follows dependencies are resolved in the plan refer to “Managing external follows dependencies for jobs and job streams” on page 59. Defining objects in the database 151 . if multiple instances of potential predecessor job streams exist in the specified time interval. If there is no preceding instance. and job3 in job stream skeda have completed successfully: jobd follows joba.skeda. Regardless of which matching criteria are used.

are workdays. If Calendar_Name is not in the database when the command schedulr runs. do not run the job stream. -su or both after Calendar_Name.job stream keywords . schedule sked3 freedays GERMHOL -sa on APDATES fdignore 152 IBM Tivoli Workload Scheduler: Reference Guide . Comments: If you specify a freedays calendar in the job stream definition. schedule sked2 freedays GERMHOL on 01/01/2005. Do not use the names of weekdays for the calendar names. If Calendar_Name is not in the database. If the selected date is a freeday. then the workdays keyword takes the following value: workdays = everyday excluding saturday and sunday (unless you specified -sa or -su along with freedays) and excluding all the dates of Calendar_Name If you do not specify freedays in the job stream definition. -sa -su Saturdays are workdays. Tivoli Workload Scheduler issues an error message and uses the default calendar holidays in its place. In this example. workdays Select job stream sked3 to run two workdays before each date in the PAYCAL calendar. schedule sked3 freedays USAHOL -sa on PAYCAL -2 workdays Select job stream sked3 on the dates listed in the APDATES calendar. saturday and sunday are considered as freedays unless you specify the contrary by adding -sa. All days from Monday to Saturday. The keyword affects only the scheduling of the job streams for which it is specified. Workdays are every day from Monday to Saturday as long as they are not listed in the freedays calendar named USAHOL. Sundays and all the dates listed in the GERMHOL calendar are to be considered as freedays. Sundays are workdays.freedays freedays Use freedays to specify the name of a freedays calendar that lists the days when the job stream should not run. then: workdays = everyday excluding saturday and sunday and all the dates of the holidays calendar By default. Examples: Select job stream sked2 to run on 01/01/2005 and on all workdays as long as they are not listed in the freedays calendar named GERMHOL. Syntax: freedays Calendar_Name [-sa] [-su] Arguments: Calendar_Name The name of the calendar that must be used as the freedays calendar for the job stream. Tivoli Workload Scheduler uses this calendar as the base calendar for calculating workdays for the job stream. except for the dates listed in GERMHOL. Tivoli Workload Scheduler issues a warning message when you save the job stream.

freedays Select job stream testsked3 to run every weekday except 5/15/2005 and 5/23/2006. Saturdays. If the date to be excluded is a freeday.job stream keywords . and all the dates listed in GERMHOL are to be considered as freedays. freedays are all the dates listed in USAHOL. except for the dates listed in GERMHOL. If 5/23/2006 is a freeday. do not exclude it. Sundays. while workdays are all the days from Monday to Sunday that are not listed in USAHOL. In this example. All days from Monday to Friday. Defining objects in the database 153 . In this example. schedule testskd3 freedays GERMHOL on weekdays except 5/15/2005 fdignore except 5/23/2006 Select job stream testsked4 to run every day except two weekdays prior to every date listed in the MONTHEND calendar. are workdays. schedule testskd4 freedays USAHOL -sa -su on everyday except MONTHEND -2 weekdays fdnext Chapter 7. but exclude the nearest following workday. do not exclude it.

In fact the wrong keyword is considered extraneous to the job definition and so it is interpreted as the job name of an additional job definition. Note: Wrongly typed keywords used in job definitions lead to truncated job definitions stored in the database. Note that the cross reference report. Examples: The following example defines a job stream with three previously defined jobs: 154 IBM Tivoli Workload Scheduler: Reference Guide . the attributes or recovery options of its jobs are also added or modified. When a job stream is added or modified. any job modifications affect all other job streams that use the jobs.job statement job statement Jobs can be defined in the database independently (as described in “Job definition” on page 119). from that moment on. or as part of job streams. Comments: When defining a job as part of a job stream as the job stream definition is added to the database also the new job definition is added and can be referenced. are added to the plan even though they are not processed. Syntax: To define a job as part of a job stream. Note: Jobs scheduled to run on workstations marked as ignored. In either case. also from other job streams. use the following syntax inside the job stream definition: [workstation#]jobname [as newname] {scriptname filename | docommand “command”} streamlogon username [description “description”] [tasktype tasktype] [interactive] [rccondsucc ″Success Condition″] [recovery {stop | continue | rerun} [after [workstation#]jobname] [abendprompt “text”] ] To use a job already defined in the database in the job stream definition define job statement using the following syntax: [workstation#]jobname [as newname] Arguments: as The name you want to use to refer to the job instance within that job stream. For the other keywords refer to “Job definition” on page 119. Usually this misinterpretation causes also a syntax error or an inexistent job definition error for the additional job definition. Remember that when you add or replace a job stream. xref.job stream keywords . and belonging to job streams scheduled to run on active workstations. can be used to determine the names of the job streams including a specific job. the changes are made in the database and do not affect the production plan until the start of a new production plan. For more information about cross reference report refer to “xref” on page 424.

Defining objects in the database 155 .job stream keywords .job statement schedule bkup on fr at 20:00 : cpu1#jbk1 cpu2#jbk2 needs 1 tape cpu3#jbk3 follows jbk1 end The following job stream definition contains job statements that add or modify the definitions of two jobs in the database: schedule sked4 on mo : job1 scriptname “d:\apps\maestro\scripts\jcljob1” streamlogon jack recovery stop abendprompt “continue production” site1#job2 scriptname “d:\apps\maestro\scripts\jcljob2” streamlogon jack follows job1 end Chapter 7.

See the IBM Tivoli Workload Scheduler Planning and Installation Guide for information about enabling the key flag mechanism. Syntax: keyjob Examples: The following example SCHEDULE cpu1#sched1 ON everyday KEYSCHED AT 0100 cpu1#myjob1 KEYJOB END 156 IBM Tivoli Workload Scheduler: Reference Guide .keyjob keyjob The keyjob keyword is used to mark a job as key or critical in both the database and in the plan and for monitoring by applications. such as Tivoli Business Systems Manager or Tivoli Enterprise Console.job stream keywords .

Syntax: keysched Examples: The following example : SCHEDULE cpu1#sched1 ON everyday KEYSCHED AT 0100 cpu1#myjob1 KEYJOB END Chapter 7.keysched keysched The keysched keyword is used to mark a job stream as key or critical in both the database and in the plan and for monitoring by applications.job stream keywords . See the IBM Tivoli Workload Scheduler Planning and Installation Guide for information about enabling the key flag mechanism. such as Tivoli Business Systems Manager. Defining objects in the database 157 .

job stream keywords . Possible values are 0 through 1024.limit limit The limit keyword limits the number of jobs that can run simultaneously in a job stream on the same CPU. If you specify 0. you prevent all jobs from being launched even the one with priority set to GO. Syntax: limit joblimit Arguments: joblimit Specifies the number of jobs that can be running at the same time in the job stream. Examples: The following example limits to five the number of jobs that can run simultaneously in job stream sked2: schedule sked2 on fr limit 5 : 158 IBM Tivoli Workload Scheduler: Reference Guide .

SCHEDULE PDIVITA1#SCHED2 ON RUNCYCLE RULE1 "FREQ=DAILY.matching matching Sets a default for the matching criteria to be used in all follows dependencies where a matching criteria is not set in the job stream definition or in the jobs contained in the job stream.JOB1 : PDIVITA1#JOB1 PDIVITA1#JOB2 END In this sample the external follows dependency from PDIVITA1#SCHED2. v Needs the instance of job stream SCHED1 running the same day to complete before running.JOB1 inherits the matching criteria specified in the matching keyword.job stream keywords ." ON RUNCYCLE CALENDAR2 CAL1 MATCHING PREVIOUS FOLLOWS PDIVITA1#SCHED1. Syntax: matching {previous |sameday | relative from [+⁄−] time to [+⁄−] time Arguments: For information about the keyword used with matching see the “follows” on page 150 keyword. Examples: The following example shows the definition of job stream SCHED2 that: v Contains a job1 that can be run today only if it was run yesterday.@ SAMEDAY FOLLOWS PDIVITA1#SCHED2. Chapter 7. Defining objects in the database 159 .

a standard agent and its host can reference the same resources. The following example allows no more than two jobs to run concurrently in job stream sked4: schedule sked4 joba needs 1 jobb needs 1 jobc needs 2 jobd needs 1 end on mo. Specifies the name of the resource..job stream keywords . resourcename Comments: A job or job stream can request a maximum of 1024 units of a resource in a needs statement. the next job or job stream waiting for that resource waits until a current holder terminates AND the needed amount of resource becomes available. each needs statement is converted in holders.] Arguments: n workstation Specifies the number of resource units required. Resources can be used as dependencies only by jobs and job streams that run on the workstation where the resource is defined. not in both. Possible values are 1 to 1024 for each needs statement. If not specified. and two units of tapes become available: schedule sked3 on fr needs 3 cputime. The default is 1. However. Specifies the name of the workstation on which the resource is locally defined. Syntax: needs [n] [workstation#]resourcename [.needs needs The needs keyword defines resources that must be available before a job or job stream is launched.fr : jlimit jlimit jlimit <<runs alone>> jlimit 160 IBM Tivoli Workload Scheduler: Reference Guide . each holding a maximum of 32 units of a specific resource.2 tapes : The jlimit resource has been defined with two available units. Independently from the amount of available units of the resource. You can use the needs keyword either in a job stream definition or in the definition of the contained jobs. for a single resource there can be a maximum of 32 holders. Examples: The following example prevents job stream sked3 from being launched until three units of cputime. At run time.. If 32 holders are already defined for a resource.we. the default is the workstation where the dependent job or job stream runs..

The on keyword must follow the schedule keyword. validto date Delimits the time frame during which the job stream is active.. Defining objects in the database 161 . for a job stream that is scheduled to run on the 25th of May 2006 and on the 12th of June 2006 the value is: on 20060525.. See “except” on page 148 for more information..]For example. Syntax: on [runcycle name] [validfrom date] [validto date] [description ”text”] {date|day|calendar|request|”icalendar”} [.yyyymmdd][...] [fdignore|fdnext|fdprev] Arguments: runcycle name Specifies a label with a friendly name for the run cycle specified in the following lines. If omitted the job stream is not added to the preproduction plan. except Saturday and Sunday.. The calendar name can be followed by an offset in the following format: {+ | -}n {day[s] | weekday[s] | workday[s]} Where: n days The number of days.. for a job stream that is scheduled to run every Monday the value is: on mo calendar The dates specified in a calendar with this name. weekdays. validfrom date .. The syntax used for this type is: {mo|tu|we|th|fr|sa|su}For example. weekdays Every day of the week. or workdays. that is the job stream is added to the production plan. description ”text” Contains a description of the run cycle. Every day of the week. workdays Every day of the week. date Specifies a run cycle that runs on specific dates.on on This is a job stream keyword that defines when and how often a job stream is selected to run.20060612 day Specifies a run cycle that runs on specific days. The syntax used for this type is: yyyymmdd [. except for Saturdays and Sundays (unless Chapter 7.job stream keywords .

For example.INTERVAL=n] where the value set for validfrom is the first day of the resulting dates.BYFREEDAY|BYWORKDAY For example.INTERVAL=[-]n] [. Note: When attempting to run a job stream that contains ″on request″ times. for a job stream that is scheduled to run every freeday the value is: FREQ=DAILY.INTERVAL=n].BYDAY=weekday_list 162 IBM Tivoli Workload Scheduler: Reference Guide . for a job stream that is scheduled to run daily the value is: FREQ=DAILY For a job stream that is scheduled to run every second day the value is: FREQ=DAILY. icalendar Represents a standard used to specify a recurring rule that describes when a job stream runs.INTERVAL=2. To prevent a scheduled job stream from being selected for JnextPlan.INTERVAL=2 every free or work days by using the following format: FREQ=DAILY[. request Selects the job stream only when requested. v ″On request″ never takes precedence over ″on″. This is used for job streams that are selected by name rather than date. change its definition to ON REQUEST.{BYFREEDAY|BYWORKDAY|BYDAY=weekday_list| BYMONTHDAY=monthday_list}] where the default value for keyword INTERVAL is 1.INTERVAL=n].job stream keywords .BYWORKDAY every n weeks on specific weekdays by using the following format: FREQ=WEEKLY[. Using icalendar you can specify that a job stream runs: every n days by using the following format: FREQ=DAILY[. The syntax used for run cycle with type icalendar is the following: FREQ={DAYLY|WEEKLY|MONTHLY|YEARLY} [. consider that: v ″On request″ always takes precedence over ″at″.on otherwise specified with the freedays keyword) and for the dates marked either in a designated freedays calendar or in the holidays calendar.BYFREEDAY For a job stream that is scheduled to run every second workday the value is: FREQ=DAILY.

For example.BYDAY=1MO. Defining objects in the database 163 .WE][.BYMONTHDAY=27 For a job stream that is scheduled to run every six months on the 15th and on the last day of the month the value is: FREQ=MONTHLY.BYDAY=FR.TH][.BYMONTHDAY=monthday_list where the value set for monthday_list is represented by a list of [+number_of_day_from_beginning_of_month] [−number_of_day_from_end_of_month] [number_of_day_of_the_month] .INTERVAL=n]. for a job stream that is scheduled to run monthly on the 27th day the value is: FREQ=MONTHLY.BYDAY=2TU every n years by using the following format: FREQ=YEARLY[.BYMONTHDAY=15.SA] For example.job stream keywords .BYDAY=day_of_m_week_list where the value set for day_of_m_week_list is represented by a list of [+number_of_week_from_beginning_of_month] [−number_of_week_from_end_of_month] [weekday] For example. for a job stream that is scheduled to run every week on Friday and Saturday the value is: FREQ=WEEKLY.INTERVAL=n] where the value set for validfrom is the first day of the resulting dates. for a job stream that is scheduled to run yearly the value is: FREQ=YEARLY Chapter 7. For example.TU][.BYDAY=FR every n months on specific dates of the month by using the following format: FREQ=MONTHLY[.SA For a job stream that is scheduled to run every three weeks on Friday the value is: FREQ=WEEKLY.FR][.INTERVAL=6.on where the value set for weekday_list is [SU][.INTERVAL=n].-1 every n months on specific days of specific weeks by using the following format: FREQ=MONTHLY[.INTERVAL=6. for a job stream that is scheduled to run monthly on the first Monday and on the last Friday the value is: FREQ=MONTHLY.-1FR For a job stream that is scheduled to run every six months on the 2nd Tuesday the value is: FREQ=MONTHLY.INTERVAL=3.MO][.

In this example. 1999. Multiple on instances must be consecutive within the job stream definition. fdprev Add the nearest workday before the freeday. 2005 and May 24. Each instance is equivalent to a run cycle to which you can associate a freeday rule. The available settings are: fdignore Do not add the date. Each instance of the keyword can contain any of the values allowed by the on syntax.job stream keywords . and on 29/12/2005. and all the dates listed in the default HOLIDAYS calendar.05/24/2005 The following example selects job stream testskd4 every day except two weekdays prior to any date appearing in a calendar named monthend: schedule testskd4 on everyday except monthend -2 weekdays Select job stream sked1 to run all Mondays. run the job stream on the nearest preceding day. and on the dates listed in the apdates calendar: schedule sked3 on 6/15/99. Comments: You can define multiple instances of the on keyword for the same job stream. 164 IBM Tivoli Workload Scheduler: Reference Guide . Examples: The following example selects job stream sked1 on Mondays and Wednesdays: schedule sked1 on mo.on For a job stream that is scheduled to run every two years the value is: FREQ=YEARLY. the freedays are Saturdays. run the job stream on the nearest following workday.apdates The following example selects job stream sked4 two weekdays before each date appearing in the monthend calendar: schedule sked4 on monthend -2 weekdays The following example selects job stream testskd1 every weekday except on Wednesdays: schedule testskd1 on weekdays except we The following example selects job stream testskd3 every weekday except May 15.we The following example selects job stream sked3 on June 15. fdnext Add the nearest workday after the freeday. Sundays. 2005: schedule testskd3 on weekdays except 05/16/2005. Workdays are all days from Monday to Friday if they are not listed in the HOLIDAYS calendar. If Fridays are freedays.INTERVAL=2 fdignore|fdnext|fdprev Indicates the rule to be applied if the date selected for running the job or job stream falls on a freeday. Fridays. If Mondays and 29/12/2005 are freedays.

WE" FDNEXT ( START 0000 ) ON RUNCYCLE D3 VALIDFROM 08/25/2005 DESCRIPTION "daily" "FREQ=DAILY.08/28/2005.INTERVAL=5.08/30/2005.BYDAY=MO.@ FOLLOWS X8#COPYOFJS2.--------.BYDAY=1MO." DRAFT ON RUNCYCLE M5 VALIDFROM 08/25/2005 DESCRIPTION "monthly" "FREQ=MONTHLY.INTERVAL=7" ( AT 0100 ) ON RUNCYCLE SS1 VALIDFROM 08/25/2005 08/10/2005.-------–.-------TESTCLI SITE2 Y 08/25/2005 mdmDBE4 08/25/2005 mdmDBE4 SCHEDULE W5#TESTCLI VALIDFROM 08/25/2005 TIMEZONE ACT DESCRIPTION "Job stream with several run cycle settings. 12/29/2005 fdnext on fr fdprev This example shows the output of the display command of job stream testcli defined to run on different run cycles on workstation site2: display js=site2#testcli obtained in 120-column format by setting MAESTROCOLUMNS=120 before accessing the composer command-line: JobstreamName Workstation Draft ValidFrom ValidTo UpdatedBy UpdatedOn LockedBy ------------.INTERVAL=2" FDPREV ( START 0000 ) ON RUNCYCLE C2 VALIDFROM 08/25/2005 DESCRIPTION "calendar" ITALY +2 DAYS ( START 0000 ) ON RUNCYCLE M6 VALIDFROM 08/25/2005 DESCRIPTION "monthly" "FREQ=MONTHLY.1" ( START 0000 ) ON RUNCYCLE W4 VALIDFROM 08/25/2005 DESCRIPTION "weekly" "FREQ=WEEKLY. Defining objects in the database 165 .----------.08/18/2005.on schedule sked1 on mo.------.08/25/2005 ( AT 0000 UNTIL 0000 +1 DAYS ONUNTIL SUPPR DEADLINE 0000 +2 DAYS ) EXCEPT RUNCYCLE S1 VALIDFROM 08/25/2005 DESCRIPTION "simple" 08/26/2005.1TH.09/13/2005 ( AT 0000 ) CARRYFORWARD MATCHING SAMEDAY FOLLOWS LAB235004#SROBY2.RR FOLLOWS XA15::TPA KEYSCHED LIMIT 22 PRIORITY 15 : X8#PIPPO AS JOBTC CONFIRMED PRIORITY 13 KEYJOB FOLLOWS W5#POPO.@ Chapter 7.--------.job stream keywords .INTERVAL=2.08/20/2005.----.INTERVAL=5.2WE" ( START 0000 +2 DAYS ) ON RUNCYCLE Y7 VALIDFROM 08/25/2005 DESCRIPTION "yearly" "FREQ=YEARLY.BYMONTHDAY=-3.

F3 END AWSBIA291I Total objects: 1 The calendar ITALY is a custom calendar defined in the database that sets the workdays and holidays of the calendar in use in Italy. 166 IBM Tivoli Workload Scheduler: Reference Guide .on FOLLOWS X8#JS2.job stream keywords .

Examples: The following example checks to see that file c:\users\fred\ datafiles\file88 on workstation nt5 is available for read access before launching ux2#sked6: schedule ux2#sked6 on tu opens nt5#"c:\users\fred\datafiles\file88" The following example checks to see if three directories. enclosed in quotation marks. filename Specifies the name of the file. qualifier Specifies a valid test condition. In Windows.opens opens Specifies files that must be available before a job or job stream can be launched. exist under /users before launching job jobr2: jobr2 opens "/users"(-d %p/john -a -d %p/mary -a -d %p/roger) Chapter 7. is used to pass the value assigned to filename to the test function. True if the file exists and is a regular file. In both UNIX and Windows. Comments: The combination of the path of the file and the qualifiers cannot exceed 120 characters. If you use a workstation class.] Arguments: workstation Specifies the name of the workstation or workstation class on which the file exists. If you use a parameter. Boolean operator OR. True if the file exists and is readable. and the name of the file cannot exceed 28 characters. Defining objects in the database 167 . The default is the workstation or workstation class of the dependent job or job stream. the qualifier is passed to a test command. The file name must be fully qualified for all workstation types with the exception of extended agents (XAs). /mary.job stream keywords . it must be the same as that of the job stream that includes this statement. In UNIX. True if the file exists.. the expression %p.. True if the file exists and its size is greater than zero. Syntax: opens [workstation#]″filename″ [(qualifier)] [. Boolean operator AND. Entering (notempty) is the same as entering (-s %p). The valid qualifiers are: -d %p -e %p -f %p -r %p -s %p -w %p -a -o True if the file exists and is a directory. which runs as root in bin/sh. /john. where this is not a requirement. True if the file exists and is writable. and /roger. You can use Tivoli Workload Scheduler parameters as part or all of the file name string. If no qualifier is specified. it must be enclosed in carets (^).. the default is (-f %p). the test function is performed as the Tivoli Workload Scheduler user.

must have submit access to a job with the following attributes: name=cmdstest. the file below contains a command in the qualifier: /users/xpr/hp3000/send2(-n "`ls /users/xpr/hp3000/m*`" -o -r %p) If the qualifier contains another command. before running job job77: job77 opens nyc#"C:\tech\checker\startf"(-s %p -a -w %p) Security for test(1) Commands: In UNIX.fileeq logon=root jcl=the path of the opens files cpu=the CPU on which the opens files reside Note that cmdstest and fileeq do not exist. a special security feature prevents unauthorized use of other commands in the qualifier. 168 IBM Tivoli Workload Scheduler: Reference Guide . v In the security file.opens The following example checks to see if cron has created its FIFO file before launching job job6: job6 opens "/usr/lib/cron/FIFO"(-p %p) The following example checks to see that file d:\work\john\execit1 on workstation dev3 exists and is not empty. the user documenting the schedule or adding the Open Files dependency with a conman adddep command.job stream keywords . is not empty. the following checks are made: v The local option jm no root must be set to no. For example. and is writable. before running job jobt2: jobt2 opens dev3#"d:\work\john\execit1"(notempty) The following example checks to see that file c:\tech\checker\startf on workstation nyc exists.

By assigning a different priority to jobs or job streams you determine which one starts first. Chapter 7. the job that starts first is the one with the highest priority. Syntax: priority number | hi | go Arguments: number hi go Specifies the priority. jobb. the jobs are launched in the following order: joba.job stream keywords . job1. sked1 and sked2 have the following definitions in the database: schedule sked1 on tu priority 50 : job1 priority 15 job2 priority 10 end schedule sked2 on tu priority 10 : joba priority 60 jobb priority 50 end Since the job stream sked1 has the highest priority then the jobs are launched in the following order: job1. if the dependencies are solved. when set commands the immediate launch of the job or job stream it is free from other dependencies. instead. Examples: The following example shows the relationship between job stream and job priorities. Assuming the jobs and job streams are ready to be launched . the job stream priorities are the same. joba. job2. Defining objects in the database 169 . job2. If. If job2 has a dependency A and job1 has a dependency B and the dependency A becomes solved (while B remains not solved) then job2 starts before job1 even though job2 has a priority lower than the one set for job1. Represents a value higher than any value that can be specified with a number. if you set a priority for the job streams and for the jobs in the job streams: v The job stream that starts first is the one with the highest priority. The two job streams. Represents the highest priority that can be set. A priority of 0 prevents the job or job stream from launching. jobb.priority priority Sets the priority of a job or job stream. v Among the jobs in the job stream with the highest priority. Possible values are 0 through 99.

You can use one or more parameters as part or all of the text string. when not specifying a parameter.. Multiple strings separated by backlash n (\n) can be used for long messages.prompt prompt Specifies prompts that must be answered affirmatively before a job or job stream is launched.\n Do you want to launch it now? (y/n)" : j1 j2 follows j1 end 170 IBM Tivoli Workload Scheduler: Reference Guide . When a single affirmative reply is received for the prompt named apmsg. You can specify more than one promptname separated by commas but you cannot mix under the same prompt keyword prompts defined in the database with literal prompts... but it is not recorded in the log file.th prompt "All ap users logged out of ^sys1^? (y/n)" : job1 prompt apmsg job2 prompt apmsg end text The following example defines a literal prompt that appears on more than one line. Specifies a literal prompt as a text string enclosed in quotes (″). place its name between carets (^).job stream keywords .] prompt ″[: | !]text″ [. Within global prompts.] Arguments: promptname Specifies the name of a prompt in the database.. carets do not have to be preceded by a backslash. The first prompt is a literal prompt that uses a parameter named sys1. To use a parameter.. It is defined with backlash n (\n) at the end of each line: schedule sked5 on fr prompt "The jobs in this job stream consume \n an enormous amount of cpu time. You can include backslash n (\n) within the text for new lines. the message is displayed. If the string begins with an exclamation mark (!). Note: Within a local prompt. carets (^) must be preceded by a backslash (\) or they cause errors in the prompt. the dependencies for both job1 and job2 are satisfied. Syntax: prompt promptname [. the message is displayed but no reply is necessary. If the string begins with a colon (:). schedule sked3 on tu. Examples: The following example shows both literal and named prompts..

the job or job stream instance might start processing before the time set in the schedtime keyword if all its dependencies are resolved and if its priority allows it to start. If neither the at nor the schedtime keywords are specified in the job or job stream definition. While the production plan is in process. the start time field is blank. the value of the Start time field displayed on the Job Scheduling Console and Tivoli Dynamic Workload Console depends on the setting of the enPreventStart global option (which determines if job streams without an at dependency can start immediately. For an explanation on how the schedtime keyword is used to identify predecessors in the preproduction plan. Defining objects in the database 171 . is scheduled to start at 3:00 a. The default is the time zone of the workstation on which the job or job stream is launched. then its value is used to position the instance in the preproduction plan. without waiting for the run cycle specified in the job stream): v If enPreventStart is set to yes.. the start time is 12:00 AM converted to the time zone specified on the graphical user interface. Instead. Syntax: schedtime time [timezone|tz tzname][+n day[s]] [.schedtime schedtime Represents the time when the job stream is positioned in the plan. v The following job stream. the value specified in the schedtime keyword is used only to position the specific job or job stream instance in the preproduction plan. v If enPreventStart is set to no. | | | | | | | | For job streams with a schedtime definition. If schedtime is not specified and the at keyword is specified in the job or job stream. refer to “Managing external follows dependencies for jobs and job streams” on page 59. Chapter 7. on Wednesday morning.m. Examples: The following examples assume that the Tivoli Workload Scheduler processing day starts at 6:00 a. Its two jobs are launched as soon as possible after the job stream starts processing..m. Possible values are from 0000 to 2359. Comments: Differently from the at key. the job or job stream instance might start processing before the time set in the schedtime keyword if all its dependencies are resolved and if its priority allows it to start.job stream keywords . the schedtime key does not represent a time dependency.] Arguments: time Specifies a time of day. selected on Tuesdays.. it is assumed by default to be the value assigned to the startOfDay global option set on the master domain manager. n Specifies an offset in days from the scheduled start date and time. The at and schedtime keywords are mutually exclusive. While the production plan is in process. “Managing time zones. tzname Specifies the time zone to be used when calculating the start time. See Chapter 12.” on page 461 for time zone names. that is it does not state a time before which a job or job stream cannot start. The value assigned to schedtime does not represent a dependency for the job stream.

America/Los_Angeles) Saturday.m. job3 is launched on workstation nycity at 4:00 p. America/New_York (11:00 a.m. America/Los_Angeles Saturday (as specified by the + 1 day offset). America/New_York (1:00 p.schedtime schedule sked7 on tu schedtime 0300: job1 job2 end v The time zone of workstation sfran is defined as America/Los_Angeles. Job job1 is launched on sfran as soon as possible after the job stream starts processing.m.job stream keywords .m. Job job2 is launched on sfran at 2:00 p. sfran#schedule sked8 on fr schedtime 1000 + 1 day: job1 job2 at 1400 tz America/New_York nycity#job3 at 1600 end 172 IBM Tivoli Workload Scheduler: Reference Guide . America/Los_Angeles) Saturday.m. It is scheduled to start on workstation sfran at 10:00 a. Job stream sked8 is selected to run on Friday. and the time zone of workstation nycity is defined as America/New_York.

or deadline for that job. If none of the mentioned time zones is set.job stream keywords . if you use a time zone in a time restriction. and must be followed by the on keyword.schedule schedule Specifies the job stream name. such as deadline and until. the time zone conversion that is performed when processing jobs and job streams across the Tivoli Workload Scheduler network is made respecting the following criteria: 1. timezone|tz tzname Specifies the time zone to be used when managing for the job stream. Regardless of whether you are defining a job or a job stream. Defining objects in the database 173 . “Managing time zones. For information on time zone settings. It can contain up to 16 characters. and underscores. then the time zone used is the one set on the master domain manager. in which case the time zone set for the job is converted into the time zone set for the job stream. 3. for example at then you must use the same time zone when specifying the other time restrictions. This setting is ignored if the global option enTimeZone is set to no on the master domain manager. The name must start with a letter. until. this must be the first keyword in a job stream. To manage all possible time zone settings. Examples: This is the definition of e time zone of workstation sfran defined on workstation sfran on which is set the time zone America/New_York. jstreamname Specifies the name of the job stream. until. These time zones can differ from each other. If a time zone is not set for a job within a job stream. Syntax: schedule [workstation#]jstreamname [timezone|tz tzname] Arguments: workstation Specifies the name of the workstation on which the job stream is launched. and can contain alphanumeric characters. Comments: In a job stream definition you can set a time zone for the entire job stream by using the timezone keyword in the validity interval or when specifying time restrictions using at. In a job stream definition you can set a time zone for the entire job stream and for the jobs it contains. If a time zone is not set for a job stream. The time zone set for job2 to run of workstation LA is defined as America/Los_Angeles. The default is the workstation on which composer runs to add the job stream. 2. With the exception of comments. refer to Chapter 12. or deadline. then that job inherits the time zone set on the workstation where the job is planned to run. dashes.” on page 461. then the time zone set is the one set on the workstation where the job stream is planned to run. Chapter 7. You can set also a time zone for a job contained in a job stream by setting keywords at.

schedule schedule sfran#sked8 tz America/New_York on fr at 1000 + 1 day: job1 LA#job2 at 1400 tz America/Los_Angeles end 174 IBM Tivoli Workload Scheduler: Reference Guide .job stream keywords .

Any job or job stream that was dependent on the completion of a job or job stream that was cancelled. specifies the latest time a job stream must be completed or the latest time a job can be launched. the status for the job stream is calculated following the usual rules. tzname Specifies the time zone to be used when computing the time. Note: If an until time and an at or deadline time are specified. the cancel operation on the job is issued by the FTA on which the job runs. the time zones must be the same. Syntax: until time [timezone|tz tzname][+n day[s]] [onuntil action] Arguments: time Specifies the time of day. from the scheduled date and time. When using onuntil canc on jobs. The possible values are 0000 through 2359. Note: When using onuntil canc at job stream level. A job or job stream is cancelled when the until time specified expires. onuntil action Depending on the object definition the until keyword belongs to. Note: Both the keyword until and deadline can be used in the same definition but they must be expressed using the same time zone setting. Defining objects in the database 175 .until until Depending on the object definition the until keyword belongs to. suppressed jobs are not considered in the calculation. When the until time expires for a job. define as owner of the job stream the workstation highest in the hierarchy of the scheduling environment.job stream keywords . v The action to be taken on a job stream whose until time has expired but the job stream is not yet completed in SUCC state. runs because the dependency no longer exists. The default is the time zone of the workstation on which the job or job stream is launched. Once the until time expired on a job stream.” on page 461 for time zone names. In case the job stream contains at least one every job its status is HOLD. specifies: v The action to be taken on a job whose until time has expired but the job has not yet started. “Managing time zones. This is he default behavior. the job moves to HOLD status or keeps any previous status which is a final status cont The job or job stream runs when all necessary conditions are met and a notification message is written to the log when the until time elapses. See Chapter 12. n Specifies an offset. The following are the possible values of the action parameter: suppr The job or job stream and any dependent job or job stream do not run. canc Chapter 7. in days. among all workstations that own jobs contained in the job stream.

job2 runs at 4:30 p. The jobs are to be launched within this interval: schedule sked4 on fr at 0800 + 2 days until 1300 + 2 days : job1 job2 at 0900 <<launched on sunday>> job3 follows job2 at 1200 <<launched on sunday>> end The following example launches job stream sked8 on weekdays at 4:00 p. or at the latest 4:50 p. it is cancelled.@ : job02 end SCHEDULE sked03 on everyday follows sked01.m. at which time. when its until time is reached: schedule sked1 until 1700 onuntil cont The following example launches job1 between 1:00 p.m.m.m.m. and should complete running by 5 p. When the until event occurs..m.m.. The jobs are to be launched as follows: job1 runs at 4 p.m. 4:20 p.m. schedule sked8 on weekdays at 1600 deadline 1700 : job1 at 1600 until 1620 onuntil cont job2 at 1630 until 1650 onuntil canc end The following example launches job stream sked01.m.. and 5:00 p. it is considered a late job stream. a notification message is written to the log and it starts running.m. SCHEDULE sked01 on everyday: job01 until 2035 onuntil suppr end SCHEDULE sked02 on everyday follows sked01. if job2 has not yet started... and 11:30 p. or at the latest. on Tuesdays: schedule sked1 on tu until 1700 : The following example launches sked1 at 5:00 p. the job stream sked02 is run because the job stream sked01 is placed in SUCC state.m.job stream keywords . is not run because it has a punctual time dependency on job job01 and this dependency has not been released.until Examples: The following example prevents sked1 from launching after 5:00 p. and 1:00 p. on Mondays: schedule sked3 on mo : joba at 2230 every 0015 until 2330 end The following example launches job stream sked4 on Sundays between 8:00 a.m.m.job01 : job03 END 176 IBM Tivoli Workload Scheduler: Reference Guide . if job1 has not yet started. If the job stream is not completed by 5 p. on weekdays: schedule sked2 on weekdays : job1 at 1300 until 1700 end The following example launches joba every 15 minutes between 10:30 p. instead.m. The job stream sked03. at which time.

but having different validity intervals. all versions of that job stream are locked. The validity time is set using the validfrom key in the job stream definition. Different versions of the same job stream continue to share the name and workstation fields after their creation. and the validto date is automatically set to the value of the validfrom date of the following version. that is it must be included in a production plan if the production plan duration includes that date. the change is propagated in all its versions. Chapter 7. The job stream identified as the dependency is the one whose validity interval is during the period the dependency is active. The concept of versions of the same job stream sharing the same jobstreamname and the same workstationname are key when managing dependency on that job stream. If you lock a version of the job stream. which is a time frame within which the job stream is included in the preproduction plan. “Managing objects in the database composer. If you change the name of a job defined in a job stream version then the new job name is propagated in all versions of the job stream. When defining a job stream version. you are only asked to enter the validfrom date. if you modify something. the internal and external job stream associations remain consistent. Syntax: validfrom date Arguments: validfrom date Defines from which date the job stream is active. This means that. If you change the jobstreamname or the workstationname in one version of the job stream.job stream keywords .” on page 189. If you modify the name of a version or change the workstation on which it was defined.validfrom validfrom You can set a validity time for a job stream. other than the jobstreamname or the workstationname. the change is applied to all versions of that job stream. Comments: Different versions of the same job stream can be defined by creating different job streams with the same name and workstation. Defining objects in the database 177 . For more information refer to Chapter 8. In fact when you define an external follows dependencies on a job stream you identify the predecessor job stream using its jobstreamname and workstationname. The validto date is shown when issuing list and display command when MAESTROCOLUMNS is set to 120. Note: If the keywords used in the job stream definition are validfrom and validto. the corresponding filtering keywords used when issuing commands against object definitions stored in the database are valid from and valid to.

n) v <eventRule name=" " ruleType=" " isDraft=" "> (1. The rule language schemas defined in eventRules.” on page 89 for an overview of scheduling event rules. The following is a list of all the language elements used for defining an event rule. The first 1 indicates that the language element is required. You can configure an environment variable on your computer to automatically open an XML editor of your choice to work with event rule definitions. 1 indicates that if coded. the time interval it is active. 1) – <activeTime start=" " end=" "> (0. 1 indicates that the language element is required. Complex rules may include multiple events and multiple actions. 1) – <description> (0. n indicates that multiple occurrences are allowed. Syntax Unlike all other scheduling object definitions. 1) (0. the time frame of its validity. (1. only 1 occurrence is allowed. 2 indicates that 2 occurrences are required. n) Meaning 0 indicates that the language element is optional. to provide syntactic help. multiple occurrences are allowed. Notation (0. 0 indicates that the language element is optional. you define event rules directly in XML language with the use of any XML editor.xsd and in FilteringPredicate. 1 indicates that the language element is required. Table 30. The files are located in the schemas subdirectory of the Tivoli Workload Scheduler installation directory. The definition of an event rule correlates events and triggers actions. See “The composer editor” on page 191 for details.xsd and in FilteringPredicate. Explanation of the notation defining the number of occurrences for a language element. Refer to Chapter 6. and other information required to decide when actions are triggered. n indicates that if coded. 1) – <validity from=" " to=" "> (0. The XML describing the event rule must match the rule language schemas defined in EventRules. Table 30 explains the meaning of the notation that follows each language element. 2) (1. 1) 178 IBM Tivoli Workload Scheduler: Reference Guide . “Running event-driven workload automation. It includes information related to the specific events (eventCondition) that the rule must detect and the specific actions it is to trigger upon their detection or timeout (action). n represents an unbounded number. depending upon the XML editor you have.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Event rule definition A scheduling event rule defines a set of actions that are to run upon the occurrence of specific event conditions.xsd. 1) (1. An event rule definition is identified by a rule name and by a set of attributes that specify if the rule is in draft state or not.xsd are used to validate your rule definitions and. The second 1 indicates that only 1 occurrence is allowed. 1) – <timeZone> (0.

that the rule is defined to detect. v <eventRuleSet> (1. n) .<scope> (0. are saved in the database. The next time you open a rule definition. n) v <attributeFilter name=" " operator="ne"> (0. An eventRule element typically includes: v A number of required and optional rule attributes v One or more event conditions v One or more rule actions. Defining objects in the database 179 . Use the description attribute to write any additional information instead.<filteringPredicate> (0.and on their correlation . Note that none of the comments you might write in the XML. n) Use the eventRuleSet language element also if you have to enclose a single rule definition. ruleType The rule type is based on the number of events . n) . n) . It can be one of the following: Chapter 7.<scope> (0. n) – <value> (1. 1) – <eventRule> (1. Underscore (_) and dash (-) characters are allowed. n) – <value> (1.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | – <timeInterval amount=" " unit=" "> (0. it must start with a letter. n) – <value> (1.<value> (1. 1) . 1) v <attributeFilter name=" " operator="ge"> (0. 1) . in the form <!--text-->.<parameter name=" ">(1. 2) – <correlationAttributes> (0. the comments you wrote the first time will be gone. 1) v <attributeFilter name=" " operator="range"> (0. 1) Event rule definitions are grouped into event rule sets. n) v <attributeFilter name=" " operator="le"> (0. 1) v <attributeFilter name=" " operator="eq"> (0. n) – <action actionProvider=" " actionType=" " responseType=" "> (0. n) – <value> (1. It can be up to 40 alphanumeric characters in length. 1) .<description> (0. 1) . although rules with no actions are also allowed The rule attributes are: v Required attributes: name The name of the event rule.<attribute name=" "> (1. 1) – <eventCondition eventProvider=" " eventType=" "> (1. Arguments The keywords describing an event rule are the following XML tags: eventRule The scheduling object that encloses the definition of multiple event conditions and multiple rule actions in addition to a set of attributes that define when the rule is activated. 1) – <value> (1. and cannot contain blanks.

It can be of up to 120 characters. Remember to write any XML special characters you might use in the XML special notation. For example. The default is no. for & – &gt. when one or more events arrive but the complete sequence does not arrive within the specified time window. Values can be yes or no. set The rule is activated when an unordered sequence of events arrives within a specific time interval. 2:10 becomes 3:10. filter The rule is activated upon the detection of a single specific event. activeTime Specifies the rule activity time window within each day of validity in terms of: isDraft Specifies if the rule definition is currently enabled. v Optional attributes: description A description of the rule. timeZone Specifies a different time zone for the execution of the rule. for < – &quot. to yy-mm-dd The validity period ends at midnight (of the rule time zone) of the specified day.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | validity Specifies the rule validity period in terms of: from yy-mm-dd The validity period starts at midnight (of the rule time zone) of the specified day. 180 IBM Tivoli Workload Scheduler: Reference Guide . – On the day that DST is turned off (the clock is adjusted backward one hour) the rule operation times that fall within the hour duplicated by the application of DST are regarded without DST. The application of daylight saving time (DST) has an impact on the activeTime interval (described next) of event rules: – On the day that DST is turned on (the clock is adjusted forward one hour) the rule operation times that fall within the hour absorbed by the application of DST are moved forward by one hour. for " and so on. for > – &lt. The default time zone is the time zone defined on the workstation where the event processing server resides. sequence The rule is activated when an ordered sequence of events arrives within a specific time interval. such as: – &amp. Rules of type set and sequence can also be activated on timeout.

Defining objects in the database 181 . unit The time unit in one of the following: – hours – seconds – milliseconds This attribute is mandatory when there are timeout actions in the event rule definition. The time interval starts from the moment the first event specified in the rule is detected. minutes. FileMonitor Monitors events affecting files. Event type JobStatusChanged JobUntil JobSubmit JobCancel This event is sent when. and seconds. TWSObjectsMonitor events. Table 31 lists the TWSObjectsMonitor events. eventCondition The event condition is made up by the following attributes: v Required attributes: eventProvider Identifies the event monitoring provider that can capture a type of event. The event providers supplied at installation time are: TWSObjectsMonitor Monitors the status of Tivoli Workload Scheduler plan objects. Every event can be referred to an event provider. timeInterval Applies to rules that include timeout actions. This event provider runs on every Tivoli Workload Scheduler agent and sends the events to the event processing server.. end hh:mm:ss The end of the time window when the rule is active in hours. eventType Specifies the type of event that is to be monitored. and seconds. Specify the time interval in terms of: amount The length of the time interval in time units. minutes.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | start hh:mm:ss The beginning of the time window when the rule is active in hours.. it refers to the next day. Specifies the time interval within which all the events specified in the rule must have been received before a corrective timeout action is started. If the time is earlier than in start hh:mm:ss. The following tables list the event types by event provider. the status of a job changes the latest start time of a job has elapsed a job is submitted a job is cancelled Chapter 7. Table 31. Click on the event types to see their properties.

TWSObjectsMonitor events. FileMonitor events. or property name.. Event type FileCreated FileDeleted ModificationCompleted This event is sent when. It can be of up to 120 characters. filteringPredicate The filtering predicate sets the event conditions that are to be monitored for each event type. Table 32.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 31. It cannot be specified by users. (continued) Event type JobRestart JobLate JobStreamStatusChanged JobStreamCompleted JobStreamUntil JobStreamSubmit JobStreamCancel JobStreamLate WorkstationStatusChanged ApplicationServerStatusChanged ChildWorkstationLinkChanged This event is sent when. The scope is automatically generated from what is defined in the XML. a job is restarted a job becomes late the status of a job stream changes a job stream has completed the latest start time of a job stream has elapsed a job stream is submitted a job stream is cancelled a job stream becomes late a workstation is started or stopped the embedded WebSphere Application Server has stopped or is restarting the workstation defined in the event rule links or unlinks from its parent workstation (the parent workstation sends the event) the parent workstation links or unlinks from the workstation defined in the event rule (the child workstation sends the event) a prompt is asked or replied ParentWorkstationLinkChanged PromptStatusChanged Table 32 lists the FileMonitor events. a file is created a file is deleted a file is modified (the event is sent only if two consecutive monitoring cycles have passed since the file was created or modified with no additional changes being detected) a specific string is found in a file (this event can be used to monitor application or system logs) LoggedMessageWritten v Optional attributes: scope One or more qualifying attributes that describe the event. Refer to “Event 182 IBM Tivoli Workload Scheduler: Reference Guide .. of the event type that is to be monitored... It is made up by: attributeFilter The attribute filter is a particular attribute of the event type that is to be monitored: – Is defined by the following elements: name The attribute.

ge (equal or greater than) . You may save such rules as draft and add actions later before they are deployed.eq (equal) . All the mandatory property names without a default value must have a filtering predicate defined. each active rule has one rule copy that runs in the event processing server. However. sometimes the same rule is needed for different groups of events. correlationAttributes The correlation attributes provide a way to direct the rule to create a separate rule copy for each group of events that share common characteristics.le (equal or less than) . operator Can be: . which are often related to different groups of resources.range (range) – Includes one or more: value The value on which the operator must be matched. TWSAction Runs one of the following conman commands: – submit job (sbj) – submit job stream (sbs) – submit command (sbd) – reply to prompt (reply) Chapter 7. MessageLogger Logs the occurrence of a situation in an internal auditing database. The action providers available at installation time are: TECEventForwarder Forwards the event to an external TEC (Tivoli Enterprise Console) server (or any other application capable of listening to events in TEC format). v Is defined by the following required attributes: actionProvider The name of the action provider that can implement one or more configurable actions. Use with set and sequence rule types.ne (not equal) . Event rule definitions with events but no actions are syntactically accepted. Note that every event type has a number of mandatory attributes. action The action that is to be triggered if the event is detected. although they may have no practical significance. Each is defined by: attribute name=" " The object attribute that you are correlating. Using one or more correlation attributes is a method for directing a rule to create a separate rule copy for each group of events with common characteristics. or property names. Not all the mandatory property names have default values. Defining objects in the database 183 . Typically.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | providers and definitions” on page 509 for a list of property names for every event type. You can specify one or more attributes. MailSender Connects to an SMTP server to send an e-mail.

The scheduler will however let you save event rules where timeout actions have been defined without specifying a time interval. The following table lists the action types by action provider. Applies to set and sequence rules only. actionType Specifies the type of action that is to be triggered when a specified event is detected. Note that timeout actions are not run if you do not specify a time interval. Table 33. Remember to write any XML special characters you might use in the XML special notation. for > – &lt. because you could set the time interval at a later time. for " and so on. 184 IBM Tivoli Workload Scheduler: Reference Guide . It can be of up to 120 characters. Action types by action provider. Applies to all rule types. such as: – &amp. One or more qualifying attributes that describe the action. v Includes the following optional attributes: description A description of the action. Action provider TECEventForwarder MailSender MessageLogger Action types TECFWD SendMail PostOperatorMessage sbs (SubmitJobStream) sbj (SubmitJob) sbd (SubmitAdHocJob) reply (ReplyPrompt) RunCommand responseType Specifies when the action is to run. The commands are run on the same computer where the event processor runs. Every action can be referred to an action provider. Values can be: onDetection The action starts as soon as all the events defined in the rule have been detected. Until then. for < – &quot. See also “Rule operation notes” on page 102. It can be of up to 120 characters.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scope GenericAction TWSAction GenericAction Runs non-Tivoli Workload Scheduler commands. Click on the action types to see their properties. It cannot be specified by users. The scope is automatically generated from what is defined in the XML. for & – &gt. only actions with the onDetection response type are processed. onTimeOut The action starts after the time specified in timeInterval has expired but not all the events defined in the rule have been received.

for example to format the schedTime of a job stream in the body of an e-mail.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v Includes a list of one or more parameters.property} Replaces the value as is. or property names. The eventCondition section of the rule is coded as follows: <eventCondition name=“event1” eventProvider=“TWSObjectsMonitor” eventType=“JobStatusChanged”> <filteringPredicate> <attributeFilter name=“JobName” operator=“eq”> <value>job15@</value> </attributeFilter> <attributeFilter name=“Workstation” operator=“eq”> <value>@</value> </attributeFilter> <attributeFilter name=“Status” operator=“eq”> <value>Error</value> </attributeFilter> </filteringPredicate> </eventCondition> Wild cards are used to generalize the desired event condition to all the job instances whose name starts with job15 and to their associated Chapter 7. submit that job again. for example the schedTime of a job stream. Note that you can use variable substitution also if no attributeFilter was specified for an attribute and also if the attribute is read-only. property Is the attributeFilter name in the filtering predicate of the triggering event condition. write the value for the action parameter you intend to substitute in either of these two forms: – ${event. This means that when you define action parameters. the task of an event rule is to detect when any of the jobs that have a name starting with job15 end in error and. You can use variable substitution. Where: event Is the name you set for the triggering eventCondition. value See “Action providers and definitions” on page 537 for a list of possible values or value types. or property names. – %{event. available for every action type. All action types have at least one mandatory parameter.property} Replaces the value formatted in human readable format. when that happens. you can use the property names of the events that trigger the event rule to replace the value of the action property name. Every parameter is defined by: parameter name=" " See “Action providers and definitions” on page 537 for a list of parameters. Defining objects in the database 185 . To do this. This is useful to pass the information to an action that works programmatically with that information. For example. The value taken by the attribute filter when the rule is triggered is replaced as a parameter value in the action definition before it is performed. This is useful to pass the information to an action that forwards that information to a user.

As soon as the file is received.XLS.0/event-management/rules” xsi:schemaLocation=“http://www. JOB7 must start to process the file. The action section is: <action actionProvider=“TWSAction” actionType=“sbj” responseType=“onDetection”> <description>Submit again the job that ended in error</description> <parameter name=“JobDefinitionName”> <value>${event1.XLS is finished.Workstation}</value> </parameter> </action> Examples JOB7 has a file dependency on DAILYOPS. If this does not happen.xsd”> <EventRule name=“sample_rule” ruleType=”sequence” isDraft=“no”> <description>An e-mail is sent if job JOB7 does not start within a minute after file DAILYOPS. The second event is the submission of JOB7.XLS</value> </attributeFilter> <attributeFilter name=“Workstation” operator=“eq”> <value>ACCREC03</value> </attributeFilter> <attributeFilter name=“SampleInterval” operator=“eq”> <value>300</value> </attributeFilter> </filteringPredicate> </eventCondition> <eventCondition name=“job_JOB7_problem_event” eventProvider=“TWSObjectMonitor” eventType=“JobSubmit”> <filteringPredicate> <attributeFilter name=“JobStreamWorkstation” operator=“eq”> <value>ACCREC03</value> </attributeFilter> <attributeFilter name=“Workstation” operator=“eq”> <value>ACCREC03</value> </attributeFilter> <attributeFilter name=“JobStreamName” operator=“eq”> <value>JSDAILY</value> 186 IBM Tivoli Workload Scheduler: Reference Guide . The following rule controls that JOB7 starts within one minute after the transfer of DAILYOPS. As soon as this event is detected.XLS on the workstation to which it is to be transferred.com/xmlns/prod/tws/1.org/2001/XMLSchema-instance” xmlns=“http://www.0” encoding=“UTF-8”?> aeventRuleSet xmlns:xsi=“http://www. a rule instance is created and a one minute interval count is begun to detect the next event condition.com/xmlns/prod/tws/1. an e-mail is sent to the evening operator. This is accomplished by defining two sequential event conditions that have to monitored: 1.Event rule definition | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | workstation.w3.0/event-management/rules EventRules. a?xml version=“1. the rule times out and the SendMail action is started.XLS is created</description> <timeZone>America/Indianapolis</timeZone> <validity from=“2007-01-01” to=“2007-12-31” /> <activeTime start=“20:00:00” end=“22:00:00” /> <timeInterval amount=“60” unit=“seconds” /> <eventCondition name=“DAILYOPS_FTPed_event” eventProvider=“FileMonitor” eventType=“FileCreated”> <filteringPredicate> <attributeFilter name=“FileName” operator=“eq”> <value>c:/dailybus/DAILYOPS. Variable substitution is used in the action section to submit again the specific job that ended in error on the same workstation. The first event that triggers the rule is the creation of file DAILYOPS.ibm.JobName}</value> </parameter> <parameter name=“JobDefinitionWorkstationName”> <value>${event1. If this event fails to be detected within the specified time interval. 2.ibm.

</value> </parameter> </action> </eventRule> </eventRuleSet> Note that the scope does not show the first time the rule is defined. Go to “Event rule examples” on page 97 to find more event rule examples. Chapter 7.com</value> </parameter> <parameter name=“Subject”> <value>Job JOB7 failed to start within scheduled time on workstation ACCREC03. Defining objects in the database 187 .Event rule definition | | | | | | | | | | | | | | | | | | | | </attributeFilter> <attributeFilter name=“JobName” operator=“eq”> <value>JOB7</value> </attributeFilter> </filteringPredicate> </eventCondition> <action actionProvider=“MailSender” actionType=“SendMail” responseType=“onTimeOut”> <description>Send email to evening operator stating job did not start</description> <parameter name=“To”> <value>eveoper@bigcorp.

Event rule definition 188 IBM Tivoli Workload Scheduler: Reference Guide .

print v lock v modify v new v rename v unlock © Copyright IBM Corp.composer This chapter describes how you use the composer command-line program to manage scheduling objects in the Tivoli Workload Scheduler database. The following commands now include event rules as target objects: v create-extract v delete v display v list. 1999. Managing objects in the database . 2007 189 .Chapter 8. It is divided into the following sections: v “What is new in managing objects in the database” v “Using the composer command-line program” on page 190 v “Running commands from composer” on page 194 What is new in managing objects in the database | | | | | | | | | | | | The composer command line program of Version 8.4 is enhanced to include command line management of event rule definitions in the database.

MAESTROLPLINES Specifies the number of lines per page. Setting up the composer environment This section describes how you set up your composer environment. appending the output to the end of the file. the standard shell variables.offline option in composer commands is used to print the output of a command. Terminal output The shell variables named MAESTROLINES and MAESTROCOLUMNS determine the output to your computer. MAESTROLPCOLUMNS Specifies the number of characters per line.offline option in composer commands is used to print the output of a command. >> file Redirects output to a file. composer does not pause at the end of a page. it is created. If the file does not exist. the following variables control the output: Windows variables: MAESTROLP Specifies the file into which a command’s output is written. If MAESTROLINES (or LINES) is set to zero or a negative number. it is created. When you include it. || command Pipes output to a system command or process. LINES and COLUMNS. The system command is not run if there is no output. Offline output The . If the file does not exist. UNIX variables: The . the following shell variables control the output: MAESTROLP Specifies the destination of a command’s output. The default is 60. The default is 132.Using composer command-line program Using the composer command-line program The composer command line program manages scheduling objects in database. | command Pipes output to a system command or process. The system command is run whether or not output is generated. 190 IBM Tivoli Workload Scheduler: Reference Guide . composer prompts to continue. You must install the Tivoli Workload Scheduler Command Line Client feature on fault-tolerant agents and systems outside the Tivoli Workload Scheduler network to use the composer command-line program. If either variable is not set. overwriting the contents of that file. The default is stdout. The default value for MAESTROLP is | lp -tCONLIST which directs the command output to the printer and places the title “CONLIST” in the banner page of the printout. are used. Set it to one of the following: > file Redirects output to a file. When you include it. At the end of each screen page.

The prompt can be up to ten characters long. set the EDITOR environment variable to the path and name of the new editor before you run composer. or modify commands on an event rule.cmd Then use the following syntax to run commands from the composer user interface: Chapter 8. new. it defines the editor. The XML editor opens automatically each time you run the composer add./TWS_home/tws_env. The default is 60. The default is 132. To change the editor. MAESTROLPCOLUMNS Specifies the number of characters per line. The default command prompt is a dash (-). set the PATH and TWS_TISDIR variables by running one of the following scripts: In UNIX: v . Notepad is used as the default editor.csh for C shells In Windows: v TWS_home\tws_env. a vi editor is opened. You can select which editor you want composer to use. refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide. 3-NLS. ./TWS_home/tws_env. UNIX: Several commands you can issue from composer automatically open a text editor. 1-mdy. in both Windows and UNIX. not including the required trailing pound sign (#): #---------------------------------------------------------------------------# Custom format attributes # date format = 1 # The possible values are 0-ymd. You must export the variables before you run composer. If neither of the variables is set. The type of editor is determined by the value of two shell variables. To select a different prompt. composer prompt = conman prompt = % switch sym prompt = <n>% #---------------------------------------------------------------------------- For additional information about localopts configuration file. edit the composer prompt option in the localopts file and change the dash. 2-dmy. . you can set the XMLEDIT environment variable to point to an XML editor of your choice to edit event rule definitions. Managing objects in the database . The composer editor Several composer commands automatically open a text editor.composer 191 . | | | | In addition. Windows: In Windows. otherwise the variable EDITOR defines the editor.Setting up composer environment MAESTROLPLINES Specifies the number of lines per page. If the variable VISUAL is set. Selecting the composer prompt on UNIX The composer command prompt is defined in the TWS_home/localopts file.sh for Bourne and Korn shells v . Running the composer program To configure your environment to use composer.

or HTTPS with certificate authentication. username Is the username of the user running composer. and the WebSphere Application Server infrastructure using HTTP or HTTPS. | | | | | timeout Is the maximum time. make sure that the character is escaped. port_number Is the port number used when establishing the connection with the master domain manager. expressed in seconds. when you specify a password that contains double quotation marks (") or other special characters. composer running on the master domain manager in this case. used in place of the useropts and localopts files. the connecting command line program can wait for the master domain manager response before considering communication request failed. connection_parameters Represents the set of parameters that rule the interaction between the product interface. Use the following syntax to specify the settings for the connection parameters: [-host hostname] [-port port_number] [-protocol protocol_name] [-proxy proxy_name] [-proxyport proxy_port_number] [-password user_password] [-timeout timeout] [-username username] where: hostname Is the hostname of the master domain manager. proxy_port_number Is the proxy port number used in the connection with HTTP protocol..]″] where: -file filename Indicates an alternate custom properties file containing the settings for the connection parameters. proxy_name Is the proxy hostname used in the connection with HTTP protocol. Note: When accessing the composer command line the user with the username and password specified in the connection parameters must be defined as system user on the operating Note: On Windows workstations.. protocol_name Is the protocol used during the communication. It can be HTTP with basic authentication. For example. write it as "tws11\"tws". user_password Is the password of the user that is used to run composer. if your password is tws11"tws.Running composer program composer [-file filename][connection_parameters] [-defaultws twscpu] [″command[&[command]][. 192 IBM Tivoli Workload Scheduler: Reference Guide .

the composer command-line program exits. from the composer command line prompt. are the following: v Runs print and version commands. When running composer in interactive mode. The feature that installs the composer command-line program is named Command Line Client. Tivoli Workload Scheduler searches for a value first in the useropts file and then in the localopts file.Running composer program system where the master domain manager is installed and must have the authorization defined in the security file on the master domain manager. and quits: composer "p parms&v" v Runs print and version commands. for example: composer delete dom=old_domain noask v Escaping the . make sure you manage the . It must be installed separately on top of a Tivoli Workload Scheduler agent workstation or stand-alone on a node outside the Tivoli Workload Scheduler network. -defaultws twscpu Indicates the default workstation composer uses for identifying the scheduling object when a specific workstation is not specified The composer command-line program is installed automatically when installing the master domain manager.txt from jobs=@ When running composer in batch mode. you can use the composer command line both in batch and in interactive mode. Refer to “Setting up options for using the user interfaces” on page 29 for information on useropts and localopts files. noask Other examples on how to use the command. for example. you first launch the composer command-line program and then. composer –f “c:\TWS\network\mylocalopts” add myjobs. Once installed. character in one of the following ways: v Using double-quotes. assuming connection parameters are set in the local configuration scripts. for example: composer –username admin2 –password admin2pwd add myjobs. you launch the composer command-line program specifying as input parameter the command to be issued. for example: composer "delete dom=old_domain. If no value is found then an error is displayed. Managing objects in the database . for example: composer delete dom=old_domain \. noask" v Using a space character. and then prompts for a command: composer "p parms&v&" v Reads commands from cmdfile: Chapter 8. you run commands one at a time. character. If any of these parameters is omitted when invoking composer. When the command is processed.composer 193 .txt Note: If you use the batch mode to issue more than one command from within the composer.txt create myjobs. refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide. For information on how to install the Command Line Client feature.

the backslash character must be prefixed by another backslash character to be interpreted as an occurrence to be found. Search for an exact match with string S\E. Similarly. Ctrl+d composer quits after running the current command. The wild cards you can use from composer are: @ ? Replaces one or more alphanumeric characters. Search for an exact match with string S@E. Filters and wild cards In Tivoli Workload Scheduler composer you can use wild cards and filters when issuing some specific commands to filter scheduling objects defined in the database. Replaces one alphanumeric character. and whose length is three characters. Ctrl+c composer stops running the current command at the next step that can be interrupted and returns a command prompt. S@E S?E S\@E S\?E S\\E Search for all strings starting with S and ending with E. The following examples clarify these rules. Search for an exact match with string S?E. selection Specifies the object or set of objects to be acted upon.Running composer program composer < cmdfile v Pipes commands from cmdfile to composer: cat cmdfile | composer Control characters You can enter the following control characters in conversational mode to interrupt composer if your stty settings are configured to do so. Search for all strings starting with S and ending with E. The commands you can issue from composer and that support filtering are: v display v create 194 IBM Tivoli Workload Scheduler: Reference Guide . arguments Specifies the command arguments. which also apply when specifying search strings using the filter keyword. make sure you use the backslash character \ before @ or ? to escape them so that they are not interpreted as wild cards. To search for occurrences with names that contain either @ or ?. Running commands from composer Composer commands consist of the following elements: commandname selection arguments where: commandname Specifies the command name. whatever is their length.

list users=cpu1#operator? print res=cpu?#operator? parameter delete parms=myparm@ job definition jobname mod jd=mycpu#myjob@ RecoveryJob list jobdefinition=@.composer 195 . workstationname# Applies the command to the resourcename resources whose identifier satisfies the criteria. Scheduling objects filtering criteria Scheduling object workstation Filter keywords Description or fields that can be filtered workstationname Applies the command to the workstations whose name satisfies the criteria. filter workstations which belong to domain=dom1 a domain. Applies the command to the jobs whose definition contains the specified recovery job definition. parametername Applies the command to the parameters whose name satisfies the criteria. Applies the command to the domains whose parent domain satisfies the criteria. filter RecoveryJob=CPUA#job01 Chapter 8.. and for each object.]] Table 34 shows the scheduling objects you can filter when issuing the commands listed above.. filter parent=rome lock prompt=p@ prompt promptname Windows user resource workstationname# Applies the command to the username users whose identifier satisfies the criteria.Filters and wildcards v v v v v v delete list lock modify print unlock The syntax used to filter objects when issuing one of these commands is the following: command_name type_of_object=selection. Applies the command to the global prompts whose name satisfies the criteria. display dom=dom? domain domainname parent list dom=@. [option. Managing objects in the database . Applies the command to the domains whose name satisfies the criteria. Applies the command to the job definitions whose name satisfies the criteria. Example list ws=p@ domain Applies the command to the mod ws=@. which fields can be filtered (in italic) or which key (in bold) is used to filter its fields: Table 34.] [filter filter_keyword=selection [.

info. Scheduling objects filtering criteria (continued) Scheduling object job stream Filter keywords Description or fields that can be filtered workstationname# Applies the command to the jobstreamname job definitions whose name satisfies the criteria. = :! Description Command delimiter. Applies the command to the job streams that refers to the prompt specified in the filter. You can combine more than one filter for the same object type as shown in the following example: list js=@#@. freedays calendar VACATIONS.offline Value delimiter. Comments can be placed on a single line anywhere in a job stream. filter Calendar=cal1 Jobdefinition Applies the command to the list js=@#@. Delimeters and special characters for composer Character & . Applies the command to the job streams that refers to the resource specified in the filter. it is passed automatically to the system. filter Resource=cpu1#disk1 Resource Prompt list js=@#@. list js=@#@. For example: . filter Calendar=cal1 FreeCalendar=VACATIONS jobdefinition=CPUA#job01 The output of the command is a list of job streams using calendar cal1. Argument delimiter. These prefixes are optional. Calendar or FreeCalendar Applies the command to the job streams that contains the calendar or Freeday calendar specified in the filter. filter js=accrecjs5 event rules that include an action on a specific job or job stream. filter Prompt=myprompt | | | | event rule eventrulename Applies the command to the list er=@. For example: schedule foo <<comment>> on everyday 196 IBM Tivoli Workload Scheduler: Reference Guide . if composer does not recognize the command. Example mod js=mycpu#myjs@ list js=@#@. filter job streams that contains the jobdefinition=CPUA#job01 job definition specified in the filter. For example: !ls or :ls << >> Comment brackets. See “Running the composer program” on page 191.Filters and wildcards Table 34. For example: sched=sked5 Command prefixes that pass the command on to the system. and containing a job with job definition CPUA#job01. Table 35. Delimeters and special characters Table 35 lists characters have special meanings in composer commands.

and can be abbreviated to as few leading characters as are needed to uniquely distinguish them from each other. Delimeters and special characters for composer (continued) Character * Description Comment prefix. When this prefix is the first character on a line. Note: Command names and keywords can be entered in either uppercase or lowercase characters.Delimeters and special characters Table 35. Deletes scheduling objects. If the file does not exist. the entire line is a comment. cr de di ed e Creates a text file for editing containing an object definition from the database. Table 36. When the prefix follows a command. The system command is run whether or not output is generated. it is created. For example: *comment or print& *comment > Redirects command output to a file. However there are some abbreviations. the remainder of the line is a comment. version in this case. This happens when the abbreviation is hard coded in the product and so mismatches in invoking the wrong command are automatically bypassed. it is created. Managing objects in the database . Displays the details of the specified scheduling object. The system command is not run if there is no output.composer 197 . List of composer commands Command add Short Name Description a Adds scheduling objects. even though they do not uniquely identify that command in the list. Edits a file. If the file does not exist. Changes the credentials of the user running composer. See page 203 205 206 207 210 213 217 218 authenticate au continue create delete display edit exit Chapter 8. For example: display parms | grep alparm || Pipes command output to a system command or process. Ignores the next error. For example: display parms > parmlist >> Redirects command output to a file and appends the output to the end of file. Some of the command names also have short forms. overwriting the contents of that file. For example: display parms >> parmlist | Pipes command output to a system command or process. such as v. that point to a specific command. For example: display parms || grep alparm Command descriptions Table 36 lists the composer commands. Exits composer.

Command descriptions Table 36. Tivoli Workload Scheduler checks that: – The object definition to be deleted exists in the database. Creates scheduling objects using a text file where the object definition is inserted on line. Invokes an operating system command. Tivoli Workload Scheduler checks that: – An object of the same type and with the same identifier does not already exist. Releases lock on the scheduling object defined in the database. and data integrity of an object definition. Locks the access to database objects. 198 IBM Tivoli Workload Scheduler: Reference Guide . semantic. Lists scheduling objects. – The object definition to be deleted is not referenced by other objects defined in the database. Prints scheduling objects. List of composer commands (continued) Command extract help list lock modify new print redo rename replace unlock validate version system command val v rn rep m n Short Name Description ex h l Extracts an object definition from the database and writes it in a text file. These are the checks performed by the product: v Every time you use a command that creates a new object in the database. Validates the syntax. Displays the composer command-line program banner. – The objects referenced by this object exist in the database. – The objects referenced by this object already exist in the database. or delete the definition of a referenced object. | Note that there is no referential integrity check for event rules. v Every time you run a command that modifies an object definition in the database. Tivoli Workload Scheduler checks that: – The object definition to be modified exists in the database. Changes the object name. Replaces scheduling objects. the object definition does not appear in the definition of an object belonging to the chain of his ancestors. modify. Edits and reruns the previous command. Invoke the help on line for a command. v Every time you run a command that deletes an object definition in the database. – To avoid integrity inconsistencies. Modifies scheduling objects. See page 207 219 220 224 227 231 213 232 234 236 238 241 242 237 Referential integrity check Tivoli Workload Scheduler automatically performs referential checks to avoid lack of integrity in the object definitions in the database whenever you run commands that create.

Referential integrity check Table 37 shows. referential integrity prevents the deletion of objects when they are referenced by other objects in the database.. for each object type.. remove the dependency from the job or job stream . the deletion might be allowed. Managing objects in the database . remove the workstation from the workstation class Table 39 on page 200 describes how the product behaves when it is requested to delete an object referenced by another object with using a specific relationship: Chapter 8.. if defined.. if defined. remove the dependency from the job or job stream . However... validfrom workstationname and jobstreamname. in some cases where the deletion of an object (for example a workstation) implies only the update of a referencing object (for example a workstation class that includes it). . and. validfrom workstationname and resourcename promptname parametername eventrulename | event rule In general. jobname.. Object definition update upon deletion of referenced object Object Internetwork Dependency External Follows Depend References Workstation Job Stream Job Internal Dependency Workstation Class Job Workstation Upon deletion of the referenced object . remove the dependency from the job or job stream ... the identifiers that are used to uniquely identify the object in the database when creating or modifying object definitions: Table 37.. Object identifiers for each type of object defined in the database Object type domain workstation workstation class calendar job definition Windows user job stream job within a job stream resource prompt parameter Object identifiers domainname workstationname (checked across workstations and workstation classes) workstationclassname (checked across workstations and workstation classes) calendarname workstationname and jobname workstationname and username workstationname and jobstreamname and..composer 199 . remove the dependency from the job or job stream . Table 38 shows all cases when a referenced object can be deleted even if other objects reference it: Table 38..

Referential integrity check Table 39. Both workstation A and its entry in workstation class B are deleted. An error specifying the existing relationship is displayed. An error specifying the existing relationship is displayed. An error specifying the existing relationship is displayed. job stream B job B within job stream B job B within job stream B resource B file B workstation class B job B within job stream B 200 IBM Tivoli Workload Scheduler: Reference Guide . An error specifying the existing relationship is displayed. An error specifying the existing relationship is displayed. Referential integrity check when deleting an object from the database Object to be deleted domain A Referenced by object domain B workstation B workstation workstation A B job B job stream B windows user B job stream B Relationship domain A is parent of domain B workstation B belongs to domain A workstation A is host for workstation B job B is defined on workstation A job stream B is defined on workstation A windows user B is defined on workstation A workstation A works as network agent for internetwork dependencies set in job stream B job stream B has a file dependency from a file defined on workstation A workstation A works as network agent for internetwork dependencies set in job B job B has a file dependency from a file defined on workstation A resource B is defined on workstation A file B is defined on workstation A workstation A belongs to workstation class B job B contained in job stream B is defined on workstation A Delete rule An error specifying the existing relationship is displayed. An error specifying the existing relationship is displayed. An error specifying the existing relationship is displayed. Both workstation A and the internetwork dependency are deleted Both workstation A and the file dependency are deleted Both workstation A and the internetwork dependency are deleted Both workstation A and the file dependency are deleted An error specifying the existing relationship is displayed.

An error specifying the existing relationship is displayed. prompt dependency defined An error specifying the existing in job B relationship is displayed. An error specifying the existing relationship is displayed. job B within job stream B job B follows job A job A is in the action definition of event rule B (and does not use variable substitution) job stream B uses calendar A job B is defined on workstation class A job stream B is defined on workstation class A resource B is defined on workstation class A file B is defined on workstation class A needs dependency defined in job stream B needs dependency defined in job B | | | | calendar A event rule B job stream B An error specifying the existing relationship is displayed. An error specifying the existing relationship is displayed. Managing objects in the database . workstation job B class A job stream B resource B file B resource A job stream B job B within job stream B prompt A job stream B job B within job stream B prompt dependency defined An error specifying the existing in job stream B relationship is displayed.composer 201 . An error specifying the existing relationship is displayed. Chapter 8. An error specifying the existing relationship is displayed. An error specifying the existing relationship is displayed. Referential integrity check when deleting an object from the database (continued) Object to be deleted job A Referenced by object job B job stream B job stream B Relationship job A is recovery job for job B job A is contained in job stream B job stream B follows job A Delete rule An error specifying the existing relationship is displayed. job A and the follows dependency in job stream B are deleted. An error specifying the existing relationship is displayed.Referential integrity check Table 39. An error specifying the existing relationship is displayed. job A and the follows dependency in job B are deleted.

job stream A and the follows dependency in job B are deleted. (and does not use variable substitution) 202 IBM Tivoli Workload Scheduler: Reference Guide .Referential integrity check Table 39. parameter A is deleted without checking Delete rule parameter A is deleted without checking job B within a job stream B | | | | event rule B job stream A is in the action An error specifying the existing definition of event rule B relationship is displayed. Referential integrity check when deleting an object from the database (continued) Object to be deleted parameter A Referenced by object job stream B Relationship parameter A is used in job stream B in: v in the text of an ad hoc prompt v or in the file name specified in a file dependency job B parameter A is used in job stream B in: v in the text of an ad hoc prompt v or in the file name specified in a file dependency v or in the value specified for streamlogon v or in the value specified for scriptname prompt B job stream A job stream B parameter A is used in the text of prompt B job stream B follows job stream A job B follows job stream A parameter A is deleted without checking job stream A and the follows dependency in job stream B are deleted.

If you change the name of an object. For all new objects inserted. Specifies the name of the text file that contains the object definitions. the option is ignored.unlock Indicates that the object definitions must be unlocked if locked by another user. run the following command: a mysked Chapter 8.unlock] Arguments filename | | | | | . otherwise the command is interrupted and an error message is displayed. run the following command: add myjobs To add the job streams from the file mysked. you are asked whether or not to replace it. For example. The add command checks for loop dependencies inside job streams. Managing objects in the database . an error is displayed. filename specifies the name of the XML file containing the definitions of the event rules you wish to add (see “Event rule definition” on page 178 for XML reference and see “The composer editor” on page 191 for details on setting up an XML editor). v modify and unlock access to the object if the object is locked by another user. The add command does not check for loop dependencies between job streams because. Comments | | | | | The text file is validated at the client and. Syntax add filename [. and the job definitions are automatically updated without prompting any message. and job2 follows job1 there is a loop dependency. This does not apply to event rule definitions since they are provided directly in XML format. Authorization You must have add access to add a new scheduling object. Composer transforms object definitions into an XML definition used at the server. For event rules. If the object already exists in the database you must have: v modify access to the object if the object is not locked.composer 203 . it is interpreted by composer as a new object and will be inserted. With the add command. A rename command is recommended in this case. this check might be too time and CPU consuming. if correct. objects are inserted into the database on the master domain manager. Examples To add the jobs from the file myjobs. You can use the option unlock to update existing objects previously locked using only one command. if job1 follows job2. if an object already exists.add add Adds or updates scheduling objects to the database. depending on the complexity of the scheduling activities. This behavior does not affect existing job definitions inside job streams. When a loop dependency inside a job stream is found.

workstation classes.add To add the workstations.xml See also For the equivalent Job Scheduling Console task.src.xml. run the following command: a users_nt | | To add the event rule definitions you edited in a file named newrules. Event rule management is not supported by the Job Scheduling Console. see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.src To add the user definitions from the file users_nt. run the following command: a cpus. and domains from the file cpus. 204 IBM Tivoli Workload Scheduler: Reference Guide . run: a newrules.

password=password The password of the user you want to switch to. Authorization Any user authorized to run composer is authorized to issue this command.authenticate authenticate Switches to another user credentials while running composer. Comments A message is displayed communicating the authentication failure or success. Examples To switch to user tws_user1 with password mypasswd1 from within the composer command-line program.composer 205 . This command is used only in interactive mode. Managing objects in the database . Syntax authenticate [username=username password=password] Arguments username=username The username of the user you want to switch to. run the following command: authenticate username=tws_user1 password=mypasswd1 Chapter 8.

results in an error. Syntax continue Comments This command is useful when multiple commands are entered on the command line or redirected from a file. Examples If you want the composer to continue with the print command if the delete command results in an error. This command is not needed when you enter commands interactively because composer does not quit on an error. It instructs composer to continue running commands even if the next command. run the following command: composer "continue&delete cpu=site4&print cpu=@" 206 IBM Tivoli Workload Scheduler: Reference Guide . following continue.continue continue Specifies that the next command error is to be ignored. Authorization Any user authorized to run composer is authorized to issue this command.

cpu Copies workstations. resources resource|res Copies all resource definitions into the file.composer 207 . refer to “parms” on page 400.lock Arguments filename calendars calendar|cal Specifies the name of the file to contain the object definitions. prompts prom Copies all prompt definitions into the file.create . Chapter 8. Copies prompt definitions into the file. Wildcard characters are permitted. workstation classes. Managing objects in the database . also the modify access. Copies all calendar definitions into the file. For more information on how to import parameter definitions locally. Wildcard characters are permitted. Copies calendar definitions into the file. parmname The name of the parameter. Authorization You must have display access to the objects being copied and. Copies resource definitions into the file. Copies parameter definitions into the file.lock keyword. Copies all parameter definitions into the file. You can use this command to create a file containing parameter definitions to be imported into the parameter database defined locally on a workstation. Wildcard characters are permitted. calname parms parm The name of the calendar.extract create .extract Creates a text file containing object definitions extracted from the database. promptname The name of the prompt. Syntax | | | | | | | | | | | | | | | create | extract filename from {[calendars | {calendar | cal}=calname] | [parms | [parm=parmname]] | [prompts | [prom=promptname]] | [resources | {resource | res}=resourcename] | [[cpu={workstationame | workstationclassname | domainame}] | [{workstation | ws}=workstationame] | [{workstationclass | wscl}=workstationclassname] | [{domain | dom}=domainame]] | [{jobs | jobdefinition | jd}=[workstationame#]jobname] | [{sched|jobstream|js}= [workstationame#]jstreamname [valid from date| valid to date |valid in date date] [full]] | [{users | user}=[workstationame#]username] | [{eventrule | erule | er}=eventrulename]} . if you want to use the . resourcename The name of the resource. or domains into the file. Wildcard characters are permitted.

domainame The domain name specified in the job stream.create . The name of the job stream. date date The time frame during which the job stream can run. workstation|ws Copies workstation definitions into the file. The format is mm/dd/yy . domain The domain name specified in the job stream. Wildcard characters are permitted. Wildcard characters are permitted. Wildcard characters are permitted. The name of the workstation. domain|dom Copies domain definitions into the file. Wildcard characters are permitted. The format is mm/dd/yy. The default is the workstation on which composer is running. jobname sched|jobstream|js Copies job stream definitions into the file. Wildcard characters are permitted. workstationclassname The workstation class name specified in the job stream. date Restricts the selection to job streams that have a valid to date equal to the indicated value. Wildcard characters are permitted. workstation The name of the workstation on which the job runs. jstream valid to valid in 208 IBM Tivoli Workload Scheduler: Reference Guide . The format is mm/dd/yy. valid from date Restricts the selection to job streams that have a valid from date equal to the indicated value. One of the two dates can be represented by @. Wildcard characters are permitted. Wildcard characters are permitted. jobs|jobdefinition|jd Copies job definitions into the file.extract workstation workstationclass The workstation class name specified in the job stream. Wildcards are permitted. Wildcards are permitted. The default is the workstation on which composer is running. workstationclass|wscl Copies workstation class definitions into the file. workstation The name of the workstation on which the job stream runs. The name of the job.mm/dd/yy. workstationname The name of the workstation.

composer 209 . eventrulename The name of the event rule definition. Event rule management is not supported by the Job Scheduling Console. run the following command: extract alljobs. Without lock option. Specifies to keep locked the selected object. run the following command: create caltemp from calendars=@ To create a file named stemp containing all job streams.txt containing all job definitions. Examples To create a file named caltemp containing all calendars. find some of these objects already locked by someone else.extract full users|user Copies also all job definitions contained in the job stream. Wildcard characters are permitted. Chapter 8. The user name. Managing objects in the database .xml containing all event rule definitions. Comments The user can invoke the command with the old name “create” or the new name “extract”. Wildcard characters are permitted.txt from jd=@#@ | | | To create a file named allrules. After you create a file. Note: You should regularly create a backup copy of the objects stored in the database. run the following command: cr stemp from jobstream=@ To create a file named alljobs. these objects will not be present in the file and a message to stdout will be presented for each locked object. see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. have to remain locked by the user in the database.xml from erule=@ See also For the equivalent Job Scheduling Console task. Copies the user definition into the file. The default is the workstation on which composer is running. run the following command: create allrules.create . during the extraction. If composer. Wildcard characters are permitted. database locking is not checked and all matching objects are extract to the file. you can use the edit command to make changes to the file and add or replace command to add or update the database The user can specify with the option lock.lock eventrule|erule|er Copies event rule definitions into an XML file. if the objects that respond to selected criteria. username | | | | . The password field is not copied for security reasons. workstation The name of the workstation on which the user is defined.

noask] Arguments calendars calendar|cal Deletes all calendar definitions. workstation classes. Deletes resource definitions. Wildcard characters are permitted. Deletes all parameter definitions. resources resource|res Deletes all resource definitions. Wildcard characters are permitted. Wildcard characters are permitted. Syntax | | | | | | | | | | | | | | | delete {[calendars | {calendar | cal}=calname] | [parms | [parm=parmname]] | [prompts | [prom=promptname]] | [resources | {resource | res}=resourcename] | [[cpu={workstationame | workstationclassname | domainame}] | [{workstation | ws}=workstationame] | [{workstationclass | wscl}=workstationclassname] | [{domain | dom}=domainame]] | [{jobs | jobdefinition | jd}=[workstationame#]jobname] | [{sched | jobstream | js}= [workstationame#]jstreamname [valid from date| valid to date |valid in date date] [full]] | [{users | user}=[workstationame#]username] | [{eventrule | erule | er}=eventrulename]} [. cpu Deletes workstations. Authorization You must have delete access to the objects being deleted. calname parms parm The name of the calendar. The name of the workstation. promptname The name of the prompt.delete delete Deletes object definitions in the database. parmname The name of the parameter. Wildcard characters are permitted. Wildcard characters are permitted. resourcename The name of the resource. Deletes calendar definitions. or domains. prompts prom Deletes all prompt definitions. Deletes parameter definitions. Deletes prompt definitions. workstation workstationclass The workstation class name specified in the job stream. 210 IBM Tivoli Workload Scheduler: Reference Guide . Wildcard characters are permitted.

mm/dd/yy.delete domain The domain name specified in the job stream. workstation The name of the workstation on which the user is defined. workstation The name of the workstation on which the job runs. Wildcard characters are permitted. workstationclass|wscl Deletes workstation class definitions. Wildcard characters are permitted. The format is mm/dd/yy. Managing objects in the database . Wildcard characters are permitted. Wildcards are permitted. One of the two dates can be represented by @. The format is mm/dd/yy . date Restricts the selection to job streams that have a valid to date equal to the indicated value. Wildcard characters are permitted. Wildcard characters are permitted. The name of the job stream. The format is mm/dd/yy. domain|dom Deletes domain definitions. domainame The domain name specified in the job stream. Wildcards are permitted. The default is the workstation on which composer is running. The default is the workstation on which composer is running. valid from date Restricts the selection to job streams that have a valid from date equal to the indicated value. date date The time frame during which the job stream can run. jobs|jobdefinition|jd Deletes job definitions. Wildcard characters are permitted. jobname sched|jobstream|js Deletes job stream definitions. The name of the job. Chapter 8. The default is the workstation on which composer is running. workstation|ws Deletes workstation definitions.composer 211 . workstation The name of the workstation on which the job stream runs. jstream valid to valid in users|user Deletes the user definition. Wildcard characters are permitted. workstationclassname The workstation class name specified in the job stream. workstationname The name of the workstation.

composer requires confirmation before deleting each matching definition. eventrule|erule|er Deletes event rule definitions. 212 IBM Tivoli Workload Scheduler: Reference Guide . eventrulename The name of the event rule definition. Wildcard characters are permitted. run the following command: delete jobs=site3#job3 To delete all workstations with names starting with ux. it must not be locked. run the following command: de sched=@#test@ | | | To delete all the event rules named from rulejs320 to rulejs329. Examples To delete job3 that is launched on workstation site3. Comments If you use wildcard characters to specify a set of definitions. see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide Event rule management is not supported by the Job Scheduling Console.delete username | | | | noask The user name. Specifies not to prompt for confirmation before taking action on each qualifying object. A confirmation is required before deleting each matching definition if noask option is not specified. an error message with the list of these objects is shown to the user and a confirmation is required to delete the unlocked objects. run the following command: de erule=rulejs32? See also For the equivalent Job Scheduling Console task. Wildcard characters are permitted. To delete an object. run the following command: de cpu=ux@ To delete all job streams with names starting with test on all workstations. If some matching objects are locked during the command processing.

If you want to use the full keyword you must have also the display access to the jobs contained in the job stream definition. Wildcard characters are permitted. Chapter 8. calname parms parm The name of the calendar. Syntax | | | | | | | | | | | | | | | display {[calendars | {calendar | cal}=calname] | [parms | [parm=parmname]] | [prompts | [prom=promptname]] | [resources | {resource | res}=resourcename] | [[cpu={workstationame | workstationclassname | domainame}] | [{workstation | ws}=workstationame] | [{workstationclass | wscl}=workstationclassname] | [{domain | dom}=domainame]] | [{jobs | jobdefinition | jd}=[workstationame#]jobname] | [{sched|jobstream|js}= [workstationame#]jstreamname [valid from date| valid to date |valid in date date] [full]] | [{users | user}=[workstationame#]username] | [{eventrule | erule | er}=eventrulename]} . workstation classes. parmname The name of the parameter. The entire definition of the object is displayed. Displays all parameter definitions. resourcename The name of the resource. Wildcard characters are permitted. Wildcard characters are permitted. Displays prompt definitions. Wildcard characters are permitted. Displays resource definitions. Displays parameter definitions. Displays calendar definitions. resouces resource|res Displays all resource definitions.composer 213 . prompts prom Displays all prompt definitions. promptname The name of the prompt. cpu Displays workstations. or domains. Wildcard characters are permitted. Managing objects in the database .offline Arguments calendars calendar|cal Displays all calendar definitions.display display Displays the details of one or more object definitions of the same type stored in the database. Authorization You must have display access to the object being displayed. workstation The name of the workstation.

Wildcard characters are permitted. jobs|jobdefinition|jd Displays job definitions. Wildcard characters are permitted. Wildcard characters are permitted. Wildcards are permitted. Wildcard characters are permitted. The default is the workstation on which composer is running. One of the two dates can be represented by @. valid from date Restricts the selection to job streams that have a valid from date equal to the indicated value. The name of the job. The format is mm/dd/yy. The default is the workstation on which composer is running. domain The domain name specified in the job stream.mm/dd/yy. date Restricts the selection to job streams that have a valid to date equal to the indicated value. domainame The domain name specified in the job stream. workstationclass|wscl Displays workstation class definitions. Wildcard characters are permitted.display workstationclass The workstation class name specified in the job stream. workstation The name of the workstation on which the job runs. Wildcard characters are permitted. date date The time frame during which the job stream can run. jobname sched|jobstream|js Displays job stream definitions. The format is mm/dd/yy. The name of the job stream. workstation|ws Displays workstation definitions. jstream valid to valid in users|user Displays the user definition. workstation The name of the workstation on which the job stream runs. workstationclassname The workstation class name specified in the job stream. Wildcard characters are permitted. domain|dom Displays domain definitions. workstation The name of the workstation on which the user is 214 IBM Tivoli Workload Scheduler: Reference Guide . Wildcards are permitted. workstationname The name of the workstation. The format is mm/dd/yy .

Managing objects in the database . Table 40 shows an example of the output produced based on the value set for the MAESTROCOLUMNS variable. Results The display command returns you the following information about the object to be displayed: v a summary row containing information about the selected object v the selected object definition Depending on the value set for in the MAESTROCOLUMNS local variable the summary row shows different sets of information about the selected object. Wildcard characters are permitted. Wildcard characters are permitted. username | | | | . see “UNIX variables” on page 190. Table 40.display defined. The default is the workstation on which composer is running.offline The user name. For information about this device. eventrule|erule|er Displays event rule definitions. Output formats for displaying scheduling objects Object Type Calendar Domain Output format if MAESTROCOLUMNS=80 "CalendarName : UpdatedBy : UpdatedOn : LockedBy" "DomainName : ParentDomain : Master : UpdatedOn : LockedBy" "EventRuleName : Type : Draft : Status : UpdatedOn : LockedBy" "JobDefinitionName : Workstation : LockedBy" "JobstreamName : Workstation : Validfrom : UpdatedOn : LockedBy" "ParameterName : LockedBy" "PromptName : LockedBy " "ResourceName : Workstation : Quantity : LockedBy " "UserName : Workstation : LockedBy" "WorkstationName : Type : Domain : UpdatedOn : LockedBy" Output format if MAESTROCOLUMNS ≥ 120 "CalendarName : UpdatedBy : UpdatedOn : LockedBy : LockedOn" "DomainName : ParentDomain : Master : UpdatedBy : UpdatedOn : LockedBy" "EventRuleName : Type : Draft : Status : UpdatedOn : LockedBy" "JobDefinitionName : Workstation : TaskType : UpdatedBy : LockedBy" ″JobstreamName : Workstation : Draft : ValidFrom : ValidTo : UpdatedBy : UpdatedOn : LockedBy″ "ParameterName : LockedBy : UpdatedOn : LockedOn " "PromptName : LockedBy : UpdatedOn : LockedOn" "ResourceName : Workstation : Quantity : LockedBy : UpdatedOn : LockedOn " "UserName : Workstation : UpdatedBy : UpdatedOn : LockedBy" "WorkstationName : Type : Domain : OsType : Ignore : UpdatedBy : UpdatedOn : LockedBy" | | Event rule Job Job Stream Parameter Prompt Resource Windows User Workstation Chapter 8. eventrulename The name of the event rule definition.composer 215 . Wildcard characters are permitted. Sends the output of the command to the composer output device.

offline See also For the equivalent Job Scheduling Console task.--------------------01/02/2006 - PAYDAYS 01/15/2006 02/15/2006 03/15/2006 04/15/2006 05/14/2006 06/15/2006 To print the output of the display command on all job streams that are launched on workstation site2. Examples To display all calendars.display Table 40.-----------------------MONTHEND tws83 Updated On Locked By ---------. run the following command: display calendars=@ this is a sample output: Calendar Name Updated By ---------------.--------------------12/31/2005 tws83 Updated On Locked By ---------.-----------------------HOLIDAYS tws83 HOLIDAYS 01/01/2006 02/15/2006 05/31/2006 Calendar Name Updated By ---------------.-----------------------PAYDAYS tws83 Updated On Locked By ---------. Event rule management is not available from the Job scheduling Console.--------------------01/01/2006 - MONTHEND "Month end dates 1st half 2006" 01/31/2006 02/28/2006 03/31/2006 04/30/2006 05/31/2006 06/30/2006 Calendar Name Updated By ---------------. Output formats for displaying scheduling objects (continued) Object Type Workstation Class Output format if MAESTROCOLUMNS=80 "WorkstationClassName : Ignored : UpdatedOn : LockedBy" Output format if MAESTROCOLUMNS ≥ 120 "WorkstationClassName : Ignored : UpdatedBy : UpdatedOn : LockedBy" See “Offline output” on page 190 for more information on how to set MAESTROCOLUMNS. see ″Working with Object Lists″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. run the following command: di sched=site2#@. 216 IBM Tivoli Workload Scheduler: Reference Guide .

See “The composer editor” on page 191 for more information. Comments An editor is started and the specified file is opened for editing. see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. Examples To open the file mytemp for editing. Authorization Any user authorized to run composer is authorized to issue this command. run the following command: edit mytemp To open the file resfile for editing.edit edit Edits a file. Chapter 8. run the following command: ed resfile See also For the equivalent Job Scheduling Console task. Syntax edit filename Arguments filename The name of the file to be edited. Managing objects in the database .composer 217 .

Examples To exit the composer command line program. run the following command: exit or: e 218 IBM Tivoli Workload Scheduler: Reference Guide . Syntax exit Comments When you are running the composer command line program in help mode.exit exit Exits the composer command line program. this command returns composer to command input mode. Authorization Any user authorized to run composer is authorized to issue this command.

help help Displays the on-line help for a command or displays the list of commands that can be issued from composer. Managing objects in the database . Authorization Any user authorized to run composer is authorized to issue this command. Chapter 8.composer 219 . Syntax help [commandname] Arguments commandname The name of the composer command which you want to display on-line help about.

Wildcard characters are permitted. workstation The name of the workstation. calname parms parm The name of the calendar.offline Arguments calendars calendar|cal Lists or prints all calendar definitions. or domains. The print command can be used to send the output to a local printer. or prints summary information about objects defined in the Tivoli Workload Scheduler database. promptname The name of the prompt. Wildcard characters are permitted. print Lists. workstation classes. resourcename The name of the resource. Authorization You must have display access to the object being listed. Lists or prints prompt definitions. Lists or prints all parameter definitions. cpu Lists or prints workstations. Lists or prints parameter definitions. Syntax | | | | | | | | | | | | | | | list | print {[calendars | {calendar | cal}=calname] | [parms | [parm=parmname]] | [prompts | [prom=promptname]] | [resources | {resource | res}=resourcename] | [[cpu={workstationame | workstationclassname | domainame}] | [{workstation | ws}=workstationame] | [{workstationclass | wscl}=workstationclassname] | [{domain | dom}=domainame]] | [{jobs | jobdefinition | jd}=[workstationame#]jobname] | [{sched|jobstream|js}= [workstationame#]jstreamname [valid from date| valid to date |valid in date date] [full]] | [{users | user}=[workstationame#]username] | [{eventrule | erule | er}=eventrulename]} . 220 IBM Tivoli Workload Scheduler: Reference Guide . Lists or prints calendar definitions. Wildcard characters are permitted. prompts prom Lists or prints all prompt definitions. resources resource|res Lists or prints all resource definitions. Print sends the list of objects names with their attributes to the device or file specified in the MAESTROLP local variable. Wildcard characters are permitted. parmname The name of the parameter. Lists or prints resource definitions. Wildcard characters are permitted. if the MAESTROLP variable is set accordingly. List provides you with the list of objects names with their attributes. or printed if the enListSecChk option is set to yes on the master domain manager. print list.list.

workstationclass|wscl Lists or prints workstation class definitions. workstationname The name of the workstation. Wildcard characters are permitted. domain|dom Lists or prints domain definitions. print workstationclass The workstation class name specified in the job stream. Wildcard characters are permitted. Wildcards are permitted. date Restricts the selection to job streams that have a valid to date equal to the indicated value. Wildcard characters are permitted. date date The time frame during which the job stream can run. The default is the workstation on which composer is running. workstation The name of the workstation on which the job stream runs. workstation The name of the workstation on which the user is Chapter 8. The default is the workstation on which composer is running. The format is mm/dd/yy . jobname sched|jobstream|js Lists or prints job stream definitions. Wildcard characters are permitted. The format is mm/dd/yy. jstream valid to valid in users|user Lists or prints the user definition. domain The domain name specified in the job stream. workstation|ws Lists or prints workstation definitions. The format is mm/dd/yy. Managing objects in the database . workstationclassname The workstation class name specified in the job stream. Wildcard characters are permitted. One of the two dates can be represented by @. The name of the job stream. Wildcard characters are permitted. Wildcards are permitted. workstation The name of the workstation on which the job runs. valid from date Restricts the selection to job streams that have a valid from date equal to the indicated value. Wildcard characters are permitted.composer 221 . domainame The domain name specified in the job stream. The name of the job. jobs|jobdefinition|jd Lists or prints job definitions.list.mm/dd/yy.

Wildcard characters are permitted. Make sure the MAESTROLP is set in your environment before running the print command. Table 41. username | | | | . Output formats for printing scheduling objects Object Type Calendar Domain Output format if MAESTROCOLUMNS=80 "CalendarName : UpdatedBy : UpdatedOn : LockedBy" "DomainName : ParentDomain : Master : UpdatedOn : LockedBy″ "EventRuleName : Type : Draft : Status : UpdatedOn : LockedBy" "JobDefinitionName : Workstation : LockedBy" Output format if MAESTROCOLUMNS ≥ 120 "CalendarName : UpdatedBy : UpdatedOn : LockedBy : LockedOn" "DomainName : ParentDomain : Master : UpdatedBy : UpdatedOn : LockedBy" "EventRuleName : Type : Draft : Status : UpdatedOn : LockedBy" "JobDefinitionName : Workstation : TaskType : UpdatedBy : LockedBy" | | Event rule Job Job Stream "JobstreamName : Workstation : "JobstreamName : Workstation : Draft Validfrom : UpdatedOn : LockedBy" : ValidFrom : ValidTo : UpdatedBy : UpdatedOn : LockedBy" "ParameterName : LockedBy" "PromptName : LockedBy " "ResourceName : Workstation : Quantity : LockedBy " "UserName : Workstation : LockedBy" "WorkstationName : Type : Domain : UpdatedOn : LockedBy" "ParameterName : LockedBy : UpdatedOn : LockedOn " "PromptName : LockedBy : UpdatedOn : LockedOn" "ResourceName : Workstation : Quantity : LockedBy : UpdatedOn : LockedOn " "UserName : Workstation : UpdatedBy : UpdatedOn : LockedBy" "WorkstationName : Type : Domain : OsType : Ignore : UpdatedBy : UpdatedOn : LockedBy" Parameter Prompt Resource Windows User Workstation 222 IBM Tivoli Workload Scheduler: Reference Guide .. The list . Depending on the value set for in the MAESTROCOLUMNS local variable the different sets of information about the selected object can be shown. if the MAESTROLP variable is set accordingly.list.. . eventrulename The name of the event rule definition. Wildcard characters are permitted. Print sends the list of objects names with their attributes to the device or file set in the MAESTROLP local variable. print defined. For information about this device. Table 41 shows an example of the output produced according to the value set for the MAESTROCOLUMNS variable. Wildcard characters are permitted. eventrule|erule|er List or prints event rule definitions. The print command can be used to send the output to a local printer. see “UNIX variables” on page 190.offline command is equivalent to the print command. The default is the workstation on which composer is running..offline The user name.. Sends the output of the command to the composer output device. Results List provides you with the list of objects names with their attributes.

composer 223 .-------.---------. print Table 41. the output looks something like this: Event Rule Name --------------------EVENT-MULTIPLE1 EVENT-MULTIPLE2 EVENT-MULTIPLE3 M_SUCC_12_S M_SUCC_12_S_A M_SUCC_12_S_B NEWEVENTRULE Type Draft Status Updated On Locked By --------. see ″Working with Object Lists″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. run the following command: If MAESTROCOLUMNS=80.--------filter active 06/06/2007 filter active 06/06/2007 filter active 06/06/2007 sequence Y inactive 06/07/2007 filter active 06/07/2007 filter Y inactive 06/07/2007 filter active 06/01/2007 administrator See also For the equivalent Job Scheduling Console task. Managing objects in the database .--------. the output looks something like this: Event Rule Name ---------------EVENT-MULTIPLE1 EVENT-MULTIPLE2 EVENT-MULTIPLE3 M_SUCC_12_S M_SUCC_12_S_A M_SUCC_12_S_B NEWEVENTRULE Type --------filter filter filter sequence filter filter filter Draft Status Updated On ----. run the following command: list calendars=@ this is a sample output: Calendar Name ---------------HOLIDAYS PAYDAYS MONTHEND AWSBIA291I Total list er=@ Updated By -----------------------tws83 tws83 tws83 objects: 3 Updated On ---------03/02/2006 03/02/2006 03/02/2006 Locked By --------------------- v To list all your defined event rules. Chapter 8. Examples v To list all calendars.----. Event rule management is not available form the Job Scheduling Console. Output formats for printing scheduling objects (continued) Object Type Workstation Class Output format if MAESTROCOLUMNS=80 "WorkstationClassName : Ignored : UpdatedOn : LockedBy" Output format if MAESTROCOLUMNS ≥ 120 "WorkstationClassName : Ignored : UpdatedBy : UpdatedOn : LockedBy" See “Offline output” on page 190 for more information on how to set MAESTROLP.list.---------active 06/06/2007 active 06/06/2007 active 06/06/2007 Y inactive 06/07/2007 active 06/07/2007 Y inactive 06/07/2007 active 06/01/2007 Locked By ------------administrator If MAESTROCOLUMNS≥120.

resources resource|res Locks all resource definitions. Locks calendar definitions. Locks parameter definitions. Wildcard characters are permitted. Syntax | | | | | | | | | | | | | | lock {[calendars | {calendar | cal}=calname] | [parms | [parm=parmname]] | [prompts | [prom=promptname]] | [resources | {resource | res}=resourcename] | [[cpu={workstationame | workstationclassname | domainame}] | [{workstation | ws}=workstationame] | [{workstationclass | wscl}=workstationclassname] | [{domain | dom}=domainame]] | [{jobs | jobdefinition | jd}=[workstationame#]jobname] | [{sched|jobstream|js}= [workstationame#]jstreamname [valid from date| valid to date |valid in date date] [full]] | [{users | user}=[workstationame#]username] | [{eventrule | erule | er}=eventrulename]} Arguments calendars calendar|cal Locks all calendar definitions. Wildcard characters are permitted. Authorization You must have modify access to the object. 224 IBM Tivoli Workload Scheduler: Reference Guide . resourcename The name of the resource. workstation classes. cpu Locks workstations. promptname The name of the prompt. Wildcard characters are permitted. workstation workstationclass The workstation class name specified in the job stream. Wildcard characters are permitted. calname parms parm The name of the calendar. prompts prom Locks all prompt definitions.lock lock Locks the access to scheduling objects definitions in the database. Locks prompt definitions. or domains. Wildcard characters are permitted. Locks all parameter definitions. Locks resource definitions. Wildcard characters are permitted. The name of the workstation. domain The domain name specified in the job stream. parmname The name of the parameter. Wildcard characters are permitted.

Wildcard characters are permitted. Wildcard characters are permitted. The format is mm/dd/yy . workstationname The name of the workstation. username Chapter 8. domain|dom Locks domain definitions. Wildcards are permitted. Wildcard characters are permitted. Wildcard characters are permitted. The default is the workstation on which composer is running. date Restricts the selection to job streams that have a valid to date equal to the indicated value.mm/dd/yy. One of the two dates can be represented by @. jstream valid to valid in users|user Locks the user definition.lock workstation|ws Locks workstation definitions. valid from date Restricts the selection to job streams that have a valid from date equal to the indicated value. The default is the workstation on which composer is running. The default is the workstation on which composer is running. Wildcard characters are permitted. workstationclassname The workstation class name specified in the job stream. workstationclass|wscl Locks workstation class definitions. jobs|jobdefinition|jd Locks job definitions.composer 225 . Wildcards are permitted. The format is mm/dd/yy. jobname sched|jobstream|js Locks job stream definitions. workstation The name of the workstation on which the job runs. The name of the job stream. workstation The name of the workstation on which the job stream runs. date date The time frame during which the job stream can run. The format is mm/dd/yy. domainame The domain name specified in the job stream. Managing objects in the database . The name of the job. Wildcard characters are permitted. Wildcard characters are permitted. The user name. workstation The name of the workstation on which the user is defined.

disconnected and then connected again to the composer command line from the same shell. the default value corresponds to an alphanumeric string automatically created by the product. the default value is the username used by the user when connecting to the master domain manager. 226 IBM Tivoli Workload Scheduler: Reference Guide . see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. Comments Objects are locked to make sure that definitions in the database are not overwritten by different users accessing concurrently to the same objects. v a user connected. v If using composer in interactive mode. where session is a string that can be set in the environment variable TWS_SESSION identifying that specific user work session. on a machine. Wildcard characters are permitted. eventrulename The name of the event rule definition. the TWS_SESSION identifier is different for: v a user connected in two different shells to the composer command line program.lock | | | | eventrule|erule|er Locks event rule definitions. an error message is returned. Note: In the database the username of the user locking an object definition is saved in uppercase. If no value is assigned to TWS_SESSION. Examples To lock calendar named Holiday run the command: lock calendar=HOLIDAYS See also For the equivalent Job Scheduling Console task. Event rule management is not available form the Job Scheduling Console. Locks on database objects are acquired by the user using username and session. any other user has read only access until the object is released or explicitly unlocked by the administrator. then the default value identifying the session is set as follows: v If using composer in batch mode. When one user has an object locked. If one user tries to lock an object that is already locked by someone else (other user). This means that. With this command the user explicitly acquires locks of database objects.

Wildcard characters are permitted. Wildcard characters are permitted. you must have modify access to the object. cpu Modifies workstations. Managing objects in the database . Syntax | | | | | | | | | | | | | | modify {[calendars | {calendar | cal}=calname] | [parms | [parm=parmname]] | [prompts | [prom=promptname]] | [resources | {resource | res}=resourcename] | [[cpu={workstationame | workstationclassname | domainame}] | [{workstation | ws}=workstationame] | [{workstationclass | wscl}=workstationclassname] | [{domain | dom}=domainame]] | [{jobs | jobdefinition | jd}=[workstationame#]jobname] | [{sched|jobstream|js}= [workstationame#]jstreamname [valid from date| valid to date |valid in date date] [full]] | [{users | user}=[workstationame#]username] | [{eventrule | erule | er}=eventrulename]} Arguments calendars calendar|cal Modifies all calendar definitions. or domains. parmname The name of the parameter. When modifying objects. workstation classes. Chapter 8.composer The name of the workstation. Wildcard characters are permitted. Wildcard characters are permitted. prompts prom Modifies all prompt definitions. Modifies all parameter definitions. resources resource|res Modifies all resource definitions. promptname The name of the prompt. Modifies calendar definitions.modify modify Modifies or adds scheduling objects. the modify command extracts only the objects that can be locked by the current user. If the object already exists in the database. Modifies prompt definitions. Authorization You must have add access if you add a new scheduling object. workstation workstationclass The workstation class name specified in the job stream. Wildcard characters are permitted. Modifies resource definitions. Wildcard characters are permitted. resourcename The name of the resource. calname parms parm The name of the calendar. 227 . Modifies parameter definitions.

Wildcard characters are permitted. The name of the job stream. workstation|ws Modifies workstation definitions. The format is mm/dd/yy. domain|dom Modifies domain definitions. workstation The name of the workstation on which the job runs. The default is the workstation on which composer is running. Wildcard characters are permitted. Modifies the user definition. Wildcard characters are permitted. jobs|jobdefinition|jd Modifies job definitions. jstream valid to valid in full users|user Modifies all job definitions contained in the job stream. The format is mm/dd/yy . One of the two dates can be represented by @. workstationclass|wscl Modifies workstation class definitions. date date The time frame during which the job stream can run. workstationclassname The workstation class name specified in the job stream.mm/dd/yy. Wildcard characters are permitted. workstation The name of the workstation on which the job stream runs. The name of the job.modify domain The domain name specified in the job stream. domainame The domain name specified in the job stream. jobname sched|jobstream|js Modifies job stream definitions. Wildcards are permitted. workstationname The name of the workstation. valid from date Restricts the selection to job streams that have a valid from date equal to the indicated value. workstation The name of the workstation on which the user is 228 IBM Tivoli Workload Scheduler: Reference Guide . The format is mm/dd/yy. Wildcard characters are permitted. date Restricts the selection to job streams that have a valid to date equal to the indicated value. Wildcard characters are permitted. The default is the workstation on which composer is running. Wildcards are permitted.

6. 5. composer asks ″do you want to re-edit?″ and the file saved before is reopened for editing and the next steps of the sequence are repeated. Wildcard characters are permitted. eventrulename The name of the event rule definition.composer 229 . 4. Unlocks the objects in the database. eventrule|erule|er Modifies or adds event rule definitions. Locks the objects in the database. Replaces the definition contained in the temporary file to the database. If the modify command fails on a subset of the selected objects. so. username | | | | The user name.MY-JOB06 END SCHEDULE FTA1#COPYOFPROVA VALIDFROM 08/31/2005 MATCHING SAMEDAY : FTA1#MY-JOBO6 END and you change the name of the predecessor job from FTA1#MY-JOB06 to FTA1#MY-JOB05 in both job streams FTA1#PROVA and FTA1#COPYOFPROVA. For example. The default is the workstation on which composer is running. If you modify with the same modify command two or more objects linked together by any relationship. | | | Event rule definitions are opened with an XML editor (see “Event rule definition” on page 178 for XML reference and see “The composer editor” on page 191 for details on setting up an XML editor). Copies the objects definition into a temporary file. the modify command might fail on the referencing object. for example a successor job and its predecessor job. then the modify command: Chapter 8. if the referencing object is displayed before the object being referenced. then it might be relevant for the successful result of the modify command the order in which the objects are listed in the temporary file. Managing objects in the database . Edits the file. if the command: modify FTA1#@PROVA produces the following temporary file: SCHEDULE FTA1#PROVA VALIDFROM 08/31/2005 MATCHING SAMEDAY : FTA2#MY-JOB FOLLOWS FTA1#COPYOFPROVA.modify defined. 2. Wildcard characters are permitted. This happens because the modify command reads in sequence the objects contained in the temporary file. Wildcard characters are permitted. Comments The modify command performs the following sequence of actions: 1. 3.

230 IBM Tivoli Workload Scheduler: Reference Guide . Event rule management is not available form the Job Scheduling Console. this check might be too time and CPU consuming. the command is successfully performed since the predecessor job FTA1#MY-JOB05 now exists in the database.modify 1. For example. depending on the complexity of the scheduling activities. Examples To modify all calendars. At first tries to change the definition of job stream FTA1#PROVA and it fails because it finds a follows dependency from a job FTA1#MY-JOB05 which is still unknown. For user definitions. The modify command checks for loop dependencies inside job streams. run: mod er=@. run the following command: m sched=site1#sked9 | | | To modify all the event rules that include an action with job DPJOB10. 2. Then it tries to change the definition of FTA1#COPYOFPROVA and it succeeds. The second time you run modify to change the predecessor job from FTA1#MY-JOB06 to FTA1#MY-JOB05 in job stream FTA1#PROVA. To specify a null password use two consecutive double quotes (“”). and job2 follows job1 there is a loop dependency. then the modify command would have run successfully the first time because the name of the predecessor job would have been modified before changing the dependency definition in the successor job. the old password is retained. if the password field keeps the "*******" value when you exit the editor. When a loop dependency inside a job stream is found an error is displayed. if job1 follows job2. see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. If job stream FTA1#COPYOFPROVA had been listed in the temporary file before FTA1#PROVA. The modify command does not check for loop dependencies between job streams because.filter job=DPJOB10 See also For the equivalent Job Scheduling Console task. run the following command: modify calendars=@ To modify job stream sked9 that is launched on workstation site1.

an event rule. a domain. a workstation. Authorization You must have add access if you add a new scheduling object. run: new erule Chapter 8. If the object already exists in the database you must have modify access to the object.composer 231 . a parameter. a job stream. run: new prompt To create a new event rule definition. Event rule definitions are opened with an XML editor (see “Event rule definition” on page 178 for XML reference and see “The composer editor” on page 191 for details on setting up an XML editor).new new Adds a new scheduling object definition in the database. Syntax | | | | | | | | | | | | | | | | | | | | | | new [calendar | domain | eventrule | job | jobstream | parameter | prompt | resource | user | workstation | workstation_class] Arguments The object you want to define: a calendar. The object templates are located in the templates subfolder in the Tivoli Workload Scheduler installation directory. or a workstation class. run: new user To create a new prompt definition. a job. a prompt. Comments The command opens a predefined template that helps you edit the object definition and adds it in the database when you save it. a user. Examples To create a new user definition. They can be customized to fit your preferences. a resource. Managing objects in the database .

This can be followed by another directive or text. Inserts text before the character above the i. Replaces one or more characters with text. and inserts abc in their place. and inserts abc in its place. composer displays the previous command. Authorization Any user authorized to run composer is authorized to issue this command. Replaces the three characters. Appends abc to the end of the line. >abc >ddabc Deletes the last two characters in the line. and enter the following directives. Appends text to the end of the line. Deletes the three characters above the ds. Replace is implied if no other directive is entered. Syntax redo Context When you run the redo command. Directives d[dir] itext rtext Deletes the character above the d. redo does not display the password specified. Use the spacebar to move the cursor under the character to be modified. beginning with the character above the r. This can be followed by other directives. deletes the character above the second d. skips one character. >rtext Replaces characters at the end of the line with text. 232 IBM Tivoli Workload Scheduler: Reference Guide . Replaces the three characters above abc with abc. Note: If the previous command was authenticate. >text >d[dir | text] Deletes characters at the end of the line. so that it can be edited and run again. with abc. starting with the one above the r. Inserts abc before the character above the i.redo redo Edits and runs the previous command again. >rabc Replaces the last three characters in the line with abc. Directive Examples ddd iabc rabc abc d diabc Deletes the character above the first d.

Managing objects in the database . for example change site into serv by replacing ite with erv.composer 233 .redo Examples To insert a character. run the following command: redo display site1#sa@ rerv display serv1#sa@ Chapter 8. run the following command: redo dislay site1#sa@ ip display site1#sa@ To replace three characters.

jobname The command applies to this job instance defined in this job stream. Syntax | | | | | | | | | | | | | | rename {calendars|calendar|cal | parms|parm | prompts|prom | resorces|resource|res | workstation|ws | workstationclass|wscl | domain|dom | jobs|jobdefinition|jd | jobsched|jb | eventrule|erule|er sched|jobstream|js | users|user } old_object_identifier new_object_identifier Arguments old_object_identifier Specifies the old external key identifying the scheduling object. [workstationame#]jstreamname+valid from date The command applies only to this version of this job stream. 234 IBM Tivoli Workload Scheduler: Reference Guide . This format is used with the jobs|jobdefinition|jd key. See the js keyword in the “Job stream definition” on page 133 syntax for additional details. This format is used with the sched|jobstream|js key. [workstationame#]jstreamname. This format is used with the resources|resource|res key. [workstationame#]jstreamname The command applies to all versions of this job stream. for example calendar name cal1 as identifier for a defined calendar object to be renamed. For what concerns jobs. This format is used with the jobsched|jb key. This format is used with the sched|jobstream|js key. The new name must not identify an object already defined in the database. for example calendar name cal2 as new identifier to be assigned to calendar object previously named cal1. Authorization You must have modify access to the object with the old name and add access to the object with the new name. new_object_identifier Specifies the new external key identifying the scheduling object. [workstationame#]resourcename The command applies to this resource definition.rename rename Renames a scheduling object already existing in the database. resources and Windows users both the old_object_identifier and new_object_identifier have the following formats: [workstationame#]jobname The command applies to this job definition. job streams.

This can lead to incongruences when submitting ad-hoc jobs before generating again the production plan. When workstationame is not specified for objects that have the workstation name as part of their object identifier (for example. In this case. The use of wild cards is not allowed with this command. Managing objects in the database . job or job stream definitions). the scheduler uses one of the following for workstationame: v The default workstation specified in the localopts file v The master domain manager if the composer command line program is running on a node outside the Tivoli Workload Scheduler network. the default workstation set in the localopts file is the master domain manager.composer 235 . in fact. The new name assigned to an object becomes immediately effective in the database. Chapter 8. Comments To be renamed the object must be unlocked or locked by the user who issues the rename command. while it becomes effective in the plan after the JnextPlan script is run again. The rename command is used to assign new names to objects already existing in the database.rename [workstationame#][domain\]username The command applies to this Windows user definition. run the following command: rename js=CPU1#LABJST1 CPU1#LABJST2 See also For the equivalent Job Scheduling Console task. This format is used with the users|user key. Examples To rename domain object DOMAIN1 to DOMAIN2 . If an object named as specified in the old_object_identifier field does not exist in the database an error message is displayed. run the following command: rename dom=DOMAIN1 DOMAIN2 To rename job stream LABJST1 to LABJST2 on workstation CPU1. see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

xml. Comments The replace command is similar to the add command. When a loop dependency inside a job stream is found an error is displayed. run the following command: rep myres | | | | | You want to change some existing event rule definitions in the database. this option. except that there is no confirmation prompt to replace existing objects. v modify and unlock accesses to the object if you want to use the . Examples To replace the jobs from the file myjobs. and job2 follows job1 there is a loop dependency. unlock Updates existing objects previously locked and unlocks them. An error is displayed if the objects are not previously locked. if job1 follows job2. Authorization You must have add access if you add a new scheduling object. For more information.unlock option against objects locked by other users.replace replace Replaces scheduling object definitions in the database.xml See also For the equivalent Job Scheduling Console task. For all new objects inserted. You run: rep 2Q07rules. The file can contain all types of scheduling objects definition. The replace command checks for loop dependencies inside job streams. refer to “add” on page 203. You also want to add some new ones as well. is ignored. if specified. The replace command does not check for loop dependencies between job streams because.unlock Arguments filename Specifies the name of a file containing the object definitions to replace. this check might be too time and CPU consuming. depending on the complexity of the scheduling activities. For example. If the object already exists in the database you must have: v modify access to the object if the object is not locked. You write the entire definitions in an XML file you name 2Q07rules. run the following command: replace myjobs To replace all resources with those contained in the file myres. You use this command in the following way: 1. 2. Syntax replace filename. see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. 236 IBM Tivoli Workload Scheduler: Reference Guide .

The prefix of colon (:) or exclamation mark (!) is required only when the command is spelled the same as a composer command. Syntax [: | !] sys-command Arguments sys-command Specifies any valid system command. run the following command: dir \bin Chapter 8. Managing objects in the database . Examples To run a ps command on UNIX.system command system command Runs a system command.composer 237 . run the following command: ps -ef To run a dir command on Windows.

238 IBM Tivoli Workload Scheduler: Reference Guide . Unlocks parameter definitions. the object must have been locked using the same user and session. promptname The name of the prompt. workstation classes. or domains. Wildcard characters are permitted. parmname The name of the parameter. resources resource|res Unlocks all resource definitions. Wildcard characters are permitted. Unlocks resource definitions. Unlocks prompt definitions. The name of the workstation. Syntax | | | | | | | | | | | | | | | unlock {[calendars | {calendar | cal}=calname] | [parms | [parm=parmname]] | [prompts | [prom=promptname]] | [resources | {resource | res}=resourcename] | [[cpu={workstationame | workstationclassname | domainame}] | [{workstation | ws}=workstationame] | [{workstationclass | wscl}=workstationclassname] | [{domain | dom}=domainame]] | [{jobs | jobdefinition | jd}=[workstationame#]jobname] | [{sched|jobstream|js}= [workstationame#]jstreamname [valid from date| valid to date |valid in date date] [full]] | [{users | user}=[workstationame#]username] | [{eventrule | erule | er}=eventrulename]} [. Authorization You must have the unlock access to unlock objects locked by other users. Wildcard characters are permitted. Wildcard characters are permitted. Wildcard characters are permitted. calname parms parm The name of the calendar. resourcename The name of the resource.forced] Arguments calendars calendar|cal Unlocks all calendar definitions. Wildcard characters are permitted. cpu Unlocks workstations. prompts prom Unlocks all prompt definitions. By default to unlock an object. Unlocks all parameter definitions. Unlocks calendar definitions.unlock unlock Releases access locks on scheduling objects defined in the database. workstation workstationclass The workstation class name specified in the job stream.

unlock
domain The domain name specified in the job stream. Wildcard characters are permitted.

workstation|ws Unlocks workstation definitions. workstationname The name of the workstation. Wildcard characters are permitted. domain|dom Unlocks domain definitions. domainame The domain name specified in the job stream. Wildcard characters are permitted.

workstationclass|wscl Unlocks workstation class definitions. workstationclassname The workstation class name specified in the job stream. Wildcard characters are permitted. jobs|jobdefinition|jd Unlocks job definitions. workstation The name of the workstation on which the job runs. Wildcards are permitted. The default is the workstation on which composer is running. The name of the job. Wildcards are permitted.

jobname

sched|jobstream|js Unlocks job stream definitions. workstation The name of the workstation on which the job stream runs. Wildcard characters are permitted. The default is the workstation on which composer is running. The name of the job stream. Wildcard characters are permitted. valid from date Restricts the selection to job streams that have a valid from date equal to the indicated value. The format is mm/dd/yy. date Restricts the selection to job streams that have a valid to date equal to the indicated value. The format is mm/dd/yy. date date The time frame during which the job stream can run. The format is mm/dd/yy - mm/dd/yy. One of the two dates can be represented by @.

jstream

valid to

valid in

users|user

Unlocks the user definition. workstation The name of the workstation on which the user is defined. Wildcard characters are permitted. The default is the workstation on which composer is running.
Chapter 8. Managing objects in the database - composer

239

unlock
username | | | | forced The user name. Wildcard characters are permitted.

eventrule|erule|er Unlocks event rule definitions. eventrulename The name of the event rule definition. Wildcard characters are permitted.

If specified, allows the user who locked the object to unlock it regardless of the session. If this option is used by the superuser, then the unlock command can operate regardless to the user and the session used to lock the object.

Comments
If a user, other than the superuser, tries to unlock an object that is locked by another user, an error message is returned. If the object is not locked when the unlock command is issued against it, a warning message is returned.

Examples
To unlock job definition JOBDEF1, run the following command:
unlock jd=@#JOBDEF1

| |

To unlock event rule definition ERJS21, run the following command:
unlock erule=ERJS21

See also
For the equivalent Job Scheduling Console task, see ″Managing database objects″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

240

IBM Tivoli Workload Scheduler: Reference Guide

validate

validate
Performs the validation of the object definitions contained in a user file.

Authorization
You do not need any specific authorization to objects to run this command.

Syntax
validate filename [;syntax]

Arguments
filename | | | | | Specifies the name of a file that contains calendars, workstations, workstation classes, domains, jobs, parameters, prompts, resources, job streams, or event rules. For event rule definitions the file must be in the XML language. See “Event rule definition” on page 178 for details on writing event rule definitions. syntax Checks the file for syntax errors.

Comments
For job streams, if the syntax option is omitted, validation and reporting include the following: v Verify job names against the master job file. v Examine dependencies to ensure that the objects exist. Dependencies on nonexistent objects are reported. The output of the validate command can be redirected to a file as follows:
composer "validate filename" > outfile

To include error messages in the output file, use the following:
composer "validate filename" > outfile 2>&1

Examples
To check the syntax of a file containing workstation definitions, run the following command:
validate mycpus;syntax

To validate all job streams, run the following command:
create allskeds from sched=@#@ validate allskeds

You can do this to verify the integrity of references to other scheduling objects after changes have been made.

Chapter 8. Managing objects in the database - composer

241

version

version
Displays the composer command line program banner.

Authorization
Any user authorized to run composer is authorized to issue this command.

Syntax
version

Examples
To display the composer command line program banner, run the following command:
version

or:
v

242

IBM Tivoli Workload Scheduler: Reference Guide

Chapter 9. Managing objects in the plan - conman
The Tivoli Workload Scheduler production plan environment is managed using the conman command-line program. The conman program is used to start and stop processing, alter and display the Symphony production plan, and control workstation linking in a network. It can be used from the master domain manager and from any fault-tolerant agent in the Tivoli Workload Scheduler network. This chapter is divided into the following sections: v “What is new in managing objects in production” v “Using the conman command line program” v “Running commands from conman” on page 247 v v v v | | | | | | | | | | | | | | | | “Selecting jobs in commands” on page 249 “Selecting job streams in commands” on page 257 “Managing jobs and job streams from back-level agents” on page 263 “Command descriptions” on page 264

What is new in managing objects in production
This section gives a quick reference to the enhancements to managing objects in the plan included in Tivoli Workload Scheduler version 8.4. The enhancements are provided by new commands that you can use to: v Download the latest monitoring configuration for the event monitoring engine on the workstation. See “deployconf” on page 285 for details. v Start and stop the WebSphere Application Server process. See “startappserver” on page 345 and “stopappserver” on page 352 for details. v Manage (start, stop, switch) the new event processing server used in event-driven workload automation. See “starteventprocessor” on page 346, “stopeventprocessor” on page 353, and “switcheventprocessor” on page 366 for details. v Manage the new monitoring agent used in event-driven workload automation. See “startmon” on page 347 and “stopmon” on page 354 for details. The showcpus command is enhanced with the new getmon keyword that returns a list of event rules defined for the monitor running on a workstation.

Using the conman command line program
The conman command-line program manages the production plan environment. You can use the conman program from the master domain manager and from any fault-tolerant agent workstation in the Tivoli Workload Scheduler network.

Setting up the conman environment
This section gives you the information about the setup you can choose for your conman environment. Note: On Windows systems, before running conman ensure the code-page and fonts are correctly set in the DOS shell to avoid bad character conversion.

© Copyright IBM Corp. 1999, 2007

243

Setting up the conman environment
For additional information on the required settings refer to the Internationalization notes section in the IBM Tivoli Workload Scheduler: Release Notes.

Terminal output
The output to your computer is determined by the shell variables named MAESTROLINES and MAESTROCOLUMNS. If either is not set, the standard shell variables, LINES and COLUMNS, are used. The variables can be set as follows: MAESTROLINES Specifies the number of lines per screen. The default is 24. At the end of each screen page, conman prompts to continue. If MAESTROLINES (or LINES) is set to zero or a negative number, conman does not pause at the end of a page. MAESTROCOLUMNS Specifies the number of characters per line. The default is 80. MAESTRO_OUTPUT_STYLE Specifies how object names are displayed. If set to LONG, full names are displayed. If not set, or set to any value other than LONG, long names are truncated to eight characters followed by a plus sign (+).

Offline output
The ;offline option in conman commands is generally used to print the output of a command. When you include it, the following shell variables control the output: MAESTROLP Specifies the destination of a command’s output. Set it to one of the following: > file Redirects output to a file and overwrites the contents of that file. If the file does not exist, it is created.

>> file Redirects output to a file and appends the output to the end of that file. If the file does not exist, it is created. | command Pipes output to a system command or process. The system command is run whether or not output is generated. || command Pipes output to a system command or process. The system command is not run if there is no output. The default value for MAESTROLP is | lp -tCONLIST which pipes the command output to the printer and places the title “CONLIST” in the printout’s banner page. MAESTROLPLINES Specifies the number of lines per page. The default is 60. MAESTROLPCOLUMNS Specifies the number of characters per line. The default is 132. The variables must be exported before running conman.

Selecting the conman prompt on UNIX
The conman command prompt is, by default, a percent sign (%). This is defined in the TWS_home/localopts file. The default command prompt is a dash (-). To select a

244

IBM Tivoli Workload Scheduler: Reference Guide

Setting up the conman environment
different prompt, edit the conman prompt option in the localopts file and change the dash. The prompt can be up to 10 characters long, not including the required trailing pound sign (#).
#---------------------------------------------------------------------------# Custom format attributes # date format = 1 # The possible values are 0-ymd, 1-mdy, 2-dmy, 3-NLS. composer prompt = conman prompt = % switch sym prompt = <n>% #----------------------------------------------------------------------------

Running conman
To configure the environment for using conman set the PATH and TWS_TISDIR variables by running one of the following scripts: In UNIX: v . ./TWS_home/tws_env.sh for Bourne and Korn shells v . ./TWS_home/tws_env.csh for C shells In Windows: v TWS_home\tws_env.cmd Then use the following syntax to run commands from the conman user interface: conman [connection_parameters] [″command[&[command]...] [&]″] where: connection_parameters Represents the set of parameters that rule the interaction between the product interface, conman running on the master domain manager in this case, and the WebSphere Application Server infrastructure using HTTP or HTTPS. Use this syntax to specify the settings for the connection parameters: [-host hostname] [-port port_number] [-protocol protocol_name] [-proxy proxy_name] [-proxyport proxy_port_number] [-password user_password] [-timeout timeout] [-username username] where: hostname Is the hostname of the master domain manager. port_number Is the port number used when establishing the connection with the master domain manager. protocol_name Is the protocol used during the communication. It can be HTTP with basic authentication or HTTPS with certificate authentication. proxy_name Is the proxy hostname used in the connection with HTTP. proxy_port_number Is the proxy port number used in the connection with HTTP.

Chapter 9. Managing objects in the plan - conman

245

Running conman
user_password Is the password of the user that is used to run conman. | | | | | timeout Is the maximum time, expressed in seconds, the connecting command-line program can wait for the master domain manager response before considering the communication request as failed. username Is the user ID of the user running conman. This user name must be authorized to run the specific conman commands in the security file both on the connecting workstation and on the master domain manager, where the command actually runs. If any of these parameters is omitted when invoking conman, Tivoli Workload Scheduler searches for the value first in the useropts file and then in the localopts file. If a setting for the parameter is not specified either in the connection parameters when invoking the command or inside the useropts and localopts files then an error is displayed. Refer to“Setting up options for using the user interfaces” on page 29 for information on useropts and localopts files. You can invoke the conman command-line both in batch and in interactive mode. When running conman in interactive mode, you at first launch the conman command-line program and then, from the conman command-line prompt you run commands a time, for example:
conman –username admin2 –password admin2pwd ss @+state=hold;deps dds sked5;needs=2 tapes

Note: On Windows workstations, when you specify a password that contains double quotation marks (") or other special characters, make sure that the character is escaped. For example, if your password is tws11"tws, write it as "tws11\"tws".

When running conman in batch mode, you first launch the conman command-line program specifying as input parameter the command to be issued. Once the command is processed, the conman command-line program exits, for example
conman"sj&sp"

When issuing commands from conman in batch mode make sure you enclose the commands between double quotes. The following are examples of using batch mode to issue more than one command from within conman: v conman runs the sj and sp commands, and then quits:
conman "sj&sp"

v conman runs the sj and sp commands, and then prompts for a command:
conman "sj&sp&"

v conman reads commands from the file cfile:
conman < cfile

v commands from the file cfile are piped to conman:
cat cfile | conman

Control characters
You can enter the following control characters to interrupt conman.

246

IBM Tivoli Workload Scheduler: Reference Guide

Running conman
Control+c conman stops running the current command at the next step that can be interrupted, and returns a command prompt. Control+d conman quits after running the current command, on UNIX workstations only.

Running system commands
When you enter a system command using a pipe or a system command prefix (: or !), it is run by a child process. The child process’s effective user ID is set to the ID of the user running conman to prevent security breaches.

User prompting
When you use wildcard characters to select the objects to be acted upon by a command, conman prompts for confirmation after finding each matching object. Responding with yes allows the action to be taken, and no skips the object without taking the action. When you run conman interactively, the confirmation prompts are issued at your computer. Pressing the Return key in response to a prompt is interpreted as a no response. Prompting can be disabled by including the ;noask option in a command. Although no confirmation prompts are issued when conman is not running in interactive mode, it acts as though the response had been no in each case, and no objects are acted on. It is important, therefore, to include the ;noask option on commands when conman is not run in interactive mode.

Running commands from conman
conman commands consist of the following elements: commandname selection arguments where: commandname Specifies the command name. selection Specifies the object or set of objects to be acted upon. arguments Specifies the command arguments. The following is an example of a conman command:
sj sked1(1100 03/05/2006).@+state=hold~priority=0;info;offline

where: sj The abbreviated form of the showjobs command.

sked1(1100 03/05/2006).@+state=hold~priority=0 Selects all jobs in the job stream sked1(1100 03/05/2006) that are in the HOLD state with a priority other than zero. ;info;offline Arguments for the showjobs command.
Chapter 9. Managing objects in the plan - conman

247

Wildcards

Wildcards
The following wildcard characters are permitted: @ ? % Replaces one or more alphanumeric characters. Replaces one alphanumeric character. Replaces one numeric character.

Delimiters and special characters
Table 42 lists characters have special meanings in conman commands:
Table 42. Delimeters and special characters for conman Char. & + Description Command delimiter. See “Using the conman command line program” on page 243. A delimiter used to select objects for commands. It adds an attribute the object must have. For example: sked1(1100 03/05/2006).@~priority=0 ∼ A delimiter used to select objects for commands. It adds an attribute the object must not have. For example: sked1(1100 03/05/2006).@~priority=0 ; , = :! Argument delimiter. For example: ;info;offline Repetition and range delimiter. For example: state=hold,sked,pend Value delimiter. For example: state=hold Command prefixes that pass the command on to the system. These prefixes are optional; if conman does not recognize the command, it is passed automatically to the system. For example: !ls or :ls * Comment prefix. The prefix must be the first character on a command line or following a command delimiter. For example: *comment or sj& *comment > Redirects command output to a file and overwrites the contents of that file. If the file does not exist, it is created. For example: sj> joblist >> Redirects command output to a file and appends the output to the end of that file. If the file does not exist, it is created. For example: sj >> joblist | Pipes command output to a system command or process. The system command is run whether or not output is generated. For example: sj| grep ABEND || Pipes command output to a system command or process. The system command is not run if there is no output. For example: sj || grep ABEND

248

IBM Tivoli Workload Scheduler: Reference Guide

Conman commands processing

Conman commands processing
The conman program performs the commands that change the status of objects, such as start or stop for a workstation, and the commands that modify objects in the plan in an asynchronous way. This means that you might notice a delay between the time you submit the command and the time the information stored in the Symphony file is updated with the result of the command. This occurs because the conman program does not update the information stored in the Symphony file; conman submits the commands to batchman which is the only process which can access and update the information contained in the Symphony file. For this reason you need to wait for batchman to process the request of modifying the object issued by conman and then to update the information about the object stored in the Symphony file before seeing the updated information in the output of the showobj command. For example, if you request to delete a dependency using the conman deldep command, conman submits the deldep command by posting an event in the Mailman.msg mailbox. The mailman process gets the information about the deletion request from Mailman.msg and puts it in the Intercom.msg mailbox on the workstation that owns the resource you delete the dependency from. On each workstation, batchman receives the events in its Intercom.msg mailbox and processes them in the same order as they were received. If batchman is busy for any reason, events carrying requests to perform conman commands continue being queued in the Intercom.msg file waiting to be read and processed by batchman. In addition, when batchman processes the event, the operator is not notified. As a result, you could delete a dependency and it might appear that it had not been deleted because batchman was too busy to immediately perform the requested operation. If you run the command again, the deletion might have already been successful, even though a message saying that the command has been successfully forwarded to batchman is displayed in the conman prompt.

Selecting jobs in commands
For commands that operate on jobs, the target jobs are selected by means of attributes and qualifiers. The job selection syntax is shown below, and described on the following pages.

Syntax
[workstation#] {jobstreamname(hhmm[ date]) job | jobnumber} [{+ | ~}jobqualifier[...]] or [workstation#]jobstream_id.job [{+ | ~]jobqualifier[...]];schedid or: netagent::[workstation#] {jobstream(hhmm[ date]).job | jobstream_id.job;schedid}

Arguments
workstation When used with jobstream.job, this specifies the name of the workstation on which the job stream runs. When used with jobnumber, it specifies the workstation on which the job runs. Wildcard characters are permitted.
Chapter 9. Managing objects in the plan - conman

249

Selecting jobs in commands
jobstreamname Specifies the name of the job stream in which the job runs. Wildcard characters are permitted. (hhmm [date]) Indicates the time and date the job stream instance is located in the preproduction plan. The value hhmm corresponds to the value assigned to the schedtime keyword in the job stream definition if no at time constraint was set. After the job stream instance started processing, the value of hhmm [date] is set to the time the job stream started. The use of wildcards in this field is not allowed. When issuing inline conman commands from the shell prompt enclose the conman command in double quotes " ". For example, run this command as follows:
conman "sj my_workstation#my_js(2101 02/23).@"

jobstream_id Specifies the unique job stream identifier. See page 257 for more information on job stream identifier. schedid Indicates that the job stream identifier is used in selecting the job stream. jobname Specifies the name of the job. Wildcard characters are permitted. jobnumber Specifies the job number. jobqualifier See the following section, “Job qualifiers.” netagent Specifies the name of the Tivoli Workload Scheduler network agent that interfaces with the remote Tivoli Workload Scheduler network containing the target job. The two colons (::) are a required delimiter. Wildcard characters are permitted. For more information refer to Chapter 15, “Managing internetwork dependencies,” on page 499. Note: Tivoli Workload Scheduler helps you to identify the correct job stream instance when the job stream selection provides an ambiguous result if more than one instance satisfy your selection criteria. For example when more than one instances of WK1#J1 are included in the production plan and so the job stream selection provides an ambiguous result the following prompt is automatically generated to allow you to choose the correct instance:
Process WK1#J1[(0600 03/04/06),(0AAAAAAAAAAAABTB)] (enter "y" for yes, "n" for no)?y Command forwarded to batchman for WK1#J1[(0600 03/04/06),(0AAAAAAAAAAAABTB)] Process WK1#J1[(1010 03/04/06),(0AAAAAAAAAAAABTC)] (enter "y" for yes, "n" for no)?n

In the output only the job stream instance scheduled on (0600 03/04/06) and with identifier 0AAAAAAAAAAAABTB is selected to run the command.

Job qualifiers
Job qualifiers specify the attributes of jobs to be acted on by a command. They can be prefixed by + or ~. If a job qualifier is preceded by + then the jobs containing that specific attribute are selected for running the command. If a job qualifier is preceded by ~ then the jobs containing that specific attribute are excluded from running the command.

250

IBM Tivoli Workload Scheduler: Reference Guide

hightime | lowtime. | . the whole part represents the number of + days. expressed as mm/dd[/yy]. hightime Specifies the upper limit of a time range. time Specifies the time as follows: hhmm[+n days | date] [timezone|tz tzname] where: hhmm The hour and minute. expressed in the same format as time.hightime] Specifies the time within which a job must complete. when hhmm is later than the current time. Managing objects in the plan . deadline[=time | lowtime. Jobs are selected that are scheduled to start after this time. it is divided by 2400. lowtime Specifies the lower limit of a time range. while the decimal part represents the time. +n days An offset in days from the scheduled deadline time. confirmed Selects or excludes jobs that were scheduled using the confirm keyword. date The next occurrence of hhmm on date. See Chapter 12. date The next occurrence of hhmm on date. expressed as mm/dd[/yy]. at[=time | lowtime. Chapter 9. v When hhmm is greater than 2400. the start time is today. hhmm[+n days | date] [timezone|tz tzname] hhmm The hour and minute. the start time is tomorrow. expressed in the same format as time.Selecting jobs in commands Job qualifier keywords can be abbreviated to as few leading characters as needed to uniquely distinguish them from each other. Jobs are selected that are scheduled to start before this time. | . Of the division result. “Managing time zones. time conforms to the following rules: v When hhmm is earlier than the current time. If at is used alone and it is preceded by ~ then the jobs selected are those not containing an at dependency.” on page 461 for valid names.hightime ] Selects or excludes jobs based on the time specified in the at dependency.hightime | lowtime. +n days The next occurrence of hhmm in n number of days. If at is used alone and it is preceded by + then the jobs selected are those containing an at dependency. timezone|tz tzname The name of the time zone of the job.conman 251 .

time Specifies the exact time the job finished. Jobs are selected that finished at or before this time. expressed in the same format as rate.highrate | lowrate. hightime Specifies the upper limit of a time range. lowtime Specifies the lower limit of a time range.highrate] Selects or excludes jobs based on whether or not they have a repetition rate. “Managing time zones. lowrate Specifies the lower limit of a rate range. highrate Specifies the upper limit of a rate range. expressed as hours and minutes (hhmm). hightime Specifies the upper limit of a time range. expressed in the same format as time. The default is the time zone of the workstation on which the job or job stream is launched. See Chapter 12. expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute.hightime | lowtime. timezone|tz tzname The name of the time zone of the job. Jobs are selected that have repetition rates less than or equal to this rate. If every is used alone and it is preceded by + then the jobs selected are those containing any repetition rate.” on page 461 for valid names.Selecting jobs in commands timezone|tz tzname Specifies the time zone to be used when computing the deadline. expressed in the same format as time. expressed in the same format as rate. If every is used alone and it is preceded by ~ then the jobs selected are those not containing any repetition rate. expressed in the same format as time. | . expressed as mm/dd[/yy]. The next occurrence of hhmm on date. 252 IBM Tivoli Workload Scheduler: Reference Guide . See Chapter 12.hightime] Selects or excludes jobs based on whether or not they have finished. rate Specifies the scheduled run rate. Jobs are selected that have repetition rates equal to or greater than this rate. Selected jobs have a scheduled deadline not earlier than this time. “Managing time zones. Jobs are selected that finished at or after this time. every[=rate | lowrate. finished[=time | lowtime. lowtime Specifies the lower limit of a time range. Selected jobs have a scheduled deadline not later than this time. | .” on page 461 for time zone names. expressed in the same format as time. If finished is used alone and it is preceded by + then the jobs selected are the jobs that have finished running.

] Selects or excludes jobs based on whether or not they have a follows dependency. you specify that the target job follows all jobs in the job stream.job. netagent Specifies the name of the Tivoli Workload Scheduler network agent that interfaces with the remote Tivoli Workload Scheduler network containing the prerequisite job. one containing the job streams identified by the jobstreamname without the schedid keywords. you must use two different follows clauses. If follows is used alone and it is preceded by ~ then the jobs are selected if they contain no follows dependency.Selecting jobs in commands If finished is used alone and it is preceded by ~ then the jobs selected are the jobs that have not finished running. The nocheck keyword indicates that conman does not have to check for the existence of the prerequisite job jobstream_id.nocheck][. If follows is used alone and it is preceded by + then the jobs are selected if they contain follows dependencies.job | @] | jobstream_id. For more information refer to Chapter 15. Chapter 9..” on page 499.. jobname Specifies the name of the prerequisite job. Managing objects in the plan . Do not specify the job name using wildcard characters for a follows dependency. follows=[netagent::][workstation#]{jobstreamname(hhmm [mm/dd[/yy]])[. in case it does not exist batchman prints a warning message in the stdlist. See page 257 for more information on job stream identifier. It is assumed that jobstream_id. Wildcard characters are permitted. jobstreamname Specifies the name of the job stream in which the prerequisite job runs. If you want to select some job streams using the jobstream_id and some job streams using the jobstreamname.job in the Symphony file. schedid This keyword.. applies to all the job streams identifiers specified in the clause and indicates that for all the job streams specified you are using the jobstream_ids and not the jobstreamnames. Wildcard characters are permitted. If you enter jobstreamname.@.job exists.conman 253 . and the other containing the job streams identified by the jobstream_id with the schedid keyword. When entered without a jobstreamname. jobstream_id Specifies the unique job stream identifier. workstation Specifies the name of the workstation on which the prerequisite job runs. Wildcard characters are permitted. “Managing internetwork dependencies.schedid}| job[. it means that the prerequisite job is in the same job stream as the target job. if present. nocheck Is valid only for the submission commands and used in conjunction with theschedid keyword.

A file dependency occurs when a job or job stream is dependent on the existence of one or more files before it can begin running. filename Specifies the name of the file. | . Wildcard characters are permitted. qualifier A valid test condition. lowpri Specifies the lower limit of a priority range. Jobs are selected with priorities less than or equal to this value. hi or go. Wildcard characters are permitted. priority=pri | lowpri.Selecting jobs in commands logon=username Select jobs based on the user names under which they run. resourcename Specifies the name of the resource. prompt[=promptname | msgnum] Selects or excludes jobs based on whether or not they have a prompt dependency. pri Specifies the priority value. and underscores (_). If opens is used alone and it is preceded by + then the jobs are selected if they contain file dependencies. backslashes (\). If opens is used alone and it is preceded by ~ then the jobs are selected if they contain no file dependency. opens[=[workstation#]filename[(qualifier)]] Select jobs based on whether or not they have a file dependency. workstation Specifies the name of the workstation on which the file exists. If omitted. needs[=[workstation#]resourcename] Selects or excludes jobs based on whether or not they have a resource dependency. If needs is used alone and it is preceded by + then the jobs are selected if they contain resource dependencies. If username contains special characters it must be enclosed in quotes (″). If needs is used alone and it is preceded by ~ then the jobs are selected if they contain no resource dependency. Jobs are selected with priorities equal to or greater than this value. slashes (/). jobs are selected or excluded without regard to a qualifier. Wildcard characters are permitted. Wildcard characters are permitted. The name must be enclosed in quotes (″) if it contains special characters other than the following: alphanumerics. 254 IBM Tivoli Workload Scheduler: Reference Guide . You can enter 0 through 99.highpri Selects or excludes jobs based on their priorities.highpri | lowpri. Wildcard characters are permitted. dashes (-). workstation Specifies the name of the workstation on which the resource is defined. highpri Specifies the upper limit of a priority range.

filename Specifies the name of an executable file.. Valid job states are as follows: ABEND The job ended with a nonzero exit code.] Selects or excludes jobs based on their states. slashes (/). continue.. expressed as mm/dd[/yy].hightime] Selects or excludes jobs based on whether or not they have started. Jobs are selected that started at or after this time. See Chapter 12. If prompt is used alone and it is preceded by ~ then the jobs are selected if they contain no prompt dependency.hightime | lowtime. expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute. time Specifies the exact time the job started. timezone|tz tzname The name of the time zone of the job. dashes (-). recv-option Specifies the job recovery option as stop. If started is used alone and it is preceded by ~ then the jobs selected are the jobs that have not started running. expressed in the same format as time. Managing objects in the plan . state Specifies the current state of the job. state=state[. expressed in the same format as time. lowtime Specifies the lower limit of a time range.. Jobs are selected that started at or before this time. started[=time | lowtime. hightime Specifies the upper limit of a time range. or rerun. and underscores (_). The name must be enclosed in quotes (″) if it contains special characters other than the following: alphanumerics. recovery=recv-option Selects or excludes jobs based on their recovery options. scriptname=filename Selects or excludes jobs based on their executable file names. “Managing time zones.Selecting jobs in commands promptname Specifies the name of a global prompt. Wildcard characters are permitted. | . Chapter 9. backslashes (\). If started is used alone and it is preceded by + then the jobs selected are the jobs that have started running. msgnum Specifies the message number of a local prompt. Wildcard characters are permitted.conman 255 . If prompt is used alone and it is preceded by + then the jobs are selected if they contain prompt dependencies. The next occurrence of hhmm on date.” on page 461 for valid names.

or the remote job or job stream does not exist. time Specifies the scheduled end time expressed as follows: hhmm[+n days | date] [timezone|tz tzname] hhmm The hour and minute. ADD DONE The job completed in an unknown state. FAIL FENCE The job’s priority value is below the fence. INTRO+ A transitory state when the job is introduced by the local batchman process. and all dependencies are resolved.hightime | lowtime. 256 IBM Tivoli Workload Scheduler: Reference Guide .Selecting jobs in commands ABENP An abend confirmation was received. SUCC The job completed with an exit code of zero. until[=time | lowtime. READY The job is ready to launch. and is awaiting confirmation.hightime ] Selects or excludes jobs based on their scheduled end time. EXTRN For internetwork dependencies only. HOLD The job is awaiting dependency resolution. a rerun action was just performed on the job in the EXTERNAL job stream. INTRO The job is introduced for launching by the system. but the job has not completed. WAIT The job is in the WAIT state (extended agent only). | . EXEC The job is running. SCHED The job’s at time has not arrived. An error occurred. but the job has not completed. Unable to launch the job. EXEC+ A transitory state when the job is launched by the local batchman process. SUCCP A succ confirmation was received. PEND The job completed. The job is being submitted. ERROR For internetwork dependencies only. the status is unknown. an error occurred while checking for the remote status.

For this reason the jobstream_id has been made available to the user.. Because scheddateandtime is specified in minutes.schedid Arguments workstation Specifies the name of the workstation on which the job stream runs. You can choose one of the two syntaxes described. Syntax [workstation#]jobstreamname(hhmm[ date]) [{+ | ~}jobstreamqualifier[. This value corresponds to the value assigned to the schedtime keyword in the job stream definition if no at time constraint was set. expressed in the same format as time. After the job stream instance started processing the value of hhmm [date] is set to the time the job stream started. When issuing in line conman commands from the Chapter 9. If until is used alone and it is preceded by ~ then the jobs are selected if they have no until time specified. Wildcard characters are permitted. Wildcard characters are permitted. If until is used alone and it is preceded by + then the jobs are selected if they have an until time specified.]] [workstation#]jobstream_id . expressed in the same format as time. date The next occurrence of hhmm on date. The use of wildcards in this field is not allowed. the combination of the jobstreamname and the scheddateandtime time might not be unique. “Managing time zones.” on page 461 for valid names.. Jobs are selected that have scheduled end times on or before this time. lowtime Specifies the lower limit of a time range. See Chapter 12. Selecting job streams in commands For commands that operate on job streams. The job stream selection syntax is shown below. Jobs are selected that have scheduled end times on or after this time. jobstreamname Specifies the name of the job stream. the target job streams are selected by specifying attributes and qualifiers.Selecting jobs in commands +n days The next occurrence of hhmm in n number of days. Managing objects in the plan . expressed as mm/dd[/yy]. (hhmm [date]) Indicates the time and date the job stream instance is located in the preproduction plan. either for display purposes or to perform actions against a specific instance of a job stream. hightime Specifies the upper limit of a time range.conman 257 . timezone|tz tzname The name of the time zone of the job. and described on the following pages.

timezone|tz tzname The name of the time zone of the job stream.(0AAAAAAAAAAAABTC)] (enter "y" for yes. “Managing time zones. +n days The next occurrence of hhmm in n number of days.schedid option. lowtime Specifies the lower limit of a time range. Note: Tivoli Workload Scheduler helps you to identify the correct job stream instance when the job stream selection provides an ambiguous result if more than one instance satisfy your selection criteria. but it can often be used also when managing the job stream from the conman command-line program by specifying the .” on page 461 for valid names. See Chapter 12. expressed as mm/dd[/yy]. It is mainly used by internal processes to identify that instance of the job stream within the production plan. schedid Indicates that the job stream identifier is used in selecting the job stream. 258 IBM Tivoli Workload Scheduler: Reference Guide .Selecting job streams in commands shell prompt enclose the conman command in double quotes " ". time Specifies the scheduled start time expressed as follows: hhmm[+n days | date] [timezone|tz tzname] hhmm The hour and minute. Job streams are selected that have scheduled start times on or after this time. run this command as follows: conman "ss my_workstation#my_js(2101 02/23)" jobstreamqualifier See “Job Stream Qualifiers” below. For example. "n" for no)?n In the output only the job stream instance scheduled on (0600 03/04/06) and with identifier 0AAAAAAAAAAAABTB is selected to run the command. expressed in the same format as time. | . "n" for no)?y Command forwarded to batchman for WK1#J1[(0600 03/04/06). For example when more than one instances of WK1#J1 are included in the production plan and so the job stream selection provides an ambiguous result the following prompt is automatically generated to allow you to choose the correct instance: Process WK1#J1[(0600 03/04/06).(0AAAAAAAAAAAABTB)] Process WK1#J1[(1010 03/04/06).hightime ] Selects or excludes job streams based on the scheduled start time.(0AAAAAAAAAAAABTB)] (enter "y" for yes. Job stream qualifiers at[=time | lowtime.hightime | lowtime. date The next occurrence of hhmm on date. jobstream_id Specifies the unique alphanumerical job stream identifier automatically generated by the planner and assigned to that job stream.

excludes job streams that were carried forward if preceded by ~. expressed as mm/dd[/yy]. If finished is used alone and it is preceded by ~ then the jobs streams selected are the jobs that have not finished running. expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute..schedid}| job[. if preceded by ~ excludes job streams that were scheduled using the carryforward keyword.conman 259 . timezone|tz tzname The name of the time zone of the job stream. Job streams are selected that finished at or after this time. expressed in the same format as time. hightime Specifies the upper limit of a time range. expressed in the same format as time..job | @] | jobstream_id. netagent Specifies the name of the network agent that interfaces with the remote Tivoli Workload Scheduler network containing the prerequisite job or job stream. Chapter 9. Job streams are selected that finished at or before this time. | . carriedforward Selects job streams that were carried forward if preceded by +. finished[=time | lowtime.Selecting job streams in commands hightime Specifies the upper limit of a time range. Managing objects in the plan . See Chapter 12. carryforward If preceded by + selects job streams that were scheduled using the carryforward keyword. The next occurrence of hhmm on date. If finished is used alone and it is preceded by + then the jobs streams selected are the jobs that have finished running.] Selects or excludes job streams based on whether or not they have a follows dependency.” on page 461 for valid names. “Managing time zones. Wildcard characters are permitted. If at is used alone and it is preceded by + then the job streams selected are those containing an at dependency. expressed in the same format as time. lowtime Specifies the lower limit of a time range. If at is used alone and it is preceded by ~ then the job streams selected are those not containing an at dependency.hightime] Selects or excludes job streams based on whether or not they have finished.hightime | lowtime.job. Job streams are selected that have scheduled start times at or before this time.nocheck] [. time Specifies the exact time the job streams finished. follows=[netagent::][workstation#]{jobstreamname(hhmm [mm/dd[/yy]])[..

one containing the job streams identified by the jobstreamname without the schedid keywords. If follows is used alone and it is preceded by ~ then the jobs streams are selected if they contain no follows dependency. if present. limit lowlimit Specifies the lower limit of range. Specifies the exact job limit value. highlimit Specifies the upper limit of a range. Wildcard characters are permitted. in case it does not exist batchman prints a warning message in the stdlist. limit[=limit | lowlimit. you must use two different follows clauses. schedid This keyword. jobname Specifies the name of the prerequisite job. If follows is used alone and it is preceded by + then the jobs streams are selected if they contain follows dependencies. Wildcard characters are permitted. refer to Chapter 15.” on page 499.highlimit] Selects or excludes job streams based on whether or not they have a job limit. It is assumed that jobstream_id.job in the Symphony file. If you want to select some job streams using the jobstream_id and some job streams using the jobstreamname. applies to all the job streams identifiers specified in the clause and indicates that for all the job streams specified you are using the jobstream_ids and not the jobstreamnames. The nocheck keyword indicates that conman does not have to check for the existence of the prerequisite job jobstream_id. If limit is used alone and it is preceded by + then the jobs streams are selected if they have any job limit. and the other containing the job streams identified by the jobstream_id with the schedid keyword. “Managing internetwork dependencies. jobstream_id Specifies the unique job stream identifier.highlimit | lowlimit. If limit is used alone and it is preceded by ~ then the jobs streams are selected if they have no job limit. jobstreamname Specifies the name of the prerequisite job stream. nocheck Is valid only for the submission commands and used in conjunction with theschedid keyword. workstation Specifies the name of the workstation on which the prerequisite job or job stream runs. See page 257 for more information on job stream identifier. Job streams are selected that have job limits less than or equal to this limit. | . Job streams are selected that have job limits equal to or greater than this limit. Wildcard characters are permitted.Selecting job streams in commands For more information about network agents.job exists. 260 IBM Tivoli Workload Scheduler: Reference Guide .

filename Specifies the name of the file. qualifier A valid test condition. pri Specifies the priority value.conman 261 . If opens is used alone and it is preceded by + then the jobs streams are selected if they contain file dependencies. prompt[=promptname | msgnum] Selects or excludes job streams based on whether or not they have a prompt dependency. Job streams are selected with priorities equal to or greater than this value.highpri Selects or excludes job streams based on their priorities. If omitted. highpri Specifies the upper limit of a priority range.Selecting job streams in commands needs[=[workstation#]resourcename] Selects or excludes job streams based on whether or not they have a resource dependency. The name must be enclosed in quotes (″) if it contains special characters other than the following: alphanumerics. If needs is used alone and it is preceded by ~ then the jobs streams are selected if they contain no resource dependency. Wildcard characters are permitted. resourcename Specifies the name of the resource. priority=pri | lowpri.highpri | lowpri. opens[=[workstation#]filename[(qualifier)]] Selects or excludes job streams based on whether or not they have a file dependency. job streams are selected or excluded without regard to a qualifier. Job streams are selected with priorities less than or equal to this value. promptname Specifies the name of a global prompt. Wildcard characters are permitted. lowpri Specifies the lower limit of a priority range. Wildcard characters are permitted. dashes (-). You can enter 0 through 99. and underscores (_). If needs is used alone and it is preceded by + then the jobs streams are selected if they contain resource dependencies. Wildcard characters are permitted. slashes (/). workstation Specifies the name of the workstation on which the resource is defined. workstation Specifies the name of the workstation on which the file exists. If opens is used alone and it is preceded by ~ then the jobs streams are selected if they contain no file dependency. Chapter 9. hi or go. Managing objects in the plan . | . Wildcard characters are permitted. backslashes (\). A file dependency occurs when a job or job stream is dependent on the existence of one or more files before it can begin running.

If started is used alone and it is preceded by + then the jobs streams selected are the jobs that have started running. expressed in the same format as time. timezone|tz tzname The name of the time zone of the job stream. EXEC The job stream is running. Job streams are selected that started at or before this time. and all dependencies are resolved. No jobs are launched without operator intervention. state=state[..” on page 461 for valid names. The next occurrence of hhmm on date. If started is used alone and it is preceded by ~ then the jobs streams selected are the jobs that have not started running. READY The job stream is ready to launch. STUCK Execution is interrupted. “Managing time zones. started[=time | lowtime. time Specifies the exact time the job stream started.] Selects or excludes job streams based on their states.Selecting job streams in commands msgnum Specifies the message number of a local prompt. lowtime Specifies the lower limit of a time range.hightime | lowtime. ADD The job stream has just been submitted. | . 262 IBM Tivoli Workload Scheduler: Reference Guide . expressed as mm/dd[/yy]. expressed in the same format as time.. Job streams are selected that started at or after this time. state Specifies the current state of the job stream. See Chapter 12. expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute. If prompt is used alone and it is preceded by ~ then the jobs streams are selected if they contain no prompt dependency.hightime] Selects or excludes job streams based on whether or not they have started. hightime Specifies the upper limit of a time range. If prompt is used alone and it is preceded by + then the jobs streams are selected if they contain prompt dependencies. Valid job stream states are as follows: ABEND The job stream ended abnormally. HOLD The job stream is awaiting dependency resolution..

Selecting job streams in commands
SUCC The job stream completed successfully. until[=time | lowtime, | ,hightime | lowtime,hightime ] Selects or excludes job streams based on the scheduled end time. time Specifies the scheduled end time expressed as follows: hhmm[+n days | date] [timezone|tz tzname] hhmm The hour and minute.

+n days The next occurrence of hhmm in n number of days. date The next occurrence of hhmm on date, expressed as mm/dd[/yy].

timezone|tz tzname The name of the time zone of the job stream. See Chapter 12, “Managing time zones,” on page 461 for valid names. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Job streams are selected that have scheduled end times on or after this time. hightime Specifies the upper limit of a time range, expressed in the same format as time. Job streams are selected that have scheduled end times on or before this time. If until is used alone and it is preceded by + then the jobs streams selected are those containing any scheduled end time. If until is used alone and it is preceded by ~ then the jobs streams selected are those not containing any scheduled end time.

Managing jobs and job streams from back-level agents
The change in the job stream instance naming convention introduced with Tivoli Workload Scheduler version 8.3 requires you to apply the following workaround when issuing command-line commands against a plan generated on a Tivoli Workload Scheduler version 8.3 (or later) master domain manager from Tivoli Workload Scheduler version 8.1, 8.2, or 8.2.1 agents: v You must use the @ symbol as the first character for the job stream instance identifier. For example the job stream running on CPU1 workstation with identifier 0AAAAAAAAAAAAY3 must be identified in the conman command line as follows:
CPU1#@AAAAAAAAAAAAY3

v You cannot use the follows keyword when adding a dependency to a job or a job stream or when submitting as a job a command or a file. v You cannot use the into keyword to specify the job stream where the job must be added when submitting as a job a command or a file. For example, to display the information about the job job2 contained in the job stream instance with identifier 0AAAAAAAAAAAAT1 running on CPU1 workstation, run the following command on Tivoli Workload Scheduler version 8.1, 8.2, or 8.2.1 agents:
sj CPU1#@AAAAAAAAAAAAT1.job2

Chapter 9. Managing objects in the plan - conman

263

Managing jobs and job streams from back-level agents
These changes will also be seen in reports and logs, and any other places where job stream names are printed or displayed.

Command descriptions
Table 43 lists the conman commands. Note: Command names and keywords can be entered in either uppercase or lowercase characters, and can be abbreviated to as few leading characters as are needed to uniquely distinguish them from each other. Some of the command names also have short forms.
Table 43. List of conman commands Command adddep altpass altpri ap bulk Short Form adj | ads Description Adds job or job stream dependencies. Type1 F Page 267, 269 271 272 273

Alters a user object definition password. F Alters job or job stream priorities. F

| | |

bulk_discovery

Performs a bulk discovery. For use with F IBM Tivoli Monitoring 6.1 (Tivoli Enterprise Portal). Cancels a job or a job stream. Confirms job completion. Assigns the Tivoli Workload Scheduler console. Ignores the next error. F F F,S F,S F

cancel confirm console continue deldep

cj | cs

281, 276 278 279 280 302, 283 285

ddj | dds deploy

Deletes job or job stream dependencies.

| | |

deployconf

Gets the latest monitoring configuration F,S for the event monitoring engine on the workstation. Displays files, jobs, and job streams. Exits conman. Sets Tivoli Workload Scheduler job fence. Displays command information. Stops an executing job. F,S2 F,S F F,S F

display exit fence help4 kill limit link listsym recall redo release reply rerun resource setsym

df | dj | ds

286 289 290 291 292 293, 294 295 297 299 300 274, 304 306 307 310 311 312

lc | ls lk

Changes a workstation or job stream job F limit. Opens workstation links. Displays a list of Symphony log files. F,S F F F,S

rc

Displays prompt messages. Edits the previous command.

rj | rs

Releases job or job stream dependencies. F Replies to prompt message. F F F F F,S

rr

Reruns a job. Changes the number of resource units. Selects a Symphony log file.

| |

showcpus

sc

Displays workstation and link information.

264

IBM Tivoli Workload Scheduler: Reference Guide

Command descriptions
Table 43. List of conman commands (continued) Command showdomain showfiles showjobs showprompts showresources showschedules shutdown start sf sj sp sr ss shut Short Form Description Displays domain information. Displays information about files. Displays information about jobs. Displays information about prompts. Displays information about resources. Displays information about job streams. Stops Tivoli Workload Scheduler production processes. Starts Tivoli Workload Scheduler production processes. Starts the embedded WebSphere Application Server process startevtp startm Starts the event processing server. Starts the monman process that turns on the event monitoring engine on the agent. Displays Tivoli Workload Scheduler production status. Stops Tivoli Workload Scheduler production processes. Stops Tivoli Workload Scheduler production processes hierarchically. Stops the embedded WebSphere Application Server process stopevtp stopm sbd | sbf | sbj | sbs switchevtp Stops the event processing server. Stops the event monitoring engine on the agent. Submits a command, file, job, or job stream. F,S M5 F,S F,S3 Type1 F,S F F F F F F,S F,S F,S M5 F,S Page 317 319 321 332 335 337 341 342 “startappserver” on page 345 346 347

| | | | | |

startappserver starteventprocessor startmon

status stop stop ;progressive

F,S F,S

348 349 351 “stopappserver” on page 352 353 354 355, 358, 361, 363 366

| | | | |

stopappserver stopeventprocessor stopmon submit

| | |

switcheventprocessor

Switches the event processing server from master domain managers to backup masters or vice versa. Switches the domain manager. Sends a command to the system.

M

switchmgr sys-command tellop unlink version v to

F F,S F,S F,S F,S

367 368 369 370 372

Sends a message to the console. Closes workstation links. Displays conman’s command line program banner.

| |

1. Workstation types: master domain managers and backup masters (M), domain managers and fault-tolerant agents (F), standard agents (S). 2. You can only display files on a standard agent.

Chapter 9. Managing objects in the plan - conman

265

Command descriptions
3. You can use submit job (sbj) and submit sched (sbs) on a standard agent by using the connection parameters or specifying the settings in the useropts file when invoking the conman command line. 4. Not available on supported Windows operating system. 5. Includes workstations installed as backup masters but used as ordinary fault-tolerant agents. Note: In the commands, the terms sched and schedule refer to job streams, and the term CPU refers to workstation.

| |

266

IBM Tivoli Workload Scheduler: Reference Guide

adddep job

adddep job
Adds dependencies to a job. You must have adddep access to the job. To include needs and prompt dependencies, you must have use access to the resources and global prompts.

Syntax
adj jobselect [;dependency[;...]] [;noask]

Arguments
jobselect See “Selecting jobs in commands” on page 249. dependency The type of dependency. Specify one of the following. Wildcard characters are not permitted. at=hhmm[timezone | tz tzname][+n days | mm/dd[/yy]] | [absolute | abs] confirmed deadline=time [timezone|tz tzname][+n day[s | mm/dd[/yy]] every=rate follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][.job | @] | jobstream_id.job;schedid}| job[,...] needs=[num] [workstation#]resource[,...] opens=[workstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go] prompt=″[: | !]text″ | promptname[,...] until time [timezone|tz tzname][+n day[s]] | [absolute | abs] [;onuntil action] noask Specifies not to prompt for confirmation before taking action on each qualifying job. Notes: 1. If you add twice a dependency on a job stream to a job, both dependencies are considered.. 2. When using the deadline keyword, ensure the bm check deadline variable is set to a value higher than 0 in the localopts configuration file on the target workstations for the job or job stream. For information, refer to IBM Tivoli Workload Scheduler Planning and Installation Guide.

Comments
If you do not specify a value for priority, the job reverts to its original scheduled priority. If you do not specify a workstation in follows, needs, or opens, the default is the workstation on which the job runs. You cannot use this command to add a resource or a prompt as dependencies unless they are already referenced by a job or a job stream in the Symphony file.

Examples
To add a resource dependency to job job3 in job stream sked9(0900 02/19/06), run the following command:
Chapter 9. Managing objects in the plan - conman

267

adddep job
adj sked9(0900 02/19/06).job3 ; needs=2 tapes

To add an external follows dependency from to job JOB022 in job stream MLN#SCHED_02(0600 02/24) to JOBA in job stream MLN#NEW_TEST(0900 02/19/06), run the following command:
adj MLN#NEW_TEST(0900 02/19/06).JOBA ; follows MLN#SCHED_02(0600 02/24/06).JOB022

To add a file dependency, and an until time to job j6 in job stream JS2(0900 02/19/06), run the following command:
adj WK1#JS2(0900 02/19/06).j6 ; opens="/usr/lib/prdata/file5"(-s %p) ; until=2330

See also
For the equivalent Job Scheduling Console task, see ″Creating Dependencies between Jobs″ and ″Adding External Dependencies to a Job Stream″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

268

IBM Tivoli Workload Scheduler: Reference Guide

adddep sched

adddep sched
Adds dependencies to a job stream. You must have adddep access to the job stream. To include needs and prompt dependencies, you must have use access to the resources and global prompts.

Syntax
ads jstreamselect [;dependency[;...]] [;noask]

Arguments
jstreamselect See “Selecting job streams in commands” on page 257. dependency The type of dependency. Specify one of the following. Wildcard characters are not permitted. at=hhmm[timezone | tz tzname][+n days | mm/dd[/yy]] | [absolute | abs] carryforward deadline=time [timezone|tz tzname][+n day[s | mm/dd[/yy]] follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][.job | @] | jobstream_id.job;schedid}| job[,...] limit=limit needs=[num] [workstation#]resource[,...] opens=[workstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go] prompt=″[: | !]text″ | promptname[,...] until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [;onuntil action] noask Specifies not to prompt for confirmation before taking action on each qualifying job stream. Notes: 1. If you add twice a dependency on a job stream to another job stream, only one dependency is considered. 2. When using the deadline keyword, ensure the bm check deadline variable is set to a value higher than 0 in the localopts configuration file on the target workstations for the job or job stream. For information, refer to IBM Tivoli Workload Scheduler Planning and Installation Guide.

Comments
v If you do not specify a value for priority, the job stream reverts to its original scheduled priority. v If you do not specify a value for limit, the value defaults to 0. v If you do not specify a workstation in follows, needs, or opens, the default is the workstation on which the job stream runs. v You cannot use this command to add a resource or a prompt as dependencies unless they already exists in the production plan. To see which resource and prompts exist in the plan refer to “showresources” on page 335 and “showprompts” on page 332.
Chapter 9. Managing objects in the plan - conman

269

adddep sched

Examples
To add a prompt dependency to job stream sked9(0900 02/19/06), run the following command:
ads sked9(0900 02/19/06) ; prompt=msg103

To add an external follows dependency from to job JOBB in job stream CPUA#SCHED_02(0600 02/24/06) and a job limit to job stream CPUA#TEST(0900 02/19/06), run the following command:
ads CPUA#TEST(0900 02/19/06) ; follows CPUA#SCHED_02(0600 02/24/06).JOBB; limit=2

See also
For the equivalent Job Scheduling Console task, see ″Creating Dependencies within a Job Stream″ and ″Creating Dependencies between Job Streams″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

270

IBM Tivoli Workload Scheduler: Reference Guide

altpass

altpass
Alters the password of a user object in the current production plan. You must have altpass access to the user object.

Syntax
altpass [workstation#] username [;″password″]

Arguments
workstation Specifies the workstation on which the user is defined. Use the upper case for this field even though you used the mixed case when specifying the workstation in the Windows user definition. For more information refer to “Windows user definition” on page 125. Do not specify this field if the user belongs to a active directory managed Windows domain. The default is the workstation on which you are running conman. Specifies the name of a user. Use the upper case for this field even though you used the mixed case when specifying the [domain\]username in the Windows user definition. For more information. refer to “Windows user definition” on page 125. Specifies the new password. It must be enclosed in double quotes. To indicate no password for the user, use two consecutive double quotes (″″).

username

password

Comments
If you do not specify a password, conman prompts for a password and a confirmation. The password is not displayed as it is entered and should not be enclosed in quotes. Note that the change is made only in the current production plan, and is therefore temporary. To make a permanent change see “Windows user definition” on page 125.

Examples
To change the password of user Jim on workstation mis5 to mynewpw, run the following command:
altpass MIS5#JIM;”mynewpw”

To change the password of user jim on workstation Mis5 to mynewpw without displaying the password, run the following command:
altpass MIS5#JIM password: xxxxxxxx confirm: xxxxxxxx

To change the password of user Jim, defined in an active directory managed Windows domain named twsDom, to mynewpw, run the following command:
altpass TWSDOM\JIM;”mynewpw”

See also
For the equivalent Job Scheduling Console task, see ″Changing Windows User Passwords″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

Chapter 9. Managing objects in the plan - conman

271

altpri

altpri
Alters the priority of a job or job stream. You must have altpri access to the job or job stream.

Syntax
ap jobselect | jstreamselect [;pri] [;noask]

Arguments
jobselect jstreamselect pri noask See “Selecting jobs in commands” on page 249. See “Selecting job streams in commands” on page 257. Specifies the priority level. You can enter a value of 0 through 99, hi, or go. Specifies not to prompt for confirmation before taking action on each qualifying job or job stream.

Examples
To change the priority of the balance job in job stream glmonth(0900 02/19/06), run the following command:
ap glmonth(0900 02/19/06).balance;55

To change the priority of job stream glmonth(0900 02/19/06), run the following command:
ap glmonth(0900 02/19/06);10

272

IBM Tivoli Workload Scheduler: Reference Guide

bulk_discovery

bulk_discovery
| | | Requests a bulk discovery to update the current status of monitored objects. It is used for the integration with IBM Tivoli Monitoring 6.1 (Tivoli Enterprise Portal). You must have display access to the file object.

Syntax
bulk

Comments
When the integration with IBM Tivoli Monitoring 6.1 is enabled, the bulk_discovery command checks the status of all monitored jobs and job streams within the plan and writes the corresponding events in the event log file. By default, events are written in the event.log file. Messages indicating the start and end of the bulk discovery activity are logged in the twsmerge.logfile.

Chapter 9. Managing objects in the plan - conman

273

cancel job

cancel job
Cancels a job. You must have cancel access to the job.

Syntax
cj jobselect [;pend] [;noask]

Arguments
jobselect pend noask See “Selecting jobs in commands” on page 249. Cancels the job only after its dependencies are resolved. Specifies not to prompt for confirmation before taking action on each qualifying job.

Comments
If you cancel a job before it is launched, it does not launch. If you cancel a job after it is launched, it continues to run. If you cancel a job that is running and it completes in the ABEND state, no automatic job recovery steps are attempted. If you do not use the ;pend option, jobs and job streams that are dependent on the cancelled job are released immediately from the dependency. If you include the ;pend option, and the job has not been launched, cancellation is deferred until all of the dependencies, including an at time, are resolved. Once all the dependencies are resolved, the job is cancelled and any jobs or job streams that are dependent on the cancelled job are released from the dependency. During the period the cancel is deferred, the notation [Cancel Pend] is listed in the Dependencies column of the job in a showjobs display. If you include the ;pend option and the job has already been launched, the option is ignored, and any jobs or job streams that are dependent on the cancelled job are immediately released from the dependency. You can use the rerun command to rerun jobs that have been cancelled, or that are marked [Cancel Pend]. You can also add and delete dependencies on jobs that are marked [Cancel Pend]. To immediately cancel a job that is marked [Cancel Pend], you can either enter a release command for the job or enter another cancel command without the ;pend option. For jobs with expired until times, the notation [Until] is listed in the Dependencies column in a showjobs display, and their dependencies are no longer evaluated. If such a job is also marked [Cancel Pend], it is not cancelled until you release or delete the until time, or enter another cancel command without the ;pend option. To stop evaluating dependencies, set the priority of a job to zero with the altpri command. To resume dependency evaluation, set the priority to a value greater than zero. Note: In the case of internetwork dependencies, cancelling a job in the EXTERNAL job stream releases all local jobs and job streams from the dependency. Jobs

274

IBM Tivoli Workload Scheduler: Reference Guide

job3. Examples To cancel job report in job stream apwkly(0900 02/19/06) on workstation site3.conman 275 . The status of an internetwork dependency is not checked after a cancel is performed. For more information see “Managing internetwork dependencies” on page 504.cancel job in the EXTERNAL job stream represent jobs and job streams that have been specified as internetwork dependencies.setup~state=abend To cancel job job3 in job stream sked3(0900 02/19/03) only after its dependencies are resolved. run the following command: cj mis5(1100 02/10/06). run the following command: cj site3#apwkly(0900 02/19/06). if it is not in the ABEND state.pend See also For the equivalent Job Scheduling Console task. Managing objects in the plan . run the following command: cj sked3(0900 02/19/06). see ″Deleting a Job from a Job Stream″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. Chapter 9.report To cancel job setup in job stream mis5(1100 02/10/06).

set the job stream’s priority to zero with the altpri command. set the priority to a value greater than zero. If you include the .cancel sched cancel sched Cancels a job stream. jobs and job streams that are dependent on the cancelled job stream are released immediately from the dependency. You must have cancel access to the job stream. it does not launch. the job stream is cancelled and any dependent jobs or job streams are released from the dependency.pend option and the job stream has not been launched. any remaining jobs in the job stream are cancelled. If you cancel a job stream after it is launched. Comments If you cancel a job stream before it is launched.pend] [. If you use the . If such a job stream is also marked [Cancel Pend]. To stop evaluating dependencies. including an at time. it is not cancelled until you release or delete the until time or enter another cancel command without the . run the following command: cs site2#sked1(1200 02/17) 276 IBM Tivoli Workload Scheduler: Reference Guide . and any dependent jobs and job streams are released from the dependency. are resolved.pend option. Once all dependencies are resolved. either enter a release command for the job stream or enter another cancel command without the . During the period the cancel is deferred. To resume dependency evaluation. Specifies not to prompt for confirmation before taking action on each qualifying job stream. but no other jobs are launched. To immediately cancel a job stream marked [Cancel Pend]. Cancels the job stream only after its dependencies are resolved.pend option. cancellation is deferred until all of its dependencies. the jobs that have started complete. For job streams with expired until times. the notation [Cancel Pend] is listed in the Dependencies column of a showschedules display.pend option. the notation [Until] appears in the Dependencies column of the showschedules display and their dependencies are no longer evaluated. Syntax cs jstreamselect [. If you do not use the . Examples To cancel job stream sked1(1200 02/17/06) on workstation site2.pend option and the job stream has already been launched.noask] Arguments jstreamselect pend noask See “Selecting job streams in commands” on page 257.

Managing objects in the plan . Chapter 9.conman 277 . see ″Deleting Job Streams″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. run the following command: cs mis2(0900 02/19)+state=stuck See also For the equivalent Job Scheduling Console task.cancel sched To cancel job stream mis2(0900 02/19/06) if it is in the STUCK state.

noask] Arguments jobselect succ abend noask See “Selecting jobs in commands” on page 249. Confirms that the job ended successfully. see “Managing internetwork dependencies” on page 504.abend 278 IBM Tivoli Workload Scheduler: Reference Guide .succ To issue an abend confirmation for job number 234. Syntax confirm jobselect . For more information about EXTERNAL jobs. For more information about job confirmation. run the following command: confirm 234.job3.succ no effect no effect SUCCP SUCCP no effect SUCC SUCC no effect SUCC no effect no effect SUCC State after confirm .{succ | abend} [. run the following command: confirm misdly(1200 02/17/06). Specifies not to prompt for confirmation before taking action on each qualifying job.abend no effect no effect ABENP no effect no effect ABEND ABEND no effect no effect no effect no effect ABEND Examples To issue a succ confirmation for job job3 in job stream misdly(1200 02/17/06). Table 44 shows the effect of the confirm command on the various states of jobs: Table 44. You must have confirm access to the job.confirm confirm Confirms the completion of a job that was scheduled with the confirmed keyword. Confirms that the job ended unsuccessfully. Comments Changing the state of a job from ABEND to SUCC does not require that the confirmed keyword be used to schedule the job. State change after confirm command Initial Job State READY HOLD EXEC ABENP SUCCP PEND DONE SUCC ABEND FAIL SCHED any job in the EXTERNAL job stream State after confirm . see “confirmed” on page 141.

run the following command: cons Console is #J675. Level 1.level=1 To stop writing console messages and prompts to standard output and change the message level to 4. the current state of the console is displayed. The level of Tivoli Workload Scheduler messages that are sent to the console. This is the default on fault-tolerant agents. session 675 is the process ID of the user’s shell. Exception messages such as operator prompts and job abends. Level 3. level 2. you can also have them sent to the syslog daemon. run the following command: cons sys.conman 279 . plus job launched messages.l=4 To display the current state of the console.console console Assigns the Tivoli Workload Scheduler console and sets the message level. In UNIX. plus job stream successful messages. Syntax console [sess | sys] [. msglevel Comments If you enter a console command with no options. Specify one of the following levels: 0 1 2 3 4 No messages. Chapter 9.level=msglevel] Arguments sess sys Sends Tivoli Workload Scheduler console messages and prompts to standard output. This is the default on the master domain manager. Tivoli Workload Scheduler control processes write console messages and prompts to standard list files. Level 2. plus job successful messages. By default. Stops sending Tivoli Workload Scheduler console messages and prompts to standard output. Examples To begin writing console messages and prompts to standard output and change the message level to 1. This occurs automatically when you exit conman. run the following command: console sess. Managing objects in the plan . You must have console access to the workstation.

job3" 280 IBM Tivoli Workload Scheduler: Reference Guide . Examples To have conman continue with the rerun command even if the cancel command fails. It instructs conman to continue running commands even if the next command.continue continue Ignores the next command error. results in an error. run the following command: conman "continue&cancel=176&rerun job=sked5(1200 02/17/06). following continue. Syntax continue Comments This command is useful when commands are entered non-interactively.

. needs=2 tapes To delete all external follows dependency from job stream CPUA#TEST(0900 02/19/06)..]] opens[=[workstation#]″filename″[(qualifier)][.. filename. dependency The type of dependency. Managing objects in the plan . run the following command: ddj CPUA#TEST(0900 02/19/06)...] needs[=[num] [workstation#]resource[. Dependencies on all matching files are deleted... ignoring the directory names.job | @] | jobstream_id.. and promptname.]] until[=time [timezone|tz tzname][+n day[s]] [.job. follows Chapter 9...noask] Arguments jobselect See “Selecting jobs in commands” on page 249.]] priority prompt[=″[: | !]text″ | promptname[.. the job reverts to its original scheduled priority...schedid}| job[. job.] [. You must have deldep access to the job. at[=time | lowtime | hightime | lowtime... Syntax ddj jobselect . resource. run the following command: ddj sked9(0900 02/19/06).onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job. you can include only the base file name and conman performs a case-insensitive search for matching files. jstream. You can use wildcard characters in workstation. Specify at least one of the following.JOBA .job3 . When you delete an opens dependency.dependency[.deldep job deldep job Deletes dependencies from a job. Examples To delete a resource dependency from job job3 in job stream sked9(0900 02/19/06). Deleted dependencies no longer remain in effect when running the rerun command.hightime] confirmed deadline[=time[timezone | tz tzname][+n days | mm/dd[/yy]]] every follows=[netagent::][workstation#]{jobstreamname(hhmm [mm/dd[/yy]]) [. Comments If you delete priority.conman 281 .

see ″Managing Jobs″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.deldep job See also For the equivalent Job Scheduling Console task. 282 IBM Tivoli Workload Scheduler: Reference Guide .

]] until[=time [timezone|tz tzname][+n day[s]] [.needs=2 tapes To delete all follows dependencies from job stream sked3(1000 04/19/06). Examples To delete a resource dependency from job stream sked5(0900 02/19/06).. you can include only the base file name. run the following command: dds sked5(0900 02/19/06).. dependency The type of dependency. and conman performs a case-insensitive search for matching files. run the following command: dds sked3(1000 04/19/06). Dependencies on all matching files are deleted.. and promptname.follows Chapter 9.]] priority prompt[=″[: | !]text″ | promptname[.dependency[. at[=time | lowtime | hightime | lowtime. resource. When you delete an opens dependency. Deleted dependencies no longer remain in effect when running the rerun command. the job reverts to its original scheduled priority.. You must have deldep access to the job stream. Specify at least one of the following. ignoring the directory names.] limit needs[=[num] [workstation#]resource[....] [.]] opens[=[workstation#]″filename″[(qualifier)][..hightime] carryforward deadline[=time[timezone | tz tzname][+n days | mm/dd[/yy]]] follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][.conman 283 ..job.schedid}| job[... You can use wildcard characters in workstation. filename.job | @] | jobstream_id.deldep sched deldep sched Deletes dependencies from a job stream.noask] Arguments jstreamselect See “Selecting jobs in commands” on page 249.. Managing objects in the plan .. Syntax dds jstreamselect . jstreamname. jobname.onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job stream. Comments If you delete priority ...

284 IBM Tivoli Workload Scheduler: Reference Guide . see ″Managing Job Streams″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.deldep sched See also For the equivalent Job Scheduling Console task.

This argument is useful when deploying to more than one workstation in a domain. For example. the command has no effect.deployconf | | | | | | | | | | | | | | | | | | | | | | | | workstation deployconf Gets the latest monitoring configuration for the event monitoring engine on the workstation. use the following command: deploy AURORABU!@ The domain is not needed if you do not include wildcard characters in workstation.conman 285 . Wildcard characters are not permitted. the default domain is the one in which conman is running. Specifies the name of the workstation where the monitoring engine runs. and you include wildcard characters in workstation. Permission to start actions on cpu objects is required in the security file to be enabled to run this command. Chapter 9. Managing objects in the plan . Syntax deployconf [domain!]workstation Arguments domain Specifies the name of the destination domain for the operation. Comments If the existing configuration is already up-to-date. If you do not include domain. to deploy the latest monitoring configuration to all the agents in the AURORABU domain . Wildcard characters are permitted.

For information about this device.Property of IBM # ?Restricted Materials of IBM? 286 IBM Tivoli Workload Scheduler: Reference Guide . Wildcard characters are permitted. dashes (-). you must have display access to the job or job stream. For job files and job stream definitions.offline] ds jstreamselect [valid {at date | in date date} [. This keyword applies only to path and filename of the script file of jobs defined with the scriptname option. backslashes (\). see “Offline output” on page 244. This means that the validity interval of those job stream instances must contain the time frame specified in valid argument. you must have read access to the file.CREATEPOSTREPORTS This is a sample output of this command: M235062_99#FINAL(0559 03/06/06). The name must be enclosed in quotes (″) if it contains characters other than the following: alphanumeric characters.display display Displays a job file or a job stream definition. The job file must be accessible from your login workstation. See “Selecting job streams in commands” on page 257. The format used for date depends on the value assigned to the date format variable specified in the localopts file. If not specified the selected instance is the one valid today. Use this option is you want to show only the content of the job script file. See “Selecting jobs in commands” on page 249. run the following command: dj FINAL(0559 03/06/06).offline] dj jobselect [. The file must be accessible from your login workstation. If you specify a file by name. slashes (/).CREATEPOSTREPORTS /home/tws83/CreatePostReports #!/bin/sh #################################################################### # Licensed Materials . The job stream whose definition is displayed. Specifies the day or the interval of days during which the job stream instances to be displayed must be active. and underscores (_). Syntax df filename [. jobselect jstreamselect valid offline Examples To display the file c:\maestro\jclfiles\arjob3.offline] Arguments filename Specifies the name of the file. usually a job script file. run the following command: df c:\apps\maestro\jclfiles\arjob3 To display the script file for job createpostreports in job stream final offline. The job whose job file is displayed. Sends the output of the command to the conman output device.

duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp.. ################################################################### #@(#) $Id: CreatePostReports.@ FOLLOWS M235062_99#SCHED_FIRST.v 1.0 ## ## CreatePostReports message catalog definitions.conman 287 . ## ## ## message set id ## MAE_CREATEPOSTREPORTS_SET=226 MAE_COPYRIGHT_SET=234 ## .. Managing objects in the plan . .Use.sh. # US Government Users Restricted Rights ... # # End # To display the job stream definition for job stream mod.JOB_FTA PRIORITY 66 : M235062_99#JOBMDM SCRIPTNAME "/usr/acct/scripts/gl1" STREAMLOGON root DESCRIPTION "general ledger job1" TASKTYPE UNIX RECOVERY STOP PRIORITY 30 NEEDS 16 M235062_99#JOBSLOTS PROMPT PRMT3 Chapter 9. 2006 All Rights Reserved..---------------.JOB_FTA PRIORITY 66 : M235062_99#JOBMDM SCRIPTNAME "/usr/acct/scripts/gl1" STREAMLOGON root DESCRIPTION "general ledger job1" TASKTYPE UNIX RECOVERY STOP PRIORITY 30 NEEDS 16 M235062_99#JOBSLOTS PROMPT PRMT3 B236153_00#JOB_FTA FOLLOWS M235062_99#SCHED_FIRST1.. 1998.INTERVAL=1" ( AT 1111 ) CARRYFORWARD FOLLOWS M235062_99#SCHED_FIRST1..---------. .---------.@ FOLLOWS M235062_99#SCHED_FIRST.. run the following command: ds mod This is a sample output of this command: Job Stream Name Workstation Valid From Updated On Locked By ---------------.---------------MOD M235062_99 06/30/2007 03/04/2006 SCHEDULE M235062_99#MOD VALIDFROM 06/30/2007 ON RUNCYCLE SCHED1_PREDSIMPLE VALIDFROM 07/18/2007 "FREQ=DAILY.display # 5698-WSH # (C) Copyright IBM Corp.

display B236153_00#JOB_FTA DOCOMMAND "echo pippo" STREAMLOGON root DESCRIPTION "general ledger job1" TASKTYPE UNIX RECOVERY STOP FOLLOWS JOBMDM END See also For the equivalent Job Scheduling Console task. 288 IBM Tivoli Workload Scheduler: Reference Guide . see ″Managing Jobs″ and ″Managing Job Streams″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.

conman 289 .exit exit Exits the conman command line program. Managing objects in the plan . Examples To exit the conman command-line program. run the following command: exit or e Chapter 9. Syntax e Comments When you are in help mode in UNIX. this command returns conman to command-input mode.

go. regardless of the priorities of their job streams.go To change the job fence to zero on the workstation on which you are running conman. run the following command: f . run the following command: f . When you first start Tivoli Workload Scheduler following installation. Jobs are not launched on the workstation if their priorities are less than or equal to the job fence. Comments The job fence prevents low priority jobs from being launched.fence fence Changes the job fence on a workstation. or system. the job fence is set to zero. Entering system sets the job fence to zero.noask] Arguments workstation pri noask Specifies the workstation name. it is carried forward during pre-production processing to the next day’s production plan. while allowing high priority jobs in low priority job streams to be launched. The default is your login workstation. hi. Specifies not to prompt for confirmation before taking action on each qualifying workstation. When you change the job fence. therefore.20 To change the job fence on the workstation on which you are running conman. Specifies the priority level. Syntax fence workstation .40 To prevent all jobs from being launched by the Tivoli Workload Scheduler on workstation tx3. You can enter 0 through 99. see ″Viewing and Modifying Workstation Properties″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. run the following command: f tx3. use the status command. run the following command: fence site4. Examples To change the job fence on workstation site4. It is possible.system See also For the equivalent Job Scheduling Console task. 290 IBM Tivoli Workload Scheduler: Reference Guide . To display the current setting of the job fence. to hold back low priority jobs in high priority job streams.pri [. You must have fence access to the workstation.

run the following command: h altpri Chapter 9. schedstates Lists information about job stream states.conman 291 . and help for all versions of the command is displayed. For commands consisting of two words. run the following command: help fence To display information about the altpri job and altpri sched commands. Syntax help command Arguments command Specifies the name of a conman or system command. and display sched commands. display job. Managing objects in the plan . enter the first word. jobselect Lists information about selecting jobs for commands. abbreviations and short forms are not supported. For conman commands. entering help display displays information about the display file. Examples To display a list of all conman commands.help help Displays help information about commands. Not available in Windows. jobstates Lists information about job states. schedselect Lists information about selecting job streams for commands. You can also enter the following keywords: commands Lists all conman commands. run the following command: help commands To display information about the fence command. For example. enter the full command name.

In UNIX. Syntax kill jobselect [. Any jobs or job streams that are dependent on a killed job are not released.report To kill job number 456. it is run by a Tivoli Workload Scheduler production process. Comments The kill operation is not performed by conman.noask] Arguments jobselect noask See “Selecting jobs in commands” on page 249. You must have kill access to the job.kill kill Stops a job that is running. Specifies not to prompt for confirmation before taking action on each qualifying job. so there might be a short delay. Killed jobs end in the ABEND state. run the following command: k 456 292 IBM Tivoli Workload Scheduler: Reference Guide . Examples To kill the job report in job stream apwkly(0600 03/05/06) on workstation site3. Killed jobs can be rerun. this is accomplished with a UNIX kill command. run the following command: kill site3#apwkly(0600 03/05/06).

limit cpu limit cpu Changes the limit of jobs that can run simultaneously on a workstation. Wildcard characters are permitted. noask Specifies not to prompt for confirmation before taking action on each qualifying workstation.12 To change the job limit on workstation rx12. Syntax lc workstation .10 See also For the equivalent Job Scheduling Console task. Lowering the job limit can prevent this from occurring. Note: If you set lc to zero. are launched on the workstation. run the following command: lc rx12. run the following command: lc @!@. When you first start Tivoli Workload Scheduler following installation. see ″Viewing and Modifying Workstation Properties″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. If this limit is reached.noask] Arguments workstation limit Specifies the name of the workstation. Chapter 9. When you change the limit.limit [. the system responds with a message indicating that system resources are not available. no jobs. Comments To display the current job limit on your login workstation. run the following command: lc . Tivoli Workload Scheduler attempts to launch as many jobs as possible within the job limit. Managing objects in the plan . You must have limit access to the workstation. it enters the fail state. The default is your login workstation. When a job cannot be launched for this reason. There is a practical limit to the number of processes that can be started on a workstation. use the status command. Specifies the job limit. and must be increased before any jobs are launched.6 To set to 10 the job limit on all the workstations belonging to the domain and to child domains. You can enter 0 through 1024. it is carried forward during pre-production processing to the next day’s production plan. other than hi and go priority jobs contained in a job stream in READY state.conman 293 . Entering system sets the job limit to zero. Examples To change the job limit on the workstation on which you are running conman. the workstation job limit is set to zero.

are launched from the job stream. For additional information on setting a limit in a job stream definition. You must have limit access to the job stream.limit sched limit sched Changes the limit set in the definition of a job stream. even those with priority set to GO. refer to “limit” on page 158. You can enter 0 through 1024.6 See also For the equivalent Job Scheduling Console task. run the following command: ls sales@. see ″Managing Job Streams″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. Examples To change the job limit on all job streams that include sales in their name.noask] Arguments jstreamselect limit See “Selecting job streams in commands” on page 257. 294 IBM Tivoli Workload Scheduler: Reference Guide .limit [. Note: If you specify a limit of 0. run the following command: ls CPUA#apwkly. Syntax ls jstreamselect . Specifies the job limit. noask Specifies not to prompt for confirmation before taking action on each qualifying job stream.4 To change the job limit on job stream CPUA#Job1. no further jobs.

Syntax lk [domain!]workstation [. Wildcard characters are permitted. use the following command: lk stlouis!@ The domain is not needed if you do not include wildcard characters in workstation. For information about autolink see “Workstation definition” on page 108. For example. fault-tolerant and standard agents are linked to their domain managers. If autolink is set to off. The user cannot link workstations in peer domains. Managing objects in the plan . This argument is useful when linking more than one workstation in a domain. the default domain is the one in which conman is running. If you do not include domain. Chapter 9. Assuming that a user has link access to the workstations being linked. Wildcard characters are permitted. Examples Figure 10 on page 296 and Table 45 on page 296 show the links opened by link commands run by users in various locations in the network. v A user running conman on an agent can link any workstation in its local domain provided that the workstation is a domain manager or host.conman 295 . its link is opened automatically each time Tivoli Workload Scheduler is started. Specifies not to prompt for confirmation before taking action on each qualifying workstation. workstation noask Specifies the name of the workstation to be linked. In a Tivoli Workload Scheduler network. Comments If the autolink option is set to on in a workstation definition. it is not necessary that the intervening links be open. you must use link and unlink commands to control linking. v A user running conman on a domain manager other than the master can link any workstation in its own domain and subordinate domains. Extended agents are not linked. and domain managers are linked to their parent domain managers. A peer agent in the local domain cannot be linked. v To link a subordinate domain while running conman in a higher domain.noask] Arguments domain Specifies the name of the domain in which links are opened. they communicate through a host. to link all the agents in domain stlouis. You must have link access to the target workstation. and you include wildcard characters in workstation. the following rules apply: v A user running conman on the master domain manager can link any workstation in the network.link link Opens communication links between workstations.

link A11 DM1 A12 Domain1 User1 User3 DM2 A21 A22 Domain2 User2 A31 DM3 A32 Domain3 DM4 Domain4 A41 A42 Figure 10. Table 45. Links Opened by User3 DM2-A21 link @ DM1-A11 DM1-A12 DM1-DM2 DM1-DM3 DM3-A31 DM3-A32 DM4-A41 DM4-A42 DM1-DM2 DM4-A42 DM3-A31 DM2-A21 link DOMAIN3!@ link DOMAIN4!@ link DM2 link A42 link A31 Not allowed. DM2-A21 Not allowed. DM4-A41 DM4-A42 Not applicable. Network links DMn are domain managers and Ann are agents. Not allowed. DM4-A42 Not allowed. 296 IBM Tivoli Workload Scheduler: Reference Guide . Not allowed. Links Opened by User2 DM1-DM2 DM2-A21 DM2-A22 DM2-DM4 DM4-A41 DM4-A42 DM1-DM2 DM2-A21 DM2-A22 DM2-DM4 Not allowed. Opened links Command link @!@ Links Opened by User1 All links are opened.

Syntax listsym [trial | forecast] [. For information about this device. Examples To list the production plan files. run the following command: listsym trial Chapter 9. Results Schedule Date The date used to select the job streams to run. see “Offline output” on page 244. Log Num The log number indicating the chronological order of log files. Start Time The time batchman began running the Symphony file.conman 297 . This number can be used in a setsym command to switch to a specific log file. run the following command: listsym this is a sample output for the command: Job Stream Date 03/05/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 Actual Date 03/05/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 Start Time 21:06 15:59 15:51 14:31 14:26 14:24 14:19 14:17 14:17 Log Date 03/05/06 03/05/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 03/04/06 Run Num 42 41 40 39 38 37 36 35 34 Size 534 463 362 460 436 436 436 436 364 Log Num 1 2 3 4 5 6 7 8 9 Filename M200603052111 M200603052106 M200603041559 M200603041551 M200603041431 M200603041426 M200603041424 M200603041419 M200603041417 Exp Exp Exp Exp Exp Exp Exp Exp Exp To list files containing trial plans. Lists forecast plans. Sends the output of the command to the conman output device. Actual Date The date batchman began running the Symphony file. Managing objects in the plan . This is used internally for Tivoli Workload Scheduler network synchronization. Size The number of records contained in the Symphony file. Log Date The date the plan (Symphony file) was logged by the stageman command.listsym listsym Lists the production plan (Symphony files) already processed.offline] Arguments trial forecast offline Lists trial plans. Run Num The run number assigned to the plan (Symphony file). Filename The name of the log file assigned by the stageman command.

listsym this is a sample output for the command: Job Stream Date 03/03/06 03/03/06 03/03/06 Actual Start Date Time Log Date 03/03/06 03/03/06 03/03/06 Run Num 0 0 0 Size 126 1850 1838 Log Num Filename 1 Tpippo 2 Tangelo2 3 Tangelo1 Exp Exp Exp To list the files containing the forecast plans. run the following command: listsym forecast This is a sample output for the command: Job Stream Date 03/03/06 Actual Start Date Time Log Date 03/03/06 Run Num 0 Size 62 Log Num Filename 1 Fpluto Exp 298 IBM Tivoli Workload Scheduler: Reference Guide .

Examples To display pending prompts issued on the workstation on which you are running conman. run the following command: recall or: rc To display pending prompts on workstation site3. run the following command: rc @. For information about this device. Syntax rc [workstation] [.offline] Arguments workstation Specifies the name of the workstation on which the prompt was issued. For unnamed prompts. run the following command: rc site3 To display pending prompts on all workstations and have the output sent to conman’s offline device. see “Offline output” on page 244. Managing objects in the plan . offline Results State The state of the prompt.offline Chapter 9. If you do not specify a workstation. You must have display access to the prompts.recall recall Displays prompts that are waiting for a response. only prompts for the login workstation and global prompts are displayed. The state of pending prompts is always ASKED. and the message text. the name of the prompt. the message number. the name of the job or job stream. Sends the output of the command to the conman output device. Message or Prompt For named prompts. the message number. and the message text.conman 299 .

and enter the following directives. >rtext Replaces characters at the end of the line with text.redo redo Edits and reruns the previous command. and inserts abc in its place. Inserts text before the character above the i. Inserts abc before the character above the i. Appends abc to the end of the line. conman displays the previous command. skips one character. so that it can be edited and rerun. Syntax redo Context When you run the redo command. Replace is implied if no other directive is entered. Replaces the three characters. Examples To insert a character. Directives d[dir] itext rtext Deletes the character above the d. >abc >ddabc Deletes the last two characters in the line. Replaces the three characters above abc with abc. >text >d[dir | text] Deletes characters at the end of the line. and inserts abc in their place. This can be followed by another directive or text. run the following command: redo setsm 4 iy setsym 4 To replace a character. Directive Examples ddd iabc rabc abc d diabc Deletes the character above the first d. >rabc Replaces the last three characters in the line with abc. deletes the character above the second d. This can be followed by other directives. Use the spacebar to move the cursor under the character to be modified. beginning with the character above the r. Deletes the three characters above the ds. Replaces one or more characters with text. with abc. starting with the one above the r. run the following command: 300 IBM Tivoli Workload Scheduler: Reference Guide . Appends text to the end of the line.

Managing objects in the plan .redo redo setsym 4 5 setsym 5 Chapter 9.conman 301 .

and conman performs a case-insensitive search for matching files. You must have release access to the job.. run the following command: 302 IBM Tivoli Workload Scheduler: Reference Guide .. Examples To release job job3 in job stream ap(1000 03/05/06) from all of its dependencies.job | @] | jobstream_id.job.schedid}| job[. filename. even though they might not be available. the job reverts to its original scheduled priority. You can use wildcard characters in workstation. and promptname.... jobname. at[=time | lowtime | hightime | lowtime.]] priority prompt[=″[: | !]text″ | promptname[. the released job is given the required number of units of the resource. See “Selecting jobs in commands” on page 249. ignoring the directory names.. resource. For needs dependencies... jstreamname.release job release job Releases jobs from dependencies.. Syntax rj jobselect [.onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job.] needs[=[num] [workstation#]resource[. You can specify one of the following.]] [.]] opens[=[workstation#]″filename″[(qualifier)][. Released dependencies remain in effect when running the rerun command.. you can include only the base file name..noask] Arguments jobselect Specifies the job or jobs to be released. dependency The type of dependency..dependency[.]] until[=time [timezone|tz tzname][+n day[s]] [.. Dependencies on all matching files are released.. Comments When you release an opens dependency. This can cause the available units in a showresources to display a negative number.hightime] confirmed deadline[=time[timezone | tz tzname][+n days | mm/dd[/yy]]] every follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][. When you release a job from a priority dependency..

run the following command: rj site4#@.release job rj ap(1000 03/05/06).prompt=glprmt See also For the equivalent Job Scheduling Console task.job3 To release all jobs on workstation site4 from their dependencies on a prompt named glprmt.conman 303 . Chapter 9. Managing objects in the plan . see ″Releasing a Job Instance from Dependencies″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.@.

..]] priority prompt[=″[: | !]text″ | promptname[. you can include only the base file name. 304 IBM Tivoli Workload Scheduler: Reference Guide . the job stream reverts to its original priority. filename. Specify one of the following.noask] Arguments jstreamselect See “Selecting job streams in commands” on page 257...onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job stream. jstream... see “Conman commands processing” on page 249.. the command might have succeeded even though it is again forwarded to batchman.]] until[=time [timezone|tz tzname][+n day[s]] [. at[=time | lowtime | hightime | lowtime. Dependencies on all matching files are released.job.]] opens[=[workstation#]″filename″[(qualifier)][. This can cause the available units in a showresources to display a negative number. dependency The type of dependency.schedid}| job[. job. and conman performs a case-insensitive search for matching files. Comments When deleting an opens dependency... when you have submitted a deldep command..release sched release sched Releases job streams from dependencies. For more information.. even though they might not be available. and promptname..hightime] carryforward deadline[=time[timezone | tz tzname][+n days | mm/dd[/yy]]] follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][.job | @] | jobstream_id. When you release a job stream from a priority dependency..] limit needs[=[num] [workstation#]resource[. For needs dependencies. Syntax rs jstreamselect [. resource.]] [. You must have release access to the job stream.dependency[.. In certain circumstances.. You can use wildcard characters in workstation. ignoring the directory names. the released job stream is given the required number of units of the resource.

run the following command: rs site3#@.release sched Examples To release job stream instance with jobstream_id 0AAAAAAAAAAAABSE from all of its dependencies.opens To release all job streams on workstation site3 from their dependencies on job stream main#sked23. see ″Releasing a Job Stream Instance from Dependencies″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. Chapter 9.follows=main#sked23 See also For the equivalent Job Scheduling Console task. Managing objects in the plan .conman 305 . run the following command: rs sked5(1105 03/07/06). run the following command: rs 0AAAAAAAAAAAABSE. schedid To release job stream sked5(1105 03/07/06) from all of its opens dependencies.

dependencies on the prompt are satisfied. reply noask Comments If the reply is Y. Wildcard characters are permitted. either Y for yes or N for no. Prompts can be replied to before they are issued.reply [. Specifies the message number of an unnamed prompt. Examples To reply Y to the global prompt arpmt. You can use the showprompts command to display all prompts.noask] Arguments promptname workstation msgnum Specifies the name of a global prompt. Specifies the reply. run the following command: rep site4#24.reply reply Replies to a job or job stream prompt. To reply to an unnamed prompt. run the following command: reply arprmt. the dependencies are not satisfied and the prompt is not reissued. You must have reply access to the named or global prompt.n 306 IBM Tivoli Workload Scheduler: Reference Guide . Specifies the name of the workstation on which an unnamed prompt was issued.y To reply N to message number 24 on workstation site4. you must have reply access to prompts. You can display message numbers with the recall and showprompts commands. If the reply is N. whether or not they have been issued. and reply access to the associated job or job stream. Specifies not to prompt for confirmation before taking action on each qualifying prompt. Syntax reply { promptname | [workstation#]msgnum} .

noask] Arguments jobselect Specifies the name of one or more jobs. See Chapter 12. Syntax rr jobselect [.noask] rr jobselect [. Wildcard characters are permitted. job Specifies the name of the from job definition The following types of job names are not permitted: v The names of jobs submitted using the submit file and submit docommand commands. +n days The next occurrence of hhmm in n number of days.conman 307 . v The alias names of jobs submitted using the submit job command. pri=pri Specifies the priority to be assigned to the rerun job.rerun rerun Reruns a job. Chapter 9. the job is given the same priority as the original job. “Managing time zones. To use the from argument. You must have rerun access to the job. If you do not specify a priority.” on page 461 for valid names. expressed as mm/dd[/yy]. Managing objects in the plan . date The next occurrence of hhmm on date. expressed as follows: hhmm [timezone|tz tzname] [+n days | date] where: hhmm The hour and minute.step=step] [. The default is the workstation on which conman is running.at=time] [. wkstat# Specifies the name of the workstation on which the from job runs. timezone|tz tzname The name of the time zone of the job. you must have access to the database from the computer on which you are running conman at=time Specifies the rerun job’s start time.pri=pri]] [. from=[wkstat#]job Specifies the name of a job defined in the database whose job file or command will be run in place of the job specified by jobselect.from=[wkstat#]job[ .

In conman displays. 308 IBM Tivoli Workload Scheduler: Reference Guide . rerun jobs are displayed with the notation >>rerun as. Note: You can issue rerun for jobs in the EXTERNAL job stream that are in the ERROR state. A rerun job is placed in the same job stream as the original job. Within a job script. the rerun job is scheduled to run at the same rate as the original job.. . such as altpri. in the following UNIX script..rerun step=step Specifies that the job is rerun using this name in place of the original job name.from is used. If the option is set to N. For more information.. rerun jobs retain the original job names. Jobs in the EXTERNAL job stream represent jobs and job streams that have been specified as internetwork dependencies. For example. STEP=JSTEP2 fi if [$STEP = JSTEP2] then . refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide. jobs rerun with the . FAIL. If the option is set to Y. fi .step option. When a job is rerun with the .. If you rerun a repetitive (every) job. For information about jobinfo.. see “jobinfo” on page 390. Comments You can rerun jobs that are in the SUCC. MPATH=`maestro` STEP=`$MPATH/bin/jobinfo job_name` if [$STEP = JOB3] then .. STEP=JSTEP1 fi if [$STEP = JSTEP1] then .. The job state is initially set to extrn immediately after a rerun is run.. In conman displays. and conman begins checking the state. When . the job runs with step in place of its original name. See “Usage Notes” for more information.. or ABEND state.. the name of the rerun job depends on the value of the Global Option retain rerun job names. To refer to a rerun job in another command. you must use the original job name. noask Specifies not to prompt for confirmation before taking action on each qualifying job. you can use the jobinfo command to return the job name and to run the script differently for each iteration. rerun jobs are given the from job names. and inherits the original job’s dependencies. the jobinfo command is used to set a variable named STEP to the name that was used to run the job.step option are displayed with the notation >>rerun step. The STEP variable is then used to determine how the script is run.

Managing objects in the plan .conman 309 . run the following command: rr main#sked1.rerun Examples To rerun job job4 in job stream sked1 on workstation main.step=jstep2 See also For the equivalent Job Scheduling Console task.at=1830. and its priority is set to 25. see ″Rerunning a Job Instance″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.job5.job4 To rerun job job5 in job stream sked2 using the job definition for job jobx where the job’s at time is set to 6:30 p. Chapter 9.from=jobx.pri=25 To rerun job job3 in job stream sked4 using the job name jstep2. run the following command: rr sked2.job3. run the following command: rr sked4.m.

Specifies the total number of resource units.resource resource Changes the number of total units of a resource. Valid values are 0 through 1024. You must have resource access to the resource. resource num noask Examples To change the number of units of resource tapes to 5. 310 IBM Tivoli Workload Scheduler: Reference Guide .5 To change the number of units of resource jobslots on workstation site2 to 23. run the following command: resource tapes. see ″Managing Resources in the Database″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. Specifies the name of the resource.num [. run the following command: res site2#jobslots.23 See also For the equivalent Job Scheduling Console task. Specifies not to prompt for confirmation before taking action on each qualifying resource.noask] Arguments workstation Specifies the name of the workstation on which the resource is defined. The default is the workstation on which conman is running. Syntax resource [workstation#] resource.

Managing objects in the plan . Subsequent display commands show the contents of the archived production plan. Examples To select production plan archive file 5. Lists forecast plans. If you do not specify a log file number. Syntax setsym [trial | forecast] [filenum] Arguments trial forecast filenum Lists trial plans. run the following command: set Chapter 9. the current production plan (Symphony). run the following command: setsym 5 To select the current production plan (Symphony file). You cannot modify the information in a production plan archive file.conman 311 .setsym setsym Selects a production plan archive file. Specifies the number of the production plan archive file. the pointer returns to zero. Use the listsym command to list archive file numbers.

When no domain and no workstation are specified. 312 IBM Tivoli Workload Scheduler: Reference Guide . the output can be the following: v The following command displays all the workstations that are in the domain of the workstation where the command was run. For information about this device. Specifies the name of a workstation. The default is the workstation where the command is run. The default is the domain in which the command is run. without the connected domain managers.getmon] Arguments domain workstation Specifies the name of a domain. Whether batchman is up or down is confirmed on screen by the Batchman LIVES or Batchman down message when you issue the conman start command. Sends the output of the command to the conman output device.link] [. Syntax sc [[domain!]workstation] [. The header of the output contains also the time stamp of when the rule configuration package was last generated. Displays information in the link format. | | | | The displayed information is updated only as long as Tivoli Workload Scheduler (batchman) is running on the workstations. conman "sc" v The following command displays all the workstations that are in the domain of the workstation where the command was run. Returns the list of event rules defined for the monitor running on the specified workstation in the following format: <rule_name>::<eventProvider>#<eventType>:<scope> | | | | | | | | getmon The rule scope is automatically generated information about rule attributes.offline] | sc [[domain!]workstation] [. conman "sc @" info link offline Displays information in the info format. etc. plus all the connected domain managers if the workstation is a domain manager. You must have list access to the object being shown if the enListSecChk option was set to yes on the master domain manager when the production plan was created or extended. see “Offline output” on page 244. a job or file name.info|.showcpus showcpus Displays information about workstations and links. such as the workstations where it is deployed..

conman 313 . I The jobman program has completed startup initialization. T This flag is displayed if the fault-tolerant agent is directly linked to the domain manager from where you run the command. F The workstation is fully linked through primary and all secondary connections. where: L The primary link is open (linked) to its domain/upper manager. DATE TIME The date and time Tivoli Workload Scheduler started running the current production plan (Symphony file). STATE | | | | | | | | | | | | | | | | | | | | | Displays the following information: v The state of the workstation’s links. When the getmon parameter is used. standard. Managing objects in the plan . Standard format: CPUID The name of the workstation to which this information applies. RUN NODE The node type and workstation type. the output of the command is produced in three formats. For information on how to use the optman command line. Up to five characters are displayed as follows: [L] [T|H|X] [I] [J] [W|H|X] [F] The run number of the Symphony file . the list of rules is provided as separate output. and link.showcpus Results | | | When the getmon parameter is not used. W The writer process is active on the workstation. H The workstation is linked through its host. Chapter 9. refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide. info. This flag appears only if the enSwfaultTol global option is set to YES using the optman command line on the master domain manager and it indicates that the workstation is directly linked to its domain manager and to all its full backup domain managers. J The jobman program is running. FENCE The Tivoli Workload Scheduler job fence. X The workstation is linked as an extended agent (x-agent). Node types are as follows: v UNIX v WNT v OTHER Workstation types are as follows: v MASTER v MANAGER v FTA v S-AGENT v X-AGENT LIMIT The Tivoli Workload Scheduler job limit.

TIMEZONE The time zone of the workstation. It is the same as the value of the TZ environment variable. no information is listed. A one-character flag is displayed. METHOD The name of the access method specified in the workstation definition. For extended agents. D The workstation is using an up-to-date package monitoring configuration. E The event processing server is installed and running on the workstation. the state of the extended agent is LXI JX If the workstation running conman is not the extended agent’s host. HOST The name of the workstation acting as the host to a standard agent or 314 IBM Tivoli Workload Scheduler: Reference Guide . if the application server is installed: [A|R] where: A The WebSphere Application Server was started. v The state of the WebSphere Application Server. Info format: CPUID The name of the workstation to which this information applies. The flag is blank if the application server is down or if it was not installed. the state of the extended agent is LHI JH v The state of the monitoring agent. For an extended agent. R The WebSphere Application Server is restarting.showcpus | | | | | | | | | | | | | | | | | | | | | | | | | Note: If the workstation running conman is the extended agent’s host. e The event processing server is installed on the workstation but is not running.. VERSION The version of the Tivoli Workload Scheduler jobman program. INFO The operating system version and hardware model. DOMAIN The name of the domain in which the workstation is a member. For extended agents only. Up to three characters are displayed as follows: [M] [E|e] [D] where: M The monman process is running. Link format: CPUID The name of the workstation to which this information applies. this is the time zone of its host.

Up to five characters are displayed as follows: [A] [B] [F] [s] [T] A B F s T ADDR Autolink is turned on in the workstation definition. This flag is used only in end-to-end environment and it indicates if the deactivate job launching flag is disabled. this is the same as CPUID.info a sample output for this command is: CPUID MASTER FTA1 FTA2 sc @!@. run the following command: a sample output is the following: CPUID MASTER FTA1 FTA2 showcpus HOST MASTER FTA1 FTA2 FLAGS AF T AF T AF T ADDR 51099 51000 51000 NODE 9.4. this is the name of the host workstation.9-e. NODE The node name of the workstation.showcpus extended agent. you receive the following output: | | | | | | | | | | | CPUID MASTER FTA1 FTA2 FTA3 FTA4 FTA5 SA1 XA_FTA4 FTA6 FTA7 RUN NODE LIMIT FENCE DATE TIME STATE METHOD 360 *WNT MASTER 10 0 06/04/2007 1348 I J E 360 WNT FTA 10 0 06/04/2007 1348 FTI JW M U A 360 WNT FTA 10 0 06/04/2007 1348 FTI JW M U A 360 WNT MANAGER 10 0 06/04/2007 1348 LTI JW M U A 360 WNT FTA 10 0 06/04/2007 1348 F I J M U A 360 WNT FTA 10 0 06/04/2007 1348 I J M U A 360 WNT S-AGENT 10 0 06/04/2007 1348 F I J M U A 360 OTHR X-AGENT 10 0 06/04/2007 1348 L I J M U A 360 WNT MANAGER 10 0 06/04/2007 1348 F I J M U A 360 WNT FTA 10 0 06/04/2007 1349 F I J M U A DOMAIN MASTERDM MASTERDM MASTERDM DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN2 DOMAIN2 Chapter 9.4 8.132. FLAGS The state of the workstation’s links.42 3.11.24 #1 Tue May HP-UX B. For extended agents. Managing objects in the plan .conman 315 . The ID of mailman server for the workstation.4 8.239. The TCP/IP port number for the workstation. To display information about the workstation on which you are running conman in the info format. For standard agent workstations.65 CPU235019 9.6. Full Status mode is turned on in the workstation definition. For domain managers and fault-tolerant agents.11 U 9000/785 2. this is the name of the domain manager. To display link information for all workstations.5-7.link VERSION 8. To display information about the workstation. Examples 1.132. run the following command: If you run this command in an environment when the primary connection of the workstation with its domain or upper manager is not active.235. The link is defined as TCP/IP.191-s390 #1 SM Linux 2. run the following command: showcpus .4 TIME ZONE US/Pacific INFO Linux 2.

Job1 See also For the equivalent Job Scheduling Console task. you receive the following output: CPUID MASTER FTA1 FTA2 FTA3 FTA4 FTA5 SA1 XA_FTA4 FTA6 FTA7 RUN NODE LIMIT FENCE DATE TIME STATE METHOD DOMAIN 360 *WNT MASTER 10 0 06/04/2007 1348 I J E MASTERDM 360 WNT FTA 10 0 06/04/2007 1348 FTI JW M U A MASTERDM 360 WNT FTA 10 0 06/04/2007 1348 FTI JW M U A MASTERDM 360 WNT MANAGER 10 0 06/04/2007 1348 FTI JW M U A DOMAIN1 360 WNT FTA 10 0 06/04/2007 1348 F I J M U A DOMAIN1 360 WNT FTA 10 0 06/04/2007 1348 F I M U A DOMAIN1 360 WNT S-AGENT 10 0 06/04/2007 1348 F I J M U A DOMAIN1 360 OTHR X-AGENT 10 0 06/04/2007 1348 L I J M U A DOMAIN1 360 WNT MANAGER 10 0 06/04/2007 1348 F I J M U A DOMAIN2 360 WNT FTA 10 0 06/04/2007 1349 F I J M U A DOMAIN2 | | | | | | | | | | | | | | | | | | | | | | | | 4.CPU3. To get a list of active rule monitors on the workstation named CPU1. run this command: sc CPU1 getmon You get the following output: Monitoring configuration for CPU1: ******************************************* *** Package Date : 04/22/2007 12:00 GMT *** ******************************************* Rule1::FileMonitor#FileCreated:Workstation=CPU1. see ″Working with Object Lists″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.File=”\staging\orders” Rule3::TWSObjectsMonitor#JobSubmit:JobKey=CPU1#JS1. 316 IBM Tivoli Workload Scheduler: Reference Guide .CPU2. you receive the following output: CPUID MASTER FTA1 FTA2 FTA3 FTA4 FTA5 SA1 XA_FTA4 FTA6 FTA7 RUN NODE LIMIT FENCE DATE TIME STATE METHOD DOMAIN 360 *WNT MASTER 10 0 06/04/2007 1348 I J E MASTERDM 360 WNT FTA 10 0 06/04/2007 1348 FTI JW M U A MASTERDM 360 WNT FTA 10 0 06/04/2007 1348 FTI JW M U A MASTERDM 360 WNT MANAGER 10 0 06/04/2007 1348 FTI JW M U A DOMAIN1 360 WNT FTA 10 0 06/04/2007 1348 F I J M U A DOMAIN1 360 WNT FTA 10 0 06/04/2007 1348 L I M U A DOMAIN1 360 WNT S-AGENT 10 0 06/04/2007 1348 F I J M U A DOMAIN1 360 OTHR X-AGENT 10 0 06/04/2007 1348 L I J M U A DOMAIN1 360 WNT MANAGER 10 0 06/04/2007 1348 F I J M U A DOMAIN2 360 WNT FTA 10 0 06/04/2007 1349 F I J M U A DOMAIN2 | | | | | | | | | | | | If you run this command in an environment when the primary connection of the workstation with its domain or upper manager and all secondary connections are active.File=”\tmp\filename” Rule2::FileMonitor#ModificationCompleted:Workstation=CPU1.Job1 Rule5::TWSObjectsMonitor#JobLate:JobKey=CPU1#JS1.showcpus | If you run this command in an environment when the primary connection of the workstation with its domain or upper manager is active and at least one secondary connection is not active.

Displays information in the info format. Results The output of the command is produced in two formats. MEMBER-CPUS The names of the workstations in the domain. Standard format: DOMAIN The name of the domain to which this information applies.offline] Arguments domain info offline Specifies the name of the domain. Wildcard characters are permitted. or X-AGENT. see “Offline output” on page 244.showdomain showdomain Displays domain information. The default is the domain in which conman is running.conman 317 . | | | | The displayed information is updated only as long as Tivoli Workload Scheduler (batchman) is running.info] [. PARENT The name of the parent domain. and info. Examples To display information about the domain masterdm. S-AGENT. CPU-TYPE The type of each workstation: MASTER. Syntax showdomain [domain] [. MANAGER. fault-tolerant agent. MANAGER The name of the domain manager. Info format: DOMAIN The name of the domain to which this information applies. Whether batchman is up or down is confirmed on screen by the Batchman LIVES or Batchman down message when you issue the conman start command. standard. run the following command: showdomain masterdm A sample output is the following: Chapter 9. Managing objects in the plan . For information about this device. Sends the output of the command to the conman output device. You must have list access to the object being shown if the enListSecChk option was set to yes on the master domain manager when the production plan was created or extended.

see ″Displaying and Modifying Domain Properties″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.info a sample output is the following: DOMAIN MASTERDM DOM1 DOM2 MEMBER-CPUs *MASTER FTA1 FTA2 CPU-Type MASTER MANAGER MANAGER See also For the equivalent Job Scheduling Console task. 318 IBM Tivoli Workload Scheduler: Reference Guide . run the following command: showdomain @.showdomain DOMAIN *MASTERDM MANAGER *MASTER PARENT To display the member workstations in all domains in the info format.

Syntax sf [[workstation#]file] [. | | | | The displayed information is updated only as long as Tivoli Workload Scheduler (batchman) is running. The default is to display all file dependencies. Specifies the name of the file.offline] Arguments workstation Specifies the name of the workstation on which the file exists. The arguments keys. slashes (/). The default is the workstation on which conman is running.]] [. File is unavailable.]] [..keys] [.. Availability is being checked. Specifies the state of the file dependencies to be displayed. The name must be enclosed in quotes (″) if it contains characters other than the following: alphanumerics. The states are as follows: yes no ? File exists and is available. Wildcard characters are permitted.deps[.. and deps. see “Offline output” on page 244.state[. and underscores (_). and logon modify the deps display. Sends the output of the command to the conman output device. info.keys | info | logon]] [. Chapter 9. Results The output of the command is produced in three formats: standard. Use keys. For information about this device. keys.. or does not exist. or logon to modify the display. Wildcard characters are permitted. keys deps offline Displays a single column list of the objects selected by the command. Whether batchman is up or down is confirmed on screen by the Batchman LIVES or Batchman down message when you issue the conman start command.state[.conman 319 . or the file was available and used to satisfy a job or job stream dependency. The default is to display file dependencies in all states.showfiles showfiles Displays information about file dependencies.. dashes (-).offline] sf [[workstation#]file] [. info. file state <blank> The file has not yet been checked.. Managing objects in the plan . backslashes (\). A file dependency occurs when a job or job stream is dependent on the existence of one or more files before it can begin running. Displays information in the deps format.

Deps. Each file is listed in the following format: workstation#file Deps format: Files are listed followed by the dependent jobs and job streams.info format.deps a sample output is the following: Workstation Job Stream SchedTime Job (Est) (Est) State Pr Start Elapse ReturnCode Dependencies MASTER#/test/^LFILEJOB^ Dependencies are: MASTER #LFILEJOB 0600 11/26 ******** READY 10 LFILEJOB HOLD 10 (11/26) ^LFILEJOB^ MASTER#/usr/home/me10_99/`/usr/home/me10_99/bin/parms FILE_JS1` Dependencies are: MASTER #FILE_JS1 0600 11/26 ******** HOLD 10 (11/26) parms FILE_JS1` FILE_JS1 HOLD 10 (11/26) MASTER#/usr/home/me10_99/`/usr/home/me10_99/bin/parms FILE_JOB1` Dependencies are: MASTER #FILE_JOB1 0600 11/26 ******** READY 10 FILE_JB1 HOLD 10 (11/26) parms FILE_JB1` 320 IBM Tivoli Workload Scheduler: Reference Guide .info format: Files are listed. Job streams are listed in the standard showschedules format. File Name The name of the file.keys format: Jobs and job streams that have file dependencies are listed with one on each line.job] Deps. followed by the dependent jobs and job streams. Keys format: Files are listed with one file on each line. run the following command: sf @#@. run the following command: showfiles d:\apps\mis\lib\data4 To display offline the status of all file dependencies on all workstations in the deps format. Directory names are not included. in the following format: workstation#jstream[. Examples To display the status of a file dependency for d:\apps\mis\lib\data4. run the following command: sf @#@.logon format. Job streams are listed in the standard showschedules format.deps. Jobs are listed in the showjobs. Jobs are listed in the standard showjobs format.showfiles Standard format: Exists The state of the file dependency.offline To display the status of all file dependencies on all workstations in the deps format.logon format: Files are listed followed by the dependent jobs and job streams. Jobs are listed in the showjobs. Job streams are listed in the standard showschedules format. Deps.

showjobs showjobs Displays information about jobs. Managing objects in the plan .short | single] [.keys | info | logon]] [.short | single] [. This argument must be used in conjunction with the keys argument. keys retcod stdlist Displays information in the stdlist format.short | single] [. to display a specific instance of the job.hhmm] [. Use this.showid] Arguments jobselect workstation jobnumber hhmm keys info step logon retcod See “Selecting jobs in commands” on page 249. Chapter 9.keys | info | step | logon | keys retcod] [. Displays information in the info format.stdlist[. The job number. Wildcard characters are permitted. together with the stdlist and single arguments. The name of the workstation on which the job runs. You must have list access to the object being shown if the enListSecChk option was set to yes on the master domain manager when the production plan was created or extended.offline] [. | | | | The displayed information is updated only as long as Tivoli Workload Scheduler (batchman) is running. Use the keys argument to modify the display. for example: %sj @. The time the job started. Whether batchman is up or down is confirmed on screen by the Batchman LIVES or Batchman down message when you issue the conman start command.deps[.offline] [.showid] sj [jobselect | [workstation#]jobnumber. Displays information in the step format. Displays a single column list of the objects selected by the command.conman 321 .keys]] [. Displays information in the logon format. Syntax sj [jobselect] [. Displays the return code for the job.showid] sj [jobselect] [.offline] [.

Job The name of the job. info. Schedule The name of the job stream. repetitions. single offline showid Results The output of the showjobs command is produced in seven formats: standard. info. Standard format: CPU The workstation on which the job runs. and stdlist. This is useful with the stdlist option. Job states are as follows: ABEND The job ended with a non-zero exit code. ABENP An abend confirmation was received. an error occurred while checking for the remote status. The following notation may precede a job name: >> rerun as A job that was rerun with the rerun command. but the job is not completed. 322 IBM Tivoli Workload Scheduler: Reference Guide . Displays for each job stream the job stream identifier. and recovery jobs. ERROR For internetwork dependencies only. Shortens the display for every and rerun jobs to include only the following: v The first iteration v Jobs in different states v Exactly matched jobs Selects only the parent job in a chain that can include reruns. see “Offline output” on page 244. deps. or logon to modify the display. Use keys. keys. >> rerun step A job that was rerun with the rerun . step. State The state of the job or job stream. For information about this device.step command. or as a result of automatic recovery. and logon modify the displays. info. >> recovery The run of a recovery job.showjobs deps short Displays information in the deps format. logon. Sends the output of the command to the conman output device. ADD DONE The job completed in an unknown state. The job must be identified by job number in jobselect. The arguments keys. The job is being submitted. >> every run The second and subsequent runs of an every job. EXEC The job is running.

CANCELP The job stream is pending cancellation. a rerun action was just performed on the EXTERNAL job stream. FAIL FENCE The priority of the job is below the fence. SUCCP A SUCC confirmation was received. are resolved. a rerun action was just performed on the job in the EXTERNAL job stream. CANCL The job stream was cancelled. ERROR For internetwork dependencies only. PEND The job completed. HOLD The job stream is awaiting dependency resolution. SCHED The at time set for the job has not been reached. and all dependencies are resolved. HOLD The job is awaiting dependency resolution. INTRO The job is introduced for launching by the system. Unable to launch the job. Managing objects in the plan . the status is unknown. but the job is not completed. WAIT The job is in the WAIT state (extended agent). including an at time. READY The job stream is ready to launch and all dependencies are resolved. the job stream is in a remote Tivoli Workload Scheduler network and its state is unknown. and is awaiting confirmation.showjobs EXTRN For internetwork dependencies only. EXEC The job stream is running. Chapter 9. ADD The job stream was added with operator intervention. Cancellation is deferred until all of the dependencies. an error occurred while checking for the remote status. EXTRN For internetwork dependencies only. An error occurred. Job stream states are as follows: ABEND The job stream ended with a nonzero exit code. or the INET job or job stream does not exist. or the remote job or job stream does not exist.conman 323 . An error occurred. SUCC The job completed with an exit code of zero. READY The job is ready to launch.

pend option.showjobs STUCK Execution of the job stream was interrupted. v For an until time. v For an opens dependency. the file name is displayed. v For a needs dependency. dependencies A list of job dependencies and comments. (Est)Elapse The run time of the job stream or job. a job stream or job name is displayed. If the file resides on an extended agent and its name is longer than 25 characters. v For running jobs.pend option are labeled [Cancel Pend]. the time preceded by an angle bracket (<) is displayed. SUCC The job stream completed successfully. the repetition rate preceded by an ampersand (&) is displayed. v [Recovery] means that operation intervention is required. v For an every rate. v Jobs cancelled with . the prompt number is displayed in the format #num. are labeled [Until]. Parentheses indicate an estimate of the start time. the time preceded by an angle bracket (<) is displayed. Any combination of the following can be listed: v For a follows dependency. v For a prompt dependency. No jobs are launched without operator intervention. v Cancelled jobs are labeled [Cancelled]. Pr The priority of the job stream or job. only the last 25 characters are displayed. If the number of units requested is greater than one. (Est)Start The start time of the job stream or job. v For a deadline time. A plus sign (+) preceding the priority means the job has been launched. including jobs cancelled with . Parentheses indicate an estimate based on logged statistics. In case of an orphaned dependency an [O] is displayed. the number is displayed before the first hyphen. the prompt name follows in parentheses. For global prompts. v When reporting time dependencies the showjobs command shows in the Start column: – Only the time hh:mm if the day when the time dependencies is set matches with the day when the showjobs command is run. the date is listed instead of the time. a resource name enclosed in hyphens (-) is displayed. 324 IBM Tivoli Workload Scheduler: Reference Guide . – Only the date MM/DD if the day when the time dependencies is set does not match with the day when the showjobs command is run. If the start time is more than 24 hours in the past or future. v Jobs with expired until times. v Jobs submitted on UNIX using the Tivoli Workload Scheduler at and batch commands are labeled [Userjcl]. the process identification number (PID) is displayed in the format #Jnnnnn. For more information on orphaned dependencies refer to “Managing external follows dependencies for jobs and job streams” on page 59.

Managing objects in the plan . #34 #1(PRMT3). Keys format: Job names are listed one on each line in the following format: workstation#jstream hhmm mm/dd.showjobs v [Confirm] means that confirmation is required because the job was scheduled using the confirm keyword.-16 JOBSLOTS- MYCPU+#SCHED_F+ 0600 03/04 ******* HOLD 55(03/04) (M235062+#)JOBMDM HOLD 30(03/04) MYCPU+#SCHED_F+ 1010 03/04 ******* HOLD 55(03/04) (M235062+#)JOBMDM HOLD 30(03/04) Chapter 9.job for example: CPU Schedule SchedTime Job State Pr Start Elapse RetCode Deps [03/04/06]. #33 #1(PRMT3).-16 JOBSLOTS[03/04/06]. v [Script] applies to end-to-end networks only. it means that this job has a centralized script and that Tivoli Workload Scheduler for z/OS has not yet downloaded it to the agent.conman 325 .

For example: conman "sj. and ST for stop.info | more The job recovery option.step command. produces a sample output like the following: -------. >> rerun step A job that was rerun with the rerun . causing incorrect paging. Job The name of the job. if any. Schedule The name of the job stream. CO for continue. or as a result of automatic recovery. >> every run The second and subsequent runs of an every job. Long file names might wrap. >> recovery The run of a recovery job. pipe the output to more. Opt Job Prompt The number of the recovery prompt. CPU The workstation on which the job runs.Restart --------CPU Schedule SchedTime Job M235062+#SCHED_22 1010 03/06 JOBMDM (B236153+#)JOB_FTA M235062+#SCHED_22 0600 03/07 JOBMDM (B236153+#)JOB_FTA M235062+#FINAL 0559 03/07 MAKEPLAN SWITCHP+ CREATEP+ UPDATES+ M235062+#SCHED12 1010 03/06 JOBMDM (B236153+#)JOB_FTA JobFile /usr/acct/scripts/gl1 echo pippo /usr/acct/scripts/gl1 echo pippo /home/tws83/MakePlan TWSRCMAP:(RC=0) OR (RC=4) /home/tws83/SwitchPlan /home/tws83/CreatePostReports /home/tws83/UpdateStats /usr/acct/scripts/gl1 echo pippo Opt Job Prompt Step format: This format is not supported in Windows. The recovery options are RE for rerun. Job The name of the job. Schedule The name of the job stream.showjobs Info format: CPU The workstation on which the job runs. if any. To avoid this. The name of the recovery job. if any. The following notation might precede a job name: >> rerun as A job that was rerun with the rerun command. Job File The name of the script or executable file of the job. The following notation might precede a job name: 326 IBM Tivoli Workload Scheduler: Reference Guide .

See “Standard Format” for information about state. v The stdout output of the job. Job# The process identification number displayed as #Jnnnnn. >> repeated as The second and subsequent runs of an every job. The following notation might precede a job name: >> rerun as A job that was rerun with the rerun command. Logon The user name under which the job runs. For extended agent jobs. Job# Step The process identification number displayed as #Jnnnnn. only host processes are listed. Return code The return code of the job. change the IBM Tivoli Workload Scheduler date format before creating the standard list files. the operating system locale is set by default to ″C″. >> repeated as The second and subsequent runs of an every job. v Echoed commands. change the date locale format by performing the steps listed below: v In UNIX. Logon format: CPU The workstation on which the job runs. State The state of the job or job stream. v In Windows. State The state of the job or job stream. Depending on your environment.showjobs >> rerun as A job that was rerun with the rerun command. Managing objects in the plan . v The stderr output of the job. or as a result of automatic recovery. Stdlist format: A standard list file is created automatically by jobmon in Windows or jobman in UNIX. for each job that jobmon and jobman launches. You can display the contents of the standard list files using conman. You do this by modifying the date locale format. If the LANG variable is not set. Return code The return code of the job. or as a result of automatic recovery. A standard list file contains: v Header and trailer banners. set the LANG variable in the environment when netman starts. See “Standard Format” for information about state. perform the following steps: Chapter 9. To specify a particular date format to be used in the standard list files.conman 327 . Schedule The name of the job stream. A list of descendant processes that are associated with the job. Job The name of the job.

one on each line.logon format. Job streams are listed in the standard showschedules format. and ask to show the job stream identifier for the job stream. click on ″Advanced″. Deps format: Jobs used in follows dependencies are listed followed by the dependent jobs and job streams. To display the status of jobs belonging to job stream JSDOC on workstation site3.info format: Jobs used in follows dependencies are listed. Job streams are listed in the standard showschedules format.keys format: The names of the standard list files for the selected jobs are listed. Right-click on ″My Computer″. Deps. 3. on which you are running conman. run the following command: %sj JSDOC.info format. Jobs are listed in the standard showjobs format.keys format: Jobs and job streams that have follows dependencies are listed.@ or: showjobs site3#acctg To display the status of job JBA belonging to job stream TEST1 on workstation CPUA. Jobs are listed in the showjobs.JB1 for job JOBA is shown in the Dependencies column. Go to Control Panel→Regional Options and set your locale (location). followed by the dependent jobs and job streams. Job streams are listed in the standard showschedules format. on which you are running conman. Deps. 2. Stdlist. Jobs are listed in the showjobs. one on each line.JBA A sample output for this command is the following: Workstation Job Stream SchedTime Job State Pr Start Elapse ReturnCode Dependencies CPUA #TEST1 0900 02/19 *** HOLD 0(02/19) JBA HOLD 66(14:30) {02/20/06}. go to Properties. you can run the showjobs command in one of these two formats: showjobs site3#acctg. go to Environment Variables and set the LANG variable as a system variable. Examples To display the status of all jobs in the acctg job stream on workstation site3. Deps. followed by the dependent jobs and job streams.showjobs 1. Shut down and restart the system.showid 328 IBM Tivoli Workload Scheduler: Reference Guide . -TESTJ2(0600 02/24/06). indicates that the job stream instance has been carried forward and the date indicates the day when the job stream instance was added to the production plan for the first time. and ask to show the job stream identifier for the job stream.@. run the following command: sj CPUA#TEST1(0900 02/19/06).logon format: Jobs used in follows dependencies are listed. The standard list files for the selected jobs are displayed. In the Dependencies column the date enclosed in braces. {02/20/06}.JB1 The at dependency is shown as (14:30) in the Start column and the follows dependency from the job J2(0600 02/24/06).

logon A sample output for this command is the following: Workstation Job Stream SchedTime Job State Job# Logon ReturnCode site3 #JSDOCOM 0600 11/26 JDOCOM SUCC #J25565 me10_99 0 To display the status of all jobs in the HOLD state on all workstations. run the following command: sj @#@.JOBB CPUA#JS25.JOBA HOLD 66(14:30) JS22(0600 02/24/06).J25 = USER : tme10_99 Chapter 9. run the following command: sj site3#JSDOCOM.@ To display the log from the standard list files for the job J25 in the job stream JS25(0600 02/19/06) on workstation CPUA.J25. -TEST. in the deps format.deps a sample output is the following: Workstation Job Stream SchedTime Job State Pr Start Elapse RetCode Dependencies CPUA#JS2.JOBC Dependencies are: CPUA #JS25 0600 02/24 ***** HOLD 10(02/24) jobaa HOLD 10(02/24)(00:01) {02/20/06} TEST1.JOBB Dependencies are: CPUA #JS21 0900 02/19 ***** HOLD 0(02/19) {02/20/06}.(0AAAAAAAAAAAABQM)]. JOB1 JS18(0600 02/24/06).@ CPUA#JS25.JOB1 Dependencies are: CPUA #JS25 0600 02/24 ***** HOLD 10(02/24) JOBC HOLD 10(02/24)(00:01) jobaa HOLD 10(02/24)(00:01) {02/20/06} JOB1 TEST1. To display the status of jobs belonging to job stream JSDOCOM on workstation site3.showjobs A sample output for this command is the following: Workstation Job Stream SchedTime Job State Pr Start Elapse ReturnCode Dependencies site3 #JSDOCOM 0600 11/26 *** SUCC 10 11/26 00:01 JDOC SUCC 10 11/26 00:01 0 {0AAAAAAAAAAAACRZ} #J25565 The job stream identifier 0AAAAAAAAAAAACRZ for job stream JDOCOM is shown in the Dependencies column.conman 329 . JOBC TEST2. JOBC TEST2. and ask to show the information about the user ID under which the job runs.@. Note: The time or date displayed in the Start column is converted in the time zone set on the workstation where the job stream is to run. running in a UNIX environment.@+state=hold. JOB1 JS18(0600 02/24/06). Managing objects in the plan .stdlist The output is the following: =============================================================== = JOB : CPUA#JS25[(0600 02/19/06). run the following command: sj CPUA#JS25(0600 02/19/06).

in Windows.. stderr. The following example displays the status of the job dbseload with a return code of 7 and a state of SUCCESSFUL: $conman sj workstation#DAILY_DB_LOAD Tivoli Workload Scheduler (UNIX)/CONMAN 8.Fence:0.exe process runs in a very short time. System Time Is the time the kernel system spent for the job.. Batchman LIVES. 2007 All rights reserved. which can be considered null. or both. duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp...22) Licensed Materials Property of IBM(R) 5698-WSH (C) Copyright IBM Corp 1998. Elapsed Time Is the elapsed time for the job. other countries. User Time Is the time the system user spent for the job.36. AWSBIS308I End of job =============================================================== = Exit Status : 0 = System Time (Seconds) : 0 Elapsed Time (Minutes) : 0 = User Time (Seconds) : 0 = Mon 02/20/06 07:57:38 PST =============================================================== where: Exit Status Is the status of the job when it completed. . Limit:50. IBM is a registered trademark of International Business Machines Corporation in the United States.2. Note: The System Time and User Time fields are used only in UNIX. Locale LANG set to the following: "en" . Locale LANG set to the following: "en" Scheduled for (Exp) 02/20/06 (#35) on CPUA.4 (1. and echoed commands> . the joblnch. US Government User Restricted Rights Use.5) Installed for user "tme10_99"..Audit Level:0 sj workstation#DAILY_DB_LOAD (Est) (Est) CPU Schedule Job State Pr Start Elapse Dependencies Return Code WORKSTATION #DAILY_DB_LOAD ****************************** SUCC 10 22:11 00:04 DATASPLT SUCC 10 22:11 00:01 #J17922 0 DATAMRGE ABEND 10 22:12 00:01 #J17924 1 330 IBM Tivoli Workload Scheduler: Reference Guide .showjobs = JCLFILE : ls = Job Number: 28630 = Mon 02/20/06 07:57:37 PST =============================================================== Tivoli Workload Scheduler (UNIX)/JOBMANRC AWSBIS307I Starting /usr/home/tme10_99/jobmanrc ls Tivoli Workload Scheduler (UNIX)/JOBINFO 8. <stdout.. Installed for user "tme10_99". This is because.4 (9. Their values in Windows are always set to 0.

36.Fence:0. Batchman LIVES. Installed for user "tme10_99". Locale LANG set to the following: "en" Scheduled for (Exp) 02/20/06 (#35) on CPUA.showjobs CHCKMRGE SUCC 00:01 #J17926 DATACLNS SUCC 00:01 #J17932 DATARMRG SUCC 00:01 #J18704 DBSELOAD SUCC 00:01 #J18706 DATAREPT SUCC 00:01 #J18712 DATARTRN SUCC 00:01 #J18714 $ 10 0 10 0 10 0 10 7 10 0 10 0 22:12 22:12 22:13 22:13 22:13 22:14 The following example displays the return code for a specific job named workstation#daily_db_load. See also For the equivalent Job Scheduling Console task. see ″Working with Object Lists″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.dbseload.2. Chapter 9. or both. other countries. IBM is a registered trademark of International Business Machines Corporation in the United States.keys. Limit:50.22) Licensed Materials Property of IBM(R) 5698-WSH (C) Copyright IBM Corp 1998. duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.4 (1. US Government User Restricted Rights Use.Audit Level:0 sj workstation#daily_db_load. 2007 All rights reserved.retcod Tivoli Workload Scheduler (UNIX)/CONMAN 8. Managing objects in the plan .conman 331 .keys\.dbseload\.retcod 8 $ The retcod feature when integrated into a script can become quite powerful.dbseload: $ conman sj workstation#daily_db_load.

Wildcard characters are permitted.showprompts showprompts Displays information about prompts. The states are as follows: YES NO The prompt was replied to with y.]] promptname Specifies the name of a global prompt. keys deps info Displays a single column list of the objects selected by the command. ASKED The prompt was issued. The prompt was replied to with n.keys] [. logon Displays information in the logon format.state[. Whether batchman is up or down is confirmed on screen by the Batchman LIVES or Batchman down message when you issue the conman start command. Displays information in the deps format.offline] sp [promptselect] [.deps[.keys | info | logon]][. INACT The prompt has not been issued. but no reply was given. 332 IBM Tivoli Workload Scheduler: Reference Guide .offline] Arguments promptselect [promptname | [workstation#]msgnum][.. msgnum Specifies the message number of an unnamed prompt. state Specifies the state of prompts to be displayed. Use keys. or logon to modify the display. Displays information in the info format.. You must have list access to the object being shown if the enListSecChk option was set to yes on the master domain manager when the production plan was created or extended. Syntax sp [promptselect] [. The default is the workstation on which conman is running. | | | | The displayed information is updated only as long as Tivoli Workload Scheduler (batchman) is running. see “Offline output” on page 244. workstation Specifies the name of the workstation on which an unnamed prompt is issued. info. offline Sends the output of the command to the conman output device.. For information about this device.

(0AAAAAAAAAAAABSU)]) Are you ready to process job2? INACT 7(CPUA#SCHED_22[(0600 03/12/06). Results The output of the command is produced in three formats: standard. Deps format: Prompts used as dependencies are listed. Job streams are listed in the standard showschedules format. Jobs are listed in the standard showjobs format. and the text of the prompt.deps To display the status of prompt number 7 on workstation CPUA.showprompts Note: Prompt numbers assigned to both global and local prompts change when the production plan is extended. Managing objects in the plan . run the following command: sp CPUA#7 Chapter 9. and deps. followed by the dependent jobs and job streams. Job streams are listed in the standard showschedules format. run the following command: showprompts a sample is the following: State Message or Prompt ASKED 1(PRMT3) !continue? INACT 3(CPUA#SCHED_12[(0600 03/12/06). Message or Prompt For named prompts. in the deps format.asked. Deps. Keys format: The prompts are listed one on each line. Jobs are listed in the showjobs. Deps. info. the name. For unnamed prompts. Standard format: State The state of the prompt. the message number. Named prompts are listed with their message numbers and names.logon format.conman 333 . keys. Deps.(0AAAAAAAAAAAABTR)]) Are you ready to process job3? To display the status of all mis prompts that have been issued.info format. Job streams are listed in the standard showschedules format. followed by the dependent jobs and job streams. and the names of the jobs or job streams in which they appear as dependencies.keys format: Jobs and job streams that have prompt dependencies are listed one on each line.info format: Prompts used as dependencies are listed. (0AAAAAAAAAAAABST)]) Are you ready to process job1? INACT 5(CPUA#SCHED_12[(1010 03/12/06).logon format: Prompts used as dependencies are listed. Jobs are listed in the showjobs. the name of the job or job stream. and the text of the prompt. Unnamed prompts are listed with their message numbers. and logon modify the deps display. followed by the dependent jobs and job streams. The arguments keys. Examples To display the status of all prompt issued on the workstation on which you are running conman. run the following command: sp mis@. the message number.

see ″Displaying and Modifying Prompt Properties″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.(0AAAAAAAAAAAABTR)]) Are you ready to process job3? See also For the equivalent Job Scheduling Console task. 334 IBM Tivoli Workload Scheduler: Reference Guide .showprompts The output of the command is: INACT 7(CPUA#SCHED_22[(0600 03/12/06).

Specifies the name of the resource. see “Offline output” on page 244. resourcename keys deps info logon offline Results The output of the command is produced in three formats: standard. Sends the output of the command to the conman output device.offline] Arguments workstation Specifies the name of the workstation on which the resource is defined. Use keys. The total number of defined resource units. and deps. Syntax sr [[workstation#]resourcename] [. keys. and logon modify the deps display. | | | | The displayed information is updated only as long as Tivoli Workload Scheduler (batchman) is running.keys | info | logon]] [. Displays information in the info format. Keys format: The resources are listed one on each line. Managing objects in the plan . The default is the workstation on which conman is running. The number of resource units that have not been allocated. The number of resource units allocated to a job or job stream.conman 335 . The name of the job or job stream. or logon to modify the display. info. Displays information in the logon format. Chapter 9. Standard format: CPU Resource Total Available Qty Used By The workstation on which the resource is defined. Displays a single column list of the objects selected by the command. Wildcard characters are permitted. Whether batchman is up or down is confirmed on screen by the Batchman LIVES or Batchman down message when you issue the conman start command.offline] sr [[workstation#]resourcename] [. Displays information in the deps format.deps[. You must have list access to the object being shown if the enListSecChk option was set to yes on the master domain manager when the production plan was created or extended.keys] [. The arguments keys.showresources showresources Displays information about resources. The name of the resource. For information about this device. info.

#33 #1(PRMT3).deps A sample output is the following: (Est) (Est) Workstation Job Stream SchedTime Job State Pr Start Elapse RetCode Dependencies CPUA FTAA FTAA FTAA #JOBSLOTS Dependencies are: #SCHED_F+ 0600 03/04 ****** HOLD 55(03/04) (CPUA#)JOBMDM HOLD 30(03/04) #SCHED_F+ 1010 03/04 ****** HOLD 55(03/04) (CPUA#)JOBMDM HOLD 30(03/04) #SCHED_F+ 0600 03/05 ****** HOLD 55(03/05) (CPUA#)JOBMDM HOLD 30(03/05) [03/04/06]. Job streams are listed in the standard showschedules format. followed by the dependent jobs and job streams. followed by the dependent jobs and job streams. Examples To display information about all resources on the workstation on which you are running conman. followed by the dependent jobs and job streams. Job streams are listed in the standard showschedules format.-16 JOBSLOTS[03/04/06]. Job streams are listed in the standard showschedules format. run the following command: sr CPUA#JOBSLOTS.keys format: Jobs and job streams that have resource dependencies are listed one on each line. Deps. Jobs are listed in the showjobs. see ″Displaying Resource Properties″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.showresources Deps format: Resources used as dependencies are listed. Deps. Jobs are listed in the standard showjobs format. 336 IBM Tivoli Workload Scheduler: Reference Guide .info format: Resources used as dependencies are listed. Deps.-16 JOBSLOTS[03/04/06]. Jobs are listed in the showjobs.logon format: Resources used as dependencies are listed.info format.#35 #1(PRMT3). run the following command: showresources A sample output is: CPU#Resource CPUA #JOBSLOTS Total Available 16 16 Qty UsedBy No holders of this resource To display information about the jobslots resource on workstation CPUA in the deps format.logon format.#34 #1(PRMT3).-16 JOBSLOTS- See also For the equivalent Job Scheduling Console task.

| | | | The displayed information is updated only as long as Tivoli Workload Scheduler (batchman) is running.showid] Arguments jstreamselect keys deps info logon offline See “Selecting job streams in commands” on page 257.offline] [. info. or logon to modify the display. Displays a single column list of the objects selected by the command. The states are as follows: ADD The job stream was added with operator intervention. Displays information in the deps format. You must have list access to the object being shown if the enListSecChk option was set to yes on the master domain manager when the production plan was created or extended. Sends the output of the command to the conman output device. Schedule The name of the job stream.keys] [.deps[. The arguments keys.showschedules showschedules Displays information about job streams. info. Managing objects in the plan .keys | info | logon]] [.conman 337 . see “Offline output” on page 244. and logon modify the deps display. Use keys. Displays information in the logon format. Displays for each job stream the job stream identifier. and deps. Chapter 9.showid] ss [jstreamselect] [. ABEND The job stream ended with a nonzero exit code. State The state of the job stream. Displays information in the info format.offline] [. Syntax ss [jstreamselect] [. keys. Standard format: CPU The workstation on which the job stream runs. showid Results The output of the command is produced in three formats: standard. For information about this device. Whether batchman is up or down is confirmed on screen by the Batchman LIVES or Batchman down message when you issue the conman start command.

Jobs OK The number of jobs that have completed successfully. only the last 25 characters are displayed. a resource name enclosed in hyphens (-) is displayed. and its name is longer than 25 characters. Cancellation is deferred until all of the dependencies. If the number of units requested is greater than one. the job stream is in a remote Tivoli Workload Scheduler network and its status is unknown. ERROR For internetwork dependencies only. a rerun action was just performed on the EXTERNAL job stream. CANCELP The job stream is pending cancellation. dependencies A list of job stream dependencies and comments.showschedules CANCL The job stream was cancelled. an error occurred while checking for the remote status. An error occurred. 338 IBM Tivoli Workload Scheduler: Reference Guide . Pr The priority of the job stream. If the file resides on an extended agent. v For an until time. No jobs are launched without operator intervention. the time preceded by an angled bracket (<). the date is listed instead of the time. v For an opens dependency. no limit is in effect. Parentheses indicate an estimate based on logged statistics. EXEC The job stream is running. or the INET job or job stream does not exist. If the start time is more than 24 hours in the past or future. Parentheses indicate an estimate of the start time. Jobs # The number of jobs in the job stream. READY The job stream is ready to launch and all dependencies are resolved. the number is displayed before the first hyphen. (Est)Start The start time of the job stream. SUCC The job stream completed successfully. Any combination of the following may be listed: v For a follows dependency. If one is not listed. Sch Lim The job stream’s job limit. are resolved. a job stream or job name is displayed. the file name is displayed. including an at time. HOLD The job stream awaiting dependency resolution. STUCK Job stream execution was interrupted. EXTRN For internetwork dependencies only. v For a needs dependency. (Est)Elapse The run time of the job stream.

Deps. are labeled: [Until]. v When reporting time dependencies the showschedules command shows in the Start column: – Only the time hh:mm if the day when the time dependencies is set matches with the day when the showschedules command is run. the prompt number displayed as #num.keys format: Job streams that have follows dependencies are listed one on each line. v For job streams that were carried forward from the previous production plan. Job streams are listed in the standard showschedules format. Deps format: Job streams used as dependencies are listed. run the following command: showschedules @+state=hold A sample output for this command is the following: Chapter 9.pend option are labeled [Cancel Pend].pend option. the prompt name in parentheses follows.conman 339 . followed by the dependent jobs and job streams. For global prompts. Examples To display the status of job stream CLEM_DOCOM on workstation site3. v Job streams with expired until times.info format.info format: Job streams used in as dependencies are listed. Job streams are listed in the standard showschedules format.showschedules v For a prompt dependency. – Only the date mm/dd if the day when the time dependencies is set does not match with the day when the showschedules command is run. the original name and date are displayed in brackets. Jobs are listed in the showjobs. Managing objects in the plan . v For a deadline time.logon format. Deps. Jobs are listed in the showjobs. Deps.logon format: Job streams used in as dependencies are listed. Job streams are listed in the standard showschedules format. v Cancelled job streams are labeled [Cancelled]. Note: The time or date displayed in the Start column is converted in the time zone set on the workstation where the job stream is to run. including job streams cancelled with the . followed by the dependent jobs and job streams. v Job streams that contain the carryforward keyword are labeled [Carry]. followed by the dependent jobs and job streams. Keys format: The job streams are listed one on each line. v Job streams cancelled with the . and ask for the job stream identifier run the following command: %ss @#JS_DOCOM . the time preceded by an angle bracket (<) is displayed.showid A sample output of this command is the following: (Est) (Est) Jobs Sch Workstation Job Stream SchedTime State Pr Start Elapse # OK Lim site3 #JS_DOCOM 0600 11/26 SUCC 10 11/26 00:01 1 1 {0AAAAAAAAAAAACRZ} To display the status of all job streams in the HOLD state on the workstation on which you are running conman. Jobs are listed in the standard showjobs format.

deps. run the following command: ss CPUA#sched@.off To display the status of all job streams on all workstations. see ″Displaying a Job Stream″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. 340 IBM Tivoli Workload Scheduler: Reference Guide . run the following command: %ss @#@ This is a sample output for the command: Workstation site3 site3 site2 site3 site3 site1 site3 site3 Job Stream #JS_DOCOM #JS_SCRIPT #JS_PRED1 #JS_SCRIPT1 #LFILEJOB #RES_100 #FILE_JS1 #FILE_JOB SchedTime 0600 11/26 0600 11/26 1000 11/26 0600 11/26 0600 11/26 0600 11/26 0600 11/26 0600 11/26 State SUCC SUCC SUCC ABEND READY SUCC HOLD SUCC Pr 10 10 10 10 10 10 10 10 (Est) Jobs Sch Elapse # OK Lim 00:01 1 1 00:03 1 1 00:01 1 1 00:01 1 0 1 0 11/26 00:09 1 1 (11/26) 1 0 11/26 00:01 1 1 (Est) Start 11/26 11/26 11/26 11/26 parms FILE_JS1` See also For the equivalent Job Scheduling Console task.Restart --------CPU Schedule SchedTime Job JobFile Opt Job Prompt CPUA #JS_FIRST1[(0600 03/10/06).showschedules (Est) (Est) Jobs Sch Workstation Job Stream SchedTime State Pr Start Elapse # OK Lim site3 #FILE_JS1 0600 11/26 HOLD 10 (11/26) 1 0 parms FILE_JS1` To display the status of all job streams with name beginning with sched on workstation CPUA in the deps. run the following command: ss @#@+state=abend.info format.info A sample output is the following: -------.(0AAAAAAAAAAAABVY)] Dependencies are: CPUA#MOD 0212 03/10 JOBMDM /usr/scripts/gl1(B236153+#)JOB_FTA1 echo Start gl1? CPUA#MOD 0251 03/10 JOBMDM /usr/scripts/gl2(B236153+#)JOB_FTA2 echo Start gl2? To display offline the status of all job streams in the ABEND state on all workstations.

including batchman. Examples To shut down production on the workstation on which you are running conman. Managing objects in the plan . all mailman servers.conman 341 . Syntax shut[down] [. For information about the StartUp command. mailman.shutdown shutdown Unconditionally stops all the Tivoli Workload Scheduler production processes and . run the following conman commands: start startappserver startmon You must run a conman unlink @ command before executing a shutdown command. run the following command: unlink@. To restart netman only.wait] Arguments wait Waits until all processes have stopped before prompting for another command. and all writer processes. Comments | | | | | | | The shutdown command stops the processes only on the workstation on which conman is running.wait Chapter 9. To restart the entire process tree. run the StartUp command. netman. It does not stop the WebSphere Application Server services. jobman. run the following command: unlink @ shutdown To shut down production on the workstation on which you are running conman and wait for all processes to stop. You must have shutdown access to the workstation. see “StartUp” on page 409.noask shut .

start start | | | Starts Tivoli Workload Scheduler production processes. the default domain is the one in which conman is running. Wildcard characters are permitted. The workstation becomes the new domain manager and the current domain manager becomes a fault-tolerant agent. and when the switchmgr command is run. 342 IBM Tivoli Workload Scheduler: Reference Guide . Syntax start [domain!]workstation [. For example. to start all the agents in domain stlouis. You must have start access to the workstation. For more details on this option. See “switchmgr” on page 367 for more information. This form of the command usually follows a stop command.mgr] [. noask demgr Specifies not to prompt for confirmation before taking action on each qualifying workstation. This can be entered only on the workstation on which conman is running. depriving the agent of the domain manager function. It starts the local workstation as the domain manager. for example. This option is run automatically. and workstation contains wildcard characters. of delayed restart or restart after repairing a damaged agent). Note: The preferred method of switching a domain manager is to use a switchmgr command. but until the old domain manager has processed the switchmgr event (in the case. workstation mgr Specifies the name of the workstation to be started. Note: Make sure conman start is not issued while either JnextPlan or stageman runs.noask] [. see the IBM Tivoli Workload Scheduler Planning and Installation Guide.demgr] Arguments domain Specifies the name of the domain in which workstations are started. This option prevents the opening of external connections during the transition time between when an agent starts as an old domain manager. This argument is useful when starting more than one workstation in a domain. except for the event monitoring engine and WebSphere Application Server (see“startappserver” on page 345 and “startmon” on page 347 to learn the commands that start these processes). Wildcard characters are permitted. use the following command: start stlouis!@ If domain is omitted. the demgr option must be used to start the old domain manager from the local command line.

v A user running conman on an agent can start workstations that are hosted by that agent. Started workstations in network Table 46. the following rules apply: v A user running conman on the master domain manager can start any workstation in the network.conman 343 . DMn are domain managers and Ann are agents. A11 DM1 A12 Domain1 User1 User3 DM2 A21 A22 Domain2 User2 A31 DM3 A32 Domain3 DM4 Domain4 A41 A42 Figure 11. Agents that are not autolinked are initialized and started when you run a link command.start Comments The start command is used at the start of each production period to restart Tivoli Workload Scheduler following preproduction processing. v A user running conman on a domain manager other than the master can start any workstation in that domain and subordinate domains. At that time it causes the autolinked fault-tolerant agents and standard agents to be initialized and started automatically. Managing objects in the plan . Assuming the user has start access to the workstations being started. The user cannot start workstations in peer domains. Started workstations Command start @!@ Started by User1 Started by User2 Started by User3 A21 All workstations are DM2 started A21 A22 DM4 A41 A42 DM1 A11 A12 DM3 A31 A32 DM2 A21 A22 Not allowed start @ A21 start DOMAIN3!@ Not allowed Chapter 9. Examples Figure 11 and Table 46 below show the workstations started by start commands run by users in various locations in the network.

start Table 46. Started workstations (continued) Command start DOMAIN4!@ Started by User1 DM4 A41 A42 DM2 A42 A31 Started by User2 DM4 A41 A42 DM2 A42 Not allowed Started by User3 Not allowed start DM2 start A42 start A31 Not allowed Not allowed Not allowed 344 IBM Tivoli Workload Scheduler: Reference Guide .

the default domain is the one in which conman is running.startappserver | | | | | | | | | | | | | | | | | | | | | | | workstation startappserver Starts the embedded WebSphere Application Server on the workstation.conman 345 . If no domain and workstations are specified.wait] Arguments domain Specifies the name of the domain of the workstation. the domain is not needed when starting the WebSphere Application Server on a specific workstation. Managing objects in the plan . Specifies the name of the workstation where you want to start the monitoring engine. Wildcard characters are permitted. and workstation contains wildcard characters. Chapter 9. Because workstations have unique names. wait Comments Permission to start actions on cpu objects is required in the security file to be enabled to run this command. Waits until WebSphere Application Server has started before prompting for another command. If domain is omitted. the action is on the local workstation. Wildcard characters are permitted. Syntax startappserver[domain!]workstation [. WebSphere Application Server can also be started with the StartUp utility command.

Comments You can omit the workstation name if you run the command locally. Syntax starteventprocessor [domain!]workstation Arguments domain workstation Specifies the name of the domain of the workstation. backup master.starteventprocessor | | | | | | | | | | | | | | starteventprocessor Starts the event processing server on the master domain manager. Permission to start actions on cpu objects is required in the security file to be enabled to run this command. 346 IBM Tivoli Workload Scheduler: Reference Guide . or on a workstation installed as a backup master that functions as a plain fault-tolerant agent. Wildcard characters are not permitted. Specifies the name of the workstation where you want to start the event processing server.

conman 347 . Syntax startmon [domain!]workstation [. Chapter 9. the default domain is the one in which conman is running. and workstation contains wildcard characters. Because workstations have unique names. Comments Permission to start actions on cpu objects is required in the security file to be enabled to run this command.noask] Arguments domain Specifies the name of the domain of the workstation. Managing objects in the plan .startmon | | | | | | | | | | | | | | | | | | | | workstation noask startmon Starts the monman process that turns on the event monitoring engine on the workstation. Wildcard characters are permitted. the domain is not needed when starting the monitoring engine on a specific workstation. If domain is omitted. Wildcard characters are permitted. Specifies the name of the workstation where you want to start the monitoring engine. Specifies not to prompt for confirmation before taking action on each qualifying workstation.

Fence:0. databases and plans are always expanded. the production plan (Symphony file) mode is shown in parentheses.status status Displays the conman banner and the Tivoli Workload Scheduler production status. The Def or Exp information can appear. Limit:19. With Tivoli Workload Scheduler.2. and Exp means it is in expanded mode. Job stream (Exp) 11/26/05 (#34) on site3.36. Syntax status Results Following the word schedule on the second line of output. Audit Level:0 348 IBM Tivoli Workload Scheduler: Reference Guide . Def means that the production plan is in non-expanded mode.22) Licensed Materials Property of IBM 5698-WKB (C) Copyright IBM Corp 1998. Batchman LIVES.2. %status TWS for UNIX/CONMAN 8.4 (1. The mode of the production plan is determined by the setting of the global option expanded version. duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Version 8. but this information appears for backward compatibility with previous versions. Examples The following example displays the status of the current production plan. 2007 US Government User Restricted Rights Use.

if the TCP/IP path is not available). The user cannot stop workstations in peer domains.noask] Arguments domain Specifies the name of the domain in which workstations are stopped. Comments If the stop command cannot be applied to a distant workstation (for example. Wildcard characters are permitted. Therefore. the domain is not needed when stopping a specific workstation. and is sent to the workstation when it becomes linked. Managing objects in the plan . Assuming the user has stop access to the workstations being stopped. the following rules apply: v A user running conman on the master domain manager can stop any workstation in the network. and workstation contains wildcard characters. You must have stop access to the workstation. To stop the netman process. Specifies not to prompt for confirmation before taking action on each qualifying workstation. Syntax stop [domain!]workstation [.conman 349 . This argument is useful when stopping more than one workstation in a domain. then finally runs on the domain manager. v A user running conman on an agent can stop any workstation in the local domain. if you issue a conman sc@!@ command from any CPU. even of the domain manager. the default domain is the one in which conman is running. Chapter 9. to stop all the agents in domain stlouis. When you issue a stop @ command on a domain manager. For example. The command starts running on the lowest stations in the network hierarchy. use the following command: stop stlouis!@ If domain is omitted. Specifies not to accept another command until all processes have stopped. Because workstations have unique names. Wildcard characters are permitted. the Symphony file is not updated before the CPUs go down. the resulting information might be an up to date picture of the states of the CPUs.stop stop Stops Tivoli Workload Scheduler production processes.wait] [. use the shutdown command. workstation wait noask Specifies the name of the workstation to be stopped. a local conman stop command runs on the remote CPUs. the command is stored locally in a pobox file. However. v A user running conman on a domain manager other than the master can stop any workstation in that domain and subordinate domains.

stop Examples Figure 12 and Table 47 below show the workstations stopped by different stop commands run by users in different locations in the network. A11 DM1 A12 Domain1 User1 User3 DM2 A21 A22 Domain2 User2 A31 DM3 A32 Domain3 DM4 Domain4 A41 A42 Figure 12. DMn are domain managers and Ann are agents. Stopped workstations Command stop @!@ Stopped by: User1 Stopped by User2 Stopped by User3 DM2 A21 A22 All workstations are DM2 stopped A21 A22 DM4 A41 A42 DM1 A11 A12 DM3 A31 A32 DM4 A41 A42 DM2 A42 A31 DM2 A21 A22 Not allowed stop @ DM2 A21 A22 Not allowed stop DOMAIN3!@ stop DOMAIN4!@ DM4 A41 A42 DM2 A42 Not allowed Not allowed stop DM2 stop A42 stop A31 DM2 Not allowed Not allowed 350 IBM Tivoli Workload Scheduler: Reference Guide . Stopped workstations in network Table 47.

stop . You must have stop access to the workstation. Similar to the stop @!@ command. stops itself.progressive Command stop . the domain manager stops workstations in the same domain.progressive Stops Tivoli Workload Scheduler production processes hierarchically when you have defined at least one workstation as BEHINDFIREWALL in an Tivoli Workload Scheduler network. but more effective in improving plan performance. Managing objects in the plan .progressive command on DM2. Examples Figure 12 on page 350 and Table 48 show the workstations stopped by issuing the stop .progressive Comments When you issue the command on a domain manager.conman 351 . The command does not run from the domain in which the command was initially issued for each subordinate domain. Table 48. and then continues to run on subordinate domains. all workstations in that domain are stopped and then the domain manager itself is stopped and the command continues to run on any subordinate domains. The command continues to run in this hierarchical manner. Stopped workstations with stop .progressive Stopped by DM2 A21 A22 DM2 Stopped by DM4 A41 A42 DM4 Chapter 9. but runs at each hierarchical level.progressive stop . Syntax stop .

If no domain and workstations are specified. Syntax stopappserver[domain!]workstation [. 352 IBM Tivoli Workload Scheduler: Reference Guide . and workstation contains wildcard characters. the domain is not needed when stopping the WebSphere Application Server on a specific workstation. the action is on the local workstation. Wildcard characters are permitted. Specifies the name of the workstation where you want to stop the monitoring engine. Waits until WebSphere Application Server has stopped before prompting for another command. If domain is omitted. Wildcard characters are permitted. wait Comments Permission to stop actions on cpu objects is required in the security file to be enabled to run this command.stopappserver | | | | | | | | | | | | | | | | | | | | | workstation stopappserver Stops the embedded WebSphere Application Server on the workstation. the default domain is the one in which conman is running.wait] Arguments domain Specifies the name of the domain of the workstation. Because workstations have unique names.

Wildcard characters are not permitted. Specifies the name of the master domain manager. or workstation installed as a backup master that functions as a plain fault-tolerant agent where you want to stop the event processing server.conman 353 . Comments This command cannot be issued in an asynchronous way.stopeventprocessor | | | | | | | | | | | | | | | | stopeventprocessor Stops the event processing server. Syntax stopeventprocessor [domain!][workstation] Arguments domain workstation Specifies the name of the domain of the workstation. Managing objects in the plan . Permission to stop actions on cpu objects is required in the security file to be enabled to run this command. Chapter 9. backup master. You can omit the workstation name if you run the command locally.

Specifies not to accept another command until the monitoring engine has stopped. Permission to stop actions on cpu objects is required in the security file to be enabled to run this command. Because workstations have unique names.wait] [.noask] Arguments domain Specifies the name of the domain of the workstation. the default domain is the one in which conman is running. The command is asynchronous. and workstation contains wildcard characters. If domain is omitted. Syntax stopmon [domain!]workstation [. the domain is not needed when stopping the monitoring engine on a specific workstation. Wildcard characters are permitted.stopmon | | | | | | | | | | | | | | | | | | | | | | | | | | workstation wait noask stopmon Stops the event monitoring engine on the workstation. Specifies not to prompt for confirmation before taking action on each qualifying workstation. Specifies the name of the workstation where you want to stop the monitoring engine. Comments The monitoring engine is restarted automatically when the next production plan is activated (on Windows also when Tivoli Workload Scheduler is restarted) unless you disable the autostart monman local option. unless you specify the wait keyword. Wildcard characters are permitted. 354 IBM Tivoli Workload Scheduler: Reference Guide .

The entire command must be enclosed in quotes (″). in which case.schedid |jobstreamname (hhmm[ date])}] [. The default is the workstation on which conman is running. a job name is constructed using up to 255 characters of the command name. If the command is longer than six alphanumeric characters such as. the job is launched on all qualifying workstations. followed by a ten digit random number.. you must have use access to the resources and global prompts. You must have submit access to the job.joboption[. You cannot specify a domain or workstation class. If you do not include alias the first time you submit the command. to set the local variable var1 to hello you must issue the following command: %sbd "set var1\"=\"hello" cmd Specifies a valid system command of up to 255 characters. you must mask the equal (=) sign as follows ’\=’\ when submitting Windows commands using submit docommand. Managing objects in the plan .]] Arguments workstation Specifies the name of the workstation on which the job will be launched. The command is treated as a job. If there are blanks in the command. If you submit the job from a workstation other than the master domain manager you must be connect as a user that is: v defined in the user registry used by WebSphere Application Server for authentication v authorized to perform submit commands in security file stored on the master domain manager. if the command is ″rm apfile″.alias[=name]] [. the generated name will be wlsins0396578515. For example. and all job rules apply.submit docommand submit docommand Submits a command to be launched as a job. Syntax sbd+ [workstation#]″cmd″ [. depending on the number of characters in the command. For example..conman 355 . If you enter the alias keyword without specifying a name.. Note: The local parameters specified in the this field are resolved on the workstation from where the command is submitted as a job using conman sbd.into=[workstation#] {jobstream_id. a name is constructed using up to the first six alphanumeric characters (in upper case) of the command. To include needs and prompt dependencies. the name is constructed using up to the first six alphanumeric characters before the blank. ″wlsinst″. alias=name Specifies a unique name to be assigned to the job. Note: Because of a limitation in the way Windows manages the equal (=) sign in the shell environment. Wildcard characters are permitted. If Chapter 9. the generated name will be similar to RM0123456789.

. joboption Specify one of the following: at=hhmm [timezone|tz tzname] [+n days | mm/dd[/yy]] | [absolute | abs] confirmed deadline=time [timezone|tz tzname][+n day[s | mm/dd[/yy]] every=rate follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][.schedid}| job[.. needs=[num] [workstation#]resource[. into=jobstream_instance Identifies the job stream instance into which the job will be placed for launching...] Note: The local parameters specified in the opens clause are resolved on the workstation from where the command is submitted as a job using conman sbd. priority[=pri | hi | go] prompt=″[: | !]text″ | promptname[. the job is added to a job stream named JOBS..nocheck][.] rccondsucc″Success Condition″ recovery=stop | continue | rerun after [workstation#]jobname abendprompt “text” until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [. the alias keyword is mandatory and must be unique for each command submission. Select the job stream instance as follows: [workstation#]jobstreamname[hhmm[ date]] or [workstation#]jobstream_id ..nocheck argument is not supported in internetwork dependencies.. 356 IBM Tivoli Workload Scheduler: Reference Guide . If into is not used.wait=time][.] opens=[workstation#]″filename″[(qualifier)][.. logon=user.job | @] | jobstream_id.schedid If you do not specify a workstation... interactive | Note: This keyword can be used in Windows environments only.submit docommand you submit a command a second time from the same workstation..job.] Note: The ..onuntil action] The default value for joboption is the user on the workstation from which the command is being run. the default is the workstation on which conman is running.

conman 357 . needs.at=1730 To submit chmod commands on all workstations with names beginning with site.. Managing objects in the plan . or opens.follows sked3 To submit a sort command with the alias sortit and place the job in the job stream reports with an at time of 5:30 p. run the following command: sbd "sort < file1 > file2".alias=sortit.into=reports.alias Chapter 9. run the following command: submit docommand="rm apfile". Examples To submit an rm command into the job stream JOBS with a follows dependency. run the following command: sbd site@#"chmod 444 file2".submit docommand Comments Jobs submitted in production from the conman command line are not included in the preproduction plan and so they cannot be taken into account when identifying external follows dependencies predecessors.m. If you do not specify a workstation with follows. the default is the workstation of the job.

the generated name will be similar to JCLTTX0123456789.. into=jobstream_instance Identifies the job stream instance into which the job will be placed for launching. dashes (-). If you enter the alias keyword without specifying a name. if the file name does not start with a letter.]] [.. followed by a ten digit random number. depending on the number of characters in the file name. if the file name is jclttx5. a name is constructed using up to the first six alphanumeric characters (in upper case) of the file name. To include needs and prompt dependencies.schedid |jobstreamname (hhmm[ date])}] [. and underscores (_). 358 IBM Tivoli Workload Scheduler: Reference Guide . alias=name Specifies a unique name to be assigned to the job. Select the job stream instance as follows: [workstation#]jobstreamname[hhmm[ date]] or [workstation#]jobstream_id .alias[=name]] [. in upper case. the alias keyword is mandatory and must be unique for each file submission. Note: The local parameters specified within this file are resolved on the workstation from where the file is submitted as a job using conman sbf. the job is added to a job stream named JOBS. If you do not include alias.into=[workstation#]{jobstream_id . you are prompted to use alias= name. In either of the above cases. If you submit a file a second time from the same workstation.joboption[.schedid If you do not specify a workstation. The name must be enclosed in quotes (″) if it contains characters other than alphanumeric characters. you must have use access to the resources and global prompts. a filename is constructed using up to 255 alphanumeric characters of the file’s base name.submit file submit file Submits a file to be launched as a job. Syntax | | | | | sbf ″filename″ [. Wildcard characters are permitted.. See the examples. For example. You must have submit access to the job. slashes (/). the default is the workstation on which conman is running. If you submit the job from a workstation other than the master domain manager you must be connect as a user that is: v defined in the user registry used by WebSphere Application Server for authentication v authorized to perform submit commands in security file stored on the master domain manager. If into is not used.noask] Arguments filename Specifies the name of the file. up to 255 characters.

into sequence was omitted.nocheck][. Examples To submit a file into the job stream jobs (the job name is myjcl).] rccondsucc″Success Condition″ recovery=stop | continue | rerun after [workstation#]jobname abendprompt “text” until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [. Chapter 9....conman 359 ..nocheck argument is not supported in internetwork dependencies. If you do not specify a workstation with follows.schedid}| job[. Managing objects in the plan . needs.. priority[=pri | hi | go] prompt=″[: | !]text″ | promptname[..wait=time][. the default is the workstation on which conman is running.onuntil action] noask Specifies not to prompt for confirmation before taking action against each qualifying file. Comments Jobs submitted in production from the conman command line are not included in the preproduction plan and so they cannot be taken into account when identifying external follows dependencies predecessors.] Note: The .... interactive | Note: This keyword can be used in Windows environments only. run the following command: submit file=d:\jobs\lib\daily\myjcl where the .job | @] | jobstream_id. logon=user needs=[num] [workstation#]resource[.] Note: The local parameters specified in the opens clause are resolved on the workstation from where the file is submitted as a job using conman sbf.] opens=[workstation#]″filename″[(qualifier)][. or opens....job.submit file joboption Specify one of the following: at=hhmm [timezone|tz tzname] [+n days | mm/dd[/yy]] | [absolute | abs] confirmed deadline=time[timezone | tz tzname][+n days | mm/dd[/yy]] every=rate follows=[netagent::][workstation#]{jobstreamname(hhmm [mm/dd[/yy]])[.

where "\" is the escape character for the blank in the file path. v In command line mode: conman sbf "\"\\\"C:\Program Files\IBM\TWS\lucaMDM\tws_env.alias=MYJOB Being in Windows.cmd\\\"\"".cmd.cmd\"". and running the command externally from the conman environment. run the following command: sbf /usr/lib/mis/jcl4. the double quotes (") must be escaped by the "\ character sequence.alias=MYJOB Being in Windows.submit file To submit a file. whose path contains a blank.needs=2 slots The job needs two units of the slots resource. run the following command: sbf "/usr/lib/backup/back@". To submit all files that have names beginning with back into the job stream bkup. 360 IBM Tivoli Workload Scheduler: Reference Guide . into the job stream missked. on a Windows workstation run: v In interactive mode: sbf "\"C:\Program Files\IBM\TWS\lucaMDM\tws_env. with a job name of misjob4. the escape sequence becomes longer.alias=misjob4.into=missked .into=bkup | | | | | | | | | | | To submit file tws_env.

conman 361 . The name is always upshifted. Managing objects in the plan .joboption[. you must use the alias argument to assign a unique name. If you enter the alias keyword without specifying a name. If into is not used. Wildcard characters are permitted. the job is added to a job stream named JOBS. You cannot specify a domain or workstation class.schedid If you do not specify a workstation. and is being submitted into the same job stream. in which case. You must have submit access to the job. the generated name will be similar to JC123456..submit job submit job Submits a job to be launched. To include needs and prompt dependencies.alias[=name]] [. if jobname is jcrttx5. Wildcard characters are permitted. the job is launched on all qualifying workstations. If you submit the job from a workstation other than the master domain manager you must be connect as a user that is: v defined in the user registry used by WebSphere Application Server for authentication v authorized to perform submit commands in security file stored on the master domain manager. all qualifying jobs are submitted. Syntax sbj [workstation#]jobname [. For example. If the job is already in the production plan.. jobname Specifies the name of the job. into=jobstream_instance Identifies the job stream instance into which the job will be placed for launching.into=[workstation#]{jobstream_id .schedid | jobstreamname(hhmm[ date])}] [. joboption Specify one of the following: at=hhmm [timezone|tz tzname] [+n days | mm/dd[/yy]] | [absolute | abs] confirmed Chapter 9.]] [.. you must have use access to the resources and global prompts. Select the job stream instance as follows: [workstation#]jobstreamname[hhmm[ date]] or [workstation#]jobstream_id . in which case. The default is the workstation on which conman is running.noask] Arguments workstation Specifies the name of the workstation on which the job will be launched. alias=name Specifies a unique name to be assigned to the job in place of jobname. the default is the workstation on which conman is running. a name is constructed using the first two alphanumeric characters of jobname followed by a six digit random number.

run the following command: sbj rjob4.submit job deadline=time[timezone | tz tzname][+n days | mm/dd[/yy]] every=rate follows=[netagent::][workstation#]{jobstreamname(hhmm [mm/dd[/yy]]) [....job | @] | jobstream_id. If you do not specify a workstation with follows.. run the following command: sbj site@#txjob3...] Note: The . or opens...] rccondsucc″Success Condition″ recovery=stop | continue | rerun after [workstation#]jobname abendprompt “text” until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [...] opens=[workstation#]″filename″[(qualifier)][. needs.at=1730 To submit job txjob3 on all workstations whose names begin with site.alias See also For the equivalent Job Scheduling Console task. 362 IBM Tivoli Workload Scheduler: Reference Guide .job. see ″Submitting Jobs″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide.schedid.into=reports. the default is the workstation of the job.nocheck][..nocheck argument is not supported in internetwork dependencies. run the following command: sbj test To submit a job with an alias of rptx4 and place the job in the job stream reports with an at time of 5:30 p. needs=[num] [workstation#]resource[.schedid}| job[. priority[=pri | hi | go] prompt=″[: | !]text″ | promptname[..] Note: The local parameters specified in the opens clause are resolved on the workstation from where the job is submitted using conman sbj. Examples To submit the test jobs into the job stream JOBS.wait=time][. This option can be used only with . Comments Jobs submitted in production from the conman command line are not included in the preproduction plan and so they cannot be taken into account when identifying external follows dependencies predecessors.m.alias=rptx4.onuntil action] noask Specifies not to prompt for confirmation before taking action against each qualifying job..

Managing objects in the plan . you must have use access to the resources and global prompts.submit sched submit sched Submits a job stream to be launched.. the generated name will be similar to ST123456.conman 363 . by then. If you enter the alias keyword without specifying a name.jstreamoption[. The submit schedule command uses the credentials set in the useropts file belonging to the TWS_user who installed that workstation. in which case.. jstreamoption Enter one of the following: [at=hhmm [timezone|tz tzname] [+n days | date] | [absolute | abs]] | [schedtime=[hhmm [date] | [+n days]] where: schedtime Represents the day and time when the job stream is positioned in the plan. The value assigned to schedtime does not represent a dependency for the job Chapter 9. Syntax sbs [workstation#]jstreamname [. The default is the workstation on which conman is running. If the job stream is already in the production plan. To include needs and prompt dependencies.]] [. If.noask] Arguments workstation Specifies the name of the workstation on which the job stream will be launched. For example. If you submit the job stream from a workstation other than the master domain manager you must be connect as a user that is: v defined in the user registry used by WebSphere Application Server for authentication v authorized to perform submit commands in security file stored on the master domain manager. the job streams is launched. if jstreamname is sttrom. alias=name Specifies a unique name to be assigned to the job stream in place of jstreamname. you must use the alias argument to assign a unique name. Wildcard characters are permitted.. if set this value corresponds also to the jobstream_id.alias[=name]] [. The name is always upshifted. it is free from dependencies and it has no at time restriction is defined. the job stream is launched on all qualifying workstations. all qualifying job streams are submitted. You must have submit access to the job stream. a name is constructed using the first alphanumeric characters of jstreamname followed by a six digit random number. jstreamname Specifies the name of the job stream. Wildcard characters are permitted. in which case. You cannot specify a domain or workstation class.

nocheck][.submit sched stream. This option can be used only with . 3.. carryforward deadline=time[timezone | tz tzname][+n days | date] follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][.wait=time][.. 364 IBM Tivoli Workload Scheduler: Reference Guide .. Comments Job streams submitted in production from the conman command line are not included in the preproduction plan and so they cannot be taken into account when identifying external follows dependencies predecessors. When a job stream.schedid. If an at restriction is defined then the value assigned to schedtime is overwritten by the at value.. If no preceding instance of JS_B exists then the predecessor instance is the closest instance of JS_B following JS_A. including those submitted with an alias.] The matching criteria used when submitting job streams in production is different from the way follows dependencies are resolved in the preproduction plan.. When the job stream actually starts then the value assigned to schedtime is overwritten by the actual start time of the job stream.... using sbs. The format used for date depends on the value assigned to the date format variable specified in the localopts file.job | @] | jobstream_id.. The closest instance of JS_B preceding JS_A. Note: The . Its value is then displayed in the SchedTime columns in the output of the show commands.onuntil action] noask Specifies not to prompt for confirmation before taking action against each qualifying job stream.] until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [. for example JS_A. and the instances submitted in production. limit=joblimit needs=[num] [workstation#]resource[. The predecessor job stream instance is searched among the instances added to the production plan when JnextPlan was run.] Note: The local parameters specified in the opens clause are resolved on the workstation from where the job stream is submitted using conman sbs.nocheck is not used.] opens=[workstation#]″filename″[(qualifier)][. 2..nocheck argument is not supported in internetwork dependencies.schedid}| job[. for example JS_B. is submitted from the conman command line program the predecessor instance of JS_B is defined following this criteria: 1..job. Otherwise an error is displayed and the command fails if the keyword . containing a follows dependency from a job or a job stream.. priority[=pri | hi | go] prompt=″[: | !]text″ | promptname[.

or opens. a priority of 23. run the following command: sbs fox4. needs. Examples To submit the adhoc job stream on workstation site1 and flags it as a carryforward job stream.until=0000 To submit job stream sched3 on all workstations with names that start with site. Managing objects in the plan . the default is the workstation of the job stream.carryforward To submit job stream fox4 with a job limit of 2.submit sched If you do not specify a workstation with follows. run the following command: submit sched=site1#adhoc.pri=23. and an until time of midnight. Chapter 9.limit=2.conman 365 . see ″Managing distributed plans″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. run the following command: sbs site@#sched3 See also For the equivalent Job Scheduling Console task.

Syntax switcheventprocessor workstation Arguments workstation Specifies the name of the master domain manager or of the backup master where you want to switch the event processing server. the cached events are lost after the event processing is switched. 366 IBM Tivoli Workload Scheduler: Reference Guide .switcheventprocessor | | | | | | | | | | | | | | | | | | | | switcheventprocessor Switches the event processing server from the master domain manager to the backup master or vice versa. Permission to start and stop actions on cpu objects is required in the security file to be enabled to run this command. The correlation state of pending correlation rule instances is lost whenever the server is switched off or migrated. Comments In case of backup masters the workstation must have the full-status attribute set to on. Note that you can run the event processing server also on a workstation installed as a backup master that runs as a plain fault-tolerant agent. If caching of received events is enabled in the configuration file of the EIF listener. Wildcard characters are not permitted.

Specifies the name of the new domain manager.newmgr Arguments domain newmgr Specifies the domain in which you want to switch managers. The switchmgr command must only be used as part of specific procedures for switching domain management capabilities from a domain manager to its backup domain manager either permanently or temporarily. All domain member workstations are informed of the switch. run the following command: switchmgr bldg2. The next time JnextPlan is run on the old domain manager.conman 367 . Examples To switch the domain manager to workstation orca in the masterdm domain. For information about these procedures. and the old domain manager is converted to a fault-tolerant agent in the domain. Comments The command stops a specified workstation and restarts it as the domain manager. and should be defined beforehand as a fault-tolerant agent with Resolve Dependencies and Full Status enabled. the domain acts as though another switchmgr command had been run and the old domain manager automatically resumes domain management responsibilities.switchmgr switchmgr Switches domain management from the current domain manager to a backup domain manager.ruby Chapter 9. You must have start and stop access to the backup domain manager.orca To switch the domain manager to workstation ruby in the bldg2 domain. This must be a workstation in the same domain. Managing objects in the plan . Syntax switchmgr domain. refer to the IBM Tivoli Workload Scheduler: Administration and Troubleshooting Guide. run the following command: switchmgr masterdm.

system system Runs a system command. run the following command: dir \bin 368 IBM Tivoli Workload Scheduler: Reference Guide . The prefix (: or !) is required only when a command name has the same spelling as a conman command. Syntax [: | !] sys-command Arguments sys-command Specifies any valid system command. run the following command: ps -ef To run a dir command in Windows. Examples To run a ps command in UNIX.

run the following command: tellop TWS will be stopped at\n4:30 for 15 minutes. type two slashes (//) or a period (. * TELLOP>********************************* TELLOP>// Chapter 9. If tellop is entered alone. If issued on a domain manager. If issued on a workstation other than a domain manager. the message is sent only to its domain manager if it is linked. The message can contain up to 900 characters. run the following command: to TELLOP>********************************* TELLOP>* TWS will be stopped at * TELLOP>* 4:30 for 15 minutes. Comments If tellop is issued on the master domain manager. the message is sent to all linked workstations.tellop tellop Sends a message to the Tivoli Workload Scheduler console.). and press the Return key. type each line and press the Return key. Managing objects in the plan . Syntax to [text] Arguments text Specifies the text of the message.conman 369 . the message is sent to all of the linked agents in its domain and subordinate domains. At the end of the message. At the prompt. To prompt for text before sending a message. See “console” on page 279. Examples To send a message. You can use the new line sequence (\n) to format messages. it prompts for the message text. The message is displayed only if the console message level is greater than zero. Typing Control+c at any time will exit the tellop command without sending the message.

workstation noask Specifies the name of the workstation to be unlinked. Note: You must always specify the domain name when unlinking a workstation not in the master domain. Specifies not to prompt for confirmation before taking action on each qualifying workstation. For additional information see “link” on page 295. You must have unlink access to the target workstation. The user cannot unlink workstations in peer domains. v A user running conman on an agent can unlink any workstation in its local domain provided that the workstation is either a domain manager or host. the default domain is the one in which conman is running. the following rules apply: v A user running conman on the master domain manager can unlink any workstation in the network. and workstation includes wildcard characters. DMn are domain managers and Ann are agents. use the following command: unlink stlouis!@ If you do not specify domain. Wildcard characters are permitted.unlink unlink Closes communication links between workstations. Wildcard characters are permitted. to unlink all the agents in domain stlouis. Examples Figure 13 on page 371 and Table 49 on page 371 show the links closed by unlink commands run by users in various locations in the network. It is not necessary to specify the domain name of a workstation in the master domain. v A user running conman on a domain manager other than the master can unlink any workstation in its own domain and subordinate domains. A peer agent in the same domain cannot be unlinked. Comments Assuming that a user has unlink access to the workstations being unlinked.noask] Arguments domain Specifies the name of the domain in which to close links. Syntax unlink [domain!]workstation [. 370 IBM Tivoli Workload Scheduler: Reference Guide . This argument is useful when unlinking more than one workstation in a domain. For example.

Managing objects in the plan . Unlinked workstations Command unlink@!@ Closed by User1 Closed by User2 Closed by User3 DM2-A21 All links are closed DM1-DM2 DM2-A21 DM2-A22 DM2-DM4 DM4-A41 DM4-A42 DM1-A11 DM1-A12 DM1-DM2 DM1-DM3 DM3-A31 DM3-A32 DM4-A41 DM4-A42 DM1-DM2 DM4-A42 DM3-A31 DM1-DM2 DM2-A21 DM2-A22 DM2-DM4 Not allowed DM4-A41 DM4-A42 Not applicable DM4-A42 Not allowed unlink @ DM2-A21 unlink DOMAIN3!@ unlink DOMAIN4!@ unlink DM2 unlink A42 unlink A31 Not allowed Not allowed DM2-A21 Not allowed Not allowed Chapter 9.unlink A11 DM1 A12 Domain1 User1 User3 DM2 A21 A22 Domain2 User2 A31 DM3 A32 Domain3 DM4 Domain4 A41 A42 Figure 13. Unlinked network workstations Table 49.conman 371 .

Batchman LIVES.version version | | Displays the conman program banner.4 (1.Audit Level:0 372 IBM Tivoli Workload Scheduler: Reference Guide .2. duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.Fence:0. 2007 US Government User Restricted Rights Use. inclusive of the version up to the installed fix pack level.22) Licensed Materials Property of IBM 5698-WKB (C) Copyright IBM Corp 1998.36.Limit:19. Job stream (Exp) 11/26/06 (#34) on site3. Syntax version Examples To display the conman program banner. run the following command: %version The output is similar to this: TWS for UNIX/CONMAN 8.

Lists processes. Windows Windows Windows | | evtdef evtsize jobinfo jobstdl listproc killproc © Copyright IBM Corp. Windows UNIX. are installed in the TWS_home/bin directory.4. | | | | | | | | | | What is new in using utility commands This section gives a quick reference to the enhancements in using the utility commands introduced with Tivoli Workload Scheduler version 8. Returns information about a job. Command descriptions Table 50 contains the list of the utility commands. Returns the pathnames of standard list files. Kills processes. This command is not supported. See the following sections for additional details. with the exception of StartUp and version. Imports/exports custom events definitions. List of utility commands Command at batch cpuinfo datecalc delete Description Submits a job to be run at a specific time. Windows UNIX. Returns information from a workstation definition. Operating system UNIX UNIX UNIX. The following utility commands for event rule management have been added : v The evtdef command can be used to change custom event definitions using a supplied generic event provider. and for each command. 2007 373 . This command is not supported. StartUp is installed in the TWS_home directory and version is installed in the TWS_home/version directory. v The sendevent command can be used for sending custom events defined with the evtdef command to the currently active event processor server also from non-Tivoli Workload Scheduler systems. Defines the maximum size of event message files. 1999. Converts date and time to a desired format Removes script files and standard list files by name. Submits a job to be run as soon as possible. These commands. Windows UNIX. its description and the operating systems it supports.Chapter 10. Windows UNIX. Using utility commands This chapter describes Tivoli Workload Scheduler utility commands. Windows UNIX. Table 50. You run utility commands from the operating system command prompt. Windows UNIX.

and adds parameters. Displays the contents of standard list files. Windows UNIX. Operating system UNIX. WebSphere Application Server.Command descriptions Table 50. Windows UNIX. Windows UNIX. List of utility commands (continued) Command maestro makecal metronome. Windows UNIX morestdl parms release rmstdlist sendevent showexec StartUp version 374 IBM Tivoli Workload Scheduler: Reference Guide . Sends generic events to the currently active event processor server. Windows UNIX UNIX. Tivoli Workload Scheduler. Creates custom calendars. Displays information about executing jobs. UNIX. Displays version information.pl Description Returns the Tivoli Workload Scheduler home directory. optionally. Releases units of a resource. Starts the netman process and. Windows Generates an HTML report containing a snapshot of UNIX. Displays. changes. Removes standard list files based on age. Makes a backup copy of the Windows Tivoli Workload Scheduler database. Windows UNIX. Windows UNIX.

Alternatively. End each line of input by pressing the Return key. which can be a single letter (a through z). enter the commands that constitute the job. If the -s and -q arguments are omitted. -s jstream Specifies the jobstream_id of the job stream instance into which the job is submitted. the job stream alias will be the first eight characters of the user’s group name. If ATSCRIPT contains the word maestro.at and batch at and batch Submit ad hoc commands and jobs to be launched by Tivoli Workload Scheduler. or batch (for jobs submitted with batch). the job stream alias will be at (for jobs submitted with at). See “Other considerations” on page 376 for more information about job streams. The entire sequence is ended with end-of-file (usually Control+d). See “Examples” on page 377. It can contain up to 16 characters. time-spec Specifies the time at which the job will be launched.allow and at. If ATSCRIPT is not set. use an angle bracket (<) to read commands from a file. These command runs on UNIX only. The name must start with a letter. Syntax at -v | -u at {-s jstream | -q queue} time-spec batch -v | -u batch [-s jstream] Arguments -v -u Displays the command version and exits. or by entering a line with a period (. See “Other considerations” on page 376 for more information about job streams. and can contain alphanumeric characters and dashes. Displays command usage information and exits.). See at. or is set to a value other than maestro. The following keywords apply only to at jobs: -qqueue Specifies to submit the job into a job stream with the name queue. Chapter 10. a job stream name is selected based on the value of the environment variable ATSCRIPT.deny below for information about the availability to users. it is created a new job stream having jstream both as alias and as jobstream_id. Comments After entering at or batch. If a job stream instance with that jobstream_id does not exist. Using utility commands 375 . The syntax is the same as that used with the UNIX at command.

If the file does not exist. while the current production plan is in process are carried forward to the next production plan. Each job runs in the submitting user’s environment. 376 IBM Tivoli Workload Scheduler: Reference Guide . If the at. Script files: The commands entered with at or batch are stored in script files. Note: Tivoli Workload Scheduler removes script files for jobs that are not carried forward. The names consist of the user’s process ID (PID) preceded by the user’s name truncated so as not to exceed eight characters.sss where: epoch sss The number of seconds since 00:00. see the IBM Tivoli Workload Scheduler Planning and Installation Guide. Do not use the C shell. set commands are inserted into the script to match the variable settings in the user’s environment. only users listed in the file are allowed to use at and batch. 1/1/70. The resulting name is upshifted.allow and /usr/lib/cron/at. The job streams can contain dependencies that determine when the jobs will be launched. the job streams should contain the carryforward keyword. This ensures that jobs that do not complete.allow and at. at. However. The first three characters of the job stream name. only the root user is permitted to use the commands. you should monitor the disk space in the atjobs directory and remove older files if necessary. where the jobs are added to job streams in the production plan. The UNIX shell used for jobs submitted with the Tivoli Workload Scheduler at and batch commands is determined by the SHELL_TYPE variable in the jobmanrc configuration script. Symphony file. The following commands show how to replace the UNIX at and batch commands: $ $ $ $ mv mv ln ln /usr/bin/at /usr/bin/uat /usr/bin/batch /usr/bin/ubatch -s TWShome/bin/at /usr/bin/at -s TWShome/bin/batch /usr/bin/batch The at. For more information. jobs are launched in the same way as other scheduled jobs. Other considerations: v The job streams into which at and batch jobs are submitted should be created beforehand with composer. To ensure that the environment is complete.deny is checked to see if the user is explicitly denied permission. Once submitted.at and batch Information about at and batch jobs is sent to the master domain manager.deny to restrict usage. or are not launched. Job names: All at and batch jobs are given unique names by Tivoli Workload Scheduler when they are submitted.deny files: The at and batch commands use the files /usr/lib/cron/at. Replacing the UNIX commands: The standard UNIX at and batch commands can be replaced by Tivoli Workload Scheduler commands.allow file exists. If neither of the files exists. The jobs are launched based on the dependencies included in the job streams. At a minimum. The file are created by Tivoli Workload Scheduler using the following naming convention: TWS_home/atjobs/epoch.

the value is regarded as for the current day. <Control d> To submit a job to be launched two hours from the time when the command was entered. Chapter 10.. run the following command: at -s sked-mis 17h30 command <Return> . the job is submitted into a job stream having the same name as the user’s group. run the following command: at now + 2 hours command <Return> . the commands are copied from the .. v Use the limit keyword to limit the number of submitted jobs that can be run concurrently... run the following command: batch -s sched8 command <Return> . To submit a job into a job stream instance with jobstream_id sked-mis to be launched at 5:30 p. <Control d> The following command is the same as the previous command. v Use the priority keyword to set the priority of submitted jobs relative to other jobs.m... That is. Using utility commands 377 ./myjob file into a script file./myjob The fact that the commands are read from a file does not change the way they are processed. If the time value is less than the current time. If the time value is greater than the current time. Otherwise. the value is regarded as for the following day.. Examples To submit a job into job stream with jobstream_id sched8 to be launched as soon as possible. except that the job’s commands are read from a file: at -s sked-mis 17h30 < . <Control d> If the variable ATSCRIPT is null.at and batch v Include the expression on everyday to have the job streams selected every day. it is submitted into a job stream named at.

version Returns the Tivoli Workload Scheduler version that is running on the workstation. Displays command usage information and exits. in the same order that the arguments were entered on the command line. WNT. autolink Returns the value of the autolink field: ON or OFF. node port Returns the value of the node field. all applicable information is returned with labels. time_zone Returns the time zone of the workstation. type Returns the type of workstation: MASTER. Returns the value of the port field. one on each line. MANAGER.. Examples The examples below are based on the following workstation definition: 378 IBM Tivoli Workload Scheduler: Reference Guide . Syntax cpuinfo -V | -U cpuinfo workstation [infotype] [. server Returns the value of the server field. the field is blank. one on each line. fullstatus Returns the value of the fullstatus field: ON or OFF. S-AGENT. If no arguments are specified.] Arguments -V -U workstation The name of the workstation. info Returns the operating system version and workstation model. FTA. the field is blank. Comments The values are returned. For an extended agent. For an extended agent. host method Returns the value of the access field. Displays the command version and exits. the field is blank.cpuinfo cpuinfo Returns information from a workstation definition. Specify one or more of the following: os_type Returns the value of the os field: UNIX. and X-AGENT. For an extended agent. infotype The type of information to display. and OTHER.. Returns the value of the host field.

com PORT:51099 SSLPORT: 0 SEC_LEVEL: NONE AUTOLINK:ON FULLSTATUS:ON RESOLVEDEP: ON BEHINDFIREWALL: OFF HOST:oak_wks DOMAIN: MASTERDM METHID: SERVER: TYPE: MASTER TIME ZONE:Europe/Rome VERSION:8.tivoli.cpuinfo Workstation Name Type Domain Updated On Locked By ---------------. run the following command: >cpuinfo oak_wks OS TYPE:UNIX NODE:oak. run the following command: >cpuinfo oak_wks node port oak.com TCPADDR 51099 DOMAIN MASTERDM FOR MAESTRO TYPE MANAGER AUTOLINK ON BEHINDFIREWALL OFF FULLSTATUS ON END To print the node and port for workstation oak.---------. Using utility commands 379 .tivoli.tivoli.21-4.4.---------------.------.com 51099 To print all information for workstation oak.-----------------oak_wks manager MASTERDM 03/04/2006 CPUNAME oak_wks DESCRIPTION "MASTER CPU" OS UNIX NODE oak.3 INFO: Linux 2.ELsmp #1 SMP Fri O i686 Chapter 10.

mar. fr. and yy[yy]. it is possible to enter an ambiguous date. th. sep.3 mar 28 2005 28 3 05 If numbers are used. commas (. nov.7. The slashes (/) can be replaced by dashes (-). tu. for example. aug. may. or dec. or spaces.28. we. Valid values for the month (m[m]) are jan. feb.). datecalc uses the date format defined 380 IBM Tivoli Workload Scheduler: Reference Guide . If two digits are used for the year (yy). periods (.). Displays command usage information and exits. m[m]. and a number less than 70 is a 21st century date. 2.datecalc datecalc Resolves date expressions and returns dates in the format you choose. 2005: 03/28/05 3-28-2005 28. a number greater than 70 is a 20th century date. mo. where element is: d[d]. jul. Valid values are: su. oct. jun. Specifies a date. base-date Specify one of the following: day | date | today | tomorrow | scheddate where: day date Specifies a day of the week. in the format element/element[/element].mar. apr.05 05. Syntax datecalc -V | -U datecalc base-date [offset] [pic format] [freedays Calendar_Name [-sa] [-su]] datecalc -t time [base-date] [offset] [pic format] datecalc yyyymmddhhtt [offset] [pic format] Arguments -V -U Displays the command version and exits. In this case.04. or sa. any of the following can be entered for March 28. For example.

).m. tomorrow Specifies the current system date plus one day. an apostrophe (’). scheddate Specifies the date of the production plan. datecalc generates an error message. h[h][[:]mm] Specifies the hour and minute in 12-hour time (if am or pm are used). or a space. datecalc converts it to the local time. which could be different from the production date of the job stream if the job has an at dependency specified.). When used inside jobs within a carried forward job stream. (or 1200). or. Chapter 10. the n days are not added to the variable TIVOLI_JOB_DATE and therefore. If the date does not match the format. any of the following can be entered for 8:00 p.: 8:00pm 20:00 0800pm 2000 8pm 20 8. This might not be the same as the system date. (or 0000). which could be different from the production date of the carried forward job stream if the job has an at dependency specified.m. it returns the date when the job should have run. a comma (. -t time [base-date] Specify time in one of the following formats: now | noon | midnight | [h[h][[:]mm] [am | pm] [zulu] where: now noon Specifies the current system date and time. The optional colon (:) delimiter can be replaced by a period (. the datecalc command does not report these days. today Specifies the current system date. or 24-hour time. For example. it returns the date when the job should run. Using utility commands 381 .m. the letter h.00pm 20. If the at dependency is used with the following syntax: at=hhmm + n days. Specifies 12:00 p. in the case of time calculations. When used inside jobs within a job stream that is not a carried forward job stream. midnight Specifies 12:00 a.datecalc in the Tivoli Workload Scheduler message catalog to interpret the date. plus 24 hours.00 8\’00pm 20 00 zulu Specifies that the time you entered is Greenwich Mean Time (Universal Coordinated Time).

Valid values are: su. day calendar Specifies the entries in a calendar with this name. month[s] Specifies calendar months. nearest Specifies an offset to the nearest occurrence of the unit type (earlier or later). th. or sa. week[s] Specifies seven days. use < (less than) in UNIX. For example. we. year[s] Specifies calendar years. fr. May 7. workday[s] Same as weekday[s]. hour. Specifies an offset to an earlier date or time. month.| < number | nearest] | next} day[s] | weekday[s] | workday[s] | week[s] | month[s] | year[s] | hour[s] | minute[s] | day | calendar where: +|> Specifies an offset to a later date or time. enter the following: 200505070915 offset Specifies an offset from base-date in the following format: {[+ | > | .(Minus) in Windows. Be sure to add a backslash (\) before the angle bracket (>). Use + (Plus) in Windows. day. 382 IBM Tivoli Workload Scheduler: Reference Guide . 9:15 a. next Specifies the next occurrence of the unit type. -|< number day[s] Specifies every day. but also excludes the dates on the holidays calendar. for 2005. tu. The number of units of the specified type. weekday[s] Specifies every day except Saturday and Sunday. and minute expressed in exactly twelve digits. The format characters are as follows: m Month number. hour[s] Specifies clock hours.m. minute[s] Specifies clock minutes. Use .datecalc yyyymmddhhtt Specifies the year. mo. pic format Specifies the format in which the date and time are returned.. Specifies a day of the week. Be sure to add a backslash (\) before the angle bracket (>). use > (greater than) in UNIX.

Using utility commands 383 . One space. and all the dates listed in Calendar_Name. Use / (slash) in Windows. workdays is evaluated as everyday excluding saturday. >datecalc today +2 days pic mm/dd/yyyy 04/16/2006 >datecalc today next tu pic yyyy\^mm\^dd 2006 04 16 >LANG=american. Minute number. 2006 02:30:00 PM >LANG=french. datecalc returns the date and time in the format defined by the Native Language Support (NLS) environment variables. >datecalc -t now \> 4 hours pic hh:tt 14:24 Chapter 10. By default. run the following command: >datecalc today next monthend In the following examples. the current system time is 10:24.datecalc -t 14:30 tomorrow Samedi 17 avril 2006 14:30:00 In the following example. Hour number. use ^ (carat) in UNIX (add a backslash (\) before the carat (^) if you are in the Bourne shell). You can also specify holidays as the name of the freedays calendar.datecalc d y j h t ^|/ Day number. Examples To return the next date.export LANG >datecalc -t 14:30 tomorrow Sat. saturday and sunday are not regarded as workdays. from today. Year number. If the NLS variables are not defined. These are the same as the delimiters used in date and time. freedays Specifies the name of a freedays calendar Calendar_Name that is to replace holidays in the evaluation of workdays. on the monthend calendar. Julian day number. Apr 17. the current system date is Friday. unless you explicitly state the opposite by adding -sa and -su after Calendar_Name. sunday. If a format is not defined. In this case. 2006. You can also include punctuation characters. April 16. the native language defaults to C.

dashes (-). Other users can remove only files associated with their own jobs. run the following command: delete d:\win32app\maestro\stdlist\2004. The standard configuration script. and Administrator in Windows can remove any file. Even though this command is intended to remove standard list files you are suggested to use the rmstdlist command instead. included in a scheduled job in UNIX..delete delete Removes files..4. slashes (/). For more information about jobmanrc. removes the job’s standard list file if there are no errors: . sets the variable UNISON_STDLIST to the name of the job standard list file. The users maestro and root in UNIX. The name must be enclosed in quotes (″) if it contains characters other than the following: alphanumerics. refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide. Examples To remove all the standard list files for 4/11/04.11\@ The following script.. Displays command usage information and exits. 384 IBM Tivoli Workload Scheduler: Reference Guide . Wildcard characters are permitted. jobmanrc. backslashes (\). #Remove the stdlist for this job: if grep -i error $UNISON_STDLIST then exit 1 else `maestro`/bin/delete $UNISON_STDLIST fi . Syntax delete -V | -U delete filename Arguments -v -u filename Specifies the name of the file or group of files to be removed. Note: Use this command carefully. Displays the command version and exits.. Improper use of wildcard characters can result in removing files accidentally. and underscores (_).

expressed in seconds. username Is the user ID of the user running the command. protocol_name Is the protocol used during the communication. Use this syntax to specify the settings for the connection parameters: [-host hostname] [-port port_number] [-protocol protocol_name] [-proxy proxy_name] [-proxyport proxy_port_number] [-password user_password] [-timeout timeout] [-username username] where: hostname Is the hostname of the master domain manager. Syntax evtdef -U | -V evtdef [connection parameters] dumpdef file-path evtdef [connection parameters] loaddef file-path Arguments -U -V Displays command usage information and exits. proxy_name Is the proxy hostname used in the connection with HTTP.evtdef | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | evtdef Imports/exports a generic event provider XML definition file where you can add and modify custom event types. user_password Is the password of the user running the command. Displays the command version and exits. You can then use the sendevent command to send these events to the event processing server. the connecting command-line program can wait for the master domain manager response before considering the communication request as failed. timeout Is the maximum time. Tivoli Workload Scheduler searches for the value first in the useropts file and then in the localopts file. Using utility commands 385 . If a setting for the parameter is not specified Chapter 10. connection parameters Represents the set of parameters that rule the interaction between the command line and the WebSphere Application Server infrastructure using HTTP or HTTPS. proxy_port_number Is the proxy port number used in the connection with HTTP. It can be HTTP with basic authentication or HTTPS with certificate authentication. port_number Is the port number used when establishing the connection with the master domain manager. If any of these parameters is omitted when invoking the command.

loaddef file-path Uploads the modified generic event provider XML file from the file and path you provide in file-path. You can edit the file to add your own custom event types.</displayDescription> 386 IBM Tivoli Workload Scheduler: Reference Guide .xml 2. The name of the generic event provider supplied with the product is GenericEventPlugIn.0" encoding="UTF-8" ?> -<eventDefinitions xmlns="http://www. Edit the file to add your own event type definitions. Comments The following rule language schemas are used to validate your custom event definitions and. Download the generic event provider XML file as file c:\custom\myevents.</displayDescription> -<property type="string" required="true" wildcardAllowed="true" multipleFilters="true" minlength="1"> <complexName displayName="Parameter 1" name="Param1" /> <displayDescription>The value of parameter 1</displayDescription> </property> -<property type="string" required="true" wildcardAllowed="false" multipleFilters="false" minlength="1> <complexName displayName="Workstation" name="Workstation" /> <displayDescription>The workstation for which the event is generated. Refer to“Setting up options for using the user interfaces” on page 29 for information on useropts and localopts files.com/xmlns/prod/tws/1.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www. to provide syntactic help: v eventDefinitions. The file is downloaded with the file name and path you provide in file-path.w3.0/event-management/plugins/events" xmlns:xsi="http://www.xsd" > -<eventPlugin> <complexName displayName="Custom event" name="GenericEventPlugIn" /> -<scopes> -<scope name="Generic"> <scopedef text="{Param1} on {Workstation}" /> </scope> </scopes> -<!-.xsd The files are located in the schemas subdirectory of the Tivoli Workload Scheduler installation directory.xsd v common.0/event-management/plugins/events eventDefinitions. it looks like this: <?xml version="1.Generic Event --> -<event baseAliasName="genericEvt" scope="Generic"> <complexName displayName="Generic event" name="Event1" /> <displayDescription>The event is sent when the specified expression is matched. dumpdef file-path Downloads the generic event provider XML file.ibm.evtdef | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | either in the connection parameters when invoking the command or inside the useropts and localopts files then an error is displayed.xml evtdef dumpdef c:\custom\myevents. The first time you download the generic event provider file. Examples In this example you: 1.com/xmlns/prod/tws/1. depending upon the XML editor you have.ibm.

Using utility commands 387 .xml Chapter 10. you upload the generic event provider XML file from file c:\custom\myevents.evtdef | | | | | | | | </property> </event> </eventPlugin> </eventDefinitions> 3.xmll evtdef loaddef c:\custom\myevents. When finished.

“End of file on events file. This command is used by the Tivoli Workload Scheduler administrator either to increase the size of a message file after receiving the message. 2006 All rights reserved. You must be maestro or root in UNIX. -show filename Displays the size of the queue of messages contained in the message file filename The name of the event file. or Administrator in Windows to run evtsize.msg 15000000 The following command: evtsize -show Intercom.4) Licensed Materials Property of IBM(R) 5698-WSH (C) Copyright IBM Corp 1998.msg file to 20 MB. run the following command: evtsize Intercom. or to monitor the size of the queue of messages contained in the message file. Specify one of the following: Courier. Examples To set the maximum size of the Intercom.msg pobox/workstation.msg Intercom. Be sure to stop the IBM Tivoli Workload Scheduler engine before running this command.evtsize evtsize Defines the size of the Tivoli Workload Scheduler message files. the maximum size is set to 10 MB.”. Syntax evtsize -V | -U evtsize filename size evtsize -show filename Arguments -V -U Displays the command version and exits.msg Mailbox.2. When first built by Tivoli Workload Scheduler.3 (1. US Government User Restricted Rights 388 IBM Tivoli Workload Scheduler: Reference Guide .msg 20000000 To set the maximum size of the pobox file for workstation chicago to 15 MB. run the following command: evtsize pobox\chicago. as this occurs the message file is emptied.msg returns the following output: Tivoli Workload Scheduler (UNIX)/EVTSIZE 8.msg size The maximum size of the event file in bytes. Note: The size of the message file is equal to or bigger than the real size of the queue of messages it contains and it progressively increases until the queue of messages becomes empty.2. Displays command usage information and exits.

evtsize
Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. IBM is a registered trademark of International Business Machines Corporation in the United States, other countries, or both. AWSDEK703I Queue size current 240, maximum 10000000 bytes (read 48, write 288)

where: 880 10000000 read 48 write 928

Is Is Is Is

the the the the

size of the current queue of the Intercom.msg file maximum size of the Intercom.msg file pointer position to read records pointer position to write records

Chapter 10. Using utility commands

389

jobinfo

jobinfo
Used in a job script to return information about the job.

Syntax
jobinfo -v | -u jobinfo job-option [...]

Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.

job-option The job option. Specify one or more of the following: confirm_job is_command job_name job_pri Returns YES if the job requires confirmation. Returns YES if the job was scheduled or submitted using the docommand construct. Returns the job’s name without the workstation and job stream names. Returns the job’s priority level.

programmatic_job Returns YES if the job was submitted with using the at or batch command. UNIX only. re_job re_type rstrt_flag rstrt_retcode schedule schedule_ia schedule_id time_started Returns YES if the job is being rerun as the result of a conman rerun command, or the rerun recovery option. Returns the job’s recovery option (stop, continue, or rerun). Returns YES if the job is being run as the recovery job. If the current job is a recovery job, returns the return code of the parent job. Returns the name of the job stream where the job is submitted. Returns the time and date the job stream is scheduled to start. Returns the jobstream_ID of the job stream where the job is submitted. Returns the time the job started running.

Comments
Job option values are returned, one on each line, in the same order they were requested.

390

IBM Tivoli Workload Scheduler: Reference Guide

jobinfo

Examples
1. The script file /jcl/backup is referenced twice, giving it the job names partback and fullback. If the job runs as partback, it performs a partial backup. If it runs as fullback, it performs a full backup. Within the script, commands like the following are used to make the distinction:
#Determine partial (1) or full (2): if [ "`\`maestro\`/bin/jobinfo job_name`" = "PARTBACK" ] then bkup=1 else bkup=2 fi ...

2. To display the return code of the parent job, if the current job is a recovery job, run the following command:
$ jobinfo rstrt_retcode

The first job (parent job) has been defined in the script recovery.sh while the second job (recovery job) gets enabled only if the first job abends. When combined with a return code condition, jobinfo rstrt_retcode can be used to direct the recovery job to take different actions depending on the parent job’s return code. A recovery job is shown in the example below:
$JOBS MASTER#DBSELOAD DOCOMMAND "/usr/local/tws/maestro/scripts/populate.sh" STREAMLOGON "^TWSUSER^" DESCRIPTION "populate database manual" RECOVERY RERUN AFTER MASTER#RECOVERY RCCONDSUCC "(RC = 0) OR ((RC > 4) AND (RC < 11))"

Note: The job is defined with the recovery action RERUN. This enables the recovery job to take some corrective action, before the parent job attempts to run again. The recovery job itself is defined as shown in the example below:
$ JOBS MASTER#RECOVERY DOCOMMAND "^TWSHOME^/scripts/recovery.sh" STREAMLOGON "^TWSUSER^" DESCRIPTION "populate database recovery manual" RECOVERY STOP

Chapter 10. Using utility commands

391

jobstdl

jobstdl
Returns the names of standard list files. This command must be run by the user for which Tivoli Workload Scheduler was installed. If you use this command without any parameters, ensure that you are logged on as a Tivoli Workload Scheduler user.

Syntax
jobstdl -v | -u jobstdl [-day num] [{-first | -last | -num n | -all}] [-twslog] [{-name ["jobstreamname [(hhmm date),(jobstream_id)].]jobname" | jobnum | -schedid jobstream_id.jobname}]

Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.

-day num Returns the names of standard list files that are the specified number of days old (1 for yesterday, 2 for the day before yesterday, and so on). The default is zero (today). -first -last -num n Returns the name of the standard list file for the specified run of a job. -all -twslog Returns the path of the current day stdlist file. -name ["jobstreamname[(hhmm date), (jobstream_id)].]jobname" | jobnum Specifies the instance of the job stream and name of the job for which standard list file names are returned. jobnum Specifies the job number of the job for which standard list file names are returned. -schedid jobstream_id.jobname Specifies the job stream ID and name of the job for which standard list file names are returned. Returns the name of all qualifying standard list files. Returns the name of the first qualifying standard list file. Returns the name of the last qualifying standard list file.

Comments
File names are returned in a format suitable for input to other commands. Multiple names are returned separated by a space. The square brackets in the expression [(hhmm date), (jobstream_id)] are part of the command, not syntax indicators. This means that you can supply either of the following for the -name argument:
jobstdl -name ["jobstreamname[(hhmm date),(jobstream_id)].jobname" jobstdl -name jobnum

392

IBM Tivoli Workload Scheduler: Reference Guide

jobstdl
The whole job identification string must be enclosed in double quotes if the part identifying the job stream instance contains blanks. For example, because the schedtime, represented by hhmm date, has a space in it you must enclose the whole job identification in double quotes. If you just want to identify a job name, you do not need the double quotes. The following is an example of the syntax to use when identifying a job both with and without its job stream. In the example, job_stream1 is the name of the job stream, 0600 04/05/06 is the scheduled time, 0AAAAAAAAAAAAAB5 is the job stream ID, and job1 is the job name. You can run the jobstdl command against job1 using either of these two formats:
jobstdl -name "job_stream1[(0600 04/05/06),(0AAAAAAAAAAAAAB5)].job1" jobstdl -name job1

Examples
To return the path names of all standard list files for the current day, run the following command:
jobstdl

To return the path name of the standard list for the first run of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR on the current day, run the following command:
jobstdl -first -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To return the path name of the standard list for the first run of job 0AAAAAAAAAAAAAEE.DIR on the current day, run the following command:
jobstdl -first -schedid 0AAAAAAAAAAAAAEE.DIR

To return the path name of the standard list for the second run of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR on the current day, run the following command:
jobstdl -num 2 -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To return the path names of the standard list files for all runs of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR from three days ago, run the following command:
jobstdl -day 3 -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To return the path name of the standard list for the last run of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR from four days ago, run the following command:
jobstdl -day 4 -last -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To return the path name of the standard list for job number 455, run the following command:
jobstdl 455

To print the contents of the standard list file for job number 455, run the following command:
cd `maestro`/bin lp -p 6 `jobstdl 455`

Chapter 10. Using utility commands

393

maestro

maestro
Returns the path name of the Tivoli Workload Scheduler home directory, referred to as TWS_home.

Syntax
maestro [-v | -u]

Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.

Examples
To display the Tivoli Workload Scheduler home directory, run the following command:
$ maestro /usr/lib/maestro

To change the directory to the Tivoli Workload Scheduler home directory, run the following command:
$ cd `maestro`

394

IBM Tivoli Workload Scheduler: Reference Guide

makecal

makecal
Creates a custom calendar. In UNIX, the Korn shell is required to run this command.

Syntax
makecal [-v | -u] makecal [-c name] -d n | -e | {-f 1 | 2 | 3 -s date} | -l | -m | -p n | {-r n -s date} | -w n [-i n] [-x | -z] [-freedays Calendar_Name [-sa] [-su]]

Arguments
-v -u -c name Specifies a name for the calendar. Tivoli Workload Scheduler keywords (such as Freedays or Schedule) cannot be used as calendar names. The name can contain up to eight alphanumeric characters and must start with a letter. Do not use the names of weekdays for the calendar names. The default name is: Chhmm, where hhmm is the current hour and minute. -d n -e Specifies the nth day of every month. Specifies the last day of every month. Displays the command version and exits. Displays command usage information and exits.

-f 1 | 2 | 3 Creates a fiscal month-end calendar containing the last day of the fiscal month. Specify one of the following formats: 1 2 3 4-4-5 week format 4-5-4 week format 5-4-4 week format

This argument requires the -s argument. -i n -l Specifies to insert n dates in the calendar. Specifies the last workday of every month. For this argument to work properly, the production plan (Symphony file) and the holidays calendar must already exist. Note: Using this argument results in the new calendar also including the last workday of the month that precedes the date of creation of the calendar. -m Specifies the first and fifteenth days of every month.

Chapter 10. Using utility commands

395

makecal
-p n Specifies the workday before the nth day of every month. For this argument to work properly, the production plan (Symphony file) and the holidays calendar must already exist Specifies every nth day. This argument requires the -s argument.

-r n

-s date Specifies the starting date for the -f and -r arguments. The date must be enclosed in quotation marks, and must be valid and unambiguous, for example, use JAN 10 2005, not 1/10/05. See base-date for datecalc on page 380 for more information about date formats. -w n Specifies the workday after the nth of the month. For this argument to work properly, the production plan (Symphony file) and the holidays calendar must already exist. Sends the calendar output to stdout instead of adding it to the database. Adds the calendar to the database and compiles the production plan (Symphony file). Note: This argument re-submits jobs and job streams from the current day’s production plan. It might be necessary to cancel job streams and jobs. -freedays Specifies the name of a freedays calendar Calendar_Name that is to replace holidays in the evaluation of workdays. In this case, workdays is evaluated as everyday excluding saturday, sunday and all the dates listed in Calendar_Name. By default, saturday and sunday are not regarded as workdays, unless you explicitly state the opposite by adding -sa and/or -su after Calendar_Name. You can also specify holidays as the name of the freedays calendar. This keyword affects the processing of makecal with options -l, -p, and -w.

-x -z

Examples
To make a two-year calendar with the last day of every month selected, run the following command:
makecal -e -i 24

To make a calendar with 30 days that starts on May 30, 2005, and has every third day selected, run the following command:
makecal -r 3 -s "30 MAY 2005" -i 30

396

IBM Tivoli Workload Scheduler: Reference Guide

metronome.pl

metronome.pl
It is a PERL Version 5.8.0 script used mainly for troubleshooting and diagnosis purposes. This utility command can be used to get one of the following: v A backup copy of the Tivoli Workload Scheduler configuration files v An HTML report containing a snapshot of Tivoli Workload Scheduler v A backup copy of the Tivoli Workload Scheduler DB2 database It is useful to collect problem determination information to provide to IBM Software Support, if a problem with the product the problem is encountered.

Comments
Refer to IBM Tivoli Workload Scheduler Administration and Troubleshooting Guide for more information about the metronome.pl command.

Chapter 10. Using utility commands

397

morestdl

morestdl
Displays the contents of standard list files. This command must be run by the user for which Tivoli Workload Scheduler was installed. If you use this command without any parameters, ensure that you are logged on as a Tivoli Workload Scheduler user.

Syntax
morestdl -v | -u morestdl [-day num] [-first | -last | -num n | -all] [-twslog] [{-name ["jobstreamname [(hhmm date),(jobstream_id)].]jobname" | jobnum | -schedid jobstream_id.jobname}]

Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.

-day num Displays standard list files that are the specified number of days old (1 for yesterday, 2 for the day before yesterday, and so on). The default is zero (today). -first -last -num n Displays the standard list file for the specified run of a job. -all -twslog Displays the content of the current day stdlist file. -name ["jobstreamname [(hhmm date),(jobstream_id)].]jobname"|jobnum Specifies the instance of the job stream and the name of the job for which the standard list file is displayed. jobnum Specifies the job number of the job for which the standard list file is displayed. -schedid jobstream_id.jobname Specifies the job stream ID and name of the job for which standard list file names are returned. Displays all qualifying standard list files. Displays the first qualifying standard list file. Displays the last qualifying standard list file.

Comments
The square brackets in the expression [(hhmm date), (jobstream_id)] are part of the command, not syntax indicators. This means that you can supply either of the following for the -name argument:
morestdl -name ["jobstreamname[(hhmm date),(jobstream_id)].jobname" morestdl -name jobnum

398

IBM Tivoli Workload Scheduler: Reference Guide

morestdl
The whole job identification string must be enclosed in double quotes if the part identifying the job stream instance contains blanks. For example, because the schedtime, represented by hhmm date, has a space in it you must enclose the whole job identification in double quotes. If you just want to identify a job name, you do not need the double quotes. The following is an example of the syntax to use when identifying a job both with and without its job stream. In the example, job_stream1 is the name of the job stream, 0600 04/05/06 is the scheduled time, 0AAAAAAAAAAAAAB5 is the job stream ID, and job1 is the job name. You can run the morestdl command against job1 using either of these two formats:
morestdl -name "job_stream1[(0600 04/05/06),(0AAAAAAAAAAAAAB5)].job1" morestdl -name job1

Examples
To display the standard list file for the first run of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR on the current day, run the following command:
morestdl -first -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To display the standard list file for the first run of job 0AAAAAAAAAAAAAEE.DIR on the current day, run the following command:
morestdl -first -schedid 0AAAAAAAAAAAAAEE.DIR

To display the standard list file for the second run of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR on the current day, run the following command:
morestdl -num 2 -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To display the standard list files for all runs of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR from three days ago, run the following command:
morestdl -day 3 -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To display the standard list file for the last run of job MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR from four days ago, run the following command:
morestdl -day 4 -last -name "MY_CPU#ELI[(1824 03/09/06),(0AAAAAAAAAAAAAEE)].DIR"

To print the standard list file for job number 455, run the following command:
morestdl 455 | lp -p 6

Chapter 10. Using utility commands

399

parms

parms
Manages parameters defined locally on workstations. Parameters managed by parms can only be used in jobs or job streams definition with the scriptname or opens keywords or in a job script file. These parameters are resolved at submission time on the workstation where the job or job stream is submitted from the conman command line. If there is no match between the specified parametername and the name of the parameters defined in the local database on the workstation then a null value is returned.

Authorization
You must have display access to the locally defined parameters database. In addition you must be authorized with the following access: build on object file If you use the -b option to create or rebuild the local parameters database. delete If you use the -d option to delete parameter definitions.

modify on object file If you use the -replace option to add or modify parameter definitions.

Syntax
parms {[-V | -u] | -build} parms {-replace | -extract} filename parms [-d]parametername parms -c parametername value

Arguments
-V -u Displays the command version and exits. Displays command usage information and exits.

-build Creates the parameters database on the workstation if it does not exist. Rebuilds the parameters database, removing unused records and avoiding fragmentation from numerous additions and deletions, if it already exists. -extract Extracts all parameter definitions from the local database and stores them in the file with name filename. Use this option if you want to export local parameter definitions to import them as global parameter definitions into the scheduling objects database using the “add” on page 203 or the “replace” on page 236 commands. -replace Add in the local database new parameter definitions stored in a file named filename or substitute the already existing ones. Use this option if you want to import, as local parameter definitions, the global parameter definitions contained in the file named filename and extracted from the scheduling objects database using the “create - extract” on page 207 command. -d Deletes the parameters with name parametername from the local database on the workstation.

400

IBM Tivoli Workload Scheduler: Reference Guide

Enclose the value in double quotes if it contains special characters." RECOVERY STOP When used in a job script file. This is a sample usage of a local parameter. If the parameter does not exist. that means replaced by the value assigned to var in the local database. -c name value Specifies the name and the value of a parameter. If the parameter already exists. These are examples on how to use the var parameter in job script files. the parameter is not expanded until the script launches. The value can contain up to 72 characters. it is added to the database." RECOVERY STOP Windows job definition example: BORG#WIN_P_TEST DOCOMMAND "dir ^var^" STREAMLOGON "mae82" DESCRIPTION "Test parms in job definition on Windows. If the job is submitted as an ad hoc job. MYFILE. at submission time and not when the job launches. Using utility commands 401 . UNIX job definition example: DATA#UX_P_TEST DOCOMMAND "ls ^var^" STREAMLOGON "mae82" DESCRIPTION "Test parms in job definition on UNIX./tws/mae82/maestro" export TWS_HOME MDIR=`$TWS_HOME/bin/parms var` export MDIR ls -l $MDIR Windows script example: Chapter 10. When used with the argument -d it represents the name of the parameter to be deleted. UNIX script example: #!/bin/sh TWS_HOME="/opt. Comments When parms is run at the command line without arguments. in a file dependency clause: schedule test_js on everyday opens "/usr/home/tws_99/`/usr/home/tws_99/bin/parms MYFILE`" : test_job end The following example explains how the variable var enclosed by the caret ^ is replaced while the job is in process. its value is changed. it prompts for parameter names and values. The use of parms in either job definitions and job script files requires that the parameter already exists locally in the parameters database on the workstation.parms parametername Specifies the name of the parameter whose value is displayed. It is not expanded when the job stream containing the job is processed by JnextPlan. the parameter var is expanded.

run the following command: parms -c hisparm "item 789" To change the value of myparm and add herparm. run the following command: parms -c myparm "item 123" To create a new parameter named hisparm.parms set TWS_HOME=d:\win32app\TWS\mae82\maestro echo %TWS_HOME% FOR /F "Tokens=*" %%a in (’%TWS_HOME%\bin\parms var’) do set MDIR=%%a echo %MDIR% dir %MDIR% Examples To return the value of myparm. run the following command: parms Name of parameter ? Value of parameter? Name of parameter ? Value of parameter? Name of parameter ? myparm < Return> "item 456" < Return> herparm < Return> "item 123" < Return> < Return> 402 IBM Tivoli Workload Scheduler: Reference Guide . run the following command: parms myparm To change the value of myparm.

If -s is not used. Using utility commands 403 . Displays command usage information and exits. the needs dependency from the specified resource is released at the job level. the script file for jobrel contains the following command: `maestro`/bin/release -s dbase Note: The -s argument can be omitted. two units of the dbase resource are required by job stream sked5: schedule ux1#sked5 on tu needs 2 dbase : job1 jobrel follows job1 job2 follows jobrel end To release the dbase resource before job2 begins. Releases the needs dependency from the specified resource only at the job stream level. because no resources were reserved at the job level. or at the job stream level if the needs dependency from that resource is not found at the job level. Examples In the following job stream. Comments Units of a resource are acquired by a job or job stream at the time it is launched and are released automatically when the job or job stream completes. The release command can be used in a job script to release resources before job or job stream completion or to release manually jobs and job streams from needs dependencies in emergency situations. Chapter 10. The default is the local workstation. This command must be issued only from within the job script file. workstation# Specifies the name of the workstation or workstation class on which the resource is defined.release release Releases jobs and job streams from needs dependencies on a resource. resourcename Specifies the name of the resource involved in the needs dependency. count Specifies the number of units of the resource to be released. Syntax release -v | -u release [-s] [workstation#] resourcename [count] Arguments -v -u -s Displays the command version and exits.

The default is 10 days. you should regularly remove standard list files somewhere between every 10-20 days. This problem might occur on AIX systems. No directories or files are removed. particularly. Remove the redirection to /dev/null so that the line becomes: rm -rf `cat /tmp/rm$$` Examples To display the names of standard list file directories that are more than 14 days old. run the following command: rmstdlist -p 14 To remove all standard list files (and their directories) that are more than seven days old. Locate the script in the TWS_home/bin directory 2. run the following command: rmstdlist 7 404 IBM Tivoli Workload Scheduler: Reference Guide . because of a currently unresolved limitation with the rm -rf command. the dates shown in the list of directories could differ from the dates displayed in the list of files.rmstdlist rmstdlist Removes or displays standard list files based on the age of the file. of standard list file directories to be displayed or removed. the qualifying standard list files are removed. if the number of files becomes exceedingly large. Syntax rmstdlist -v | -u rmstdlist [-p] [age] Arguments -v -u -p Displays the command version and exits. This utility should be used by the Tivoli Workload Scheduler administrator to maintain the scheduling environment. Displays the names of qualifying standard list file directories. in days. The minimum age. | | | | | | | | | | | | | | | | Syntax As a rule. you might be required to erase some of them manually before you can use rmstdlist again. it does not display any errors other than exit code 126. Displays command usage information and exits. When rmstdlist fails because of this limitation. you can edit the rmstdlist script in the following way: 1. Larger backlogs may be harder to manage and. If you would rather have the rm -rf error displayed. age Note: Because the list of directories and files shown or deleted using rmstdlist is produced based on the last time they were accessed. If you do not specify -p. Find the line: rm -rf `cat /tmp/rm$$` 2> /dev/null 3.

Currently. Comments This command can be run also on systems where only the Tivoli Workload Scheduler remote command line client is installed.] Arguments -V Displays the command version and exits.. -port port Specifies the port number of an alternate event processor server other than the currently active one. This parameter is required if the command is launched from a remote command line. Users can override the default destination server (defined by global options) by specifying the host and the port of a new server. Examples In this example an application sends the BusProcCompleted custom event type to an alternate event processor server named master3. sendevent -hostname master3 -port 4294 BusProcCompleted GenericEventPlugIn TransacName=calcweek Workstation=ab5supp Chapter 10. ? | -help | -u | -usage Displays command usage information and exits. This parameter is required if the command is launched from a remote command line.sendevent | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sendevent The command sends the custom events defined with the evtdef command to the event processor server currently active in the production plan. Syntax sendevent -V | ? | -help | -u | -usage sendevent [-hostname hostname][-port port] eventType source [[attribute=value]. attribute=value One or more of the attributes qualifying the custom event type that are specified as the triggering event attributes for the event rule. The event is that file calcweek finished processing. that is: GenericEventPlugIn GenericEventPlugIn must also be specified as the event provider in the definition of the event rules triggered by the custom events. you must specify the name of the generic event provider that you customized with evtdef.. As the events are received by the event processor. eventType One of the custom event types defined with the evtdef command in the generic event provider and specified as the triggering event in an event rule definition. -hostname hostname Specifies the host name of an alternate event processor server other than the currently active one. Using utility commands 405 . they trigger the event rules in which they were specified. source The event originator.

406 IBM Tivoli Workload Scheduler: Reference Guide .sendevent | | | The file name and the associated workstation are the two BusProcCompleted event attributes that were specified as triggering event attributes in an associated event rule.

Displays command usage information and exits.showexec showexec Displays the status of running jobs. Examples To display running jobs in the standard format. The job name. Results The output of the command is available in two formats: standard and INFO. This command is for standard agents. run the following command: showexec INFO Chapter 10. and time. The time the job started running. This command applies to UNIX only. Standard format: CPU Schedule Job Job# User Start Date Start Time (Est) Elapse Info format: CPU Schedule Job Job# JCL The workstation on which the job runs. The file name of the job. Syntax showexec [-v | -u | INFO] Arguments -v -u Displays the command version and exits. The name of the job stream in which the job runs. run the following command: showexec To display running jobs in the INFO format. On domain managers and fault-tolerant agents. The user name of the job. in minutes. use the conman showjobs command instead. The date the job started running. The name of the job stream in which the job runs. date. that the job will run. The workstation on which the job runs. INFO Displays the name of the job file instead of the user. Using utility commands 407 . The job number. The estimated time. The job number. The job name.

Comments Make sure the TWS_user you are using belongs to the Admnistrators group defined on the Windows workstation. Applies to Windows workstations only. Displays command usage information and exits. You must have shutdown access to the workstation. run the following command: shutdown -appsrv 408 IBM Tivoli Workload Scheduler: Reference Guide . and optionally also stops the embedded application server. Displays the command version and exits. Examples To display the command name and version. Syntax shutdown [-v | -u] [-appsrv] Arguments -v -u -appsrv Stops also WebSphere Application Server.shutdown shutdown | | | Stops the Tivoli Workload Scheduler processes. run the following command: shutdown -v To stop both the Tivoli Workload Scheduler processes and WebSphere Application Server.

the StartUp command can be run automatically by invoking it from the /etc/inittab file. Comments In Windows. run the following command: StartUp -v To start the netman process. In UNIX. The remainder of the process tree can be restarted with the conman start conman startmon commands. the netman service is started automatically when a computer is restarted. the Tivoli Workload Scheduler network management process. run the following command: StartUp Chapter 10. StartUp can be used to restart netman if it is stopped for any reason.StartUp StartUp Starts netman. You must have start access to the workstation. Syntax StartUp [-v | -u] Arguments -v -u Displays the command version and exits. StartUp can be used to restart the service if it is stopped for any reason. See conman “start” on page 342 for more information. so that WebSphere Application Server infrastructure and netman is started each time a computer is rebooted. Displays command usage information and exits. Examples To display the command name and version. Using utility commands 409 .

if -a is used. Results The output header contains the product name. The patch level of the file. patch level. On AIX. You can move the version. However.info in the current working directory. you must then include the -f argument to locate the file. The version. or. The default is a file named version. The checksum for the file. This file is placed in the TWS_home/version directory during installation. if any. Displays command usage information and exits. Displays command help information and exits. separated by spaces. The remaining display lists information about the file or files specified. This command applies to UNIX only./version A sample output of this command is: 410 IBM Tivoli Workload Scheduler: Reference Guide . -f vfile Specifies the path and name of the version file if different from the default setting.info file to another directory. sum is used with the -o argument. and installation date. The default is to display no file information. run the following command: .info file is in a specific format and should not be altered. file Specifies the names of product files. Checksum is calculated using the UNIX sum command. version.version version Displays information about the current release of Tivoli Workload Scheduler installed on the system. The size of the file in bytes. The files are listed in the following format: File Revision Patch Size (bytes) Checksum The name of the file. Syntax version -V | -u | -h version [-a] [-f vfile] [file [. Examples To display information about the release of Tivoli Workload Scheduler installed.]] Arguments -V -u -h -a Displays the command version and exits..info file. all file information. operating system.. The revision number of the file. The information is extracted from a version file. for which version information is displayed. Comments Tivoli Workload Scheduler file information is contained in the version. Displays information about all product files. The default is to display information only about the specified files.

version IBM Tivoli Workload Scheduler/VERSION 8.info customize Chapter 10./version customize To display information about the file customize.info is located in /apps/maestro.9) (C) Copyright IBM Corp 1998. Using utility commands 411 .info To display information about the file customize.3 (9.3 UNIX linux-ix86 PATCH February 2006 To display information about all files. run the following command: cd version . 2006 IBM Tivoli Workload Scheduler 8./version -f /apps/maestro/version. run the following command: version/version -a -f version/version. run the following command: cd version . when version.

They can be used if similar Windows utilities are not available.Unsupported commands Unsupported commands The following unsupported utility commands provide functions in Windows that are similar to UNIX ps and kill commands. 412 IBM Tivoli Workload Scheduler: Reference Guide . Syntax listproc killproc pid Comments listproc Displays a tabular listing of processes on the system. killproc Kills the process with the process ID pid. Note: When run by the Administrator. killproc is capable of killing system processes.

/TWS_home/tws_env.cmd in Windows | The report commands must be run from the TWS_home directory.Chapter 11./TWS_home/tws_env. © Copyright IBM Corp.sh for Bourne and Korn shells in UNIX v . These commands are run from the operating system command prompt on the master domain manager. There are: v Historical reports: – Job run history – Job run statistics – Workstation workload summary – Workstation workload runtimes – Custom SQL v Production reports: – Actual production details – Planned production details See “Additional reports available on the Tivoli Dynamic Workload Console” on page 454 and the Tivoli Dynamic Workload Console online documentation for more information. . The default is stdout. The chapter is divided into the following sections: v “What is new in running reports and statistics” v “Setup for using report commands” v “Command descriptions” on page 414 v “Sample report outputs” on page 425 v “Report extract programs” on page 440 v “Additional reports available on the Tivoli Dynamic Workload Console” on page 454 What is new in running reports and statistics This product version supports a set of new reports that can be run on the Tivoli Dynamic Workload Console.csh for C shells in UNIX v TWS_home\tws_env. Setup for using report commands To configure the environment for using report commands set the PATH and TWS_TISDIR variables by running one of the following scripts: v . 1999. The output of the report commands is controlled by the following environment variables: MAESTROLP Specifies the destination of the output of a command. 2007 413 . Getting reports and statistics | | | | | | | | | | | | | | | | | | | | | | | | | | This chapter describes the report commands that let you get summary or detailed information about the previous or next production plan. . You can set it to any of the following: filename Writes the output to a file.

Job Details Listing Report 02 . If it is not set or is set to anything other than LONG.Setup for report commands output > filename UNIX only. The system command is not run if there is no output. See the IBM Tivoli Workload Scheduler Planning and Installation Guide for details on modifying local variables in the localopts file.Parameter Listing Report 04B . Redirects output to a file. >> filename UNIX only. If the file does not exist it is created. long names are truncated to eight characters and a plus sign. MAESTRO_OUTPUT_STYLE Specifies the output style for long object names. If the file does not exist it is created. overwriting the contents of the file. Pipes output to a system command or process. appending to the end of the file. Pipes output to a system command or process. For example: A1234567+. the date format affects all commands that accept a date as an input option (except the datecalc command). | command UNIX only. and the headers in all reports. Command descriptions Tivoli Workload Scheduler report commands are listed in Table 52: Table 52. Redirects output to a file. || command UNIX only. Changing the date format In Tivoli Workload Scheduler.Calendar Listing Report 04A . Set the variable to LONG to use full length (long) fields for object names. To select a different format. List of report commands Command rep1 rep2 rep3 rep4a rep4b Description Report 01 .Prompt Listing Report 03 . Date formats date format value 0 1 2 3 Corresponding date format output yy/mm/dd mm/dd/yy dd/mm/yy Native language support variables. edit the date format local option store in the localopts file. The values are: Table 51. You are suggested to use a fixed font size for correctly managing reports output formatting. The default date format is mm/dd/yy. The system command is always run.Resource Listing 414 IBM Tivoli Workload Scheduler: Reference Guide .

Planned Production Schedule Report Report Report Report Report 09A 09B 09D 10A 10B Planned Production Summary Planned Production Detail Planned Production Detail (Long Names) Actual Production Summary Actual Production Detail xref Report 12 .Job History Listing Report 08 .Cross Reference Report Chapter 11. List of report commands (continued) Command rep7 rep8 rep11 reptr Description Report 07 .Job Histogram Report 11 .Command descriptions Table 52. Getting reports and statistics 415 .

2. 3. Arguments x -u -v A number corresponding to the report.rep4b rep1 . Displays the command version and exits.rep4b These commands print the following reports: Report 01 Job Details Listing Report 02 Prompt Listing Report 03 Calendar Listing Report 04A Parameters Listing Report 04B Resource Listing Syntax rep[x] [-v|-u] | Run the command from the TWS_home directory. on printer lp2: MAESTROLP="| lp -dlp2 -n2" export MAESTROLP rep4a 416 IBM Tivoli Workload Scheduler: Reference Guide .rep1 . 4a. User Parameters Listing. Examples Print Report 03. Comments | | The Job Details Listing (report 01) cannot include jobs that were submitted using an alias name. User Calendar Listing: rep3 Display usage information for the rep2 command: rep2 -u In UNIX. or 4b. Displays the command usage information and exits. print two copies of report 04A. The numbers are: 1.

This option is valid only if you also specify at least one of the -f or -t options. The default is all workstations. Examples Print all job history for workstation ux3: rep7 -c ux3 Print all job history for all jobs in job stream sked25: Chapter 11. the output of the command contains no statistic information. -s jstream_name Specifies the name of the job stream in which the jobs run. The default is all job streams. Enter the date as yyyymmdd. Enter the date as yyyymmdd. -t date Specifies to print job history up to this date. Any time you run rep7 the output of the command contains the information stored until the last time you run JnextPlan. The default is the earliest available date. Getting reports and statistics 417 . Using this option causes the order of output to be reversed: the job summary line will be printed after the individual job run lines. Displays the command version and exits. Arguments -u -v Displays the command usage information and exits.rep7 rep7 This command prints Report 07-Job History Listing. For this reason if you run rep7 after having generated the production plan for the first time or after a ResetPlan command. Comments | The report does not include jobs that were submitted using an alias name. -c wkstat Specifies the name of the workstation on which the jobs run. -j job Specifies the name of the job. The default is all jobs. -f date Specifies to print job history from this date forward. the information related to the run of the current production plan will be contained in the rep7 output the next time you run JnextPlan. -l Limits the summary line information to the jobs which fall in the date range specified by the -f or -t options. The default is the most recent date. Syntax rep7 -v|-u rep7 [-c wkstat] [-s jstream_name] [-j job] [-f date ] [-t date] [-l] | Run the command from the TWS_home directory.

rep7 rep7 -s sked25 Print job history for all jobs in job stream mysked on workstation x15 between 1/21/2005 and 1/25/2005: rep7 -c x15 -s mysked -f 20050121 -t 20050125 418 IBM Tivoli Workload Scheduler: Reference Guide .

Chapter 11. -i file Specifies the name of the log file from which job history is extracted. Comments | The report does not include jobs that were submitted using an alias name. The default is the Tivoli Workload Scheduler startOfDay. -t date Specifies to print job history up to this date.rep8 rep8 This command prints Report 08-Job Histogram. -b time Specifies to print job history from this time forward. -p Specifies to insert a page break after each run date. For this reason if you run rep8 after having generated the production plan for the first time or after a ResetPlan command. Note that log files are stored in the schedlog directory. Arguments -u -v Displays the command usage information and exits. Note: Ensure that the time range specified by the [-f date -b time -t date -e time] arguments is within the date and time range defined in the -i file log file name. -f date Specifies to print job history from this date forward. Getting reports and statistics 419 . -e time Specifies to print job history up to this time. Syntax rep8 -v|-u rep8 [-f date -b time -t date -e time] [-i file] [-p ] rep8 [-b time -e time] [-i file] [-p ] | Run the command from the TWS_home directory. The default is the most recent date. Enter the time as hhmm. the output of the command contains no statistic information. Enter the date as yyyymmdd. Displays the command version and exits. The default is today’s date. Any time you run rep8 the output of the command contains the information stored until the last time you run JnextPlan. The default is the current Symphony file. The default is the Tivoli Workload Scheduler start of day time. the information related to the run of the current production plan will be contained in the rep8 output the next time you run JnextPlan. Enter the date as yyyymmdd. Enter the time as hhmm.

beginning at 6:00 am. from the current plan (Symphony file). on 1/25/2005.m.rep8 Examples Print a job histogram which includes all information in the current plan (Symphony file): rep8 Print a job histogram beginning at 6:00 a. on 1/26/2005: rep8 -f 20050125 -b 0600 -t 20050126 -e 0559 -i schedlog/M199801260601 Print a job histogram. and ending at 5:59 a.m. and ending at 10:00 pm: rep8 -b 0600 -e 2200 420 IBM Tivoli Workload Scheduler: Reference Guide .

-m mm[yy] Specifies the months to be reported. You can also enter a year as yy. and direct output to the file r11out: rep11 -m 06 07 08 -o r11out Report on this month and year for workstation site2: rep11 -c site2 Chapter 11.. Syntax rep11 -v|-u rep11 [-m mm[yy] [. The default is all job streams. Examples Report on June.rep11 rep11 This command prints Report 11-Planned Production Schedule. Arguments -u -v Displays the command usage information and exits.]] [-c wkstat [. Getting reports and statistics 421 . the default is stdout. July.]] [-s jstream_name] [-o file] | Run the command from the TWS_home directory. -c wkstat Specifies the workstations to be reported. and August of 2004 for workstations main. The default is the current month.. and August of this year for all workstations. If MAESTROLP is not set. The default is all workstations. July. -o file Specifies the output file. Displays the command version and exits.. -s jstream_name Specifies the name of the job stream in which the jobs run. site1 and sagent1: rep11 -m 062004 072004 082004 -c main site1 sagent1 Report on June.. The default is the current year or next year if you specify a month earlier than the current month. The default is the file defined by the MAESTROLP variable. Enter the month number as mm.

Displays the command version and exits. both sets of reports are printed. If -summary and -detail are omitted. Specifies to print the pre-production reports (09A and 09B). all pre and post reports are printed. logfile Specifies the name of the log file from which the reports will be printed. The default is Symnew in the current directory. -summary Specifies to print the summary reports (09A and 10A). Arguments -u -v -pre -post Displays the command usage information and exits. The default is the current plan (Symphony file). both sets of reports are printed. Syntax reptr [-v|-u] reptr -pre [-{summary | detail}] [symfile] reptr -post [-{summary | detail}] [logfile] | Run the command from the TWS_home directory. If the command is run with no options. If -summary and -detail are omitted. Note that plan log files are stored in the schedlog directory.reptr reptr This command prints the following reports: Report 09A Planned Production Summary Report 09B Planned Production Detail Report 10A Actual Production Summary Report 10B Actual Production Detail Report 09A and Report 09B refer to future production processing while Report 10A and Report 10B show processing results and status of each single job of already processed production. -detail Specifies to print the detail reports (09B and 10B). Specifies to print the post-production reports (10A and 10B). symfile Specifies the name of the plan file from which reports will be printed. Examples Print the pre-production detail report from the Symnew file: reptr -pre -detail 422 IBM Tivoli Workload Scheduler: Reference Guide .

Getting reports and statistics 423 .reptr Print the pre-production summary report from the file mysym: reptr -pre -summary mysym Print the post-production summary report from the log file M199903170935: reptr -post -summary schedlog/M199903170935 Print all pre and post-production reports. reptr The pre-production reports are based on information read from the Symnew file. Chapter 11. The post-production reports are based on information read from the Symphony file.

-schedules Specifies to print a report showing the job streams and jobs that are successors of each job stream. -when Specifies to print a report showing job stream Include and Exclude dates. If the command is run with no options. information from all qualified workstations is included..]] | Run the command from the TWS_home directory. -files -jobs Specifies to print a report showing the job streams and jobs that are dependent on each file. showing all cross-reference information: xref Print a report for all workstations. Examples Print a report for all workstations. all workstations and all options are selected. Include cross-reference information about all successor dependencies: xref -cpu @ -depends -schedules 424 IBM Tivoli Workload Scheduler: Reference Guide . Syntax xref [-V|-U] xref [-cpu wkstat] [-depends|-files|-jobs|-prompts|-resource|-schedules|-when[.xref xref This command prints Report 12-Cross Reference Report. -cpu wkstat Specifies to print the report for the named workstation. Displays the command version and exits. Arguments -U -V Displays the command usage information and exits. The default is all workstations. in which case. -resource Specifies to print a report showing the job streams and jobs that are dependent on each resource. -depends Specifies to print a report showing the job streams and jobs that are successors of each job. Specifies to print a report showing the job streams in which each job is run. -prompts Specifies to print a report showing the job streams and jobs that are dependent on each prompt. The @ wildcard is permitted..

Sample report outputs Sample report outputs Report 01 . CPU(secs) 0 0 (On 0 (On 0 (On at 00:00) ) ) 0 Aborted ibm Job Details Listing Page 1 03/06/06 #SCHEDDDD Elapsed(mins) 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 : : : : : : : : : : MASTER8+ #JnextPlan ADDED BY composer FOR SCHEDULE MASTER821#FINAL.3 (1.Job Details Listing: TWS for UNIX (AIX)/REPORT1 8. CPU(secs) 0 0 (On 03/05/06 at 22:22) 0 (On 03/05/06) 0 (On 03/05/06) E n d o f R e p o r t * * * * 0 Aborted Elapsed(mins) 00:00:01 00:00:01 00:00:01 00:00:01 00:00:01 * * * * Chapter 11. Getting reports and statistics 425 . pwd ^ACCLOGIN^ root STOP Yes 1 1 Successful. CPU(secs) 44 4 (On 03/05/06 at 23:16) 4 (On 03/04/06) 4 (On 03/04/06) 0 Aborted Elapsed(mins) 00:00:14 00:00:01 00:00:01 00:00:02 00:00:01 : : : : : : : : : : MASTER8+ #JOB1 ADDED BY composer.7) Report 01 Job Description JCL File Logon Creator Recovery Job Recovery Type Recovery Prompt composer Autodoc Total Runs Total Normal Last Run Maximum Minimum Job Description JCL File Logon Creator Recovery Job Recovery Type Recovery Prompt composer Autodoc Total Runs Total Normal Last Run Maximum Minimum Job Description JCL File Logon Creator Recovery Job Recovery Type Recovery Prompt composer Autodoc Total Runs Total Normal Last Run Maximum Minimum : : : : : : : : : : FTAWIN8+ dir maestro_adm root STOP Yes 0 0 Successful. /test/maestro_adm/tws/JnextPlan maestro_adm maestro_adm STOP Yes 11 11 Successful.

Is the name of the user who created the job definition. expressed in seconds. under which the job runs. Last Run Is the Elapsed time recorded during the last run of the job. Job Logon 426 IBM Tivoli Workload Scheduler: Reference Guide . Total Normal Is the average value of CPU time recorded during the ’Total Runs’. Is the identifier of the job. Is the amount of time. Is the sum of CPU time recorded for the ’Total Runs’. Last Run Is the CPU time recorded during the last run of the job. or the command specified in the docommand field to invoke when running the job. CPU (secs) Is the actual time. Is the user name. | | | | | | | | JCL File Maximum Is the maximum among the values collected for Elapsed time during the ’Total Runs' (calculated only for jobs ended successfully). Minimum Is the minimum among the values collected for CPU time during the ’Total Runs’ (calculated only for jobs ended successfully). expressed in minutes. | | | | | | | | Creator Description Elapsed Maximum Is the maximum among the values collected for CPU time during the ’Total Runs’ (calculated only for jobs ended successfully). [workstation#]jobname. Is the textual description of the job set in the description field of the job definition statement. Is the name of the file set in the scriptname field that contains the script to run. Is the sum of Elapsed time recorded for the ’Total Runs’. specified in the streamlogon field. the job made use of the CPU to run.Job Details Listing In the output you see the values set in the “Job definition” on page 119 as follows:: composer Autodoc Says if the job statement was described in the job stream definition using the command line interface. that includes both the time during which the job made use of the CPU and the time the job had to wait for other processes to release the CPU. Total Normal Is the average value of Elapsed time recorded during the ’Total Runs’.Report 01 . Minimum Is the minimum among the values collected for Elapsed time during the ’Total Runs’ (calculated only for jobs ended successfully).

specified as after [workstation#]jobname. continue. Chapter 11. It can be set to stop. Getting reports and statistics 427 . that is displayed if this job abends. Recovery Prompt Is the text of the prompt. specified in the abendprompt field. Recovery Type Is the recovery option set in the job definition. that is run if the parent job abends.Report 01 . or rerun.Job Details Listing Recovery Job Is the job.

428 IBM Tivoli Workload Scheduler: Reference Guide .7) Report 02 Prompt PROMPT1 PROMPT2 CALLNO CALLOPER PERSON2CALL Message Reply YES when ready to run acc103 and acc104.3 (1. Lou Armstrong 5 E n d o f R e p o r t * * * * ibm Prompt Message Listing Page 1 03/06/06 Total number of prompts on file: * * * * The Report 02 output lists the name and the text of the prompts defined in the environment.Report 02 . Have all users logged out? 555-0911 Call ^PERSON2CALL^ at ^CALLNO^ to ensure all time cards have been processed.Prompt Listing: TWS for UNIX (AIX)/REPORT2 8.Prompt Listing Report 02 .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Feb 2006 Sun Mon Tue Wed Thu Fri Sat . . 30 Dec 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . . 30 Jul 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . . . . . . . . . . . . . . . 31 * * * * E n d o f R e p o r t * * * * In the output you see highlighted the end of month days selected in calendar MONTHEND. . . . . . . . . . . . . . . . . . . . . . . . . 31 Jun 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . . . . . . . . . 28 May 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Apr 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . . . . . . . . . . . . . . . . . Jan 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting reports and statistics 429 .Report 03 . . . . . . . . . . . .Calendar Listing Report 03 . . . . . . . . . . . . . .7) Report 03 ibm User Calendar List Page 1 03/06/06 Calendar Type: MONTHEND Description: End of month until end of 2006. . . 31 Aug 2006 Sun Mon Tue Wed Thu Fri Sat . . . 30 Sep 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . 30 Mar 2006 Sun Mon Tue Wed Thu Fri Sat . .3 (1. . .Calendar Listing: TWS for UNIX (AIX)/REPORT3 8. . . . . . Chapter 11. . . . . . . . . . . . . . 31 Nov 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . 31 Oct 2006 Sun Mon Tue Wed Thu Fri Sat . . . . . . . . . . . . . . . . .

Report 04A .3 (1.7) Report 4A Parameter Name ACCHOME ACCLOGIN BADEXIT GOODEXIT SCRPATH Contents /usr/local/Tivoli/maestro_adm maestro_adm 99 0 /usr/local/Tivoli/maestro_adm/scripts 5 E n d o f R e p o r t * * * * ibm User Parameter Listing Page 1 03/06/06 Number of Parameters on file: * * * * The Report 04A output lists the name and the content of the parameters defined in the environment.Parameter Listing: TWS for UNIX (AIX)/REPORT4A 8.Parameter Listing Report 04A . 430 IBM Tivoli Workload Scheduler: Reference Guide .

3 (1.7) Report 4B Resource Name #DATTAPES #QUKTAPES #TAPES #JOBSLOTS 4 E n d o f R e p o r t * * * * ibm TWS Resources Listing Number Avail 1 2 2 1024 Page 1 03/06/06 CPU FTAHP FTAWIN8+ MASTER8+ MASTER8+ Description DAT tape units Quick tape units Tape units Job slots Number of Resources on file: * * * * The Report 04B output lists the name.Report 04B . Chapter 11. Getting reports and statistics 431 .Resource Listing Report 04B .Resource Listing: TWS for UNIX (AIX)/REPORT4B 8. the number of available resources defined in the environment and their description.

13) ibm Job History Listing Elapsed CPU Status Page 1 03/08/06 Job Stream Name Job:MASTER8+#MyJS Runs: Aborted 0 Successful 11 Elapsed Time: Normal 1 Min 1 Max 2 03/03/06 03/03/06 03/03/06 03/03/06 03/03/06 03/03/06 03/05/06 03/06/06 03/06/06 03/06/06 01:46 19:08 19:33 19:37 23:08 05:59 05:59 05:59 21:57 23:16 MASTER8+#JS1 MASTER8+#JS2 MASTER8+#JS3 MASTER8+#JS4 MASTER8+#JS5 MASTER8+#JS_A MASTER8+#JS_G MASTER8+#JS_H MASTER8+#TIMEJ MASTER8+#SLEEPJ Runs: Aborted 0 MASTER8+#JOBS * * * * 1 1 1 1 2 1 1 1 2 1 4 4 4 4 4 4 4 4 4 4 SU SU SU SU SU SU SU SU SU SU Job:MASTER8+#JOB1 03/06/06 22:22 Successful 1 Elapsed Time: Normal 1 Min 1 Max 1 1 0 SU E n d o f R e p o r t * * * * The Report 7 reads the information about job run stored in the database and displays them.Job History Listing: TWS for UNIX (AIX)/REPORT7 8. 432 IBM Tivoli Workload Scheduler: Reference Guide .Job History Listing Report 07 . The possible states for a job are: AB SU DN for failed jobs for successfully completed jobs for submitted jobs whose state is unknown because neither a successful or a failure message has been received yet.Report 07 .3 Report 07 Date Time (1.

Job Histogram Report 08 .Report 08 . 1 5 3 5 1 7 0 5 1 8 3 5 2 0 0 5 2 1 3 5 2 3 0 5 0 0 3 5 0 2 0 5 0 3 3 5 0 5 0 5 0 6 3 5 0 8 0 5 0 9 3 5 1 1 0 5 1 2 3 5 1 4 0 4 Page 1 03/06/05 CF05066+.3 (1.JnextPlan The output of Report 8 shows the time slots during which the jobs run. written top-down. and dots.*. The time slots when the job run are marked by asterisks when the position of the marker is aligned with a time written top-down.Job Histogram: TWS for UNIX (AIX)/REPORT8 8. The numbers at the top of the job histogram are times.03/06/06 14:04 Interval Per Column: 15 minutes 1 4 0 5 Job Name 03/06/06 Stat SU * * * * E n d o f R e p o r t * * * * .7) ibm Report 08 Job Histogram 03/05/06 14:05 . for example the first column 1405 means 2:05PM. Getting reports and statistics 433 . Chapter 11.

for example: Start Time 06:00(03/20/06) The time the job stream is planned to run set in the job stream definition using the schedtime keyword. for example: Start Time 06:00 03/20/06 434 IBM Tivoli Workload Scheduler: Reference Guide . for example: Start Time 06:00{03/20/06} The time the job stream actually started to run. The information displayed is taken from the definitions stored in the Tivoli Workload Scheduler database. and the dependency on other jobs or job streams. and job limit. the list of jobs they contain. The Start Time field in the output of the reports generated by the reptr command shows: A time restriction set in the job stream definition using the at keyword. the time dependencies. if set. If the date is enclosed in parenthesis ().E0000000 23:00(03/06/06) 01:00 Until Page 1 03/06/06 Every Limit Dependencies TESTCROME Schedule MYMST #FINAL 00:00 10 05:59(03/07/06) JnextPlan 00:01 10 Total 00:01 Total 00:34 * * * * E n d o f R e p o r t * * * * The output of Report 9B shows what is in plan to run on the selected date in the Tivoli Workload Scheduler environment. repetition rate. For example. The output shows the job streams that are planned to run on the 6th of March 2006 with their description.3 (1. job stream named iwdske that is planned to run on MYFTA has a follows dependency on job NETAG#EXTERNAL.Report 9B .Planned Production Detail: TWS for UNIX (AIX) REPORTER 8.Planned Production Detail Report 9B .E0000000 that is planned to run on the network agent named NETAG. If the date is enclosed in braces {}. If the date is not enclosed either in braces or in parenthesis.7) ibm Report 09B Symnew Planned Production Detail For 03/06/06 Estimated Job Name Run Time Pri Start Time Schedule NETAG #EXTERNAL E0000000 Total Total Schedule MYFTA #IWDSKE JOBIWD Total Schedule MYMST #TESTSKE TESTCRO+ NEWTEST Total 0 0 00:00 00:00 10 10 00:00 00:29 10 00:01 10 00:29 10 08:30(03/06/06) 00:29 NETAG#EXTERNAL.

The job stream EXTERNAL instead failed on the network agent NETAG and so the IWSKE job stream that has a follows dependency from EXTERNAL job stream remains in the HOLD state. This means that anytime this report command is run during the processing the information displayed reflects the actual status of the planned activity. the 6th of March. because within the job stream run time. The information displayed is taken from copy of the Symphony file that is currently used and updated across the scheduling environment. that means that operator intervention is needed. The job stream TESTSKE. after having started with job ID J11613. instead.Actual Production Detail: TWS for UNIX (AIX) REPORTER 8.Actual Production Detail Report 10B .Report 10B .7) ibm Report 10B Symphony Actual Production Detail For 03/06/06 Estimated Job Name Run Time Priority Start Time Schedule NETAG #EXTERNAL E0000000 Total Schedule MYMST #MONTHSKE GETLOGS Total Schedule MYFTA #IWSKE JOBIWD Total Schedule MYMST #TESTSKE TESTCRO+ NEWTEST Total Schedule MYMST #FINAL JnextPlan Total Total 0 0 00:00 00:02 00:02 00:02 10 10 10 10 00:00 00:29 00:01 00:29 00:30 00:01 00:01 00:01 01:38 * * * * 10 10 10 10 10 00:00 06:01(03/06/06) 00:02 06:01(03/06/06) 00:02 00:02 05:59(03/07/06) 00:00 00:09 0 0 0 HOLD HOLD 0 STUCK #J11613 ABEND HOLD 00:00 06:01(03/06/06) 00:03 06:01(03/06/06) 00:03 00:03 0 #J11612 0 HOLD HOLD SUCC SUCC Page 1 03/07/06 Actual CPU Job Run Time Seconds Number Status EXTRN ERROR E n d o f R e p o r t * * * * The output of Report 10B shows states of the scheduling activities currently running across the Tivoli Workload Scheduler network. is in state STUCK. failed in ABEND state causing the depending job NEWTEST to turn into HOLD state.3 (1. the 7th of March. If you compare this output with the output of Report 9B you see that job stream MONTHSKE has run during the current production day. job TESTCROME. Chapter 11. but is not in plan to run the next day. Getting reports and statistics 435 .

---------------------------------------------------------------------------------------------------Estimated Cpu Time Per Day in Seconds Mon Tue Wed Thu Fri Sat Sun 1 0 7 0 14 0 21 0 28 0 TWS for UNIX (AIX)/REPORT11 8.7) Report 11 Planned Production Schedule for FEB 2006 CPU: FTAWIN8+ Num Est Cpu 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Schedule Jobs Time Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo SCHED1 1 1 * An * between Schedule name and Num Jobs indicates that the schedule has jobs running on other cpus.3 (1. ---------------------------------------------------------------------------------------------------Estimated Cpu Time Per Day in Seconds Mon Tue Wed Thu Fri Sat Sun 1 4 7 4 14 4 21 4 28 4 * * * * E n d o f R e p o r t * * * * 8 4 15 4 22 4 2 4 9 4 16 4 23 4 3 4 10 4 17 4 24 4 4 4 11 4 18 4 25 4 5 4 12 4 19 4 26 4 6 4 13 4 20 4 27 4 Page 2 03/08/06 8 0 15 0 22 0 2 0 9 0 16 0 23 0 3 0 10 0 17 0 24 0 4 0 11 1 18 0 25 0 5 0 12 0 19 0 26 0 6 0 13 0 20 0 27 0 Page 1 03/08/065 436 IBM Tivoli Workload Scheduler: Reference Guide .3 (1.Planned Production Schedule Report 11 .7) Report 11 Planned Production Schedule for FEB 2006 CPU: MASTER8+ Num Est Cpu 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Schedule Jobs Time Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo FINAL 1 4 * * * * * * * * * * * * * * * * * * * * * * * * * * * * An * between Schedule name and Num Jobs indicates that the schedule has jobs running on other cpus.Planned Production Schedule: TWS for UNIX (AIX)/REPORT11 8.Report 11 .

the estimated CPU time used by the job stream to run. In the first line it is displayed the number of jobs the job stream contains. Chapter 11. Getting reports and statistics 437 .Planned Production Schedule The output of Report 11 shows when the job streams are planned to run during the selected month. In the matrix it is displayed for each day of the selected month the estimated CPU time used by that job stream to run.Report 11 . and when the job stream is planned to run.

7) ibm Report 12 Cross Reference Report for Job Names.3 (1.Cross Reference Report Report 12 . 03/08/06 CPU: MASTER8+ WHEN EVERYDAY REQUEST Used by the following schedules: FINAL TMP * * * * E n d o f R e p o r t * * * * xref -jobs TWS for UNIX (AIX)/CROSSREF 8. CPU: FTAWIN8+ Job Name SCHEDDDD Exists in Schedules SCHED1 Page 4 03/08/06 TWS for UNIX (AIX)/CROSSREF 8.7) ibm Report 12 Cross Reference Report for Job Names.3 (1.7) ibm Page 1 Report 12 Cross Reference Report for the ON.3 (1. 03/08/06 CPU: FTAWIN8+ WHEN MONTHEND REQUEST Used by the following schedules: SCHED1 SCHED1 .Report 12 . EXCEPT(*) and FREEDAYS(f) options. EXCEPT(*) and FREEDAYS(f) options.3 (1. In this section you find some samples of output.3 (1.Cross Reference Report: The output of Report 12 shows different information according to the flag used when issuing the xref command. SCHEDDAA TWS for UNIX (AIX)/CROSSREF 8. CPU: MASTER8+ Job Name JnextPlan JOB1 Exists in Schedules FINAL TMP * * * * E n d o f R e p o r t * * * * Page 5 03/08/06 438 IBM Tivoli Workload Scheduler: Reference Guide . xref -when TWS for UNIX (AIX)/CROSSREF 8. 03/08/06 CPU: FTAHP WHEN REQUEST Used by the following schedules: TRFINAL TWS for UNIX (AIX)/CROSSREF 8. EXCEPT(*) and FREEDAYS(f) options.7) ibm Page 3 Report 12 Cross Reference Report for the ON.7) ibm Page 2 Report 12 Cross Reference Report for the ON. For each of these sample the corresponding flag used with the xref command is highlighted.

Report 12 .sh Used by the following: FTAWIN8+#SCHED1 .7) ibm Report 12 Cross Reference Report for File Dependencies.7) ibm Report 12 Cross Reference Report for Prompt Dependencies. CPU: MASTER8+ File Name /root/MY_FILE.Cross Reference Report xref -resource TWS for UNIX (AIX)/CROSSREF 8.7) ibm Report 12 Cross Reference Report for Resource Users. TMP * * * * E n d o f R e p o r t * * * * Page 10 03/08/06 Chapter 11.7) ibm Report 12 Cross Reference Report for Resource Users.7) ibm Report 12 Cross Reference Report for Prompt Dependencies.3 (1. TMP TMP * * * * E n d o f R e p o r t * * * * Page 7 03/08/06 xref -files TWS for UNIX (AIX)/CROSSREF 8.3 (1. CPU: FTAWIN8+ Resource QUKTAPES(N/F) Used by the following: SCHED1 Page 8 03/08/06 TWS for UNIX (AIX)/CROSSREF 8. CPU: MASTER8+ Prompt BADEXIT GOODEXIT User defined text Used by the following: FTAWIN8+#SCHED1 FTAWIN8+#SCHED1 . CPU: MASTER8+ Resource TAPES(N/F) Used by the following: TMP * * * * E n d o f R e p o r t * * * * Page 9 03/08/06 xref -prompts TWS for UNIX (AIX)/CROSSREF 8.3 (1. CPU: FTAWIN8+ Prompt User defined text Used by the following: SCHED1 Page 6 03/08/06 TWS for UNIX (AIX)/CROSSREF 8.3 (1. Getting reports and statistics 439 .3 (1.

Report extract program jbxtract prxtract caxtract paxtract rextract r11xtr xrxtrct Description Used to generate Report 01 . which defines how long object names are handled.Job History Listing Used to generate Report 02 . refer to “Command descriptions” on page 414.Resource Listing Used to generate Report 11 .Cross Reference Report The output of the extract programs is controlled by the MAESTRO_OUTPUT_STYLE variable.Calendar Listing Used to generate Report 04A . For more information on the MAESTRO_OUTPUT_STYLE variable.Planned Production Schedule Used to generate Report 12 . Report extract programs.Parameters Listing Used to generate Report 04B . 440 IBM Tivoli Workload Scheduler: Reference Guide .Report extract programs Report extract programs Data extraction programs are used to generate several of the Tivoli Workload Scheduler reports.Prompt Listing Used to generate Report 03 . The programs are listed in Table 53: Table 53.Job Details Listing and for Report 07 .

If the variable is not set. Syntax jbxtract [-v | -u] [-j job] [-c wkstat] [-f date -t date] [-o file] Arguments -v -u -j job Displays the command version and exits. -t date Specifies to print job history up to this date. Enter the date as yyyymmdd. Table 54. Set the variable to LONG to use full length (long) fields for object names. The default is all workstations. -c wkstat Specifies the workstation of jobs for which extraction is performed. Getting reports and statistics 441 . The default is stdout. Each job record contains tab-delimited. The default is the earliest available date. 1=rerun. long names are truncated to eight characters and a plus sign. Jbxtract output fields Field 1 2 3 4 5 6 7 8 9 10 11 12 13 Description workstation name job name job script file name job description recovery job name recovery option (0=stop. -o file Specifies the output file. variable length fields. 2=continue) recovery prompt text auto-documentation flag (0=disabled. -f date Specifies to print job history from this date forward. Results The MAESTRO_OUTPUT_STYLE variable specifies the output style for long object names. The default is the most recent date. The fields are described Table 54. or is set to anything other than LONG. The default is all jobs.jbxtract jbxtract Extracts information about jobs from the database. Enter the date as yyyymmdd. Specifies the job for which extraction is performed. 1=enabled) job login user name job creator user name number of successful runs number of abended runs total elapsed time of all job runs Max Length (bytes) 16 16 4096 65 16 5 64 5 36 36 5 5 8 Chapter 11. For example: A1234567+. Displays command usage information and exits.

Jbxtract output fields (continued) Field 14 15 16 17 18 19 20 21 22 23 24 25 Description total cpu time of all job runs average elapsed time last run date (yymmdd) last run time (hhmm) last cpu seconds last elapsed time maximum cpu seconds maximum elapsed time maximum run date (yymmdd) minimum cpu seconds minimum elapsed time minimum run date (yymmdd) Max Length (bytes) 8 8 8 8 8 8 8 8 8 8 8 8 Examples To extract information about job myjob on workstation main and direct the output to the file jinfo.jbxtract Table 54. run the following command: jbxtract -j myjob -c main -o jinfo 442 IBM Tivoli Workload Scheduler: Reference Guide .

The default is stdout. Getting reports and statistics 443 . Displays command usage information and exits. Prxtract output fields Field 1 2 Description prompt name prompt value Max Length (bytes) 8 200 Examples To extract information about all prompt definitions and direct the output to the file prinfo. Specifies the output file. variable length fields. Syntax prxtract [-v | -u] [-o file] Arguments -v -u -o file Displays the command version and exits. Results Each prompt record contains tab-delimited. run the following command: prxtract -o prinfo Chapter 11. Table 55.prxtract prxtract Extracts information about prompts from the database. The fields are described in Table 55.

run the following command: caxtract -o cainfo 444 IBM Tivoli Workload Scheduler: Reference Guide . Results Each calendar record contains tab-delimited. Specifies the output file. Table 56. The default is stdout. Caxtract output fields Field 1 2 Description calendar name calendar description Max Length (bytes) 8 64 Examples To extract information about all calendar definitions and direct the output to the file cainfo.caxtract caxtract Extracts information about calendars from the database. Syntax caxtract [-v | -u] [-o file] Arguments -v -u -o file Displays the command version and exits. Displays command usage information and exits. The fields are described in Table 56. variable length fields.

Paxtract output fields Field 1 2 Description parameter name parameter value Max Length (bytes) 8 64 Examples To extract information about all parameter definitions and direct the output to the file painfo. Specifies the output file. Syntax paxtract [-v | -u] [-o file] Arguments -v -u -o file Displays the command version and exits.paxtract paxtract Extracts information about parameters from the database. The default is stdout. Displays command usage information and exits. Results Each parameter record contains tab-delimited. run the following command: paxtract -o painfo Chapter 11. variable length fields. Table 57. Getting reports and statistics 445 . The fields are described in Table 57.

Syntax rextract [-v | -u] [-o file] Arguments -v -u -o file Displays the command version and exits. Results Each resource record contains tab-delimited.rextract rextract Extracts information about resources from the database. The default is stdout. run the following command: rextract -o reinfo 446 IBM Tivoli Workload Scheduler: Reference Guide . Specifies the output file. Rextract output fields Field 1 2 3 4 Description workstation name resource name total resource units resource description Max Length (bytes) 8/16 8 4 72 Examples To extract information about all resource definitions and direct the output to the file reinfo. The fields are described in Table 58. Displays command usage information and exits. variable length fields. Table 58.

optionally. Sa) Max Length (bytes) 16 16 6 6 1 4 2 Examples To extract information about job streams on June 2004 for workstation main. Mo. We. Each job stream record contains tab-delimited. long names are truncated to eight characters and a plus sign. Fr. Th. -m mm[yy] Specifies the month (mm) and.r11xtr r11xtr Extracts information about job streams from the database. Syntax r11xtr [-v | -u] [-m mm[yyyy]] [-c wkstat] [-o file] [-s jstream_name] Arguments -v -u Displays the program version and exits. The default is the current month and year. Table 59. -s jstream_name Specifies the name of the job stream in which the jobs run. The default is all job streams. run the following command: r11xtr -m 0604 -c main Chapter 11. variable length fields. -o file Specifies the output file. Getting reports and statistics 447 . The default is stdout. For example: A1234567+. The default is all workstations. R11xtr output fields Field 1 2 3 4 5 6 7 Description workstation name job stream name job stream date (yymmdd) estimated cpu seconds multiple workstation flag (* means some jobs run on other workstations) number of jobs day of week (Su. Set the variable to LONG to use full length (long) fields for object names. The fields are described in Table 59. Displays program usage information and exits. Results The MAESTRO_OUTPUT_STYLE variable specifies the output style for long object names. Tu. the year (yy) of the job streams. If the variable is not set. -c wkstat Specifies the workstation to be reported. or is set to anything other than LONG.

and direct the output to file r11out. run the following command: r11xtr -m 06 -o r11out 448 IBM Tivoli Workload Scheduler: Reference Guide .r11xtr To extract information about job streams on June of this year for all workstations.

The first contains information about jobs and job streams that are dependent on a job. xresources. xsched. xprompt. Set the variable to LONG to use full length (long) fields for object names. xdep_sched. xjob. The fields are described in Table 60. with no delimiters. xdep_job. The fields are described in Table 61. xfile. Syntax xrxtrct [-v | -u] Arguments -v -u Displays the command version and exits. and xwhen.xrxtrct xrxtrct Extracts information about cross-references from the database. or is set to anything other than LONG. The command output is written to eight files. Getting reports and statistics 449 . Xdep_job output fields (continued) Field 1 Description 08 Length (bytes) 2 Chapter 11. If the variable is not set. xdep_job file: The xdep_job file contains two record types. For example: A1234567+. long names are truncated to eight characters and a plus sign. Table 60. Xdep_job output fields Field 1 2 3 4 5 6 7 8 9 10 11 12 13 Description 03 workstation name job name job stream name not used dependent job stream workstation name dependent job stream name dependent job workstation name dependent job name not used not used not used end-of-record (null) Length (bytes) 2 16 40 16 240 16 16 16 40 6 6 8 1 The second record type contains information about jobs and job streams that are dependent on an internetwork dependency. Displays command usage information and exits. Each dependent job and job stream record contains the fixed length fields. with no delimiters. Table 61. Results The MAESTRO_OUTPUT_STYLE variable specifies the output style for long object names. Each dependent job and job stream record contains fixed length fields.

with no delimiters. Each record contains fixed length fields. Xfile output fields Field 1 2 3 4 5 Description 07 workstation name file name dependent job stream workstation name dependent job stream name Length (bytes) 2 16 256 16 16 450 IBM Tivoli Workload Scheduler: Reference Guide . Each dependent job stream record contains fixed length fields. Xdep_sched output fields Field 1 2 3 4 5 6 7 8 9 10 11 12 Description 02 workstation name job stream name not used dependent job stream workstation name dependent job stream name not used not used not used not used not used end-of-record (null) Length (bytes) 2 16 16 248 16 16 8 8 6 6 8 1 xfile file: The xfile file contains information about jobs and job streams that are dependent on a file. Table 63. The fields are described in Table 63.xrxtrct Table 61. with no delimiters. Table 62. The fields are described in Table 62. Xdep_job output fields (continued) (continued) Field 2 3 4 5 6 7 8 9 10 11 12 Description workstation name job name not used dependent job stream workstation name dependent job stream name dependent job workstation name dependent job name not used not used not used end-of-record (null) Length (bytes) 16 120 128 16 16 16 40 6 6 8 1 xdep_sched file: The xdep_sched file contains information about job streams that are dependent on a job stream.

with no delimiters. Xfile output fields (continued) Field 6 7 8 9 10 11 Description dependent job workstation name dependent job name not used not used not used end-of-record (null) Length (bytes) 16 40 6 6 8 1 xjob file: The xjob file contains information about the job streams in which each job appears. Table 65. with no delimiters.xrxtrct Table 63. Xprompts output fields Field 1 2 3 4 5 6 7 8 9 10 Description 05 workstation name prompt name or text not used dependent job stream workstation name dependent job stream name dependent job workstation name dependent job name not used not used Length (bytes) 2 16 20 236 16 16 16 40 6 6 Chapter 11. Xjob output fields Field 1 2 3 4 5 6 7 8 9 10 11 12 Description 04 workstation name job name not used job stream workstation name job stream name not used not used not used not used not used end-of-record (null) Length (bytes) 2 16 40 248 16 16 8 8 6 6 8 1 xprompt file: The xprompt file contains information about jobs and job streams that are dependent on a prompt. Getting reports and statistics 451 . Each job record contains fixed length fields. Table 64. Each prompt record contains fixed length fields. The fields are described in Table 65. The fields are described in Table 64.

Each resource record contains fixed length fields. Each job stream record contains the following fixed length fields. with no delimiters. Table 66. Table 67. Each job stream record contains fixed length fields. Xsched output fields Field 1 2 3 4 5 6 7 8 9 10 11 12 Description 00 workstation name job stream name not used workstation name (same as 2 above) job stream name (same as 3 above) not used not used not used not used not used end-of-record (null) Length (bytes) 2 16 16 248 16 16 8 8 6 6 8 1 xwhen file: The xwhen file contains information about when job streams will run. The fields are described in Table 66. Xprompts output fields (continued) Field 11 12 Description not used end-of-record (null) Length (bytes) 8 1 xresource file: The xresource file contains information about jobs and job streams that are dependent on a resource. with no 452 IBM Tivoli Workload Scheduler: Reference Guide .xrxtrct Table 65. Xresource output fields Field 1 2 3 4 5 6 7 8 9 10 11 12 Description 06 workstation name resource name not used dependent job stream workstation name dependent job stream name dependent job workstation name dependent job name units allocated not used not used end-of-record (null) Length (bytes) 2 16 8 248 16 16 16 40 6 6 8 1 xsched file: The xsched file contains information about job streams. The fields are described in Table 67. with no delimiters.

Getting reports and statistics 453 . The fields are described in Table 68.xrxtrct delimiters. Table 68. run the following command: xrxtrct Chapter 11. Xwhen output fields Field 1 2 3 4 5 6 7 8 9 10 11 12 13 Description 01 workstation name ON/EXCEPT name or date except flag (*=EXCEPT) not used workstation name job stream name not used not used not used offset num offset unit end-of-record (null) Length (bytes) 2 16 8 1 247 16 16 8 8 6 6 8 1 Examples To extract information about all cross-references.

Canceled. workstation name. v Late jobs v Status (Success. for reruns v Delay indicators v Other historical v Job execution information. v Job name. v Long duration Unknown) and v Rerun indicators external status.xrxtrct | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Additional reports available on the Tivoli Dynamic Workload Console These reports can be run only from the Tivoli Dynamic Workload Console. v Missed deadlines Error. Selection criteria Output content options You can select from the following: v Job name v Workstation (job) v Job stream name v Workstation (job stream) v Scheduled time v Actual start time v Estimated duration v Actual duration v Job number v Started late (delay) v Ended late (delay) v Status v Return code v CPU consumption (not available on Windows workstations) v Logon user v Rerun type v Iteration number v Return code The output is in table view. job stream name. This section provides an overview. and workstation Collects historical job name (job stream). Summary of historical reports Report name Job run history Description Corresponds to Report 07. interval v Include/Exclude Note: The report rerun iterations does not include jobs that were submitted using an alias name. Refer to the Tivoli Dynamic Workload Console online help for details. Helps you wildcard and find: commas to add v Jobs ended in error more values. execution data Each field can be during a time specified using a interval. Historical reports The following table summarizes the historical reports in terms of their: v Functionality v Selection criteria v Output content options Table 69. 454 IBM Tivoli Workload Scheduler: Reference Guide .

Ended late.xrxtrct | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 69. Ended v Late and long late. and Long duration statistics duration v Total runs and Note: The report total reruns does not include jobs that were submitted using an alias name. Long duration) – Minimum and maximum elapsed and CPU times (for successful runs only) – Average duration (for successful runs only) – CPU consumption (not available on Windows workstations) v Report format: – Charts view (pie. Collects job execution Each field can be statistics. Error. v Average duration Started late. maximum elapsed v Percentage of jobs and CPU times in Success. Summary of historical reports (continued) Report name Job run statistics Description Corresponds to Report 01. Chapter 11. bar) – Table view – Include table of contents by job or by workstation v Job name. Getting reports and statistics 455 . and user login. Selection criteria Output content options You can select from the following: v Job details: – Job name – Workstation name – Logon user – Job creator – Description – Script v Job statistics: – Total runs (divided in Successful and Error) – Total of runtime exceptions (Started late. workstation name. Helps you specified using a find: wildcard and v Success/error rates commas to add v Minimum and more values.

necessary capacity v Date ranges or planning adjustments specific days for (workload modeling. Each field the number of jobs can be specified that have run on using a wildcard each workstation. intervals (allows to reuse the same report task for running each day and getting the report of the production of the day before) 456 IBM Tivoli Workload Scheduler: Reference Guide . and workstation v Relative time tuning). Summary of historical reports (continued) Report name Workstation workload summary Description Selection criteria Output content options You can select from the following: v Workstation information granularity arranged by: – Hour – Day – Production day v Information aggregation options: – Provide cumulative and aggregated workstation summary information for all or a desired subset of workstations v Report format: – Charts view (bar. workload filtering. line) – Table view – Include table of contents by date or by workstation Provides data on the v Workstation workload in terms of names. and commas to Helps making the add more values.xrxtrct | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 69.

- - All reports are created in HTML (PDF) or CSV format.xrxtrct | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 69. Custom SQL A wizard helps you define your custom SQL query (only on the database views which you are authorized to access). Each field can be Provides data on the specified using a job runs (time and wildcard and duration) on the commas to add workstations.4 installations). Helps more values. Chapter 11. Selection criteria Output content options You can select from the following: v Information grouped by: – Workstation – Run date – Production day Can be ordered by rerun iteration v Job information: – Job name – Workstation name – Workstation name (Job stream) – Job stream name – Scheduled time – Actual start time – Actual duration – Status – Rerun iteration v Report format: – Charts view (GANNT) – Table view – Include table of contents – Limit the number of jobs in each single chart v Job and workstation names. The resulting report has a table with the column name as specified in the SELECT part of the SQL statement. The body contains the report charts in the selected form. Summary of historical reports (continued) Report name Workstation workload runtimes Description Corresponds to Report 08. making the necessary v Job execution capacity planning interval adjustments v Daily time (workload modeling. Getting reports and statistics 457 . The heading of the output contains the SQL statement. intervals and workstation tuning). Note: The report does not include jobs that were submitted using an alias name. You must have the appropriate security file authorizations for report objects to run these reports (granted by default to the tws_user on fresh Version 8.

xrxtrct | | | | | Production reports The following table summarizes the historical reports in terms of their: v Functionality v Selection criteria v Output content options 458 IBM Tivoli Workload Scheduler: Reference Guide .

v Job stream information: v Job name.xrxtrct | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 70. job stream name name (job). Summary of production reports Report name Actual production details Description Corresponds to Report 10B. Getting reports and statistics 459 . Selection criteria Output content options v Job stream name You can select from the following: and workstation name (job stream). Provides data on current and archived plans. job – Priority stream workstation – Limit (job) – Total jobs v Priority – Status – Internal status – Scheduled start time – Latest start time – Actual start time – Estimated deadline time – Estimated duration – Actual duration – CPU time v Job information: – Job name – Workstation name – Priority – Status – Internal status – Is every job – Is rerun job – CPU time – Job log – Estimated start time – Latest start time – Actual start time – Estimated deadline time – Estimated duration – Actual duration – Rerun code – Job number – Dependencies v Report format: – Flat format – CSV separator Chapter 11. – Job stream name workstation name – Workstation (job).

xrxtrct | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 70. – Job stream name workstation name – Workstation (job). job stream name name (job). information: and forecast plans. Summary of production reports (continued) Report name Planned production details Description Corresponds to Report 9B. v Job Stream Provides data on trial v Job name. job – Priority stream workstation – Limit (job) – Total jobs v Priority – Scheduled start time – Latest start time – Estimated deadline time v Job information: – Job name – Workstation name – Priority – Is every job – Scheduled start time – Latest start time – Estimated deadline time – Estimated duration – Dependencies v Report format: – Flat format – CSV separator You must have the appropriate security file authorizations for report objects to run these reports (granted by default to the tws_user on fresh Version 8.4 installations). Selection criteria Output content options v Job stream name You can select from the following: and workstation name (job stream). 460 IBM Tivoli Workload Scheduler: Reference Guide .

The new labels are indicated by revision bars in Table 72 on page 466. As a consequence. All the at. while all SystemV labels are no longer available. when different time zones are involved: © Copyright IBM Corp. until. The setting takes effect after the next JnextPlan is run. 2007 461 . These are the available settings: | | | | | | no Disable time zone management. The new labels can be used only on this version of Tivoli Workload Scheduler. Enabling time zone management You can enable or disable the management of time zones by modifying the setting assigned to the global option enTimeZone on the master domain manager using the optman command line. At the end of this chapter are two sections each containing a time zone list table.Chapter 12. The 3-character notation is supported for backward compatibility with previous versions of Tivoli Workload Scheduler. The second contains the complete set of time zones with long name notation. for example Europe/Paris as equivalent to ECT (European Central Time). 1999. This means that the values assigned to all timezone keywords in the definitions are ignored. The first shows for each 3-character format time zone name that was already in use and the corresponding default long name notation assigned. and deadline time restrictions are managed individually by each fault-tolerant agent. The variable length notation format is area/city. The chapter is divided in the following sections: v “What is new about managing time zones” v “Enabling time zone management” v “How Tivoli Workload Scheduler manages time zones” on page 462 v “Moving to daylight saving time on” on page 464 v “Moving to daylight saving time off” on page 464 v “General rules” on page 464 v “Backward compatibility time zone table” on page 465 v “Complete table of time zones with variable length notation” on page 466 | | | | | What is new about managing time zones New time zone labels have been added for use with this product version. Managing time zones Tivoli Workload Scheduler supports different time zones. Both the 3-character and the variable length notations are supported. thus ignoring the time zone of the agent scheduling the job or job stream. including the master and the domain managers. Enabling time zones provides you with the ability to manage your workload across a multiple time zone environment.

This means that the values assigned to the timezone settings are used to calculate the time when the jobs and job streams run on the target workstations. the impact is that each agent processes the time dependencies by its own time zone. Based on the level of Tivoli Workload Scheduler you installed on the master domain manager you can decide how the product manages time zones while processing. How Tivoli Workload Scheduler manages time zones When the time zone is enabled. is applied to the different time zones on the two fault-tolerant agents. By default the enTimeZone option is set to yes. While performing plan management activities. jobs. This has no impact however on the scheduling process of the job. and precisely: If you installed Tivoli Workload Scheduler version 8. When the production plan is created or extended. the job stream instances are assigned to workstations where the instance is scheduled to run and the time zone is converted from GMT into the time zone set in the target workstation definition. but defined on a different agent. refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide. you can use time zone settings in workstations. incorrect information is displayed about these time dependencies when looked at from an agent other than the job owner. For more details on how to use the optman command line to manage global options on the master domain manager.3 and Fix Pack 01 and you set the enLegacyStartOfDayEvaluation to no The value assigned to the startOfDay option on the master domain manager is not converted into the local time zone set on each workstation across the network. causing jobs of the same job stream. This is why if you use the conman showsched or conman showjobs commands to see the information about scheduled jobs and job streams you see the time zone values expressed using the time zone set on the workstation where the job or job stream is planned to run. The same time conversion is applied to the job stream JS1 scheduled to run on the three machines and containing an at time dependency at 0745 US/Central time zone. it is 0600 in the local time zone set on each workstation in the network. The time frame that identifies 462 IBM Tivoli Workload Scheduler: Reference Guide . and therefore at different times. This means that if the startOfDay option is set to 0600 on the master domain manager. When the job stream instances are added to the preproduction plan. 2.3 or if you installed Tivoli Workload Scheduler version 8. to run at a different time. Tivoli Workload Scheduler converts the value set for the time zones into objects definitions. The conversions are applied in this order: 1. v For job streams. and job streams definitions. Enable time zone management. set to 0600 on the master domain manager. This also means that the processing day begins at the same hour on all workstations. Figure 14 on page 463 shows you how the start of day.Enabling time zone management | | | | | | | yes v For jobs. the time zone set in the job stream definitions is converted into the GMT time zone and then the external follows dependencies are resolved.

Fault-tolerant agent 2 + 2h US/Eastern TZ (GMT-5) JS1 Master Domain Manager JS1 7:45 a. US/Central start of day 2 a. US/Eastern start of day 6 a. Managing time zones 463 . on all workstations in the network.m.How Tivoli Workload Scheduler manages time zones the new processing day is greyed out in Figure 14. US/Samoa start of day 6 a. but not necessarily at the same hour. US/Central TZ(GMT-7) Fault-tolerant agent 1 JS1 JS1 .m. start of day 6 a.4h US/Samoa TZ (GMT-11) start of day 6 a. Example when start of day conversion is applied Chapter 12.m. This means that if the startOfDay option is set to 0600 on the master domain manager. Example when start of day conversion is not applied If you installed Tivoli Workload Scheduler version 8.m. US/Central TZ(GMT-7) Fault-tolerant agent 1 JS1 JS1 .3 and Fix Pack 01 and you set the enLegacyStartOfDayEvaluation to yes The value assigned to the startOfDay option on the master domain manager is converted into the local time zone set on each workstation across the network. it is converted on each workstation into the corresponding time according to the local time zone set on that workstation. Figure 15 shows you how the start of day. US/Eastern Fault-tolerant agent 2 + 2h US/Eastern TZ (GMT-5) JS1 Master Domain Manager JS1 7:45 a.m.4h start of day 8 a. US/Central Figure 14. The time frame that identifies the new processing day is greyed out in Figure 15.m. set to 0600 on the master domain manager. is applied to the different time zones on the two fault-tolerant agents. This also means that the scheduling day begins at the same moment. It also shows how the timing of the job stream JS1 scheduled to run on the three machines and containing an at time dependency at 0730 US/Central time zone is not modified because of the startOfDay conversion. US/Samoa US/Samoa TZ (GMT-11) Figure 15.m.m.

then the time zone set is the one set on the workstation where the job stream is planned to run. some general rules are applied. the enLegacyStartOfDayEvaluation global option is set to no. JnextPlan can be run at any time and the startOfDay indicates only the moment when the new processing day starts. Moving to daylight saving time on Tivoli Workload Scheduler manages the moving to daylight saving time (DST) when generating the production plan. To maintain consistency with production planning criteria. This means that the date and time to run assigned to jobs and job streams in the plan is already converted into the corresponding date and time with DST on.m. refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide. if free from dependencies. These rules are now described divided by topic: Identifying default time zone settings for jobs and job streams: Within a job stream definition you can set a time zone for the entire job stream and for the jobs contained in the job stream. The reason for doing this is that at 2:00 the clock time is moved one hour ahead because DST is switched on. To manage all possible time zone settings the time zone conversion is made respecting the following criteria: v If a time zone is not set for a job within a job stream. The following example explains how Tivoli Workload Scheduler applies the time conversion when JnextPlan is run to generate or extend the production plan while the time moves to DST. then that job inherits the time zone set on the workstation where the job is planned to run.3 there is no linking between the time set for the startOfDay and the moment when JnextPlan is run. General rules When the time zone is enabled in the Tivoli Workload Scheduler environment. Moving to daylight saving time off Moving to daylight saving time (DST) off. the date and time to run assigned to jobs and job streams in the plan is already converted into the corresponding date and time with DST off. on the systems where Tivoli Workload Scheduler version 8. start immediately because 3:00 is later than their scheduled start time. Because the time conversion is applied when generating or extending the production plan. For more details on how to use the optman command line to manage global options on the master domain manager. By default. Tivoli Workload Scheduler ensures that the job stream instances planned to run during the hour before the time shift backward are run only one time. 464 IBM Tivoli Workload Scheduler: Reference Guide . v If a time zone is not set for a job stream. the clock time is set to one hour earlier with respect to the DST time. then all job streams scheduled to start between 2:00 and 2:59 are set to start at 3:00. If DST is switched on at 3:00 p. regardless of which value is set for the enLegacyStartOfDayEvaluation option.3 and Fix Pack 01 are installed.How Tivoli Workload Scheduler manages time zones Note: Starting from version 8. and so all job streams planned to start between 2:00 and 2:59. These time zones can differ from each other.

Backward compatibility time zone table Long Name GMT UTC Europe/Paris Europe/Istanbul Africa/Cairo Asia/Riyadh Europe/Paris Asia/Yerevan Asia/Karachi Short Name GMT UTC ECT EET ART EAT MET NET PLT Description Greenwich Mean Time Universal Coordinated Time European Central Time Eastern European Time (Arabic) Egypt Standard Time Eastern African Time Middle Europe Time Near East Time Pakistan Lahore Time Relative to GMT GMT GMT GMT+1:00 GMT+2:00 GMT+2:00 GMT+3:00 GMT+1:00 GMT+4:00 GMT+5:00 Chapter 12. The time zone name is case sensitive. Backward compatibility time zone table Table 71 shows for each 3-character format time zone that was in use with the previous versions of the product. Default time zone setting for the master domain manager: If a time zone is not set in the master domain manager definition. Applying an offset to a time zone when scheduling a job stream: If you submit in production a job stream specifying an at dependency with an offset of +n days. As a best practice. To see which time zone is set on the master domain manager you can run the following command: conman showcpu. if a time zone is set in the workstation definition. This is important especially when referring to the time when daylight saving time moving occurs. Table 71. the time specified for the at dependency is automatically converted into the time zone set on the workstation from where the conman command is run. then the time zone used is the one set on the master domain manager. before enabling the time zone management across the Tivoli Workload Scheduler network. set a time zone on each workstation of your Tivoli Workload Scheduler network. Managing time zones 465 .info Using the time zone on extended agents: Extended agents inherit the time zone of the master domain manager. it is the same as the time zone set on the system where the workstation is installed. if you enable time zone management. the default long name notation assigned. Choosing the correct time zone for the workstations: To avoid inconsistencies. Displaying time zone setting in production for an AT time dependency: If you use conman commands sj or ss to display a job or job stream having an at time dependency with a time zone set. then Tivoli Workload Scheduler first adds the offset to the date and then converts the time zone set in the at dependency.General rules v If none of the mentioned time zones is set. it inherits the time zone set on the system where the master domain manager is installed. make sure that.

| | | | | | The new time zone labels that can be used with this version of the product are shown with revision bars. v The new names are not supported by earlier Tivoli Workload Scheduler versions than 8. Backward compatibility time zone table (continued) Long Name Asia/Calcutta Asia/Dacca Asia/Bangkok Asia/Shanghai Asia/Tokyo Australia/Darwin Australia/Sydney Pacific/Guadalcanal Pacific/Fiji Pacific/Apia Pacific/Honolulu America/Anchorage America/Los_ Angeles America/Phoenix America/Denver America/Chicago America/New_York America/ Indianapolis America/Caracas America/St_Johns America/Buenos_ Aires America/Sao_Paulo Atlantic/Cape_Verde Short Name IST BST VST CTT JST ACT AET SST NST MIT HST AST PST PNT MST CST EST IET PRT CNT AGT BET CAT Description India Standard Time Bangladesh Standard Time Vietnam Standard Time China Taiwan Time Japan Standard Time Australia Central Time Australia Eastern Time Solomon Standard Time New Zealand Standard Time Midway Islands Time Hawaii Standard Time Alaska Standard Time Pacific Standard Time Phoenix Standard Time Mountain Standard Time Central Standard Time Eastern Standard Time Indiana Eastern Standard Time Puerto Rico and US Virgin Islands Time Canada Newfoundland Time Argentina Standard Time Brazil Eastern Time Central African Time Relative to GMT GMT+5:30 GMT+6:00 GMT+7:00 GMT+8:00 GMT+9:00 GMT+9:30 GMT+10:00 GMT+11:00 GMT+12:00 GMT-11:00 GMT-10:00 GMT-9:00 GMT-8:00 GMT-7:00 GMT-7:00 GMT-6:00 GMT-5:00 GMT-5:00 GMT-4:00 GMT-3:30 GMT-3:00 GMT-3:00 GMT-1:00 Complete table of time zones with variable length notation Table 72 shows all the supported time zones expressed with variable length notation. and their offset with respect to GMT. Variable length notation time zones list Long Name ACT AET Africa/Abidjan Description Central Standard Time (Northern Territory) Eastern Standard Time (New South Wales) Greenwich Mean Time Relative to GMT GMT+9 GMT+11 GMT 466 IBM Tivoli Workload Scheduler: Reference Guide . Table 72.4. v The SystemV time zones are no longer supported. Note that : v Time zone names are case sensitive.Backward compatibility time zone table Table 71. their descriptions.

Complete table of time zones with variable length notation Table 72. Variable length notation time zones list (continued) Long Name Africa/Accra Africa/Addis_Ababa Africa/Algiers Description Greenwich Mean Time Eastern African Time Central European Time Eastern African Time Eastern African Time Greenwich Mean Time Western African Time Greenwich Mean Time Greenwich Mean Time Central African Time Western African Time Central African Time Eastern European Time Western European Time Central European Time Greenwich Mean Time Greenwich Mean Time Eastern African Time Eastern African Time Western African Time Western European Time Greenwich Mean Time Central African Time Central African Time South Africa Standard Time Eastern African Time Eastern African Time Central African Time Western African Time Western African Time Western African Time Greenwich Mean Time Western African Time Central African Time Central African Time Western African Time Central African Time South Africa Standard Time South Africa Standard Time Relative to GMT GMT GMT+3 GMT+1 GMT+3 GMT+3 GMT GMT+1 GMT GMT GMT+2 GMT+1 GMT+2 GMT+2 GMT GMT+1 GMT GMT GMT+3 GMT+3 GMT+1 GMT GMT GMT+2 GMT+2 GMT+2 GMT+3 GMT+3 GMT+2 GMT+1 GMT+1 GMT+1 GMT GMT+1 GMT+2 GMT+2 GMT+1 GMT+2 GMT+2 GMT+2 | Africa/Asmara Africa/Asmera Africa/Bamako Africa/Bangui Africa/Banjul Africa/Bissau Africa/Blantyre Africa/Brazzaville Africa/Bujumbura Africa/Cairo Africa/Casablanca Africa/Ceuta Africa/Conakry Africa/Dakar Africa/Dar_es_Salaam Africa/Djibouti Africa/Douala Africa/El_Aaiun Africa/Freetown Africa/Gaborone Africa/Harare Africa/Johannesburg Africa/Kampala Africa/Khartoum Africa/Kigali Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Lome Africa/Luanda Africa/Lubumbashi Africa/Lusaka Africa/Malabo Africa/Maputo Africa/Maseru Africa/Mbabane Chapter 12. Managing time zones 467 .

Complete table of time zones with variable length notation Table 72. Variable length notation time zones list (continued) Long Name Africa/Mogadishu Africa/Monrovia Africa/Nairobi Africa/Ndjamena Africa/Niamey Africa/Nouakchott Africa/Ouagadougou Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek AGT America/Adak America/Anchorage America/Anguilla America/Antigua America/Araguaina Description Eastern African Time Greenwich Mean Time Eastern African Time Western African Time Western African Time Greenwich Mean Time Greenwich Mean Time Western African Time Greenwich Mean Time Greenwich Mean Time Eastern European Time Central European Time Western African Time Argentine Time Hawaii-Aleutian Standard Time Alaska Standard Time Atlantic Standard Time Atlantic Standard Time Brazil Time Argentine Time Argentine Time Argentine Time Argentine Time Argentine Time Argentine Time Argentine Time Argentine Time Argentine Time Argentine Time Argentine Time Atlantic Standard Time Relative to GMT GMT+3 GMT GMT+3 GMT+1 GMT+1 GMT GMT GMT+1 GMT GMT GMT+2 GMT+1 GMT+2 GMT-3 GMT-10 GMT-9 GMT-4 GMT-4 GMT-2 GMT-3 GMT-3 GMT-3 GMT-3 GMT-3 GMT-3 GMT-3 GMT-3 GMT-3 GMT-3 GMT-3 GMT-4 | | | | | | | | | | | | | | | | | | | | | | America/Argentina/ Buenos_Aires America/Argentina/ Catamarca America/Argentina/ ComodRivadavia America/Argentina/ Cordoba America/Argentina/ Jujuy America/Argentina/ La_Rioja America/Argentina/ Mendoza America/Argentina/ Rio_Gallegos America/Argentina/ San_Juan America/Argentina/ Tucuman America/Argentina/ Ushuaia America/Aruba 468 IBM Tivoli Workload Scheduler: Reference Guide .

Managing time zones 469 .Complete table of time zones with variable length notation Table 72. Variable length notation time zones list (continued) Long Name America/Asuncion Description Paraguay Time Eastern Standard Time Hawaii-Aleutian Standard Time Brazil Time Atlantic Standard Time Brazil Time Central Standard Time Eastern Standard Time Amazon Standard Time Colombia Time Mountain Standard Time Argentine Time Mountain Standard Time Central Standard Time Venezuela Time Argentine Time French Guiana Time Eastern Standard Time Central Standard Time Mountain Standard Time Argentine Time Relative to GMT GMT-3 GMT-5 GMT-10 GMT-3 GMT-4 GMT-3 GMT-6 GMT-5 GMT-4 GMT-5 GMT-7 GMT-3 GMT-7 GMT-6 GMT-4 GMT-3 GMT-3 GMT-5 GMT-6 GMT-7 GMT-3 GMT-5 GMT-6 GMT-3 GMT-4 GMT GMT-8 GMT-7 GMT-7 GMT-5 GMT-4 GMT-7 GMT-5 GMT-6 GMT-8 GMT-5 GMT-3 GMT-4 | | America/Atikokan America/Atka America/Bahia America/Barbados America/Belem America/Belize | America/Blanc-Sablon America/Boa_Vista America/Bogota America/Boise America/Buenos_Aires America/Cambridge_ Bay America/Cancun America/Caracas America/Catamarca America/Cayenne America/Cayman America/Chicago America/Chihuahua America/Cordoba | America/Coral_Harbour Eastern Standard Time America/Costa_Rica America/Cuiaba America/Curacao Central Standard Time Amazon Standard Time Atlantic Standard Time America/Danmarkshavn Greenwich Mean Time America/Dawson Pacific Standard Time America/Dawson_Creek Mountain Standard Time America/Denver America/Detroit America/Dominica America/Edmonton America/Eirunepe America/El_Salvador America/Ensenada America/Fort_Wayne America/Fortaleza America/Glace_Bay Mountain Standard Time Eastern Standard Time Atlantic Standard Time Mountain Standard Time Acre Time Central Standard Time Pacific Standard Time Eastern Standard Time Brazil Time Atlantic Standard Time Chapter 12.

Complete table of time zones with variable length notation Table 72. Variable length notation time zones list (continued) Long Name America/Godthab America/Goose_Bay America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Hermosillo America/Indiana/ Indianapolis America/Indiana/Knox America/Indiana/ Marengo Description Western Greenland Time Atlantic Standard Time Eastern Standard Time Atlantic Standard Time Atlantic Standard Time Central Standard Time Ecuador Time Guyana Time Atlantic Standard Time Central Standard Time Mountain Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Mountain Standard Time Eastern Standard Time Eastern Standard Time Argentine Time Alaska Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Bolivia Time Peru Time Pacific Standard Time Eastern Standard Time Brazil Time Central Standard Time Amazon Standard Time Relative to GMT GMT-3 GMT-4 GMT-5 GMT-4 GMT-4 GMT-6 GMT-5 GMT-4 GMT-4 GMT-5 GMT-7 GMT-5 GMT-5 GMT-5 GMT-5 GMT-5 GMT-5 GMT-5 GMT-5 GMT-7 GMT-5 GMT-5 GMT-3 GMT-9 GMT-5 GMT-5 GMT-5 GMT-4 GMT-5 GMT-8 GMT-5 GMT-3 GMT-6 GMT-4 | | America/Indiana/ Petersburg America/Indiana/ Vevay | | | | America/Indiana/ Vincennes America/Indiana/ Winamac America/Indianapolis America/Inuvik America/Iqaluit America/Jamaica America/Jujuy America/Juneau America/Kentucky/ Louisville America/Kentucky/ Monticello America/Knox_IN America/La_Paz America/Lima America/Los_Angeles America/Louisville America/Maceio America/Managua America/Manaus 470 IBM Tivoli Workload Scheduler: Reference Guide .

Managing time zones 471 . Variable length notation time zones list (continued) Long Name America/Martinique America/Mazatlan America/Mendoza America/Menominee America/Merida America/Mexico_City America/Miquelon Description Atlantic Standard Time Mountain Standard Time Argentine Time Central Standard Time Central Standard Time Central Standard Time Pierre & Miquelon Standard Time Atlantic Standard Time Central Standard Time Uruguay Time Eastern Standard Time Atlantic Standard Time Eastern Standard Time Eastern Standard Time Eastern Standard Time Alaska Standard Time Fernando de Noronha Time Central Standard Time Central Standard Time Relative to GMT GMT-4 GMT-7 GMT-3 GMT-6 GMT-6 GMT-6 GMT-3 GMT-4 GMT-6 GMT-3 GMT-5 GMT-4 GMT-5 GMT-5 GMT-5 GMT-9 GMT-2 GMT-6 GMT-6 | America/Moncton America/Monterrey America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Nipigon America/Nome America/Noronha America/ North_Dakota/ Center | | | America/ North_Dakota/ New_Salem America/Panama America/Pangnirtung America/Paramaribo America/Phoenix America/Port_of_Spain America/Port-au-Prince America/Porto_Acre America/Porto_Velho America/Puerto_Rico America/Rainy_River America/Rankin_Inlet America/Recife America/Regina Eastern Standard Time Eastern Standard Time Suriname Time Mountain Standard Time Atlantic Standard Time Eastern Standard Time Acre Time Amazon Standard Time Atlantic Standard Time Central Standard Time Eastern Standard Time Brazil Time Central Standard Time Central Standard Time Acre Time Argentine Time Chile Time GMT-5 GMT-5 GMT-3 GMT-7 GMT-4 GMT-5 GMT-5 GMT-4 GMT-4 GMT-6 GMT-6 GMT-3 GMT-6 GMT-6 GMT-5 GMT-3 GMT-3 | America/Resolute America/Rio_Branco America/Rosario America/Santiago Chapter 12.Complete table of time zones with variable length notation Table 72.

Variable length notation time zones list (continued) Long Name America/Santo_ Domingo America/Sao_Paulo America/Scoresbysund America/Shiprock America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Swift_Current America/Tegucigalpa America/Thule America/Thunder_Bay America/Tijuana America/Tortola Description Atlantic Standard Time Brazil Time Eastern Greenland Time Mountain Standard Time Newfoundland Standard Time Atlantic Standard Time Atlantic Standard Time Atlantic Standard Time Atlantic Standard Time Central Standard Time Central Standard Time Atlantic Standard Time Eastern Standard Time Pacific Standard Time Atlantic Standard Time Central Standard Time Pacific Standard Time Atlantic Standard Time Pacific Standard Time Central Standard Time Alaska Standard Time Mountain Standard Time Western Standard Time (Australia) Davis Time Dumont-d’Urville Time Mawson Time New Zealand Standard Time Chile Time Rothera Time New Zealand Standard Time Syowa Time Vostok Time Central European Time Eastern European Time Arabia Standard Time Alma-Ata Time Eastern European Time Anadyr Time Relative to GMT GMT-4 GMT-2 GMT-1 GMT-7 GMT-3 GMT-4 GMT-4 GMT-4 GMT-4 GMT-6 GMT-6 GMT-4 GMT-5 GMT-8 GMT-4 GMT-6 GMT-8 GMT-4 GMT-8 GMT-6 GMT-9 GMT-7 GMT+8 GMT+7 GMT+10 GMT+6 GMT+13 GMT-3 GMT-3 GMT+13 GMT+3 GMT+6 GMT+1 GMT+2 GMT+3 GMT+6 GMT+2 GMT+12 | America/Toronto America/Vancouver America/Virgin America/Whitehorse America/Winnipeg America/Yakutat America/Yellowknife Antarctica/Casey Antarctica/Davis Antarctica/Dumont DUrville Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer Antarctica/Rothera Antarctica/South_Pole Antarctica/Syowa Antarctica/Vostok Arctic/Longyearbyen ART Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr 472 IBM Tivoli Workload Scheduler: Reference Guide .Complete table of time zones with variable length notation Table 72.

Complete table of time zones with variable length notation Table 72. Variable length notation time zones list (continued) Long Name Asia/Aqtau Asia/Aqtobe Asia/Ashgabat Asia/Ashkhabad Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Choibalsan Asia/Chongqing Asia/Chungking Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dhaka Asia/Dili Asia/Dubai Asia/Dushanbe Asia/Gaza Asia/Harbin Asia/Hong_Kong Asia/Hovd Asia/Irkutsk Asia/Istanbul Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Kashgar Asia/Katmandu Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuching Description Aqtau Time Aqtobe Time Turkmenistan Time Turkmenistan Time Arabia Standard Time Arabia Standard Time Azerbaijan Time Indochina Time Eastern European Time Kirgizstan Time Brunei Time India Standard Time Choibalsan Time China Standard Time China Standard Time Sri Lanka Time Bangladesh Time Eastern European Time Bangladesh Time East Timor Time Gulf Standard Time Tajikistan Time Eastern European Time China Standard Time Hong Kong Time Hovd Time Irkutsk Time Eastern European Time West Indonesia Time East Indonesia Time Israel Standard Time Afghanistan Time Petropavlovsk-Kamchatski Time Pakistan Time China Standard Time Nepal Time Krasnoyarsk Time Malaysia Time Malaysia Time Relative to GMT GMT+4 GMT+5 GMT+5 GMT+5 GMT+3 GMT+3 GMT+4 GMT+7 GMT+2 GMT+5 GMT+8 GMT+5 GMT+9 GMT+8 GMT+8 GMT+6 GMT+6 GMT+2 GMT+6 GMT+9 GMT+4 GMT+5 GMT+2 GMT+8 GMT+8 GMT+7 GMT+8 GMT+2 GMT+7 GMT+9 GMT+2 GMT+4 GMT+12 GMT+5 GMT+8 GMT+5 GMT+7 GMT+8 GMT+8 Chapter 12. Managing time zones 473 .

Variable length notation time zones list (continued) Long Name Asia/Kuwait Asia/Macao Asia/Macau Asia/Magadan Asia/Makassar Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novosibirsk Asia/Omsk Asia/Oral Asia/Phnom_Penh Asia/Pontianak Asia/Pyongyang Asia/Qatar Asia/Qyzylorda Asia/Rangoon Asia/Riyadh Description Arabia Standard Time China Standard Time China Standard Time Magadan Time Central Indonesia Time Philippines Time Gulf Standard Time Eastern European Time Novosibirsk Time Omsk Time Oral Time Indochina Time West Indonesia Time Korea Standard Time Arabia Standard Time Qyzylorda Time Myanmar Time Arabia Standard Time Arabia Standard Time Arabia Standard Time Arabia Standard Time Indochina Time Sakhalin Time Turkmenistan Time Korea Standard Time China Standard Time Singapore Time China Standard Time Uzbekistan Time Georgia Time Iran Standard Time Israel Standard Time Bhutan Time Bhutan Time Japan Standard Time Central Indonesia Time Ulaanbaatar Time Ulaanbaatar Time China Standard Time Relative to GMT GMT+3 GMT+8 GMT+8 GMT+11 GMT+8 GMT+8 GMT+4 GMT+2 GMT+6 GMT+6 GMT+4 GMT+7 GMT+7 GMT+9 GMT+3 GMT+6 GMT+6 GMT+3 GMT+3 GMT+3 GMT+3 GMT+7 GMT+10 GMT+5 GMT+9 GMT+8 GMT+8 GMT+8 GMT+5 GMT+4 GMT+3 GMT+2 GMT+6 GMT+6 GMT+9 GMT+8 GMT+8 GMT+8 GMT+8 | | | Asia/Riyadh87 Asia/Riyadh88 Asia/Riyadh89 Asia/Saigon Asia/Sakhalin Asia/Samarkand Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Tel_Aviv Asia/Thimbu Asia/Thimphu Asia/Tokyo Asia/Ujung_Pandang Asia/Ulaanbaatar Asia/Ulan_Bator Asia/Urumqi 474 IBM Tivoli Workload Scheduler: Reference Guide .Complete table of time zones with variable length notation Table 72.

Time Eastern Standard Time (New South Wales) Central Standard Time (South Australia) Eastern Standard Time (Queensland) Central Standard Time (South Australia/New South Wales) Eastern Standard Time (New South Wales) Eastern Standard Time (Tasmania) Central Standard Time (Northern Territory) Western Standard Time (Australia) Eastern Standard Time (Tasmania) Load Howe Standard Time Eastern Standard Time (Queensland) Load Howe Standard Time Eastern Standard Time (Victoria) Central Standard Time (Northern Territory) Eastern Standard Time (New South Wales) Western Standard Time (Australia) Eastern Standard Time (Queensland) Central Standard Time (South Australia) Eastern Standard Time (New South Wales) Eastern Standard Time (Tasmania) Relative to GMT GMT+7 GMT+10 GMT+9 GMT+5 GMT+4 GMT-9 GMT-1 GMT-4 GMT GMT-1 GMT GMT GMT+1 GMT GMT GMT-2 GMT GMT-3 GMT+11 GMT+10 GMT+10 GMT+10 GMT+11 GMT+11 GMT+8:.Complete table of time zones with variable length notation Table 72.45 GMT+11 GMT+11 GMT+11 GMT+10 GMT+11 GMT+11 GMT+9 GMT+11 GMT+8 GMT+10 GMT+10 GMT+11 GMT+11 | Atlantic/Faroe Atlantic/Jan_Mayen Atlantic/Madeira Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley Australia/ACT Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Canberra | | Australia/Currie Australia/Darwin Australia/Eucla Australia/Hobart Australia/LHI Australia/Lindeman Australia/Lord_Howe Australia/Melbourne Australia/North Australia/NSW Australia/Perth Australia/Queensland Australia/South Australia/Sydney Australia/Tasmania Chapter 12. Variable length notation time zones list (continued) Long Name Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yekaterinburg Asia/Yerevan AST Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Description Indochina Time Vladivostok Time Yakutsk Time Yekaterinburg Time Armenia Time Alaska Standard Time Azores Time Atlantic Standard Time Western European Time Cape Verde Time Western European Time Western European Time Eastern Greenland Time Western European Time Greenwich Mean Time South Georgia Standard Time Greenwich Mean Time Falkland Is. Managing time zones 475 .

Variable length notation time zones list (continued) Long Name Australia/Victoria Australia/West Australia/Yancowinna BET Brazil/Acre Brazil/DeNoronha Brazil/East Brazil/West BST Canada/Atlantic Canada/Central Canada/Eastern Canada/EastSaskatchewan Canada/Mountain Canada/Newfoundland Canada/Pacific Canada/Saskatchewan Canada/Yukon CAT CET Chile/Continental Chile/EasterIsland CNT CST CST6CDT CTT Cuba EAT ECT EET Egypt Eire EST EST5EDT Description Eastern Standard Time (Victoria) Western Standard Time (Australia) Central Standard Time (South Australia/New South Wales) Brazil Time Acre Time Fernando de Noronha Time Brazil Time Amazon Standard Time Bangladesh Time Atlantic Standard Time Central Standard Time Eastern Standard Time Central Standard Time Mountain Standard Time Newfoundland Standard Time Pacific Standard Time Central Standard Time Pacific Standard Time Central African Time Central European Time Chile Time Easter Is.Complete table of time zones with variable length notation Table 72. Time Newfoundland Standard Time Central Standard Time Central Standard Time China Standard Time Central Standard Time Eastern African Time Central European Time Eastern European Time Eastern European Time Greenwich Mean Time Eastern Standard Time Eastern Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Relative to GMT GMT+11 GMT+8 GMT+10 GMT-2 GMT-5 GMT-2 GMT-2 GMT-4 GMT+6 GMT-4 GMT-6 GMT-5 GMT-6 GMT-7 GMT-3 GMT-8 GMT-6 GMT-8 GMT+2 GMT+1 GMT-3 GMT-5 GMT-3 GMT-6 GMT-6 GMT+8 GMT-5 GMT+3 GMT+1 GMT+2 GMT+2 GMT GMT-5 GMT-5 GMT GMT-0 GMT-1 GMT-10 | | | | Etc/GMT Etc/GMT-0 Etc/GMT-1 Etc/GMT-10 476 IBM Tivoli Workload Scheduler: Reference Guide .

Managing time zones 477 . Variable length notation time zones list (continued) Long Name Description Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Greenwich Standard Time Central European Time Central European Time Eastern European Time Greenwich Mean Time Central European Time Central European Time Central European Time Central European Time Eastern European Time Central European Time Relative to GMT GMT-11 GMT-12 GMT-13 GMT-14 GMT-2 GMT-3 GMT-4 GMT-5 GMT-6 GMT-7 GMT-8 GMT-9 GMT+0 GMT+1 GMT+11 GMT+12 GMT+2 GMT+3 GMT+4 GMT+5 GMT+6 GMT+7 GMT+8 GMT+9 GMT GMT GMT GMT GMT+2 GMT+1 GMT+1 GMT+2 GMT GMT+1 GMT+1 GMT+1 GMT+1 GMT+2 GMT+1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Etc/GMT-11 Etc/GMT-12 Etc/GMT-13 Etc/GMT-14 Etc/GMT-2 Etc/GMT-3 Etc/GMT-4 Etc/GMT-5 Etc/GMT-6 Etc/GMT-7 Etc/GMT-8 Etc/GMT-9 Etc/GMT+0 Etc/GMT+1 Etc/GMT+11 Etc/GMT+12 Etc/GMT+2 Etc/GMT+3 Etc/GMT+4 Etc/GMT+5 Etc/GMT+6 Etc/GMT+7 Etc/GMT+8 Etc/GMT+9 Etc/GMT0 Etc/Greenwich Etc/UTC Etc/Universal Etc/Zulu Europe/Amsterdam Europe/Andorra Europe/Athens Europe/Belfast Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Bucharest Europe/Budapest Chapter 12.Complete table of time zones with variable length notation Table 72.

Variable length notation time zones list (continued) Long Name Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Description Eastern European Time Central European Time Greenwich Mean Time Central European Time Central European Time Eastern European Time Greenwich Mean Time Eastern European Time Greenwich Mean Time Eastern European Time Eastern European Time Western European Time Central European Time Greenwich Mean Time Central European Time Central European Time Central European Time Eastern European Time Eastern European Time Central European Time Moscow Standard Time Eastern European Time Central European Time Central European Time Central European Time Central European Time Eastern European Time Central European Time Samara Time Central European Time Central European Time Eastern European Time Central European Time Eastern European Time Central European Time Eastern European Time Central European Time Eastern European Time Eastern European Time Relative to GMT GMT+2 GMT+1 GMT GMT+1 GMT+1 GMT+2 GMT GMT+2 GMT GMT+2 GMT+2 GMT GMT+1 GMT GMT+1 GMT+1 GMT+1 GMT+2 GMT+2 GMT+1 GMT+3 GMT+2 GMT+1 GMT+1 GMT+1 GMT+1 GMT+2 GMT+1 GMT+4 GMT+1 GMT+1 GMT+2 GMT+1 GMT+2 GMT+1 GMT+2 GMT+1 GMT+2 GMT+2 | | | Europe/Guernsey Europe/Helsinki Europe/Isle_of_Man Europe/Istanbul Europe/Jersey Europe/Kaliningrad Europe/Kiev Europe/Lisbon Europe/Ljubljana Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta | Europe/Mariehamn Europe/Minsk Europe/Monaco Europe/Moscow Europe/Nicosia Europe/Oslo Europe/Paris | Europe/Podgorica Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/San_Marino Europe/Sarajevo Europe/Simferopol Europe/Skopje Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Tiraspol Europe/Uzhgorod 478 IBM Tivoli Workload Scheduler: Reference Guide .Complete table of time zones with variable length notation Table 72.

Variable length notation time zones list (continued) Long Name Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Vilnius Description Central European Time Central European Time Central European Time Eastern European Time Moscow Standard Time Central European Time Central European Time Eastern European Time Central European Time Greenwich Mean Time Greenwich Mean Time Greenwich Mean Time Greenwich Mean Time Greenwich Mean Time Greenwich Mean Time Greenwich Mean Time Hong Kong Time Hawaii Standard Time Greenwich Mean Time Eastern Standard Time Eastern African Time Indian Ocean Territory Time Christmas Island Time Cocos Islands Time Eastern African Time French Southern and Antarctic Lands Time Seychelles Time Maldives Time Mauritius Time Eastern African Time Reunion Time Iran Standard Time Israel Standard Time India Standard Time Eastern Standard Time Japan Standard Time Japan Standard Time Marshall Islands Time Eastern European Time Relative to GMT GMT+1 GMT+1 GMT+1 GMT+2 GMT+3 GMT+1 GMT+1 GMT+2 GMT+1 GMT GMT GMT GMT GMT GMT GMT GMT+8 GMT-10 GMT GMT-5 GMT+3 GMT+6 GMT+7 GMT+6 GMT+3 GMT+5 GMT+4 GMT+5 GMT+4 GMT+3 GMT+4 GMT+3 GMT+2 GMT+5 GMT-5 GMT+9 GMT+9 GMT+12 GMT+2 | Europe/Volgograd Europe/Warsaw Europe/Zagreb Europe/Zaporozhye Europe/Zurich GB GB-Eire GMT | | | | GMT-0 GMT+0 GMT0 Greenwich Hongkong HST Iceland IET Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion Iran Israel IST Jamaica Japan JST Kwajalein Libya Chapter 12. Managing time zones 479 .Complete table of time zones with variable length notation Table 72.

Time Kosrae Time Marshall Islands Time Marshall Islands Time Marquesas Time Samoa Standard Time Nauru Time Niue Time Norfolk Time Relative to GMT GMT+1 GMT-8 GMT-7 GMT-6 GMT+3 GMT+3 GMT+3 GMT-11 GMT-7 GMT-7 GMT-7 GMT+4 GMT+13 GMT+13 GMT+13 GMT-11 GMT+13 GMT+13 GMT-5 GMT+11 GMT+13 GMT-10 GMT+12 GMT+12 GMT-6 GMT-9 GMT+11 GMT+10 GMT-10 GMT-10 GMT+14 GMT+11 GMT+12 GMT+12 GMT-9 GMT-11 GMT+12 GMT-11 GMT+11 | | | Mideast/Riyadh87 Mideast/Riyadh88 Mideast/Riyadh89 MIT MST MST7MDT Navajo NET NST NZ NZ-CHAT Pacific/Apia Pacific/Auckland Pacific/Chatham Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Johnston Pacific/Kiritimati Pacific/Kosrae Pacific/Kwajalein Pacific/Majuro Pacific/Marquesas Pacific/Midway Pacific/Nauru Pacific/Niue Pacific/Norfolk 480 IBM Tivoli Workload Scheduler: Reference Guide . Variable length notation time zones list (continued) Long Name MET Mexico/BajaNorte Mexico/BajaSur Mexico/General Description Middle Europe Time Pacific Standard Time Mountain Standard Time Central Standard Time Arabia Standard Time Arabia Standard Time Arabia Standard Time West Samoa Time Mountain Standard Time Mountain Standard Time Mountain Standard Time Armenia Time New Zealand Standard Time New Zealand Standard Time Chatham Standard Time West Samoa Time New Zealand Standard Time Chatham Standard Time Easter Is. Time Tokelau Time Fiji Time Tuvalu Time Galapagos Time Gambier Time Solomon Is. Time Chamorro Standard Time Hawaii Standard Time Hawaii Standard Time Line Is.Complete table of time zones with variable length notation Table 72. Time Vanuatu Time Phoenix Is.

Complete table of time zones with variable length notation Table 72. Time Tonga Time Truk Time Wake Time Wallis & Futuna Time Yap Time Pakistan Time Mountain Standard Time Central European Time Western European Time China Standard Time Atlantic Standard Time Pacific Standard Time Pacific Standard Time China Standard Time Korea Standard Time Singapore Time Solomon Is. Variable length notation time zones list (continued) Long Name Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Samoa Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis Pacific/Yap PLT PNT Poland Portugal PRC PRT PST PST8PDT Description New Caledonia Time Samoa Standard Time Palau Time Pitcairn Standard Time Ponape Time Papua New Guinea Time Cook Is. Time Chamorro Standard Time Samoa Standard Time Tahiti Time Gilbert Is. Managing time zones 481 . Time Eastern European Time Coordinated Universal Time Alaska Standard Time Hawaii-Aleutian Standard Time Mountain Standard Time Central Standard Time Eastern Standard Time Eastern Standard Time Hawaii Standard Time Eastern Standard Time Eastern Standard Time Relative to GMT GMT+11 GMT-11 GMT+9 GMT-8 GMT+11 GMT+10 GMT-10 GMT+10 GMT-11 GMT-10 GMT+12 GMT+13 GMT+10 GMT+12 GMT+12 GMT+10 GMT+5 GMT-7 GMT+1 GMT GMT+8 GMT-4 GMT-8 GMT-8 GMT+8 GMT+9 GMT+8 GMT+11 GMT+2 GMT GMT-9 GMT-10 GMT-7 GMT-6 GMT-5 GMT-5 GMT-10 GMT-5 GMT-5 | ROC ROK Singapore SST Turkey | Universal US/Alaska US/Aleutian US/Arizona US/Central US/Eastern US/East-Indiana US/Hawaii US/Indiana-Starke US/Michigan Chapter 12.

Complete table of time zones with variable length notation Table 72. Variable length notation time zones list (continued) Long Name US/Mountain US/Pacific US/Pacific-New US/Samoa UTC VST WET W-SU Description Mountain Standard Time Pacific Standard Time Pacific Standard Time Samoa Standard Time Coordinated Universal Time Indochina Time Western European Time Moscow Standard Time Central African Time Relative to GMT GMT-7 GMT-8 GMT-8 GMT-11 GMT GMT+7 GMT GMT+3 GMT+2 | Zulu 482 IBM Tivoli Workload Scheduler: Reference Guide .

Actions are logged whether or not they are successful. For information on the optman command line. Enabling the auditing feature Auditing is disabled by default when the product is installed. © Copyright IBM Corp. If these options are not present among the global options then auditing is disabled. Set the value to yes to enable auditing or to no to disable auditing.Chapter 13. Database audit log file Logs all actions against scheduling objects. This chapter is divided into the following sections: v “Auditing overview” v “Enabling the auditing feature” v “Audit log format” on page 484 v “Sample audit log files” on page 487 Auditing overview Tivoli Workload Scheduler provides you with two types of audit log files: Plan audit log file Logs all user action performed against the plan. 1999. The auditing logs are created once a day at 00:00:00 GMT in the following directories: TWS_home/audit/plan TWS_home/audit/database on each workstation in the Tivoli Workload Scheduler network to minimize the risk of audit failure due to network problems. You can enable or disable the auditing feature by setting the value of these two global options: plan audit level database audit level using the optman command line on the master domain manager. Plan auditing settings take effect when JnextPlan is run. even if an object is opened and saved without changing it. refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide. By default the auditing feature is disabled. The auditing feature Tivoli Workload Scheduler provides you with an auditing feature to track changes applied to the database and to the plan. 2007 483 .

for each action logged. and whether it is a plan or a database audit log. Workstation Name The Tivoli Workload Scheduler workstation name for which this file was created. In the audit log files: The format for dates is yyyymmdd where: v yyyy is the year v mm is the month v dd is the day The format for times is hhmmss where: v hh is the hour v mm is the minutes v ss is the seconds The formats of the audit log files header and body are described in the following sections. the following set of information ordered in fields separated by vertical bars ( | ): 484 IBM Tivoli Workload Scheduler: Reference Guide . The local time is defined by the time zone option of the workstation. The logging level. The local date is defined by the time zone option of the workstation. the workstation it relates to.Audit log format Audit log format The audit log formats are basically the same for both the plan and the database audit log files. DATABASE for a database log file and PLAN for a plan log file. Each workstation in the Tivoli Workload Scheduler network creates its own log. The local time when the log file was created. They consist of a header portion containing information about when the log was created. User ID Version Level The Tivoli Workload Scheduler user ID that created the log file. All data is stored in normal text and formatted to be readable and editable from a text editor such as vi or notepad. Audit log header format The header contains the following set of information ordered in fields separated by vertical bars ( | ): Fields Log Type GMT Date GMT Time Local Date Local Time Object Type Contents HEADER The GMT date when the log file was created. The local date when the log file was created. The version of the file. The GMT time when the log file was created. Audit log body format The log contains. and a body containing a record for each action performed.

It is one of the following: DATABASE DBWKSTN DBWKCLS DBDOMAIN DBUSER DBJBSTRM DBJOB DBCAL DBPROMPT DBPARM DBRES DBSEC PLAN PLWKSTN PLDOMAIN PLJBSTRM PLJOB PLPROMPT PLRES PLFILE Database definition Database workstation definition Database workstation class definition Database domain definition Database user definition Database job stream definition Database job definition Database calendar definition Database prompt definition Database parameter definition Database resource definition Database security Plan Plan workstation Plan domain Plan job stream Plan job Plan prompt Plan resource Plan file Action Type The action taken against the object.Audit log header format Log Type An eight-character value indicating the source of the log record. The local date is defined by the time zone option of the workstation. The type of the object that the action was performed on. The auditing feature 485 . The GMT time when the action was performed. The following log types are supported: HEADER conman PLAN STAGEMAN RELEASE DATABASE PARMS MAKESEC GMT Date GMT Time Local Date Local Time Object Type The log file header conman command text Plan action stageman run release command text Database action Parameter command text makesec run The GMT date when the action was performed. Chapter 13. The local time is defined by the time zone option of the workstation. Valid action types are add. The local date when the action was performed. The local time when the action was performed.

modify. users. The format of this field depends on the object type as follows: DBWKSTN DBWKCLS DBDOMAIN DBUSER DBJBSTRM DBJOB DBCAL DBPROMPT DBPARM DBRES PLWKSTN PLDOMAIN PLJBSTRM PLJOB PLPROMPT PLRES PLFILE workstation workstation_class domain [workstation#]user workstation#jobstream workstation#job calendar prompt workstation#parameter workstation#resource workstation domain workstation#jobstream_instance workstation#jobstream_instance. The format of this data is dependent on the Action Type field. Workstation Name The Tivoli Workload Scheduler workstation on which the user performs the action. expand. and modify actions for workstation. and install. On Windows operating systems. and install. delete. resources. prompts. 486 IBM Tivoli Workload Scheduler: Reference Guide . User ID The logon user who performed the particular action. The install action is recorded when the makesec command is run to install a new security file. For parameters. modify. domains.Audit log header format delete. job streams. For plan audit log Tivoli Workload Scheduler records add. delete. and parameters in the database. expand. if the user who installed WebSphere Application Server was domain user. For database audit logs Tivoli Workload Scheduler records add. the command line with arguments is logged. The appropriate values for this field depend on the action being taken. jobs.job [workstation#]prompt workstation#resource workstation#path(qualifier) Object Name Action Dependent Data The action-specific data fields. workstation classes. calendars. for Log Type stageman and conman this field contains the fully qualified user name domain\user. The fully qualified name of the object. List and display actions for objects are not logged.

yes A ResetPlan command run against the current production plan is stored in the plan audit log file as follows: STAGEMAN|20060207|100758|20060207|110758|PLAN|DELETE|WK1|admin| |/home/WK1/schedlog/M200603140127| AWSBHV025I The old Symphony file renamed /home/WK1/schedlog/M200603140127 Chapter 13. STAGEMAN|20060207|100758|20060207|110758|PLAN |INSTALL|WK1|admin| |C:\IBM\TWS\oper1\Sinfonia| AWSBHV036I Multi-workstation Symphony file copied to C:\IBM\TWS\oper1\Sinfonia STAGEMAN|20060207|100758|20060207|110758|ADITLEVL|MODIFY |WK1|admin| | AWSBHV077I Audit level changing from 0 to 1. The auditing feature 487 .10 PLAN PLAN |admin| |WK1 |admin| |SLUTRI1 | | | | | |20060207|101018|20060207|111018|PLWKSTN |MODIFY |WK1|oper1| |WK1 limit cpu=SLUTRI1.0| Level=1 | | | | | | | | | | |WK1|operator1| |res=WK1#RESOURCE DATABASE|20060207|100524|20060207|110524|DBWKSTN |MODIFY|WK1|operator1| |ws=TIVOLI10 DATABASE|20060207|100525|20060207|110525|DBWKSTN |MODIFY|WK1|operator1| |ws=ASLUTRI1 DATABASE|20060207|100525|20060207|110525|DBWKSTN |MODIFY|WK1|operator1| |ws=WK1 DATABASE|20060207|100526|20060207|110526|DBDOMAIN|MODIFY|WK1|operator1| |dom=MASTERDM DATABASE|20060207|100610|20060207|110610|DBWKSTN |MODIFY|WK1|operator1| |ws=TIVOLI10 DATABASE|20060207|100610|20060207|110610|DBWKSTN |MODIFY|WK1|operator1| |ws=ASLUTRI1 DATABASE|20060207|100611|20060207|110611|DBWKSTN |MODIFY|WK1|operator1| |ws=WK1 DATABASE|20060207|100611|20060207|110611|DBWKSTN |ADD |WK1|operator1| |ws=WK2 DATABASE|20060207|100612|20060207|110612|DBDOMAIN|MODIFY|WK1|operator1| |dom=MASTERDM This is a sample plan audit log: HEADER |20060207|100758|20060207|110758|PLAN | |WK1|admin| | |Version=A1. CONMAN |20060207|100800|20060207|110800|PLWKSTN |MODIFY | continue & start CONMAN |20060207|100941|20060207|110941|PLWKSTN |MODIFY | limit cpu=slutri1.0|Level=1 STAGEMAN|20060207|100758|20060207|110758|PLAN |INSTALL|WK1|admin| |C:\IBM\TWS\oper1\Symphony| AWSBHV030I The new Symphony file is installed.20 |20060207|101028|20060207|111028|PLDOMAIN|MODIFY |WK1|oper1| |ECCOLO reply ECCOLO.Sample audit log files Sample audit log files This is a sample database audit log: HEADER |20060207|084124|20060207|094124|DATABASE| DATABASE|20060207|084124|20060207|094124|DBRES |ADD |WK1| | | |Version=A1.

Sample audit log files 488 IBM Tivoli Workload Scheduler: Reference Guide .

z/OS. In this case they are defined as extended agents. For additional information.com tcpaddr 5000 domain masterdm for maestro type x-agent host ROCIOUS access mvsjes end The following example describes a Tivoli Workload Scheduler job named orajob2 that runs in an Oracle Applications extended agent workstation named ora002. ora002#orajob2 streamlogon orajobs scriptname "-user global -job fnd ’application developer’ po poxacr -prn ps4 2 -v1 ’abc’" description "oracle apps job #2" recovery continue after recov2 The arguments of scriptname differ by application. OPC. This chapter is divided into the following sections: v “What are extended agents?” v “Access method interface” on page 490 v “Method running” on page 494 v “Troubleshooting” on page 496 The following example shows a definition for a z/OS extended agent workstation named MVSCPU that uses the mvsjes access method.rome. their interface and provides information for programmers who want to create custom access methods.tivoli. The Oracle Applications job is named poxacr and its owner is global. CA-7. Oracle EBS.Chapter 14. If recovery is needed. hosted by a physical workstation. Managing extended agents Workstations are generally physical assets (that is computers) but they might also be logical definitions. refer to IBM Tivoli Workload Scheduler for Applications: User's Guide What are extended agents? Extended agents are used to extend the job scheduling functions of Tivoli Workload Scheduler to other systems and applications. representing operating systems or applications where you want to run jobs or job streams. Peoplesoft. JES. cpuname MVSCPU description "zOS extended agent" os other node mvsesa36. © Copyright IBM Corp. SAP R/3. Tivoli Workload Scheduler will run job recov2 and then continue processing. 1999. Extended Agents are used to extend the job scheduling functions of IBM Tivoli Workload Scheduler to other systems and applications such as: local or remote UNIX operating systems. This chapter describes the extended agents. It logs on to UNIX as orajobs and launches a job under Oracle Applications. 2007 489 . and VMS.

Checks the availability of a file. 490 IBM Tivoli Workload Scheduler: Reference Guide . Gets the status of a job. Method command line syntax The Tivoli Workload Scheduler host runs an access method using the following command line syntax: methodname -t task options -. Access method interface The interface between Tivoli Workload Scheduler and an access method consists of information passed to the method on the command line. to launch a job on an extended agent. The access method communicates with the external system or application to launch the job and return the status of the job. passing it job details as command line options. This logical workstation must be hosted by an Tivoli Workload Scheduler physical workstation. Use this option to check job follows dependencies. and of messages returned to Tivoli Workload Scheduler in stdout. the access method is called and passes the job information to the external system. the host runs the access method.” Task options The task options are listed in Table 73 on page 491. Use this option to check file opens dependencies. Manages a previously launched job. See “Task options. where task is one of the following: LJ MJ CF GS Launches a job. An X means that the option is valid for the task. taskstring A string of up to 255 characters associated with the task.What are extended agents? An extended agent is defined as a workstation that has a host and an access method. options Specifies the options associated with the task. FTA workstation. domain manager. The extended agent workstation definition references the name of the access method and the host workstation.taskstring where: methodname Specifies the file name of the access method. The access method is an IBM-supplied or user-supplied script or program that is run by the host whenever the extended agent is referenced in the production plan. Workstation definition Each extended agent must have a logical workstation definition. The host is any other workstation. When jobs are launched on the extended agent workstation. For example. All access methods must be stored in the directory: TWS_home/methods -t task Specifies the task to be performed. either a master domain manager. See “Task options” for more information. except another extended agent. Use this option to resynchronize if a prior LJ task ended unexpectedly.

The current and specific run numbers might be different if the job was carried forward from an earlier run. Method command task options Task LJ MJ CF GS -c X X X X -n X X X X -p X X X X X X -r X X -s X X -d X X -l X X -o X X -j X X X X -q -w -S X Task String ljstring mjstring cfstring gsstring -c xagent. This is defined in the extended agent’s workstation definition Node field. and the master domain manager separated by commas. -s jstream Specifies the name of the job’s job stream. in seconds.Method command line syntax Table 73.epoch Specifies the job stream date (yymmdd) and the epoch equivalent. -n nodename Specifies the node name of the computer associated with the extended agent. if any. separated by a comma.id Specifies the job’s name and the unique identifier assigned by Tivoli Workload Scheduler. -q qualifier Specifies the qualifier to be used in a test command issued by the method against the file. The default is 300. if any. Any output from the job must be written to this file. -o stdlist Specifies the full path name of the job’s standard list file. the host. -w timeout Specifies the amount of time. -j jobname. -p portnumber Specifies the TCP/IP port number associated with the extended agent. This is defined in the extended agent’s workstation definition TCP Address field. -l user Specifies the job’s user name. separated by a comma.specificrun Specifies the current run number of Tivoli Workload Scheduler and the specific run number associated with the job separated by a comma. that Tivoli Workload Scheduler waits to get a reply on an external job before sending a SIGTERM signal to the access method. -r currentrun. Managing extended agents 491 .host. The name is defined in the job definition Job Name field. This is defined in the job definition Logon field. -S new name Specifies that the job is rerun using this name in place of the original job Chapter 14. -d scheddate.master Specifies the names of the extended agent.

492 IBM Tivoli Workload Scheduler: Reference Guide . For the GS task. -. The format is as follows: followsjob[. For a file opens dependency. Specifies the job whose status is checked.ljstring Used with the LJ task.jobid] where: followsjob The string from the Follows Sched/Job list of the job stream definition. the string from the Opens Files field of the job stream definition. this identifies the job that was launched. state The state to which the job is changed. a UNIX method can provide the process identification (PID) of the job it launched.Method command line syntax name. All Tivoli Workload Scheduler job states are valid except HOLD and READY. the following states are also valid: ERROR EXTRN An error occurred. jobid An optional job identifier received by Tivoli Workload Scheduler in a %CJ response to a previous GS task. The string from the Script File or Command field of the job definition. -. Within a job script. Usually. The information provided to the Tivoli Workload Scheduler by the method in a message indicating a job state change %CJ (see “Method response messages” for additional details on messages indicating job state change) following to a LJ task. The messages have the following format: %CJ state [mjstring | jobid] %JS [cputime] %RC rc %UT [errormessage] where: CJ Changes the job state.gsstring Used with the GS task. -.cfstring Used with the CF task. -. Method response messages Methods return information to Tivoli Workload Scheduler in messages written to stdout. you can use the jobinfo command to return the job name and run the script differently for each iteration. which is then sent by the Tivoli Workload Scheduler as part of an MJ task. Each line starting with a percent sign (%) and ending with a new line is interpreted as a message. Status is unknown.mjstring Used with the MJ task. For example.

The options recognized by Tivoli Workload Scheduler are as follows: LJuser=username CFuser=username GSuser=username GStimeout=seconds where: LJuser=username Specifies the login to use for the LJ and MJ tasks. The return code is taken into account only if a return code condition was specified in the definition of the extended agent job. The default for UNIX is root. the changes only take effect when it is stopped and restarted. Displays a string of up to 255 characters that Tivoli Workload Scheduler will include in its error message. Tivoli Workload Scheduler reads the file. If the file is modified after Tivoli Workload Scheduler is started. Otherwise. See 492. before running a method. See 492. GSuser=username Specifies the login to use for the GS tasks. jobid A string of up to 64 characters that Tivoli Workload Scheduler will include in any GS task associated with the job. Likewise. RC rc rc is a number that is interpreted by Tivoli Workload Scheduler as the return code of the extended agent job. Chapter 14. and for Windows is the user name of the account in which Tivoli Workload Scheduler was installed. CFuser=username Specifies the login to use for the CF task. Managing extended agents 493 .Method response messages mjstring A string of up to 255 characters that Tivoli Workload Scheduler will include in any MJ task associated with the job. The file can contain Tivoli Workload Scheduler options and any other method information. Method options file You can use a method options file to specify special login information and other options. The default for UNIX is root. The default is the login from the job definition. JS [cputime] Indicates successful completion of a job and provides its elapsed run time in seconds. and for Windows is the user name of the account in which Tivoli Workload Scheduler was installed. if it exists. it is ignored and the successful completion of the extended agent job is indicated by the presence of message %JS [cputime]. then the successful completion of the extended agent job is indicated by the presence of message %JS [cputime]. if the method does not send the %RC message. UT [errormessage] Indicates that the requested task is not supported by the method.

opts Method running The following subsections describe the interchange between Tivoli Workload Scheduler and an access method. For example. Note: If the extended agent’s host is a Windows computer. In addition. Before running the method. with an . Sets job state to ABEND and displays errormessage. Sets job state to SUCC. Sets job state to ABEND.Method options file GStimeout=seconds Specifies the amount of time. it writes messages to its stdout that indicate the state of the job on the external system. it is set to/bin:/usr/bin. A typical sequence consists of one or more %CJ messages indicating changes to the job state and then a %JS message before the method exits to indicate that the job ended successfully. it is set to%SYSTEM%\SYSTEM32. Table 74. If the parameter is not present or the options file does not exist. Tivoli Workload Scheduler establishes a run environment. Launch job task (LJ) messages Task LJ and MJ Method Response %CJ state [mjstring] %JS [cputime] Exit code=non-zero %UT [errormessage] and Exit code=2 Tivoli Workload Scheduler Action Sets job state to state. The options file must have the same path name as its access method. If the job is unsuccessful. TZ The time zone.opts file extension. in seconds. For Windows. Launch job task (LJ) The LJ task instructs the extended agent method to launch a job on an external system or application. Once a method is running. If the method cannot be run. the method must exit without writing 494 IBM Tivoli Workload Scheduler: Reference Guide . Includes mjstring in any subsequent MJ task. the job is placed in the FAIL state. the following environment variables are set: HOME The login user’s home directory. the Windows path name of an options file for a method named netmeth is TWS_home\methods\netmth. The LJuser parameter is read from the method options file to determine the user account with which to run the method. Tivoli Workload Scheduler waits for a response before killing the access method. PATH For UNIX. the user account specified in the Logon field of the job’s definition is used. these users must be defined as Tivoli Workload Scheduler user objects. LOGNAME The login user’s name. The default is 300 seconds. The messages are summarized in Table 74.

causing Tivoli Workload Scheduler to place the job in the ABEND state. The signal is sent when an operator issues a kill command from Tivoli Workload Scheduler console manager. Upon receiving the signal. Managing extended agents 495 . Tivoli Workload Scheduler establishes a run environment. and.Launch job task (LJ) the %JS message. Tivoli Workload Scheduler sets up the environment in the same manner as for the LJ task and passes it the mjstring. Set file state to NO. This is summarized in Table 75. A method that does not support the LJ task. A method that does not support the CF task writes a %UT message to stdout and exits with an exit code of 2. If the method is unable to locate the job. Set file state to NO. Check file task (CF) The CF task requests the extended agent method to check the availability of a file on the external system. If the file test is true. See “Launch job task (LJ)” on page 494 for more information. Get status task (GS) The GS task tells the extended agent’s method to check the status of a job. it exits with a nonzero exit code. the method exits with a nonzero exit code. If the file test is false. on UNIX the root user is used. If the parameter is not present or the options file does not exist. the file status is set to NO and any dependent job or job stream is not allowed to run. it responds with the same messages as an LJ task. Check file task (CF) messages Task CF Method Response Exit code=0 Exit code=nonzero %UT [errormessage] and Exit code=2 Tivoli Workload Scheduler Action Set file state to YES. the method runs a test command. If the method cannot be run. the user name of the account in which Tivoli Workload Scheduler was installed is used. the method must trap a SIGTERM signal (signal 15). If the method locates the specified job. This is necessary when another job is dependent on the successful completion of an external job. Killing a job While an LJ or MJ task is running. Once it is running. that is. Table 75. the user name of the account in which Tivoli Chapter 14. the method exits with an exit code of zero. Manage job task (MJ) The MJ task is used to synchronize with a previously launched job if Tivoli Workload Scheduler determines that the LJ task ended unexpectedly. the file opens dependency is marked as failed. The CFuser parameter is read from the method options file to determine the user account with which to run the method. against the file using the qualifier passed to it in the -q command line option. on Windows. on UNIX the root user is used and. the GSuser parameter is read from the method options file to determine the user account with which to run the method. Before running the method. or the equivalent. If the parameter is not present or the options file does not exist. the method must attempt to stop (kill) the job and then exit without writing a %JS message. writes a %UT message to stdout and exits with an exit code of 2. on Windows. Before running the method.

the dependent job or job stream is not allowed to run. An error occurred in the method while checking job status. For GS and CF tasks that are not associated Tivoli Workload Scheduler jobs. the method is re-run with a GS task until one of the following job states is returned: abend The job ended abnormally. and returns it in a %CJ message written to stdout. but its success or failure is not known. messages are written to Tivoli Workload Scheduler standard list file. Cpuinfo command The cpuinfo command can be used in an access method to return information from a workstation definition. it is passed to the method. If the method cannot be run. Get status task (GS) messages Task GS Method Response %CJ state [jobid] %UT [errormessage] and Exit code=2 Tivoli Workload Scheduler Action Sets job state to state and includes jobid in any subsequent GS task. The job is ended. The method checks the state of the specified job. Note that GStimeout in the method options file specifies how long Tivoli Workload Scheduler will wait for a response before killing the method. succ cancl done fail error extrn The job completed successfully. 496 IBM Tivoli Workload Scheduler: Reference Guide . The job check failed or the job status could not be determined. See “Method options file” on page 493 for more information. A method that does not support the GS task writes a %UT message to stdout and exits with an exit code of 2. Job standard list error messages All output messages from an access method. See “cpuinfo” on page 378 for complete command information. For information about a problem of any kind. The job could not be run. are written to the job’s standard list (stdlist) file. except those that start with a percent sign (%). If a jobid is available from a prior GS task. Job state is unchanged. Troubleshooting The following topics are provided to help troubleshoot and debug extended agent and access method problems.Get status task (GS) Workload Scheduler was installed is used. The job was cancelled. check these files. Method responses are summarized in Table 76: Table 76. It then exits with an exit code of zero. At a rate set by the bm check status local option.

review the standard list files (stdlist) for the job and for Tivoli Workload Scheduler. Managing extended agents 497 . Composer and compiler messages The following error messages are generated when composer encounters invalid syntax in a workstation definition: AWSDEM045E There is an error in the workstation definition. v For the CF task. the file dependency is unresolved and the dependent job remains in the HOLD state. Console Manager messages This error message is displayed if you issue a start. Failure to launch a job generates the following message: AWSBDW057E The job job_name was not launched for this reason: error_message Failure of a check file task generates the following message: AWSBDW062E Jobman was unable to invoke the following method file method_name for the extended agent. stop. because the workstation is an extended agent. To get more information. the job is placed in the FAIL state. AWSDEM046E There is an error in the workstation definition. The ACCESS keyword was not followed by a valid method. The ACCESS keyword has been specified more than once. Jobman messages For extended agents. the job dependency is unresolved and the dependent job remains in the HOLD state. The ACCESS keyword was not followed by a valid method. #Jrun_number for user user_ID. link. error.Method not executable Method not executable If an access method cannot be run. Valid methods correspond with the name of a file in the TWS_home/methods directory (the file need not be present when the access method is defined). and information messages are written to jobman’s stdlist file. The operating system error is: system_error Failure of a manage job task generates the following message: Chapter 14. AWSDEM047E There is an error in the workstation definition. the following occurs: v For LJ and MJ tasks. the following message is displayed: AWSBIA140E For an extended agent you must specify the host and the access method. cannot be performed. A successful job launch generates the following message: AWSBDW019I Launched job job_name. If an extended agent is defined with an access method but without a host. v For the GS task. Valid methods correspond with the name of a file in the TWS_home/methods directory (the file need not be present when the access method is defined). or unlink command for an extended agent: AWSBHU058E The command issued for workstation: workstation_name. warning. where the command is not supported.

monitor PID and method file are as follows: job_name. The job identifier. 498 IBM Tivoli Workload Scheduler: Reference Guide . #Jmonitor_pid using method file.Jobman messages AWSBDW066E Planman has asked jobman to run a task that is not supported on the targeted agent. The following method options file was used: method_options_file. the following message is generated: AWSBDW064E A job that jobman is monitoring has returned the following unrecognizable message: incorrect_message. The job identifier and monitor PID are as follows: job. #Jmonitor_pid When a method sends a message to jobman that is not recognized.

you must create a workstation definition for the network agent. Internetwork dependencies overview Before you specify an internetwork dependency. with the exception that the network agent’s name is included to identify the followed job or job stream. Internetwork dependencies are assigned to jobs and job streams in the same way as local follows dependencies. In the local Tivoli Workload Scheduler network there can be more than one network agent. © Copyright IBM Corp. It contains placeholder jobs to represent each internetwork dependency. 1999. 2007 499 . The chapter is divided into the following sections: v “What is new about internetwork dependencies” v “Internetwork dependencies overview” v “Configuring a network agent” on page 501 v “Defining an internetwork dependency” on page 503 v “Managing internetwork dependencies” on page 504 v “Internetwork dependencies in a mixed environment” on page 507 What is new about internetwork dependencies The concept of run cycles for job streams and the possibility to schedule more than one instance of the same job stream with the same name and different scheduled date and time within the same production plan introduce the need to link each internetwork dependency to specific instances of a job stream. These rules also apply when dealing with depending jobs defined within job streams scheduled to run for multiple days. To do this the following rules are applied in defining and managing internetwork dependencies: v A job is created in the EXTERNAL job stream for each day the referring job stream is scheduled to run. v A job in the EXTERNAL job stream is identified by the script name and the date the referring job stream is planned to run. This chapter describes how to customize your environment to be able to define internetwork dependencies and how to manage the internetwork dependencies. These enhancements are described in more detail in the following sections. each representing a specific Tivoli Workload Scheduler remote network where jobs and job streams referring to locally defined internetwork dependencies are defined.Chapter 15. A network agent is a Tivoli Workload Scheduler workstation that handles follows dependencies between its local network and a remote Tivoli Workload Scheduler network. A special job stream named EXTERNAL is automatically created by Tivoli Workload Scheduler for each network agent in the local network. Managing internetwork dependencies Tivoli Workload Scheduler internetwork dependencies allow jobs and job streams in the local network to use jobs and job streams in a remote network as follows dependencies.

JOB1" is satisfied.JOB1" TWS206#ELISCHE 0600 03/31 **** HOLD 10 (03/31) ELI HOLD 10 where (03/31) represents the at time restriction set in TWS206#ELISCHE. v The date the local job stream containing the internetwork dependency is planned to start. CANCL. This means that an EXTERNAL job differs from another one by: v The script file name. Use the conman sj command to see the internetwork dependency set: CPU (Est) (Est) Schedule SchedTime Job State Pr Start Elapse RetCode Deps XA-MAST::"TWS207#MYJS. as one of their job streams is released and the job starts the internetwork dependency is checked and possibly released. or ERROR state.info you see the list of jobs representing internetwork dependencies defined in jobs and job streams running in the local network from jobs and job streams defined in the remote network reachable through the network agent XA-MAST: 500 IBM Tivoli Workload Scheduler: Reference Guide . Tivoli Workload Scheduler checks the status of the referred jobs and job streams in the remote network and maps their status in the jobs representing the internetwork dependencies in the EXTERNAL job stream. If you run the command: %sj XA-MAST#EXTERNAL. If the dependency is defined in a job within the job stream the date the job stream is planned to start is taken into account. In this case when the second job starts to check its internetwork dependency it finds the dependency already solved but not necessarily on the expected day.Internetwork dependencies overview An EXTERNAL job is created for each internetwork dependency belonging to job streams planned to start in different days with different schedule dates. v XA_MAST is the network agent defined in the local network to manage internetwork dependencies from jobs and job streams defined in that remote network. Assume that: v You defined a job stream named ELISCHED running on workstation TWS206 containing a job named ELI with an internetwork dependency from a job stream TWS207#FINAL. In case of two jobs belonging to different job streams and referring to the same internetwork dependency. If you want to prevent this situation from occurring you must rerun the job representing the internetwork dependency after it is solved the first time. Understanding how an internetwork dependency is shown This section describes a sample scenario about internetwork dependencies and how to link the job representing the internetwork dependency to the job stream where the dependency is defined. The check of the internetwork dependency check does not start until the job stream matches its time dependency or it is released.JOB1 is checked in the remote network to see if the internetwork dependency XA-MAST::"TWS207#MYJS. which identifies the remote job or job stream the local job or job stream is dependent on. The status of these jobs and job streams is checked over a fixed time interval until the remote job or job stream reaches the SUCC.MAKEPLAN running in a different Tivoli Workload Scheduler network. Starting from (03/31) the status of TWS207#MYJS.

This options file must have the same path as the access method: TWS_home/methods/netmth. An options file named netmth. Managing internetwork dependencies 501 . In this file are defined the user under which the access method runs and the time to wait to get a response from the access method before shutting it down.opts The content of the netmth.deps The output shows the link between the dependent job and the internetwork dependency: CPU (Est) (Est) Schedule SchedTime Job State Pr Start Elapse RetCode Deps XA-MAST#EXTERNAL. or ERROR state. CANCL. 03/31/06.opts is created on the workstation where the network agent runs.JOB1 Opt Job You can see the details about the job or job stream depending on TWS207#MYJS. (03/31). The batchman process on the master domain manager queries the netmth on the network agent at fixed time intervals to get the status of the remote predecessor job or job stream.JOB1 will be listed in the job E8802332 within the XA-MAST#EXTERNAL job stream.JOB1 and the local job stream is planned to start on the same day. by running the following command: %sj @#EXTERNAL. Configuring a network agent Network agent workstations are defined as extended agents and require a hosting physical workstation and an access method. If there is another job defined within another job stream in the local network that has a dependency on TWS2007#MYJS. then also the dependency of this other job on TWS2007#MYJS. The Tivoli Workload Scheduler continues checking until the remote job or job stream reaches the SUCC.E8802332 Dependencies are: TWS206#ELISCHE 0600 03/31 **** HOLD 10 (03/31) ELI HOLD 10 XA-MAST::"TWS207#MYJS.JOB1 in the internetwork dependency represented by job E8802332 in the EXTERNAL job stream. or is released.Internetwork dependencies overview CPU Schedule SchedTime Job JobFile Prompt XA-MAST #EXTERNAL E8802332 TWS207#MYJS.opts file has the following structure: GSuser=login_name GStimeout=seconds where: Chapter 15. The access method for network agents is named netmth.E8802332.JOB1" The internetwork dependency check does not start until the job stream TWS206#ELISCHE matches its time dependency. You can customize the time interval between two consecutive checks by setting the global option bm check status in the localopts file on the master domain manager.

Local and remote networks Assuming that: v MasterA is the master domain manager of the remote network. – The TCP port number for MasterA as 12345. Network B. Network A. and that: – tws_masterA is the TWS_user defined on MasterA.rome. seconds Is the number of seconds. this user must be defined in Tivoli Workload Scheduler. that allows local network. the access method starts up automatically. A sample network agent definition The following example shows how to define a network agent workstation for a remote network. Changes to this file do not take effect until you stop and restart Tivoli Workload Scheduler.rome.com. The default setting is 300 seconds.tivoli. – The node where MasterB is defined is MasterB. Tivoli Workload Scheduler waits for a response before shutting down the access method. defined on MasterB to manage internetwork dependencies on jobs or job streams defined in Network A can be the following: 502 IBM Tivoli Workload Scheduler: Reference Guide . Remote Network A Local Network B MasterA MasterB Network Agent Figure 16.Configuring a network agent login_name Is the login used to run the method. Network A. v MasterB is the master domain manager of the local network. A network agent workstation named NetAgt.tivoli. to use jobs and job streams in the remote network as internetwork dependencies. The next time batchman needs to check the status of the remote predecessor job or job stream. If the network agent’s host is a Windows computer.com. – The node where MasterA is defined is MasterA. and that: – tws_masterB is the TWS_user defined on MasterB. Network B.

you can define internetwork dependencies using the following follows statements: To define an internetwork dependency of schedB from the job stream instance schedA(1100) Use the following statement: schedule schedB on everyday follows NetAgt::MasterA#schedA(1100) : end To define an internetwork dependency of jobB from jobA contained in the job stream instance schedA(1100) Use the following statement: schedule schedB on everyday : jobB : follows NetAgt::MasterA#schedA(1100). the first job stream found is taken into account. Defining an internetwork dependency The syntax used to specify an internetwork dependency within a job stream definition is the following: follows Network_agent_name::remote_workstation#jobstreamname(time [date]). v jobA is a job defined in the MasterA database.jobname where the (time [date]) are specific to the time zone used on the workstation of the remote network the network agent is connected to.ROME.TIVOLI.COM TCPADDR 12345 FOR maestro HOST MASTERB ACCESS NETMTH END The options file. netmth. Managing internetwork dependencies 503 . If (time [date]) is not specified in this syntax or if there is more than one job stream with the same (time [date]). v jobB is a job defined in the MasterB database.Configuring a network agent CPUNAME NETAGT DESCRIPTION "NETWORK AGENT" OS OTHER NODE MASTERA.jobA Chapter 15. in our sample the time zone of MasterA. v schedB is a job stream defined in the MasterB database. A sample internetwork dependency definition Assuming that: v schedA is a job stream defined in the MasterA database.opts defined on MasterB can be: GSuser=tws_masterB GStimeout=600 Note: The network agent can be defined on either the master domain manager or a fault-tolerant agent.

The reported status refers to the last time the remote network was checked. If it isan EXTERNAL job it returns to state EXTRN. make sure you manually cancel also the job. Is the current seconds. Note: If you cancel in the local network the instances of jobs or job streams dependent on the same instance of a job or job stream defined in a remote network. EXTRN The initial state. see ″Creating Job Streams″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. All states for jobs and job streams. except FENCE. States of jobs defined in the EXTERNAL job stream The status of the jobs defined in the EXTERNAL job stream is determined by the access method and listed in the Release Status field of the EXTERNAL job stream. representing that 504 IBM Tivoli Workload Scheduler: Reference Guide . Managing internetwork dependencies Internetwork dependencies are managed in the plan from the conman command line by managing the EXTERNAL job stream. Note: Remote jobs and job streams are defined and run on their local network in the standard manner. Their use as internetwork dependencies has no effect on their local behavior. In addition to these there are two states that are specific to the EXTERNAL jobs. See Also For the equivalent Job Scheduling Console task. Is the current minutes. Within the EXTERNAL job stream. If the job is not found in the remote network the EXTERNAL job state remains EXTRN. they are: ERROR An error occurred while checking for the remote status. The actual name of the job or job stream is stored in the script files specification of the job record. Jobs might appear to skip states when states change in between two different checks. unique job names representing internetwork dependencies are generated as follows: Ennnmmss where: nnn mm ss Is a random number. are listed. Within the EXTERNAL job stream the internetwork dependencies are listed as jobs regardless of whether they are defined for jobs or job streams.Defining an internetwork dependency : end : end You can also define internetwork dependencies of a job on a job stream or a job stream on a job. There is an EXTERNAL job stream for every network agent in the plan.

Confirm SUCC / ABEND Sets the status of the EXTERNAL job to SUCC or ABEND. The status of the dependency in no longer checked. Rerun is useful for EXTERNAL jobs in the ERROR state. Working with jobs defined in the EXTERNAL job stream These are the available actions you can perform against jobs in an EXTERNAL job stream: Cancel Cancels the EXTERNAL job.Managing internetwork dependencies internetwork dependency in the EXTERNAL job stream. For example.The same consideration applies when the local job stream dependent on the job or job stream defined in the remote network is not carried forward to the new plan. releasing the dependency for all depending local jobs and job streams. to prevent the EXTERNAL job stream from being continuously carried forward. v A workstation in the remote network called remote1 v A job stream defined for the remote workstation remote1 called rcshed v A job in defined in remote1#rsched called rjob You can perform the following actions from the conman command line in the local network: Adding an internetwork dependency from a remote job to a local job. Managing internetwork dependencies 505 . the method can start but conman will not start checking the EXTERNAL job state until you perform a rerun. run the following command: Chapter 15. For example. Rerun Instructs conman to restart checking the state of the EXTERNAL job. the job enters the ERROR state and its status ceases to be checked. Sample internetwork dependency management scenarios This section provides sample scenarios describing how you can manage internetwork dependency in production using the conman command line commands. releasing the internetwork dependency for all local jobs and job streams. The job state is set to EXTRN immediately after a rerun is performed. if an EXTERNAL job cannot be launched because the network access method does not grant execute permission. They simply manipulate the dependency for the local network. Assuming that you have already defined the following: v A local workstation called local1 v A job stream defined for the local workstation local1 called sched1 v A job defined in local1#sched1 called job1 v A network agent called netagt defined in the local network to manage internetwork dependency from jobs and job streams defined in the remote network. The status of the dependency is no longer checked. Note: None of these commands has any effect on the remote job or job stream in the remote network. After you correct the permissions. to add the remote job rjob as an internetwork dependency for job1.

run the following command: ads local1#sched1.rjob for the local job local1#sched1. For example.follows=netagt::remote1#rsched.follows=netagt::remote1#rsched. For example.rjob for the local job stream local1#sched1.rjob Adding an internetwork dependency from a remote job stream to a local job stream.rjob Releasing a local job from an internetwork dependency from a remote job.rjob. to add the remote job stream rsched as an internetwork dependency for job stream sched1. run one of the following two commands: rr netagt#EXTERNAL.follows=netagt::remote1#rsched.info 506 IBM Tivoli Workload Scheduler: Reference Guide . run the following command: dds local1#sched1. For example.rjob. to display all the internetwork dependencies defined for a network agent with their original names and their generated job names.rjob Releasing a local job stream from an internetwork dependency from a remote job.follows=netagt::remote1#rsched Cancelling internetwork dependencies managed by a network agent. run one of the following two commands: cj netagt#EXTERNAL.job1. to release a job from an internetwork dependency from a remote job. run the following command: rj local1#sched1. to cancel all EXTERNAL jobs for a network agent netagt. to delete the internetwork dependency from the remote job remote1#rsched. run the following command: confirm netagt::remote1#rsched.job1.Managing internetwork dependencies adj local1#sched1. to confirm that the remote job remote1#rsched.rjob completed successfully and so release the corresponding internetwork dependency.rjob Deleting an internetwork dependency from a job for a job stream.follows=netagt::remote1#rsched.succ Deleting an internetwork dependency from a job for a job. run the following command: ddj local1#sched1.@. to rerun a job belonging to the EXTERNAL job stream to restart checking the internetwork dependency from the remote job remote1#rsched.rjob rr netagt::remote1#rsched. to delete the internetwork dependency from the remote job remote1#rsched.@ cj netagt::@ Confirming the successful completion of an internetwork dependency.job1.rjob Displaying internetwork dependencies from jobs and job streams defined in a remote network. For example. run the following command: rs local1#sched1. For example. run the following command: sj netagt#EXTERNAL.job1. For example. For example. to release a job stream from an internetwork dependency from a remote job. For example.rjob Rerunning a job in the EXTERNAL job stream to restart checking a dependency.follows=netagt::remote1#rsched. For example.

the schedtime keyword is parsed by Wks_B.3 Net_A sends the information to Wks_B as if it had the same version as Wks_B.3 Sym_B back-level Wks_B works as if it Net_A sends the had the same version information to Wks_B.2.2. the schedtime keyword in the job definition is automatically removed by Wks_B. Not supported. The Symphony file processed in the remote network. the schedtime keyword in the job definition is automatically removed by Wks_B. Internetwork dependencies in a mixed environment Net_A back-level Sym_A back-level Wks_B back-level Sym_B back-level This is not a mixed version 8. Not supported. The key to the table is as follows: Net_A Wks_B The network agent defined in the local network.3 Sym_A 8. The Symphony file processed in the local network.3 environment. If defined. Version 8.3 environment. the schedtime keyword in the job definition is automatically removed by Net_A. If defined. Not supported. or 8. The workstation in the remote network that the network agent Net_A is connected to. 8.1.2. Net_A back-level Sym_A 8. 8. Wks_B is the workstation that identifies and checks the state of the remote job or job stream specified in the internetwork dependency.3 Chapter 15.1. to submit a rm command into the JOBS job stream with an internetwork dependency on a remote job stream. Net_A sends the information to Wks_B.1 Net_A 8. or 8. If defined. If defined. Net_A sends the information to Wks_B. Not supported.3 Sym_B 8. Not supported. run the following command: sbd "rm apfile". The use of the schedtime keyword in the job definition is not supported. Not supported.2.3 Wks_B 8. the schedtime keyword in the job definition is automatically removed by Wks_B. Net_A sends the information to Wks_B.3 Net_A sends the information to Wks_B in 8. If defined.3 environment.3 Sym_A back-level Net_A sends the information to Wks_B as if it had the same version as Wks_B. Internetwork dependencies in a mixed environment Table 77 shows the supported configuration for internetwork dependencies defined in a mixed version 8. see ″Creating Job Streams″ in the IBM Tivoli Workload Scheduler Job Scheduling Console User’s Guide. Wks_B 8.1 format. as Net_A. Wks_B back-level Sym_B 8. Sym_A Sym_B back-level Table 77. Net_A 8.follows=netagt::remote1#rsched See Also For the equivalent Job Scheduling Console task. Managing internetwork dependencies 507 .Managing internetwork dependencies Submitting a job with an internetwork dependency from a job stream defined in a remote network For example. This is a version 8.

508 IBM Tivoli Workload Scheduler: Reference Guide .

1999. © Copyright IBM Corp. The scheduling objects are monitored as follows: v Jobs are monitored by the workstation where they run v Job streams are monitored by the master domain manager v Workstations monitor themselves v Local prompts are monitored by the workstation running the job or job stream that have a dependency on the prompt v Global prompts are monitored by the master domain manager The following tables show the parameters of each event type. JobStatusChanged This event is sent when the status of a job changes. 2007 509 .msg. Event providers and definitions This section gives details on the event types of the following event providers: v TWSObjectsMonitor v FileMonitor TWSObjectsMonitor events TWSObjectsMonitor events are: v JobStatusChanged v JobUntil v JobSubmit v JobCancel v JobRestart v JobLate v JobStreamStatusChanged v JobStreamCompleted v JobStreamUntil v JobStreamSubmit v JobStreamCancel v JobStreamLate v WorkstationStatusChanged v ApplicationServerStatusChanged v ChildWorkstationLinkChanged v ParentWorkstationLinkChanged v PromptStatusChanged These events are generated by batchman (or mailman for the workstations) and written in a mailbox file named monbox. Event-driven workload automation event and action definitions This appendix documents the event and action providers you can use for event-driven workload automation and gives details on event and action definitions.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Appendix A.

Is significant only if the job has already started. Parameters of JobStatusChanged event types. The ID of the job stream instance containing the job instance. U U 1 510 IBM Tivoli Workload Scheduler: Reference Guide . Undecided. The return code of the job. The actual start time of the job instance. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) JobWorkstation The name of the workstation associated with the job instance. Ready. The name of the job instance. The value of the deadline restriction of the job instance. Running. True if the job instance is key job. The value of the until restriction of the job instance. The job priority. The estimated duration of the job. The scheduled time of the job stream instance containing the job instance. string U U U U 1 16 JobStreamWorkstation string U U U U U 1 16 * JobStreamID string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime U U JobName Priority Monitored string numeric (0-101) boolean U U U U U U U U U U 1 40 * ActualStart datetime U U EstimatedDuration ActualDuration duration duration U U U U ReturnCode numeric U U U LatestStart datetime U U Deadline datetime string Value can be: Error. The actual duration of the job. Waiting U U Status The new status of the job instance. It is significant only for completed or abended jobs. The name of the job stream instance containing the job instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 78. Successful. Held. The name of the workstation associated with the job stream containing the job instance.

Parameters of JobUntil event types. PEND. DONE. INTRO. FAIL. USER. WAITD string duration InternalStatus The new internal status of the job instance. SUSP. The fully qualified host name of the computer that sent the event. CANCP. When the event was generated. Event-driven workload automation event and action definitions 511 . FENCE. ABENP. Table 79. string U U U U 1 16 Appendix A. WAIT. SUCC. The IP address of the computer that sent the event. EXEC. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) string Value can be: ABEND. U U U U U U 1 ErrorMessage string U U U U 1 TimeStamp datetime Hostname string 1 IPAddress string PlanNumber numeric JobUntil This event is sent when the latest start time of a job has elapsed. The every frequency of the job instance. RJOB. ERROR. A message describing the cause of the job failure. Parameters of JobStatusChanged event types. READY. The run number of the Plan running when the event was generated. SCHED. U U 1 Login EveryFrequency The login of the user used to run the job. HOLD. It has significance only when the job instance goes in error (Fail) status. SUCCP. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) JobWorkstation The name of the workstation associated with the job instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 78. EXTRN.

U U 1 512 IBM Tivoli Workload Scheduler: Reference Guide . Successful. The name of the job stream instance containing the job instance. The ID of the job stream instance containing the job instance. The value of the deadline restriction of the job instance. Running. True if the job instance is key job. Parameters of JobUntil event types. Error. The name of the job instance. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) JobStreamWorkstation The name of the workstation associated with the job stream containing the job instance. The value of the until restriction of the job instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 79. Ready. The scheduled time of the job stream instance containing the job instance. string U U U U U 1 16 * JobStreamID string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime U U JobName Priority Monitored EstimatedDuration string numeric (0-101) boolean duration U U U U U U U U U U U U 1 40 * LatestStart datetime U U Deadline datetime string Value can be: Cancelled. Held. Undecided. Waiting U U Status The new status of the job instance. The job priority. The estimated duration of the job.

Parameters of JobUntil event types. DONE. FENCE. WAIT. SUCC. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) string Value can be: ABEND. WAITD string duration string The action taken after the until restriction time has elapsed. READY. PEND. The IP address of the computer that sent the event. EXEC. CANCL. EXTRN. U U 1 Login EveryFrequency The login of the user used to run the job. The fully qualified host name of the computer that sent the event. USER. SCHED. CANCP. SUCCP. Event-driven workload automation event and action definitions 513 . Suppress datetime InternalStatus The new internal status of the job instance. string U U U U 1 16 Appendix A. RJOB. SUSP. INTRO. ERROR. The every frequency of the job instance. Continue. Parameters of JobSubmit event types. Hostname string 1 IPAddress string PlanNumber numeric JobSubmit This event is sent when a job is submitted. U U U U U U 1 UntilAction U U 1 TimeStamp When the event was generated. FAIL. ABENP. HOLD. Value can be: Cancel. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) JobWorkstation The name of the workstation associated with the job instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 79. The run number of the Plan running when the event was generated. Table 80.

The scheduled time of the job stream instance containing the job instance. The estimated duration of the job. The job priority. The name of the job stream instance containing the job instance. The value of the until restriction of the job instance. The fully qualified host name of the computer that sent the event. The ID of the job stream instance containing the job instance. The name of the job instance. The run number of the Plan running when the event was generated. 514 IBM Tivoli Workload Scheduler: Reference Guide . When the event was generated.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 80. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) JobStreamWorkstation The name of the workstation associated with the job stream containing the job instance. The IP address of the computer that sent the event. The every frequency of the job instance. The login of the user used to run the job. True if the job instance is key job. Parameters of JobSubmit event types. The value of the deadline restriction of the job instance. string U U U U U 1 16 * JobStreamID string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime U U JobName Priority Monitored EstimatedDuration string numeric (0-101) boolean duration U U U U U U U U U U U U 1 40 * LatestStart datetime U U Deadline datetime U U Login string U U U U 1 EveryFrequency TimeStamp duration datetime U U Hostname string 1 IPAddress string PlanNumber numeric JobCancel This event is sent when a job is cancelled.

The name of the job stream instance containing the job instance. Ready. The name of the job instance. The name of the workstation associated with the job stream containing the job instance. Parameters of JobCancel event types. The scheduled time of the job stream instance containing the job instance. The ID of the job stream instance containing the job instance. Error. U U 1 Appendix A. Held. Successful. Event-driven workload automation event and action definitions 515 . The job priority. Undecided. string U U U U 1 16 JobStreamWorkstation string U U U U U 1 16 * JobStreamID string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime U U JobName Priority Monitored string numeric (0-101) boolean U U U U U U U U U U 1 40 * ActualStart datetime U U EstimatedDuration ActualDuration duration duration U U U U ReturnCode numeric U U U LatestStart datetime U U Deadline datetime string Value can be: Cancelled. The value of the deadline restriction of the job instance. True if the job instance is key job. The actual start time of the job instance. It is significant only for completed or abended jobs. Running. The return code of the job. The estimated duration of the job. Is significant only if the job has already started. The actual duration of the job. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) JobWorkstation The name of the workstation associated with the job instance. The value of the until restriction of the job instance. Waiting U U Status The new status of the job instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 81.

Table 82. The every frequency of the job instance. FENCE. CANCL. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value JobWorkstation The name of the workstation associated with the job instance. RJOB. CANCP. The name of the workstation associated with the job stream containing the job instance. The fully qualified host name of the computer that sent the event. U U U U 1 EveryFrequency duration U U TimeStamp datetime Hostname string 1 IPAddress string PlanNumber numeric JobRestart This event is sent when a job is restarted. When the event was generated. INTRO. USER. EXTRN. WAITD string InternalStatus The new internal status of the job instance. SUCC. HOLD. EXEC. string U U U U 1 16 JobStreamWorkstation string U U U U U 1 16 * 516 IBM Tivoli Workload Scheduler: Reference Guide . Parameters of JobRestart event types. PEND. ERROR. DONE. READY.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 81. Parameters of JobCancel event types. The run number of the Plan running when the event was generated. SUCCP. SUSP. ABENP. WAIT. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) string Value can be: ABEND. U U 1 Login The login of the user used to run the job. The IP address of the computer that sent the event. SCHED. FAIL.

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 82. The estimated duration of the job. The return code of the job. The login of the user used to run the job. The IP address of the computer that sent the event. string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime U U JobName Priority string numeric (0-101) boolean U U U U U U U U 1 40 * Monitored U U ActualStart datetime U U EstimatedDuration duration U U ActualDuration duration U U ReturnCode numeric U U U LatestStart datetime U U Deadline datetime U U Login string U U U U 1 EveryFrequency duration U U TimeStamp datetime Hostname string 1 IPAddress string Appendix A. The name of the job instance. The scheduled time of the job stream instance containing the job instance. The name of the job stream instance containing the job instance. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value JobStreamID The ID of the job stream instance containing the job instance. Parameters of JobRestart event types. Is significant only if the job has already started. True if the job instance is key job. The job priority. The fully qualified host name of the computer that sent the event. The actual start time of the job instance. The actual duration of the job. When the event was generated. It is significant only for completed or abended jobs. The value of the deadline restriction of the job instance. Event-driven workload automation event and action definitions 517 . The value of the until restriction of the job instance. The every frequency of the job instance.

you must configure local option: bm check deadline = 300 See the Planning and Installation guide for further reference. True if the job instance is key job.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 82. The scheduled time of the job stream instance containing the job instance. The actual start time of the job instance. Is significant only if the job has already started. Parameters of JobLate event types. string U U U U 1 16 JobStreamWorkstation string U U U U U 1 16 * JobStreamID string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime U U JobName Priority string numeric (0-101) boolean U U U U U U U U 1 40 * Monitored U U ActualStart datetime U U EstimatedDuration duration U U 518 IBM Tivoli Workload Scheduler: Reference Guide . The name of the job instance. The estimated duration of the job. The job priority. To properly use this event type and to trigger an action. The ID of the job stream instance containing the job instance. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value PlanNumber The run number of the Plan running when the event was generated. Table 83. The name of the workstation associated with the job stream containing the job instance. The name of the job stream instance containing the job instance. numeric JobLate This event is sent when a job becomes late. Parameters of JobRestart event types. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) JobWorkstation The name of the workstation associated with the job instance.

Held. INTRO. SCHED. SUCCP. CANCP. SUCC. ERROR. Waiting string Value can be: ABEND. It is significant only for completed or abended jobs. DONE. The value of the deadline restriction of the job instance. HOLD. FAIL. EXTRN. PEND. USER. duration U ReturnCode numeric U U U LatestStart datetime U U Deadline datetime U U string Value can be: Cancelled. WAIT. SUSP. U U U U 1 EveryFrequency duration U U TimeStamp datetime Hostname string 1 Appendix A. The every frequency of the job instance. Event-driven workload automation event and action definitions 519 . U U 1 InternalStatus The new internal status of the job instance. ABENP. The return code of the job. Parameters of JobLate event types. The value of the until restriction of the job instance. EXEC. When the event was generated. Undecided. Ready. Running. RJOB. WAITD string Status The new status of the job instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 83. READY. U U 1 Login The login of the user used to run the job. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed U Wildcard allowed Length Default (minvalue max) ActualDuration The actual duration of the job. The fully qualified host name of the computer that sent the event. Successful. Error. FENCE. CANCL.

True if the job stream instance contains key jobs. Parameters of JobStreamStatusChanged event types. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) Workstation The name of the workstation associated with the job stream instance. The scheduled time of the job stream instance. The ID of the job stream instance. The job stream priority. The name of the workstation associated with the job stream instance (same value as in Workstation.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 83. string PlanNumber numeric JobStreamStatusChanged This event is sent when the status of a job stream changes. The value of the deadline restriction of the job stream instance. The name of the job stream instance. Table 84. The run number of the Plan running when the event was generated. string 1 JobStreamWorkstation string U U U U U 1 16 * JobStreamID string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime numeric (0-101) U U Priority U U U Monitored boolean U U LatestStart datetime U U Deadline datetime U U 520 IBM Tivoli Workload Scheduler: Reference Guide . The value of the until restriction of the job stream instance. but is used for correlation with other events. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) IPAddress The IP address of the computer that sent the event. This is the same value as the Job Stream Workstation property. Parameters of JobLate event types.

The new status Cancelled. FENCE. Waiting string Value can be: ABEND. FAIL. Held. of the job stream Error. RJOB. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) string Value can be: Blocked. USER. INTRO. CANCP. EXEC. WAITD datetime Status U U 1 InternalStatus The new internal status of the job stream instance. EXTRN. WAIT. READY. DONE. The IP address of the computer that sent the event.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 84. Hostname string 1 IPAddress string PlanNumber numeric JobStreamCompleted This event is sent when a job stream has completed. SCHED. Successful. Parameters of JobStreamStatusChanged event types. SUSP. SUCCP. The fully qualified host name of the computer that sent the event. U U 1 TimeStamp When the event was generated. Undecided. Event-driven workload automation event and action definitions 521 . ERROR. Ready. Running. The run number of the Plan running when the event was generated. ABENP. PEND. Appendix A. SUCC. HOLD. instance.

Hostname string 1 522 IBM Tivoli Workload Scheduler: Reference Guide .| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 85. The scheduled time of the job stream instance. SUCC datetime Status U U 1 InternalStatus U U 1 TimeStamp When the event was generated. but is used for correlation with other events. The value of the deadline restriction of the job stream instance. Parameters of JobStreamCompleted event types. CANCL. Value can be: Cancelled. The name of the workstation associated with the job stream instance (same value as in Workstation. The ID of the job stream instance. Value can be: ABEND. The name of the job stream instance. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) Workstation The name of the workstation associated with the job stream instance. The job stream priority. True if the job stream instance contains key jobs. The fully qualified host name of the computer that sent the event. Error. The value of the until restriction of the job stream instance. string 1 JobStreamWorkstation string U U U U U 1 16 * JobStreamID string JobStreamName string U U U U U 1 16 * JobStreamSchedTime datetime numeric (0-101) U U Priority U U U Monitored boolean U U LatestStart datetime U U Deadline datetime U U string The new status of the job stream instance. This is the same value as the Job Stream Workstation property. Successful string The new internal status of the job stream instance.

The name of the job stream instance. Property name Description Type Filtering allowed Required Multiple Multiple filter values predicates allowed allowed Wildcard allowed Length (min-max) Default value Workstation The name of the workstation associated with the job stream instance. The value of the deadline restriction of the job stream instance. The value of the until restriction of the job stream instance. string PlanNumber numeric JobStreamUntil This event is sent when the latest start time of a job stream has elapsed. Parameters of JobStreamUntil event types. Table 86. True if the job stream instance contains key jobs. but is used for correlation with other events. The run number of the Plan running when the event was generated. Parameters of JobStreamCompleted event types. The name of the workstation associated with the job stream instance (same value as in Workstation. The job stream priority. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length Default (minvalue max) IPAddress The IP address of the computer that sent the event. This is the same value as the Job Stream Workstation property. string 1 JobStreamWorkstation string U U U U U 1 16 * JobStreamID JobStreamName string string U U U U U 1 16 * JobStreamSchedTime datetime numeric (0-101) boolean U U Priority U U U Monitored U U LatestStart datetime U U Deadline datetime U U Appendix A. The scheduled time of the job stream instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 85. The ID of the job stream instance. Event-driven workload automation event and action definitions 523 .

WAIT. Waiting string Value can be: ABEND. U U 1 UntilAction U U 1 TimeStamp When the event was generated. CANCL. USER. CANCP. Parameters of JobStreamUntil event types. Running. SUCCP. The IP address of the computer that sent the event. ERROR. Ready. Held. 524 IBM Tivoli Workload Scheduler: Reference Guide . The new status of Cancelled. the job stream Error. instance. RJOB. SUSP. Undecided. FENCE. The fully qualified host name of the computer that sent the event. INTRO. Successful. Continue. PEND. FAIL. READY. DONE. Suppress datetime Status U U 1 InternalStatus The new internal status of the job stream instance. HOLD. The run number of the Plan running when the event was generated. WAITD string The action taken after the until restriction time has elapsed. EXTRN. SCHED. SUCC. ABENP. Hostname string 1 IPAddress string PlanNumber numeric JobStreamSubmit This event is sent when a job stream is submitted. EXEC. Value can be: Cancel. (continued) Property name Description Type Filtering allowed Required Multiple Multiple filter values predicates allowed allowed Wildcard allowed Length (min-max) Default value string Value can be: Blocked.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 86.

The job stream priority. The fully qualified host name of the computer that sent the event. The value of the until restriction of the job stream instance. The name of the workstation associated with the job stream instance (same value as in Workstation. The scheduled time of the job stream instance. The ID of the job stream instance. Property name Description Type Filtering allowed Required Multiple Multiple filter values predicates allowed allowed Wildcard allowed Length (minmax) Default value Workstation The name of the workstation associated with the job stream instance. The IP address of the computer that sent the event. Event-driven workload automation event and action definitions 525 . The run number of the Plan running when the event was generated. The name of the job stream instance. Parameters of JobStreamSubmit event types. True if the job stream instance contains key jobs. string 1 JobStreamWorkstation string U U U U U 1 16 * JobStreamID JobStreamName string string U U U U U 1 16 * JobStreamSchedTime datetime numeric (0-101) boolean U U Priority U U U Monitored U U LatestStart datetime U U Deadline datetime U U TimeStamp datetime Hostname string 1 IPAddress string PlanNumber numeric JobStreamCancel This event is sent when a job stream is cancelled. Appendix A. The value of the deadline restriction of the job stream instance.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 87. but is used for correlation with other events. This is the same value as the Job Stream Workstation property. When the event was generated.

Cancelled. The name of the job stream instance. The name of the workstation associated with the job stream instance (same value as in Workstation. The scheduled time of the job stream instance. Held. Parameters of JobStreamCancel event types. string 1 JobStreamWorkstation string U U U U U 1 16 * JobStreamID JobStreamName string string U U U U U 1 16 * JobStreamSchedTime datetime numeric (0-101) boolean U U Priority U U U Monitored U U LatestStart datetime U U Deadline datetime U U string Value can be: Blocked. True if the job stream instance contains key jobs. The value of the until restriction of the job stream instance. Successful. The job stream priority. Running. The value of the deadline restriction of the job stream instance. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value Workstation The name of the workstation associated with the job stream instance. This is the same value as the Job Stream Workstation property. Waiting Status The new status of the job stream instance. The ID of the job stream instance. Error. 1 526 IBM Tivoli Workload Scheduler: Reference Guide .| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 88. Ready. but is used for correlation with other events. Undecided.

FAIL. CANCL. WAITD datetime InternalStatus The new internal status of the job stream instance. The fully qualified host name of the computer that sent the event. ABENP. INTRO. The run number of the Plan running when the event was generated. RJOB. string 1 Appendix A. PEND. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value Workstation The name of the workstation associated with the job stream instance. SUCC. you must configure local option: bm check deadline = 300 See the Planning and Installation guide for further reference. The IP address of the computer that sent the event. ERROR. DONE. EXTRN. Hostname string 1 IPAddress string PlanNumber numeric JobStreamLate This event is sent when a job stream becomes late. Parameters of JobStreamLate event types. CANCP. 1 TimeStamp When the event was generated. To properly use this event type and to trigger an action. WAIT. HOLD. EXEC. SCHED. USER. Parameters of JobStreamCancel event types. READY. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value string Value can be: ABEND. FENCE. SUSP.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 88. Table 89. Event-driven workload automation event and action definitions 527 . SUCCP.

RJOB. PEND. READY. Error. SUSP. EXEC. Undecided. string U U U U U 1 16 * JobStreamID JobStreamName string string U U U U U 1 16 * JobStreamSchedTime datetime numeric (0-101) boolean U U Priority U U U Monitored U U LatestStart datetime U U Deadline datetime U U string Value can be: Blocked. Successful. The value of the deadline restriction of the job stream instance. The job stream priority. EXTRN. U U 1 TimeStamp When the event was generated.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 89. Waiting string Value can be: ABEND. DONE. FAIL. SCHED. HOLD. The name of the job stream instance. ERROR. FENCE. Running. 528 IBM Tivoli Workload Scheduler: Reference Guide . True if the job stream instance contains key jobs. Held. Cancelled. USER. WAITD datetime Status The new status of the job stream instance. Ready. INTRO. The value of the until restriction of the job stream instance. CANCP. SUCCP. The scheduled time of the job stream instance. WAIT. The ID of the job stream instance. U U 1 InternalStatus The new internal status of the job stream instance. CANCL. ABENP. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value JobStreamWorkstation The name of the workstation associated with the job stream instance (same value as in Workstation. Parameters of JobStreamLate event types. SUCC.

TRUE if the workstation is running. The fully qualified host name of the computer that sent the event. Appendix A. string 1 IPAddress string PlanNumber numeric WorkstationStatusChanged This event is sent when a workstation is started or stopped. The reason why batchman (or jobman) was terminated. The run number of the Plan running when the event was generated. Significant only if one of them is not running. Property name Description Type Filtering allowed Required Multiple values allowed U Multiple filter predicates allowed U Wildcard allowed Length (minmax) 1 16 Default value Workstation The name of the workstation. Parameters of JobStreamLate event types. Table 90. Stop 1 StopReason TimeStamp datetime Hostname string 1 IPAddress string PlanNumber The run number of the Plan running when the numeric event was generated. string U U U Running boolean U U string Value can be: Abend. ApplicationServerStatusChanged This event is sent when the embedded WebSphere Application Server has stopped or is restarting. The date and time when the event was generated. The IP address of the computer that sent the event. Parameters of WorkstationStatusChanged event types. The IP address of the computer that sent the event. Event-driven workload automation event and action definitions 529 . (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value Hostname The fully qualified host name of the computer that sent the event. FALSE if it is stopped.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 89.

530 IBM Tivoli Workload Scheduler: Reference Guide . Significant only if the application server is not running. Is significant only if the application server is not running and Restarting is false. The IP address of the computer that sent the event. Stop U 1 StopReason Restarting boolean U U string Value can be: No auto start. Significant only if it is not running. The run number of the Plan running when the event was generated. Maximum restart exceeded. The date and time when the event was generated. True if the system will retry automatically to start the application server. False if stopped. Parameters of ApplicationServerStatusChanged event types. string U U U * Running boolean U U string Value can be: Unexpected end. Property name Description Type Filtering allowed Required Multiple values allowed U Multiple filter predicates allowed U Wildcard allowed Length (minmax) 1 16 Default value Workstation The name of the workstation True if the application server on the workstation is running. Terminated too quickly NoRestartReason U 1 TimeStamp datetime Hostname string 1 IPAddress string PlanNumber numeric ChildWorkstationLinkChanged This event is sent when the workstation defined in the event rule links or unlinks one of its child workstations. The reason why the application server was terminated.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 91. The fully qualified hostname of the computer that sent the event. The reason why the system will not automatically start the application server.

can be: Available only Broken. Property name Description Type Filtering Required allowed Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (min-max) Default value Workstation The name of the workstation that is sending the event. Table 93. The IP address of the computer that sent the event. The name of the parent workstation that is changing link status. The fully qualified hostname of the computer that sent the event. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value Workstation The name of the child workstation that is changing link status. Unlinked U 1 UnlinkReason Shows the string reason why the workstation Value was unlinked. Parameters of ParentWorkstationLinkChanged event types. When the event datetime was generated.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 92. Value can be: Linked. Parameters of ChildWorkstationLinkChanged event types. 1 TimeStamp Hostname string 1 IPAddress string PlanNumber numeric ParentWorkstationLinkChanged This event is sent when the parent workstation of the workstation defined in the event rule is linked or unlinked. if LinkStatus is Dropped Unlinked. The parent workstation will send a ChildWorkstationLinkChanged event when the link in the other direction is established or lost. string U U U U U 1 16 * ParentWorkstation string U U U U 1 16 string LinkStatus The new link status of the workstation. string U U U U U 1 16 * ParentWorkstation string U U U U 1 16 Appendix A. Event-driven workload automation event and action definitions 531 . The run number of the Plan running when the event was generated. The name of the workstation that is sending the event.

Parameters of PromptStatusChanged event types. LinkStatus is Dropped Unlinked. JobLocal. RepliedYes string U U 1 Type The type of the prompt. Value can be: Asked. JobStreamLocal U U 1 RecoveryPrompt Indicates if the prompt is a recovery prompt. The run number of the Plan running when the event was generated. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed U Wildcard allowed Length (minmax) Default value Name The name or the number of the prompt. Available only when the status is asked. can be: Available only if Broken. When the event was generated. The IP address of the computer that sent the event. RepliedNo. Value can be: Global. Table 94. string U U U U 1 8 * Text string string U U U U Status The status of the prompt.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 93. Parameters of ParentWorkstationLinkChanged event types. datetime 1 TimeStamp Hostname string 1 IPAddress string PlanNumber numeric PromptStatusChanged This event is sent when a prompt is asked or replied. (continued) Property name Description Type Filtering Required allowed Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (min-max) Default value string LinkStatus The new link status of the workstation. The fully qualified host name of the computer that sent the event. The text of the prompt. Value can be: Linked. boolean U U 532 IBM Tivoli Workload Scheduler: Reference Guide . Unlinked U 1 UnlinkReason Shows the reason string why the workstation was Value unlinked.

Event-driven workload automation event and action definitions 533 . Parameters of PromptStatusChanged event types. The name of the workstation associated with the job stream instance that owns the prompt (or that contains the job instance that owns the prompt). Available only for local prompts owned by jobs. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value Workstation The name of the workstation associated with the job instance or job stream instance that owns the prompt. The scheduled time of the job stream instance that owns the prompt (or that contains the job instance that owns the prompt). Available only for local prompts. The ID of the job stream instance that owns the prompt (or that contains the job instance that owns the prompt). The name of the job stream instance that owns the prompt (or that contains the job instance that owns the prompt). Available only for local prompts.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 94. The name of the job instance that owns the prompt. Available only for local prompts. string U U U U 1 JobStreamWorkstation string U U U U 1 JobStreamID string JobStreamName string U U U U 1 JobStreamSchedTime datetime U U JobName string U U U U 1 Appendix A. Available only for local prompts. Available only for local prompts.

The IP address of the computer that sent the event. The IP address of the computer that sends the event. Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) 1 Default value FileName string U U U SampleInterval numeric U U U 60 Workstation string U U 1 16 TimeStamp datetime Hostname string U U U U 1 IPAddress string EventRuleId string FileDeleted This event is sent when a specified file is deleted. The run number of the Plan running when the event was generated. Property name Description The absolute path and filename(s) of the specified file(s). The time when the event is sent. The interval (in seconds) with which the specified file is monitored.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 94. numeric The name of the workstation for which the event is generated. Parameters of PromptStatusChanged event types. The fully qualified host name of the computer that sent the event. 534 IBM Tivoli Workload Scheduler: Reference Guide . The fully qualified host name of the computer that sends the event. FileCreated This event is sent when a specified file is created. Parameters of FileCreated event types. The identifier of the event rule. Table 95. (continued) Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value TimeStamp When the event was generated. datetime Hostname string 1 IPAddress string PlanNumber numeric FileMonitor events FileMonitor events are: v FileCreated v FileDeleted v ModificationCompleted v LogMessageWritten The following tables show the parameters of each event type.

Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) 1 Default value FileName string U U U SampleInterval numeric U U U 60 Workstation string U U 1 16 TimeStamp datetime Hostname string U U U U 1 IPAddress string EventRuleId string ModificationCompleted This event is sent when a specified file has not been modified in two consecutive monitoring cycles after any of the following: v Its creation v A detected modification.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 96. The identifier of the event rule. The name of the workstation for which the event is generated. The fully qualified host name of the computer that sends the event. Property name Description The absolute path and filename(s) of the specified file(s). The interval (in seconds) with which the specified file is monitored. The IP address of the computer that sends the event. Table 97. Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) 1 Default value FileName string U U U SampleInterval numeric U U U 60 LastWriteTime datetime U U U Workstation string U U 1 16 TimeStamp datetime Hostname string U U U U 1 IPAddress string EventRuleId string Appendix A. The time when the event is sent. Property name Description The absolute path and filename(s) of the specified file(s). Event-driven workload automation event and action definitions 535 . The interval (in seconds) with which the specified file is monitored. The time when the event is sent. The fully qualified host name of the computer that sends the event. Parameters of FileDeleted event types. The IP address of the computer that sends the event. numeric The time when the specified file was last modified. The identifier of the event rule. numeric The name of the workstation for which the event is generated. Parameters of ModificationCompleted event types.

It does not report the number of matches currently in the file. If you make changes to a file section that has already undergone scanning. The size of the log file (in bytes) when the most recent matching log file entry was found.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LogMessageWritten This event is sent when a specific string is found in a file. The identifier of the event rule. string U U U 1 Matches numeric U U U MatchExpression string U U 1 LastWriteTime datetime U U U Size filesize U U U SampleInterval numeric U U U 60 Workstation string U U 1 16 TimeStamp datetime Hostname string U U U U 1 IPAddress string Linetext string EventRuleId string Datetime Contains both date and time. The string to look for in the log file(s) being monitored. The contents of the line where the search string was found. Table 98. The time when the event is sent. The time when the specified file was last modified. Parameters of LogMessageWritten event types. The number of matches found since monitoring started. Already scanned portions of the file are not checked again. these changes will not be detected in the current monitoring process. Property name Description Type Filtering allowed Required Multiple values allowed Multiple filter predicates allowed Wildcard allowed Length (minmax) Default value FileName The absolute path and filename(s) of the specified file(s). The interval (in seconds) with which the specified file is monitored. Be aware of the following when you change or delete and create the file again during the monitoring activity: v The matches parameter counts the total number of matches found since monitoring started. The IP address of the computer that sends the event. v The scanning mechanism is such that at each sample period. 536 IBM Tivoli Workload Scheduler: Reference Guide . there may be a discrepancy between the number of matches recorded and the ones presently shown in the file. numeric The name of the workstation for which the event is generated. The fully qualified host name of the computer that sends the event. You can specify either one or both values in the filter. scanning is picked up from the last know position. If you change the file while monitoring is in progress.

Warning string U 1 U Required Length (min-max) 1 1 1 Default value 1 Appendix A. Multiple values allowed You can specify multiple values for this property within a single filter predicate. Normal. Parameters of TECFWD action types. Action providers and definitions This section gives details on the action types of the following action providers: v TECEventForwarder v MailSender v MessageLogger v TWSAction v GenericAction TECEventForwarder actions This provider implements a single action named TECFWD that forwards the event to an external TEC (Tivoli Enterprise Console) server (or any other application capable of listening to events in TEC format). Wildcard allowed Supported wildcards are asterisk (*) and question mark (?). Property name Host Port Message Description Host name or IP of the TEC recipient Port number of the TEC recipient The event message The severity of the event message The line of business impacted by the situation reported by the event Type string numeric string string Value can be: Critical. The following table lists the parameters of TECFWD: Table 99. The provider uses a default TEC server whose host name and port can be defined with optman. The event will match the event condition if all the predicates are satisfied. Event-driven workload automation event and action definitions 537 . The filter will be satisfied when one of the values is matched. Fatal. The TEC used as recipient can be overridden by action settings.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LOB Severity Multiple filter predicates allowed You can specify multiple filter predicates for this property.

Multiple addresses can be specified using commas as separators. Property name Description The main receiver list. The body of the mail. Multiple addresses can be specified using commas as separators. Parameters of SendMail action types. Type Required Length (min-max) Default value To string U 1 Cc string 1 Bcc string 1 Subject Body string string U 1 1 538 IBM Tivoli Workload Scheduler: Reference Guide . The subject of the mail. Multiple addresses can be specified using commas as separators. The blank copied receiver list. Parameters of TECFWD action types. You can use optman to customize the following related attributes: v Mail sender v SMTP server v SMTP port number v Mail user name v Mail user password v SSL The following table lists the parameters of SendMail: Table 100.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 99. The copied receiver list. (continued) Property name Parm_1 Parm_2 Parm_3 Parm_4 Parm_5 Parm_6 Parm_7 Parm_8 Parm_9 Parm_10 Custom parameters Description Type string string string string string string string string string string Required Length (min-max) 1 1 1 1 1 1 1 1 1 1 Default value MailSender actions This provider implements a single action named SendMail that connects to an SMTP server to send an e-mail.

There is an automatic cleanup based on a FIFO policy. Event-driven workload automation event and action definitions 539 . Error Default is Info ObjectKey A key identifying the object to which the message pertains A custom string that identifies the source The line of business impacted by the situation reported by the message The group of operators in whose queue the message is placed string U 1 Required U Length (min-max) 1 Default value Severity U 1 Info Source string 1 LOB string 1 Group string 1 TWSAction actions TWSAction actions are: v SubmitJobStream v SubmitJob v SubmitAdHocJob v ReplyPrompt The following tables show the parameters of each action type. Table 102.| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MessageLogger actions This provider implements a single action named MSGLOG that logs the occurrence of a situation in an internal auditing database. The following table lists the parameters of MSGLOG: Table 101. Property name JobStreamName Description The name of the job stream The name of the workstation associated with the job streami Type string string JobStreamWorkstationName Value can be: Info. Property name Message Description The message Type string string The severity of the message Value can be: Info. SubmitJobStream This action submits a job stream. Warning. Error U 1 16 Required U Length (min-max) 1 16 Default value Appendix A. The number of entries within the auditing database is configurable. Parameters of SubmitJobStream action types. Parameters of MSGLOG action types. Warning.

Next (closest next job job stream instance stream). (continued) Property name JobStreamSchedTime JobStreamAlias Parm_1 Parm_2 Parm_3 Parm_4 Parm_5 Parm_6 Parm_7 Parm_8 Parm_9 Parm_10 Custom parameters Description The scheduled time of the job stream instance The job stream alias Type datetime string string string string string string string string string string string 1 1 1 1 1 1 1 1 1 1 1 16 Required