Windows Jobs

Windows Jobs define Windows operating system processing steps to be carried out in a target system. Like all other Job objects (JOBS), Windows Jobs can run independently or they can be added to a group (JOBG) or to a workflow. For more information about the integration between the Automation Engine and Windows please refer to AE and Windows.

The Windows page contains the Windows-specific execution parameters.

Defining Windows Jobs

A Windows Job definition is made up of the following pages:

• Standard pages that are always available, no matter what type of object you are defining:
  • General Page
  • Version Management Page
  • Documentation Page
• Additional pages that are always available for executable objects:
  • Process Pages
  • Attributes Page
  • Output Pages
  • Variables Page
  • Prompt Sets Page
  • Rollback Page
• The Windows page described here.

To Define the Start Parameters of a Windows Job

Define how the Automation Engine Windows Job object should start the job on the Windows target system.

1. Define how to execute the script in Interpreter Type:

   • Batch

     The JCL contained on the Process page is executed as a Windows batch file.

   • Command (cmd.exe)

     The Windows CMD Shell contains a number of external commands that Windows supplies as separate executable files. Select the Command (cmd.exe) option to display the Command field and enter an external command. What you enter here is passed on to the Windows command line and executed.

     Note: For internal Windows commands such as dir, cd, or echo, you have the following options:

     • Use the Batch option instead

     • Call cmd.exe using /c to isolate and call a particular internal command

       Example: cmd.exe /c dir

   • Custom interpreter

     Administrator users can specify a custom interpreter in the INI file of the Windows Agent. Select this option to transfer the JCL contained on the Process as a file to that interpreter to process it. For more information, see the descriptions of ECPEXE= and ecpext= at Agent Windows 64-bit.
     

     Note: In certain cases, the AE has to insert a comment line into the script which is forwarded to the custom interpreter. This action is necessary because different interpreters use different prefixes for single-line comments. To provide the correct prefix for the defined interpreter, make sure you set the &UC_REM_PRF variable accordingly. Add a statement to the Pre-Process page such as shown in the example for powershell.exe where # is used to comment a line:

     :set &UC_REM_PRF = "# "

   Best Practices

   Windows distinguishes between four program types:

   • Graphical User Interface programs
   • Console programs
   • Operating system commands, for example DIR or SET

   Start GUI and console programs from the command line to take advantage of the Automation Engine and retrieve the correct program exit code.

   OS commands can only be started using a BAT file. Check the return code after each command to react quickly to errors.

   Test the BAT file or the command line on the target system before starting the job through the Automation Engine. If possible, perform your tests with the user that will later execute the Automation Engine Windows Job.

2. Specify the Working Directory in which the Job must run.

3. Activate the Batch Mode: Log on as batch user to execute the job in batch mode. This is necessary when admin rights are required to execute programs and UAC (User Account Control) is activated on the target system. For more information, see User Account Control in WindowsUser Account Control (UAC) in Windows.

4. In View Job on Desktop specify if you want to have the view that shows the execution of the job displayed. This is particularly useful for GUI programs because they sometimes display messages that require user intervention.

5. Some jobs or programs in Windows start other child programs. The parent and the child run asynchronously. When the Automation Engine Windows Job starts one of these parent programs, it can happen that the parent ends while the child is still running. If this happens, the status of the Automation Engine Windows Job is also ended although some processes have not finished yet.

   Example

   A job contains a script with three command lines where the first one starts three sub-processes. When the three command lines have been successfully executed, the Windows Agent returns this information to the Automation Engine, which considers the Job as finished. As the sub-processes are running asynchronously, it can happen that they are not finished yet. The Automation Engine has no control over them and does not know about their status. This situation has the following consequences:

   • The information written to the reports is incorrect.
   • If the Job is started again while the sub-processes are still running, it will end abnormally.
   • If a process is canceled, its sub-process is not automatically canceled, which may cause an unwanted result.

   You can avoid these situations by connecting the Automation Engine Windows Job Object with its sub-processes within one Windows OS job object. The Windows OS job object is then in charge of signaling the end of the Automation Engine object when all its child processes have also ended and to also cancel all its child processes when the job is canceled.

   You can connect them using the options available in Use Windows OS Job Object:

   • Default setting from agent: Whether the Windows OS job object is used or not depends on the default setting specified in the INI file of the Windows Agent.
   • Yes: The Windows OS Job Object is used. The parent and child processed are connected.
   • No: The Windows OS Job Object is not used and no connection is established between parent and child processes.

6. For information on the Job Report section, see Job Reports.

7. Save your changes

See also:

• Windows Job: Watch the Video
• Jobs (JOBS)
• Test Programs
• Windows Job Object