Controlling Batch Operations

Connection parameters

Regardless of the type of triggering, you need to give the Batch Controller some parameters for connecting to a CM: a user ID, its password, the CM's port number, and the address of the CM's host computer. The Batch Controller logs on as the user you specify inthe infranet.connection parameter. If you want the logon to use both the user ID and password, set infranet.login.type = 1; if you want to not use the password, set infranet.login.type = 0.

In the batch.lock.socket.addr parameter, you must specify the socket number to lock on. If in doubt, check with your system administrator for the number of an unused socket that can be used exclusively by the Batch Controller. You needn't change the default value, 11971, unless some other application is using that socket number.

If you want to write a stack trace of any runtime exceptions in the log file, set infranet.log.logallebuf to true . To disable this feature, set it to false .

Time-to-run parameters

When your system's heaviest load typically occurs, you might want some handlers to run less often than they do in slacker times. The Batch Controller divides the day into a high-load period and a low-load period to let you balance the demand for system resources.

Specify the starting time of your system's busiest period in the batch.start.highload.time parameter. Specify the starting time of your system's slowest period in the batch.end.highload.time parameter. For each of these times, specify the hour, minute, and second in this format: hhmmss, using a 24-hour scale. For each handler, you can specify the maximum number of simultaneous actions during each of these two periods.

The end parameter must be greater than the start parameter. If you do specify start , it must be greater than end . Specifying the same value for both parameters causes an error.

In the batch.check.interval parameter, specify the time, in seconds, between checks for occurrences of the type specified in batch.timed.events or batch.random.events . Omitting batch.check.interval causes an error.

Log-file parameter

For logging, you can specify the level of information reported, the full path of the log file, and whether to print a stack trace of runtime exceptions. Set infranet.log.level to 0 if you want no logging, 1 for error messages only, 2 to also include warnings, or 3 to also include debugging messages. Set infranet.log.file to the path and file name for the Batch Controller log file.

If you omit infranet.log.file , Infranet uses default.pinlog in the current directory. Omitting infranet.log.level causes an error.

Timeout-limit parameters

You can also set timeout limits for handlers to start their objects and to complete their execution. Set batch.handler.start.wait to the number of seconds allowed for the handler to update its own object status from STARTING to STARTED , and set batch.handler.end.wait to the number of seconds allowed for updating from STARTED to some other state, such as COMPLETED . Writing Custom Batch Handlers describes all of the handler states.

Omitting either batch.handler.start.wait or batch.handler.end.wait causes an error.

Example of parameters

This example demonstrates the general parameters described above:

---

	infranet.connection	pcp://root.0.0.0.1:mypass@myserver:11960/service/pcm_client
	infranet.login.type	1
	infranet.log.logallebuf	true
	batch.lock.socket.addr	11971
	batch.start.highload.time	083000
	batch.end.highload.time	211500
	infranet.log.file	/opt/portal/6.1/apps/batch_controller/batch.pinlog
	infranet.log.level	2
	batch.handler.start.wait	600
	batch.handler.end.wait	43200

---

 

In this example, the Batch Controller logs on to the CM host on myserver , port 11960, as user root.0.0.0.1 , using password mypass . High usage is expected between 8:30 a.m. and 9:15 p.m. Logging writes a normal level of information to file batch.pinlog and prints a stack trace if any program errors are found. Timeouts for updating object status are 10 minutes (600 seconds) for going to STARTED and 12 hours (43,200 seconds) for going to COMPLETED or some other state.

Metronomic execution

To set up metronomic execution:

1. In the batch.timed.events parameter, specify the event identifiers. If you have two or more event identifiers, separate them with commas.
2. In the event_id .name parameter, enter a brief descriptive label for the event. This name can include spaces or any other characters. It can be of any length, but brief names are easier to read.
3. In the event_id .handlers parameter, specify identifiers for one or more handlers that are to be triggered when the event occurs. If you have two or more handlers, separate them with commas.
4. (Optional) In the event_id .start parameter, specify when you want the first execution to occur, in this format: hhmmss , using a 24-hour scale. If you omit this parameter, the first execution occurs immediately after the Batch Controller starts.
5. In the event_id .interval parameter, specify the frequency, in seconds, for triggering the associated handler. Failing to specify the interval causes an error.
6. (Optional) In the event_id .count parameter, specify how many times to execute this batch handler. If you do not specify this limit, batch handlers run repeatedly at the fixed interval, for as long as the Batch Controller is running.

Caution! You must specify batch.timed.events or batch.random.events or both. Specifying neither causes the Batch Controller to shut down just after it is started, because it is given nothing to do.

This example demonstrates the metronomic parameters described above:

---

	batch.timed.events	event4
	. . .
	event4.name	Hourly tally
	event4.handlers	handler4
	event4.start	000000
	event4.interval	3600
	event4.count	4

---

 

In this example, the occurrence specified as event4 is named Hourly tally . It runs handler4 for the first time at midnight ( 000000 ), then runs it again every hour (3,600 seconds) after that until it has run four times. If it cannot run at a scheduled time because previous executions are not finished, it runs again immediately as soon as possible. For example, consider this time line for event4 , above:

Scheduled execution

To set up scheduled execution:

In the batch.timed.events parameter, specify the event identifiers. If you have two or more event identifiers, separate them with commas.

In the event_id .name parameter, enter a brief descriptive label for the event. This name can include spaces or any other characters. It can be of any length, but brief names are easier to read.

In the event_id .handlers parameter, specify identifiers for one or more handlers that are to be triggered when the event occurs. If you have two or more handlers, separate them with commas.

In the event_id .at parameter, specify each time when you want execution to occur, in this format: hhmmss , using a 24-hour scale.

This example demonstrates the schedule parameters described above:

---

	batch.timed.events	event5
	. . .
	event5.name	Sporadic tally
	event5.handlers	handler5
	event5.at	004500, 0022500, 045500
	. . .
	handler5.name	Sporadic Handler
	handler5.max.at.lowload.time	8
	handler5.max.at.highload.time	4
	handler5.start.string	/apps/sporadic -uel

---

 

In this example, the program specified as event5 is named Sporadic tally . It runs only at 12:45 a.m., 2:25 a.m., and 4:55 a.m. If it cannot run at a scheduled time because previous executions are not finished, it runs again immediately as soon as possible.