Executing Jobs

Jobs execute commands on computers or in enterprise business solutions (SAP, PeopleSoft, Siebel, Oracle Applications, etc.). The scripts on the Job Process pages are processed in a specific way. Depending on the JCL (Job Control Language) and the script elements, an executable job is generated for the corresponding target system and transmitted via file transfer.

The Automation Engine scripting language(if existing) and the JCL lines are processed and, subsequently, the JCL is sent to the target system. The Automation Engine scripting language is never sent to the target system.

This page includes the following:

Windows

On Windows the User Account Control (UAC) should be turned off to prevent errors because of missing permissions

Database

The database Agent regularly attempts to establish a connection to the database if its first attempt was not successful. The administrator can define this interval in the connect= INI file parameter. The Job remains in Active status during these attempts to establish a connection.

The Job also remains in status Active if the Agent is not able to establish a connection because the login data specified in the Login object is incorrect. It must be canceled manually either in the Process Monitoring perspective, using the CANCEL_UC_OBJECT script function or directly in the Job by monitoring the maximum runtime (see Runtime Page).

Note: It is not possible to end commands that the Agent has been processing in the database when job canceling is initiated. The JDBC interface does not provide this function. Jobs can only be canceled between two commands. Therefore, the Agent waits until a command which is just being processed is finalized and cancels the job afterward. Use the functions of your database Server to cancel ongoing commands.

UNIX

The user specified in the Login object also owns the Job and report file. The administrator can assign authorizations for both files through the Agent INI file (parameters JobFileMode= and ReportMode=).

Note: It is recommended to set the Login_check= parameter in the INI file to yes. This means that the password specified in the Login object is checked. If you set it to no, only the user name is checked.

Troubleshooting - LD_LIBRARY_PATH Overridden

Jobs scheduled to run on UNIX Agents can include customer-specific scripts. The Automation Engine processes these scripts first, which results in a combination of customer-specific snippets and AE calls. One of these calls is the messenger; an Agent binary that must be started using the latest system libraries.

The LD_LIBRARY_PATH environment variable takes control of the library paths the loader uses when running executable objects. If a customer-specific script modifies the LD_LIBRARY_PATH environment variable while the loader is running, the change remains in the shell environment. If the messenger binary runs after that, loading fails and the job execution is aborted. In this case, the corresponding error messages are written in the logs.

Example

.../agents/bin/ucxjlx6m: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found

.../agents/bin/ucxjlx6m: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found

To prevent these kind of issues, make sure that any change to the LD_LIBRARY_PATH environment variable is undone as soon as it is no longer needed. To do so, you can use a sub-shell.

Example

Before using a sub-shell:

# Need to load some special binary
export LD_LIBRARY_PATH=/my_special_libs/
./run_my_special_bin.sh

# LD_LIBRARY_PATH continues to be overridden

After using a sub-shell:

(
# Need to load some special binary
export LD_LIBRARY_PATH=/my_special_libs/
./run_my_special_bin.sh
)
# LD_LIBRARY_PATH no longer overridden