Process Page

Job objects (JOBS) have three pages in which you enter the script to be processed. If you enter scripts on all of them, they are processed in the following order: 1. Pre-Process, 2. Process, 3. Post-Process, 4. Child Post-Process (SAP only). This page is different for a number of target platforms, as is the case of SAP jobs, for example, where you can choose between building the scripts either writing code in the script editor or adding predefined, ready-to-use commands available in the Forms view.

The script on this page is processed either at job activation or at job start, depending on the option Generate Job at that you have selected on the Attributes Pages of Executable Objects.

Commands that should be processed in the header, such as setting specific agent attributes, or executed before the Job Messenger starts, must be defined in the Pre-Process Page. On the other hand, commands that should be processed after the job has ended are stored in the Post-Process Page. This way you can influence the final end of this job.

These lines correspond to the particular JCL (Job Control Language) of the target system and are transferred to the target system exactly as they are. DATA lines can, for example, contain BS2000 commands or MS DOS commands for batch processing.

Special Functions for Guardian/NSK

Please refer to Automated Handling of Input Prompts for information on the special functions that are available for the automatic handling of input requests.

JCL for z/OS

The actual JCL is indicated here. Do NOT specify a job card (to be specified through the attributes) or an end card.

SAP JCL Interpreted by the SAP Agent

Because there is no JCL in SAP, the Automation Engine supplies one that is interpreted by the SAP agent and converted to processing statements for the target system. For details see About SAP JCL.

Enabling an Interpreted for Windows

You can also enter a script for use with an external interpreter. To enable the interpretation of that script, use :BEGIN_EXT_INTERPRETERS... :END_EXT_INTERPRETERS.

In addition, the Storage object's binary files can be attached and transferred to the Windows agent using the :ATTACH_RES script function to attach and transfer these binary files.

To be able to use these functions you must configure the UC_EXT_INTERPRETERS_* - Register External Interpreters and :REGISTER_VARIABLE variables.

Enabling an Interpreted for Unix

The same condition applies to UNIX, namely, you can enter a script for use with an external interpreter. To enable the interpretation of that script, use :BEGIN_EXT_INTERPRETERS... :END_EXT_INTERPRETERS.

In addition the Storage object's binary files can be attached and transferred to the UNIX agent, using the :ATTACH_RES script function to attach and transfer these binary files.

To be able to use these functions you must configure the UC_EXT_INTERPRETERS_* - Register External Interpreters and :REGISTER_VARIABLE variables.

Windows BAT and Powershell Examples

The Windows BAT script below puts the output of the C:\Temp directory into a file and checks whether the command ran successfully. If the command does not complete successfully, the job will end with the return code from the dir command:

dir C:\temp /S >> C:\temp\test.txt

@set retcode=%errorlevel%

@if NOT %ERRORLEVEL% == 0 goto :retcode

The Windows Powershell script below gets content of the C:\Temp directory and puts the output into a file. Then the error code from Powershell will be checked and if is not equal to 0, the job aborts with $LastExitCode, which is the equivalent to %ERRORLEVEL% in the CMD.EXE/.BAT script.

Get-ChildItem C:\Temp > C:\Temp\test.txt

if( $LastExitCode -ne 0 )

{ __uc_return $LastExitCode }

The __uc_return function can be used for ending of Powershell jobs. It only works if the Windows job type is set to Interpreter, but not with using the new functions :BEGIN_EXT_INTERPRETERS... :END_EXT_INTERPRETERS.