These modules are designed to be used by programs running in the BRTE. BRTE programs are written in ksh. These functions are only supported for the korn shell, i.e. ksh.

These functions tend to build upon one another. For instance, the do_command function relies on the check_execute function which in turn relies on the print_to_log function.

The BRTE program functions are defined to the program by including the file batch_modules. This would be done by the following syntax:

The BRTE entry point batch_modules takes two optional arguments.

A -a can be specified which changes the logging behaviour of the program. The default behaviour is to create a log for each execution of the program. With this option a single log is created for all executions of the program within a 24 hour period.

The -d option requires a parameter that specifies an alternative brte directory. This option is primarily aimed for debugging brte itself. However, it can be used in an emergency situation if a bug is found in the prodution copy installed on a system. A copy of the production brte installation can be made and modified and then the program that failed modifed so that it uses this option to use the copied brte. This option should not be used in normal production programs.

These functions assist in the implementation of BRTE. (See the BRTE Documentation for details.) Primarily this is done by assigning values to the abstract system definition defined in the BRTE documentation.

There is certain information that BRTE cannot know for every application. This information like the application, what DB servers that it uses, etc must be passed to BRTE in a standard way. The mechanism that BRTE uses is to read the file $HOME/brte_profile as soon as batch_modules is called. For system accounts this file will contain environment variable definitions like SYSTEMNAME and ORA_SERVERS. Developer accounts should have some logic in this file that will result in the appropriate definitions for the same variables. (See the BRTE Examples for more details.)

A base set of application variables must be set before BRTE functions can assign the proper values of the ASD (Abstract System Definition). These values are set in $HOME/brte_profile. If the BRTE functions detect that these application variables are not set, then they will force an error immediately.

In addition to the requisite variables above, there are a set of variables that control the execution of certain functions. Various functions will behave differently depending on how or if these variables are set. These variables can be set by the developer within the program. Another method is to use the $HOME/brte_profile to set some of these variables. By using this method, code does not need to change as a script migrates from one environment to another. Below is a list of variables that should be defined in $HOME/brte_profile if they are required by a program.

The following variables are also used by BRTE but can be set anywhere inside a program. These variables do not need to change depending on what environment i.e. production, QA test, unit testing, development.

The functions are defined by calling in the program batch_modules. In addition batch_modules sets the variables in Table 1. Some of these variables are read-only. batch_modules is written to be re-entrant though. If a chain of programs each call batch_modules, the first program will set the automatic read-only variables for the subsequent programs. For instance no new log file will be created. The children programs will all write to the parent's log file.

This is the entry point for BRTE. This is actually a program that sourced directly into the target program. batch_modules is responsible for defining all the resources that other BRTE functions will rely on. It performs the following tasks:

1. Check if batch_modules has been previously called. If it has it returns a 0 and allows the calling program to continue.

2. Process options passed.

3. Inline run the $HOME/brte_profile file.

4. Define all BRTE required variables and defaults for other BRTE variables where applicable.

5. Mark application functions in $SYSTEMHOME/lib/brte for autoloading.

6. Mark BRTE functions for autoloading.

7. Initialize log file and checks for success.

8. Checks to see if program has been WNR'd.

9. Returns control to the calling program.

-a Normally BRTE creates a new log file each time the program is executed. This option changes that behavior so that no more than one log file is created per day. This should be used for programs that are frequently executed during the day, i.e. 3 or more times per day.

-d Specifies an alternate location for the BRTE functions. Usually used only when debugging BRTE itself, but could be used in an emergency in production.

batch_modules will either return a 0 or will panic. It may put certain warnings into the log if it discovers them.

^*Assignment logic is specified in ksh syntax.