Tivoli Workload SchedulerReference
Tivoli Workload SchedulerReference
Reference Guide
SC32-1274-02
Reference Guide
SC32-1274-02
Note Before using this information and the product it supports, read the information in Notices on page 331.
Third Edition (December 2004) This edition applies to version 8, release 2, modification level 0 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 SC32127401. Copyright International Business Machines Corporation 1999, 2004. 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 guide . . . . . . . . . . xi
Who should read this guide . . . . . . . . . xi What this guide contains . . . . . . . . . . xi Publications . . . . . . . . . . . . . . xii IBM Tivoli Workload Scheduler library . . . . xii Related publications . . . . . . . . . . xv Accessing publications online . . . . . . . xvi Ordering publications. . . . . . . . . . xvi Providing feedback about publications . . . . xvi Accessibility . . . . . . . . . . . . . xvii Tivoli technical training . . . . . . . . . . xvii Support information . . . . . . . . . . . xvii Conventions used in this guide . . . . . . . xvii Typeface conventions . . . . . . . . . xvii Operating system-dependent variables and paths . . . . . . . . . . . . . . . xviii Command syntax. . . . . . . . . . . xviii The wmaeutil command . . . . . . . . . 28
| Chapter 1. Quick start . . . . . . . . . 1 | Creating a plan . . . . . . . . . . . . . 1 | Managing jobs and job streams . . . . . . . . 5
. . Automating the production cycle . . . . . . Customizing the final job stream . . . . . Adding the final job stream . . . . . . . Starting a production cycle . . . . . . . Managing the production environment . . . . Choosing the IBM Tivoli Workload Scheduler Start of Day . . . . . . . . . . . . Changing the start of day . . . . . . . Creating a plan for future or past dates . . . Using reports . . . . . . . . . . . . Launching jobs . . . . . . . . . . . . Job environment variables . . . . . . . Standard configuration script - jobmanrc . . Local configuration script - $HOME/.jobmanrc Production processing commands . . . . . . The schedulr command . . . . . . . . The compiler command . . . . . . . . The stageman command . . . . . . . . The logman command . . . . . . . . .
Copyright IBM Corp. 1999, 2004
iii
showschedules . . shutdown . . . start . . . . . status . . . . . stop . . . . . stop ;progressive . submit docommand submit file . . . submit job . . . submit sched . . switchmgr . . . system . . . . tellop . . . . . unlink . . . . . version . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
194 197 198 200 201 203 204 206 208 210 212 213 214 215 217
iv
Workstation definition . . . . Access method interface . . . . . Method command line syntax . . Method response messages . . . Method options file . . . . . Method execution . . . . . . . Launch job (LJ) task . . . . . Manage job (MJ) task . . . . . Check file (CF) task . . . . . Get status (GS) task . . . . . The cpuinfo command . . . . Troubleshooting . . . . . . . Job standard list error messages . Method not executable . . . . Console Manager messages . . . Composer and compiler messages Jobman messages . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
279 279 279 282 282 283 283 284 284 285 286 286 286 286 286 286 286
Search the information center at the IBM support Web site . . . . . . . . . . . Search the Internet . . . . . . . . . . Obtaining fixes . . . . . . . . . . . . . Contacting IBM Software Support . . . . . . Determine the business impact of your problem Describe your problem and gather background information . . . . . . . . . . . . . Submit your problem to IBM Software Support
. 292 . 293
| Appendix B. Managing time zones 319 | Activating the Time Zone feature . . . . . . . 319 | Running a job stream not time zoneenabled | when the master domain manager is ahead of | the fault-tolerant agent . . . . . . . . . 320 | Running a job stream time zoneenabled when | the master is ahead of the fault-tolerant agent . 320 | Running a job stream not time zoneenabled | when the master domain manager is behind the | fault-tolerant agent. . . . . . . . . . . 320 | Running a job stream time zoneenabled when | the master domain manager is behind the | fault-tolerant agent. . . . . . . . . . . 321 | Submitting ad hoc a job stream specifying an at | dependency . . . . . . . . . . . . . 321 | Submitting a job stream specifying an at | dependency that occurs during daylight saving | time . . . . . . . . . . . . . . . 322 | Time zone list . . . . . . . . . . . . . 322
| | | | | | | | | | |
Notices . . . . . . . . . . . . . . 331
Trademarks . . . . . . . . . . . . . . 332
Contents
vi
Figures
| 1. | 2.
3. 4. Process tree on UNIX . . . . . . . . . 10 Process tree on Windows . . . . . . . . 12 Network links . . . . . . . . . . . 160 Started workstations in network . . . . . 199 5. 6. 7. 8. Stopped workstations in network . Unlinked network workstations . Local and remote networks . . . Dead zones . . . . . . . . . . . . . . . . . . . . . . . . 202 216 290 319
vii
viii
Tables
|
1. 2. 3. 4. 5. 6. Command syntax . . . . . . . . . . Job environment variables. . . . . . . Variables of jobmanrc . . . . . . . . List of reserved words . . . . . . . . Values for the supported operating systems Type of communication depending on the securitylevel value. . . . . . . . . . xviii . 16 . 17 . 32 34 . 36 7. 8. 9. 10. 11. 12. 13. Comparison operator Logical operators. . Comparison operator Logical operators. . Object attributes . Actions . . . . Actions (continued) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 . 44 . 97 . 98 . 301 . 302 . 302
| | |
ix
xi
v v
Describes the scheduling objects that you can define in the IBM Tivoli Workload Scheduler database and explains the usage and syntax of the commands used in the composer program to manage these objects in the database. Chapter 4, The scheduling language, on page 81 Explains how to create a job stream, based on the scheduling objects defined in the IBM Tivoli Workload Scheduler database, using the composer command. Chapter 5, Conman reference, on page 115 Describes the conman command line interface. This is used to monitor and manage jobs and job streams during a production day. Chapter 6, Utility commands, on page 219 Describes the IBM Tivoli Workload Scheduler utility commands that manage the environment. Chapter 7, The report commands, on page 267 Describes how to print different types of reports. Chapter 8, The Extended Agent reference, on page 279 Describes how to create and use extended agents to extend IBM Tivoli Workload Scheduler job scheduling functions to other systems and applications such as local or remote UNIX Systems, Peoplesoft, SAP R/3, z/OS, OPC, Oracle CCM, and VMS.
v Chapter 9, The Network Agent reference, on page 289 Describes how to create and use a network agent workstation to manage scheduling internetwork dependencies. v Chapter 10, Setting User Security Definitions, on page 297 Describes how to manage the Security File. v Appendix A, Support information, on page 315 Describes the different options for obtaining support for IBM products. v Appendix B, Managing time zones, on page 319 Lists the time zones supported by IBM Tivoli Workload Scheduler. v Appendix C, The auditing feature, on page 325 Describes how to enable and use the auditing option to track changes applied to the database and to the plan.
Publications
This section lists publications in the Tivoli Workload Scheduler library and any other related documents. It also describes how to access Tivoli publications online and how to order Tivoli publications. | | | | | | | | |
xii
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
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 Tivoli Workload Scheduler for Applications library This library contains all publications that apply only to IBM Tivoli Workload Scheduler for Applications. 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.
xiii
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Provides information about how to administer IBM Tivoli Workload Scheduler on platforms other than z/OS, and what to do if things go wrong. It includes help on many messages generated by the main components of IBM Tivoli Workload Scheduler. v IBM Tivoli Workload Scheduler: Limited Fault-tolerant Agent for OS/400, SC32-1280 Describes how to install, configure, and use IBM Tivoli Workload Scheduler limited fault-tolerant agents on AS/400. v IBM Tivoli Workload Scheduler: Plus Module Users Guide, SC32-1276 Describes how to set up and use the IBM Tivoli Workload Scheduler Plus module. See http://www.ibm.com/software/tivoli/products/scheduler/ for an introduction to the product.
xiv
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Provided with the installation tape for Tivoli Workload Scheduler for z/OS (program 5698-WSC), describes all of the installation materials and gives installation instructions specific to the product release level or feature number. See http://www.ibm.com/software/tivoli/products/scheduler-zos/ for an introduction to the product.
IBM IBM Tivoli Workload Scheduler for Virtualized Data Centers library
The following manuals are available in the IBM IBM Tivoli Workload Scheduler for Virtualized Data Centers library: v IBM Tivoli Workload Scheduler for Virtualized Data Centers: Release Notes, SC32-1453 Provides late-breaking information about IBM Tivoli Workload Scheduler for Virtualized Data Centers. v IBM Tivoli Workload Scheduler for Virtualized Data Centers: Users Guide, SC32-1454 Describes how to extend the scheduling capabilities of IBM Tivoli Workload Scheduler to workload optimization and grid computing by enabling the control of IBM LoadLeveler and IBM Grid Toolbox jobs. See http://www.ibm.com/software/info/ecatalog/en_US/ products/Y614224T20392S50.html for an introduction to the product.
Related publications
The following documents also provide useful information: v IBM Redbooks: High Availability Scenarios with IBM Tivoli Workload Scheduler and IBM Tivoli Framework This IBM Redbook, shows you how to design and create highly available IBM Tivoli Workload Scheduler and IBM Tivoli Management Framework (TMR server, Managed Nodes and Endpoints) environments. It presents High Availability Cluster Multiprocessing (HACMP) for AIX and Microsoft Windows Cluster Service (MSCS) case studies. This Redbook can be found on the Redbooks Web site at http://www.redbooks.ibm.com/abstracts/sg246632.html v IBM Redbooks: Customizing IBM Tivoli Workload Scheduler for z/OS V8.2 to Improve Performance 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). This Redbook can be found on the Redbooks Web site at http://www.redbooks.ibm.com/abstracts/sg246352.html
About this guide
xv
v IBM Redbooks: End-to-End Scheduling with IBM Tivoli Workload Scheduler Version 8.2 This IBM Redbook considers how best to provide end-to-end scheduling using Tivoli Workload Scheduler Version 8.2, both distributed (previously known as Maestro) and mainframe (previously known as OPC) components. This Redbook can be found on the Redbooks Web site at http://www.redbooks.ibm.com/abstracts/sg246624.html The Tivoli Software Glossary includes definitions for many of the technical terms related to Tivoli software. TheTivoli Software Glossary is available at the following Tivoli software library Web site: http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm
Ordering publications
You can order many Tivoli publications online at the following Web site: http://www.elink.ibmlink.ibm.com/public/applications/ publications/cgibin/pbi.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 In other countries, see the following Web site for a list of telephone numbers: http://www.ibm.com/software/tivoli/order-lit/
xvi
http://www.ibm.com/software/sysmgmt/products/support
Accessibility
Accessibility features help users with a physical disability, such as restricted mobility or limited vision, to use software products successfully. With this product, you can use assistive technologies to hear and navigate the interface. You can also use the keyboard instead of the mouse to operate all features of the graphical user interface. For additional information, see the Accessibility Appendix in the IBM Tivoli Job Scheduling Console Users Guide.
Support information
If you have a problem with your IBM software, you want to resolve it quickly. 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, Technotes, and other information. v Obtaining fixes: You can locate the latest fixes that are already available for your product. v Contacting IBM Software Support: If you still cannot solve your problem, and you need to work with someone from IBM, you can use a variety of ways to contact IBM Software Support. For more information about these three ways of resolving problems, see Appendix A, Support information, on page 315.
Typeface conventions
This guide 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, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes, multicolumn lists, containers, menu choices, menu names, tabs, property sheets), labels (such as Tip:, and Operating system considerations:) v Keywords and parameters in text Italic v Words defined in text
About this guide
xvii
v Emphasis of words (words as words) v New terms in text (except in a definition list) v Variables and values you must provide Monospace v Examples and code examples v File names, programming keywords, 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
Command syntax
This guide uses the following syntax wherever it describes commands:
Table 1. Command syntax Syntax convention Brackets ([ ]) Braces ({ }) Underscore ( _ ) Vertical bar ( | ) Description The information enclosed in brackets ([ ]) is optional. Anything not enclosed in brackets must be specified. Braces ({ }) identify a set of mutually exclusive options, when one option is required. An underscore (_) connects multiple words in a variable. Mutually exclusive options are separated by a vertical bar( | ). You can enter one of the options separated by the vertical bar, but you cannot enter multiple options in a single use of the command. A vertical bar can be used to separate optional or required options. Bold text designates literal information that must be entered on the command line exactly as shown. This applies to command names and non-variable options. Italic text is variable and must be replaced by whatever it represents.
Bold
Italic
xviii
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Creating a plan
To create a plan that runs daily, perform the following steps: 1. Log in to a shell on the Master Domain Manager Log in using the user ID you specified at installation time and from that shell perform all the operations described in the following steps.
Copyright IBM Corp. 1999, 2004
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
2. Start the IBM Tivoli Workload Scheduler processes Perform this step from the user command line by running the Startup command to start the scheduler network management process. For more details about the Startup command, refer to StartUp on page 255. 3. Add in the database the definitions to describe the topology of your scheduling environment This step can be divided as follows: a. Define the workstations in your environment A workstation is usually a physical workstation on which jobs and job streams are run, however, in the case of extended agents, the workstations are logical definitions hosted by a physical workstation. 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 IBM Tivoli Workload Scheduler installation. For additional information, refer to Workstation definitions on page 33. b. Define domains Use this step if you want to create a hierarchical tree of the path through the domains. IBM Tivoli Workload Scheduler works downwards through this tree when distributing the plan at the beginning of the production day, and upwards, when sending information back to the Master Domain Manager about jobs and job streams run on the target workstations. For additional information refer to Domain definitions on page 40. 4. Define users allowed to run jobs on Windows workstations On Windows workstations only, define any user allowed to run jobs using IBM Tivoli Workload Scheduler by specifying username and password. For additional information refer to User definitions on page 47. 5. Define dependencies Dependencies are conditions that must be met before a job can start. They can be defined for the job stream itself, for a job within the job stream, or for both. The maximum number of dependencies that can be set for a job or job stream is 40. For additional information refer to Chapter 4, The scheduling language, on page 81. These are some of the dependencies that you can set: a. Time dependencies Set a time dependency to specify the earliest or latest time a job or job stream can be started or the time within which a job or job stream must complete. You can also identify
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
days when the job stream should not run. For more details, refer to Keywords on page 82. b. Open file dependencies Use open file dependencies to specify files that must be available before a job or job stream can be started. For more details, refer to opens on page 108. c. Follow dependencies Set a follow dependency to define other jobs and job streams that must complete successfully before a job or job stream. For more details, refer to follows on page 93. d. Resources Use resources to specify physical or logical objects belonging to a workstation that are required to run a job on that workstation. Because resource availability is checked before running jobs on a specific workstation, resources can be used as dependencies to make job and job stream management more flexible. For example, you can define a resource called TAPES, with a value of 2, identifying the two system tape drives and then define two jobs that require that both tape drives are available as a dependency. Jobs with this dependency cannot run concurrently, because each time a job is run the TAPES resource is in use. For additional information refer to Resource definitions on page 54. e. Prompts Use a prompt when you want to associate a unique name to a textual message requesting an answer from the operator. Prompts are used as dependencies to prevent jobs from starting until an affirmative response is received. For additional information refer to Prompt definitions on page 52. f. Limit Set Limit to set the maximum number of jobs that can run simultaneously in a job stream. For additional information, refer to limit on page 103.
g. Priority Use this dependency to set the priority of a job or job stream. For additional information refer to priority on page 110. 6. Define jobs A job is a unit of work that runs on workstations, such as an executable file, program, or command scheduled and launched by IBM Tivoli Workload Scheduler as part of a job stream processing. It usually includes all necessary computer programs, links, files, and instructions to the operating system. It does not include scheduled
Chapter 1. Quick start
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 10. 7.
dates and times to run, because these are defined as arguments of the job streams definition. For additional information refer to Job definitions on page 42. Define job streams A job stream is an ordered sequence of jobs to be run respecting set dependencies. Jobs might be grouped together in a job stream because they all run on the same day, share a common function, or share common dependencies. For additional information refer to Chapter 4, The scheduling language, on page 81. 8. Define calendars A calendar defines if and when a job stream has to run. Use it to include or exclude days in a daily run cycle. A calendar definition can be assigned to one or more job streams. For additional information refer to Calendar definitions on page 49. 9. Define parameters that represent variables inside jobs or job streams A parameter definition is the mapping between a name and a value, this value being the value of a variable used in a job or in a job stream for a specific argument. Parameter names are replaced with the corresponding values inside the job or job stream definitions at the end of a processing day when the production plan is created for the next processing day. For additional information refer to Parameter definitions on page 50. Automate the plan generation at the end of the current production day Add the final job stream to the database to perform pre-production and post-production processing to ensure full automation of the plan generation at the end of each current production day. For additional information refer to Automating the production cycle on page 13. 11. Generate the plan Run the Jnextday command to generate the plan. This command starts the processing of the scheduling information stored in the database and creates the plan for the next production day. If you automated the plan generation as described in step 10, you only need to run the Jnextday command the first time. This plan is stored in a file named Symphony which is distributed from the Master Domain Manager down through the child domains at the start of day time (by default at 6:00 AM). Once the new production day has started, any modification you make in the objects stored in the database has no effect on the current production day processing except for the jobs and job streams or files submitted using conman sbj or conman sbs. For additional information refer to Chapter 2, The production cycle, on page 7. When you complete this step by step process, your scheduling environment is up and running, with batch processing of an ordered sequence of jobs and job streams being performed against resources defined on a set of workstations. By default, the first time you run the Jnextday command, the number of jobs that can run simultaneously on a workstation is zero, so make sure that you increase this value
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
by changing the cpu limit to allow job execution on that workstation, see the section limit cpu on page 157 for more details. This batch processing revolves around a 24 hour cycle and is generated again at the end of each production day by the Master Domain Manager.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
processes running on the system. For additional information on linking workstations, refer to link on page 159, and, on unlinking workstations refer to unlink on page 215. Stop, start or shutdown the IBM Tivoli Workload Scheduler processes Perform this operation to act on production processes, for example, the IBM Tivoli Workload Scheduler processes, except for the network management process. The shutdown operation stops all IBM Tivoli Workload Scheduler processes, including the network management process. For additional information refer to stop on page 201, start on page 198, and shutdown on page 197. Submit a command Perform this operation to submit a command on a workstation as a scheduler job. If not specified in the submit options, the job name defaults to a string that begins with the command name and the job stream defaults to JOBS. The events reporting the result of the execution are logged in the database. For additional information refer to submit docommand on page 204. Submit a job Perform this operation to submit a command to run a job defined in the database within a job stream during the current production day on a workstation which has received the plan. If not specified in the submit options, the job stream defaults to JOBS. This command can only be run on the Master Domain Manager. The events reporting the result of the execution are logged in the database. For additional information refer to submit job on page 208. Submit a job stream Perform this operation to submit a command to run job stream defined in the database during the current production day on a workstation which has received the plan. This command can only be run on the Master Domain Manager. The events reporting the result of the execution are logged into the database. For additional information refer to submit sched on page 210. Submit a file Perform this action if you want to submit a script file as a job within a job stream during the current production day on a workstation which has received the plan. If not specified in the submit options, the job name defaults to the file name and the job stream defaults to JOBS. The events reporting the result of the execution are logged in the database. For additional information refer to submit file on page 206.
User interfaces
A combination of graphical and command line interface programs is provided to run IBM Tivoli Workload Scheduler. The command line interface (CLI) is available for certain advanced features which are not available in the graphical user interface (Job Scheduling Console). The user interfaces are: Composer A command line program used to define scheduling objects and compose schedules.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Conman A command line program used to monitor and control the IBM Tivoli Workload Schedulers production environment. Job Scheduling Console An interactive graphical interface used to create, modify, and delete objects in the product database and plan.
Security commands
The following commands are used to define and maintain user privileges. dumpsec The command which creates an editable copy of the product security file. makesec The command which compiles and installs the product security file.
Production processes
The following are the IBM Tivoli Workload Scheduler production processes: Netman The process which receives service requests and invokes appropriate programs. Mailman The process which routes messages to either local or remote workstations. Batchman The process which communicates directly with the plan and updates it. Jobman (on Windows and UNIX), Jobmon (on Windows), joblnch.exe (on Windows) The processes which control the actual execution of jobs. They are responsible for launching and tracking jobs using the scripts jobmanrc and .jobmanrc. For information about these scripts, see Launching jobs on page 16. Writer The process, generated by Netman, which establishes the link between workstations in the IBM Tivoli Workload Scheduler network.
| | | |
netman
mailman
writer
batchman
serverA (mailman)
jobman
jobmanrc
jobmanrc
jobmanrc
.jobmanrc
.jobmanrc
.jobmanrc
job file
Figure 1. Process tree on UNIX
job file
job file
10
| | | |
11
netman.exe
mailman.exe
writer.exe
batchman.exe
serverA (mailman.exe)
jobman.exe
jobmon.exe
joblnch.exe
joblnch.exe
joblnch.exe
jobmanrc.cmd
jobmanrc.cmd
jobmanrc.cmd
job file
Figure 2. Process tree on Windows
job file
job file
12
13
use this Sfinal file or create and customize a new one. See the IBM Tivoli Workload Scheduler Planning and Installation Guide version 8.2 for details about customizing the final job stream. The following is an example of configuring a master domain manager after the installation: 1. Log in as TWS user. 2. Run the tws_env script to set the IBM Tivoli Workload Scheduler environment as follows: v UNIX: on C shells launch source/tws_home/tws_env.sh v UNIX: on Korn shells launch ./tws_home/tws_env.sh v From a Windows command line: launch \tws_home\tws_env.cmd Where tws_home represents the product installation directory. 3. Run the composer command. 4. 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 created a new one, use its name in place of Sfinal.
This performs pre-production processing and starts the scheduler production processes. Note: Do not update or build the Tivoli Workload Scheduler database while Jnextday is running, as this could damage the database. 3. When the Jnextday job completes, check the status of IBM Tivoli Workload Scheduler:
conman status
If the IBM Tivoli Workload Scheduler started correctly, the status is Batchman=LIVES. 4. Raise the limit to allow jobs to run. The default job limit after installation is zero. This means no jobs will run, so you might want to raise the job limit now:
conman "limit;10"
14
v Late afternoon v Midnight These are a few of the scheduling implications: Start Time and Latest Start Time Start times (at keyword) are always specified in relation to the scheduler production day start time. You may need to add + 1 day to job streams whose jobs run across production days. Also, ensure that the latest start time (until keyword) is a time later than the start time. On keyword Production and calendar days might not be the same. If your production day starts at 06:00 a.m. (the default setting), 05:59 a.m. will be the last minute of the production day. A job stream defined to run ON MONDAY at 05:30 will be selected on Monday and will run on the calendar day Tuesday at 5:30 a.m. Carryforward keyword Placing the start of day near midnight to correspond with the calendar day will tend to produce a large number of carried forward job streams. This may increase the complexity of managing the data center. Deadline Notifications are sent when jobs and job streams have reached their deadline but have not yet started, or have not yet finished running. A deadline specifies the time within which a job or job stream must complete.
With the date option you can specify to create a plan based on a future or past day of processing. 3. Run the compiler command to create a Symnew file:
compiler (-date ddmmyyyy)
You can use the date option with the compiler to specify todays date or the date of the day you are trying to re-create. This option may be necessary if you
Chapter 2. The production cycle
15
have job streams that contain date sensitive input parameters. The scheddate parameter is keyed off the date specified with the compiler command. 4. Run console manager to stop scheduler processes:
conman stop @!@;wait
If you have defined at least one workstation as behindfirewall in an IBM Tivoli Workload Scheduler Version 8.2 network, you must enter the following command:
conman stop ;progressive
Using reports
Use reports to help you manage the production cycle. For more information, see Chapter 7, The report commands, on page 267 and reptr command on page 273.
Launching jobs
Jobs are launched under the direction of the production control process Batchman. Batchman resolves all job dependencies to ensure the correct order of execution, and then issues a job launch message to the Jobman process. Jobman spawns a job monitor process that begins by setting a group of environment variables, and then it runs the standard configuration script (tws_home/jobmanrc). If the user is allowed to use a local configuration script, and the script $HOME/.jobmanrc exists, the local configuration script is also run. The job is then run either by the standard configuration script, or by the local one. Each of the processes launched by Jobman, including the configuration scripts and the jobs, retain the user name recorded with the stream logon of the job. In case of submitted jobs, they retain the submitting users name. To have the jobs run with the users environment, be sure to add the users .profile environment to the local configuration script. | | | | | | | | | | | | |
16
| | | | | | | | | | | | | | |
Table 2. Job environment variables (continued) UNISON_JOBNUM UNISON_MASTER UNISON_RUN UNISON_SCHED UNISON_SCHED_DATE UNISON_SCHED_EPOCH UNISON_SYM UNISON_EXEC_PATH TIVOLI_JOB_DATE The job number (ppid) The name of the master CPU Tivoli Workload Schedulers current production run number The schedule name Tivoli Workload Schedulers production date (yymmdd) Tivoli Workload Schedulers production date, expressed in epoch form The Symphony record number The jobmanrc fully qualified path The scheduled date for a job
LOCAL_RC_OK
17
Table 3. Variables of jobmanrc (continued) Variable Name MAIL_ON_ABEND Value (Settable) If set to yes, a message is mailed to the login users mailbox if the job terminates with a non-zero exit code. This can also be set to one or more user names, separated by spaces, and a message is mailed to each user. For example, root mis sam mary. If set to no, no messages are mailed if the job abends. Abend messages have the following format: cpu#sched.job jcl-file failed with exit-code Please review standard-list-filename SHELL_TYPE (Configurable) If set to standard, the first line of the jcl file is read to determine which shell to use to run the job. If the first line does not start with #!, then /bin/sh is used to run the local configuration script or $UNISON_JCL. Commands are echoed to the jobs standard list file. If set to user, the local configuration script or $UNISON_JCL is run by the users login shell ($UNISON_SHELL). Commands are echoed to the jobs standard list file. If set to script, the local configuration script or $UNISON_JCL is run directly, and commands are not echoed unless the local configuration script or $UNISON_JCL contains a set -x command. Any other setting is interpreted as standard. (Settable) If set to yes, the job, or the users local configuration script is run using the exec command, thus eliminating an extra process. This option is overridden if MAIL_ON_ABEND is also set to yes. Any other setting is interpreted as no, in which case the job or local configuration script is run by another shell process.
USE_EXEC
18
If you intend to use a local configuration script, it must, at a minimum, run the jobs script file ($UNISON_JCL). The Tivoli-supplied standard configuration script, jobmanrc, runs your local configuration script as follows:
$EXECIT $USE_SHELL $HOME/.jobmanrc "$UNISON_JCL" $IS_COMMAND
The value of USE_SHELL is set to the value of the jobmanrc SHELL_TYPE variable (see Table 3 on page 17). IS_COMMAND is set to yes if the job was scheduled or submitted using the docommand construct. EXECIT is set to exec if the variable USE_EXEC is set to yes (see Table 3 on page 17), otherwise it is null. The following example shows how to run a jobs script file, or command, 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 that does processing based on the exit code of the users 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 - Non Fatal Error" exit 0 elif [ $RETVAL -gt 1 -a $RETVAL -lt 100 ] then conman "tellop This is a database error - page the dba" elif [ $RETVAL -ge 100 ] then conman "tellop Job aborted. Please page the admin" fi
19
Synopsis
schedulr -v|-u schedulr [-date date|-autodate] [-scheds {in-file|-}] [-prodsked {out-file|-}]
Arguments
-u -v -date Display command usage information and exit. Display the command version and exit. Select job streams for a specific date. The date is entered as mm/dd/[yy]yy.
-autodate Select job streams for the current system date. -scheds In addition to those selected by -date or -autodate, if any, select the job streams named in in-file. The names must appear in the file as [workstation#]jobstream, with one name per line. If a dash is entered instead of a file name, schedulr prompts for job stream names at stdin. -prodsked Direct schedulr output to out-file. If a dash is entered instead of a file name, the output is directed to stdout. If the argument is omitted, the output is written to a file named prodsked.
Description
If -autodate, and -date are omitted, schedulr prompts for a date. If you respond to the prompt by pressing Return, job streams are selected only from the in-file.
Examples
Select job streams for todays date, plus the job streams named in the file myskeds:
schedulr -autodate -scheds myskeds
Select job streams for February 15, 2001, do not prompt for extra job stream names, and write the output to the file myprodsked:
schedulr -date 2/15/01 -prodsked myprodsked
Select job streams for February 15, 2001, and prompt for extra job streams:
schedulr -date 2/15/2001 -scheds -
Prompt for the production date, and extra job streams (note that schedule is the same as job stream):
schedulr Enter schedule date: 4/14/01 Enter a list of extra schedules Schedule name: site1#sked2 Schedule name: <Return> <list of job streams selected> End of Program
20
Synopsis
compiler -v|-u compiler [-date date] [-input in-file] [-output out-file]
Arguments
-u -v -date Display command usage information and exit. Display the command version and exit. The production date to be recorded in the interim production plan file. The date is entered as mm/dd/[yy]yy.
-input The name of the file containing the production schedule. If this option is omitted, the default name is prodsked. -output Direct compiler output to out-file. If the argument is omitted, the output is written to a file named Symnew.
Description
If you omit the -date argument, Symnew is given the same date as that recorded in the production schedule file created by schedulr. If there is no date in production schedule file, the current system date is used. The date in Symnew is the date that the scheduler will begin executing the production plan. The ability to enter a different date can be used to set up processing for past or future dates. Missing object messages: The following messages are produced by compiler to indicate missing scheduling objects. The messages are normally found in the standard list file for the Jnextday job. job. 5 ... Undefined parameter in "schedule"; not replaced. A parameter called for in a job stream does not exist in the scheduler database. No substitution occurs and the parameter string itself is used. AWSBIC102W ... Job name is not found in database. Added a dummy job in FAIL state. A job named in a job stream does not exist in the scheduler database. A dummy job of the same name is placed in the production schedule with a priority of zero and a state of FAIL. AWSBIC103W ... Prompt name not found. Added prompt name in Symphony. A prompt named in a job stream does not exist in the scheduler database. A dummy prompt containing the following text is used instead: Prompt name was not found in database. This is dummy text. Do you want to continue (Y/N). AWSBIC104W ...Resource name for cpu name not found in database. Added resource name with 0 units.
21
A resource named in a job stream does not exist in the scheduler database. A dummy resource with zero available units is used instead: AWSBIC106W ... Cpu name does not exist in cpu database. Ignoring schedule name. A job stream is defined to run on a cpu that does not exist. The job stream is ignored and not placed in the production schedule.
Examples
Compile prodsked into Symnew:
compiler
Compile prodsked into Symnew, and enter a production date of May 15, 2002:
compiler -date 5/15/02
22
Synopsis
stageman -v stageman [-carryforward {yes|no|all}] [-log log-file|-nolog] [symnew]
Arguments
-v Display the command version and exit. -carryforward Define the type of carry forward as follows: no yes all -log Do not carry forward any job streams. Carry forward only those uncompleted job streams that are Carry Forward enabled. Ignore Carry Forward enabling in job streams, and carry forward all uncompleted job streams.
Log the old production plan, and give the log file this name. See Log file names on page 24 for more information.
-nolog Do not log the old production plan. symnew The name of the interim production plan file created by compiler. If omitted, the file Symnew is used.
Description
If you omit -carryforward, the default for carry forward is determined by the carryforward global option. In UNIX only, stageman also determines which executable files can be deleted for jobs submitted with the at and batch commands. These are jobs that were not carried forward. The files are actually deleted when the scheduler starts up for the new day. If scheduler processes are still running and accessing the Symphony file, stageman displays the message:
Unable to get exclusive access to Symphony. Shutdown batchman and mailman.
To continue, stop the scheduler and rerun stageman. If stageman aborts for any reason, you must rerun both compiler and stageman. Users accessing the plan through the CLI during the time Symphony is being switched are sent the message:
Current Symphony file is old. Switching to new Symphony. Schedule mm/dd/yy (nnnn) on cpu, Symphony switched.
Chapter 2. The production cycle
23
Some user commands run during the switch may not run properly because the target jobs or job streams were not carried forward. Log file names: Production plan log files are stored in the TWShome/schedlog directory. The default naming convention used by stageman, when the -log and -nolog arguments are omitted, is as follows:
TWShome/schedlog/Myyyymmddhhtt
where yyyymmddhhtt is the year, month, day, hour, and minute the log file was created. The above naming convention is coded in the Jnextday script supplied by Tivoli. If you wish, you can change the naming convention when you automate the production cycle. For more information see Automating the production cycle on page 13. Note: Be sure to monitor the disc space in the schedlog directory and remove older log files on a regular basis. Job streams carried forward: The carry forward option remains enabled on job streams that are carried forward, so they may be carried forward again. If an unsuccessful job stream is carried forward and it continues to terminate in a state other than SUCC, it may be carried forward indefinitely unless its Until time expires or it is cancelled. Carried forward job streams maintain their original production date internally. Any job within these job streams that utilizes datecalc will use this production date when using the scheddate keyword. For more information see datecalc on page 227 For carry forward to work properly in a network, the master domain managers production plan file, Symphony, must be updated with the latest job stream status from its agents and subordinate domain managers. This can be accomplished by entering the following at a command prompt on the master domain manager prior to executing stageman:
conman "link @"
Job stream names: Job streams that are carried forward are renamed as follows: CFyyjjjnnxxxxxxxxx where yy are the last two digits of the year, jjj is the Julian date, nn is a sequence number (00-99, AA-ZZ), and xxxxxxxxx is a random alpha string. Carry forward prompts: To retain continuity when carrying job streams forward, stageman creates special prompts in the new production plan to account for disconnected Follows dependencies. These prompts are issued after the new processing day begins, when the scheduler checks to see if the job or job stream is ready to launch, and are replied to as standard prompts. The following is an example of a Carry Forward prompt:
INACT 12 (SYS1#CF9123AA) follows SYS1#SKED3 satisfied?
This prompt indicates that a job stream from the previous day was carried forward as CF9123AA, and that it follows a job stream named sked3 which was not carried forward. The state of the prompt INACT in this case defines the state of the corresponding Follows dependency. The possible states are:
24
INACT The prompt has not been issued and the dependency is not satisfied. ASKED The prompt has been issued, and is awaiting a reply. The dependency is not satisfied. NO Either a no reply was received, or it was determined before Carry Forward occurred that the followed job stream (sked3) had not completed successfully. The dependency is not satisfied. Either a yes reply was received, or it was determined before Carry Forward occurred that the followed job stream (sked3) had completed successfully. The dependency is satisfied.
YES
| | | | | | | | |
Note: A prompt is generated if the schedule is carried forward and it has a follows dependency on another schedule which is not carried forward. In the case of Internetwork dependencies, even when both schedules are carried forward, a prompt is generated. This is because in the case of Internetwork dependencies there is no available mechanism to keep them connected. No way is provided for the successor to know if the schedule on the other side has been carried forward or not, and the dependency link is broken in any case. For more details, refer to Chapter 9, The Network Agent reference, on page 289.
Examples
Carry forward all uncompleted job streams (regardless of the status of the Carry Forward option), log the old Symphony file, 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, do not log the old Symphony file, and create a new production control file named mysym:
stageman -nolog mysym
25
Synopsis
logman -v|-u logman [-smooth percent] [-minmax {elapsed|cpu}] log-file
Arguments
-u -v Display command usage information and exit. Display the command version and exit.
-smooth Use a weighting factor that favors the most recent job run when calculating the normal (average) run time for a job. This is expressed as a percentage. For example, -smooth 40 will apply a weighting factor of 40% to the most recent job run, and 60% to the existing average. The default is zero. -minmax Define how the minimum and maximum job run times are logged and reported. elapsed Base the minimum and maximum run times on elapsed time. cpu Base the minimum and maximum run times on CPU time.
log-file The name of the production plan file or log file from which job statistics are extracted.
Description
Jobs that have already been logged, cannot be logged again. Attempting to do so generates a 0 jobs logged error message. Elapsed time compared to CPU time: Elapsed time, expressed in minutes, is greatly affected by system activity. It includes both the amount of time a job made use of the CPU and the intervals the job had to wait for other processes to release the CPU. In periods of high system activity, for example, a job may have a long elapsed time, and yet use no more CPU time than in periods of low system activity. On the other hand, CPU time, expressed in seconds, is a measure of the actual time a job made use of the CPU, and does not include the intervals when the job was waiting. If you run logman with the -minmax elapsed argument, the maximum and minimum run times and dates are based solely on a jobs elapsed time. The values are updated only if the latest job run has an elapsed time greater than the existing maximum, or less than the existing minimum. The CPU times, in this case, will not necessarily indicate their maximum and minimum extremes. If you run logman with the -minmax CPU argument, the maximum and minimum run times and dates are based solely on a jobs CPU time. The values are updated only if the latest job run has a CPU time greater than the existing maximum, or less than the existing minimum. The elapsed times, in this case, will not necessarily indicate their maximum and minimum extremes. If you run logman without the -minmax argument, the elapsed time and CPU time values are updated independently to indicate their maximum and minimum
26
extremes, but the run dates correspond only to the elapsed time values. No record is kept, in this case, of the run dates for maximum and minimum CPU times.
Examples
Log job statistics from the log file M199903170935:
logman schedlog/M199903170935
Log job statistics from the log file M$DATE based on elapsed time, giving the most recent job runs a weight of 40% when calculating normal (average) run times:
logman -smooth 40 -minmax elapsed schedlog/M$DATE
The $DATE variable contains the date and time stamp used by stageman to create the log file name. See The stageman command on page 23 for more information.
27
Synopsis
UNIX: wmaeutil.sh instance_name [-stop DB | PL | EG | *] [-version DB | PL | EG | *] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop] Windows: wmaeutil.cmd instance_name [-stop DB | PL | EG | *] [-version DB | PL | EG | *] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop]
Arguments
instance_name The name of the scheduler instance. This refers to the instance name you entered during installation of the scheduler engine, and the installation of the connector. -stop DB | PL | EG | * This option can be used to shut down specified connector server. The (*) asterisk can be used to shut down all three connector server. -version DB | PL | EG | * This option is used to obtain the version number of the connector server for the plan, database, engine and installed on the system. The (*) asterisk can be used to obtain versions for all three connector server at once. -dbinfo DB | PL This option is used to find out if the scheduler database and plan to which this connector is linked is expanded or unexpanded. With IBM Tivoli Workload Scheduler, Version 8.2, databases and plans are always expanded, but this option exists for backward compatibility. -sethome This option is used to set TWShome attribute of the scheduler objects (Engine, Database, and Plan) in Tivolis object database. This attribute value links connectors for the specified object instance to the core scheduler product. It takes the fully qualified name of the scheduler home directory as an argument. Also the pathname string should be enclosed in quotes to prevent any shell interpretation. -gethome This option does not require any arguments and it prints the value of TWSHome attribute for the Engine, Database, and Plan object instances as set in the object database. ALL -stop This option stops the connector servers for all scheduler connector
28
instances connected to the current scheduler installation, that is, it stops the connector servers for all instances whose TWSHome attribute matches the home directory of the scheduler current installation.
Usage Notes
Set environment variables: Before wmaeutil can be run successfully, you must run the following file to set the framework environment. For Windows:
c: \> %SystemRoot%\system32\drivers\etc\Tivoli\setup_env.cmd
For UNIX:
$. /etc/Tivoli/setup_env.sh
You can update your UNIX profile to run this file, to avoid having to run the command manually. Makesec considerations: The wmaeutil.sh command must be run before running the makesec command. The makesec command will not run successfully on Windows platforms until the connectors are stopped. You should also stop the connectors when using the makesec command on UNIX. IBM Tivoli Workload Scheduler instance name: If you are not sure of the instance name that was entered at installation, perform the following steps: 1. Source the Tivoli environment variables:
. /etc/Tivoli/setup_env.sh (for UNIX) C:\winnt\system32\drivers\etc\Tivoli\setup_env.cmd (for Windows)
Examples
Stop the connectors for the database, plan, and engine for an instance called maestro:
wmaeutil.sh maestro -stop ALL
Stop the connectors for the database for an instance called tws:
wmaeutil.sh tws -stop ALL DB
Stop the connector versions for the database, plan and engine for an instance called maestro2:
wmaeutil.sh maestro2 -version *
29
30
31
Table 4. List of reserved words abendprompt end after every at everyday autodocoff except autodocon extraneous behindfirewall fdignore carryforward fdnext confirmed fdprev cpuname filename dateval follows day(s) freedays day_of_week go deadline hi docommand i18n_id
i18n_priority in interactive isuserjob jobfilename keyjob keysched maestro needs netdelim nextjob node notempty number
on onuntil op opens order os priority prompt qualifier quoted_string recovery request rerun sa
schedule scriptname server stop streamlogon su timezone_tzid token_in until weekday(s) workday(s)
32
Workstation definitions
A workstation is a scheduling object that runs jobs. A workstation is usually an individual computer, on which jobs and job streams are run. A workstation definition is required for every computer that runs jobs in the IBM Tivoli Workload Scheduler network. Primarily workstation definitions refer to physical workstations. However, in the case of extended agents, the workstations are logical definitions that must be hosted by a physical workstation. You can include multiple workstation definitions in the same text file, along with workstation class definitions and domain definitions. Each workstation definition has the following format and arguments:
Synopsis
#[ comment] cpuname wkstation [description text] os os-type node hostname [tcpaddr port] [secureaddr port][timezone|tz tzname] [domain domainname] [for maestro [host host-wkstation [access method]] [type fta | s-agent | x-agent] [ignore] [autolink on | off] [behindfirewall on | off] [securitylevel enabled | on | force] [fullstatus on | off] [resolvedep on | off] [server serverid]] end [cpuname ...] [cpuclass ...] [domain ...]
Arguments
# comment Specifies to treat everything from the pound sign to the end of the line as a comment. cpuname wkstation Specifies the name of the workstation. The name must start with a letter, and can contain alphanumeric characters, dashes and underscores. It can contain up to 16 characters. See Table 4 on page 32 for a list of words to avoid using when specifying the cpuname. Note: Workstation names must be unique, and cannot be the same as workstation class and domain names. description text Provides a description of the workstation. Your text must be enclosed in double quotes. os os_type Specifies the operating system of the workstation. Valid values include UNIX, WNT, and OTHER where,
Chapter 3. Composer reference
33
Table 5. Values for the supported operating systems Use these values... UNIX For these operating systems... HP-UX, Sun Solaris, AIX, Linux for Intel, Linux for S/390 and z/Series, Linux for ISeries and PSeries, Irix, OSF, Dynix, Compaq Windows NT, Windows 2000, Windows 2000 NET Server, Windows XP Professional Used in connection with extended agents.
WNT OTHER
Note: Refer to the IBM Tivoli Workload Scheduler Release Notes for an up-to-date list of supported platforms. node hostname Specifies the host name or the IP address of the workstation. Fully-qualified domain names are accepted. tcpaddr port Specifies the TCP port number that the scheduler uses for communications on the workstation. The default is 31111. secureaddr Defines the port used to listen for incoming SSL connections. This value must match the one defined in the nm SSL port local option of the workstation. It must be different from the nm port local option that defines the port used for normal communications. If securitylevel is specified but this attribute is missing, 31113 is used as the default value. See the IBM Tivoli Workload Scheduler Planning and Installation Guide for reference on SSL authentication. timezone|tz tzname Specifies the time zone of the workstation. See Appendix B, Managing time zones, on page 319 for valid time zone names. To ensure the accuracy of scheduling times, this time zone must be the same as the computers operating system time zone. domain domainname Specifies the name of the scheduler domain of the workstation. The default for fault-tolerant and standard agents is the master domain, usually named MASTERDM. The default for a domain manager is the domain in which it is defined as the manager. The default for an extended agent is the domain of its host workstation. host host-wkstation Specifies the name of the agents host workstation. This is required for extended agents. The host is the workstation with which the extended agent communicates and where its access method resides. Note that the host cannot be another extended agent. access method Specifies an access method for extended and network agents. This must be the name of a file that resides in the TWShome/methods directory on the agents host workstation. type Specifies the type of workstation. Enter one of the following: fta Fault-tolerant agent, including domain managers and backup domain managers.
34
s-agent Standard agent. x-agent Extended agent. ignore Specifies that the scheduler will ignore this workstation definition. autolink Specifies whether to open the link between workstations at startup. For fault-tolerant and standard agents, enter on to have the domain manager open the link to the agent when the domain manager is started. For the domain manager, enter on to have its agents open links to the domain manager when they are started. Autolink is useful primarily during the startup sequence at the beginning of each day. At that time, a new production plan is created and compiled on the master domain manager, and all workstations are stopped and restarted. For each agent with autolink turned on, the domain manager automatically sends a copy of the new production plan and starts the agent. If autolink is also turned on for the domain manager, the agent, in turn, opens a link back to the domain manager. If the value of autolink is off for an agent, it is initialized when you run a Conman link command on the agents domain manager or the master domain manager. behindfirewall If this attribute is set to ON, this means that there is a firewall between the workstation and the master domain manager. Only a direct connection between the workstation and its domain manager is allowed. For all the workstations with behindfirewall set to ON, the start wkstation, stop wkstation, and showjobs commands are sent following the domain hierarchy, instead of making the master or the domain manager open a direct connection with the workstation. fullstatus Specifies whether the agent is updated with full or partial status. This is for fault-tolerant agents only. Enter on to have the agent operate in Full Status mode. In this mode, the agent is updated with the status of jobs and job streams running on all other workstations in its domain and in subordinate domains, but not on peer or parent domains. If the value of fullstatus is off, the agent is informed only about the status of jobs and job streams on other workstations that affect its own jobs and job streams. This can improve performance by reducing network activity. To keep an agents production plan at the same level of detail as its domain manager, set fullstatus and resolvedep to on. Always set these modes on for backup domain managers. securitylevel Specifies the type of SSL authentication for the workstation. It must have one of the following values: enabled The workstation uses SSL authentication only if its domain manager workstation or another fault-tolerant agent below it in the domain hierarchy requires it. on The workstation uses SSL authentication when it connects with its domain manager. The domain manager uses SSL authentication
35
force
when it connects to its parent domain manager. The fault-tolerant agent refuses any incoming connection from its domain manager if it is not an SSL connection. The workstation uses SSL authentication for all of its connections and accepts connections from both parent and subordinate domain managers. It will refuse any incoming connection if it is not an SSL connection.
If this attribute is omitted, the workstation is not configured for SSL connections. In this case, any value for secureaddr will be ignored. You should also set the nm ssl port local option to 0 to be sure that this port is not opened by netman. See the IBM Tivoli Workload Scheduler Planning and Installation Guide for reference on SSL authentication. The following table describes the type of communication used for each type of securitylevel setting.
Table 6. Type of communication depending on the securitylevel value. Fault-Tolerant Agent (Domain Manager) Enabled On Force Enabled On Force Enabled On Force Enabled On Force Domain Manager (Parent Domain Manager) On On On On Enabled Enabled Enabled Enabled Force Force Force Force Connection Type TCP/IP TCP/IP No connection No connection TCP/IP TCP/IP SSL SSL TCP/IP TCP/IP SSL SSL No connection SSL SSL SSL
resolvedep Specifies whether an agent will track all dependencies or only its own. This is for fault-tolerant agents only. Enter on to have the agent operate in Resolve All Dependencies mode. In this mode, the agent tracks dependencies for all jobs and job streams, including those running on other workstations. Note that the value of fullstatus must also be on so that the agent is informed about activity on other workstations. If the value of resolvedep is off, the agent tracks dependencies for its own jobs and job streams only. This reduces processing overhead. To keep an agents production plan at the same level of detail as its domain manager, set fullstatus and resolvedep to on. Always set these modes on for backup domain managers.
36
server serverid Specifies a Mailman server on the domain manager to handle communications with the agent. This is for fault-tolerant and standard agents only. Do not use this option for domain managers. Using servers can reduce the time required to initialize agents and improve the timeliness of messages. The ID is a single letter or a number (A-Z and 0-9). The IDs are unique to each domain manager, so you can use the same IDs in other domains without conflict. If more than 36 server IDs are required in a domain, consider dividing it into two or more domains. If a server ID is not specified, communications with the agent are handled by the main Mailman process on the domain manager. When it starts up, the domain manager creates a separate server for each unique server ID. If the same ID is used for multiple agents, a single server is created to handle their communications. As a guide, extra servers should be defined to prevent a single server from handling more than eight agents.
Examples
The following example creates a master domain manager named hdq-1, and a fault-tolerant agent named hdq-2 in the master domain. Note that a domain argument is optional in this example, because the master domain defaults to masterdm.
cpuname hdq-1 description Headquarters master DM os unix tz pst node sultan.ibm.com domain masterdm for maestro type fta autolink on fullstatus on resolvedep on end cpuname hdq-2 os wnt tz pst node opera.ibm.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 est node pewter.ibm.com domain distr-a for maestro type fta autolink on fullstatus on resolvedep on end
37
cpuname distr-a2 os wnt node quatro.ibm.com tz est domain distr-a for maestro type s-agent end
The following example creates a workstation with SSL authentication. The securitylevel security definition specifies that the connection between the workstation and its domain manager can be only of the SSL type. Port 32222 is reserved for listening for incoming SSL connections.
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, see Creating a z/OS Workstation and Creating a Distributed Workstation in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
38
Synopsis
# comment cpuclass wkstationclass members {wkstation | @} [...] end [cpuname ...] [cpuclass ...] [domain ...]
Arguments
# comment Specifies to treat everything from the pound sign to the end of the line as a comment. cpuclass wkstationclass Specifies the name of the workstation class. The name must start with a letter, and can contain alphanumeric characters, dashes and underscores. It can contain up to 16 characters. Note: You cannot use the same names for workstations, workstation classes, and domains. members wkstation Specifies a list of workstation names, separated by spaces, that are members of the class. The at sign (@) wildcard character 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
See Also
| | For the equivalent Job Scheduling Console task, see Creating a Workstation Class in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
39
Domain definitions
A domain is a group of workstations consisting of one or more agents and a domain manager. The domain manager acts as the management hub for the agents in the domain. You can include multiple domain definitions in the same text file, along with workstation definitions and workstation class definitions. Each domain definition has the following format and arguments:
Synopsis
# comment domain domainname[description text] manager wkstation [parent domainname] end [cpuname ...] [cpuclass ...] [domain ...]
Arguments
# comment Treat all from the pound sign to the end of the line as a comment. domain domainname The name of the domain. It must start with a letter, and can contain alphanumeric characters, dashes, and underscores. It can contain up to 16 characters. You cannot use the same names for workstations, workstation classes, and domains. description text Provides a description of the domain. Your text must be enclosed in double quotes. manager wkstation Specifies the name of the workstation that is the domain manager. This workstation must belong to the domain that is being defined. The domain manager must be a fault-tolerant agent with fullstatus and resolvedep set to on. parent domainname The name of the parent domain to which the domain manager is linked. The default is the master domain, which does not require a domain definition. The master domain is defined by the global options master and master domain.
Examples
The following example defines a domain named east, with the master domain as its parent, and two subordinate domains named northeast and southeast:
domain east description The Eastern domain manager cyclops end domain northeast description The Northeastern domain manager boxcar parent east end domain southeast description The Southeastern domain manager sedan parent east end
40
See Also
| | For the equivalent Job Scheduling Console task, see Creating a Domain in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
41
Job definitions
A job is an executable file, program, or command that is scheduled and launched by IBM Tivoli Workload Scheduler. You can write job definitions in edit files and then add them to the scheduler database with the composer command line program. You can include multiple job definitions in a single edit file. Note: A job itself has no dependencies, these must be added to a job in a job stream.. The scheduling language used to write job streams also permits you to add and modify job definitions. Please refer to next chapter for additional information on how to use scheduling language to write job streams. Each job definition has the following format and arguments:
Synopsis
$jobs [wkstation#]jobname scriptname filename | docommand commandstreamlogon username [description text] [interactive] [rccondsucc Success Condition] [recovery {stop | continue | rerun} [after [wkstation#]jobname] [abendprompt text] ] [ [wkstation#]jobname... ]
Arguments
wkstation# Specifies the name of the workstation or workstation class on which the job runs. The default is the workstation on which Composer is running. The pound sign (#) is a required delimiter. If you specify a workstation class, it must match the workstation class of any job stream in which the job is included. jobname Specifies the name of the job. The name must start with a letter, and can contain alphanumeric characters, dashes and underscores. It can contain up to 40 characters. scriptname filename Specifies the name of the file the job runs. Use scriptname for UNIX and Windows jobs. For an executable file, enter the file name and any options and arguments. The length of filename plus the length of Success Condition (of the rccondsucc keyword) must not exceed 4095 characters. You can also use IBM Tivoli Workload Scheduler parameters. See Using parameters in job definitions on page 46 for more information. For Windows jobs, include the file extensions. Universal Naming Convention (UNC) names are permitted. Do not specify files on mapped drives. If spaces or special characters are included, other than slashes (/) and backslashes (\), the entire string must be enclosed in quotes ().
42
If the file name contains spaces, enter the name in another file that does not have spaces in its name and use the second files name for this argument. docommand command Specifies a command that the job runs. Enter a valid command and any options and arguments enclosed in quotes (). The length of command plus the length of Success Condition (of the rccondsucc keyword) must not exceed 4095 characters. A command is run directly and, unlike scriptname, the configuration script, jobmanrc, is not run. Otherwise, the command is treated as a job, and all job rules apply. You can also enter IBM Tivoli Workload Scheduler parameters. See Using parameters in job definitions on page 46 for more information. streamlogon username The user name under which the job runs. The name can contain up to 47 characters. If the name contains special characters it must be enclosed in quotes (). Specify a user that can log on to the workstation on which the job runs. You can also enter IBM Tivoli Workload Scheduler parameters. See Using parameters in job definitions on page 46 for more information. For Windows jobs, the user must also have a user definition. See User definitions on page 47 for user requirements. description text Provides a description of the job. Your text must be enclosed in double quotes. interactive For Windows jobs, include this keyword to indicate that the job runs interactively on the Windows NT desktop. rccondsucc Success Condition An expression which determines the return code (RC) required to consider a job successful. The success condition maximum length must be 256 characters. This expression can contain a combination of comparison and boolean expressions: Comparison expression Specifies the job return codes. The syntax is:
(RC operator operand)
RC
The RC keyword.
43
operand An integer between -2147483647 and 2147483647. For example, 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. The syntax is:
comparison_expression operator comparison_expression
comparison_expression The expression is evaluated from left to right. You can use parentheses to assign a priority to the expression evaluation. operator Logical operator. It can have the following values:
Table 8. 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. TRUE if either expr_a or expr_b is TRUE. TRUE if expr_a is not TRUE.
For example, 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, and less than 10 as follows:
rccondsucc "(RC=3) OR ((RC>=5) AND (RC<10))"
recovery Recovery options for the job. The default is stop with no recovery job and no recovery prompt. Enter one of the recovery options, stop, continue, or rerun. This can be followed by a recovery job, a recovery prompt or both. stop If the job abends, do not continue with the next job.
continue If the job abends, continue with the next job. rerun If the job abends, rerun the job.
after [wkstation#]jobname Specifies the name of a recovery job to run if the parent job abends. Recovery jobs are run only once for each abended instance of the parent job. You can specify the recovery jobs workstation if it is different than the parent jobs workstation. The default is the parent jobs workstation. Not all jobs are eligible to have recovery jobs run on a different workstation. Follow these guidelines: v If either workstation is an extended agent, it must be hosted by a domain manager or a fault-tolerant agent with a value of on for fullstatus.
44
v The recovery job workstation must be in the same domain as the parent job workstation. v If the recovery job workstation is a fault-tolerant agent, it must have a value of on for fullstatus. abendprompt text Specifies the text of a recovery prompt, enclosed in quotes, to be displayed if the job abends. The text can contain up to 64 characters. If the text begins with a colon (:), the prompt is displayed, but no reply is required to continue processing. If the text begins with an exclamation mark (!), the prompt is not displayed, but a reply is required to proceed. The following table summarizes all possible combinations of recovery options and actions. The table is based on the following criteria from a job stream called sked1: v Job stream sked1 has two jobs, job1 and job2. v If selected for job1, the recovery job is jobr. v job2 is dependent on job1 and will not start until job1 is complete.
Stop Recovery prompt: No Intervention is Recovery job: No required. Continue Run job2. Rerun Rerun job1. If job1 abends, issue scheduler prompt. If reply is yes, repeat above. If job1 is successful, run job2. Issue recovery prompt. If reply is yes, rerun job1. If job1 abends, repeat above. If job1 is successful, run job2. Run jobr. If jobr abends, intervention is required. If jobr is successful, rerun job1. If job1 abends, issue scheduler prompt. If reply is yes, repeat above. If job1 is successful, run job2. Issue recovery prompt. If reply is yes, run jobr. If jobr abends, intervention is required. If jobr is successful, rerun job1. If job1 abends, repeat above. If job1 is successful, run job2.
Recovery prompt: Issue recovery Yes Recovery job: No prompt. Intervention is required.
Recovery prompt: No Run jobr. If it Recovery job: Yes abends, intervention is required. If it is successful, run job2.
Recovery prompt: Issue recovery Yes Recovery job: Yes prompt. If reply is yes, run jobr. If it abends, intervention is required. If it is successful, run job2.
Notes: 1. Intervention is required means that job2 is not released from its dependency on job1, and therefore must be released by the operator.
45
2. The continue recovery option overrides the abend state, which may cause the schedule containing the abended job to be marked as successful. This will prevent the schedule from being carried forward to the next day. 3. If you select the Rerun option without supplying a recovery prompt, the scheduler generates its own prompt. 4. To reference a recovery job in Conman, you must use the name of the original job (job1 in the scenario above, not jobr). Recovery jobs are run only one per abend. Using parameters in job definitions: Parameters have the following uses and limitations in job definitions: v Parameters are allowed in the streamlogon, scriptname, and docommand values. v A parameter can be used as an entire string or a part of it. v Multiple parameters are permitted in a single variable. v Enclose parameter names in carets (^), and enclose the entire string in quotation marks. v Ensure that the caret characters are not preceded by a backslash in the string. If it occurs, move that backslash in the definition of the parameter between carets. For example instead of entering the following parameters definition:
$PARM MYDIR "scripts" job01 scriptname "c:\pippo\home\^MYDIR^\test.cmd"
In the example below a parameter named mis is used in the streamlogon value. For additional examples, see Parameter definitions on page 50.
Examples
The following is a file containing two 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 Users Guide.
46
User definitions
The user names used as the streamlogon value for Windows job definitions must have user definitions. This is not required for users who run jobs on other platforms. Each user definition has the following format and arguments:
Synopsis
# comment username[wkstation#]username password password end [username ...]
Arguments
# comment Specifies to treat everything from the pound sign to the end of the line as a comment. username [wkstation#]username Specifies the name of a Windows user. wkstation Specifies the workstation on which the user is allowed to launch jobs. The pound sign is required. The default is the blank, meaning all workstations. username Specifies the user name in the following form: [domain\]user where domain is the Windows domain of the user and user is the name of the user. The domain name can contain up to 16 characters (including the backslash), and the user name can contain up to 31 characters. Note that Windows user names are case-sensitive. Also, the user must be able to log on to the workstation on which the scheduler will launch jobs, and must have the right to Log on as batch. If the name is not unique in Windows, it is considered to be a local user, a domain user, or a trusted domain user, in that order. password Specifies the users password. The password can contain up to 29 characters, and must be enclosed in quotes. To indicate no password, use two consecutive quotes with no space (). Once a user definition is compiled, you cannot read the password. Users with appropriate security privileges can modify or delete a user, but password information is never displayed. Using the Tivoli Workload Scheduler user and streamlogon definitions: On Windows, user definitions are specified through composer in the form [wkstation#]username. The workstation name is optional; its absence indicating all the workstations running on Widows in the Tivoli Workload Scheduler network. When you define or submit a job with composer, you must specify both a workstation and a valid user logon for the workstation. The logon in these cases is
Chapter 3. Composer reference
47
just a username a valid user name for Windows without the complement of the workstation name. For example, in the following job definition:
$JOB wkstation job01 docommand "dir" streamlogon username
the value for streamlogon is username and not wkstation#username. However, when you use the altpass command, remember that you must use the user definition in the form
wkstation#username
For this command, you can omit the workstation name only in the case you are changing the password of the workstation from where you are running the command. Trusted domain user: If the scheduler must launch jobs for a trusted domain user, give special attention to defining the user accounts. Assuming the scheduler is installed in Domain1 for user account maestro, and user account sue in Domain2 needs to launch a job, the following must be true: v There must be mutual trust between Domain1 and Domain2. v In Domain1 on the computers where jobs are launched, sue must have the right to Log on as batch. v In Domain1, maestro must be a domain user. v On the domain controllers in Domain2, maestro must have the right to Access this computer from network.
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, see Creating a Windows User in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
48
Calendar definitions
Calendars are lists of dates that you can use to schedule job streams. Calendar definitions are entered using the composer modify command. When you enter the command, composer copies the complete list of calendar definitions into an edit file and starts an editor where you can modify the list. Each calendar definition has the following format and arguments:
Synopsis
$calendar calendarname [description] date [...] [calendarname ...]
Arguments
calendarname Specifies the name of the calendar. The name can contain up to eight alphanumeric characters, including dashes (-) and underscores (_), and must start with a letter. description Provides a description of the calendar. It must be enclosed in double quotes. It can contain alphanumeric characters as long as it starts with a letter. It can contain the following characters: comma (,), period (.), dash (-), plus (+), single quote (), and equal (=). It cannot contain double quotes () other than the enclosing ones, colon (:), semi-colon (;), and ampersand (&). date [...] Specifies one or more dates, separated by spaces. The format is mm/dd/yy.
Examples
The following example defines three calendars named monthend, paydays, and holidays:
$calendar monthend "Month end dates 1st half 99" 01/31/99 02/28/99 03/31/99 04/30/99 05/31/99 06/30/99 paydays 01/15/99 02/15/99 03/15/99 04/15/99 05/14/99 06/15/99 holidays 01/01/99 02/15/99 05/31/99
See Also
| | For the equivalent Job Scheduling Console task, see Creating a Calendar in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
49
Parameter definitions
Parameters are values which substitute variables in job and job stream definitions when as the new production plan is created. Parameter definitions are entered using the composer modify command. When you enter the command, composer copies the complete list of parameter definitions into an edit file and starts an editor where you can modify the list. Each parameter definition has the following format and arguments:
Synopsis
$parm parametername value [parametername ...]
Arguments
parametername The name of the parameter. The name can contain up to eight alphanumeric characters, including dashes (-) and underscores (_), and must start with a letter. value Specifies the value assigned to the parameter. Do not include the names of other parameters.
Usage Notes
Parameters are accessible to all jobs, job streams, and prompts. When used in scheduling, parameter names are replaced by their values when the production plan is compiled for a new processing day. You can use multiple parameters in a single variable. When you use a parameter enclose it in carets (^), and enclose the entire string in quotation marks. Ensure that the caret characters are not preceded by a backslash in the string. If it occurs, move that backslash in the definition of the parameter between carets. For example instead of entering the following parameters definition:
$PARM MYDIR "scripts" job01 scriptname "c:\pippo\home\^MYDIR^\test.cmd"
Examples
Two parameters, glpath and gllogon, are defined as follows:
$parm glpath gllogon "/glfiles/daily" "gluser"
The glpath and gllogon parameters are used in the gljob2 job of the glsched job stream:
schedule glsched on weekdays : gljob2 scriptname "/usr/gl^glpath^"
50
See Also
| | For the equivalent Job Scheduling Console task, see Creating a Parameter in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
51
Prompt definitions
You can use prompts as dependencies in jobs and job streams. A prompt is defined by a unique name associated with a textual message and must be answered affirmatively for the dependent job or job stream to launch. Prompt definitions are entered using the composer modify command. When you enter the command, composer copies the complete list of prompt definitions into an edit file and starts an editor where you can modify the list. There are two types of prompts: v ad hoc or local v predefined or global A local prompt is defined within the properties of a job or job stream and is unique to that job or job stream. A global prompt is defined in the scheduler database and can be used by any job or job stream. Note: Predefined or global prompt definitions are reset each time the Jnextday command is run.
Synopsis
$prompt promptname [: | !]text [promptname ...]
Arguments
promptname Specifies the name of the prompt. The name can contain up to eight alphanumeric characters, including dashes (-) and underscores (_), and must start with a letter. text Provides the text of the prompt. If the text begins with a colon (:), the prompt is displayed, but no reply is required to continue processing. If the text begins with an exclamation mark (!), the prompt is not displayed, but a reply is required to proceed. You can use one or more parameters as part or all of the text string for a prompt. If you use a parameter, the parameter string must be enclosed in carets (^). See Parameter definitions on page 50 for an example. Note: Within a local prompt, when not designating a parameter, carets (^) must be preceded by a backslash (\) or they will cause errors in the prompt. Within global prompts, carets do not have to be preceded by a backslash. You can include backslash n (\n) within the text to create a new line.
Examples
The following example defines three prompts:
52
$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 Users Guide.
53
Resource definitions
Resources represent physical or logical scheduling resources that can be used as dependencies for jobs and job streams. Resource definitions are entered using the composer modify command. When you enter the command, composer copies the complete list of resource definitions into an edit file and starts an editor where you can modify the list. Each resource definition has the following format and arguments:
Synopsis
$resource wkstation#resourcename units [description ] [wkstation#resourcename ...]
Arguments
wkstation Specifies the name of the workstation or workstation class on which the resource is used. resourcename Specifies the name of the resource. The name can contain up to eight alphanumeric characters, including dashes (-) and underscores (_), and must start with a letter. units Specifies the number of available resource units. Values can be 0 through 1024.
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, see Creating a Distributed Resource in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
54
Running composer
To run the program, use the following command: composer [command[&[command]][...]] The following are examples of the command: v Runs composer and prompts for a command:
composer
v Runs print and version commands, and then prompts for a command:
composer "p parms&v&"
Control characters
You can enter the following control characters in conversational mode to interrupt composer if your stty settings are configured to do so. Ctrl+c composer stops executing the current command at the next step that can be interrupted and returns a command prompt. Ctrl+d composer quits after executing the current command.
Terminal output
The output to your computer is controlled by shell variables named MAESTROLINES and MAESTROCOLUMNS. If either is not set, the standard shell variables, LINES and COLUMNS, are used. At the end of each screen page, Composer prompts to continue. If MAESTROLINES (or LINES) is set to zero or a negative number, Composer does not pause at the end of a page.
Offline output
The ;offline option in Composer commands is used to print the output of a command. When you include it, the following variables control the output: Windows variables: $MAESTROLP Specifies the file into which a commands output is written. The default is stdout. $MAESTROLPLINES Specifies the number of lines per page. The default is 60. $MAESTROLPCOLUMNS Specifies the number of characters per line. The default is 132.
55
UNIX variables: The ;offline option in Composer commands is 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 commands output. Set it to one of the following: > file Redirects output to a file and overwrites the contents of the file. If the file does not exist, it is created.
>> file Redirects output to a file and appends the output to the end of the 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 is | lp -tCONLIST which directs the command output to the printer and places the title CONLIST in the banner page of the printout. $MAESTROLPLINES Specifies the number of lines per page. The default is 60. $MAESTROLPCOLUMNS Specifies the number of characters per line. The default is 132. You must export the variables before you run Composer.
56
Command syntax
Composer 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.
Wildcards
The following wildcard characters are permitted in some Composer commands: @ | ? % Replaces one or more alphanumeric characters. Replaces one alphanumeric character. Replaces one numeric character.
57
Character >>
Description Redirects command output to a file and appends the output to the end of file. If the file does not exist, it is created. For example: display parms >> parmlist Pipes command output to a system command or process. The system command is run whether or not output is generated. For example: display parms | grep alparm Pipes command output to a system command or process. The system command is not run if there is no output. For example: display parms || grep alparm
||
Command descriptions
The following pages describe Composers commands.
Command add build continue create delete display Description Adds scheduling objects. Builds or rebuilds a IBM Tivoli Workload Scheduler file. Ignores the next error. Creates a file for editing. Deletes scheduling objects. Displays scheduling objects. Page add on page 60 build on page 61 continue on page 62 create on page 63 delete on page 65 display, list, print on page 67 edit on page 70 exit on page 71 display, list, print on page 67 modify on page 72 new on page 74 display, list, print on page 67 redo on page 75 replace on page 77 validate on page 79
Modifies scheduling objects. Edits and adds scheduling objects. Prints scheduling objects.
58
Description Displays Composers command line program banner. Passes a system command to the system.
You can type command names and keywords in either uppercase or lowercase. You can also be abbreviate them to as few leading characters as needed to distinguish them from one another.
59
add
Adds jobs, job streams, users, workstations, workstation classes, and domains. You must have add access for new objects. If an object already exists, you must have modify access to the object.
Synopsis
add filename
Arguments
filename Specifies the name of a file that contains the following: v Job definitions. (The first line of the file must be $jobs.) v Job stream definitions. v Any combination of workstation, workstation class, and domain definitions. v User definitions.
Usage Notes
The syntax of the file is always checked before it is written to the database. All errors and warnings are reported. If there are syntax errors, you are asked if you want to edit the file to make corrections. If an object already exists, you are asked whether or not to replace it. | | | | | | | | | | | | |
Examples
To add the jobs from the file myjobs, run the following command:
add myjobs
To add the job streams from the file mysked, run the following command:
a mysked
To add the workstations, workstation classes, and domains from the file cpus.src, run the following command:
a cpus.src
To add the user definitions from the file users_nt, run the following command:
a users_nt
See Also
For the equivalent Job Scheduling Console task, see Monitoring Tasks in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
60
build
Builds or rebuilds scheduler database files. You must have build access to the file. | | | | If you have implemented fix pack 8.2-TWS-FP04, you can use this command while IBM Tivoli Workload Scheduler is running. If you have not implemented this or a later fix pack, it is advisable to stop all IBM Tivoli Workload Scheduler processes before running this command.
Synopsis
build filename
Arguments
database file name Specifies one of the following file names: calendars The file that contains calendar definitions. cpudata The file that contains workstation, workstation class, and domain definitions. jobs The file that contains job definitions.
mastsked The file that contains job stream definitions. parms The file that contains parameter definitions. prompts The file that contains prompt definitions. resources The file that contains resource definitions. userdata The file that contains user definitions.
Usage Notes
If a file does not exist, one is created. If the file exists, it is rebuilt. Rebuilding a database file can be useful when the database becomes fragmented from numerous additions and deletions. The rebuild will remove unused records and optimize the keys. | | | | | | | |
Examples
To rebuild the files containing job stream definitions, run the following command:
build mastsked
61
continue
Specifies to ignore the next command error.
Synopsis
continue
Usage Notes
This command is useful when multiple commands are entered on the command line or redirected from a file. It instructs Composer to continue executing commands even if the next command, following continue, results in an error. This command is not needed when you enter commands interactively because Composer will not quit on an error. | | | |
Examples
If you want the Composer to continue with the print command if the delete command results in an error, run the following command:
composer "continue&delete cpu=site4&print cpu=@"
62
create
Creates a file containing object definitions. You must have display access to the objects being copied.
Synopsis
create filename from calendars | parms | prompts | resources | cpu={wkstation | wkstationclass | domain} | jobs=[wkstation#]jobname | sched=[wkstation#]jstream | users=[wkstation#]username
Arguments
filename Specifies a file name. calendars Copies all calendars into the file. parms Copies all parameters into the file. prompts Copies all prompts into the file. resources Copies all resources into the file. cpu Copies a workstation, workstation class, or domain into the file. wkstation The workstation name. Wildcard characters are permitted. wkstationclass The workstation class name. Wildcard characters are permitted. domain The domain name. Wildcard characters are permitted. jobs Copies jobs into the file. wkstation The name of the workstation or workstation class on which the job runs. Wildcards are permitted. The default is the workstation on which Composer is running. jobname The job name. Wildcards are permitted. sched Copies job streams into the file. wkstation The name of the workstation or workstation class on which the job stream runs. Wildcard characters are permitted. The default is the workstation on which Composer is running. jstream The job stream name. Wildcard characters are permitted. users Copies users into the file. The password field is not copied for security reasons. wkstation 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 3. Composer reference
63
username The user name. Wildcard characters are permitted. | | Note: You should create regularly a back-up copy of the objects stored in the database.
Usage Notes
After you create a file, you can use the edit command to make changes to the file. The add or replace command can then be used to add or update the definition. | | | | | | | |
Examples
To create a file containing all calendars, run the following command:
create caltemp from calendars
To create a file containing all job streams, run the following command:
cr stemp from sched=@
See Also
For the equivalent Job Scheduling Console task, see Monitoring Tasks in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
64
delete
Deletes object definitions from the database. You must have delete access to the objects being deleted.
Synopsis
delete cpu={wkstation | wkstationclass | domain} | jobs=[wkstation#]jobname | sched=[wkstation#]jstream | users=[wkstation#]username
Arguments
cpu Deletes workstations, workstation classes, or domains. wkstation The workstation name. Wildcards are permitted. wkstationclass The workstation class name. Wildcards are permitted. domain The domain name. Wildcards are permitted. jobs Deletes jobs. wkstation The name of the workstation or workstation class on which the job runs. Wildcards are permitted. The default is the workstation on which Composer is running. jobname The job name. Wildcards are permitted. sched Deletes job streams. wkstation The name of the workstation or workstation class on which the job stream runs. Wildcards are permitted. The default is the workstation on which Composer is running. jstream The job stream name. Wildcards are permitted. users Deletes users. wkstation The name of the workstation on which the user is defined. Wildcards are permitted. The default is the workstation on which Composer is running. username The user name. Wildcards are permitted.
Usage Notes
If you use wildcard characters to specify a set of definitions, Composer requires confirmation before deleting each matching definition. | | | | |
Examples
To delete job3 that is launched on workstation site3, run the following command:
delete jobs=site3#job3
To delete all workstations with names starting with ux, run the following command:
Chapter 3. Composer reference
65
| | | | | | |
de cpu=ux@
To delete all job streams with names starting with test on all workstations, run the following command:
de sched=@#test@
See Also
For the equivalent Job Scheduling Console task, see Monitoring Tasks in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
66
Synopsis
display | list | print calendars | parms | prompts | resources | cpu={wkstation | wkstationclass | domain} | jobs=[wkstation#]jobname | sched=[wkstation#]jstream | users=[wkstation#]username
Arguments
calendars Displays all calendars. parms Displays all parameters. prompts Displays all prompts. resources Displays all resources. cpu Displays a workstation, workstation class, or domain. wkstation The workstation name. Wildcards are permitted. wkstationclass The workstation class name. Wildcards are permitted. domain The domain name. Wildcards are permitted. jobs Displays a job. wkstation The name of the workstation or workstation class on which the job runs. Wildcards are permitted. The default is the workstation on which Composer is running. jobname The job name. Wildcards are permitted. sched Displays a job stream. wkstation The name of the workstation or workstation class on which the job stream runs. Wildcards are permitted. The default is the workstation on which Composer is running. jstream The job stream name. Wildcards are permitted. users Displays a user. (The password field is not copied for security reasons.) wkstation The name of the workstation on which the user is defined. Wildcards are permitted. The default is the workstation on which Composer is running.
67
Command Output
The list command displays only the object names. The output of the print command is controlled by the variable MAESTROLP. See Offline output on page 55 for more information. Calendars Format: Calendar The calendar name. Description A free-form description of the calendar. Following these fields is a list of calendar dates. Cpu Format: CPU id The of a workstation, workstation class, or domain. Creator The name of the user who created the workstation definition. Last Updated The date the workstation definition was last updated. Following these fields is the workstation or workstation class definition. Jobs Format: CPU id The name of the workstation on which the job runs. Job The name of the job.
Logon The name of the logon user for the job. Last Run Date The date the job was last run. Following these fields is the job definition. Parms Format: Parameter The name of the parameter. Value The value of the parameter. Prompts Format: Prompt The name of the prompt. Message The prompt message text. Resources Format: CPU id The name of the workstation on which the resource is defined.
68
Resource The name of the resource. No Avail The total number of resource units. Description The free-form description of the resource. Sched Format: CPU id The name of the workstation on which the job stream runs. Schedule The name of the job stream. Creator The name of the user who created the job stream definition. Last Updated The date the job stream definition was last updated. Following these fields is the job stream definition. Users Format: CPU id The name of the workstation on which the user is allowed to run jobs. User Creator The name of the user who created the user definition. Last Updated The date the user definition was last updated. Following these fields is the user definition. | | | | | | | | | The name of the user.
Examples
To display all calendars, run the following command:
display calendars
To print all job streams that are launched on workstation site2, run the following command:
di sched=site2#@;offline
See Also
For the equivalent Job Scheduling Console task, see Working with Object Lists in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
69
edit
Edits a file.
Synopsis
edit filename
Usage Notes
An editor is started and the specified file is opened for editing. See The composer editor on page 56 for more information. | | | | |
Examples
To open the file mytemp for editing, run the following command:
edit mytemp
To open the file resfile for editing, run the following command:
ed resfile
See Also
| | For the equivalent Job Scheduling Console task, see Monitoring Tasks in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
70
exit
Exits the Composer command line program.
Synopsis
exit
Usage Notes
When you are running the Composer command line program in help mode, this command returns Composer to command input mode. | | | | | |
Examples
To exit the Composer command line program, run the following command:
exit
or:
e
71
modify
Modifies or adds scheduling objects. You must have modify access to the object or affected database file.
Synopsis
modify calendars | parms | prompts | resources | cpu={wkstation | wkstationclass | domain} | jobs=[wkstation#]jobname | sched=[wkstation#]jstream | users=[wkstation#]username
Arguments
calendars Modifies all calendars. parms Modifies all parameters. prompts Modifies all prompts. resources Modifies all resources. cpu Modifies a workstation, workstation class, or domain. wkstation The workstation name. Wildcards are permitted. wkstationclass The workstation class name. Wildcards are permitted. domain The domain name. Wildcards are permitted. jobs Modifies a job. wkstation The name of the workstation or workstation class on which the job runs. Wildcards are permitted. The default is the workstation on which Composer is running. jobname The job name. Wildcards are permitted. sched Modifies a job stream. wkstation The name of the workstation or workstation class on which the job stream runs. Wildcards are permitted. The default is the workstation on which Composer is running. jstream The job stream name. Wildcards are permitted. users Modifies a user. wkstation The name of the workstation on which the user is defined. Wildcards are permitted. The default is the workstation on which Composer is running. username The user name. Wildcards are permitted.
72
Usage Notes
The modify command copies the definition or object list into a temporary file, edits the file, and then adds the contents of the file to the appropriate database file. This is equivalent to the following sequence of commands:
create file from object-specification edit file add file
If the add operation is successful, the edit file is purged. For more information, refer to the descriptions of the create, edit, and add commands in this chapter. For user definitions, if a password field remains empty when you exit the editor, the old password is retained. To specify a null password use two consecutive double quotes (). | | | | | | | | |
Examples
To modify all calendars, run the following command:
modify calendars
To modify job stream sked9 that is launched on workstation site1, run the following command:
m sched=site1#sked9
See Also
For the equivalent Job Scheduling Console task, see Monitoring Tasks in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
73
new
Adds a new scheduling object. You must have add access for new objects on the workstation. For existing objects, you must have modify access to the object or the affected database file.
Synopsis
new
Usage Notes
The new command creates a temporary file, edits the file, and then adds the contents of the file. For calendars, parameters, resources, and prompts, use the modify command on page 72. | | | | | | | |
Examples
To create a temporary file, edit the file, and then add the contents of the file to the database, run the following command:
new or: n
74
redo
Edits and reruns the previous command.
Synopsis
redo
Context
When you run the redo command, Composer displays the previous command, so that it can be edited and rerun. Use the spacebar to move the cursor under the character to be modified, and enter the following directives. Directives d[dir] itext rtext Deletes the character above the d. This can be followed by other directives. Inserts text before the character above the i. Replaces one or more characters with text, beginning with the character above the r. Replace is implied if no other directive is entered. Appends text to the end of the line.
>text
>d[dir | text] Deletes characters at the end of the line. This can be followed by another directive or text. >rtext Replaces characters at the end of the line with text.
Directive Examples ddd iabc rabc abc d diabc Deletes the character above the first d, skips one character, deletes the character above the second d, and inserts abc in its place. >abc >ddabc Deletes the last two characters in the line, and inserts abc in their place. >rabc | | | | | | | Replaces the last three characters in the line with abc. Appends abc to the end of the line. Deletes the three characters above the ds. Inserts abc before the character above the i. Replaces the three characters, starting with the one above the r, with abc. Replaces the three characters above abc with abc.
Examples
To insert a character, run the following command:
redo dislay site1#sa@ ip display site1#sa@
75
| | | | |
76
replace
Replaces scheduling objects. You must have modify access to the objects or the affected database file.
Synopsis
replace filename
Arguments
filename Specifies the name of a file containing one of the following: v Job definitions. The first line of the file must be $jobs. v Job stream definitions. v Any combination of workstation, workstation class, and domain definitions. v User definitions. v A complete set of calendars, parameters, prompts, or resources.
Usage Notes
The replace command is similar to the add command, except that there is no prompt to replace existing objects. For more information, refer to add on page 60. | | | | | | | | |
Examples
To replace the jobs from the file myjobs, run the following command:
replace myjobs
To replace the job streams from the file mysked, run the following command:
rep mysked
To replace all resources with those contained in the file myres, run the following command:
rep myres
77
system command
Runs a system command.
Synopsis
[: | !] sys-command
Arguments
sys-command Specifies any valid system command. The prefix of colon (:) or exclamation mark (!) is required only when the command is spelled the same as a Composer command.
| | | | | |
Examples
To run a ps command on UNIX, run the following command:
ps -ef
78
validate
Validates a file containing scheduling objects.
Synopsis
validate filename[;syntax]
Arguments
filename Specifies the name of a file that contains calendars, workstations, workstation classes, domains, jobs, parameters, prompts, resources, or job streams. Enter prodsked to validate the production schedule file created during pre-production day processing. syntax Checks the file for syntax error.
Usage Notes
The validate command performs the same syntax checks and validation that are performed when you add or modify objects. It can also be used to validate the production schedule file, prodsked, created during the pre-production day processing. Prodsked contains the job streams to be run on a particular day, and it can be modified with an editor to include ad hoc changes before processing day begins. Validate should be used in these cases to ensure that the production schedule is still valid. 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. For example, a needs dependency on a non-existent resource is reported. This will also check for references to non-existent calendars. v Check for circular dependencies. For example, if job1 follows job2, and job2 follows job1 there is a circular dependency. The output of the validate command can be redirected to a file as follows:
composer "validate filename" > outfile
| | | | | | | | |
Examples
To check the syntax of a file containing workstation definitions, run the following command:
validate mycpus;syntax
You can do this to verify the integrity of references to other scheduling objects after changes have been made.
79
version
Displays the Composers command line program banner.
Synopsis
version | | | | | |
Examples
To display the Composers command line program banner, run the following command:
version
or:
v
80
81
Do not attempt to write job streams on a single line, since they will be rejected by the schedulr command after having been apparently accepted by composer. For instance, writing the following schedule in one line:
SCHEDULE cbdbu01#NN_CBCID1001YS31 ON CBZZ0001 PRIORITY 10 FOLLOWS cbdbu02#NN_CBTND10011501:cbdbu01#JN_CBCID1001YS1GA1 PRIORITY 10 OPENS "/st01/st01if/in/CUBCIFYS1GA1001.dat.ok"
will result in an error being returned when the schedule is processed by schedulr. For this example, you should do one of the following: v Use composer to: 1. Create a filename from schedule=cbdbu01#NN_CBCID1001YS31 (or all the schedules that are defined in this way). 2. Run composer add filename v Split the schedule in the following way:
SCHEDULE cbdbu01#NN_CBCID1001YS31 ON CBZZ0001 PRIORITY 10 FOLLOWS cbdbu02#NN_CBTND10011501:cbdbu01#JN_CBCID1001YS1GA1 PRIORITY 10 OPENS "/st01/st01if/in/CUBCIFYS1GA1001.dat.ok"
Keywords
A brief description of the scheduling keywords is provided in the following table.
Keyword at carryforward comments confirmed deadline end every except follows Description Defines the time of day that job stream or job execution begins. Carries the job stream forward if it is not completed. Includes comments in a job stream definition Specifies that the completion of this job requires confirmation. Specifies the time within which a job or job stream should complete. Marks the end of a job stream. Launches the job repeatedly at a specified rate. Specifies dates that are exceptions to the dates the job stream is selected for execution. Specifies not to launch this job or job stream until other jobs and job streams have completed successfully. Page at on page 84 carryforward on page 85 comments on page 86 confirmed on page 87 deadline on page 88 end on page 89 every on page 90 except on page 91 follows on page 93
freedays
Specifies a freeday calendar for calculating workdays freedays on for the job stream. It can also set Saturdays and page 94 Sundays as workdays. Defines a job and its dependencies. job statement on page 96
Marks a job as key or critical in both the database keyjob on and daily plan for monitoring by applications, such page 101 as IBM Tivoli Business Systems Manager or Tivoli Enterprise Console.
82
Keyword keysched
Description Marks a job stream as key or critical in both the database and daily plan for monitoring by applications, such as IBM Tivoli Business Systems Manager or Tivoli Enterprise Console. Sets a limit on the number of jobs that can be launched concurrently from the job stream. Defines the number of units of a resource required by the job or job stream before it can be launched. Defines the dates on which the job stream is selected for execution. Defines files that must be accessible before the job or job stream is launched. 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. Defines a time of day after which the job or job stream is not launched.
limit on page 103 needs on page 104 on on page 105 opens on page 108 priority on page 110 prompt on page 111 schedule on page 112 until on page 113
Dependencies
A dependency is a condition that must be satisfied before a job or job stream is launched. They are to job streams with the follows, needs, opens and prompt keywords. The maximum number of dependencies permitted for a job or job stream is 40. Note: The only dependency that is checked immediately before running a job is NEEDS. An OPENS dependency is automatically considered resolved before the job runs.
Case sensitivity
With the exception of path names, user names, and UNIX commands, which are case-sensitive, you can use either upper or lower case characters when writing your schedules.
Keyword descriptions
The following pages describe the syntax for scheduling language keywords.
83
at
Defines the earliest time a job or job stream will be launched.
Synopsis
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 Appendix B, Managing time zones, on page 319 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 time are specified, the time zones must be the same. n Specifies an offset in days from the scheduled start date and time.
Usage Notes
If an at time is not specified for a job or job stream, its launch time is determined by its dependencies and priority. The time value in the at option is considered as follows: If the time value is less than the current time, it is taken as for the following day. If the time value is greater than the current time, it is taken as for the current day. If you specify a time value greater than 2400, the value is divided by 2400 to obtain the number of days. If you specify days, these are add to the value obtained by dividing by 2400.
Examples
The following examples assume that the IBM 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 Pacific Standard Time (pst), and the time zone of workstation nycity is defined as Eastern Standard Time (est). The following job stream is selected for execution on Friday. It is launched on workstation sfran at 10:00 a.m. pst Saturday. job1 is launched on sfran as soon as possible after that time. job2 is launched on sfran at 2:00 p.m. est (11:00 a.m. pst) Saturday. job3 is launched on workstation nycity at 4:00 p.m. est (1:00 p.m. pst) Saturday.
sfran#schedule sked8 on fr at 1000 + 1 day : job1 job2 at 1400 tz est nycity#job3 at 1600 end
84
carryforward
Makes a job stream eligible to be carried forward to the next days production plan if it is not completed before the end of the current days production plan.
Synopsis
carryforward
Examples
The following job stream is carried forward if its jobs have not completed before pre-production processing begins for a new day.
schedule sked43 on th carryforward : job12 job13 job13a end
85
comments
Includes comments in a job stream definition.
Synopsis
*text | <<text>>
Arguments
*text Inserts a comment line. The first character in the line must be an asterisk. <<text>> Inserts comment text on a line. The text must be enclosed in double angle brackets.
Examples
The following example includes both types of comments:
**************************************** * The weekly cleanup jobs **************************************** * schedule wkend on fr at 1830 carryforward : job1 <<final totals and reports>> job2 <<update database >> end
86
confirmed
Specifies that a jobs completion must be confirmed by executing a Conman confirm command. See confirm on page 145 for more information.
Synopsis
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
87
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 has expired, 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.
Synopsis
deadline 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 deadline. See Appendix B, Managing time zones, on page 319 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.
Examples
The following example launches job stream sked7 everyday 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
88
end
Marks the end of a job stream definition.
Synopsis
end
Examples
schedule test1 on monthend : job1 job2 job3 end << end of job stream >>
89
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 when the dependency is satisfied.
Synopsis
every rate
Arguments
rate The repetition rate expressed in hours and minutes, in the format: hhmm. (The rate can be greater than 24 hours.)
Usage Notes
| | | | | | | | | If an every job abends , the iteration continues. If the every option is used with the AT dependency, jobs are launched at specific times. If one rerun is delayed (for a dependency or for any other reason) IBM Tivoli Workload Scheduler will realign to the AT time. In this case one or two iterations might not respect the EVERY rate. If the EVERY option is used without the AT dependency, the rerun jobs will be 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 can there be any interactions that do not respect the every rate. For all other cases the every rate is always respected.
Examples
The following example runs the job testjob every hour:
testjob every 100
The following example runs the job testjob1 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 will run at 1800, 1815, 1830, and so on. If the job is submitted adhoc at 1833, the reruns will be at 1833,1834,1845 and so on. The following example does not start the job testjob2 iteration until the job testjob1 has completed successfully:
testjob2 every 15 follows testjob1
90
except
Defines the dates that are exceptions to the on dates of a job stream. See on on page 105 for more information.
Synopsis
except {date| day | calendar } [fdignore | fdnext | fdprev][,...] [except {date| day | calendar }] [fdignore | fdnext | fdprev][,...]]
Arguments
date day A date in the format: mm/dd/yy. A day of the week. Specify one or more of the following: mo Monday tu Tuesday we Wednesday th Thursday fr Friday sa Saturday su Sunday weekdays Everyday except Saturday and Sunday. workdays Can be one of the following: v If you specified a freedays calendar, workdays are everyday excluding saturday and sunday (unless you specified -sa or -su along with the freedays keyword) and excluding all the dates of the specified freedays calendar. v If you did not specify a freedays calendar, workdays are everyday excluding saturday and sunday and excluding all the dates of the holidays calendar. freedays The days marked in the freedays calendar, if you specified one. The dates specified on a calendar by this name. 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, weekdays, or workdays. Stands for every day of the week.
calendar
weekdays Stands for every day of the week, except Saturday and Sunday. workdays Stands for every day of the week, except for Saturdays and Sundays (unless otherwise specified with the freedays keyword) and for the dates marked either in a designated freedays calendar or in the holidays calendar. freeday rule Specifies a rule that must be applied when the date selected for exclusion falls on a freeday. Can be one of the following:
91
fdignore Do not exclude the date. fdnext Exclude the nearest workday after the freeday. fdprev Exclude the nearest workday before the freeday.
Usage Notes
You can define multiple instances of the except keyword for the same job stream. Each instance is equivalent to a run cycle to which you can associate a freeday rule. Multiple except instances must be consecutive within the job stream definition. Each instance of the keyword can contain any of the values allowed by the except syntax.
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,holidays
The following example selects job stream testskd3 to run every weekday except May 15,1999 and May 23, 1999:
schedule testskd3 on weekdays except 05/15/99,05/23/99
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
Select job stream sked4 to run on Mondays, Tuesdays, and 2 weekdays prior to each date listed in the MONTHEND calendar. If the run date is a freeday, run the job stream on the nearest following workday. Do not run the job stream on Wednesdays.
schedule sked4 on mo on tu, MONTHEND -2 weekdays fdnext except we
Select job stream testskd2 to run every weekday except for the days listed in MONTHEND. If a date in MONTHEND falls on a freeday, exclude the nearest workday before it. In this example, the freedays are Saturdays, Sundays, and all the dates listed in the default holidays calendar .
schedule testskd2 on weekdays except MONTHEND fdprev
92
follows
Defines the other jobs and job streams that must complete successfully before a job or job stream is launched.
Synopsis
Use the following syntax for job streams: follows [netagent::][wkstation#]jstream[.jobname | @] [,...] Use the following syntax for jobs: follows [netagent::][wkstation#]jstream{.jobname | @} | jobname [,...]
Arguments
netagent The name of the network agent where the inter-network dependency is defined. wkstation The workstation on which the job or job stream that must be complete runs. The default is the same workstation as the dependent job or job stream. If a wkstation is not specified with netagent, the default is the workstation to which the network agent is connected. jstream The name of the job stream that must be complete. For a job, the default is the same job stream as the dependent job. jobname The name of the job that must be complete. An at sign (@) can be used to indicate that all jobs in the job stream must complete successfully.
Examples
The following example specifies to not 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,site2#sked5.joba
Do not launch sked6 until jobx in the job stream skedx on remote network cluster4 has completed successfully:
sked6 follows cluster4::site4#skedx.jobx
The following example specifies to not launch jobd until joba in the same job stream, and job3 in job stream skeda have completed successfully:
jobd follows joba,skeda.job3
The following example specifies to not launch jobe until all jobs in job stream skedb on workstation unix1 have completed successfully:
jobe follows unix1#skedb.@
93
freedays
Enables you to specify the name of a freedays calendar (see the Users Guide for a description of freedays calendars) that lists the days when the job stream should not run. Tivoli Workload Scheduler uses this calendar as the base calendar for calculating workdays for the job stream. The keyword affects only the scheduling of the job streams for which it is specified.
Synopsis
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. If Calendar_Name is not in the database, Tivoli Workload Scheduler issues a warning message when you save the job stream. If Calendar_Name is not in the database when scheduler runs, Tivoli Workload Scheduler issues an error message and uses the default calendar holidays in its place. Do not use the names of weekdays for the calendar names. -sa -su Count Saturdays as workdays. Count Sundays as workdays.
Usage Notes
If you do specify a freedays calendar in the job stream definition, then the workdays keyword takes on the following value: workdays = everyday excluding saturday and sunday (unless user 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, then: workdays = everyday excluding saturday and sunday and all the dates of the holidays calendar By default, saturday and sunday are considered as freedays unless you specify the contrary by adding -sa and/or -su after Calendar_Name.
Examples
Select job stream sked2 to run on 01/01/2001 and on all workdays as long as they are not listed in the freedays calendar named GERMHOL.
schedule sked2 freedays GERMHOL on 01/01/2001, workdays
Select job stream sked3 to run two workdays before each date in the PAYCAL calendar. Workdays are everyday from Monday to Saturday as long as they are not listed in the freedays calendar named USAHOL.
schedule sked3 freedays USAHOL -sa on PAYCAL -2 workdays
Select job stream sked3 on the dates listed in the APDATES calendar. If the selected date is a freeday, do not run the job stream. In this example, Sundays and all the dates listed in the GERMHOL calendar are to be considered as freedays. All days from Monday to Saturday, except for the specific dates listed in GERMHOL, are workdays.
94
Select job stream testsked3 to run every weekday except 5/15/2002 and 5/23/2002. If 5/23/2002 is a freeday, do not exclude it. In this example, Saturdays, Sundays, and all the dates listed in GERMHOL are to be considered as freedays. All days from Monday to Friday, except for the specific dates listed in GERMHOL, are workdays.
schedule testskd3 freedays GERMHOL on weekdays except 5/15/2002 fdignore except 5/23/2002
Select job stream testsked4 to run every day except two weekdays prior to every date listed in the MONTHEND calendar. If the date to be excluded is a freeday, do not exclude it, but exclude the nearest following workday. In this example, freedays are all the dates listed in USAHOL, while workdays are all the days from Monday to Sunday that are not in USAHOL.
schedule testskd4 freedays USAHOL -sa -su on everyday except MONTHEND -2 weekdays fdnext
95
job statement
Job statements place jobs in a job stream and define job dependencies. In a job statement, you can also include job attributes and recovery options that add a new job or modify an existing job in the database. See Usage Notes for more information.
Synopsis
[wkstation#]jobname [description text] [scriptname filename | docommand commandline][streamlogon username] [interactive] [rccondsucc Success Condition] [recovery {stop | continue | rerun} [after [wkstation#]jobname] [abendprompt text] ] [job-dependency [,...]]
Arguments
wkstation Specifies the name of the workstation or workstation class on which the job runs. The default is the workstation on which the job stream runs. The pound sign (#) is a required delimiter. If you specify a workstation class, it must match the workstation class of any job stream in which the job is included. jobname Specifies the name of the job. The name must start with a letter, and can contain alphanumeric characters, dashes and underscores. It can contain up to 40 characters. Note: Do not use the word recovery as the job name. This is reserved. description A free-form description of the job, enclosed in double quotes. scriptname filename Specifies the name of the file the job runs. Use scriptname for UNIX and Windows jobs. For an executable file, enter the file name and any options and arguments. The length of filename plus the length of Success Condition (of the rccondsucc keyword) must not exceed 4095 characters. You can also use IBM Tivoli Workload Scheduler parameters. See Using Parameters in Job Definitions on page 99 for more information. For Windows jobs, include the file extensions. Universal Naming Convention (UNC) names are permitted. Do not specify files on mapped drives. If spaces or special characters are included, other than slashes (/) and backslashes (\), the entire string must be enclosed in quotes (). If the file name contains spaces, enter the name in another file that does not have spaces in its name and use the second files name for this argument. docommand command Specifies a command that the job runs. Enter a valid command and any options and arguments enclosed in quotes (). The length of command plus
96
the length of Success Condition (of the rccondsucc keyword) must not exceed 4095 characters. A command is run directly and, unlike scriptname, the configuration script, jobmanrc, is not run. Otherwise, the command is treated as a job, and all job rules apply. You can also enter IBM Tivoli Workload Scheduler parameters. See Using Parameters in Job Definitions on page 99 for more information. On Windows-based fault-tolerant agents, jobs will fail if the path of the script/program that is to run contains a blank. For example, the statement
CMD.EXE /C "C:\PROGRAM FILES\CCR\CCR_CONSOLIDATE.BAT"
because blanks are not managed in this context. streamlogon The user name under which the job runs. The name can contain up to 47 characters. If the name contains special characters it must be enclosed in quotes (). Specify a user that can log on to the workstation on which the job runs. You can also enter IBM Tivoli Workload Scheduler parameters. See Using Parameters in Job Definitions on page 99. For Windows jobs, the user must also have a user definition. See User definitions on page 47 for user requirements. interactive For Windows jobs, include this keyword to indicate that the job runs interactively on the Windows desktop. rccondsucc Success Condition An expression which determines the return code (RC) required to consider a job successful. The success condition maximum length must be 256 characters. This expression can contain a combination of comparison and boolean expressions: Comparison expression Specifies the job return codes. The syntax is:
(RC operator operand)
RC
The RC keyword.
97
operand An integer between -2147483647 and 2147483647. For example, 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. The syntax is:
comparison_expression operator comparison_expression
comparison_expression The expression is evaluated from left to right. You can use parentheses to assign a priority to the expression evaluation. operator Logical operator. It can have the following values:
Table 10. 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. TRUE if either expr_a or expr_b is TRUE. TRUE if expr_a is not TRUE.
For example, 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, and less than 10 as follows:
rccondsucc "(RC=3) OR ((RC>=5) AND (RC<10))"
recovery Recovery options for the job. The default is stop with no recovery job and no recovery prompt. Enter one of the recovery options, stop, continue, or rerun. This can be followed by a recovery job, a recovery prompt or both. stop If the job abends, do not continue with the next job.
continue If the job abends, continue with the next job. rerun If the job abends, rerun the job.
after [wkstation#]jobname Specifies the name of a recovery job to run if the parent job abends. Recovery jobs are run only once for each abended instance of the parent job. You can specify the recovery jobs workstation if it is different than the parent jobs workstation. The default is the parent jobs workstation. Not all jobs are eligible to have recovery jobs run on a different workstation. Follow these guidelines: v If either workstation is an extended agent, it must be hosted by a domain manager or a fault-tolerant agent with a value of on for fullstatus.
98
v The recovery jobs workstation must be in the same domain as the parent jobs workstation. v If the recovery jobs workstation is a fault-tolerant agent, it must have a value of on for fullstatus. abendprompt text Specifies the text of a recovery prompt, enclosed in quotes, to be displayed if the job abends. The text can contain up to 64 characters. If the text begins with a colon (:), the prompt is displayed, but no reply is required to continue processing. If the text begins with an exclamation mark (!), the prompt is not displayed, but a reply is required to proceed. job-dependency Specifies scheduling keywords and arguments. The valid keywords for jobs are: at, confirmed, every, follows, needs, opens, priority, prompt, and until. Using Parameters in Job Definitions: Parameters have the following uses and limitations in job definitions: v Parameters are allowed in the streamlogon, scriptname, and docommand values. v A parameter can be used as an entire string or a part of it. v Multiple parameters are permitted in a single variable. v Enclose parameter names in carets (^), and enclose the entire string in quotation marks. See the example below in which a parameter named mis is used in the streamlogon value. For additional examples, see Parameter definitions on page 50.
Usage Notes
A job needs to be defined only once in the database, and can be used in multiple job streams. When a job stream is added or modified, the attributes or recovery options of its jobs are also added or modified. When defining jobs, keep the following in mind: v Jobs can be defined independently (as described in Job definitions on page 42), or as part of job streams. In either case, the changes are made in the database and do not affect the production plan until the start of a new processing day. v When you add or replace a job stream, any job modifications affect all other job streams that use the jobs. Note that the Cross Reference Report can be used to determine the names of job streams in which a particular job is included.
Examples
The following example defines a job stream with three previously defined jobs:
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:
99
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
100
keyjob
The keyjob keyword is used to mark a job as key or critical in both the database and daily plan and for monitoring by applications, such as Tivoli Business Systems Manager. See the IBM Tivoli Workload Scheduler Planning and Installation Guide for information about enabling the key flag mechanism.
Examples
The following example
SCHEDULE cpu1#sched1 ON everyday KEYSCHED AT 0100 cpu1#myjob1 KEYJOB END
101
keysched
The keysched keyword is used to mark a job stream as key or critical in both the database and daily plan and for monitoring by applications, such as Tivoli Business Systems Manager. See the IBM Tivoli Workload Scheduler Planning and Installation Guide for information about enabling the key flag mechanism.
Synopsis
keysched
Examples
The following example :
SCHEDULE cpu1#sched1 ON everyday KEYSCHED AT 0100 cpu1#myjob1 KEYJOB END
102
limit
Limits the number of jobs that can run simultaneously in a job stream.
Synopsis
limit joblimit
Arguments
joblimit Specifies the number of jobs that can be running at the same time in the schedule. Possible values are 0 through 1024. If you specify 0, you prevent all jobs from being launched.
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 :
103
needs
Defines resources that must be available before a job or job stream is launched.
Synopsis
needs [n] [wkstation#]resourcename [,...]
Arguments
n Specifies the number of resource units required. Possible values are 0 through 32. The default is one. Note: The number of jobs and schedules using a resource at any one time cannot exceed 32. wkstation Specifies the name of the workstation on which the resource is locally defined. The default is the workstation of the dependent job or job stream. Resources can be used as dependencies only by jobs and job streams that run on the same workstation as the resource. However, a standard agent and its host can reference the same resources. Specifies the name of the resource.
resourcename
Examples
The following example prevents job stream sked3 from being launched until three units of cputime, and two units of tapes become available:
schedule sked3 on fr needs 3 cputime,2 tapes :
The jlimit resource has been defined with two available units. 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,we,fr : jlimit jlimit jlimit <<runs alone>> jlimit
104
on
This is a required job stream keyword that defines when and how often a job stream is selected for execution. The on keyword must follow the schedule keyword. See except on page 91 for more information.
Synopsis
on {date| day | calendar | request}[,...] [fdignore | fdnext | fdprev][,...] [on {date| day | calendar | request}[,...] [fdignore | fdnext | fdprev]][,...]
Arguments
date day Specifies a date in the format, mm/dd/yy. A day of the week. You can specify one or more of the following: mo Monday tu Tuesday we Wednesday th Thursday fr Friday sa Saturday su Sunday weekdays Everyday except Saturday and Sunday everyday Every day of the week workdays Can be one of the following: v If you specified a freedays calendar, workdays are everyday excluding saturday and sunday (unless you specified -sa or -su along with the freedays keyword) and excluding all the dates of the specified freedays calendar. v If you did not specify a freedays calendar, workdays are everyday excluding saturday and sunday and excluding all the dates of the holidays calendar. freedays The days marked in the freedays calendar, if you specified one. The dates specified on a calendar by this name. 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, weekdays, or workdays. Stands for every day of the week.
calendar
weekdays Stands for every day of the week, except saturday and sunday. workdays Stands for every day of the week, except for Saturdays and Sundays (unless otherwise specified with the freedays keyword) and for the dates marked either in a designated freedays calendar or in the holidays calendar. | | request Selects the job stream only when requested. This is used for job streams
Chapter 4. The scheduling language
105
| | | | | | | |
that are selected by name rather than date. To prevent a scheduled job stream from being selected for Jnextday, change its definition to ON REQUEST. Note: When attempting to run a job stream that contains on request times, consider that: v On request always takes precedence over at. v On request never takes precedence over on. freeday rule Specifies a rule that must be applied when the selected date falls on a freeday. Can be one of the following: fdignore Do not run the job stream. fdnext Run the job stream on the nearest workday after the freeday. fdprev Run the job stream on the nearest workday before the freeday.
Usage Notes
You can define multiple instances of the on keyword for the same job stream. Each instance is equivalent to a run cycle to which you can associate a freeday rule. Multiple on instances must be consecutive within the job stream definition. Each instance of the keyword can contain any of the values allowed by the on syntax. You must specify the on keyword at least once in the definition of a job stream.
Examples
The following example selects job stream sked1 on Mondays and Wednesdays:
schedule sked1 on mo,we
The following example selects job stream sked3 on June 15, 1999, and on the dates listed on the apdates calendar:
schedule sked3 on 6/15/99,apdates
The following example selects job stream sked4 two weekdays before each date appearing on the monthend calendar:
schedule sked4 on monthend -2 weekdays
The following example selects job stream testskd1 every weekday except Wednesdays:
schedule testskd1 on weekdays except we
The following example selects job stream testskd3 every weekday except May 15, 1999 and May 24, 1999:
schedule testskd3 on weekdays except 05/16/99,05/24/99
The following example selects job stream testskd4 every day except two weekdays prior to any date appearing on a calendar named monthend:
106
Select job stream sked1 to run all Mondays, Fridays, and on 29/12/2001. If Mondays and 29/12/2001 are freedays, run the job stream on the nearest following workday. If Fridays are freedays, run the job stream on the nearest preceding day. In this example, the freedays are Saturdays, Sundays, and all the dates listed in the default HOLIDAYS calendar. Workdays are all days from Monday to Friday as long as they are not listed in HOLIDAYS.
schedule sked1 on mo, 29/12/2001 fdnext on fr fdprev
107
opens
Specifies files that must be available before a job or job stream can be launched.
Synopsis
opens [wkstation#]filename [(qualifier)] [,...]
Arguments
wkstation Specifies the name of the workstation or workstation class on which the file exists. The default is the workstation or workstation class of the dependent job or job stream. If you use a workstation class, it must be the same as that of the job stream that includes this statement. filename Specifies the name of the file, enclosed in quotation marks. You can use IBM Tivoli Workload Scheduler parameters as part or all of the file name string. If you use a parameter, it must be enclosed in carets (^). The file name must be fully qualified for all workstation types with the exception of extended agents (XAs), where this is not a requirement. qualifier Specifies a valid test condition. On UNIX, the qualifier is passed to a test command, which runs as root in bin/sh. On Windows, the test function is performed as the maestro user. The valid qualifiers are: -d %p -e %p -f %p -r %p -s %p -w %p True if the file exists and is a directory. True if the file exists. True if the file exists and is a regular file. True if the file exists and is readable. True if the file exists and its size is greater than zero. True if the file exists and is writable.
On both UNIX and Windows, the expression %p, inserts the name of the file. Entering (notempty) is the same as entering (-s %p). If no qualifier is specified, the default is (-f %p).
Usage Notes
| | The combination of the path of the file and the qualifiers cannot exceed 120 characters, and the name of the file cannot exceed 28 characters.
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, /john, /mary, and /roger, exist before launching job jobr2:
jobr2 opens "/users"(-d %p/john -a -d %p/mary -a -d %p/roger)
108
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, 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 with a size greater than zero, and is writable, before running job job77:
job77 opens nyc#"C:\tech\checker\startf"(-s %p -a -w %p)
Security for test(1) Commands: On UNIX, a special security feature prevents unauthorized use of other commands in the qualifier. For example, 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, the following checks are made: 1. The Local Option jm no root must be set to no. 2. In the security file, the user documenting the schedule or adding the Open Files dependency with a Conman adddep command, must have submit access to a job with the following attributes: name=cmdstest.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.
109
priority
Sets the priority of a job or job stream.
Synopsis
priority number | hi | go
Arguments
number hi go Specifies the priority. Possible values are 0 through 99. A priority of zero prevents the job or job stream from launching. The equivalent of priority 100. The equivalent of priority 101, the highest priority.
Examples
The following example illustrates the relationship between job stream and job priorities. The jobs are launched in the following order: job1, job2, joba, jobb.
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
If the job stream priorities were the same, the jobs would be launched in the following order: joba, jobb, job1, job2.
110
prompt
Specifies prompts that must be answered affirmatively before a job or job stream is launched.
Synopsis
prompt promptname [,...] prompt [: | !]text [...]
Arguments
promptname text Specifies the name of a prompt in the database. Specifies a literal prompt as a text string enclosed in quotes (). Multiple strings separated by backlash n (\n) can be used for long messages. If the string begins with a colon (:), the message is displayed but no reply is necessary. If the string begins with an exclamation point (!), the message is not displayed but it requires a reply. You can include backslash n (\n) within the text for new lines. You can use one or more parameters as part or all of the text string. To use a parameter, place its name between carets (^). Note: Within a local prompt, when not designating a parameter, carets (^) must be preceded by a backslash (\) or they will cause errors in the prompt. Within global prompts, carets do not have to be preceded by a backslash.
Examples
The following example illustrates both literal and named prompts. The first prompt is a literal prompt that uses a parameter named sys1. When a single affirmative reply is received for the named prompt apmsg, the dependencies for both job1 and job2 are satisfied.
schedule sked3 on tu,th prompt "All ap users logged out of ^sys1^? (y/n)" : job1 prompt apmsg job2 prompt apmsg end
The following example defines a literal prompt that will appear on more than one line. 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.\n Do you want to launch it now? (y/n)" : j1 j2 follows j1 end
111
schedule
Specifies the job stream name. With the exception of comments, this must be the first keyword in a job stream, and must be followed by the on keyword.
Synopsis
schedule [wkstation#]jstreamname on ...
Arguments
wkstation Specifies the name of the workstation on which the job stream is launched. The default is the workstation on which Composer runs to add the job stream.
jstreamname Specifies the name of the job stream. The name must start with a letter, and can contain alphanumeric characters, dashes, and underscores. It can contain up to 16 characters. on Specifies when, or how often, the job stream is selected for execution. See on on page 105 for more information.
Examples
The following example names a job stream sked1 that runs on the workstation on which Composer is running:
schedule sked1 on tu
The following example names a job stream sked-2 that runs on the workstation on which Composer is running:
schedule sked-2 on everyday except fr
The following example names a job stream skedux7 that runs on workstation hpux3:
schedule hpux3#skedux7 on monthend
112
until
Specifies the latest time a job or job stream will be launched.
Synopsis
until time [timezone|tz tzname][+n day[s]] [onuntil action]
Arguments
time Specifies the time of day. The possible values are 0000 through 2359. tzname Specifies the time zone to be used when computing the time. See Appendix B, Managing time zones, on page 319 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 until time and an at time are specified, the time zones must be the same. n Specifies an offset, in days, from the scheduled date and time.
onuntil action Specifies the action to be taken on a job or job stream whose until time has expired, but the job or job stream has not yet started. The following are the possible values of the action parameter: | | | | | suppr The final job stream state is HOLD if the job stream contains at least one every job. Otherwise the final state is calculated using the normal rules and the jobs with the option onuntil suppr are considered in SUCC state when the until time occurs, even if their dependencies have actually not been released. 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. A job or job stream is cancelled when the until time specified expires. Any job or job stream that was dependent on the completion of a job or job stream that was cancelled, will run because the dependency no longer exists.
canc
Examples
The following example prevents sked1 from launching after 5:00 p.m. on Tuesdays:
schedule sked1 on tu until 1700 :
The following example launches sked1 at 5:00 p.m., when its until time expires:
schedule sked1 until 1700 onuntil cont
The following example launches job1 between 1:00 p.m. and 5:00 p.m. on weekdays:
schedule sked2 on weekdays : job1 at 1300 until 1700 end
The following example launches joba every 15 minutes between 10:30 p.m. and 11:30 p.m. on Mondays:
schedule sked3 on mo : joba at 2230 every 0015 until 2330 end
113
The following example launches job stream sked4 on Sundays between 8:00 a.m. and 1:00 p.m. 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.m. and should complete running by 5 p.m. If the job stream is not completed by 5 p.m., it is considered a late job stream. The jobs are to be launched as follows: job1 runs at 4 p.m., or at the latest, 4:20 p.m., at which time, if job1 has not yet started, a notification message is written to the log and it starts running. job 2 runs at 4:30 p.m. or at the latest 4:50 p.m., at which time, if job2 has not yet started, it is cancelled.
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. When the until event occurs, the job stream sked02 is run because the job stream sked01 is placed in SUCC state. The job stream sked03, instead, is not run because it has a punctual time dependency on job job01 and this dependency has not been released.
SCHEDULE sked01 on everyday: job01 until 2035 onuntil suppr end SCHEDULE sked02 on everyday follows sked01.@ : job02 end SCHEDULE sked03 on everyday follows sked01.JTEST : job03 END
114
Running conman
To run Conman, enter the following command:
conman [command[&...][&]"]
Examples
In the following example, Conman starts and prompts for a command:
conman
In the following example, Conman runs the sj and sp commands, and then quits:
conman"sj&sp"
In the following example, Conman runs the sj and sp commands, and then prompts for a command:
conman"sj&sp&"
Control characters
You can enter the following control characters to interrupt Conman. Control+c Conman stops executing the current command at the next step that can be interrupted, and returns a command prompt. Control+d Conman quits after executing the current command.
115
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 Conman is run 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.
Terminal output
The output to your computer is specified by 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 the method of displaying object names. 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 commands output. Set it to one of the following: > file Redirects output to a file and overwrites the contents of the file. If the file does not exist, it is created.
>> file Redirects output to a file and appends the output to the end of the 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 is | lp -tCONLIST which pipes the command output to the printer and places the title CONLIST in the printouts banner page.
116
$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.
Command syntax
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.@+state=hold~priority=0;info;offline
sked1.@+state=hold~priority=0 Selects all jobs in the job stream sked1 that are in the hold state with a priority other than zero. ;info;offline Arguments for the showjobs command.
Wildcard characters
The following wildcard characters are permitted: @ Replaces one or more alphanumeric characters.
117
? %
List of commands
The following table lists the Conman command set. Command names and keywords can be entered in either uppercase or lowercase characters, and can be
118
abbreviated to as few leading characters as are needed to distinguish them from each other. Some of the command names also have short forms.
Command adddep altpass altpri cancel confirm console continue deldep display exit fence help5 kill limit link listsym recall redo release reply rerun resource setsym showcpus showdomain showfiles showjobs showprompts sf sj sp sc rr rj | rs rc lc | ls lk ddj | dds df | dj | ds ap cj | cs Short Form Description adj | ads Adds job or job stream dependencies. Alters a User object definition password. Alters job or job stream priorities. Cancels a job or a job stream. Confirms job completion. Assigns the IBM Tivoli Workload Scheduler console. Ignores the next error. Deletes job or job stream dependencies. Displays files, jobs, and job streams. Terminates Conman. Sets IBM Tivoli Workload Scheduler job fence. Displays command information. Stops an executing job. Changes a workstation or job stream job limit. Opens workstation links. Displays a list of Symphony log files. Displays prompt messages. Edits the previous command. Releases job or job stream dependencies. Replies to prompt message. Reruns a job. Changes the number of resource units. Selects a Symphony log file. Displays workstation and link information. Displays domain information. Displays information about files. Displays information about jobs. Displays information about prompts. Type1 M,F M,F M,F M,F M,F M,F,A M,F,A M,F M,F,A2 M,F,A M,F,A M,F,A M,F M,F,A M,F,A M,F M,F M,F,A M,F M,F M,F M,F M,F M,F,A M,F,A M,F M,F M,F
3
Page 135, 137 139 140 148, 143 145 146 147 165, 150 152 153 154 155 156 157, 158 159 161 162 163 141, 167 169 170 173 174 175 179 180 182 190
119
Type1 M,F
Displays information about job M,F streams. Stops IBM Tivoli Workload Scheduler production processes. Starts IBM Tivoli Workload Scheduler production processes. Displays IBM Tivoli Workload Scheduler production status. Stops IBM Tivoli Workload Scheduler production processes. Stops IBM Tivoli Workload Scheduler production processes hierarchically. M,F,A
start
M,F,A
198
status stop
M,F,A M,F,A
200 201
stop ;progressive
203
submit
M,F,A4
Switches the domain manager. Sends a command to the system. Sends a message to the console. Closes workstation links. Displays Conmans command line program banner.
1. Workstation types: domain managers (M), fault-tolerant agents (F), standard agents (A). 2. You can display only files on a standard agent. 3. You can change the limit of only jobs launched on a standard agent workstation. 4. You can use submit job (sbj) and submit sched (sbs) on a standard agent only if the mozart directory on the master domain manager is accessible to the standard agent. 5. Not available on supported Windows platforms.
120
Synopsis
[wkstation#] {jobstream.job | jobnumber} [+ | ~jobqualifier[...]] or: netagent::[wkstation#] jobstream.job
Arguments
wkstation 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. jobstream Specifies the name of the job stream in which the job runs. Wildcard characters are permitted. job 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 scheduler network agent that interfaces with the remote scheduler network containing the target job. The two colons (::) are a required delimiter. Wildcard characters are permitted. For more information refer to Chapter 9, The Network Agent reference, on page 289.
Job Qualifiers
Job qualifiers specify attributes of jobs to be acted on by a command. They are prefixed by a + or a ~. A + means that jobs with the attribute qualify for the command. A ~ means that jobs with the attribute are excluded from the commanded. Job qualifier keywords can be abbreviated to as few leading characters as needed to distinguish one from another. at[=time | lowtime | hightime | lowtime,hightime [absolute | abs]] Selects or excludes jobs based on scheduled start time. time Specifies the scheduled start time expressed as follows: hhmm[+n days | date] [timezone|tz tzname] where: 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.
121
timezone|tz tzname The name of the time zone of the job. See Appendix B, Managing time zones, on page 319 for valid names. time conforms to the following rules: v When hhmm is earlier than the current time, the start time is tomorrow; when hhmm is later than the current time, the start time is today. v When hhmm is greater than 2400, it is divided by 2400. Of the result, the whole part represents the number of + days, while the decimal part represents the time. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Jobs are selected that have scheduled start times on or after this time. hightime Specifies the upper limit of a time range, expressed in the same format as time. Jobs are selected that have scheduled start times on or before this time. absolute | abs Specifies the scheduled start time for the current day. This keyword can be used only with timezone|tz tzname and hhmm. It conforms to the following rules: v When hhmm is earlier than the current time, the start time is immediately. v When hhmm is later than the current time, the start time is the time specified by hhmm of the current day. v When hhmm exceeds 2400, it is divided by 2400 to obtain the calculated day and time. Of the division result, the whole part represents the calculated day (number of + days), while the decimal part represents the calculated time: If the calculated time is earlier than the current time, the start time is one day before the calculated day at the calculated time. If the calculated time is later than the current time, the start time is the calculated day and time. For example, if the current time is 1200 and a job is submitted at hhmm=3500 (2400 + 1100), with the abs keyword specified, the job is launched at 1100 of the following day. Instead, without specifying the abs keyword, the job is launched at 1100, two days later. If at is used alone, the range is open-ended, and jobs are selected or excluded if they have any scheduled start time. confirmed Selects or excludes jobs that were scheduled using the confirm keyword. deadline[=time | lowtime, | ,hightime | lowtime,hightime] Specifies the time within which a job must complete. hhmm[+n days | date] [timezone|tz tzname] hhmm The hour and minute.
122
+n days An offset in days from the scheduled deadline time. date The next occurrence of hhmm on date, expressed as mm/dd/yy.
timezone|tz tzname Specifies the time zone to be used when computing the deadline. See Appendix B, Managing time zones, on page 319 for time zone names. The default is the time zone of the workstation on which the job or job stream is launched. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Jobs are selected that have scheduled deadline on or after this time. hightime Specifies the upper limit of a time range, expressed in the same format as time. Jobs are selected that have scheduled deadline on or before this time. every[=rate | lowrate, | ,highrate | lowrate,highrate] Selects or excludes jobs based in whether or not they have a repetition rate. rate Specifies the scheduled execution rate, expressed as hours and minutes (hhmm).
lowrate Specifies the lower limit of a rate range, expressed in the same format as rate. Jobs are selected that have repetition rates equal to or greater than this rate. highrate Specifies the upper limit of a rate range, expressed in the same format as rate. Jobs are selected that have repetition rates less than or equal to this rate. If every is used alone, the range is open-ended, and jobs are selected or excluded if they have any repetition rate. finished[=time | lowtime, | ,hightime | lowtime,hightime] Selects or excludes jobs based on whether or not they have finished. time Specifies the exact time the jobs finished, expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute. The next occurrence of hhmm on date, expressed as mm/dd/yy.
timezone|tz tzname The name of the time zone of the job. See Appendix B, Managing time zones, on page 319 for valid names. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Jobs are selected that finished at or after this time. hightime Specifies the upper limit of a time range, expressed in the same format as time. Jobs are selected that finished at or before this time. If finished is used alone, the range is open-ended, and jobs are selected or excluded if they have finished executing.
Chapter 5. Conman reference
123
follows[=[netagent::][[wkstation#] jobstream.]job[;nocheck][;wait=time]] Selects or excludes jobs based on whether or not they have a follows dependency. netagent Specifies the name of the scheduler network agent that interfaces with the remote scheduler network containing the prerequisite job. Wildcard characters are permitted. For more information refer to Chapter 9, The Network Agent reference, on page 289. wkstation Specifies the name of the workstation on which the prerequisite job runs. Wildcard characters are permitted. jobstream Specifies the name of the job stream in which the prerequisite job runs. Wildcard characters are permitted. If you enter jobstream.@, you specify that the target job follows all jobs in the job stream. job Specifies the name of the prerequisite job. When entered without a jobstream, it means that the prerequisite job is in the same job stream as the target job. Do not specify the job name using wildcard characters for a follows dependency.
nocheck Is valid only for the sbd, sbj, and sbs commands. Conman does not check for the existence of prerequisite jobs in the symphony. When Batchman processes the submit command, it adds the arguments of the submit command to the symphony (such as the job to be submitted) including the dependencies on the prerequisite jobs that exist in the symphony. For those prerequisite jobs that do not exist in the symphony file, Batchman prints a warning in the stdlist. wait=time Is valid only for the sbd, sbj, and sbs commands. For the time interval specified, conman checks every second for the existence of the prerequisite jobs in the symphony file. Conman checks until the prerequisite jobs are found or the time interval specified for the wait keyword expires. When all prerequisite jobs are found, Batchman processes the submit command. If even one prerequisite job is not found in the symphony and the time interval expires, Conman does not process the submit command and returns an error message. The maximum number of seconds is 1200. If you specify nocheck together with wait, when the time interval expires, Batchman processes the submit command even if one prerequisite job does not exist in the symphony. The job to be submitted and the prerequisite jobs that exist in the symphony are added to the symphony. If follows is used alone, jobs are selected or excluded if they have any follows dependencies. logon=username Select jobs based on the user names under which they run. If username contains special characters it must be enclosed in quotes (). Wildcard characters are permitted. needs[=[wkstation#]resourcename] Selects or excludes jobs based on whether or not they have a resource dependency.
124
wkstation Specifies the name of the workstation on which the resource is defined. Wildcard characters are permitted. resourcename Specifies the name of the resource. Wildcard characters are permitted. If needs is used alone, jobs are selected or excluded if they have any resource dependency. opens[=[wkstation#]filename[(qualifier)]] Select jobs based on whether or not they have a file dependency. A file dependency occurs when a job or job stream is dependent on the existence of one or more files before it can begin execution. wkstation Specifies the name of the workstation on which the file exists. Wildcard characters are permitted. filename Specifies the name of the file. The name must be enclosed in quotes () if it contains characters other than the following: alphanumerics, dashes (-), slashes (/), backslashes (\), and underscores (_). Wildcard characters are permitted. qualifier A valid test condition. If omitted, jobs are selected or excluded without regard to a qualifier. If opens is used alone, jobs are selected or excluded if they have any file dependency. A file dependency occurs when a job or job stream is dependent on the existence of one or more files before it can begin execution. priority=pri | lowpri, | ,highpri | lowpri,highpri Selects or excludes jobs based on their priorities. pri Specifies the priority value. You can enter 0 through 99, hi or go.
lowpri Specifies the lower limit of a priority range. Jobs are selected with priorities equal to or greater than this value. highpri Specifies the upper limit of a priority range. Jobs are selected with priorities less than or equal to this value. prompt[=promptname | msgnum] Selects or excludes jobs based on whether or not they have a prompt dependency. promptname Specifies the name of a global prompt. Wildcard characters are permitted. msgnum Specifies the message number of a local prompt. If prompt is used alone, jobs are selected or excluded if they have any prompt dependency. recovery=recv-option Selects or excludes jobs based on their recovery options.
125
recv-option Specifies the job recovery option as stop, continue, or rerun. scriptname=filename Selects or excludes jobs based on their executable file names. filename Specifies the name of an executable file. The name must be enclosed in quotes () if it contains characters other than the following: alphanumerics, dashes (-), slashes (/), backslashes (\), and underscores (_). Wildcard characters are permitted. started[=time | lowtime, | ,hightime | lowtime,hightime] Selects or excludes jobs based on whether or not they have started. time Specifies the exact time the jobs started, expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute. The next occurrence of hhmm on date, expressed as mm/dd/yy.
timezone|tz tzname The name of the time zone of the job. See Appendix B, Managing time zones, on page 319 for valid names. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Jobs are selected that started at or after this time. hightime Specifies the upper limit of a time range, expressed in the same format as time. Jobs are selected that started at or before this time. If started is used alone, the range is open-ended, and jobs are selected or excluded if they have started. state=state[,...] Selects or excludes jobs based on their states. state Specifies the current state of the job. Valid job states are as follows: abend The job terminated with a non-zero exit code. abenp An abend confirmation was received, but the job is not completed. add done error exec extrn The job is being submitted. The job completed in an unknown state. For internetwork dependencies only, an error occurred while checking for the remote status. The job is executing. For internetwork dependencies only, the status is unknown. An error occurred, a rerun action was just performed on the job in the external job stream, or the remote job or job stream does not exist. Unable to launch the job. The jobs priority is below the fence.
fail fence
126
The job is awaiting dependency resolution. The job is introduced for launching by the system. The job completed, and is awaiting confirmation. The job is ready to launch, and all dependencies are resolved.
sched The jobs at time has not arrived. succ succp wait The job completed with an exit code of zero. A succ confirmation was received, but the job is not completed. The job is in the wait state. (Extended agent only)
until[=time | lowtime, | ,hightime | lowtime,hightime [absolute | abs]] Selects or excludes jobs based on their 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. See Appendix B, Managing time zones, on page 319 for valid names. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Jobs 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. Jobs are selected that have scheduled end times on or before this time. absolute | abs Specifies the scheduled start time for the current day. This keyword can be used only with timezone|tz tzname and hhmm. It conforms to the following rules: v When hhmm is earlier than the current time, the start time is immediately. v When hhmm is later than the current time, the start time is the time specified by hhmm of the current day. v When hhmm exceeds 2400, it is divided by 2400 to obtain the calculated day and time. Of the division result, the whole part represents the calculated day (number of + days), while the decimal part represents the calculated time: If the calculated time is earlier than the current time, the start time is one day before the calculated day at the calculated time. If the calculated time is later than the current time, the start time is the calculated day and time.
Chapter 5. Conman reference
127
For example, if the current time is 1200 and a job is submitted at hhmm=3500 (2400 + 1100), with the abs keyword specified, the job is launched at 1100 of the following day. Instead, without specifying the abs keyword, the job is launched at 1100, two days later. If until is used alone, the range is open-ended, and jobs are selected or excluded if they have any scheduled end time.
Synopsis
[wkstation#] jobstream [+ | ~jobstreamqual[...]]
Arguments
wkstation Specifies the name of the workstation on which the job stream runs. Wildcard characters are permitted. jobstream Specifies the name of the job stream. Wildcard characters are permitted. jobstreamqual See Job Stream Qualifiers below.
+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 Appendix B, Managing time zones, on page 319 for valid names. absolute | abs Specifies the scheduled start time for the current day. This keyword can be used only with timezone|tz tzname and hhmm. It conforms to the following rules: v When hhmm is earlier than the current time, the start time is immediately. v When hhmm is later than the current time, the start time is the time specified by hhmm of the current day.
128
v When hhmm exceeds 2400, it is divided by 2400 to obtain the calculated day and time. Of the division result, the whole part represents the calculated day (number of + days), while the decimal part represents the calculated time: If the calculated time is earlier than the current time, the start time is one day before the calculated day at the calculated time. If the calculated time is later than the current time, the start time is the calculated day and time. For example, if the current time is 1200 and a job is submitted at hhmm=3500 (2400 + 1100), with the abs keyword specified, the job is launched at 1100 of the following day. Instead, without specifying the abs keyword, the job is launched at 1100, two days later. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Job streams are selected that have scheduled start 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 start times on or before this time. If at is used alone, the range is open-ended, and job streams are selected or excluded if they have any scheduled start time. carriedforward Selects or excludes job streams that were carried forward. carryforward Selects or excludes job streams that were scheduled using the carryforward keyword. finished[=time | lowtime, | ,hightime | lowtime,hightime] Selects or excludes job streams based on whether or not they have finished. time Specifies the exact time the job streams finished, expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute. 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 Appendix B, Managing time zones, on page 319 for valid names. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Job streams are selected that finished at or after this time.
129
hightime Specifies the upper limit of a time range, expressed in the same format as time. Job streams are selected that finished at or before this time. If finished is used alone, the range is open-ended, and job streams are selected or excluded if they have finished executing. follows[=[netagent::][wkstation#] jobstream[.job[;nocheck][;wait=time]] Selects or excludes job streams based on whether or not they have a follows dependency. netagent Specifies the name of the network agent that interfaces with the remote scheduler network containing the prerequisite job or job stream. Wildcard characters are permitted. For more information about network agents, refer to Chapter 9, The Network Agent reference, on page 289. wkstation Specifies the name of the workstation on which the prerequisite job or job stream runs. Wildcard characters are permitted. jobstream Specifies the name of the prerequisite job stream. Wildcard characters are permitted. job Specifies the name of the prerequisite job. Wildcard characters are permitted.
nocheck Is valid only for the sbd, sbj, and sbs commands. Conman does not check for the existence of prerequisite jobs in the symphony. When Batchman processes the submit command, it adds the arguments of the submit command to the symphony (such as the job to be submitted) including the dependencies on the prerequisite jobs that exist in the symphony. For those prerequisite jobs that do not exist in the symphony file, Batchman prints a warning in the stdlist. wait=time Is valid only for the sbd, sbj, and sbs commands. For the time interval specified, conman checks every second for the existence of the prerequisite jobs in the symphony file. Conman checks until the prerequisite jobs are found or the time interval specified for the wait keyword expires. When all prerequisite jobs are found, Batchman processes the submit command. If even one prerequisite job is not found in the symphony and the time interval expires, Conman does not process the submit command and returns an error message. The maximum number of seconds is 1200. If you specify nocheck together with wait, when the time interval expires, Batchman processes the submit command even if one prerequisite job does not exist in the symphony. The job to be submitted and the prerequisite jobs that exist in the symphony are added to the symphony. If follows is used alone, job streams are selected or excluded if they have any follows dependency.
130
limit[=limit | lowlimit, | ,highlimit | lowlimit,highlimit] Selects or excludes job streams based on whether or not they have a job limit. limit lowlimit Specifies the lower limit of range. Job streams are selected that have job limits equal to or greater than this limit. highlimit Specifies the upper limit of a range. Job streams are selected that have job limits less than or equal to this limit. If limit is used alone, the range is open-ended, and job streams are selected or excluded if they have any job limit. needs[=[wkstation#]resourcename] Selects or excludes job streams based on whether or not they have a resource dependency. wkstation Specifies the name of the workstation on which the resource is defined. Wildcard characters are permitted. resourcename Specifies the name of the resource. Wildcard characters are permitted. If needs is used alone, job streams are selected or excluded if they have any resource dependency. opens[=[wkstation#]filename[(qualifier)]] Selects or excludes job streams based on whether or not they have a file dependency. A file dependency occurs when a job or job stream is dependent on the existence of one or more files before it can begin execution. wkstation Specifies the name of the workstation on which the file exists. Wildcard characters are permitted. filename Specifies the name of the file. The name must be enclosed in quotes () if it contains characters other than the following: alphanumerics, dashes (-), slashes (/), backslashes (\), and underscores (_). Wildcard characters are permitted. qualifier A valid test condition. If omitted, job streams are selected or excluded without regard to a qualifier. If opens is used alone, job streams are selected or excluded if they have any file dependency. A file dependency occurs when a job or job stream is dependent on the existence of one or more files before it can begin execution. priority=pri | lowpri, | ,highpri | lowpri,highpri Selects or excludes job streams based on their priorities. pri Specifies the priority value. You can enter 0 through 99, hi or go. Specifies the exact job limit value.
131
lowpri Specifies the lower limit of a priority range. Job streams are selected with priorities equal to or greater than this value. highpri Specifies the upper limit of a priority range. Job streams are selected with priorities less than or equal to this value. prompt[=promptname | msgnum] Selects or excludes job streams based on whether or not they have a prompt dependency. promptname Specifies the name of a global prompt. Wildcard characters are permitted. msgnum Specifies the message number of a local prompt. If prompt is used alone, job streams are selected or excluded if they have any prompt dependency. started[=time | lowtime, | ,hightime | lowtime,hightime] Selects or excludes job streams based on whether or not they have started. time Specifies the exact time the job streams started, expressed as follows: hhmm [date] [timezone|tz tzname] hhmm date The hour and minute. 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 Appendix B, Managing time zones, on page 319 for valid names. lowtime Specifies the lower limit of a time range, expressed in the same format as time. Job streams are selected that started at 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 started at or before this time. If started is used alone, the range is open-ended, and job streams are selected or excluded if they have started executing. state=state[,...] Selects or excludes job streams based on their states. state Specifies the current state of the job stream. Valid job stream states are as follows: abend The job stream terminated abnormally. add exec hold The schedule has just been submitted. The job stream is executing. The job stream is awaiting dependency resolution.
132
The job stream is ready to launch, and all dependencies resolved. Execution is interrupted. No jobs are launched without operator intervention. The job stream completed successfully.
until[=time | lowtime, | ,hightime | lowtime,hightime [absolute | abs]] Selects or excludes job streams based on 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 Appendix B, Managing time zones, on page 319 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. absolute | abs Specifies the scheduled start time for the current day. This keyword can be used only with timezone|tz tzname and hhmm. It conforms to the following rules: v When hhmm is earlier than the current time, the start time is immediately. v When hhmm is later than the current time, the start time is the time specified by hhmm of the current day. v When hhmm exceeds 2400, it is divided by 2400 to obtain the calculated day and time. Of the division result, the whole part represents the calculated day (number of + days), while the decimal part represents the calculated time: If the calculated time is earlier than the current time, the start time is one day before the calculated day at the calculated time. If the calculated time is later than the current time, the start time is the calculated day and time. For example, if the current time is 1200 and a job is submitted at hhmm=3500 (2400 + 1100), with the abs keyword specified, the job is launched at 1100 of the following day. Instead, without specifying the abs keyword, the job is launched at 1100, two days later.
Chapter 5. Conman reference
133
If until is used alone, the range is open-ended, and job streams are selected or excluded if they any scheduled end time.
Command descriptions
The following pages contain detailed descriptions of Conman commands. Note: In the commands, the terms sched and schedule refer to job streams, and the term cpu refers to workstations.
134
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.
Synopsis
adj jobselect[;dependency[;...]][;noask]
Arguments
jobselect See Selecting jobs in commands on page 120. 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::][wkstation#]jstream{.job | @} | job[,...] needs=[num] [wkstation#]resource[,...] opens=[wkstation#]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.
Usage Notes
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. To add prompt dependencies while running Conman on a fault tolerant agent, you must have access to the TWShome/mozart directory on the master domain manager. | | | | | | | | | | You cannot use this command to add a resource or a prompt as dependencies unless they are already referenced by a job or a schedule in the Symphony file.
Examples
To add a resource dependency to job job3 in job stream sked9, run the following command:
adddep sked9.job3;needs=2 tapes
To add a file dependency, and an until time to job job6 in job stream sked2, run the following command:
adj sked2.job6;opens="/usr/lib/prdata/file5"(-s %p); until=2330
135
| | | |
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 Users Guide.
136
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.
Synopsis
ads jstreamselect[;dependency[;...]][;noask]
Arguments
jstreamselect See Selecting job streams in commands on page 128. 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::][wkstation#]jstream{.job | @} | job[,...] limit=limit needs=[num] [wkstation#]resource[,...] opens=[wkstation#]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.
Usage Notes
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 To add prompt dependencies while running Conman on a fault tolerant agent, you must have access to the TWShome/mozart directory on the master domain manager. v You cannot use this command to add a resource or a prompt as dependencies unless they are already referenced by a job or a schedule in the Symphony file.
| | | | | | | |
Examples
To add a prompt dependency to job stream sked3, run the following command:
adddep sched=sked3;prompt=msg103
To add a follows dependency and a job limit to job stream sked4, run the following command:
ads sked4;follows=sked3;limit=2
137
| | | |
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 Users Guide.
138
altpass
Alters the password of a user object in the current production plan. You must have altpass access to the user object.
Synopsis
altpass [wkstation#]username[;password]
Arguments
wkstation username password Specifies the workstation on which the user is defined. The default is the workstation on which you are running Conman. Specifies the name of a user. Specifies the new password. It must be enclosed in quotes. To indicate no password for the user, use two consecutive quotes ().
Usage Notes
If you do not specify a password, Conman prompts for a password and a confirmation. In this case, 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 User definitions on page 47. | | | | | | | | | | | |
Examples
To change the password of user jim on workstation mis5 to giraffe, run the following command:
altpass mis5#jim;giraffe
To change the password of user jim on workstation mis5 to giraffe without displaying the password, run the following command:
altpass mis5#jim password: xxxxxxxx confirm: xxxxxxxx
See Also
For the equivalent Job Scheduling Console task, see Changing Windows User Passwords in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
139
altpri
Alters the priority of a job or job stream. You must have altpri access to the job or job stream.
Synopsis
ap jobselect | jstreamselect[;pri][;noask]
Arguments
jobselect jstreamselect pri noask | | | | | | | | | | | See Selecting jobs in commands on page 120. See Selecting job streams in commands on page 128. 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, run the following command:
altpri glmonth.balance;55
To change the priority of all jobs in job stream mis5, run the following command:
ap mis5.@;25
To change the priority of job stream glmonth, run the following command:
altpri glmonth;10
To change the priority of job stream mis5, run the following command:
ap mis5;30
140
cancel job
Cancels a job. You must have cancel access to the job.
Synopsis
cj jobselect[;pend][;noask]
Arguments
jobselect pend noask See Selecting jobs in commands on page 120. Cancels the job only after its dependencies are resolved. Specifies not to prompt for confirmation before taking action on each qualifying job.
Usage Notes
If a job is cancelled before it is launched, it will not launch. If you cancel a job after it is launched, the job continues to run. If an executing job is cancelled 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 in the external job stream represent jobs and job streams that have been specified as internetwork dependencies. The status of an internetwork
Chapter 5. Conman reference
141
dependency is not checked after a cancel is performed. For more information see Internetwork dependencies on page 292. | | | | | | | | | | | | |
Examples
To cancel job report in job stream apwkly on workstation site3, run the following command:
cancel site3#apwkly.report
To cancel job setup in job stream mis5, if it is not in the abend state, run the following command:
cj mis5.setup~state=abend
To cancel job job3 in job stream sked3 only after its dependencies are resolved, run the following command:
cj sked3.job3;pend
See Also
For the equivalent Job Scheduling Console task, see Deleting a Job from a Job Stream in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
142
cancel sched
Cancels a job stream. You must have cancel access to the job stream.
Synopsis
cs jstreamselect[;pend][;noask]
Arguments
jstreamselect pend noask See Selecting job streams in commands on page 128. Cancels the job stream only after its dependencies are resolved. Specifies not to prompt for confirmation before taking action on each qualifying job stream.
Usage Notes
If a job stream is cancelled before it is launched, it will not launch. If cancelled after it is launched, jobs that have started are allowed to complete, but no other jobs are launched. If you do not use the ;pend option, jobs and job streams that are dependent on the cancelled job stream are released immediately from the dependency. If you use the ;pend option and the job stream has not been launched, cancellation is deferred until all of its dependencies, including an at time, are resolved. Once all dependencies are resolved, the job stream is cancelled and any dependent jobs or job streams are released from the dependency. During the period the cancel is deferred, the notation [Cancel Pend] is listed in the Dependencies column of a showschedules display. If you include the ;pend option and the job stream has already been launched, any remaining jobs in the job stream are cancelled, and any dependent jobs and job streams are released from the dependency. To immediately cancel a job stream marked [Cancel Pend], either enter a release command for the job stream or enter another cancel command without the ;pend option. For job streams with expired until times, the notation [Until] appears in the Dependencies column of the showschedules display and their dependencies are no longer evaluated. If such a job stream 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 of dependencies, set the job streams priority to zero with the altpri command. To resume dependency evaluation, set the priority to a value greater than zero. | | | | |
Examples
To cancel job stream sked1 on workstation site2, run the following command:
cancel site2#sked1
To cancel job stream mis2 if it is in the stuck state, run the following command:
cs mis2+state=stuck
143
| | | | | |
To cancel job stream sked3 only after its dependencies are resolved, run the following command:
cs sked3;pend
See Also
For the equivalent Job Scheduling Console task, see Deleting Job Streams in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
144
confirm
Confirms the completion of a job that was scheduled with the confirmed keyword. An exception is noted in the Usage Notes section. You must have confirm access to the job.
Synopsis
confirm jobselect;{succ | abend}[;noask]
Arguments
jobselect succ abend noask See Selecting jobs in commands on page 120. Confirms that the job ended successfully. Confirms that the job ended unsuccessfully. Specifies not to prompt for confirmation before taking action on each qualifying job.
Usage Notes
Changing the state of a job from abend to succ does not require that the confirmed keyword be used to schedule the job. For more information about job confirmation, see confirmed on page 87. For more information about external jobs, see Internetwork dependencies on page 292. The following table shows the affect of the confirm command on the various states of jobs:
Initial Job State ready hold exec abenp succp pend done succ abend fail skel any external job State after confirm ;succ no affect no affect succp succp no affect succ succ no affect succ no affect no affect succ State after confirm ;abend no affect no affect abenp no affect no affect abend abend no affect no affect no affect no affect abend
| | | | | | |
Examples
To issue a succ confirmation for job job3 in job stream misdly, run the following command:
confirm misdly.job3;succ
To issue an abend confirmation to job number 234, run the following command:
conf 234;abend
145
console
Assigns the scheduler console and sets the message level. You must have console access to the workstation.
Synopsis
console [sess | sys][;level=msglevel]
Arguments
sess sys msglevel Sends scheduler console messages and prompts to standard output. Stops sending scheduler console messages and prompts to standard output. This occurs automatically when you exit Conman. The level of scheduler messages that are sent to the console. Specify one of the following levels: 0 1 2 3 4 No messages. This is the default on fault-tolerant agents. Exception messages such as operator prompts, and job abends. Level 1, plus job stream successful messages. Level 2, plus job successful messages. This is the default on the master domain manager. Level 3, plus job launched messages.
Usage Notes
If you enter the console command with no options, the current state of the console is displayed. By default, scheduler control processes write console messages and prompts to standard list files. On UNIX, you can also have them sent to the syslog daemon. | | | | | | | | | | |
Examples
To begin writing console messages and prompts to standard output and change the message level to 1, run the following command:
console sess;level=1
To stop writing console messages and prompts to standard output and change the message level to 4, run the following command:
cons sys;l=4
To display the current state of the console, run the following command:
cons Console is #J675, level 2, session
146
continue
Ignores the next command error.
Synopsis
continue
Usage Notes
This command is useful when commands are entered non-interactively. It instructs Conman to continue executing commands even if the next command, following continue, results in an error. | | | |
Examples
To make Conman continue with the rerun command even if the cancel command fails, run the following command:
conman "continue&cancel=176&rerun job=sked5.job3"
147
deldep job
Deletes dependencies from a job. You must have deldep access to the job.
Synopsis
ddj jobselect;dependency[;...][;noask]
Arguments
jobselect See Selecting jobs in commands on page 120. dependency The type of dependency. Specify at lease one of the following. You can use wildcard characters in wkstation, jstream, job, resource, filename, and promptname. at[=time | lowtime | hightime | lowtime,hightime] confirmed deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]] every follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]] needs[=[num] [wkstation#]resource[,...]] opens[=[wkstation#]filename[(qualifier)][,...]] priority prompt[=[: | !]text | promptname[,...]] until[=time [timezone|tz tzname][+n day[s]] [onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job.
Usage Notes
If priority is deleted, the job reverts to its original scheduled priority. When you delete an opens dependency, you can include only the base file name and Conman performs a case-insensitive search for matching files, ignoring the directory names. Dependencies on all matching files are deleted. In certain circumstances, when you have submitted a deldep command, the command might have succeeded even though it is again forwarded to Batchman. For more information, see Conman command processing on page 134. | | | | | | |
Examples
To delete a resource dependency from job job3 in job stream sked5, run the following command:
deldep sked5.job3;needs=2 tapes
To delete all follows dependencies from job job4 in job stream sked3, run the following command:
ddj sked3.job4;follows
148
| | |
See Also
For the equivalent Job Scheduling Console task, see Managing Jobs in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
149
deldep sched
Deletes dependencies from a job stream. You must have deldep access to the job stream.
Synopsis
dds jstreamselect;dependency[;...][;noask]
Arguments
jstreamselect See Selecting jobs in commands on page 120. dependency The type of dependency. Specify at least one of the following. You can use wildcard characters in wkstation, jstream, job, resource, filename, and promptname. at[=time | lowtime | hightime | lowtime,hightime] carryforward deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]] follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]] limit needs[=[num] [wkstation#]resource[,...]] opens[=[wkstation#]filename[(qualifier)][,...]] priority prompt[=[: | !]text | promptname[,...]] until[=time [timezone|tz tzname][+n day[s]] [onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job stream.
Usage Notes
If priority is deleted, the job reverts to its original scheduled priority. When you delete an opens dependency, you can include only the base file name, and Conman performs a case-insensitive search for matching files, ignoring the directory names. Dependencies on all matching files are deleted. In certain circumstances, when you have submitted a deldep command, the command might have succeeded even though it is again forwarded to Batchman. For more information, see Conman command processing on page 134. | | | | | | |
Examples
To delete a resource dependency from job stream sked5, run the following command:
deldep sked5;needs=2 tapes
To delete all follows dependencies from job stream sked3, run the following command:
dds sked3;follows
150
| | |
See Also
For the equivalent Job Scheduling Console task, see Managing Job Streams in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
151
display
Displays a job file or a job stream definition. If you specify a file by name, you must have read access to the file. For job files and job stream definitions, you must have display access to the job or job stream.
Synopsis
df filename[;offline] dj jobselect[;offline] ds jstreamselect[;offline]
Arguments
filename Specifies the name of the file, usually a job script file. The name must be enclosed in quotes () if it contains characters other than the following: alphanumeric characters, dashes (-), slashes (/), backslashes (\), and underscores (_). Wildcard characters are permitted. The file must be accessible from your login workstation. The job whose job file is displayed. See Selecting jobs in commands on page 120. The job file must be accessible from your login workstation. The job stream whose definition is displayed. See Selecting job streams in commands on page 128. The scheduler mozart directory on the master domain manager must be accessible from your login workstation. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
jobselect
jstreamselect
offline
| | | | | | | | | | | | |
Examples
To display the file c:\maestro\jclfiles\arjob3, run the following command:
df c:\apps\maestro\jclfiles\arjob3
To display the script file for job job6 in job stream sked3 offline, run the following command:
dj sked3.job6;off
To display the job stream definition for job stream sked9, run the following command:
ds sked9
See Also
For the equivalent Job Scheduling Console task, see Managing Jobs and Managing Job Streams in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
152
exit
Exits the Conman command line program.
Synopsis
e
Usage Notes
When you are in help mode on UNIX, this command returns Conman to command-input mode. | | | | |
Examples
To exit the Conman command line program, run the following command:
exit
or
e
153
fence
Changes the job fence on a workstation. Jobs are not launched on the workstation if their priorities are less than or equal to the job fence. You must have fence access to the workstation.
Synopsis
fence workstation;pri[;noask]
Arguments
workstation pri noask Specifies the workstation name. The default is your login workstation. Specifies the priority level. You can enter 0 through 99, hi, or go. Entering system sets the job fence to zero. Specifies not to prompt for confirmation before taking action on each qualifying workstation.
Usage Notes
The job fence prevents low priority jobs from being launched, regardless of the priorities of their job streams. It is possible, therefore, to hold back low priority jobs in high priority job streams, while allowing high priority jobs in low priority job streams to be launched. When you first start IBM Tivoli Workload Scheduler following installation, the job fence is set to zero. Once you change the job fence, it is carried forward during pre-production processing to the next days production plan. To display the current setting of the job fence, use the status command. | | | | | | | | | | | | | | | |
Examples
To change the job fence on workstation site4, run the following command:
fence site4;20
To change the job fence on the workstation on which you are running Conman, run the following command:
f ;40
To prevent all jobs from being launched by the scheduler on workstation tx3, run the following command:
f tx3;go
To change the job fence to zero on the workstation on which you are running Conman, run the following command:
f ;system
See Also
For the equivalent Job Scheduling Console task, see Viewing and Modifying Workstation Properties in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
154
help
Displays help information about commands. Not available on Windows.
Synopsis
help command
Arguments
command Specifies the name of a Conman or system command. For Conman commands, enter the full command name, abbreviations and short forms are not supported. In the case of commands consisting of two words, enter the first word, and help for all versions of the command is displayed. For example, entering help display will display information about the display file, display job, and display sched commands. You can also enter the following keywords: commands Lists all Conman commands. jobselect Lists information about selecting jobs for commands. jobstates Lists information about job states. schedselect Lists information about selecting job streams for commands. schedstates Lists information about job stream states. | | | | | | | | |
Examples
To display a list of all Conman commands, run the following command:
help commands
To display information about the fence command, run the following command:
help fence
To display information about the altpri job and altpri sched commands, run the following command:
h altpri
155
kill
Stops an executing job. On UNIX, this is accomplished with a UNIX kill command.
Synopsis
kill jobselect[;noask]
Arguments
jobselect noask See Selecting jobs in commands on page 120. Specifies not to prompt for confirmation before taking action on each qualifying job.
Usage Notes
The kill operation is not performed by Conman, it is run by a scheduler production process, so there might be a short delay. Killed jobs terminate in the abend state. Any jobs or job streams that are dependent on a killed job are not released. Killed jobs can be rerun. | | | | | | |
Examples
To kill the job report in job stream apwkly on workstation site3, run the following command:
kill site3#apwkly.report
156
limit cpu
Changes the limit of jobs launched on a standard agent workstation. You must have limit access to the workstation.
Synopsis
lc wkstation;limit[;noask]
Arguments
wkstation limit Specifies the name of the standard agent workstation. Wildcard characters are permitted. The default is your login workstation. Specifies the job limit. You can enter 0 through 1024. Entering system sets the job limit to zero. If a limit of zero is set, no jobs, other than hi and go priority jobs, are launched on the workstation. Specifies not to prompt for confirmation before taking action on each qualifying workstation.
noask
Usage Notes
To display the current job limit on your login workstation, use the status command. When you first start IBM Tivoli Workload Scheduler following installation, the workstation job limit is set to zero, and must be raised before any jobs are launched. Once you change the limit, it is carried forward during pre-production processing to the next days production plan. The scheduler attempts to launch as many jobs as possible within the job limit. There is a practical limit to the number of processes that can be started on a workstation. If the limit is reached, the system responds with a message indicating that system resources are not available. When a job cannot be launched for this reason, it enters the fail state. Lowering the job limit can prevent this from occurring. | | | | | | | | | | | |
Examples
To change the job limit on workstation site3, run the following command:
limit cpu=site3;25
To change the job limit on the workstation on which you are running Conman, run the following command:
lc ;12
To change the job limit on workstation rx12, run the following command:
lc rx12;6
See Also
For the equivalent Job Scheduling Console task, see Viewing and Modifying Workstation Properties in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
157
limit sched
Changes the job limit for a job stream. You must have limit access to the job stream.
Synopsis
ls jstreamselect;limit[;noask]
Arguments
jstreamselect limit noask | | | | | | | | | See Selecting job streams in commands on page 128. Specifies the job limit. You can enter 0 through 1024. If you specify a limit of zero, no further jobs are launched from the job stream. Specifies not to prompt for confirmation before taking action on each qualifying job stream.
Examples
To change the job limit on all job streams that include sales in their name, run the following command:
limit sched=sales@;4
To change the job limit on job stream apwkly, run the following command:
ls apwkly;6
See Also
For the equivalent Job Scheduling Console task, see Managing Job Streams in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
158
link
Opens communication links between workstations. In a scheduler network, fault-tolerant and standard agents are linked to their domain managers, and domain managers are linked to their parent domain managers. Extended agents are not linked; they communicate through a host. You must have link access to the target workstation.
Synopsis
lk [domain!]wkstation[;noask]
Arguments
domain Specifies the name of the domain in which links are opened. Wildcard characters are permitted. This argument is useful when linking more than one workstation in a domain. For example, to link all the agents in domain stlouis, use the following command:
link stlouis!@
The domain is not needed if you do not include wildcard characters in wkstation. If you do not include domain, and you include wildcard characters in wkstation, the default domain is the one in which Conman is running. wkstation noask Specifies the name of the workstation to be linked. Wildcard characters are permitted. Specifies not to prompt for confirmation before taking action on each qualifying workstation.
Usage Notes
If the autolink option is set to on in a workstation definition, its link is opened automatically each time the scheduler is started. If autolink is set to off, you must use link and unlink commands to control linking. For information about autolink see Workstation definitions on page 33. Assuming that a user has link access to the workstations being linked, the following rules apply: v A user running Conman on the master domain manager can link any workstation in the network. v A user running Conman on a domain manager other than the master can link any workstation in its own domain and subordinate domains. The user cannot link workstations in peer domains. 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. A peer agent in the local domain cannot be linked. v To link a subordinate domain while running Conman in a higher domain, it is not necessary that the intervening links be open.
Examples
The illustration and table below show the links opened by link commands run by users in various locations in the network.
159
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
160
listsym
Lists the production plan (Symphony) log files. You must have display access to the Symphony file.
Synopsis
listsym [;offline]
Arguments
offline Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
Command Output
Schedule Date The date used by the schedulr command to select job streams for execution. Actual Date The date batchman began executing the Symphony file. Start Time The time batchman began executing the Symphony file. Log Date The date the plan (Symphony) was logged by the stageman command. Run Num The run number assigned to the plan (Symphony). These are used internally for scheduler network synchronization. Size The size of the log file in records.
Log Num The log number indicating the chronological order of log files. This number can be used in a setsym command to switch to a specific log file. Filename The name of the log file assigned by the stageman command. | | | | | |
Examples
To list the production plan log files, run the following command:
listsym
To list the production plan log files to Conmans output device, run the following command:
lis ;off
161
recall
Displays prompts that are waiting for a response. You must have display access to the prompts.
Synopsis
rc [wkstation][;offline]
Arguments
wkstation Specifies the name of the workstation on which the prompt was issued. If you do not specify a workstation, only prompts for the login workstation and global prompts are displayed. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
offline
Command Output
State The state of the prompt. The state of pending prompts is always ASKED. Message or Prompt For named prompts, the message number, the name of the prompt, and the message text. For unnamed prompts, the message number, the name of the job or job stream, and the message text. | | | | | | | | | | | |
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 all workstations and have the output sent to Conmans offline device, run the following command:
rc @;offline
162
redo
Edits and reruns the previous command.
Synopsis
redo
Context
When you run the redo command, Conman displays the previous command, so that it can be edited and rerun. Use the spacebar to move the cursor under the character to be modified, and enter the following directives. Directives d[dir] itext rtext Deletes the character above the d. This can be followed by other directives. Inserts text before the character above the i. Replaces one or more characters with text, beginning with the character above the r. Replace is implied if no other directive is entered. Appends text to the end of the line.
>text
>d[dir | text] Deletes characters at the end of the line. This can be followed by another directive or text. >rtext Replaces characters at the end of the line with text.
Directive Examples ddd iabc rabc abc d diabc Deletes the character above the first d, skips one character, deletes the character above the second d, and inserts abc in its place. >abc >ddabc Deletes the last two characters in the line, and inserts abc in their place. >rabc | | | | | | | Replaces the last three characters in the line with abc. Appends abc to the end of the line. Deletes the three characters above the ds. Inserts abc before the character above the i. Replaces the three characters, starting with the one above the r, with abc. Replaces the three characters above abc with abc.
Examples
To insert a character, run the following command:
redo setsm 4 iy setsym 4
163
| | | | |
164
release job
Releases jobs from dependencies. You must have release access to the job.
Synopsis
rj jobselect[;dependency[;...]][;noask]
Arguments
jobselect Specifies the job or jobs to be released. See Selecting jobs in commands on page 120. dependency The type of dependency. You can specify one of the following. You can use wildcard characters in wkstation, jstream, job, resource, filename, and promptname. at[=time | lowtime | hightime | lowtime,hightime] confirmed deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]] every follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]] needs[=[num] [wkstation#]resource[,...]] opens[=[wkstation#]filename[(qualifier)][,...]] priority prompt[=[: | !]text | promptname[,...]] until[=time [timezone|tz tzname][+n day[s]] [onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job.
Usage Notes
When you release an opens dependency, you can include only the base file name, and Conman performs a case-insensitive search for matching files, ignoring the directory names. Dependencies on all matching files are released. For needs dependencies, the released job is given the required number of units of the resource, even though they might not be available. This can cause the Available units in a showresources to display a negative number. When you release a job from a priority dependency, the job reverts to its original scheduled priority. | | | | | | |
Examples
To release job job3 in job stream ap from all of its dependencies, run the following command:
release job=ap.job3
To release job job2 in job stream skedr from all of its opens dependencies, run the following command:
rj skedr.job2;opens
Chapter 5. Conman reference
165
| | | | | | |
To release all jobs on workstation site4 from their dependencies on a prompt named glprmt, run the following command:
rj site4#@.@;prompt=glprmt
See Also
For the equivalent Job Scheduling Console task, see Releasing a Job Instance from Dependencies in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
166
release sched
Releases job streams from dependencies. You must have release access to the job stream.
Synopsis
rs jstreamselect[;dependency[;...]][;noask]
Arguments
jstreamselect See Selecting job streams in commands on page 128. dependency The type of dependency. Specify one of the following. You can use wildcard characters in wkstation, jstream, job, resource, filename, and promptname. at[=time | lowtime | hightime | lowtime,hightime] carryforward deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]] follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]] limit needs[=[num] [wkstation#]resource[,...]] opens[=[wkstation#]filename[(qualifier)][,...]] priority prompt[=[: | !]text | promptname[,...]] until[=time [timezone|tz tzname][+n day[s]] [onuntil action]] noask Specifies not to prompt for confirmation before taking action on each qualifying job stream.
Usage Notes
When deleting an opens dependency, you can include only the filename (basename), and Conman performs a case-insensitive search for matching files, ignoring the directory names. Dependencies on all matching files are released. For needs dependencies, the released job stream is given the required number of units of the resource, even though they might not be available. This can cause the Available units in a showresources to display a negative number. When you release a schedule from a priority dependency, the job stream reverts to its original priority. In certain circumstances, when you have submitted a deldep command, the command might have succeeded even though it is again forwarded to batchman. For more information, see Conman command processing on page 134. | | |
Examples
To release job stream ap from all of its dependencies, run the following command:
release sched=ap
167
| | | | | | | | | |
To release job stream sked5 from all of its opens dependencies, run the following command:
rs sked5;opens
To release all job streams on workstation site3 from their dependencies on job stream main#sked23, run the following command:
rs site3#@;follows=main#sked23
See Also
For the equivalent Job Scheduling Console task, see Releasing a Job Stream Instance from Dependencies in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
168
reply
Replies to a job or job stream prompt. You must have reply access to the named or global prompt. To reply to an unnamed prompt, you must have reply access to prompts, and reply access to the associated job or job stream.
Synopsis
reply { promptname | [wkstation#]msgnum};reply[;noask]
Arguments
promptname wkstation msgnum Specifies the name of a global prompt. Wildcard characters are permitted. Specifies the name of the workstation on which an unnamed prompt was issued. Specifies the message number of an unnamed prompt. You can display message numbers with the recall and showprompts commands. Specifies the reply, either Y for yes or N for no. Specifies not to prompt for confirmation before taking action on each qualifying prompt.
reply noask
Usage Notes
If the reply is Y, dependencies on the prompt are satisfied. If the reply is N, the dependencies are not satisfied and the prompt is not re-issued. Prompts can be replied to before they are issued. You can use the showprompts command to display all prompts, whether they have been issued or not. | | | | | | |
Examples
To reply Y to the global prompt arprmt, run the following command:
reply arprmt;y
169
rerun
Reruns a job. You must have rerun access to the job.
Synopsis
rr jobselect[;from=[wkstat#]job[;at=time][;pri=pri]][;noask] rr jobselect[;step=step][;noask]
Arguments
jobselect Specifies the name of one or more jobs. Wildcard characters are permitted. from=[wkstat#]job Specifies the name of a job defined in the scheduler database whose job file or command will be run in place of the job specified by jobselect. wkstat# Specifies the name of the workstation on which the from job runs. The default is the workstation on which Conman is running. 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. v The alias names of jobs submitted using the submit job command.
To use the from argument, you must have access to the scheduler database from the computer on which you are running Conman at=time Specifies the rerun jobs start time, expressed as follows: hhmm [timezone|tz tzname] [+n days | date] where: 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. See Appendix B, Managing time zones, on page 319 for valid names. pri=pri Specifies the priority to be assigned to the rerun job. If you do not specify a priority, the job is given the same priority as the original job. step=step Specifies that the job is rerun using this name in place of the original job name. See Usage Notes for more information. noask Specifies not to prompt for confirmation before taking action on each qualifying job.
170
Usage Notes
You can rerun jobs that are in the succ, fail or abend state. A rerun job is placed in the same job stream as the original job, and inherits the original jobs dependencies. If you rerun a repetitive (every) job, the rerun job is scheduled to run at the same rate as the original job. Note: You can issue rerun for jobs in the external job stream that are in the error state. Jobs in the external job stream represent jobs and job streams that have been specified as internetwork dependencies. The job state is initially set to extrn immediately after a rerun is run, and Conman begins checking the state. When ;from is used, the name of the rerun job depends on the value of the Global Option retain rerun job names. If the option is set to Y, rerun jobs retain the original job names. If the option is set to N, rerun jobs are given the from job names. For more information, refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide. In Conman displays, rerun jobs are displayed with the notation >>rerun as. To refer to a rerun job in another command, such as altpri, you must use the original job name. When a job is rerun with the ;step option, the job runs with step in place of its original name. Within a job script, you can use the jobinfo command to return the job name and to run the script differently for each iteration. For example, in the following UNIX script, the jobinfo command is used to set a variable named STEP to the name that was used to run the job. The STEP variable is then used to determine how the script is run.
... MPATH=`maestro` STEP=`$MPATH/bin/jobinfo job_name` if [$STEP = JOB3] then ... STEP=JSTEP1 fi if [$STEP = JSTEP1] then ... STEP=JSTEP2 fi if [$STEP = JSTEP2] then ... fi ...
In Conman displays, jobs rerun with the ;step option are displayed with the notation >>rerun step. For information about jobinfo, see jobinfo on page 237. | | | |
Examples
To rerun job job4 in job stream sked1 on workstation main, run the following command:
rerun main#sked1.job4
171
| | | | | | | | | |
To rerun job job5 in job stream sked2 using the job definition for job jobx where the jobs at time is set to 6:30 p.m. and its priority is set to 25, run the following command:
rr sked2.job5;from=jobx;at=1830;pri=25
To rerun job job3 in job stream sked4 using the job name jstep2, run the following command:
rr sked4.job3;step=jstep2
See Also
For the equivalent Job Scheduling Console task, see Rerunning a Job Instance in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
172
resource
Changes the number of total units of a resource. You must have resource access to the resource.
Synopsis
resource [wkstation#]resource;num[;noask]
Arguments
wkstation Specifies the name of the workstation on which the resource is defined. The default is the workstation on which Conman is running. Specifies the name of the resource. Specifies the total number of resource units. Valid values are 0 through 1024. Specifies not to prompt for confirmation before taking action on each qualifying resource.
Examples
To change the number of units of resource tapes to 5, run the following command:
resource tapes;5
To change the number of units of resource jobslots on workstation site2 to 23, run the following command:
res site2#jobslots;23
See Also
For the equivalent Job Scheduling Console task, see Managing Resources in the Database in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
173
setsym
Selects a production plan archive file. Subsequent display commands display the contents of the archived production plan. You cannot modify the information in a production plan archive file.
Synopsis
setsym [filenum]
Arguments
filenum Specifies the number of the production plan archive file. If you do not specify a log file number, the pointer returns to zero, the current production plan (Symphony). Use the listsym command to list archive file numbers.
| | | | | |
Examples
To select production plan archive file 5, run the following command:
setsym 5
To select the current production plan (Symphony), run the following command:
set
174
showcpus
Displays information about workstations and links.
Synopsis
sc [[domain!]wkstation][;info|;link][;offline]
Arguments
domain wkstation Specifies the name of a domain. The default is the domain in which the command is run. Specifies the name of a workstation. The default is the workstation where the command is run. When no domain and no workstation are specified, the output an be the following: v The following command displays all the workstations that are in the domain of the workstation where the command was run, plus all the connected domain managers if the workstation is a domain manager.
conman "sc"
v The following command displays all the workstations that are in the domain of the workstation where the command was run, without the connected domain managers.
conman "sc @"
Displays information in the info format. Displays information in the link format. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
Command Output
The output of the command is produced in three formats, standard, info, and link. Standard format: CPUID The name of the workstation to which this information applies. RUN NODE The node type and workstation type. Node types are as follows: v UNIX v WINT v OTHER Workstation types are as follows: v MASTER v MANAGER v FTA v S-AGENT v X-AGENT LIMIT The scheduler job limit. FENCE The scheduler job fence.
Chapter 5. Conman reference
175
DATE TIME The date and time the scheduler started executing the current production plan (Symphony). STATE The state of the workstations links. Up to five characters are displayed as follows:
[L] [T|H|X] [I] [J] [W|H|X]
| |
L T H X I J W F
The primary link is open (linked) to its domain/upper manager. The link is TCP/IP. The workstation is linked through its host. The workstation is linked as an extended agent (x-agent). The jobman program has completed startup initialization. The jobman program is running. The workstation is linked by TCP/IP. The workstation is fully linked through primary and all secondary connections.
Note: If the workstation running Conman is the extended agents host, the state of the x-agent is
LXI JX
If the workstation running Conman is not the extended agents host, the state of the x-agent is
LHI JH
METHOD The name of the access method specified in the workstation definition. For extended agents only. DOMAIN The name of the domain in which the workstation is a member. info format: CPUID The name of the workstation to which this information applies. VERSION The version of the IBM Tivoli Workload Scheduler jobman program. TIMEZONE The time zone of the workstation. It is the same as the value of the TZ environment variable. For an extended agent, this is the time zone of its host. INFO The Operating System version and hardware model. For extended agents, no information is listed. link format: CPUID The name of the workstation to which this information applies. HOST The name of the workstation acting as the host to a standard agent or extended agent. For domain managers and fault-tolerant agents, this is the same as CPUID. For standard agent workstations, this is the name of the domain manager. For extended agents, this is the name of the host workstation.
176
FLAGS The state of the workstations links. Up to five characters are displayed as follows:
[A] [F] [s] [T]
A F s T ADDR
Autolink is turned on in the workstation definition. Full Status mode is turned on in the workstation definition. The ID of mailman server for the workstation. The link is defined as TCP/IP.
The TCP port number for the workstation. NODE The node name of the workstation.
Examples
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. To display information about the workstation on which you are running Conman in the info format, run the following command:
showcpus ;info
2. To display link information offline for all workstations, run the following command:
sc @!@;link;off
If you run this command in an environment when the primary connection of the workstation with its domain or upper manager is not active, you receive the following output:
MASTER FTA1 FTA2 FTA3 FTA4 FTA5 SA1 XA_FTA4 FTA6 FTA7 360 *WNT MASTER 360 WNT FTA 360 WNT FTA 360 WNT MANAGER 360 WNT FTA 360 WNT FTA 360 WNT S-AGENT 360 OTHR X-AGENT 360 WNT MANAGER 360 WNT FTA 10 10 10 10 10 10 10 10 10 10 0 0 0 0 0 0 0 0 0 0 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 13:48 13:48 13:48 13:48 13:48 13:48 13:48 13:48 13:48 13:49 I FTI FTI LTI F I I F I L I F I F I J JW JW JW J J J J J J MASTERDM MASTERDM MASTERDM DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN2 DOMAIN2
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, you receive the following output:
MASTER FTA1 FTA2 FTA3 FTA4 FTA5 SA1 XA_FTA4 FTA6 FTA7 360 *WNT MASTER 360 WNT FTA 360 WNT FTA 360 WNT MANAGER 360 WNT FTA 360 WNT FTA 360 WNT S-AGENT 360 OTHR X-AGENT 360 WNT MANAGER 360 WNT FTA 10 10 10 10 10 10 10 10 10 10 0 0 0 0 0 0 0 0 0 0 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 13:48 13:48 13:48 13:48 13:48 13:48 13:48 13:48 13:48 13:49 I FTI FTI FTI F I L I F I L I F I F I J JW JW JW J J J J J MASTERDM MASTERDM MASTERDM DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN1 DOMAIN2 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, you receive the following output:
MASTER FTA1 FTA2 FTA3 FTA4 FTA5 360 *WNT MASTER 360 WNT FTA 360 WNT FTA 360 WNT MANAGER 360 WNT FTA 360 WNT FTA 10 10 10 10 10 10 0 0 0 0 0 0 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 12/04/03 13:48 13:48 13:48 13:48 13:48 13:48 I FTI FTI FTI F I F I J JW JW JW J MASTERDM MASTERDM MASTERDM DOMAIN1 DOMAIN1 DOMAIN1
177
| | | | | | |
10 10 10 10
0 0 0 0
F L F F
I I I I
J J J J
See Also
For the equivalent Job Scheduling Console task, see Working with Object Lists in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
178
showdomain
Displays domain information.
Synopsis
showdomain [domain][;info][;offline]
Arguments
domain info offline Specifies the name of the domain. The default is the domain in which Conman is running. Wildcard characters are permitted. Displays information in the info format. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
Command Output
The output of the command is produced in two formats, standard, and info. Standard format: DOMAIN The name of the domain to which this information applies. MANAGER The name of the domain manager. PARENT The name of the parent domain. info format: DOMAIN The name of the domain to which this information applies. MEMBER-CPUS The names of the workstations in the domain. CPU-TYPE The type of each workstation: MASTER, MANAGER, FTA, S-AGENT, or X-AGENT. | | | | | | | | | |
Examples
To display information about the domain masterdm, run the following command:
showdomain masterdm
To display the member workstations in all domains in the info format, run the following command:
showdomain @;info
See Also
For the equivalent Job Scheduling Console task, see Displaying and Modifying Domain Properties in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
179
showfiles
Displays information about file dependencies. 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.
Synopsis
sf [[wkstation#]file][;state[;...]][;keys][;offline] sf [[wkstation#]file][;state[;...]][;deps[;keys | info | logon]][;offline]
Arguments
wkstation Specifies the name of the workstation on which the file exists. The default is the workstation on which Conman is running. Wildcard characters are permitted. Specifies the name of the file. The name must be enclosed in quotes () if it contains characters other than the following: alphanumerics, dashes (-), slashes (/), backslashes (\), and underscores (_). The default is to display all file dependencies. Wildcard characters are permitted. Specifies the state of the file dependencies to be displayed. The default is to display file dependencies in all states. The states are as follows: yes no ? File exists and is available. File is unavailable, or does not exist. Availability is being checked.
file
state
<blank> The file has not yet been checked, or the file was available and used to satisfy a job or job stream dependency. keys deps offline Displays a single column list of the objects selected by the command. Displays information in the deps format. Use keys, info, or logon to modify the display. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
Command Output
The output of the command is produced in three formats: standard, keys, and deps. The arguments keys, info, and logon modify the deps display. Standard format: Exists The state of the file dependency. File Name The name of the file. keys format: Files are listed with one file on each line. Directory names are not included. Each file is listed in the following format:
wkstation#file
180
deps format: Files are listed followed by the dependent jobs and job streams. Jobs are listed in the standard showjobs format. Job streams are listed in the standard showschedules format. deps;keys format: Jobs and job streams that have file dependencies are listed with one on each line, in the following format:
wkstation#jstream[.job]
deps;info format: Files are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;info format. Job streams are listed in the standard showschedules format. deps;logon format: Files are listed followed by the dependent jobs and job streams. Jobs are listed in the showjobs;logon format. Job streams are listed in the standard showschedules format. | | | | | | | |
Examples
To display the status of a file dependency for d:\apps\mis\lib\data4, 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, run the following command:
sf @#@;deps;offline
181
showjobs
Displays information about jobs.
Synopsis
sj [jobselect] [;keys | info | step | logon | retcod][;short | single][;offline] sj [jobselect] [;deps[;keys | info | logon]][;short | single][;offline] sj [jobselect|wkstation# {jobnumber.hhmm}] [;stdlist[;keys]][;short | single][;offline]
Arguments
jobselect wkstation jobnumber hhmm keys info step logon retcod stdlist deps short See Selecting jobs in commands on page 120. The name of the workstation on which the job runs. Wildcard characters are permitted. The job number. The started time of the job. Use this, together with the stdlist and single arguments, to display a specific instance of the job. Displays a single column list of the objects selected by the command. Displays information in the info format. Displays information in the step format. Displays information in the logon format. Displays the return code for the job. Displays information in the stdlist format. Use the keys argument to modify the display. Displays information in the deps format. Use keys, info, or logon to modify the display. 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, repetitions, and recovery jobs. The job must be identified by job number in jobselect. This is particularly useful with the stdlist option. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
single
offline
Command Output
The output of the showjobs command is produced in seven formats: standard, keys, info, step, logon, deps, and stdlist. The arguments keys, info, and logon modify the displays. Standard format: CPU The workstation on which the job runs.
182
Schedule The name of the job stream. Job The name of the job. The following notation may precede a job name: >> rerun as A job that was rerun with the rerun command, or as a result of automatic recovery. >> rerun step A job that was rerun with the rerun ;step command. >> every run The second and subsequent runs of an every job. >> recovery The run of a recovery job. State The state of the job or job stream. Job states are as follows: abend The job terminated with a non-zero exit code. abenp An abend confirmation was received, but the job is not completed. add done error exec extrn The job is being submitted. The job completed in an unknown state. For internetwork dependencies only, an error occurred while checking for the remote status. The job is executing. For internetwork dependencies only, the status is unknown. An error occurred, a rerun action was just performed on the job in the external job stream, or the remote job or job stream does not exist. Unable to launch the job. The jobs priority is below the fence. The job is awaiting dependency resolution. The job is introduced for launching by the system. The job completed, and is awaiting confirmation. The job is ready to launch, and all dependencies are resolved.
sched The jobs at time has not arrived. succ succp wait The job completed with an exit code of zero. A succ confirmation was received, but the job is not completed. The job is in the wait state. (Extended agent)
Job stream states are as follows: abend The job stream terminated with a non-zero exit code. add The job stream was added with operator intervention.
cancel The job stream was canceled. cancel pend The job stream is pending cancellation. Cancellation is deferred until all of the dependencies, including an at time, are resolved.
183
For internetwork dependencies only, an error occurred while checking for the remote status. The job stream is executing. For internetwork dependencies only, the job stream is in a remote scheduler network and its status is unknown. An error occurred, a rerun action was just performed on the EXTERNAL job stream, or the INET job or job stream does not exist. The job stream is awaiting dependency resolution. The job stream is ready to launch and all dependencies are resolved. Execution of the job stream was interrupted. No jobs are launched without operator intervention. The job stream completed successfully.
The priority of the job stream or job. A plus sign (+) preceding the priority means the job has been launched.
(Est)Start The start time of the job stream or job. Parentheses indicate an estimate of the start time. If the start time is more than 24 hours in the past or future, the date is listed instead of the time. (Est)Elapse The run time of the job stream or job. Parentheses indicate an estimate based on logged statistics. dependencies A list of job dependencies and comments. Any combination of the following can be listed: v For a follows dependency, a job stream or job name is displayed. v For an opens dependency, the file name is displayed. If the file resides on an extended agent and its name is longer than 25 characters, only the last 25 characters are displayed. v For a needs dependency, a resource name enclosed in hyphens (-) is displayed. If the number of units requested is greater than one, the number is displayed before the first hyphen. v For a deadline time, the time preceded by an angle bracket (<) is displayed. v For an every rate, the repetition rate preceded by an ampersand (&) is displayed. v For an until time, the time preceded by an angle bracket (<) is displayed. v For a prompt dependency, the prompt number is displayed in the format #num. For global prompts, the prompt name follows in parentheses. v For executing jobs, the process identification number (PID) is displayed in the format #Jnnnnn. v Jobs submitted on UNIX using the IBM Tivoli Workload Scheduler at and batch commands are labeled [Userjcl]. v Cancelled jobs are labeled [Cancelled]. v Jobs cancelled with ;pend option are labeled [Cancel Pend].
184
v Jobs with expired until times, including jobs cancelled with ;pend option, are labeled [Until]. v [Recovery] means that operation intervention is required. v [Confirm] means that confirmation is required because the job was scheduled using the confirm keyword. 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. keys format: Job names are listed one on each line in the following format:
wkstation#jstream.job
Schedule The name of the job stream. Job The name of the job. The following notation may precede a job name: >> rerun as A job that was rerun with the rerun command, or as a result of automatic recovery. >> rerun step A job that was rerun with the rerun ;step command. >> every run The second and subsequent runs of an every job. >> recovery The run of a recovery job. Job File The name of the jobs script or executable file. Long file names might wrap, causing incorrect paging. To avoid this, pipe the output to more. For example:
conman sj;info | more
The job recovery option, if any. The recovery options are RE for rerun, CO for continue, and ST for stop. The name of the recovery job, if any. The number of the recovery prompt, if any.
step format: This format is not supported on Windows. CPU The workstation on which the job runs.
Schedule The name of the job stream. Job The name of the job. The following notation might precede a job name: >> rerun as A job that was rerun with rerun command, or as a result of automatic recovery. >> repeated as The second and subsequent runs of an every job.
Chapter 5. Conman reference
185
State
The state of the job or job stream. See Standard Format for information about state.
Return code The return code of the job. Job# Step The process identification number displayed as #Jnnnnn. A list of descendant processes that are associated with the job. For extended agent jobs, only host processes are listed.
Schedule The name of the job stream. Job The name of the job. The following notation may precede a job name: >> rerun as A job that was rerun with rerun command, or as a result of automatic recovery. >> repeated as The second and subsequent runs of an every job. State The state of the job or job stream. See Standard Format for information about state.
Return code The return code of the job. Job# The process identification number displayed as #Jnnnnn.
Logon The user name under which the job runs. | | | | | | | | | | | | | | | | | | | | stdlist format: A standard list file is created automatically by Jobmon on Windows or Jobman on UNIX, for each job Jobmon and Jobman launch. You can display the contents of the standard list files using Conman. A standard list file contains: v Header and trailer banners. v Echoed commands. v The stdout output of the job. v The stderr output of the job. To specify a particular date format to be used in the standard list files, change the IBM Tivoli Workload Scheduler date format before creating the standard list files. You do this by modifying the date locale format. Depending on your environment, change the date locale format by performing the steps listed below: v On UNIX, set the LANG variable in the environment when Netman starts. If the LANG variable is not set, the operating system locale is set by default to C. v On Windows, perform the following steps: 1. Go to Control PanelRegional Options and set your locale (location). 2. Right-click on My Computer, go to Properties, click on Advanced, go to Environment Variables and set the LANG variable as a system variable. 3. Shut down and restart the system.
186
The standard list files for the selected jobs are displayed. stdlist;keys format: The names of the standard list files for the selected jobs are listed, one on each line. deps format: Jobs used in follows dependencies are listed followed by the dependent jobs and job streams. Jobs are listed in the standard showjobs format. Job streams are listed in the standard showschedules format. deps;keys format: Jobs and job streams that have follows dependencies are listed, one on each line. deps;info format: Jobs used in follows dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;info format. Job streams are listed in the standard showschedules format. deps;logon format: Jobs used in follows dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;logon format. Job streams are listed in the standard showschedules format.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Examples
To display the status of all jobs in all acctg job streams on workstation site3, run the following command:
showjobs site3#acctg@.@
To display the status of all jobs on the workstation on which you are running Conman, in the logon format, run the following command:
sj ;logon
To display the status of all jobs in the hold state on all workstations, in the deps format, run the following command:
sj @#@.@+state=hold;deps
To display all the standard list files for the job sendmail in the job stream mail on workstation WN1, running in a Windows environment, run the following command:
sj WN1#mail.sendmail;stdlist
where:
187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Exit Status Is the status of the job when it completed. Elapsed Time Is the elapsed time for the job. System Time Is the time the kernel system spent for the job. User Time Is the time the system user spent for the job. Note: The System Time and User Time fields are used only in UNIX. Their values in Windows are always set to 0. This is because, in Windows, the joblnch.exe process runs in a very short time, which can be considered null. 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 TWS for UNIX (AIX)/CONMAN 8.2 (1.36.1.7) Licensed Materials Property of IBM 5698-WKB (C) Copyright IBM Corp 1998,2001 US Government User Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Installed for user Locale LANG set to en_US Schedule (Exp) 09/30/03 (#126) on MASTER. Batchman LIVES. Limit: 10, Fence: 0, Audit Level: 1 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 CHCKMRGE SUCC 10 22:12 00:01 #J17926 0 DATACLNS SUCC 10 22:12 00:01 #J17932 0 DATARMRG SUCC 10 22:13 00:01 #J18704 0 DBSELOAD SUCC 10 22:13 00:01 #J18706 7 DATAREPT SUCC 10 22:13 00:01 #J18712 0 DATARTRN SUCC 10 22:14 00:01 #J18714 0 $
There is also a new arguments retcod, that when used in conjunction with the keys argument, gives the return code for a specified job, as shown in the following example:
$ conman sj workstation#daily_db_load.dbseload\;keys\;retcod TWS for UNIX (AIX)/CONMAN 8.2 (1.36.1.7) Licensed Materials Property of IBM 5698-WKB (C) Copyright IBM Corp 1998,2001 US Government User Restricted Rights
188
| | | | | | | | | |
Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Installed for user Locale LANG set to en_US Schedule (Exp) 10/16/03 (#150) on MASTER. Batchman LIVES. Limit: 10, Fence: 0, Audit Level: 1 sj workstation#daily_db_load.dbseload;keys;retcod 8$
The retcod feature when integrated into a script can become quite powerful.
See Also
| | For the equivalent Job Scheduling Console task, see Working with Object Lists in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
189
showprompts
Displays information about prompts.
Synopsis
sp [promptselect][;keys][;offline] sp [promptselect] [;deps[;keys | info | logon]][;offline]
Arguments
promptselect [promptname | [wkstation#]msgnum][;state[;...]] promptname Specifies the name of a global prompt. Wildcard characters are permitted. wkstation Specifies the name of the workstation on which an unnamed prompt is issued. The default is the workstation on which Conman is running. msgnum Specifies the message number of an unnamed prompt. state Specifies the state of prompts to be displayed. The states are as follows: YES NO The prompt was replied to with y. The prompt was replied to with n.
ASKED The prompt was issued, but no reply was given. INACT The prompt has not been issued. keys deps info Displays a single column list of the objects selected by the command. Displays information in the deps format. Use keys, info, or logon to modify the display. Displays information in the info format.
logon Displays information in the logon format. offline Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
Command Output
The output of the command is produced in three formats: standard, keys, and deps. The arguments keys, info, and logon modify the deps display. Standard format: State The state of the prompt.
Message or Prompt For named prompts, the message number, the name, and the text of the prompt. For unnamed prompts, the message number, the name of the job or job stream, and the text of the prompt.
190
keys format: The prompts are listed one on each line. Named prompts are listed with their message numbers and names. Unnamed prompts are listed with their message numbers, and the names of the jobs or job streams in which they appear as dependencies. deps format: Prompts used as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the standard showjobs format. Job streams are listed in the standard showschedules format. deps;keys format: Jobs and job streams that have prompt dependencies are listed one on each line. deps;info format: Prompts used as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;info format. Job streams are listed in the standard showschedules format. deps;logon format: Prompts used as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;logon format. Job streams are listed in the standard showschedules format. | | | | | | | | | | | | | |
Examples
To display the status of all prompts issued on the workstation on which you are running Conman, run the following command:
showprompts
To display the status of all mis prompts that have been issued, in the deps format, run the following command:
sp mis@;asked;deps
To display the status of prompt number 34 on workstation main, run the following command:
sp main#34
See Also
For the equivalent Job Scheduling Console task, see Displaying and Modifying Prompt Properties in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
191
showresources
Displays information about resources.
Synopsis
sr [[wkstation#]resourcename][;keys][;offline] sr [[wkstation#]resourcename][;deps[;keys | info | logon]][;offline]
Arguments
wkstation Specifies the name of the workstation on which the resource is defined. The default is the workstation on which Conman is running. Specifies the name of the resource. Wildcard characters are permitted. Displays a single column list of the objects selected by the command. Displays information in the deps format. Use keys, info, or logon to modify the display. Displays information in the info format. Displays information in the logon format. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
Command Output
The output of the command is produced in three formats: standard, keys, and deps. The arguments keys, info, and logon modify the deps display. Standard format: CPU Resource Total Available Qty Used By The workstation on which the resource is defined. The name of the resource. The total number of defined resource units. The number of resource units that have not been allocated. The number of resource units allocated to a job or job stream. The name of the job or job stream.
keys format: The resources are listed one on each line. deps format: Resources used as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the standard showjobs format. Job streams are listed in the standard showschedules format. deps;keys format: Jobs and job streams that have resource dependencies are listed one on each line. deps;info format: Resources used as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;info format. Job streams are listed in the standard showschedules format.
192
deps;logon format: Resources used as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;logon format. Job streams are listed in the standard showschedules format. | | | | | | | | | |
Examples
To display information about all resources on the workstation on which you are running Conman, run the following command:
showresources
To display information about the dbase resource on workstation main in the deps format, run the following command:
sr main#dbase;deps
See Also
For the equivalent Job Scheduling Console task, see Displaying Resource Properties in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
193
showschedules
Displays information about job streams.
Synopsis
ss [jstreamselect][;keys][;offline] ss [jstreamselect][;deps[;keys | info | logon]][;offline]
Arguments
jstreamselect keys deps info logon offline See Selecting job streams in commands on page 128. Displays a single column list of the objects selected by the command. Displays information in the deps format. Use keys, info, or logon to modify the display. Displays information in the info format. Displays information in the logon format. Sends the output of the command to the Conman output device. For information about this device, see Offline output on page 116.
Command Output
The output of the command is produced in three formats: standard, keys, and deps. The arguments keys, info, and logon modify the deps display. Standard format: CPU The workstation on which the job stream runs.
Schedule The name of the job stream. State The state of the job stream. The states are as follows: add The job stream was added with operator intervention.
abend The job stream terminated with a non-zero exit code. cancel The job stream was canceled. cancel pend The job stream is pending cancellation. Cancellation is deferred until all of the dependencies, including an at time, are resolved. error exec extrn For internetwork dependencies only, an error occurred while checking for the remote status. The job stream is executing. For internetwork dependencies only, the job stream is in a remote scheduler network and its status is unknown. An error occurred, a rerun action was just performed on the EXTERNAL job stream, or the INET job or job stream does not exist. The job stream awaiting dependency resolution. The job stream ready to launch and all dependencies are resolved. Job stream execution was interrupted. No jobs are launched without operator intervention.
194
succ Pr
(Est)Start The start time of the job stream. Parentheses indicate an estimate of the start time. If the start time is more than 24 hours in the past or future, the date is listed instead of the time. (Est)Elapse The run time of the job stream. Parentheses indicate an estimate based on logged statistics. Jobs # The number of jobs in the job stream. Jobs OK The number of jobs that have completed successfully. Sch Lim The job streams job limit. If one is not listed, no limit is in effect. dependencies A list of job stream dependencies and comments. Any combination of the following may be listed: v For a follows dependency, a job stream or job name is displayed. v For an opens dependency, the file name displayed. If the file resides on an extended agent, and its name is longer than 25 characters, only the last 25 characters are displayed. v For a needs dependency, a resource name enclosed in hyphens (-) is displayed. If the number of units requested is greater than one, the number is displayed before the first hyphen. v For an until time, the time preceded by an angled bracket (<). v For a prompt dependency, the prompt number displayed as #num. For global prompts, the prompt name in parentheses follows. v Cancelled job streams are labeled [Cancelled]. v Job streams cancelled with the ;pend option are labeled [Cancel Pend]. v For a deadline time, the time preceded by an angle bracket (<) is displayed. v Job streams with expired until times, including job streams cancelled with the ;pend option, are labeled: [Until]. v Job streams that contain the carryforward keyword are labeled [Carry]. v For job streams that were carried forward from the previous day, the original name and date are displayed in brackets. keys format: The job streams are listed one on each line. deps format: Job streams used as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the standard showjobs format. Job streams are listed in the standard showschedules format. deps;keys format: Job streams that have follows dependencies are listed one on each line. deps;info format: Job streams used in as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;info format. Job streams are listed in the standard showschedules format.
195
deps;logon format: Job streams used in as dependencies are listed, followed by the dependent jobs and job streams. Jobs are listed in the showjobs;logon format. Job streams are listed in the standard showschedules format. | | | | | | | | | | | | | | | | | | | | | | | | | |
Examples
To display the status of all job streams in the hold state on the workstation on which you are running Conman, run the following command:
showschedules @+state=hold
To display the status of all corp job streams on workstation site2 in the deps;info format, run the following command:
ss site2#corp@;deps;info
To display offline the status of all job streams in the abend state on all workstations, run the following command:
ss @#@+state=abend;off
To display the status of all job streams on all workstations, run the following command:
%ss @#@
See Also
For the equivalent Job Scheduling Console task, see Displaying a Job Stream in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
196
shutdown
Unconditionally stops all of scheduler production processes, including Batchman, Jobman, Netman, Mailman, all Mailman servers, and all writers. You must have shutdown access to the workstation.
Synopsis
shutdown [;wait]
Arguments
wait Waits until all processes have stopped before prompting for another command.
Usage Notes
The shutdown command stops the processes only on the workstation on which Conman is running. To restart Netman only, run the StartUp command. For information about the StartUp command, see StartUp on page 255. To restart the entire process tree, run a Conman start command. You must run a Conman unlink @ command before executing a shutdown command. | | | | | | | | | |
Examples
To shut down production on the workstation on which you are running Conman, 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, run the following command:
unlink@;noask shut ;wait
197
start
Starts scheduler production processes. You must have start access to the workstation.
Synopsis
| start [domain!]wkstation[;mgr][;noask][;demgr]
Arguments
domain Specifies the name of the domain in which workstations are started. Wildcard characters are permitted. This argument is useful when starting more than one workstation in a domain. For example, to start all the agents in domain stlouis, use the following command:
start stlouis!@
If domain is omitted, and wkstation contains wildcard characters, the default domain is the one in which Conman is running. wkstation mgr Specifies the name of the workstation to be started. Wildcard characters are permitted. This can be entered only on the workstation on which Conman is running. It starts the local workstation as the domain manager. The workstation becomes the new domain manager and the current domain manager becomes a fault-tolerant agent. This form of the command usually follows a stop command. Note that the preferred method of switching a domain manager is to use a switchmgr command. See switchmgr on page 212 for more information. Specifies not to prompt for confirmation before taking action on each qualifying workstation. This option prevents the opening of external connections during the transition time between when an agent starts as an old domain manager, and when the switchmgr command is run, depriving the agent of the domain manager function. This option is run automatically, but until the old domain manager has processed the switchmgr event (in the case, for example, of delayed restart or restart after repairing a damaged agent), the demgr option must be used to start the old domain manager from the local command line. For more details on this option, see the IBM Tivoli Workload Scheduler Planning and Installation Guide.
noask | | | | | | | | | | demgr
Usage Notes
The start command is used at the start of each day to restart the scheduler following pre-production processing. At that time it causes the autolinked fault-tolerant agents and standard agents to be initialized and started automatically. Agents that are not autolinked are initialized and started when you run a link command. Assuming the user has start access to the workstations being started, the following rules apply: v A user running Conman on the master domain manager can start any workstation in the network.
198
v A user running Conman on a domain manager other than the master can start any workstation in that domain and subordinate domains. The user cannot start workstations in peer domains. v A user running Conman on an agent can start workstations that are hosted by that agent.
Examples
The illustration and table below show the workstations started by start commands run by users in various locations in the network. DMn are domain managers and Ann are agents.
Figure 4. Started workstations in network 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 DM4 A41 A42 DM2 A42 A31 DM2 A21 A22 Not allowed.
start @
A21
start DOMAIN3!@
Not allowed
start DOMAIN4!@
Not allowed
199
status
Displays the Conman banner and the IBM Tivoli Workload Scheduler production status.
Synopsis
status
Command Output
Following the word Schedule on the second line of output, the production plan (Symphony) mode is shown in parentheses. The Def or Exp information can appear. Def means that the production plan is in non-expanded mode, and Exp means it is in expanded mode. The mode of the production plan is determined by the setting of the Global option expanded version. With IBM Tivoli Workload Scheduler, Version 8.2, databases and plans are always expanded, but this information appears for backward compatibility.
Examples
The following example displays the status of the current production plan. Then it sets the production plan pointer to 2 and displays the status of that production plan.
%status TWS for WINDOWS NT/CONMAN 8.2 (1.36.1.7) Licensed Materials Property of IBM 5698-WKB (C) Copyright IBM Corp 1998,2001 US Government User Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Schedule (Exp) 05/19/03 (#17) on DEMOCPU. Batchman down. Limit: 30, Fence: 0, Audit Level: 1
200
stop
Stops scheduler production processes. To stop the Netman process, use the shutdown command. You must have stop access to the workstation.
Synopsis
stop [domain!]wkstation[;wait][;noask]
Arguments
domain Specifies the name of the domain in which workstations are stopped. Because workstations have unique names, the domain is not needed when stopping a specific workstation. Wildcard characters are permitted. This argument is useful when stopping more than one workstation in a domain. For example, to stop all the agents in domain stlouis, use the following command:
stop stlouis!@
If domain is omitted, and wkstation contains wildcard characters, the default domain is the one in which Conman is running. wkstation wait noask Specifies the name of the workstation to be stopped. Wildcard characters are permitted. Specifies not to accept another command until all processes have stopped. Specifies not to prompt for confirmation before taking action on each qualifying workstation.
Usage Notes
If the stop command cannot be applied to a distant workstation (if the TCP/IP path not available, for example), the command is stored locally in a pobox file, and is mailed to the workstation when it becomes linked. 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. v A user running Conman on a domain manager other than the master can stop any workstation in that domain and subordinate domains. The user cannot stop workstations in peer domains. v A user running Conman on an agent can stop any workstation in the local domain. When you issue a stop @ command on a domain manager, a local conman stop command runs on the remote CPUs. The command starts running on the lowest stations in the network hierarchy, then finally runs on the domain manager. However, the symphony files are not updated before the CPUs go down. Therefore, if you issue a conman sc@!@ command form any CPU, the resulting information might be an accurate picture of the states of the CPUs, even of the domain manager.
201
Examples
The illustration and table below show the workstations stopped by different stop commands run by users in different locations in the network. DMn are domain managers and Ann are agents.
Figure 5. Stopped workstations in network 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 @
stop DOMAIN3!@
stop DOMAIN4!@
Not allowed.
202
stop ;progressive
Stops scheduler production processes hierarchically when you have defined at least one workstation as behindfirewall in an IBM Tivoli Workload Scheduler Version 8.2 network. Similar to the stop @!@ command, but more effective in improving plan execution performance. The command does not run from the domain in which the command was initially issued for each subordinate domain, but runs at each hierarchical level. You must have stop access to the workstation.
Synopsis
stop ;progressive
Usage Notes
When you issue the command on a domain manager, 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, the domain manager stops workstations in the same domain, stops itself, and then continues to run on subordinate domains.
Examples
The illustration Figure 5 on page 202 and the table below show the workstations stopped by issuing the stop ;progressive command on DM2.
Command stop ;progressive Stopped by DM2 A21 A22 DM2 Stopped by DM4 A41 A42 DM4
203
submit docommand
Submits a command to be launched as a scheduler job. You must have submit access to the job. To include needs and prompt dependencies, you must have use access to the resources and global prompts.
Synopsis
sbd [wkstation#]cmd[;alias[=name]][;into=jobstream] [;joboption[;...]]
Arguments
wkstation Specifies the name of the workstation on which the job will be launched. Wildcard characters are permitted, in which case, the job is launched on all qualifying workstations. The default is the workstation on which Conman is running. You cannot specify a domain or workstation class. cmd Specifies a valid system command of up to 255 characters. The entire command must be enclosed in quotes (). The command is treated as a job, and all job rules apply.
alias=name Specifies a unique name to be assigned to the job. If you enter the alias keyword without specifying a name, a name is constructed using up to the first six alphanumeric characters (in upper case) of the command, depending on the number of characters in the command, followed by a ten digit random number. If there are blanks in the command, the name is constructed using up to the first six alphanumeric characters before the blank. For example, if the command is rm apfile, the generated name will be similar to RM0123456789. If the command is longer than six alphanumeric characters such as, wlsinst, the generated name will be wlsins0396578515. If you do not include alias the first time you submit the command, a job name is constructed using up to 255 characters of the command name. If you submit a command a second time from the same workstation, the alias keyword is mandatory and must be unique for each command submission. into=jobstream Specifies the name of the job stream into which the job will be placed for launching. Enter the name as follows: [wkstation#]jstream If you do not specify a wkstation, the default is the workstation on which Conman is running. If into is not used, the job is added to a job stream named JOBS. 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::][wkstation#]jstream{.job | @} | job[;nocheck][;wait=time][,...] interactive
204
logon=user needs=[num] [wkstation#]resource[,...] opens=[wkstation#]filename[(qualifier)][,...] priority[=pri | hi | go] prompt=[: | !]text | promptname[,...] rccondsuccSuccess Condition recovery=stop | continue | rerun after [wkstation#]jobname abendprompt text until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil action]
Usage Notes
If you do not specify a workstation with follows, needs, or opens, the default is the workstation of the job. If the job is run on a fault-tolerant agent, and you want to include a prompt dependency or a recoveryprompt, the mozart directory (TWShome/mozart) on the master domain manager must be accessible, either mounted or shared. | | | | | | | | | | |
Examples
To submit an rm command into the job stream JOBS with a follows dependency, run the following command:
submit docommand="rm apfile";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.m., run the following command:
sbd "sort < file1 > file2";alias=sortit;into=reports;at=1730
To submit chmod commands on all workstations with names beginning with site, run the following command:
sbd site@#"chmod 444 file2";alias
205
submit file
Submits a file to be launched as a scheduler job. You must have submit access to the job. To include needs and prompt dependencies, you must have use access to the resources and global prompts.
Synopsis
sbf filename[;alias[=name]][;into=jobstream][;joboption[;...]][;noask]
Arguments
filename Specifies the name of the file, up to 255 characters. Wildcard characters are permitted. The name must be enclosed in quotes () if it contains characters other than alphanumeric characters, dashes (-), slashes (/), backslashes (\), and underscores (_). alias=name Specifies a unique name to be assigned to the job. If you enter the alias keyword without specifying a name, a name is constructed using up to the first six alphanumeric characters (in upper case) of the file name, depending on the number of characters in the file name, followed by a ten digit random number. For example, if the file name is jclttx5, the generated name will be similar to JCLTTX0123456789. If you do not include alias, a filename is constructed using up to 255 alphanumeric characters of the files base name, in upper case. In either of the above cases, if the file name does not start with a letter, you are prompted to use alias= name. If you submit a file a second time from the same workstation, the alias keyword is mandatory and must be unique for each file submission. into=jobstream The name of the job stream into which the job will be placed for launching. Enter the name as: [wkstation#]jstream If you do not specify a wkstation, the default is the workstation on which Conman is running. If into is not used, the job is added to a job stream named JOBS. 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::][wkstation#]jstream{.job | @} | job[,...] interactive logon=user needs=[num] [wkstation#]resource[,...] opens=[wkstation#]filename[(qualifier)][,...] priority[=pri | hi | go] prompt=[: | !]text | promptname[,...]
206
rccondsuccSuccess Condition recovery=stop | continue | rerun after [wkstation#]jobname abendprompt text until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil action] noask Specifies not to prompt for confirmation before taking action against each qualifying file.
Usage Notes
If you do not specify a workstation with follows, needs, or opens, the default is the workstation on which Conman is running. If the job is run on a fault-tolerant agent, and you want to include a prompt dependency or a recoveryprompt, the mozart directory (TWShome/mozart) on the master domain manager must be accessible, either mounted or shared. | | | | | | | | | | | |
Examples
To submit a file into the job stream jobs (the job name is myjcl), run the following command:
submit file=d:\jobs\lib\daily\myjcl
To submit a file, with a job name of misjob4, into the job stream missked, run the following command:
sbf /usr/lib/mis/jcl4;alias=misjob4;into=missked ;needs=2 slots
The job needs two units of the slots resource. To submit all files that have names beginning with back into the job stream bkup, run the following command:
sbf "/usr/lib/backup/back@";into=bkup
207
submit job
Submits a job to be launched by the scheduler. You must have submit access to the job. To include needs and prompt dependencies, you must have use access to the resources and global prompts. To submit a job, you must be running Conman on the master domain manager, or have access to the scheduler databases on the master domain manager.
Synopsis
sbj [wkstation#]jobname[;alias[=name]][;into=jobstream] [;joboption[;...]][;noask]
Arguments
wkstation Specifies the name of the workstation on which the job will be launched. Wildcard characters are permitted, in which case, the job is launched on all qualifying workstations. The default is the workstation on which Conman is running. You cannot specify a domain or workstation class. jobname Specifies the name of the job. Wildcard characters are permitted, in which case, all qualifying jobs are submitted. If the job is already in the production plan, and is being submitted into the same job stream, you must use the alias argument to assign a unique name. alias=name Specifies a unique name to be assigned to the job in place of jobname. If you enter the alias keyword without specifying a name, a name is constructed using the first two alphanumeric characters of jobname followed by a six digit random number. The name is always upshifted. For example, if jobname is jcrttx5, the generated name will be similar to JC123456. into=jobstream Specifies the name of the job stream into which the job will be placed for launching. Enter the name as: [wkstation#]jstream If you do not specify a wkstation, the default is the workstation on which Conman is running. If into is not used, the job is added to a job stream named jobs. 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::][wkstation#]jstream{.job | @} | job[;nocheck][;wait=time][,...] needs=[num] [wkstation#]resource[,...] opens=[wkstation#]filename[(qualifier)][,...] priority[=pri | hi | go] prompt=[: | !]text | promptname[,...]
208
rccondsuccSuccess Condition recovery=stop | continue | rerun after [wkstation#]jobname abendprompt text until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil action] noask Specifies not to prompt for confirmation before taking action against each qualifying job.
Usage Notes
If you do not specify a workstation with follows, needs, or opens, the default is the workstation of the job. If the job is run on a fault-tolerant agent, and you want to include a prompt dependency or a recoveryprompt, the mozart directory (TWShome/mozart) on the master domain manager must be accessible, either mounted or shared. | | | | | | | | | | | |
Examples
To submit the test jobs into the job stream JOBS, run the following command:
submit job=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.m., run the following command:
sbj rjob4;alias=rptx4;into=reports;at=1730
To submit job txjob3 on all workstations whose names begin with site, run the following command:
sbj site@#txjob3;alias
See Also
For the equivalent Job Scheduling Console task, see Submitting Jobs in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
209
submit sched
Submits a job stream to be launched by the scheduler. You must have submit access to the job stream. To include needs and prompt dependencies, you must have use access to the resources and global prompts. To submit a job stream, you must be running Conman on the master domain manager or have access to the scheduler databases on the master domain manager.
Synopsis
sbs [wkstation#]jstreamname[;alias[=name]] [;jstreamoption[;...]][;noask]
Arguments
wkstation Specifies the name of the workstation on which the job stream will be launched. Wildcard characters are permitted, in which case, the job stream is launched on all qualifying workstations. The default is the workstation on which Conman is running. You cannot specify a domain or workstation class. jstreamname Specifies the name of the job stream. Wildcard characters are permitted, in which case, all qualifying job streams are submitted. If the job stream is already in the production plan, you must use the alias argument to assign a unique name. alias=name Specifies a unique name to be assigned to the job stream in place of jstreamname. If you enter the alias keyword without specifying a name, a name is constructed using the first two alphanumeric characters of jstreamname followed by a six digit random number. The name is always upshifted. For example, if jstreamname is sttrom, the generated name will be similar to ST123456. jstreamoption Enter one of the following: at=hhmm [timezone|tz tzname] [+n days | mm/dd/yy] | [absolute | abs] carryforward deadline=time[timezone | tz tzname][+n days | mm/dd/yy] follows=[netagent::][wkstation#]jstream{.job | @} | job[;nocheck][;wait=time][,...] limit=joblimit needs=[num] [wkstation#]resource[,...] opens=[wkstation#]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 against each qualifying job stream.
210
Usage Notes
If you do not specify a workstation with follows, needs, or opens, the default is the workstation of the job stream. If the job stream is run on a fault-tolerant agent, and you want to include a prompt dependency or a recoveryprompt, the mozart directory (TWShome/mozart) on the master domain manager must be accessible, either mounted or shared. | | | | | | | | | | | | |
Examples
To submit the adhoc job stream on workstation site1 and flags it as a carryforward job stream, run the following command:
submit sched=site1#adhoc;carryforward
To submit job stream fox4 with a job limit of 2, a priority of 23, and an until time of midnight, run the following command:
sbs fox4;limit=2;pri=23;until=0000
To submit job stream sched3 on all workstations with names that start with site, run the following command:
sbs site@#sched3
See Also
For the equivalent Job Scheduling Console task, see Plan Tasks for Distributed in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
211
switchmgr
Switches domain management from the current domain manager to a backup domain manager. You must have start and stop access to the backup domain manager.
Synopsis
switchmgr domain;newmgr
Arguments
domain newmgr Specifies the domain in which you want to switch managers. Specifies the name of the new domain manager. This must be a workstation in the same domain, and should be defined beforehand as a fault-tolerant agent with Resolve Dependencies and Full Status enabled.
Usage Notes
The command stops a specified workstation and restarts it as the domain manager. All domain member workstations are informed of the switch, and the old domain manager is converted to a fault-tolerant agent in the domain. If new day processing (the Jnextday job) is performed on the old domain manager, the domain will act as though another switchmgr command had been run and the old domain manager will automatically resume domain management responsibilities. | | | | | | | |
Examples
To switch the domain manager to workstation orca in the masterdm domain, run the following command:
switchmgr masterdm,orca
To switch the domain manager to workstation ruby in the bldg2 domain, run the following command:
switchmgr bldg2,ruby
212
system
runs a system command.
Synopsis
[: | !] sys-command
Arguments
sys-command Specifies any valid system command. The prefix (: or !) is required only when a command name has the same spelling as a Conman command.
| | | | | |
Examples
To run a ps command on UNIX, run the following command:
ps -ef
213
tellop
Sends a message to the scheduler console.
Synopsis
to [text]
Arguments
text Specifies the text of the message. The message can contain up to 900 characters.
Usage Notes
If tellop is issued on the master domain manager, the message is sent to all linked workstations. If issued on a domain manager, the message is sent to all of the linked agents in its domain and subordinate domains. 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 is displayed only if the console message level is greater than zero. See console on page 146. If tellop is entered alone, it prompts for the message text. At the prompt, type each line and press the Return key. At the end of the message, type two slashes (//) or a period (.), and press the Return key. You can use the new line sequence (\n) to format messages. Typing Control+c at any time will exit the tellop command without sending the message. | | | | | | | | | | |
Examples
To send a message, run the following command:
tellop TWS will be stopped at\n4:30 for 15 minutes.
To prompt for text before sending a message, run the following command:
to TELLOP>********************************* TELLOP>* TWS will be stopped at * TELLOP>* 4:30 for 15 minutes. * TELLOP>********************************* TELLOP>//
214
unlink
Closes communication links between workstations. You must have unlink access to the target workstation.
Synopsis
unlink [domain!]wkstation[;noask]
Arguments
domain Specifies the name of the domain in which to close links. It is not necessary to specify the domain name of a workstation in the master domain. Wildcard characters are permitted. Note: You must always specify the domain name when unlinking a workstation not in the master domain. This argument is useful when unlinking more than one workstation in a domain. For example, to unlink all the agents in domain stlouis, use the following command:
link stlouis!@
If you do not specify domain, and wkstation includes wildcard characters, the default domain is the one in which Conman is running. wkstation noask Specifies the name of the workstation to be unlinked. Wildcard characters are permitted. Specifies not to prompt for confirmation before taking action on each qualifying workstation.
Usage Notes
Assuming that a user has unlink access to the workstations being unlinked, the following rules apply: v A user running Conman on the master domain manager can unlink any workstation in the network. v A user running Conman on a domain manager other than the master can unlink any workstation in its own domain and subordinate domains. 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. A peer agent in the same domain cannot be unlinked. For additional information see link on page 159.
Examples
The illustration and table below show the links closed by unlink commands run by users in various locations in the network.
215
unlink @
DM1-A11 DM1-A12 DM1-DM2 DM1-DM3 DM3-A31 DM3-A32 DM4-A41 DM4-A42 DM1-DM2 DM4-A42 DM3-A31
DM2-A21
unlink DOMAIN3!@ unlink DOMAIN4!@ unlink DM2 unlink A42 unlink A31
216
version
Displays Conmans command line program banner.
Synopsis
version | | | | |
Examples
To display Conmans command line program banner, run the following command:
%version MAESTRO for UNIX (HPUX)/CONMAN 6.0 (3.34) (C) Tivoli Systems 1998 Schedule 5/16/98 (#7) on SFO. Batchman down. Limit: 6, Fence: 0
217
218
Command descriptions
Command at batch caxtract cpuinfo datecalc dbexpand delete evtsize jbxtract jobinfo jobstdl listproc killproc maestro makecal metronome.pl morestdl parms paxtract prxtract r11xtr release rextract rmstdlist showexec StartUp version xrxtrct wmaeutil Description For UNIX only. Submits a job to be run at a specific time. For UNIX only. Submits a job to be run as soon as possible. Extracts information about calendars. Returns information from a workstation definition. Converts date and time to a desired format Expands scheduler databases. Removes script files and standard list files by name. Defines the maximum size of event message files. Extracts information about jobs. Returns information about a job. Returns the pathnames of standard list files. For Windows only. Lists processes. This command is unsupported. For Windows only. Kills processes. This command is unsupported. Returns the scheduler home directory. Creates custom calendars. Takes a snapshot of IBM Tivoli Workload Scheduler and generates an html report to aid in solving problems. Displays the contents of standard list files. Displays, changes, and adds parameters. Extracts information about parameters. Extracts information about prompts. Extracts information about job streams. Releases units of a resource. Extracts information about resources. Removes standard list files based on age. For UNIX only. Displays information about executing jobs. Starts the Netman process. For UNIX only. Displays version information. Extracts information about cross-references. Extracts information about cross-references.
219
Synopsis
at -v | -u at -sjstream | -qqueuetime-spec batch -v | -u batch [-s jstream]
Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.
-s jstream Specifies the name of a job stream into which the job is submitted. If the job stream does not exist, it is created. The name must start with a letter, and can contain alphanumeric characters and dashes. It can contain up to 16 characters. If the -s and -q arguments are omitted, a job stream name is selected based on the value of the environment variable ATSCRIPT. If ATSCRIPT contains the word maestro, the job stream name will be the first eight characters of the users group name. If ATSCRIPT is not set, or is set to a value other than maestro, the job stream name will be at (for jobs submitted with at), or batch (for jobs submitted with batch). See Other considerations on page 222 for more information about job streams. -qqueue Specifies to submit the job into a job stream with the name queue, which can be a single letter (a through z). See Other considerations on page 222 for more information about job streams. time-spec Specifies the time at which the job will be launched. For at jobs only. The syntax is the same as that used with the UNIX at command.
Usage Notes
After entering at or batch, enter the commands that constitute the job. End each line of input by pressing the Return key. The entire sequence is ended with end-of-file (usually Control+d), or by entering a line with a period (.). Alternatively, use an angle bracket (<) to read commands from a file. See Examples on page 222. Information about at and batch jobs is sent to the master domain manager, where the jobs are added to job streams in the production plan, Symphony. The jobs are launched based on the dependencies included in the job streams.
220
The UNIX shell used for jobs submitted with the IBM Tivoli Workload Scheduler at and batch commands is determined by the SHELL_TYPE variable in the jobmanrc configuration script. Do not use the C shell. For more information, see the IBM Tivoli Workload Scheduler Planning and Installation Guide. Once submitted, jobs are launched in the same manner as other scheduled jobs. Each job runs in the submitting user environment. To ensure that the environment is complete, set commands are inserted into the script to match the variable settings in the users environment. Replacing the UNIX commands: The standard UNIX at and batch commands can be replaced by scheduler commands. The following commands illustrate 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
On tier 2 platforms only, when you install the scheduler through the customize script , the following links are created by default: /usr/bin/mat >TWShome/bin/at /usr/bin/mbatch > TWShome/bin/batch This permits the commands to be run as follows:
/usr/bin/mat /usr/bin/mbatch
The at.allow and at.deny files: The at and batch commands use the files /usr/lib/cron/at.allow and /usr/lib/cron/at.deny to restrict usage. If the at.allow file exists, only users listed in the file are allowed to use at and batch. If the file does not exist, at.deny is checked to see if the user is explicitly denied permission. If neither of the files exists, only the root user is permitted to use the commands. On tier 2 platforms, if the commands are run as mat and mbatch, at.allow and at.deny are ignored, and no restrictions apply. Script files: The commands entered with at or batch are stored in script files. The file are created by the scheduler using the following naming convention: TWShome/atjobs/epoch.sss where: epoch sss The number of seconds since 00:00, 1/1/70. The first three characters of the job stream name.
Note: The scheduler removes script files for jobs that are not carried forward. However, Tivoli recommends that you monitor the disc space in the atjobs directory and remove older files if necessary. Job names: All at and batch jobs are given unique names by the scheduler when they are submitted. The names consist of the users process ID (PID) preceded by the users name truncated so as not to exceed eight characters. The resulting name is upshifted.
221
Other considerations: Tivoli recommends that the job streams into which at and batch jobs are submitted be created beforehand with Composer. The job streams can contain dependencies that determine when the jobs will be launched. At a minimum, the job streams should contain the carryforward keyword. This will ensure that jobs that do not complete, or are not launched, during the current day will be carried forward to the next days production plan. Some other suggestions regarding at and batch job streams: v Include the expression on everyday to have the job streams selected every day. v Use the limit keyword to limit the number of submitted jobs that can be run concurrently. v Use the priority keyword to set the priority of submitted jobs relative to other jobs. If the time value is less than the current time, the value is regarded as for the following day. If the time value is greater than the current time, the value is regarded as for the current day. If the time value is greater than 2400, the value is divided by 2400 to obtain the number of days. If you specify the time value in days, this is added to the value obtained by dividing by 2400. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Examples
To submit a job into job stream sched8 to be launched as soon as possible, run the following command:
batch -s sched8 command <Return> ... <Control d>
To submit a job into job stream k to be launched at 9:45 p.m., run the following command:
at -qk 21h45 command <Return> ... <Control d>
To submit a job to be launched two hours from the time at which the command was entered, run the following command:
at now + 2 hours command <Return> ... <Control d>
If the variable ATSCRIPT is null, the job is submitted into a job stream having the same name as the users group. Otherwise, it is submitted into a job stream named at. To submit a job into job stream sked-mis to be launched at 5:30 p.m., run the following command:
at -s sked-mis 17h30 command <Return> ... <Control d>
The following command is the same as the previous command, except that the jobs commands are read from a file:
at -s sked-mis 17h30 < ./myjob
222
| |
The fact that the commands are read from a file does not change the way they are processed. That is, the commands are copied from the ./myjob file into a script file.
223
caxtract
Extracts information about calendars from the the scheduler database.
Synopsis
caxtract [-v | -u] [-o file]
Arguments
-v -u -o file Displays the command version and exits. Displays command usage information and exits. Specifies the output file. The default is stdout.
Command Output
Each calendar record contains tab-delimited, variable length fields. The fields are described in the following table.
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, run the following command:
caxtract -o cainfo
224
cpuinfo
Returns information from a workstation definition.
Synopsis
cpuinfo -v | -u cpuinfo wkstation [infotype] [...]
Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.
wkstation The name of the workstation. infotype The type of information to display. Specify one or more of the following: os_type Returns the value of the os field: UNIX, WNT,, and OTHER. node port Returns the value of the node field. Returns the value of the port field.
autolink Returns the value of the autolink field: ON or OFF. fullstatus Returns the value of the fullstatus field: ON or OFF. resolvedep Returns the value of the resolvedep field: ON or OFF. host method Returns the value of the access field. server Returns the value of the server field. type Returns the type of workstation: MASTER, MANAGER, FTA, S-AGENT, and X-AGENT. Returns the value of the host field.
time_zone Returns the time zone of the workstation. For an extended agent, the field is blank. version Returns the scheduler version that is running on the workstation. For an extended agent, the field is blank. info Returns the operating system version and workstation model. For an extended agent, the field is blank.
Usage Notes
The values are returned, separated by new lines, in the same order that the arguments were entered on the command line. If no arguments are specified, all applicable information is returned with labels, separated by new lines. | |
Examples
The examples below are based on the following workstation definition:
Chapter 6. Utility commands
225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
end
To print the os type for workstation oak, run the following command:
>cpuinfo oak os_type UNIX
To print the node and port for workstation oak, run the following command:
>cpuinfo oak node port oak.tivoli.com 31111
To print all information for workstation oak, run the following command:
>cpuinfo oak OS TYPE:UNIX NODE:oak.tivoli.com PORT:31111 AUTOLINK:ON FULLSTATUS:ON RESOLVEDEP:ON HOST: METHOD: SERVER: TYPE: FTA TIME ZONE:US/Pacif VERSION:6.1 INFO:SunOS 5.3 Generic 1016 sun4m
226
datecalc
Resolves date expressions and returns dates in desired formats.
Synopsis
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. Displays command usage information and exits.
base-date Specify one of the following: day | date | today | tomorrow | scheddate where: day date Specifies a day of the week. Valid values are: su, mo, tu, we, th, fr, or sa. Specifies a date, in the format element/element[/element], where element is: d[d], m[m], and yy[yy]. If two digits are used for the year (yy), a number greater than 70 is a 20th century date, and a number less than 70 is a 21st century date. Valid values for the month (m[m]) are jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, or dec. The slashes (/) can be replaced by dashes (-), periods (.), commas (,), or spaces. For example, any of the following can be entered for March 28, 1999: 03/28/99 3-28-1999 28.mar.99 99,28,3 mar 28 1999 28 3 99 If numbers are used, it is possible to enter an ambiguous date, for example, 2,7,98. In this case, datecalc uses the date format defined in the scheduler message catalog to interpret the date. If the date does not match the format, datecalc generates an error message. today Specifies the current system date.
tomorrow Specifies the current system date plus one day, or, in the case of time calculations, plus 24 hours. scheddate Specifies the date of the production plan. This may not be the same
Chapter 6. Utility commands
227
as the system date. When used inside jobs within a job stream that is not a carried forward job stream, it returns the date when the job should run, 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, it returns the date when the job should have run, which could be different from the production date of the carried forward job stream if the job has an AT dependency specified. If the AT dependency is used with the following syntax: at=hhmm + n days, the n days are not added to the variable TIVOLI_JOB_DATE and therefore, the datecalc command does not report these days. -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. Specifies 12:00 p.m. (or 1200).
midnight Specifies 12:00 a.m. (or 0000). h[h][[:]mm] Specifies the hour and minute in 12-hour time (if am or pm are used), or 24-hour time. The optional colon (:) delimiter can be replaced by a period (.), a comma (,), an apostrophe (), the letter h, or a space. For example, any of the following can be entered for 8:00 p.m.: 8:00pm 20:00 0800pm 2000 8pm 20 8,00pm 20.00 8\00pm 20 00 zulu Specifies that the time you entered is Greenwich Mean Time (Universal Coordinated Time). datecalc will convert it to the local time.
yyyymmddhhtt Specifies the year, month, day, hour, and minute expressed in exactly twelve digits. For example, for 1999, May 7, 9:15 a.m., enter the following: 199905070915 offset Specifies an offset from base-date in the following format: {[+ | > | - | < number | nearest] | next} day[s] | weekday[s] | workday[s] | week[s] | month[s] | year[s] | hour[s] | minute[s] | day | calendar where:
228
+|>
Specifies an offset to a later date or time. Use + (Plus) on Windows. Use > (Greater than) on UNIX. Be sure to escape the angle bracket (\>). Specifies an offset to an earlier date or time. Use - (Minus) on Windows. Use < (Less than) on UNIX. Be sure to escape the angle bracket (\<). The number of units of the specified type.
-|<
number nearest Specifies an offset to the nearest occurrence of the unit type (earlier or later). next Specifies the next occurrence of the unit type.
day[s] Specifies every day. weekday[s] Specifies every day except Saturday and Sunday. workday[s] Same as weekday[s], but also excludes the dates on the holidays calendar. week[s] Specifies seven days. month[s] Specifies calendar months. year[s] Specifies calendar years. hour[s] Specifies clock hours. minute[s] Specifies clock minutes. day calendar Specifies the entries in a calendar by this name. pic format Specifies the format in which the date and time are returned. The format characters are as follows: m d y j h t ^|/ Month number. Day number. Year number. Julian day number. Hour number. Minute number. One space. Use ^ (carat) on UNIX (this character must be escaped (\) in the Bourne shell). Use / (slash) on Windows. Specifies a day of the week. Valid values are: su, mo, tu, we, th, fr, or sa.
229
You can also include punctuation characters. These are the same as the delimiters used in date and time. If a format is not defined, datecalc returns the date and time in the format defined by the Native Language Support (NLS) environment variables. If the NLS variables are not defined, the native language defaults to C. 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.
Examples
| | To return the next date, from today, on the monthend calendar, run the following command:
>datecalc today next monthend
In the following examples, the current system date is Friday, April 9, 1999.
>datecalc today +2 days pic mm/dd/yy 04/11/99 >datecalc today next tu pic yy\^mm\^dd 99 04 13 >LANG=american;export LANG >datecalc -t 14:30 tomorrow Sat, Apr 10, 1999 02:30:00 PM >LANG=french;datecalc -t 14:30 tomorrow Samedi 10 avril 1999 14:30:00
230
dbexpand
Converts the databases on the master domain manager from non-expanded mode to expanded mode. The command sets the expanded version global option to yes, and makes backup copies of your old database files that you can use to return to non-expanded mode if necessary. If you update your network in stages and it contains workstations running Tivoli Maestro Version 5.x or earlier, you must use non-expanded databases until all of your computers have been updated to Tivoli Maestro 6.x or IBM Tivoli Workload Scheduler. When all of the computers are updated, run dbexpand on the master domain manager to convert the databases to expanded mode.
Synopsis
dbexpand -v | -u dbexpand -n [-b backup-dir ]
Arguments
-v -u -n Specifies not to prompt for a backup directory name. If -b is included, the named directory is used for backup. If -b is not included, the default directory is used. In either case, if the directory exists, it is overwritten. -b backup-dir Specifies a directory in which to backup the database files. The default directory is: TWShome/mozart/mozart.old If -n is omitted and the backup directory already exists, you are prompted for a backup directory name. Displays the command version and exits. Displays command usage information and exits.
Usage Notes
You can run the dbexpand command without stopping the scheduler. However, you cannot submit jobs or job streams into the current production plan until after the new day turnover occurs. For this reason, Tivoli recommends that you run dbexpand shortly before the Jnextday job runs. | | | | | | | | |
Examples
To expand the databases and back up the current files in the /usr/lib/maestro/temp directory, run the following command:
dbexpand -n -b /usr/lib/maestro/temp
If the directory already exists, its contents are overwritten. To expand the databases and back up the current files in the c:\programs\wsched\temp directory, run the following command:
dbexpand -b c:\programs\wsched\temp
231
delete
Removes files. This command is intended to remove standard list files. The users maestro and root on UNIX, and Administrator on Windows can remove any file. Other users can remove only files associated with their own jobs.
Synopsis
delete -v | -u delete filename
Arguments
-v -u filename Specifies the name of the file or group of files to be removed. The name must be enclosed in quotes () if it contains characters other than the following: alphanumerics, dashes (-), slashes (/), backslashes (\), and underscores (_). Wildcard characters are permitted. CAUTION: Use this command carefully. Improper use of wildcard characters can result in removing files accidentally. Displays the command version and exits. Displays command usage information and exits.
Examples
| | To remove all the standard list files for 4/11/04, run the following command:
delete d:\win32app\maestro\stdlist\2004.4.11\@
The following script, included in a scheduled job on UNIX, removes the jobs standard list file if there are no errors:
... #Remove the stdlist for this job: if grep -i error $UNISON_STDLIST then exit 1 else `maestro`/bin/delete $UNISON_STDLIST fi ...
Note that the standard configuration script, jobmanrc, sets the variable UNISON_STDLIST to the name of the job standard list file. For more information about jobmanrc refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide.
232
evtsize
Defines the size of the scheduler event files. This command is used to increase the size of an event file after receiving the message, End of file on events file. You must be maestro or root on UNIX, or Administrator on Windows to run evtsize. Be sure to stop the IBM Tivoli Workload Scheduler engine before running this command.
Synopsis
evtsize -v | -u evtsize filename size evtsize -show filename
Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.
-show filename Queries the current queue length of the specified file. filename The name of the event file. Specify one of the following: Courier.msg Intercom.msg Mailbox.msg pobox/wkstation.msg size | | | | | | | | | | | | | | | | | | | | The maximum size of the event file in bytes. When first built by the scheduler, the maximum size is set to 10 MB.
Examples
To set the maximum size of the Intercom file to 20 MB, run the following command:
evtsize Intercom.msg 20000000
To set the maximum size of the pobox file for workstation chicago to 15 MB, run the following command:
evtsize pobox\chicago.msg 15000000
where:
Chapter 6. Utility commands
233
| | | | | | |
the size of the current queue of the Intercom.msg file the maximum size of the Intercom.msg file the pointer position to read records the pointer position to write records
234
jbxtract
Extracts information about jobs from the scheduler database.
Synopsis
jbxtract [-v | -u] [-j job] [-c wkstat] [-o file]
Arguments
-v -u -j job Displays the command version and exits. Displays command usage information and exits. Specifies the job for which extraction is performed. The default is all jobs.
-c wkstat Specifies the workstation of jobs for which extraction is performed. The default is all workstations. -o file Specifies the output file. The default is stdout.
Command Output
The MAESTRO_OUTPUT_STYLE variable specifies the the output style for long object names. Set the variable to LONG to use full length (long) fields for object names. If the variable is not set or is set to anything other than LONG, long names are truncated to eight characters and a plus sign. For example: A1234567+. Each job record contains tab-delimited, variable length fields. The fields are described in the following table.
Field 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Description workstation name job name job script file name job description recovery job name recovery option (0=stop, 1=rerun, 2=continue) recovery prompt text auto-documentation flag (0=disabled, 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 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 Max Length (bytes) 16 16 4096 65 16 5 64 5 36 36 5 5 8 8 8 8 8 8 8 8
235
Field 21 22 23 24 25
Description maximum elapsed time maximum run date (yymmdd) minimum cpu seconds minimum elapsed time minimum run date (yymmdd)
| | | | |
Examples
To extract information about job myjob on workstation main and direct the output to the file jinfo, run the following command:
jbxtract -j myjob -c main -o jinfo
236
jobinfo
Used in a job script to return information about the job.
Synopsis
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 Returns YES if the job requires confirmation. is_command Returns YES if the job was scheduled or submitted using the docommand construct. job_name Returns the jobs name without the workstation and job stream names. job_pri Returns the jobs priority level. programmatic_job Returns YES if the job was submitted with the scheduler at or batch command. UNIX only. re_job Returns YES if the job is being rerun as the result of a Conman rerun command, or the rerun recovery option. re_type Returns the jobs recovery option (stop, continue, or rerun). rstrt_flag Returns YES if the job is being run as the recovery job. rstrt_retcode If the current job is a recovery job, returns the return code of the parent job. time_started Returns the time the job started executing.
Usage Notes
Job option values are returned, separated by new lines, in the same order they were requested.
237
Examples
1. The script file /jcl/backup is documented 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 determination:
#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 jobs 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 that 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
238
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
jobstdl
Returns the names of standard list files. This command must be run by the user for which IBM Tivoli Workload Scheduler was installed. If you use this command without any parameters, ensure that you are logged on as an IBM Tivoli Workload Scheduler user.
Synopsis
jobstdl -v | -u jobstdl [-day num] [-first | -last | -num n | -all] [-name jstream.job | jobnum]
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 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.
-name jstream.job Specifies the name of the job stream and 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.
Usage Notes
File names are returned in a format suitable for input to other commands. Multiple names are returned separated by a space.
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 mailxhg1.getmail on the current day, run the following command:
jobstdl -first -name mailxhg1.getmail
To return the path name of the standard list for the second run of job mailxhg1.getmail on the current day, run the following command:
jobstdl -num 2 -name mailxhg1.getmail
To return the path names of the standard list files for all runs of job mailxhg1.getmail from three days ago, run the following command:
jobstdl -day 3 -name mailxhg1.getmail
Chapter 6. Utility commands
239
| | | | | | | | | | |
To return the path name of the standard list for the last run of job mailxhg1.getmail from four days ago, run the following command:
jobstdl -day 4 -last -name mailxhg1.getmail
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`
240
maestro
Returns the path name of the scheduler home directory, referred to as TWShome.
Synopsis
maestro [-v | -u]
Arguments
-v -u | | | | | | | | Displays the command version and exits. Displays command usage information and exits.
Examples
To display the scheduler home directory, run the following command:
$ maestro /usr/lib/maestro
To change the directory to the scheduler home directory, run the following command:
$ cd `maestro`
241
makecal
Creates a custom calendar. On UNIX, the Korn shell is required to run this command.
Synopsis
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. IBM 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 put 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 including also the last workday of the month that precedes the date of creation of the calendar. -m -p n Specifies the first and fifteenth days of every month. 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 1999, not 1/10/99. See base-date for datecalc on page 227 for more information about date formats.
242
-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 rather than adding it to the calendar database. Adds the calendar to the calendar database and compiles the production plan (Symphony file). WARNING: This argument re-submits jobs and job streams from the current days production plan. It may be necessary to cancel job streams and jobs.
-x -z
-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. | | | | | | | |
Examples
To make a two-year calendar with the last day of every month selected, run the following command:
makecal -e -i24
To make a calendar with 30 days that starts on May 30, 1999, and has every third day selected, run the following command:
makecal -r 3 -s "30 MAY 1999" -i30
243
metronome.pl
A PERL script that takes a snapshot of IBM Tivoli Workload Scheduler and generates an html report. When a user encounters a problem with the product, this report can aid IBM Tivoli Workload Scheduler customer support.
Usage Notes
Refer to IBM Tivoli Workload Scheduler Troubleshooting and Error Messages for more information about the metronome utility.
244
morestdl
Displays the contents of standard list files. This command must be run by the user for which IBM Tivoli Workload Scheduler was installed. If you use this command without any parameters, ensure that you are logged as an IBM Tivoli Workload Scheduler user.
Synopsis
morestdl -v | -u morestdl [-day num] [-first | -last | -num n | -all] [-name jstream.job | jobnum]
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 Displays all qualifying standard list files. Displays the first qualifying standard list file. Displays the last qualifying standard list file.
-name jstream.job Specifies the name of the job stream and 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. | | | | | | | | | | | | | | |
Examples
To display the standard list file for the first run of job mailxhg1.getmail on the current day, run the following command:
morestdl -first -name mailxhg1.getmail
To display the standard list file for the second run of job mailxhg1.getmail on the current day, run the following command:
morestdl -num 2 -name mailxhg1.getmail
To display the standard list files for all runs of job mailxhg1.getmail from three days ago, run the following command:
morestdl -day 3 -name mailxhg1.getmail
To display the standard list file for the last run of job mailxhg1.getmail from four days ago, run the following command:
morestdl -day 4 -last -name mailxhg1.getmail
To print the standard list file for job number 455, run the following command:
morestdl 455 | lp -p 6
245
parms
Returns the current value of a parameter, changes the value of a parameter, or adds a new parameter.
Synopsis
parms [-v | -u] parms name parms -c name value
Arguments
-v -u name Displays the command version and exits. Displays command usage information and exits. Specifies the name of the parameter whose value is displayed.
-c name value Specifies the name and the value of a parameter. The value can contain up to 72 characters. Quotation marks are required if the value contains special characters. If the parameter does not exist, it is added to the database. If the parameter already exists, its value is changed.
Usage Notes
When parms is run at the command line without arguments, it prompts for parameter names and values. | | | | | | | | | | | | | | |
Examples
To return the value of myparm, run the following command:
parms myparm
To change the value of myparm and add herparm, 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>
246
paxtract
Extracts information about parameters from the scheduler database.
Synopsis
paxtract [-v | -u] [-o file]
Arguments
-v -u -o file Displays the command version and exits. Displays command usage information and exits. Specifies the output file. The default is stdout.
Command Output
Each parameter record contains tab-delimited, variable length fields. The fields are described in the following table.
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, run the following command:
paxtract -o painfo
247
prxtract
Extracts information about prompts from the scheduler database.
Synopsis
prxtract [-v | -u] [-o file]
Arguments
-v -u -o file Displays the command version and exits. Displays command usage information and exits. Specifies the output file. The default is stdout.
Command Output
Each prompt record contains tab-delimited, variable length fields. The fields are described in the following table.
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, run the following command:
prxtract -o prinfo
248
r11xtr
Extracts information about job streams from the scheduler database.
Synopsis
prxtract [-v | -u] [-m mm[yy]] [-c wkstat] [-o file]
Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.
-m mm[yy] Specifies the month (mm) and, optionally, the year (yy) of the job streams. The default is the current month and year. -c wkstat Specifies the workstation of the job streams. The default is all workstations. -o file Specifies the output file. The default is stdout.
Command Output
The MAESTRO_OUTPUT_STYLE variable specifies the the output style for long object names. Set the variable to LONG to use full length (long) fields for object names. If the variable is not set or is set to anything other than LONG, long names are truncated to eight characters and a plus sign. For example: A1234567+. Each job stream record contains tab-delimited, variable length fields. The fields are described in the following table.
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, Mo, Tu, We, Th, Fr, Sa) Max Length (bytes) 16 16 6 6 1 4 2
| | | | | | | |
Examples
To extract information about job streams on June 1999 for workstation main, run the following command:
r11xtr -m 0699 -c main
To extract information about job streams on June of this year for all workstations, and direct the output to file r11out, run the following command:
r11xtr -m 06 -o r11out
249
release
Releases units of a resource at the job stream or job level.
Synopsis
release -v | -u release [-s] [wkstation#]resourcename
Arguments
-v -u -s Displays the command version and exits. Displays command usage information and exits. Releases resource units only at the job stream level. If -s is not used, resource units are released at the job level, or at the job stream level if the resource is not found at the job level. wkstation# Specifies the name of the workstation or workstation class on which the resource is defined. The default is the local workstation. resourcename Specifies the name of the resource.
Usage Notes
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. Units of a resource are released in the same order that they were acquired.
Examples
In the following job stream, two units of the dbase resource are required by 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, the script file for jobrel contains the following command:
`maestro`/bin/release -s dbase
Note that the -s argument can be omitted, since no resources were reserved at the job level. In the following job stream, eight units of the discio resource are required by job2. This is defined in two blocks of 5 and 3 so that they can be released incrementally in the same order they were acquired.
schedule ux1#sked7 on weekdays : job1 job2 follows job1 needs 5 discio,3 discio job3 follows job2 end
250
To release the discio resource incrementally while job2 is executing, the script for job2 contains the following command lines:
... # Release 5 units of discio: `maestro`/bin/release discio ... # Release 3 units of discio: `maestro`/bin/release discio ...
251
rextract
Extracts information about resources from the scheduler database.
Synopsis
rextract [-v | -u] [-o file]
Arguments
-v -u -o file Displays the command version and exits. Displays command usage information and exits. Specifies the output file. The default is stdout.
Command Output
Each resource record contains tab-delimited, variable length fields. The fields are described in the following table.
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, run the following command:
rextract -o reinfo
252
rmstdlist
Removes or displays standard list files based on the age of the file.
Synopsis
rmstdlist -v | -u rmstdlist [-p] [age]
Arguments
-v -u -p Displays the command version and exits. Displays command usage information and exits. Displays the names of qualifying standard list file directories. No directories or files are removed. If you do not specify -p, the qualifying standard list files are removed. The minimum age, in days, of standard list file directories to be displayed or removed. The default is 10 days.
age | | | | | | | |
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 7 days old, run the following command:
rmstdlist 7
253
showexec
Displays the status of executing jobs. For UNIX only. This command is for standard agents. On domain managers and fault-tolerant agents, use the conman showjobs command instead.
Synopsis
showexec [-v | -u | -info]
Arguments
-v -u -info Displays the command version and exits. Displays command usage information and exits. Displays the name of the job file name instead of the user, date, and time.
Command Output
The output of the command is available in two formats: standard, and info. 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 name of the job stream in which the job runs. The job name. The job number. The file name of the job. The workstation on which the job runs. The name of the job stream in which the job runs. The job name. The job number. The user name of the job. The date the job started executing. The time the job started executing. The estimated time, in minutes, that the job will run.
Examples
To display executing jobs in the standard format, run the following command:
showexec
To display executing jobs in the info format, run the following command:
showexec -info
254
StartUp
Starts the scheduler network management process, Netman. You must have start access to the workstation.
Synopsis
StartUp [-v | -u]
Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.
Usage Notes
On Windows, the Netman service is started automatically when a computer is restarted. StartUp can be used to restart the service if it is stopped for any reason. On UNIX, the StartUp command is usually installed in the /etc/rc file, so that Netman is started each time a computer is rebooted. StartUp can be used to restart Netman if it is stopped for any reason. The remainder of the process tree can be restarted with a conman start command. See start on page 198 for more information. | | | | | |
Examples
To display the command name and version, run the following command:
StartUp -v
255
version
Displays scheduler version information. For UNIX only. The information is extracted from a version file.
Synopsis
version/version -V | -u | -h version/version [-a] [-f vfile] [-p product] [file [...]]
Arguments
-V -u -h -a Displays the command version and exits. Displays command usage information and exits. Displays command help information and exits. Displays information about all product files. The default is to display information only about the specified files.
-f vfile Specifies the name of the version file. The default is a file named version.info in the current working directory, or the product directory specified with -p. -p product Specifies the Tivoli product name whose directory is directly below the current working directory, and contains a version.info file. If omitted, -f, or its default, is used. file Specifies the names of product files, separated by spaces, for which version information is displayed. The default is to display no file information, or, if -a is used, all file information.
Command Output
The output header contains the product name, version, platform, patch level, and installation date . The remaining display lists information about the file or files specified. The files are listed in the following format: File Revision Patch Size (bytes) Checksum The name of the file. The revision number of the file. The patch level of the file, if any. The size of the file in bytes. The checksum for the file. Checksums are calculated using the UNIX sum command. On AIX, sum is used with the -o argument.
Usage Notes
IBM Tivoli Workload Scheduler file information is contained in the version.info file. This file is placed in the TWShome/version directory during installation. The version.info file is in a specific format and should not be altered. You can move the version.info file to another directory. However, you must then include the -f argument to locate the file. You can use -p argument if your current directory contains the directories of multiple Tivoli products. This enables you to access version information by specifying the product name.
256
| | | | | | | | | | |
Examples
To display information about all files, run the following command:
version/version -a -f version/version.info
To display information about the file customize, run the following command:
cd version ./version customize
To display information about the file customize, when version.info is located in /apps/maestro, run the following command:
cd version ./version -f /apps/maestro/version.info customize
257
wmaeutil
Used to stop the connector server for the plan, database, and engine. The makesec command will not run successfully on Windows platforms until the connectors are stopped.
Synopsis
UNIX: wmaeutil.sh instance_name [-stop DB | PL | EG | *] [-version DB | PL | EG | *] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop] Windows: wmaeutil.cmd instance_name [-stop DB | PL | EG | *] [-version DB | PL | EG | *] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop]
Arguments
instance_name The name of the scheduler instance. This refers to the instance name you entered during installation of the scheduler engine, and the installation of the connector. -stop DB | PL | EG | * This option can be used to shut down the specified connector server. The (*) asterisk can be used to shut down all three connector servers. If used, it must be enclosed by double quotes. -version DB | PL | EG | * This option is used to obtain the version number of the connector server for the plan, database, engine and installed on the system. The (*) asterisk can be used to obtain versions for all three connector servers at once. If used, it must be enclosed by double quotes. -dbinfo DB | PL This option is used to find out if the scheduler database and plan to which this connector is linked is expanded or non-expanded. With IBM Tivoli Workload Scheduler, Version 8.2, databases and plans are always expanded, but this option exists for backward compatibility. -sethome This option is used to set TWShome attribute of the scheduler objects (Engine, Database, and Plan) in Tivolis object database. This attribute value links connectors for the specified object instance to the core scheduler product. It takes fully qualified name of the scheduler home directory as an arguments. Also the pathname string should be enclosed in quotes in order to prevent any shell interpretation. -gethome This option does not require any arguments and it prints the value of the TWShome attribute for Engine, Database, and Plan object instances as set in the object database. ALL -stop This option stops the connector servers for all scheduler connector instances connected to the current scheduler installation, that is, it stops the connector servers for all instances whose TWShome attribute matches the home directory of the scheduler current installation.
258
Usage Notes
Set environment variables: Before wmaeutil can be run successfully, you must: 1. Set the Tivoli Management Framework environment: On Windows:c:\>%SystemRoot%\system32\drivers\etc\Tivoli\setup_env.cmd On UNIX:$ . /etc/Tivoli/setup_env.sh 2. Set the IBM Tivoli Workload Scheduler environment: On Windows:TWShome\tws_env.cmd On UNIX:TWShome/tws_env.sh for Bourne shells and TWShome/tws_env.csh for C shells. You can update your UNIX profile to run this file, in order to avoid having to run the command manually. Makesec considerations: The wmaeutil command must be run before running the makesec command. The makesec command will not run successfully on Windows platforms until the connectors are stopped. You should also stop the connectors when using the makesec command on UNIX. IBM Tivoli Workload Scheduler instance name: If you do not remember the instance name that was entered at installation, perform the following steps: 1. Source the Tivoli environment variables:
. /etc/Tivoli/setup_env.sh (for UNIX) C:\winnt\system32\drivers\etc\Tivoli\setup_env.cmd (for Windows)
Examples
To stop the connectors for the database, plan, and engine for an instance called maestro, run the following command:
wmaeutil.sh maestro ALL -stop
To stop the connectors for the database for an instance called tws, run the following command:
wmaeutil.sh tws ALL -stop DB
To stop the connector versions for the database, plan, and engine for an instance called maestro2, run the following command:
wmaeutil.sh maestro2 -version *
259
xrxtrct
Extracts information about cross-references from the scheduler database.
Synopsis
xrxtrct [-v | -u]
Arguments
-v -u Displays the command version and exits. Displays command usage information and exits.
Command Output
The MAESTRO_OUTPUT_STYLE variable specifies the the output style for long object names. Set the variable to LONG to use full length (long) fields for object names. If the variable is not set or is set to anything other than LONG, long names are truncated to eight characters and a plus sign. For example: A1234567+. The command output is written to eight files, xdep_job, xdep_sched, xfile, xjob, xprompt, xresources, xsched, and xwhen. xdep_job file: The xdep_job file contains two record types. The first contains information about jobs and job streams that are dependent on a job. Each dependent job and job stream record contains the fixed length fields, with no delimiters. The fields are described in the following table.
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. Each dependent job and job stream record contains fixed length fields, with no delimiters. The fields are described in the following table.
Field 1 2 3 Description 08 workstation name job name Length (bytes) 2 16 120
260
Field 4 5 6 7 8 9 10 11 12
Description 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)
xdep_sched file: The xdep_sched file contains information about job streams that are dependent on a job stream. Each dependent job stream record contains fixed length fields, with no delimiters. The fields are described in the following table.
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. Each record contains fixed length fields, with no delimiters. The fields are described in the following table.
Field 1 2 3 4 5 6 7 8 9 10 Description 07 workstation name file name dependent job stream workstation name dependent job stream name dependent job workstation name dependent job name not used not used not used Length (bytes) 2 16 256 16 16 16 40 6 6 8
Chapter 6. Utility commands
261
Field 11
Length (bytes) 1
xjob file: The xjob file contains information about the job streams in which each job appears. Each job record contains fixed length fields, with no delimiters. The fields are described in the following table.
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. Each prompt record contains fixed length fields, with no delimiters. The fields are described in the following table.
Field 1 2 3 4 5 6 7 8 9 10 11 12 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 not used end-of-record (null) Length (bytes) 2 16 20 236 16 16 16 40 6 6 8 1
xresource file: The xresource file contains information about jobs and job streams that are dependent on a resource. Each resource record contains fixed length fields, with no delimiters. The fields are described in the following table.
Field 1 Description 06 Length (bytes) 2
262
Field 2 3 4 5 6 7 8 9 10 11 12
Description 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)
xsched file: The xsched file contains information about job streams. Each job stream record contains fixed length fields, with no delimiters. The fields are described in the following table.
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. Each job stream record contains the following fixed length fields, with no delimiters. The fields are described in the following table.
Field 1 2 3 4 5 6 7 8 Description 01 workstation name ON/EXCEPT name or date except flag (*=EXCEPT) not used workstation name job stream name not used Length (bytes) 2 16 8 1 247 16 16 8
Chapter 6. Utility commands
263
Field 9 10 11 12 13
Description not used not used offset num offset unit end-of-record (null)
Length (bytes) 8 6 6 8 1
| | | |
Examples
To extract information about all cross-references, run the following command:
xrxtrct
264
Unsupported commands
The following unsupported utility commands provide functions on Windows that are similar to UNIX ps and kill commands. They can be used if similar Windows utilities are not available.
Synopsis
listproc killproc pid
Usage Notes
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.
265
266
Report commands
IBM Tivoli Workload Scheduler report commands are listed in the following table.
Command rep1 rep2 rep3 rep4a rep4b rep7 rep8 rep11 reptr Report 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 11 - 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
Command output
The output of the report commands is controlled by the following variables: MAESTROLP Specifies the destination of the output of a command. The default is stdout. You can set it to any of the following: filename Write the output to a file. > filename UNIX only. Redirect output to a file, overwriting the contents of the file. If the file does not exist it is created. >> filename UNIX only. Redirect output to a file, appending to the end of file. If the file does not exist it is created. | command UNIX only. Pipe output to a system command or process. The system command is always run. || command UNIX only. Pipe output to a system command or process. The system command is not run if there is no output.
267
MAESTRO_OUTPUT_STYLE Specifies the output style for long object names. Set the variable to LONG to use full length (long) fields for object names. If it is not set or it is set to anything other than LONG, long names are truncated to eight characters and a plus sign. For example: A1234567+.
See the IBM Tivoli Workload Scheduler Planning and Installation Guide for details on modifying local variables.
268
Synopsis
rep[x] [-v|-u]
Arguments
x -u -v A number corresponding to the report. The numbers are: 1, 2, 3, 4a, or 4b. Display the command version and exit. Display command usage information and exit.
Examples
Print Report 03, User Calendar Listing:
rep3
On UNIX, print two copies of report 04A, User Parameters Listing, on printer lp2:
MAESTROLP="| lp -dlp2 -n2" export MAESTROLP rep4a
269
rep7 command
This command prints Report 07-Job History Listing.
Synopsis
rep7 -v|-u rep7 [-c wkstat] [-s jstream] [-j job] [-f date -t date] [-l]
Arguments
-u -v Display the command version and exit. Display command usage information and exit.
-c wkstat Specifies the name of the workstation on which the jobs run. The default is all workstations. -s jstream Specifies the name of the job stream in which the jobs run. The default is all job streams. -j job Specifies the name of the job. The default is all jobs.
-f date Specifies to print job history from this date forward. Enter the date as yyyymmdd. The default is the earliest available date. -t date Specifies to print job history up to this date. Enter the date as yyyymmdd. The default is the most recent date. -l Limits the summary line information to the jobs which fall in the date range specified by the -f or -t options. Using this option causes the order of output to be reversed: the job summary line will be printed after the individual job run lines. This option is valid only if you also specify at least one of the -f or -t options.
Examples
Print all job history for workstation ux3:
rep7 -c ux3
Print all job history for all jobs in job stream sked25:
rep7 -s sked25
Print job history for all jobs in job stream mysked on workstation x15 between 1/21/99 and 1/25/99:
rep7 -c x15 -s mysked -f 19990121 -t 19990125
270
rep8 command
This command prints Report 08-Job Histogram.
Synopsis
rep8 -v|-u rep8 [-f date -b time -t date -e time] [-i file] [-p ] rep8 [-b time -e time] [-i file] [-p ]
Arguments
-u -v Display the command version and exit. Display command usage information and exit.
-f date Specifies to print job history from this date forward. Enter the date as yyyymmdd. The default is todays date. -b time Specifies to print job history from this time forward. Enter the time as hhmm. The default is the scheduler start of day time. -t date Specifies to print job history up to this date. Enter the date as yyyymmdd. The default is the most recent date. -e time Specifies to print job history up to this time. Enter the time as hhmm. The default is the scheduler start of day time. -i file Specifies the name of the log file from which job history is extracted. Note that log files are stored in the schedlog directory. The default is the current plan (Symphony file). 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 argument. -p Specifies to insert a page break after each run date.
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.m. on 1/25/99, and ending at 5:59 a.m. on 1/26/99:
rep8 -f 19990125 -b 0600 -t 19990126 -e 0559 -i schedlog/M199801260601
Print a job histogram, from the current plan (Symphony file), beginning at 6:00 am, and ending at 10:00 pm:
rep8 -b 0600 -e 2200
271
rep11 command
This command prints Report 11-Planned Production Schedule.
Synopsis
rep11 -v|-u rep11 [-m mm[yy] [...]] [-c wkstat [...]] [-o file]
Arguments
-u -v Display the command version and exit. Display command usage information and exit.
-m mm[yy] Specifies the months to be reported. Enter the month number as mm. The default is the current month. You can also enter a year as yy. The default is the current year or next year if you specify a month earlier than the current month. -c wkstat Specifies workstations to be reported. The default is all workstations. -o file Specifies the output file. The default is the file defined by the MAESTROLP variable. If MAESTROLP is not set, the default is stdout.
Examples
Report on June, July, and August of 1999 for workstations main, site1 and sagent1:
rep11 -m 0699 0799 0899 -c main site1 sagent1
Report on June, July, and August of this year for all workstations, and direct output to the file r11out:
rep11 -m 06 07 08 -o r11out
272
reptr command
This command prints the following reports: v Report 09A - Planned Production Summary v Report 09B - Planned Production Detail v Report 10A - Actual Production Summary v Report 10B - Actual Production Detail
Synopsis
reptr [-v|-u] reptr -pre [-{summary | detail}] [symfile] reptr -post [-{summary | detail}] [logfile]
Arguments
-u -v -pre -post Display the command version and exit. Display command usage information and exit. Specifies to print the pre-production reports (09A, 09B). Specifies to print the post-production reports (10A, 10B).
-summary Specifies to print the summary reports (09A, 10A). If -summary and -detail are omitted, both sets of reports are printed. -detail Specifies to print the detail reports (09B, 10B). If -summary and -detail are omitted, both sets of reports are printed. symfile Specifies the name of the plan file from which reports will be printed. The default is Symnew in the current directory. logfile Specifies the name of the log file from which the reports will be printed. Note that plan log files are stored in the schedlog directory. The default is the current plan (Symphony file).
If the command is run with no options, all pre and post reports are printed.
Examples
Print the pre-production detail report from the Symnew file:
reptr -pre -detail
Print the post-production summary report from the log file M199903170935:
reptr -post -summary schedlog/M199903170935
The pre-production reports are based on information read from the Symnew file. The post-production reports are based on information read from the Symphony file.
273
xref command
This command prints Report 12-Cross Reference Report.
Synopsis
xref [-V|-U] xref [-cpu wkstat] [-depends|-files|-jobs|-prompts|-resource|-schedules|-when [...]]
Arguments
-U -V Display the command version and exit. Display command usage information and exit.
-cpu wkstat Specifies to print the report for the named workstation. The @ wildcard is permitted, in which case, information from all qualified workstations is included. The default is all workstations. -depends Specifies to print a report showing the job streams and jobs that are successors of each job. -files -jobs Specifies to print a report showing the job streams and jobs that are dependent on each file. 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. -resource Specifies to print a report showing the job streams and jobs that are dependent on each resource. -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, all workstations and all options are selected.
Examples
Print a report for all workstations, showing all cross-reference information:
xref
Print a report for all workstations. Include cross-reference information about all successor dependencies:
xref -cpu @ -depends -schedules
274
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Sample reports
Report 01 Job Details Listing:
TWS for UNIX (SOLARIS)/REPORT1 8.2 (1.8) IBM Page 1 Report 01 Job Details Listing 06/11/03 Job: SUN001 #ACC Description: JCL File : ^ACCHOME^ Logon : ^ACCLOGIN^ Creator: maestro Recovery Job : Recovery Type : STOP Recovery Prompt : Composer Autodoc : Yes Total Runs : 0 - 0 Successful, 0 Aborted Elapsed(mins) CPU(secs) Total 00:00:00 0 Normal 00:00:00 Last Run 00:00:00 0 (On at 00:00) Maximum 00:00:00 0 (On ) Minimum 00:00:00 0 (On )
275
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
276
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
(C) Copyright IBM Corp 1998,2003 US Government User Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contrac TWS for UNIX (SOLARIS)/REPORT11 8.2 (1.5.1.1) IBM Report 11 Planned Production Schedule for JUN 2003 CPU: SUN001 Num Est Cpu 1 2 3 4 5 6 7 12 13 14 15 16 17 18 19 20 26 27 28 29 30 Schedule Jobs Time Sun Mon Tue Wed Thu Fr Wed Thu Fri Sat Sun Mon Tue Wed Thu Wed Thu Fri Sat Sun Mon ACCDAIL+ 1 0 * * * * * * * * * * ACCW01 4 4 * * * * * * * * * * ACCW02 5 3 * * * * * * * * * * ACCW11 3 3 * * * * * * * * * * ACCW12 3 3 * * * * * * * * * * FINAL 1 4 * * * * * * * * * * * * * * * HRSW01 4 0 * * * * * * * * * * HRSW02 5 2 * * * * * * * * * *
277
278
Workstation definition
Each extended agent must have a logical workstation definition. This logical workstation must be hosted by an IBM Tivoli Workload Scheduler physical workstation, either a master, domain manager, FTA, or standard agent. The extended agent workstation definition references the name of the access method and the host workstation. When jobs are launched on the extended agent workstation, the access method is called and passes the job information to the external system.
279
methodname Specifies the file name of the access method. All access methods must be stored in the directory: TWShome/methods -t task Specifies the task to be performed, where task is one of the following: LJ MJ CF GS Launches a job. Manages a previously launched job. Use this option to resynchronize if a prior LJ task terminated unexpectedly. Checks the availability of a file. Use this option to check file opens dependencies. Gets the status of a job. Use this option to check job follows dependencies.
options Specifies the options associated with the task. See Task options for more information. taskstring A string of up to 255 characters associated with the task. See Task options.
Task options
The task options are listed in the following table. An X means that the option is valid for the task.
Task -t 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 Options -d X X -l X X -o X X -j X X X X -q -w -S X ljstring mjstring cfstring gsstring Task String
-c xagent,host,master Specifies the scheduler names of the extended agent, the host, and the master domain manager separated by commas. -n nodename Specifies the node name of the computer associated with the extended agent, if any. This is defined in the extended agents workstation definition Node field. -p portnumber Specifies the TCP port number associated with the extended agent, if any. This is defined in the extended agents workstation definition TCP Address field. -r currentrun,specificrun Specifies the current run number of the scheduler and the specific run number associated with the job separated by a comma. The current and specific run numbers might be different if the job was carried forward from an earlier run. -s jstream Specifies the name of the jobs job stream.
280
-d scheddate,epoch Specifies the schedule date (yymmdd) and the epoch equivalent, separated by a comma. -l user Specifies the jobs user name. This is defined in the job definition Logon field. -o stdlist Specifies the full path name of the jobs standard list file. Any output from the job must be written to this file. -j jobname,id Specifies the jobs name and the unique identifier assigned by the scheduler, separated by a comma. The name is defined in the job definition Job Name field. -q qualifier Specifies the qualifier to be used in a test command issued by the method against the file. -w timeout Specifies the amount of time, in seconds, that the scheduler waits to get a reply on an external job before sending a SIGTERM signal to the access method. The default is 300. -S new name Specifies that the job is rerun using this name in place of the original job name. Within a job script, you can use the jobinfo command to return the job name and run the script differently for each iteration. See the description of the conman rerun command in the IBM Tivoli Workload Scheduler Reference Guide for more information. -- ljstring Used with the LJ task. The string from the Script File or Command field of the job definition. -- mjstring Used with the MJ task. The information provided to the scheduler by the method in a %CJ response to an LJ task. Usually, this identifies the job that was launched. For example, a Unix method can provide the process identification (PID) of the job it launched, which is then sent by the scheduler as part of an MJ task. -- cfstring Used with the CF task. For a file opens dependency, the string from the Opens Files field of the job stream definition. -- gsstring Used with the GS task. Specifies the job whose status is checked. The format is as follows: followsjob[,jobid] where: followsjob The string from the Follows Sched/Job list of the job stream definition. jobid An optional job identifier received by the scheduler in a %CJ response to a previous GS task.
281
JS [cputime] Indicates successful completion of a job and provides its elapsed run time in seconds. RC rc rc is a number that is interpreted by IBM Tivoli Workload Scheduler as the return code of the extended agent job. The return code is taken into account only if a return code condition was specified in the definition of the extended agent job. If this is not the case, it is ignored and the successful completion of the extended agent job is indicated by the presence of message %JS [cputime]. Likewise, if the method does not send the %RC message, then the successful completion of the extended agent job is indicated by the presence of message %JS [cputime].
UT [errormessage] Indicates that the requested task is not supported by the method. Displays a string of up to 255 characters that the scheduler will include in its error message.
282
The file can contain scheduler options and any other method information. The options recognized by the 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 default is the login from the job definition. CFuser=username Specifies the login to use for the CF task. The default is root for Unix, and for Windows it is the user name of the account in which the scheduler was installed. GSuser=username Specifies the login to use for the GS tasks. The default is root for Unix, and for Windows it is the user name of the account in which the scheduler was installed. GStimeout=seconds Specifies the amount of time, in seconds, the scheduler waits for a response before killing the access method. The default is 300 seconds. Note: If the extended agents host is a Windows computer, these users must be defined as scheduler user objects. The options file must have the same path name as its access method, with an .opts file extension. For example, the Windows path name of an options file for a method named netmth is TWShome\methods\netmth.opts.
Method execution
The following topics describe the interchange between IBM Tivoli Workload Scheduler and an access method.
283
PATH For UNIX, it is set to /bin:/usr/bin. For Windows, it is set to %SYSTEM%\SYSTEM32. TZ The time zone.
If the method cannot be run, the job is placed in the fail state. Once a method is running, it writes messages to its stdout that indicate the state of the job on the external system. The messages are summarized in the following table.
Task LJ and MJ Method Response %CJ state [mjstring] %JS [cputime] Exit code=non-zero %UT [errormessage] and Exit code=2 IBM Tivoli Workload Scheduler Action Sets job state to state. Includes mjstring in any subsequent MJ task. Sets job state to succ. Sets job state to abend. Sets job state to abend and displays errormessage.
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. If the job is unsuccessful, the method must exit without writing the %JS message. A method that does not support the LJ task, writes a %UT message to stdout and exits with an exit code of 2.
Killing a job
While an LJ or MJ task is running, the method must trap a SIGTERM signal (signal 15). The signal is sent when an operator issues a Kill command through the scheduler console manager. Upon receiving the signal, the method must attempt to stop (kill) the job and then exit without writing a %JS message.
284
true, the method exits with an exit code of zero. If the file test is false, the method exits with a non-zero exit code. This is summarized in the following table.
Task CF Method Response Exit code=0 Exit code=non-zero %UT [errormessage] and Exit code=2 IBM Tivoli Workload Scheduler Action Set file state to YES. Set file state to NO. Set file state to NO.
A method that does not support the CF task writes a %UT message to stdout and exits with an exit code of 2.
Note that GStimeout in the method options file specifies how long the scheduler will wait for a response before killing the method. See Method options file on page 282 for more information. Method responses are summarized in the following table:
Task GS Method Response %CJ state [jobid] %UT [errormessage] and Exit code=2 IBM Tivoli Workload Scheduler Action Sets job state to state and includes jobid in any subsequent GS task. Job state is unchanged.
A method that does not support the GS task writes a %UT message to stdout and exits with an exit code of 2.
Chapter 8. The Extended Agent reference
285
Troubleshooting
The following topics are provided to help troubleshoot and debug extended agent and access method problems.
This error is not displayed if an extended agent is selected as the result of using wildcard characters.
If an extended agent is defined with an access method but without a host, the following message is displayed:
"Method needs a Host CPU"
Jobman messages
For extended agents, error, warning, and information messages are written to Jobmans stdlist file.
286
When a method sends a message to Jobman that is not recognized, the following message is generated:
Error: message invalid for jobname, #jjobnumber for wkstation using methodname. "first 64 characters of the offending message"
287
288
Overview
A network agent is a logical workstation definition that allows follows dependencies between a local scheduler network and a remote scheduler network. Remote follows dependencies are assigned to jobs and job streams in the same manner as local follows dependencies, except that the network agents name is included to identify that the job or job stream is in an external scheduler network. This type of dependency is called an internetwork dependency. If any job streams with internetwork dependencies are included in the plan, a special job stream named EXTERNAL is created to display the status of these dependencies. This EXTERNAL job stream contains place holder jobs to represent each remote follows dependency. The workstation definition for a network agent contains the name of the network access method, netmth. An options file is used to specify the user under which the method runs, and the rate that the remote job or job stream dependency is checked. This options file must have the same path name as the access method, and must be called netmth.opts. The access method is invoked by the scheduler each time it needs to check the status of a remote job or job stream. The access method queries the remote network for the status of the predecessor job or job stream. The scheduler continues checking until the remote job or job stream reaches the SUCC, CANCL, or ERROR state. You can monitor the status of internetwork dependencies with the Job Scheduling Console by displaying the EXTERNAL job stream.
289
2. Click the engine name. The Properties - Workstation in Database window is displayed. 3. In the Name field, specify a name for this workstation. The workstation name can have up to 16 alphanumeric characters. The name can include a dash and underscore, but must begin with a letter, such as MasterB. 4. In the Node field, specify the node name or the IP address for this workstation. Fully qualified domain names are accepted. This is a required field. 5. In the TCP Port field, enter the port number used by the master domain manager in the remote network. In the example that follows, the port number used by MasterA. 6. In the Operating System field, select OTHER. 7. In the Domain field, specify the domain of the host workstation. 8. In the Time Zone field, specify the time zone of this workstation (optional). 9. In the Description field, specify a description of the workstation. The description can be up to 40 characters long, and must begin with a letter. 10. In the Workstation Type field, select Extended Agent from the pulldown list. 11. Leave the Ignore check box blank. 12. In the Access Method field, enter netmeth. 13. In the Host field, specify the node name of the host workstation (the MasterB hostname in the example) or select one from the list provided by clicking the Workstations button. 14. Click OK. The Network Agent workstation is saved in the MasterB (local network) scheduler database. The following example shows how to define a network agent workstation for a remote network, Network A, that allows local network, Network B, use jobs and job streams in the remote network as follows dependencies.
Remote Network A
Local Network B
MasterA
MasterB
Network Agent
The following steps show how to define a network agent workstation named NetAgent that uses the netmth access method.
290
1. Define MasterA cpu on the MasterA database. The user of this cpu is tws_masterA. 2. Specify the TCP port number for MasterA as 12345. 3. Specify the node for MasterA as MasterA.rome.tivoli.com. 4. Define MasterB cpu on the Master B database. The user of this cpu is tws_masterB. 5. Specify the node for MasterB as MasterB.rome.tivoli.com. The network agent workstation definition is saved in the Master B database.
Options file
An options file must be created to specify the user under which the access method runs, and how often a remote job or job stream dependency is checked. Changes to this file do not take effect until you stop and restart the scheduler. This options file must have the same path name as the access method, and must be called netmth.opts.
TWShome/methods/netmth.opts
Syntax
GSuser=login_name GStimeout=seconds
where: login_name The login used to run the method. If the network agents host is a Windows computer, this user must be defined in the scheduler. seconds The amount of time, in seconds, the scheduler waits for a response before killing the access method. The default is 300 seconds. If the access method is called again it will start up automatically.
291
Internetwork dependencies
Using the Job Scheduling Console, internetwork dependencies are specified in the Job Stream Editor. Use the Add Dependency to Internetwork button to add an Internetwork job icon to the job stream (representing the predecessor) and then create the follows dependency from this icon to any other job using the Add Link button. 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. When remote jobs and job streams are specified as Follows dependencies in local job streams, they are tracked by Conman in a specially created EXTERNAL job stream. Names are generated for the dependencies and they are treated as jobs in the EXTERNAL job stream.
292
v Job internetwork dependency 1. Define a job called jobA on the MasterA database. 2. Define a job called jobB on the MasterB database with a dependency on jobA. Use the composer command line to define the job stream internetwork dependency as follows:
$jobs jobB ...... follows NetAgt::MasterA#jobA end end
See Also
| | For the equivalent Job Scheduling Console task, see Creating Job Streams in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
where: nnn mm ss is a random number. is the current minutes. is the current seconds.
The actual name of the job or job stream is stored in the JCL portion of the job record.
293
All states for jobs and job streams are listed, except FENCE. In addition there are two states that are unique to EXTERNAL jobs: ERROR An error occurred while checking for the remote status. EXTRN Unknown status. An error occurred, a Rerun action was performed on the EXTERNAL job stream, or the INET job or job stream does not exist.
net_dep
294
The Release, Add Dependency, and Delete Dependency actions work the same for internetwork dependencies as they do for other dependencies.
cancel job: Cancel all EXTERNAL jobs for a network agent (the two commands are equivalent):
cj netagt#EXTERNAL.@ cj netagt::@
showjobs;info: Display all the remote dependencies for a network agent with their original names and their scheduler-generated names:
sj netagt#EXTERNAL.@;info
submit: Submit a rm command into the JOBS schedule with a remote schedule as Follows dependency:
sbd "rm apfile";follows=netagt::remote1#rsched
295
See Also
| | For the equivalent Job Scheduling Console task, see Creating Job Streams in the IBM Tivoli Workload Scheduler Job Scheduling Console Users Guide.
296
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Centralizing security
The centralized security global option enables the Tivoli Workload Scheduler administrator to choose between the following two security models: Centralized security The security files of all the workstations in the Tivoli Workload Scheduler network can be created and modified only on the master domain manager, and the Tivoli Workload Scheduler administrator is responsible for their production, maintenance, and distribution. Note: Centralized security is not supported if you are working with IBM Tivoli Workload Scheduler non-expanded databases. Local Security The security file of each workstation can be managed by its root user or administrator. The local user can run the makesec command to create or update the file. Set the centralized security global option to ON for the IBM Tivoli Workload Scheduler master to enable the centralized security mechanism. After the global option is active, the Jnextday utility reloads security-related information in the symphony file. The symphony file also records the option as being turned on. After the master domain manager distributes the symphony file across the network, each workstation has a symphony file containing the same security information. The centralized security mechanism is activated every time a link is established, as well as when an IBM Tivoli Workload Scheduler command is run. In a network with centralized security, two workstations will not be able to establish a connection if one has centralized security turned off in its symphony file or if their security file information does not match. However, a workstation must always accept incoming connections from its domain manager, even if the security file information sent from the domain manager does not match the information in the workstations symphony file. This is enforced to allow the administrator to change the security file on the master without having to redistribute it to the entire network before running Jnextday. Every time a command is run on the workstation of a network with centralized security, either with conman or from the Job Scheduling Console, the security routines verify that the security information in the symphony file matches the information in the local security file. If it does not, no (or reduced) access is granted to IBM Tivoli Workload Scheduler objects and commands and a security violation message is logged.
297
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Centralized security does not apply to IBM Tivoli Workload Scheduler operations for which the symphony is not required. Commands that do not require the symphony file to run use the local security file. For example, the command parms, used to modify or display the local parameters database continues to work according to the local security file, even if centralized security is active and the local security file differs from the centralized security rules. If a workstations security file is deleted and recreated, its security information will not match the information in the security file of the master (that is also recorded in the symphony file). In addition, a mechanism associated with the creation process of the symphony file ensures prevention from tampering with the file.
298
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
. /etc/Tivoli/setup_env.sh
For csh:
source /etc/Tivoli/setup_env.sh
v On Windows
wmaeutil.cmd ALL -stop
User definitions
A user definition defines a set of users, the objects they can access, and the actions they can perform.
Synopsis
[# comment] user def-name user-attributes begin [* comment] object-type [object-attributes] access[=action[,...]] [object-type ... ] [end]
Parameters
[# | *] comment All text following a pound sign or an asterisk and at least one space is treated as a comment. Comments are not copied into the operational Security file installed by the makesec command. def-name Specifies the name of the user definition. The name can contain up to 36 alphanumeric characters and must start with an alphabetic character. user-attributes Specifies one or more attributes that identify the set of users to whom the definition applies. Specify user attributes as follows: user-attribute[{+ | ~}user-attribute[...]] Use a plus sign (+) to add an attribute the user or users must have. Use a tilde (~) to add an attribute the user or users must not have. A user-attribute is defined as: cpu=wkstation|$framework|@ [,...] where:
299
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
wkstation Specifies the workstation on which the user is logged in. Wildcard characters are permitted. The following IBM Tivoli Workload Scheduler variables can be used: $master The user is logged in on the IBM Tivoli Workload Scheduler master domain manager. $remotes The user is logged in on any IBM Tivoli Workload Scheduler standard agent. $slaves The user is logged in on any IBM Tivoli Workload Scheduler fault-tolerant agent. $thiscpu The user is logged in on the IBM Tivoli Workload Scheduler workstation on which the secured program is running. For Job Scheduling Console users, use $framework. $framework Specifies the workstation from which the user is running the Job Scheduling Console. @ Specifies that the user is accessing IBM Tivoli Workload Scheduler with the Job Scheduling Console or is logged in on any IBM Tivoli Workload Scheduler workstation.
group=groupname[,...] For UNIX users only. Do not use this argument for Job Scheduling Console users. Specifies the UNIX group in which the user is a member. Wildcard characters are permitted. logon=username|tme-admin|@ [,...] where: username Specifies the name with which the user is logged in on an IBM Tivoli Workload Scheduler workstation. Wildcard characters are permitted. The cpu= attribute must be set to a workstation name or @. tme-admin Specifies the name of the Tivoli administrators group in which the user is a member. If the name contains spaces, it must be enclosed in double quotation marks. Wildcards are permitted. The cpu= attribute must be set to $framework or @. @ Specifies that the user is logged in with any name or is a member of any Tivoli administrators group.
object-type Specifies the type of object the user is given permission to access. The object types are as follows: calendar User calendars. cpu Workstations and domains.
300
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
IBM Tivoli Workload Scheduler database files. Scheduled jobs. User parameters. Global prompts. Scheduling resources. Job streams. User objects.
You can include multiple object types in a user definition. Omitting an object type prevents access to all objects of that type. object-attributes Table 11 lists object attributes according to the object type.
Table 11. Object attributes Attribute Object calendar cpu file job parameter prompt resource schedule userobj yes no yes yes yes yes yes yes no no yes no yes yes no yes yes yes no no no yes no no no no no no no no yes no no no no yes Name cpu jcl logon
Specifies one or more attributes that identify a set of objects of the specified type. If no attributes are specified, all objects of the specified type are accessible. Specify object attributes as follows: object-attribute[{+ | ~}object-attribute[...]] Use a plus sign (+) to add an attribute that objects must have. Use a tilde (~) to add an attribute that objects must not have. An object-attribute can be any of the following: name=name[,...] Specifies one or more names for the object type. Wildcard characters are permitted. Multiple names must be separated by commas. If this attribute is not specified, all defined objects can be accessed. The following values are relevant to the file object type: calendars Contains calendars. cpudata Contains workstations and domains. jobs Contains jobs. mastsked Contains job streams. parameters Contains parameters. prodsked Contains the production schedule. prompts Contains prompts. resources Contains resources. security The Security file. Symphony Contains the production plan.
301
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 12. Actions
Action Object calendar cpu file job parameter prompt resource schedule useobj yes yes no yes yes yes yes yes yes no no no yes no no no yes no no no no no no no no no yes add adddep altpass
cpu=wkstation[,...] Specifies one or more workstation or domain names. Wildcard characters are permitted. Multiple names must be separated by commas. If omitted, all workstations qualify. The following IBM Tivoli Workload Scheduler variables are permitted: $master, $remotes, $slaves, and $thiscpu. See The variables supplied with the product on page 305 for more information. jcl=path | cmd Specifies the command or the path name of a job objects executable file. The command or path must be enclosed in quotation marks (). Wildcard characters are permitted. If omitted, all job files and commands qualify. logon=username[,...] Specifies the user names. Wildcard characters are permitted. Multiple names must be separated by commas. If omitted, all user names qualify. For the job type object, the following variables are permitted: $jclowner, $owner, and $user. See The variables supplied with the product on page 305 for more information. action Specifies the actions users can perform. Multiple actions must be separated by commas. If none are specified, no actions are permitted. Entering access=@ gives users the ability to perform all actions. Table 12 and Table 13 list all the possible action types according to the object type.
altpri build cancel confirm console deldep delete display fence kill
no no no yes no no no yes no
no no yes no no no no no no
no no no yes no no no yes no
no no no yes no no no no no
no yes no no no no no no no
no no no yes no no no yes no
no yes no no no no no no no
no no no no no no no no no
Notes: 1. The object type file is used to manage security on the CLI and is only valid for the CLI.
302
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
2. For the file object type, the clean action is equivalent to the build action. 3. To permit a user to switch the domain manager function to a workstation, the user must have both start and stop access to the workstation. add adddep Add and save new calendars in the database. Add dependencies to jobs in the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. Alter user passwords in the database. Alter the priority of jobs in the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. Build IBM Tivoli Workload Schedulers database files. This action is only available from the command line. The key clean that appears in the security file for this object is equivalent to the build key. Cancel jobs in the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. Confirm the completion of jobs in the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. View and alter the IBM Tivoli Workload Scheduler console. Delete dependencies from jobs in the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. Delete calendars from the database. Display calendars in the database. Alter workstation job fences in the production plan. Kill jobs in the production plan. Alter workstation job limits in the production plan. Open workstation links.
Chapter 10. Setting User Security Definitions
altpass altpri
build
cancel
confirm
console deldep
303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
list
Allows the user to display workstations and domains in the plan when running a Job Scheduling Console query or a conman show command. Modify calendars in the database. Release jobs from their dependencies in the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. Reply to job prompts in the production plan. Rerun jobs in the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. Shut down IBM Tivoli Workload Scheduler processing. This action is only available in the command line. Start IBM Tivoli Workload Scheduler processing. Stop IBM Tivoli Workload Scheduler processing. Submit jobs into the production plan. This action is not available on workstations connected to IBM Tivoli Workload Scheduler for z/OS for end-to-end scheduling. Close workstation links. Use calendars to schedule job streams.
modify release
reply rerun
shutdown
unlink use
304
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
#First User Definition in the Security File USER First CPU=@+LOGON=TWSDomain/TWSUser Begin ... End #Second User Definition in the Security File USER Second CPU=@+LOGON=TWSUser Begin ... End
The variables $jclgroup and $jclowner can only be verified if the user is running an IBM Tivoli Workload Scheduler program on the workstation where the jobs executable file resides. If the program is being run on a different workstation, the user is denied access.
Chapter 10. Setting User Security Definitions
305
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Wildcard characters
Where noted in the syntax descriptions, the following wildcard characters are permitted: ? % @ Replaces one alphanumeric character. Replaces one numeric character. Replaces zero or more alphanumeric characters.
Access capabilities
The following table lists the available access keywords for each object type, and the capabilities given to users in the Tivoli Workload Scheduler command line.
Object Type calendar Access Keyword add delete display modify use cpu (Includes domains) add console delete display list fence limit link modify shutdown start stop unlink file build delete display modify CLI User Capability na na composer display, create na (see file modify) composer - use calendar in schedules composer add, new conman console composer delete composer display, create conman showcpus conman fence conman limit conman link composer modify, replace conman shutdown conman start conman stop conman unlink composer build na Access Security with dumpsec Access Security with makesec and composer modify calendars, parameters, prompts, and resources
306
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Access Keyword add adddep altpri cancel confirm deldep delete display list kill modify release reply rerun submit use
CLI User Capability composer add, new conman adddep conman altpri conman cancel conman confirm conman deldep composer delete conman display composer display conman showjobs conman kill composer modify, replace conman release conman reply conman rerun conman submit (docommand, file, job) composer - use job in schedule parms to add parameters na composer display, create and parms to display parameters na (see also file modify) na na composer display, create conman recall conman showprompts na (see file modify) conman reply composer - use prompt in job stream, and conman - add dependencies na na composer display, create conman showresources na (see file modify) conman resource composer - use resource in job stream, and conman - add dependencies
parameter
prompt
resource
307
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Access Keyword add adddep altpri cancel deldep delete display list limit modify release reply submit
CLI User Capability composer add, new conman adddep conman altpri conman cancel conman deldep composer delete composer display, create conman display conman showschedules conman limit composer modify, replace conman release conman reply conman submit sched composer add, new composer delete composer display (password not displayed) composer modify conman altpass
userjob
end ########################################################### # (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY # WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.
308
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
user sm logon=maestro,root begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------- --------------------------------job cpu=$thiscpu access=@ schedule cpu=$thiscpu access=@ resource cpu=$thiscpu access=@ prompt access=@ file access=@ calendar access=@ cpu cpu=$thiscpu access=@ parameter cpu=$thiscpu ~ name=r@ access=@ end ########################################################### # (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE # MASTER DOMAIN MANAGER OR FRAMEWORK. user masterop cpu=$master,$fw + group=sys begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------- --------------------------------job cpu=@ + logon=TWSDomain\TWSUser access=@ job cpu=@ + logon=root access=adddep,altpri,cancel, confirm,deldep,release, reply,rerun,submit,use job cpu=@ + logon=$user,$jclowner ~ logon=root access=add,adddep,altpri, cancel,confirm, deldep,release,reply, rerun,submit,use schedule cpu=$thiscpu access=@ schedule cpu=@ access=adddep,altpri,cancel, deldep,limit,release, submit resource access=add,display, resource,use prompt access=add,display,reply,use file access=build calendar access=display,use cpu cpu=@ access=@ parameter name=@ ~ name=r@ access=@ 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 # ---------- --------------------------------job cpu=$thiscpu + logon=$user access=@ job cpu=$thiscpu + logon=root access=adddep,altpri,cancel, confirm,deldep,release, reply,rerun,submit,use job cpu=$thiscpu ~ logon=root access=adddep,altpri,cancel, confirm,deldep,release, reply,rerun,submit,use schedule cpu=$thiscpu access=@ resource access=add,display,resource,use prompt access=add,display,reply,use file access=build calendar access=use
Chapter 10. Setting User Security Definitions
309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
cpu=$thiscpu
########################################################### # (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON # ANY WORKSTATION OR FRAMEWORK. user misusers group=mis begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------- --------------------------------job cpu=$thiscpu + logon=$user access=@ job cpu=$thiscpu + logon=$jclowner ~ logon=root access=submit,use schedule cpu=$thiscpu access=add,submit, modify,display parameter name=r@ access=@ parameter name=@ access=display end ########################################################### # (6) APPLIES TO ALL OTHER USERS LOGGED IN ON ANY # WORKSTATION. user default logon=@ begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # ---------- --------------------------------job cpu=$thiscpu + logon=$user access=@ job cpu=$thiscpu + logon=$jclowner ~ logon=root access=submit,use schedule cpu=$thiscpu access=add,submit, modify,display parameter name=u@ access=@ parameter name=@ ~ name=r@ access=display end ###########################################################
Note that the order of definitions is from most to least specific. Because of the order, maestro and root users are matched first, followed by users in the sys group, and then users in the mis group. All other users are matched with the last definition, which is the least specific. # (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE MASTER DOMAIN MANAGER OR FRAMEWORK. user mastersm cpu=$master,$fw + logon=maestro,root,Root_london-region This user definition applies to GUI and CLI access for maestro and root users logged into a master domain manager. It also gives GUI access to users listed in the Root_london-region Tivoli administrators group. They are given unrestricted access to all objects, except parameters that have names beginning with r. Access to the r parameters is given only to users in the mis group. # (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user sm logon=maestro,root This user definition applies to maestro and root users to whom definition (1) does not apply, which are those who are logged in on any workstation other than the
310
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
master domain manager or a Framework computer. They are given unrestricted access to all objects on their login workstation. Note that prompts, files, and calendars are global in nature and are not associated with a workstation. # (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE MASTER DOMAIN MANAGER OR FRAMEWORK. user masterop cpu=$master,$fw + group=sys This user definition applies to users logged into the sys group on the master domain manager or a Framework computer. They are given a unique set of access capabilities. Multiple object statements are used to give these users specific types of access to different sets of objects. For example, there are three job statements: v The first job statement permits unrestricted access to jobs that run on any workstation (@) under the users name ($user). v The second job statement permits specific types of access to jobs that run on any workstation and that run as root. v The third job statement permits specific types of access to jobs that run on any workstation. The jobs must run under the users name ($user) or under the name of the owner of the job file ($jclowner). Jobs that run as root are excluded. # (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user op group=sys This user definition applies to sys group users to whom definition (3) does not apply, which are those who are logged in on any workstation other than the master domain manager or a Framework computer. They are given a set of access capabilities similar to those in definition (3). The exception is that access is restricted to objects on the users login workstation ($thiscpu). # (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON ANY WORKSTATION OR FRAMEWORK. user misusers group=mis This user definition applies to users logged into the mis group on any workstation or a Framework computer. They are given a limited set of access capabilities. Resources, prompts, files, calendars, and workstations are omitted, which prevents access to these objects. These users are given unrestricted access to parameters with names that begin with r, but can only display other parameters. # (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). These users are given unrestricted access to parameters with names that begin with u, but can only display other parameters. No access is permitted to parameters with names that begin with r.
311
| | | | | | | | | | | | | | | | | | | | | | | | | | |
dumpsec
Decompiles the Security file and sends the output to stdout. The user must have display access to the Security file.
Synopsis
dumpsec -v | -u dumpsec security-file
Description
If no arguments are specified, the operational Security file (TWShome/Security.conf) is dumped. To create an editable copy of a Security file, redirect the output of the command to another file, as shown in the examples below.
Arguments
-v -u Displays command version information only. Displays command usage information only.
Examples
The following command displays the command version:
dumpsec -v
The following command dumps the operational Security file to a file named mysec:
dumpsec > mysec
312
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
makesec
Compiles user definitions and installs the security file. Changes to the security file will be recognized when one of the following programs is stopped and restarted: Conman Simply exit and run again. Composer Simply exit and run again. IBM Tivoli Workload Scheduler connectors Stop the connectors by running the wmaeutil command. The connectors will automatically be restarted with the first query refresh on the Job Scheduling Console. To use the makesec command, you must have the modify access type to the security file.
Synopsis
makesec -v | -u makesec [-verify] in-file
Description
The makesec command compiles the specified file and installs it as the operational Security file (../TWShome/Security). If the -verify argument is specified, the file is checked for correct syntax, but it is not compiled and installed.
Arguments
-v -u -verify Checks the syntax of the user definitions in in-file only. The file is not installed as the Security file. (Syntax checking is performed automatically when the Security file is installed.) in-file Specifies the name of a file or set of files containing user definitions. A file name expansion pattern is permitted. Displays command version information only. Displays command usage information only.
Examples
The following command displays the command version:
makesec -v
The following command creates an editable copy of the operational Security file in a file named tempsec; modifies the user definitions with a text editor; then compiles tempsec and replaces the operational Security file:
dumpsec > tempsec edit tempsec
Here you make any required modifications to the tempsec file. When you have finished modifying the tempsec file, run the makesec command to load the security file into IBM Tivoli Workload Scheduler:
makesec tempsec
Chapter 10. Setting User Security Definitions
313
| | | |
The following command compiles user definitions from the file set userdef* and replaces the operational Security file:
makesec userdef*
314
315
Obtaining fixes
A product fix might be available to resolve your problem. You can determine what fixes are available for your IBM software product by checking the product support Web site: 1. Go to the IBM Software Support Web site (http://www.ibm.com/software/support). 2. Under Products A - Z, select your product name: select I for IBM and then scroll down to the product entries that commence IBM Tivoli Workload Scheduler. These open product-specific support sites. 3. Under Self help, follow the link to Search all Downloads, where you will find a list of fixes, fix packs, and other service updates for your product. 4. Click the name of a fix to read the description and optionally download the fix. To receive weekly e-mail notifications about fixes and other news about IBM products, follow these steps: 1. From the support page for any IBM product, click My support in the panel on the left of the page. 2. If you have already registered, skip to the next step. If you have not registered, click register in the upper-right corner of the support page to establish your user ID and password. 3. Sign in to My support. 4. On the My support page, select the Edit profile tab and click Subscribe to email. Select a product family and check the appropriate boxes for the type of information you want. 5. Click Update. 6. For e-mail notification for other product groups, repeat Steps 4 and 5. For more information about types of fixes, see the Software Support Handbook (http://techsupport.services.ibm.com/guides/handbook.html).
316
IBM sales representative or an IBM Business Partner. For more information about support for eServer software products, go to the IBM Technical Support Advantage Web page (http://www.ibm.com/servers/eserver/techsupport.html). If you are not sure what type of software maintenance contract you need, call 1-800-IBMSERV (1-800-426-7378) in the United States or, from other countries, go to the contacts page of the IBM Software Support Handbook on the Web (http://techsupport.services.ibm.com/guides/contacts.html) and click the name of your geographic region for phone numbers of people who provide support for your location. Follow the steps in this topic to contact IBM Software Support: 1. Determine the business impact of your problem. 2. Describe your problem and gather background information. 3. Submit your problem to IBM Software Support.
317
v By phone: For the phone number to call in your country, go to the contacts page of the IBM Software Support Handbook on the Web (http://techsupport.services.ibm.com/guides/contacts.html) and click the name of your geographic region. If the problem you submit is for a software defect or for missing or inaccurate documentation, IBM Software Support creates an Authorized Program Analysis Report (APAR). The APAR describes the problem in detail. Whenever possible, IBM Software Support provides a workaround for you to implement until the APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the IBM product support Web pages daily, so that other users who experience the same problem can benefit from the same resolutions. For more information about problem resolution, see Searching knowledge bases and Obtaining fixes.
318
| | | | | | | | | | | | | | | | |
6 am
Start of Day
3h
Start of Day
Dead zone 3 am
Figure 8. Dead zones
Dead zone 3 am
| | | | | | | | | | |
319
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
For more details on how to enable the time zone feature, refer to the IBM Tivoli Workload Scheduler Planning and Installation Guide.
Running a job stream not time zoneenabled when the master domain manager is ahead of the fault-tolerant agent
This section shows the job stream definition statement to run a job stream every weekday morning on a Pacific Standard Time (PST) fault-tolerant agent connected to an Eastern Standard Time (EST) master domain manager with a start of day of 0600 a.m., if you do not enable the time zone feature. To run the job stream every weekday morning you must schedule it to run Sunday through Thursday, and specify the carryforward and the at keywords as follows:
Schedule FTA# PST_SCHEDULE1 On SU, weekdays except FR CARRYFORWARD AT 0330 . . job1 job2 END
If you do not specify the carryforward keyword, the job would never run because the fault-tolerant agent would be initialized at 0300 a.m. every day.
Running a job stream time zoneenabled when the master is ahead of the fault-tolerant agent
This section shows the job stream definition statement to run a job stream every weekday morning on a PST fault-tolerant agent connected to an EST master domain manager with a start of day of 0600 a.m., if you enable the time zone feature. To run a job stream every weekday morning you must schedule it to run every weekday by specifying the at keyword as follows:
Schedule FTA# PST_SCHEDULE2 On weekdays AT 0330 . . job1 job2 END
When the EST master domain manager initializes the PST fault-tolerant agent at 0300 a.m., the fault-tolerant agent starts the job stream the same day at 0300 a.m.
Running a job stream not time zoneenabled when the master domain manager is behind the fault-tolerant agent.
This section shows the job stream definition statement to run a job stream every weekday morning on an EST fault-tolerant agent having a PST master domain manager with a 0600 a.m. start of day, if you do not enable the time zone feature. To run the job stream every weekday morning, you must schedule it to run Sunday through Thursday, and specify the carryforward keyword and +1DAY for the at keyword as shown in the following job stream definition statement:
Schedule FTA1#EST_SCHEDULE1 On SU, weekdays except FR AT 0800 + 1 DAY CARRYFORWARD .
320
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
You need to specify the carryforward keyword because otherwise the job stream is not selected to be included in the plan that runs on the following day. Without the +1DAY specification, the job stream would launch immediately after initialization from the western master at 0900 a.m..
Running a job stream time zoneenabled when the master domain manager is behind the fault-tolerant agent.
This section shows the job stream definition statement to run a job stream every weekday morning on an EST fault-tolerant agent having a PST master with a start of day of 0600 a.m., if you enable the time zone feature. To run the job stream every weekday morning, specify the following job stream definition statement:
Schedule FTA1#EST_SCHEDULE2 On SU, weekdays except FR AT 0800 . . job1 job2 END
When the eastern fault-tolerant agent is initialized at 0900 a.m., it runs the job stream at 0800 a.m. the next day.
To submit the SCHED1 job stream with a PST at dependency, run the following Conman command on the master domain manager:
sbs FTA1#SCHED1 ;at=0400 TZ PST
The master domain manager converts the submission time for example, 2:00 p.m. ECT to the time zone (PST) you specified in the command. The master domain manager then compares the value specified in the at keyword with the resulting value: v If the at dependency value is later than or the same as the resulting value, the schedule runs on the same day. v If the at dependency value is earlier than or the same as the resulting value, the schedule runs on the following day. The date obtained and the time specified in the command (4:00 a.m. PST) are now converted by the master domain manager from the time zone (PST) specified in the command into the time zone specified on the FTA1 workstation.
Appendix B. Managing time zones
321
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Submitting a job stream specifying an at dependency that occurs during daylight saving time
This section shows how to submit a job stream specifying an at dependency that occurs during daylight saving time. Consider a master domain manager defined in time zone ECT (GMT+1:00). The date is April, 3 2005. On this date, time zone ECT is already on daylight saving time and therefore GMT+2:00. You submit a job stream with at dependency related to time zone PST (GMT-8:00):
Schedule MDM#SCHED1 AT 0230 TZ PST . . job1 job2 END
In the time zone PST on the April, 3 2005 at 2:00 a.m. there is a change from standard time to daylight saving time (DST), therefore the time is moved ahead to 3:00 a.m. and the time zone changes from GMT-8:00 to GMT-7:00. The master domain manager converts the AT 0230 TZ PST time dependency to the time zone of the fault-tolerant agent where the job stream must run, which in this case is the time zone of the master domain manager itself (ETC). All time dependencies between AT 0200 TZ PST and AT 0259 TZ PST are translated to ECT 1159 because all minutes in the time zone PST match with only one minute in the time zone ECT. Outside this range of time dependencies, any dependency is converted following the standard conversion rules. For example, a time dependency of AT 0300 TZ PST is converted to ECT 1200. A time dependency of AT 0301 TZ PST is converted to ECT 1201, and so on.
322
| | | | | | | | | | | | | | | | | |
Name NST MIT HST AST PST PNT MST CST EST IET PRT CNT AGT BET CAT
Description 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+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
323
324
Audit files are logged to a flat text file on individual machines in the IBM Tivoli Workload Scheduler network. This minimizes the risk of audit failure due to network issues and enables a straightforward approach to writing the log. The log formats are the same for both plan and database in a general sense. The logs consist of a header portion which is the same for all records, an action ID, and a section of data which will vary according to the action type. All data is kept in clear text and formatted to be readable and editable from a text editor such as vi or notepad. Note: For modify commands, two entries are made in the log for resources, calendars, parameters and prompts. The modify command is displayed in the log as the delete and add commands.
A value of 1 enables auditing and a value of 0 disables auditing. IBM Tivoli Workload Scheduler currently defaults to 0, or auditing disabled. If these options are not present in the globalopts file, auditing is disabled. Auditing is disabled by default on installation of the product. To initiate database auditing, you must shut down IBM Tivoli Workload Scheduler completely and use the wmaeutil command to stop the connector instance. When you restart IBM Tivoli Workload Schedulerand the connector instance, the database audit log is initiated. Plan auditing takes effect when Jnextday is run.
325
Log Type|GMT Date|GMT Time|Local Date|Local Time|Object Type|Action Type|Workstation Name|User ID|Framework User|Object Name|Action Data fields
The log files contain the following information: Log Type This field displays an eight character value indicating the source of the log record. The following log types are supported: HEADER The log file header CONMAN conman command text FILEAID Command that opens a file PLAN Plan action STAGEMAN stageman run RELEASE release command text DATABASE Database action PARMS Parameter command text MAKESEC makesec run DBEXPAND dbexpand run GMT Date This field displays the GMT date the action was performed. The format is yyyymmdd where yyyy is the year, mm is the month, and dd is the day. GMT Time This field displays the GMT time the action was performed. The format is hhmmss where hh is the hour, mm is the minutes, and ss is the seconds. Local Date This field displays the local date the action was performed. The local date is defined by the time zone option of the workstation. The format is yyyymmdd where yyyy is the year, mm is the month, and dd is the day. Local Time This field displays the local time the action was performed. The local time is defined by the time zone option of the workstation. The format is hhmmss where hh is the hour, mm is the minutes, and ss is the seconds. Object Type This field displays the type of the object that was affected by an action. The object type is one of the following: DATABASE Database definition
326
DBWKSTN Database workstation definition DBWKCLS Database workstation class definition DBDOMAIN Database domain definition DBUSER Database user definition DBJBSTRM Database job stream definition DBJOB Database job definition DBCAL Database calendar definition DBPROMPT Database prompt definition DBPARM Database parameter definition DBRES Database resource definition DBSEC Database security PLAN Plan PLWKSTN Plan workstation PLDOMAIN Plan domain PLJBSTRM Plan job stream PLJOB Plan job PLPROMPT Plan prompt PLRES Plan resource PLFILE Plan file Action Type This field displays what action was taken against the object. The appropriate values for this field are dependent on the action being taken. For the database, the Action Type can be ADD, DELETE, MODIFY, EXPAND, or INSTALL. IBM Tivoli Workload Scheduler will record ADD, DELETE and MODIFY actions for workstation, workstation classes, domains, users, jobs, job streams, calendars, prompts, resources and parameters in the database. The Action Type field also records the installation of a new security file. When makesec is run IBM Tivoli
Appendix C. The auditing feature
327
Workload Scheduler will record it as INSTALL action for a Security definition object. When dbexpand is run it will be recorded as a EXPAND action for DATABASE object. LIST and DISPLAY actions for objects are not logged. For fileaid IBM Tivoli Workload Scheduler will only log the commands that result in the opening of a file. For parameters, the command line with arguments is logged. Workstation Name This field displays the IBM Tivoli Workload Scheduler workstation from which the user is performing the action. User ID This field displays the logon user who performed the particular action. On Win32 platforms it will be the fully qualified domain name domain\user. Framework User This field displays the Tivoli Framework recognized user ID. This is the login ID of the Job Scheduling Console user. Object Name This field displays the fully qualified name of the object. The format of this field will depend on the object type as shown here: DATABASE N/A DBWKSTN workstation DBWKCLS workstation_class DBDOMAIN domain DBUSER [workstation#]user DBJBSTRM workstation#jobstream DBJOB workstation#job DBCAL calendar DBPROMPT prompt DBPARM workstation#parameter DBRES workstation#resource DBSEC N/A PLAN N/A PLWKSTN workstation
328
PLDOMAIN domain PLJBSTRM workstation#jobstream_instance PLJOB workstation#jobstream_instance.job PLPROMPT [workstation#]prompt PLRES workstation#resource PLFILE workstation#path(qualifier) Action Dependent Data This field displays the action-specific data fields. The format of this data is dependent on the Action Type field.
329
330
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents.You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
331
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.
Trademarks
IBM, the IBM logo, z/OS, Tivoli, the Tivoli logo are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Microsoft and Windows NT are registered trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names might be trademarks or service marks of others.
332
Glossary A
Access method. An access method is an executable used by extended agents to connect and control job execution on other operating systems (for example, MVS) and applications (for example, Oracle Applications, Peoplesoft, and Baan). The access method must be specified in the workstation definition for the extended agent. Deadline. The last moment in time that a job or job stream can begin execution. This corresponds to the Until time in legacy Maestro. Dependency. A dependency is a prerequisite that must be satisfied before the execution of a job or job stream can proceed. The maximum number of dependencies permitted for a job or job stream is 40. The four types of dependencies used by Tivoli Workload Scheduler are follows dependencies, resource dependencies, file dependencies, and prompt dependencies. Domain. A domain is a named group of Tivoli Workload Scheduler workstations consisting of one or more agents and a domain manager acting as the management hub. All domains have a parent domain except for the master domain. Domain Manager. The management hub in a Tivoli Workload Scheduler domain. All communications to and from the agents in the domain are routed through the domain manager. Duration. The time you expect the job to take to complete. In the Timeline view of jobs in the database, the duration is represented by a light blue bar at the center of the activity bar or by a light blue diamond.
B
Batchman. Batchman is a process started at the beginning of each Tivoli Workload Scheduler processing day to launch jobs in accordance with the information in the Symphony file.
C
Calendar. A calendar is a defined object in the Tivoli Workload Scheduler database that contains a list of scheduling dates. Because it is a unique object defined in database, it can be assigned to multiple job streams. Assigning a calendar to a job stream causes that job stream to be run on the days specified in the calendar. Note that a calendar can be used as an inclusionary or exclusionary run cycle. Conman. Conman (console manager) is a legacy command-line application for managing the production environment. Conman performs the following tasks: start and stop production processes, alter and display schedules and jobs in the plan, and control workstation linking in a network. Composer. Composer is a legacy command-line application for managing the definitions of your scheduling objects in the database.
E
Earliest start time. The time before which the job or job stream cannot start. The earliest start time is an estimate based on previous experiences running the job or job stream. However, the job or job stream can start after the time you specify as long as all other dependencies are satisfied. In the timeline, the start time is represented by the beginning (left edge) of the navy blue activity bar. For job instances, the start time that OPC calculates is represented by a light blue bar. See also Actual start time and Planned start time. Exclusionary run cycle. A run cycle that specifies the days a job stream cannot be run. Exclusionary run cycles take precedent over inclusionary run cycles. Expanded database. Expanded databases allow longer names for database objects such as jobs, job streams, workstations, domains, and users. Expanded databases are configured using the dbexpand command or as an option during installation. Do not expand your database before understanding the implications and impact of this command. Extended agent. Extended agents are used to integrate Tivoli Workload Schedulers job control features with
D
Database. The database contains all the definitions you have created for scheduling objects (for example, jobs, job streams, resources, workstations, etc). In addition, the database holds other important information such as statistics of job and job stream execution, information on the user ID who created an object, and an objects last modified date. In contrast, the plan contains only those jobs and job streams (including dependent objects) that are scheduled for execution in todays production.
333
other operating systems (for example, MVS) and applications (for example, Oracle Applications, Peoplesoft, and Baan). Extended agents use scripts called access methods to communicate with external systems. External job. A job from one job stream that is a predecessor for a job in another job stream. An external job is represented by a place holder icon in the Graph view of the job stream.
Internetwork (INET) dependencies. A dependency between jobs or job streams in separate Tivoli Workload Scheduler networks. See also Network agent. Internetwork (INET) job / job stream. A job or job stream from a remote Tivoli Workload Scheduler network that is a predecessor to a job or job stream in the local network. An Internetwork job is represented by a place holder icon in the Graph view of the job stream. See also Network agent.
F
Fault-tolerant agent. An agent workstation in the Tivoli Workload Scheduler network capable of resolving local dependencies and launching its jobs in the absence of a domain manager. Fence. The job fence is a master control over job execution on a workstation. The job fence is a priority level that a job or job streams priority must exceed before it can run. For example, setting the fence to 40 prevents jobs with priorities of 40 or less from being launched. Final Job Stream. The FINAL job stream should be the last job stream that is run in a production day. It contains a job that runs the script file Jnextday. Follows dependency. A dependency where a job or job stream cannot begin execution until other jobs or job streams have completed successfully.
J
Jnextday job. Pre- and post-production processing can be fully automated by scheduling the Jnextday job to run at the end of each day. A sample jnextday job is provided as TWShome\Jnextday. The Jnextday job does the following: sets up the next days processing (contained in the Symphony file), prints reports, carries forward unfinished job streams, and stops and restarts Tivoli Workload Scheduler. Job. A job is a unit of work that is processed at a workstation. The job definition consists of a unique job name in the Tivoli Workload Scheduler database along with other information necessary to run the job. When you add a job to a job stream, you can define its dependencies and its time restrictions such as the estimated start time and deadline. Job Instance. A job scheduled for a specific run date in the plan. See also Job. Job status. See Status. Job Stream. A Job Stream consists of a list of jobs that run as a unit (such as a weekly backup application), along with times, priorities and other dependencies that determine the exact order of job execution. Job stream instance. A job stream that is scheduled for a specific run date in the plan. See also Job stream.
G
Global options. The global options are defined on the master domain manager in the globalopts file, and these options apply to all workstations in the Tivoli Workload Scheduler network. See also Local options.
H
Host. A Workload Scheduler workstation required by extended agents. It can be any Tivoli Workload Scheduler workstation except another extended agent.
L
Limit. Job limits provide a means of allocating a specific number of job slots into which Tivoli Workload Scheduler is allowed to launch jobs. A job limit can be set for each job stream, and for each workstation. For example, setting the workstation job limit to 25 permits Tivoli Workload Scheduler to have no more than 25 jobs executing concurrently on the workstation. List. A list displays job scheduling objects. You must create separate lists for each job scheduling object. For each job scheduling object, there are two types of lists: one of definitions in the database and another of instances in the plan.
I
Inclusionary Run Cycle. A run cycle that specifies the days a job stream is scheduled to run. Exclusionary run cycles take precedent over inclusionary run cycles. Interactive jobs. A job that runs interactively on a Windows NT desktop. Internal status. Internal status reflects the current status of jobs and job streams in the Tivoli Workload Scheduler engine. Internal status is unique to Tivoli Workload Scheduler. See also Status.
334
Local options. The local options are defined in the localopts file. Each workstation in the Tivoli Workload Scheduler network must have a localopts file. The settings in this file apply only to that workstation. See also Global options.
properties of a job or job stream and is unique to that job or job stream. A predefined prompt is defined in the Tivoli Workload Scheduler database and can be used by any job or job stream.
M
Master Domain Manager. In a Tivoli Workload Scheduler network, the master domain manager maintains the files used to document the scheduling objects. It creates the plan at the start of each day, and performs all logging and reporting for the network.
R
Resource. Resources can represent either physical or logical resources on your system. Once defined in Tivoli Workload Scheduler database, they can be used as dependencies for jobs and job streams. For example, you can define a resource named tapes with a unit value of two. Then, define jobs that require two available tape drives as a dependency. Jobs with this dependency cannot run concurrently because each time a job is run the tapes resource is in use. Run cycle. A run cycle specifies the days that a job stream is scheduled to run. In Tivoli Workload Scheduler there are three types of run cycles you can specify for a job stream: a Simple run cycle, a Weekly run cycle, or a Calendar run cycle (commonly called a calendar). Note that each type of run cycle can be inclusionary or exclusionary. That is, each run cycle can define the days a job stream is included in the production cycle, or the days a job stream is excluded from the production cycle. When you define multiple run cycles to a job stream, and inclusionary and exclusionary run cycles specify the same days, the exclusionary run cycles take precedent.
N
Network agent. A type of extended agent used to create dependencies between jobs and job streams on separate Tivoli Workload Scheduler networks. See also Internetwork (INET) dependency.
P
Parameter. Parameters are used to substitute values into your jobs and job streams. When using a parameter in a job script, the value is substituted at run time. In this case, the parameter must be defined on the workstation where it will be used. Parameters cannot be used when scripting extended agent jobs. Plan. The plan contains all job scheduling activity planned for a period of one day. In Tivoli Workload Scheduler, the plan is created every 24 hours and consists of all the jobs, job streams, and dependency objects that are scheduled to run for that day. All job streams for which you have created run cycles are automatically scheduled and included in the plan. As the production cycle progresses, the jobs and job streams in the plan are run according to their time restrictions and other dependencies. Any jobs or job streams that do not run successfully are rolled over into the next days plan. Planned Start Time. The time that Tivoli Workload Scheduler estimates a job instance will start. This estimate is based on start times of previous executions. Predecessor. A job that must complete successfully before successor jobs can begin execution. Priority . Tivoli Workload Scheduler has a queuing system for jobs and job streams in the plan. You can assign a priority level for each job and job stream from 0 to 101. A priority of 0 will not run. Prompt. Prompts can be used as dependencies for jobs and job streams. A prompt must be answered affirmatively for the dependent job or job stream to launch. There are two types of prompts: predefined and ad hoc. An ad hoc prompt is defined within the
S
Simple Run Cycle. A simple run cycle is a specific set of user-defined days a job stream is run. A simple run cycle is defined for a specific job stream and cannot be used by multiple job streams. For more information see Run Cycle. Status. Status reflects the current job or job stream status within the Job Scheduling Console. The Job Scheduling Console status is common to Tivoli Workload Scheduler and OPC. See also Internal status. stdlist file. A standard list file is created for each job launched by Tivoli Workload Scheduler. Standard list files contain header and trailer banners, echoed commands, errors, and warnings. These files can be used to troubleshoot problems in job execution. Successor. A job that cannot start until all of the predecessor jobs on which it is dependent are completed successfully. Symphony file. This file contains the scheduling information needed by the Production Control process (batchman) to run the plan. The file is built and loaded during the pre-production phase. During the production phase, it is continually updated to indicate the current status of production processing: work completed, work in progress, work to be done. To
Glossary
335
manage production processing, the contents of the Symphony file (plan) can be displayed and altered with the Job Scheduling console.
W
Weekly Run Cycle. A run cycle that specifies the days of the week that a job stream is run. For example, a job stream can be specified to run every Monday, Wednesday, and Friday using a weekly run cycle. A weekly run cycle is defined for a specific job stream and cannot be used by multiple job streams. For more information see Run Cycle.
T
Time restrictions. Time restrictions can be specified for both jobs and job streams. A time can be specified for execution to begin, or a time can be specified after which execution will not be attempted. By specifying both, you can define a window within which a job or job stream will run. For jobs, you can also specify a repetition rate. For example, you can have Tivoli Workload Scheduler launch the same job every 30 minutes between the hours of 8:30 a.m. and 1:30 p.m. Tivoli Management Framework (TMF). The base software that is required to run the applications in the Tivoli product suite. This software infrastructure enables the integration of systems management applications from Tivoli Systems Inc. and the Tivoli Partners. The Tivoli Management Framework includes the following: v Object request broker (oserv) v Distributed object database v Basic administration functions v Basic application services v Basic desktop services such as the graphical user interface In a Tivoli environment, the Tivoli Management Framework is installed on every client and server. However, the TMR server is the only server that holds the full object database. Tivoli Management Region (TMR). In a Tivoli environment, a Tivoli server and the set of clients that it serves. An organization can have more than one TMR. A TMR addresses the physical connectivity of resources whereas a policy region addresses the logical organization of resources. Tree view. The view on the left side of the Job Scheduling Console that displays the Tivoli Workload Scheduler server, groups of default lists, and groups of user created lists.
| | | | | | | |
Wildcards. The wildcards for Tivoli Workload Scheduler are: ? Replaces one alphanumeric character.
% Replaces one numeric character. * Replaces zero or more alphanumeric characters in the Tivoli Job Scheduling console.
@ Replaces zero or more alphanumeric characters in the Tivoli Workload Scheduler command line.
| Wildcards are generally used to refine a search for one | or more objects in the database. For example, if you | want to display all workstations, you can enter the | asterisk (*) wildcard. To get a listing of workstations | site1 through site8, you can enter site%.
Workstation. A workstation is usually an individual computer on which jobs and job streams are run. They are defined in the Tivoli Workload Scheduler database as a unique object. A workstation definition is required for every computer that runs jobs or job streams in the Workload Scheduler network. Workstation class. A workstation class is a group of workstations. Any number of workstations can be placed in a class. Job streams and jobs can be assigned to run on a workstation class. This makes replication of a job or job stream across many workstations easy.
X
X-agent. See Extended agent.
U
User . For Windows NT only, the user name specified in a job definitions Logon field must have a matching user definition. The definitions furnish the user passwords required by Tivoli Workload Scheduler to launch jobs. Utility commands. A set of command-line executables for managing Tivoli Workload Scheduler.
336
Index A
absolute keyword 122, 127, 128, 133 adddep job command 135 adddep sched command 137 altpass command 139 altpri command 140 APARs IY46485 16 IY46918 185 IY48317 279 IY49121.1 306, 307, 308 IY49333 57, 118, 306 IY52215 186, 187 IY52475 90 IY52493 233 IY53050 97 IY53064 298, 313 IY53459 186 IY53755 82 IY57906 303 IY58702 25 at command 219 at keyword 15, 83 auditing enabling 325 header format 329 log files 325 log format 325 sample log entries 330 commands (continued) console 146 continue 62, 147 create 63 deldep job 148 deldep sched 150 delete 65 display 67, 152 dumpsec 298, 312 edit 70 exit 71, 153 fence 154 help 155 kill 156 limit cpu 157 limit sched 158 link 159 list 67 listsym 161 logman 8 makesec 298, 313 modify 72 new 74 print 67 recall 162 redo 75, 163 release job 165 release sched 167 rep1 269 rep11 272 rep2 269 rep3 269 rep4a 269 rep4b 269 rep7 270 rep8 271 replace 77 reply 169 reptr 273 rerun 170 resource 173 schedulr 8 setsym 174 showcpus 175 showdomain 179 showfiles 180 showjobs 182 showprompts 190 showresources 192 showschedules 194 shutdown 197 stageman 8 start 198 status 200 stop 201 stop ;progressive 203 submit docommand 204 submit file 206 submit job 208 submit sched 210 switchmgr 212 commands (continued) system command 213 tellop 214 unlink 215 validate 79 version 80, 217 xref 274 comments keyword 86 compiler command 8 composer 7 composer command descriptions 58 composer command syntax 57 composer control characters 55 composer editor 56 composer program 55 composer reference 31 confirm command 145 confirmed keyword 87 conman 7 conman command list 118 conman command prompt 117 conman command syntax 117 conman reference 115 conman, running 115 connector 298 console command 146 continue command 147 control characters 55 control characters, conman 115 conventions typeface xvii cpuinfo command 226 cpuname 33 creating an internetwork dependency 292 creating the security file 298 customer support see Software Support 316
B
batch command 219 batchman 8 behindfirewall 35 books xii see publications xvi
C
calendar definition 49 cancel job command 142 cancel sched command 143 carryforward keyword 15, 85 caxtract command 224 centralized security 297 command prompt 56 command prompt, conman 117 command syntax, conman 117 commands add 60 adddep job 135 adddep sched 137 altpass 139 altpri 140 build 61 cancel job 141 cancel sched 143 compiler 8 confirm 145 Copyright IBM Corp. 1999, 2004
D
database entries 31 database object editor 56 datecalc command 227 dbexpand command 231 dead zones 319 deadline 15 deadline keyword 88 Defects 155861 42 169932 175 170660 108 deldep command 148 deldep sched command 150 delete command 232 delimiters 57 delimiters, conman 118 dependency file 125, 131, 180 internetwork 289, 292 directory names, notation xviii
337
O
239 offline output 116 offline output for UNIX 56 on keyword 15, 105 online publications accessing xvi onuntil 113 onuntil keyword 113 opens keyword 108 order of objects, security file 305 order of users, security file 304 ordering publications xvi os_type 33
E
e-mail contact xvi editor, database object 56 education see Tivoli technical training xvii enabling auditing 325 end keyword 89 environment variables, notation xviii every keyword 90 evtsize command 234 except keyword 91 exit command 153 extended agent overview 279 reference 279 workstation definition 279
K
keyjob keyword 101 keysched keyword 102 keywords absolute 122, 127, 128, 133 deadline 88 keywords, scheduling language 82 kill command 156 killproc command 265 knowledge bases, searching to find software problem resolution 315
P
parameter definition 50 parms command 246 path names, notation xviii paxtract command 247 priority keyword 110 problem determination describing problem for IBM Software Support 317 determining business impact for IBM Software Support 317 submitting problem to IBM Software Support 317 process tree on UNIX 9 process tree on Windows 11 product library xii production cycle 7 automating 13 progressive 203 prompt definition 52 prompt keyword 111 prxtract command 248 publications xii accessing online xvi ordering xvi
L
late status 88 latest start time 15 library xii limit cpu command 157 limit keyword 103 limit sched command 158 link command 159 listproc command 265 listsym command 161 local security 297 logman command 8
F
feedback about publications xvi fence command 154 file dependency 125, 131, 180 final job stream adding 13 customizing 13 firewall setting 35 fixes, obtaining 316 follows keyword 93 freedays keyword 94
M
maestro command 241 mailman 8 makecal command 242 makesec 298 makesec command 8, 298, 313 managing security 298 managing time zone 319 manuals xii see publications xvi metronome.pl command 244 morestdl command 245
G
globalopts file auditing feature 325
H
help command 155
R
r11xtract command 249 rccondsucc 43, 97 recall command 162 redo command 163 refreshing the connectors 325 release command 250 release job command 165 release sched command 167 rep1 command 269 rep11 command 272 rep2 command 269 rep3 command 269 rep4a command 269 rep4b command 269 rep7 command 270 rep8 command 271 reply command 169 reptr command 273 rerun command 170 reserved words 31 resource command 173 resource definition 54 rextract command 252
I
information centers, searching to find software problem resolution 315 Internet, searching to find software problem resolution 315, 316 internetwork dependency 289, 292
N
needs keyword 104 netman 8 netmth access method 289 network agent internetwork dependency 292 netmth 289 options file 291 overview 289 workstation 289 workstation command line example 291 notation environment variables xviii path names xviii typeface xviii
J
jbxtract command 235 Jnextday running 13 job definition 42 job launch 8 job scheduling console 7 job statement keyword 96 job states 126 jobinfo command 237
338
S
sample log entries, auditing 330 sample reports 275 sample security file 308 schedule keyword 112 scheduling language 81 scheduling language keywords 82 scheduling objects 31 schedulr command 8 security centralized 297 creating the security file 298 dumpsec 298 file syntax 299 local 297 makesec 298 managing 298 order of objects 305 order of user definitions 304 sample file 308 template file 298 UNIX superuser 306 user definitions 299 variables 305 security file updating 298 security level enabled 35 force 35 on 35 selecting job streams in commands 128 selecting jobs in commands 120 setsym command 174 setup_env 299 Sfinal adding 13 showcpus command 175 showdomains command 179 showexec command 254 showfiles command 180 showjobs command 182 showprompts command 191 showresources command 192 showschedules command 194 shutdown command 197 Software Support contacting 316 describing problem for IBM Software Support 317 determining business impact for IBM Software Support 317 submitting problem to IBM Software Support 317 special characters, composer 57 special characters, conman 118 SSL communication enabled 35 force 35 on 35 stageman command 8 start command 198 start time 15
start time, latest 15 startup command 255 states, jobs 126 status late 88 status command 200 stop ;progressive command 203 stop command 201 stop scheduler processes 16, 203 submit docommand 204 submit file command 206 submit job command 208 submit sched command 210 success condition 43, 97 support Web site, searching to find software problem resolution 315 switchmgr command 212 syntax, scheduling language 81 syntax, security file 299 system command, conman 213 system commands, conman 115
T
tellop command 214 template file, security 298 terminal output 55, 116 time zone 121 Tivoli software information center xvi Tivoli technical training xvii training, Tivoli technical xvii typeface conventions xvii
U
UNIX superuser, security 306 unlink command 215 unsupported commands 265 until keyword 113 user definition 47 user definitions, security 298 user interfaces 7 user prompts 116 utility commands 219
V
variables, notation for xviii variables, security file 305 version command 217, 256
W
wildcard characters 57, 117 wmaeutil 298 wmaeutil command 28, 258, 325 workstation class definition 39 workstation definition 33 writer 8
X
xref command 274 xrxtrct command 260
Index
339
340
Printed in USA
SC32-1274-02