Process Pages
As a developer and object designer you add functional logic to your objects on their Process pages using the Automation Engine scripting language. All executable objects have at least a Process page. Some object types have additional pre-process, post-process and child-post process pages.
Notes:
- Scripts are processed either when the object is activated or when it starts, depending on settings on the Attributes Page of the object.
- If the object has more than one Process page, be aware of the order in which the pages are processed. For more information, see Script Processing.
- Each Process page can contain up to 32767 lines. However, script generation is canceled if the script generates more than 1000 JCL lines. If your script generates more JCL lines, you can change this limit using the script statement :PUT_ATT, attribute MAX_JCL_LINES.
- The specific conditions that you can define in your script depend on the object type.
This page includes the following:
Process Page
The Process page is available in all executable objects.
In JMX, PeopleSoft, SAP and SQL Jobs, you have two options to create scripts:
- Writing code in the script editor
- Adding predefined, ready-to-use commands available in the Forms view.
For more information, see Forms View on the Process Page.
Platform-Specific Information
-
Special Functions for Guardian/NSK
For information on the special functions that are available for the automatic handling of input requests see Automated Handling of Input Prompts.
-
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
There is no JCL in SAP. For this reason, the Automation Engine supplies one that is interpreted by the SAP and converted to processing statements for the target system. For more information, see JCL for SAP.
-
Enabling an Interpreter for Windows and Unix
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.
The binary files of the Storage can be attached and transferred to the Windows Agent using the :ATTACH_RES script function.
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 :retcodeThe 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.
See also Configuring Include Objects for External Interpreter Calls.
Pre-Process Page
Available for Job objects (JOBS) only. Here you enter statements that prepare the Job for execution on the Pre-Process page. For example, use the :PUT_ATT statement to set attributes such as the Agent for the Job.
The Pre-Process and Process pages are processed simultaneously.
Pre-Process statements are executed in the job header, which means that you can add statements that are executed before the Job Messenger gets involved in the execution. For details on the Job Messenger, see Agent Job Messenger.
Tip: You can use the :INC_SCRIPT script statement to insert the content of this page on any other Process page.
Additional Information for z/OS
On the Pre-Process page, you can define all JCL commands (e.g. JCLLIB, JOBCAT, JOBLIB, OUTPUT etc. ) that must be defined after the job card but before the script first step.
The Event Monitor only considers steps on the Pre-Process page if the first step has the same name as the Automation Engine system. Otherwise, canceled pre-processing job steps do not affect the end status of an Automation Engine job.
Example
In this example, the name of the Automation Engine system is UC4PROD.
Pre-Process page
//JOBLIB DD DISP=SHR,DSN=.....
// DD DISP=SHR,DSN=....
//UC4PROD EXEC PGM=modname
Process page
//STEP01 EXEC PGM=IEFBR14
//STEP01 EXEC PGM=IEBGENER
Available for Job objects (JOBS) only: scripts on the Post Process page are processed after the job has ended. These scripts are processed when the job is has finished normally, or ended after partial completion, such as when the job is canceled. Post-processing commands let you influence how a job ends.
Tips:
- Use the :RSET script statement to transfer script variables between the Process and Post Process pages. This script statement returns the value which has been assigned to the script variable in the Process page.
- Use the :MODIFY_STATE script statement when you want to change the final ending of a job. This script statement lets you modify the job return code and status supplied by the Job Messenger in the trailer.
- Use the PREP_PROCESS_REPORT script statement on the Post Process page to analyze reports. You can then for example define an ENDED_NOT_OK status for a job even if the job has technically ended normally.
Notes:
- Post process scripts cannot include JCL lines.
- Post process commands are NOT executed in cases of ENDED_LOST task statuses.
- You cannot use the following script statements on the Post Process page:
- :PUT_ATT - Setting attributes for job generation is irrelevant.
- :EXIT - Canceling script processing with return code > "0" is not allowed.
- :STOP - Interrupting script processing is not allowed.
SAP and PeopleSoft jobs have an additional Child Post Process page. This is because SAP and PeopleSoft jobs usually contain statements that start multiple processes (sub jobs) in the target systems. This job structure is replicated in the Automic Web Interface. The SAP or PeopleSoft job you create in the Automation Engine is the parent of those sub jobs (child processes) and serves as their container.
The script you enter on the Child Post-Process page is processed for each individual child process immediately after it has finished.
See also: