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. Depending on its type, the object may have more than one Process page on which you can write scripts.

Process pages can contain up to 32767 lines. However, if the script generates more than 1000 JCL lines, its generation is canceled. If your script generates more JCL lines, you can change this limit using MAX_JCL_LINES in the :PUT_ATT script statement.

Processing Order

The scripts in the Process pages are processed in the following order:

1. Pre-Process page and Process page.
   
2. Child Post Process page.
3. Post Process page.

Tip: Read Working with the Script Editor before starting to write your scripts to learn about the script editor functions.

This page includes the following:

The script on this page is processed during the Generation stage. More specifically, the scripts on this and on the Pre Process pages are processed together during the generation stage, first the script on the Pre Process and then the script on the Process page. For detailed information about what happens during the script generation, see Script Generation In Detail.

For JMX, PeopleSoft, SAP, and SQL Jobs, the Process page provides two options to create scripts:

• Writing code in the script editor

  This option is the standard one, available for all executable objects.

• Adding predefined, ready-to-use commands available in the Forms view

For more information, see Forms View on the Process Page.

Platform-Specific Information on the Process Page

• Special Functions for Guardian/NSK

  For information about 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 statement (to be specified through the attributes) or an end statement.

• SAP JCL Interpreted by the SAP Agent

  SAP has no JCL. For this reason, the Automation Engine supplies one that is interpreted by SAP and converted to processing statements for the target system. For more information, see About SAP JCL.

• 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, configure the UC_EXT_INTERPRETERS_* - Register External Interpreters and :REGISTER_VARIABLE variables.

• Windows BAT and PowerShell Examples

  • This Windows BAT script 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 ends 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

  • This Windows PowerShell script gets content of the C:\Temp directory and puts the output into a file. The error code from Powershell is then checked. If it is not 0, the job aborts with $LastExitCode. This exit code 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. This function works only if the Windows job type is set to Interpreter. The function does not work with the new functions :BEGIN_EXT_INTERPRETERS... :END_EXT_INTERPRETERS.

For more information, see Configuring Include Objects for External Interpreter Calls.

Available for Jobs (JOBS) only. On the Pre-Process page you enter statements that prepare the Job for execution. A typical example is the :PUT_ATT statement, which sets attributes such as the Agent.

Since pre-process statements are executed in the Job header, you can add statements that are executed before the Job Messenger gets involved in the execution.

Tip: Use the :INC_SCRIPT script statement to insert the content of this page on any other process page.

For more information, see:

• Agent Job Messenger
• :PUT_ATT
• Agent Job Messenger
• :INC_SCRIPT

z/OS on the Pre-Process Page

On the Pre-Process page, you can define all JCL commands (e.g. JCLLIB, JOBCAT, JOBLIB, OUTPUT etc.). These commands must be defined after the Job statement but before the first step in the script.

The Event Monitor considers steps on the Pre-Process page only 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) and File Transfers (JOBF) only. Scripts on the Post Process page are processed after the Job has ended normally or after a partial completion. A Job has partially completed if, for example, it is canceled. With post-processing commands you influence how a Job ends.

The following rules apply:

• 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

Tips: 

• Use the :RSET script statement to transfer script variables between the Process and Post Process pages. This script statement returns the value that has been assigned to the script variable in the Process page.
• Use the :MODIFY_STATE script statement 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 define an ENDED_NOT_OK status for a Job even if the Job has technically ended normally.

For more information, see:

• :PUT_ATT
• :EXIT
• :STOP

SAP and PeopleSoft Jobs usually contain statements that start multiple processes (sub jobs) in the target systems. To replicate this job structure in the Automic Web Interface, SAP and PeopleSoft Jobs have an extra Child Post Process page. 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.